Pre-construction planning for contractors: the practical guide to designing the system before you run it
- Jan 22
- 17 min read
Updated: May 18
By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control
Founder, NEC Planning Solutions Ltd
There is a four-to-twelve-week window on every NEC project that the contractor's commercial outturn depends on more than any other stage of delivery. The window opens when the contract is awarded and closes when the team mobilises to site. It is unremarkable in most contractors' calendars. It does not appear on the master programme as a distinct phase. It is rarely discussed at board level. Yet what gets set up during this window will determine, more than any subsequent decision, whether the project's commercial position is defensible at month eighteen, whether compensation events flow through assessment cleanly, whether the accepted programme retains its value as a contractual reference, and whether the project director is fighting fires on every Wednesday morning or running a coherent operation.
This is not the standard view of pre-construction planning. The standard view is that pre-construction is preparation: getting ready to start, lining up the supply chain, making sure the team has what they need before site begins. That view is not wrong, but it is dramatically incomplete. Preparation is what happens. Design of the controls system is what should happen. The two activities use the same calendar slot and consume the same resources, but they produce different outcomes and they require different mindsets.
The strongest contractors understand pre-construction as the only window in the entire NEC project lifecycle where they design the system rather than run it. Once site starts, every controls decision is reactive: responses to compensation events, revisions to programmes, defences against challenges, recoveries from slip. The contractor running the project is operating inside a system that was designed before mobilisation, and the quality of that design determines how much of their attention is consumed by managing the system rather than managing the project.
Most contractors miss this. They use the pre-construction window for preparation and intend to "tidy up the controls" once site is properly running. The intention is well meant and almost always defeated by reality. By the time site is properly running, the controls system has set in whatever shape it took at mobilisation, and changing it requires rework that the project never has time for. The system that ran in week one is the system that runs in week eighty. Pre-construction planning is therefore the only window where the system is genuinely changeable. After mobilisation, the same effort produces a fraction of the result.
This article explains what pre-construction planning is for, why the systems-design view changes how it should be approached, what the pre-construction pack must contain to do its job, and why the contractors who treat the four-to-twelve-week mobilisation window as their most consequential planning investment outperform those who treat it as a transitional period. It is written for delivery directors, project managers, and commercial leads on civils, mechanical, electrical, energy, and infrastructure projects who recognise the pattern but have not yet seen it named.
Why pre-construction is the only design window
Every project has stages where decisions are made and stages where decisions are executed. NEC projects are no different. The award is a decision point. The programme submission is a decision point. The compensation event quotation is a decision point. But these later decisions all operate inside a controls system that was designed elsewhere. The compensation event quotation uses the WBS, the calendars, the activity coding, and the update rules that were set up at mobilisation. The programme revision sits on top of a baseline whose structure was determined in pre-construction. The project director's weekly report uses the data structure that the planning team established before site began.
This is not a procedural observation. It is a structural one. The controls system is the lens through which everything else on the project is seen. A programme built on a poor WBS will produce poor compensation event analysis even if the analysis itself is technically competent, because the data does not aggregate the way the analysis needs it to. Reporting that runs on the wrong cadence will produce decisions that lag the project by weeks, regardless of how good the report content is. Procurement disconnected from the programme logic will produce surprises on the critical path even if the procurement team is performing well, because the surprises live in the gap between two systems that were never properly integrated.
These weaknesses cannot be fixed easily once the project is running. The reason is not technical. The reason is operational. Live projects do not stop. The team is running updates, addressing compensation events, managing site issues, responding to clients. There is no quiet week in which the controls structure can be redesigned. Each week, the team uses what was set up at mobilisation, and each week, the cost of changing it grows. By month four, changing the WBS would invalidate four months of progress data. By month nine, changing the update cadence would mean reconciling nine months of reports to a different rhythm. By month twelve, the system has petrified.
This is what makes pre-construction the only design window. Before mobilisation, every decision about the controls system is cheap and reversible. After mobilisation, every decision is expensive and partially irreversible. Treating the window as preparation rather than as design exchanges a large opportunity for a small one. The contractors who recognise this allocate pre-construction time deliberately to system design choices that will pay off across the entire project lifecycle. The contractors who do not allocate pre-construction time to readiness tasks that produce immediate gains and structural costs that surface later.
The article on what the project manager checks when reviewing your NEC programme covers the project manager's review sequence and reveals how many of the rejection grounds trace back to controls-system decisions made before site began. Most contractors who experience repeated rejection cycles are not failing on individual programmes. They are running a system that was never designed to pass the project manager's review test, and each programme submission inherits the structural issues from the system it was built within.
What pre-construction is genuinely for
Pre-construction planning, properly understood, is the assembly of the foundation that the entire project will be measured against. It produces five outputs that form a single hand-over pack: a programme, the constraints and interfaces map embedded in the programme, the procurement integration, the programme narrative, and the controls set-up that the delivery team will use from day one of mobilisation. Each of these is necessary. None is sufficient on its own. The pack works when all five are produced together as a coherent system, not when each is produced separately and assumed to align.
The programme is the centre. It is logic-linked, sequenced realistically, with milestones and key dates derived from contract data and operational reality rather than from optimism. It is built in the scheduling tool that will be used for the rest of the project, not a different one that requires translation later. It includes time risk allowances visibly distributed across activities, float that is calculable, and a critical path that runs through the activities that will actually drive completion rather than through artefacts of how the schedule was structured. The article on Primavera P6 for NEC programmes covers the schedule-design choices that determine whether a programme will support compensation event assessment when the time comes.
The constraints and interfaces map sits inside the programme rather than alongside it. Access windows, permit requirements, third-party dependencies, design release dates, possessions, shutdown windows, and commissioning prerequisites are embedded in the logic as constraints with clear ownership and clear consequence-of-slip. They are not listed in a separate document that the planning team has to remember to consult. They are visible in the programme as activities, milestones, and constraints, with the responsibility flagged through activity coding so the project manager and the delivery team can filter the schedule by interface owner. Constraints that exist outside the programme are constraints that will be missed.
The procurement integration ties long-lead items, work package awards, vendor data dates, and material delivery to the programme logic. The programme shows when materials are needed on site as a derived date driven by the install activity logic, not as a forecast date that the procurement team assumes is achievable. When a vendor data return slips, the impact on the install activity is visible in the schedule the same week, not three months later when the install team reaches the activity and discovers that the data is not yet available. Long-lead items are identified, sequenced into the procurement schedule, and shown on the master programme with their procurement-side activities so the critical path includes procurement activity and not just construction activity.
The programme narrative is the document that explains the programme to anybody who reads it without opening the schedule files. It states the basis of schedule, the key assumptions, the construction methodology, the major sequences, the critical path logic, the time risk approach, and the interface ownership. It is written in prose that a commercial director, a project manager, or a client representative can read in fifteen to twenty minutes and understand what the contractor's plan is and why. Without the narrative, the programme is a Gantt chart that requires interpretation. With the narrative, the programme is a coherent argument about how the project will be delivered. The article on why your programme narrative is the part evaluators actually read covers the narrative discipline in detail.
The controls set-up is the structural element most teams underplan and that produces the most lasting consequences. It includes the work breakdown structure, the activity coding conventions, the calendar definitions, the data date discipline, the progress rules, the cut-off schedule, the update cadence, the reporting format, and the handover brief that tells the delivery team how the system will be operated. Each of these decisions is binding once the project starts running updates. Each is hard to change later. The strongest pre-construction packs include this element as a deliberate design exercise rather than as a default that emerges from individual planner habits.
These five outputs together are what the pre-construction planning service at NEC Planning Solutions delivers. The service positions pre-construction as Stage 2 of a four-stage lifecycle that begins with tender programmes, proceeds through pre-construction to live controls, and continues through compensation event support. The positioning matters because it reflects the structural truth: pre-construction is not a self-contained activity. It is the design moment in a four-stage system where the decisions made here propagate forward through every subsequent stage.
Why most pre-construction packs do not work
The standard pre-construction approach in most UK contracting organisations produces packs that look complete but do not function as a controls system. Five recurring failure modes account for the majority of pre-construction packs that fail to deliver their intended value.
The procurement plan is parallel to the programme rather than embedded in it. The procurement team produces a schedule of orders, lead times, and delivery dates. The programme team produces a schedule of activities, durations, and milestones. The two schedules are aligned at mobilisation but diverge as soon as either changes. By month three, the procurement schedule shows one set of dates and the programme shows another, and the gap between them is invisible until somebody on site needs materials that have not been ordered. The fix is structural: procurement activities sit inside the programme as activities with logic links to the install activities they precede, and the procurement schedule is generated as a filtered view of the programme rather than as a separate document.
The constraints and interfaces are documented but not embedded. The pre-construction pack contains a list of access windows, permit requirements, and third-party interfaces. The programme does not enforce them. When the planning team builds the schedule, they reference the list but do not necessarily constrain activities to honour the windows. By the time site needs to enforce a permit window, the schedule has already drifted past it, and the realisation comes too late to plan the work around the constraint. The fix is to apply constraints to the schedule at build time and surface any violations as build errors, not to document them in a parallel reference that the schedule does not enforce.
The narrative does not match the programme. The programme narrative is written by one person, often the bid manager or the project manager. The programme is built by another, usually the planner. The two work from different reference points and produce documents that look aligned at the surface but diverge in detail. When the project manager reviews the programme submission, the discrepancies are immediately visible: the narrative says one thing, the schedule shows another, and the credibility of both is undermined. The fix is to write the narrative and build the programme as a single integrated exercise, with cross-checks that ensure the narrative cannot describe a sequence the schedule does not support.
The WBS is not designed for the project. The work breakdown structure is the lens through which all subsequent reporting, analysis, and forensics will be done. A WBS designed for the bid is structured to demonstrate scope coverage to the client. A WBS designed for delivery is structured to support compensation event analysis, progress reporting, and cost allocation across the life of the project. Most pre-construction packs use the bid WBS by default, and the delivery team inherits a structure that does not work for the work they have to do. By month four, the team is producing reports that have to be reconstructed from the schedule because the WBS does not aggregate the way the reports need it to.
The handover to the delivery team is informal. The planning team produces the pack and assumes the delivery team will run it. The delivery team receives the pack and assumes the planning team has set it up correctly. Neither team sits down with the other to walk through how the system will operate week to week, what the update rules are, what the cut-off discipline looks like, what the reporting cadence requires. The first time the discrepancies become visible is at the first update cycle, when the delivery team discovers that the update rules they had assumed are not the rules the planning team had built around. The fix is a deliberate handover session that takes the form of a working operating manual, not an email transferring files.
These five failures are recurring rather than universal. Some pre-construction packs avoid one or two of them by accident or by individual planner discipline. Few avoid all five. The strongest contractor planning operations have explicit checks against each failure mode built into their pre-construction process, and the check is a deliberate gate rather than an aspiration. The article on NEC clause 31 programme acceptance covers the acceptance test that the project manager applies to the resulting programme, and most of the rejection grounds it identifies trace back to one of the five failures above.
What good looks like: the pre-construction pack that runs for eighteen months
A pre-construction pack that genuinely functions as a controls system has a recognisable shape. It can be described by what the delivery team can do at the first site meeting on day one of mobilisation, without further preparation.
The delivery team can run the first update without asking how. The data date is set, the cut-off rules are documented, the progress methodology is agreed, and the update template is in place. The first weekly progress meeting starts with a programme that is current within the agreed cut-off and a report that uses the agreed format.
The procurement team can issue the next purchase order without checking what the programme expects. The procurement schedule is a view of the programme, the long-lead items are identified, the materials-on-site dates are derived from install activities, and the procurement team's actions are aligned to the schedule's logic without separate reconciliation.
The commercial team can assess a notified compensation event against a programme that supports the analysis. The accepted programme has been formally accepted (or is on a clear path to acceptance), the WBS supports the data segregation that compensation event analysis requires, the time risk allowances are visible, and the activity coding allows fragments of the schedule to be filtered for impact assessment. The article on how to structure a time impact assessment under NEC4 covers the structural elements that make this possible.
The project manager can review the programme without rejecting it. The submission complies with clause 31.2 in form and substance. The structural checks (open ends, logic, critical path, calendars, constraints) are clean. The realism test holds. The scope compliance is verifiable. The narrative explains the schedule in prose the project manager can follow. The article on what the project manager checks when reviewing your NEC programme covers the review sequence in detail.
The project director has a single source of truth. The programme is the master record. The reports flow from it. The procurement schedule, the interface register, the assumptions log, and the milestone tracker are all derived views of the same underlying data. There is no separate spreadsheet that runs in parallel. The single source of truth is the foundation of the project's commercial defensibility and the project director's operational visibility.
This is not an aspirational picture. It is the standard achievable outcome of a properly executed pre-construction planning exercise. The four-to-twelve-week mobilisation window contains enough time to produce all of these conditions if the time is allocated to system design rather than to readiness tasks. The contractors who allocate it this way report that the first six months of the project run materially differently from projects where pre-construction was treated as preparation. Issues that would otherwise consume executive attention either do not arise or are resolved quickly because the system was designed to handle them.
The commercial case for pre-construction investment
Most contractors invest in pre-construction planning at a level that reflects its perceived urgency rather than its actual value. The perceived urgency is moderate. There is no immediate site pressure, no compensation event demanding response, no programme submission with a hard deadline. The perceived value is therefore moderate and the investment matches.
The actual value is significantly higher and significantly under-recognised. The investment in pre-construction pays off in three measurable ways across the life of the project.
The first is in compensation event recovery. A project with a properly designed controls system from mobilisation produces compensation event quotations that are accepted on first submission at materially higher rates than projects where the controls system was assembled informally. The article on how to get NEC4 compensation event quotations agreed covers the structural elements of acceptance-optimised quotations, all of which depend on a controls system that was designed to support them. Across a multi-year project with twenty or more compensation events, the cumulative recovery difference is significant.
The second is in programme acceptance. A first submission designed against the project manager's actual review sequence is accepted faster and more reliably than a submission produced from a generic template. Each programme acceptance preserves the contractor's commercial baseline. Each rejection or delayed acceptance weakens it. Across the life of the project, the difference between a project where the accepted programme is consistently current and one where it drifts for months at a time is substantial.
The third is in management attention. Project directors who run projects with well-designed controls systems spend their time on high-value decisions: commercial negotiations, client relationships, strategic responses to events. Project directors who run projects with poorly designed controls systems spend their time on low-value coordination: reconciling reports, finding missing data, explaining gaps between documents. The opportunity cost of the second pattern compounds across the life of the project and the career of the director.
The investment required to capture these benefits is modest. A well-executed pre-construction planning exercise on a typical NEC project, including the full pack covered above, requires four to twelve weeks of dedicated planning resource depending on project complexity. The commercial benefit, conservatively estimated, runs to multiples of the investment cost across the project lifecycle. The disciplines required are not technically demanding. They require organisational commitment to treating pre-construction as a design exercise rather than as a transitional phase.
For contractors who want this discipline embedded without building the internal capability themselves, specialist pre-construction planning support provides the four-to-twelve-week intervention as a managed service. The cost is small compared to the commercial benefit. The benefit accrues over the entire project lifecycle from mobilisation to completion.
The bottom line
Pre-construction planning is the only window in the entire NEC project lifecycle where the contractor designs the system rather than runs it. Every later stage operates inside a controls system that was set up before mobilisation. The quality of that design determines how much of the project's commercial outturn is captured and how much of the management team's attention is consumed by structural friction that should have been engineered out.
Most contractors treat pre-construction as preparation: getting ready to start. The framing is not wrong but it is dramatically incomplete. Preparation is what happens. Design of the controls system is what should happen. The two activities use the same calendar slot but produce different outcomes and require different mindsets. The contractors who allocate pre-construction time to deliberate system design outperform those who allocate it to readiness tasks, and the difference compounds across every subsequent stage.
The pre-construction pack that genuinely functions as a controls system contains five integrated outputs: a logic-linked programme that is the master record for the project, a constraints and interfaces map embedded in the programme rather than parallel to it, procurement integration that ties material delivery to install activity logic, a programme narrative that explains the schedule in prose a non-planner can follow, and a controls set-up that the delivery team can operate from day one of mobilisation without further preparation. Each is necessary. The pack works when all five are produced as a coherent system.
The five recurring failure modes are recognisable and avoidable: procurement parallel to the programme rather than embedded in it, constraints documented but not enforced, narrative diverging from the programme in detail, WBS designed for the bid rather than for delivery, and informal handover that treats the delivery team as recipients rather than operators. Each can be fixed structurally rather than tactically. Each is fixable only in pre-construction.
The four-to-twelve-week mobilisation window is the most consequential planning investment available on an NEC project. The investment itself is modest. The commercial benefit accrues across the entire project lifecycle and is significantly larger than the contractors who underinvest in pre-construction typically recognise. The disciplines required are organisational rather than technical. The contractors who establish them produce projects that are commercially defensible at month eighteen and operationally calmer throughout. The contractors who do not produce projects where the executive team is fighting fires that the controls system should have handled silently.
The choice is structural. The window closes at mobilisation and does not reopen.
FAQ
What is pre-construction planning for a contractor?
Pre-construction planning is the assembly of the controls system that the project will be measured against from mobilisation to completion. It is not preparation for site start. It is the design exercise that produces the integrated pack of outputs (programme, constraints map, procurement integration, narrative, controls set-up) which the delivery team will operate from day one. Most other definitions describe what gets produced in the window. The systems-design definition captures what the window is actually for.
How long does pre-construction planning take?
Typically four to twelve weeks between contract award and site mobilisation, compressed on fast-track or framework projects. The window length depends on project complexity, interface count, procurement scope, and the maturity of the design at award. The work itself takes the time required to do it properly; underinvesting in the window produces structural costs that surface later in the project.
Why does the controls set-up matter so much?
Because every subsequent decision on the project is made through it. The work breakdown structure, the activity coding, the calendar definitions, the update rules, and the reporting format set in pre-construction will shape how the project is reported, how compensation events are assessed, and how disputes are evidenced for the next eighteen months. Changing these decisions later requires rework that live projects do not have time for.
What is the difference between a pre-construction programme and the accepted programme under clause 31?
The pre-construction programme is the contractor's plan as designed before site begins. The accepted programme is the contractual reference baseline established under clause 31.3 once the project manager has accepted the submitted programme. They start from the same logic but the accepted programme is the formal contractual document that subsequent compensation event assessments will reference. A well-designed pre-construction programme is built specifically to pass the project manager's clause 31.3 acceptance test, so the transition from pre-construction programme to accepted programme is procedural rather than reconstructive.
Can pre-construction discipline be retrofitted on a live project?
Partially. The narrative can be improved, the WBS can be supplemented, the reporting format can evolve. But the structural decisions (data date discipline, cut-off rules, activity coding conventions, calendar definitions) become difficult to change once they have been operating for several months because changing them invalidates progress data and disrupts running reports. Retrofitting is therefore always more expensive and partially less effective than designing the system properly during pre-construction.
About the author
Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BSc in Mechanical Engineering and postgraduate training in Planning and Control.
NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.
Mobilising on a new project and want pre-construction set up properly?
If the controls system is being assembled informally by individual planners, if the procurement schedule is running parallel to the programme rather than embedded in it, or if the four-to-twelve-week mobilisation window is being used for readiness tasks rather than systems design, specialist pre-construction planning support builds the integrated pack that the delivery team can run for the entire project from day one.
