Primavera P6 for NEC programmes: The Complete Contractor Guide
- 4 days ago
- 20 min read
There is a particular failure mode that recurs on NEC projects across the UK, and it almost always starts with the same assumption.
The contractor wins the job. The planning team opens Primavera P6 and starts building the programme. Primavera is the industry-standard scheduling tool, used on everything from small civils packages to multi-billion-pound nuclear projects. There is no reason to think it will not produce an NEC-compliant programme. The planner builds the schedule, the programme is submitted for acceptance under clause 31, and everybody moves on.
Three months later, a compensation event arises. The contractor tries to demonstrate the time impact using the accepted programme. And something awkward becomes visible. The programme looks credible on screen. The activities are there. The dates are there. But the underlying structure, meaning the logic relationships, the constraints, the critical path integrity, the calendars, the way float is calculated, does not actually support the compensation event assessment the contract requires. The planner did what P6 schedulers do by default, not what NEC specifically needs. And the difference is about to cost the contractor time and money.
This pattern is surprisingly common. Primavera P6 is a powerful scheduling tool, but it is also an opinionated one. Its defaults, its behaviours, and the working habits it encourages in schedulers were shaped by decades of use on engineering and construction projects under contracts that work very differently from NEC. A P6 schedule built to generic best practice will usually look fine on the surface and fail at the moments that matter most: compensation event assessment, delay analysis, acceptance under clause 31, and forensic defence when a dispute arrives.
This article explains what a P6 schedule needs to do differently to work properly under NEC. It is written for planners who use P6 daily but have not had the contract-specific training to bridge the gap, and for commercial directors and project managers who need to understand why their planning teams keep producing programmes that the project manager will not accept or that cannot defend entitlement when tested.
What P6 is, and what it is not
Primavera P6 is not a contract tool. It is a critical path method scheduling engine wrapped around a relational database. It calculates early and late dates based on activity durations, logic links, calendars, and constraints. It visualises that calculation as a Gantt chart. It produces reports. It does not know what contract the project is being delivered under, and it does not adjust its behaviour to suit one.
This matters because NEC places specific demands on a programme that generic P6 best practice does not automatically meet. Clause 31.2 requires the programme to show a long list of specific information, much of which is not default P6 output. Clause 63.5 requires the programme to support a specific kind of time impact analysis, which depends on the schedule being in a particular structural state. Clause 32 expects the programme to be revised on a regular cadence, with visible change tracked against an accepted baseline. P6 does not enforce any of this. It will happily produce a schedule that is beautifully scheduled, mathematically perfect, and useless under NEC.
The contractors who use P6 well on NEC projects understand this distinction. The software is a medium. The contract is the message. The job is to configure P6 so that its output expresses what the contract needs, rather than what P6 defaults produce. The article on NEC clause 31 programme acceptance covers what the contract needs. This article covers how P6 should be set up to meet those needs.
Work Breakdown Structure: planning for the contract, not the software
Most P6 schedulers, trained on general construction, build the WBS around project management logic: phases, areas, disciplines, deliverables. A typical structure might split the project into Enabling Works, Substructure, Superstructure, Building Services, Fit-Out, Commissioning. Each level decomposes into progressively smaller work packages until activities sit at the bottom.
This approach does not produce an NEC-compliant programme.
NEC requires the programme to show specific things that a generic WBS does not naturally surface. Access dates for different parts of the site. Key dates that trigger contractor liability if missed. Points at which the employer is required to provide information or acceptance. Dates when plant and materials are provided by the employer. Dates when work by others affects the contractor's sequence. A WBS built around construction phases alone will bury these elements inside activity details or, worse, leave them out entirely.
The solution is to design the WBS with the contract in mind. The highest levels should reflect the commercial and contractual structure, not just the construction sequence. A first-level node for Client and Employer Obligations gives visibility to access dates, information provision dates, and acceptances required from the project manager. A first-level node for Key Dates gives contractual milestones their own place in the schedule. A first-level node for Compensation Events, starting empty, provides a designated location for CE fragnets as they arise during the project, rather than having them disappear into whichever area WBS node the planner happens to choose at the time.
Inside these contract-structural nodes, the construction WBS runs as normal: areas, disciplines, deliverables. But the contract elements are surfaced, visible, and available for acceptance review without the project manager having to dig for them.
A WBS designed this way also improves compensation event management significantly. When CE-07 arises, the fragnet for the time impact is built under the Compensation Events WBS node with a consistent code (CE07-*), preserving the logic that connects the CE to the affected activities in the construction WBS. When the quotation is produced, the CE fragnet can be exported cleanly. When the CE is implemented and the programme is revised, the fragnet becomes part of the live schedule without losing its origin. This is the kind of discipline that produces accepted programmes and defensible compensation event assessments.
Activity coding: the commercial layer
Activity codes in P6 are one of the most underused features on NEC projects. Most planners treat them as optional labels. On an NEC project, they are the commercial layer of the schedule: the means by which the programme speaks the language the contract uses.
At minimum, an NEC programme in P6 should carry activity codes for Responsibility (contractor, employer, others), Compensation Event (blank for baseline activities, populated with CE number for CE-affected activities), Clause Reference (where a specific activity corresponds to a contractual obligation such as an access date or key date), and Status (baseline, implemented CE, rejected CE, pending).
These codes let the programme be filtered and reported in ways the contract needs. When the project manager asks what activities are affected by CE-12, a P6 filter on the CE code produces the answer immediately. When the QS needs to see all activities sitting under employer-owned obligations, the filter produces it. When the next revision is submitted for acceptance, a view filtered by Status = Implemented CE shows exactly what has changed since the last accepted programme, which is what clause 32 requires.
Activity codes also make compensation event quotations significantly cleaner. A quotation showing the impacted activities with CE-12 flagged across them is immediately legible. The project manager sees the cause-and-effect chain without needing to reconstruct it. The same schedule submitted without activity codes forces the project manager to take the contractor's narrative word for which activities are affected, which creates grounds for disagreement.
The effort to set up activity codes properly at project outset is two to three hours. The effort saved across the project runs to days. Most contractors never make this investment and pay the price through every subsequent compensation event.
Calendars: the silent distorter of entitlement
Calendars are the most frequently misconfigured element of NEC schedules in P6, and the misconfigurations have direct commercial consequences.
P6 allows multiple calendars: global, project, and resource. Activities default to the project calendar unless assigned otherwise. The default calendar typically shows a five-day working week, standard working hours, and UK bank holidays. This sounds reasonable and is almost always wrong for an NEC programme.
The specific issue is that different types of work on a construction project happen on different working patterns, and those patterns affect how delay is measured. Site-based construction work typically runs on a five- or six-day week with seasonal weather considerations. Design and approval activities run on a five-day professional calendar, often with the employer's own working week applying, not the contractor's. Manufacturing and procurement activities may run on a seven-day manufacturer's calendar, factory shutdowns excluded. Commissioning activities may run continuously.
When all activities sit on a single default calendar, the programme misrepresents how delay will actually manifest. A design approval delay of two weeks counted on a seven-day calendar produces a different forecast than the same delay counted on a five-day professional calendar. A compensation event affecting manufacturing lead time calculated on the site calendar understates the true impact because weekends the factory works through are incorrectly shown as non-working.
The fix is to define separate calendars for each distinct working pattern on the project, and assign activities to the correct calendar at the point of creation. Employer acceptance activities on the employer's calendar. Factory procurement activities on a manufacturer's calendar. Site works on the contractor's site calendar. Commissioning activities on a continuous calendar if that reflects reality.
The effort is modest. Set up once at project outset, maintained as calendars change, it eliminates an entire category of arguments about how delay is measured. Without it, compensation event assessments will produce numbers that nobody can agree on because the underlying calendar assumptions are wrong.
Logic links: finish-to-start is not enough
NEC compensation event assessment requires the programme to show how delay to one activity flows through to planned completion. The ability to demonstrate that flow depends on the logic relationships between activities. A programme with incomplete or shallow logic cannot demonstrate the time impact of a compensation event because the mechanical chain connecting cause to effect is missing.
Most P6 planners, trained on general construction, default to finish-to-start relationships and leave it at that. This works for simple linear sequences but fails on anything with concurrent, overlapping, or interface-sensitive work, which is most real construction projects and especially anything with M&E, commissioning, or multi-party interfaces.
NEC schedules should use the full range of relationship types where they reflect reality. Start-to-start relationships where two activities must begin in parallel, such as survey and design work feeding concurrent design packages. Finish-to-finish relationships where two activities must complete together, such as commissioning activities that cannot hand over until all prerequisite systems are operational. Start-to-finish relationships, rare but useful for certain logistics and handover scenarios. Lags and leads where realistic sequencing requires an overlap or a gap, always with an explanation captured somewhere.
The test of whether the logic is adequate is simple. Pick any activity at random in the programme. If that activity is delayed by two weeks, does the schedule show the correct downstream effect without any manual intervention? If not, the logic is incomplete and the programme cannot support proper compensation event assessment.
A related problem is open ends. An open-ended activity is one with no predecessor (an open start) or no successor (an open finish). Open starts should only exist at the project start milestone. Open finishes should only exist at completion milestones. Any other open end is a logic error and will distort the critical path calculation.
P6 has built-in reports that identify open ends and missing logic. Running these reports is a fifteen-minute check. Doing it before every submission catches structural problems before the project manager catches them.
Constraints: the enemy of prospective analysis
Constraints in P6 are perhaps the single most common source of disputes over programme quality on NEC projects.
A constraint is a fixed date applied to an activity that overrides the calculated early or late dates the scheduling engine would otherwise produce. Common constraint types are Must Start On, Must Finish On, Start No Earlier Than, Finish No Later Than. In the right hands, constraints represent real-world fixed dates: contractually mandated access dates, sectional completion dates, key dates that cannot move. In the wrong hands, constraints are used to force the schedule to produce desired dates without having the logic underneath to support them.
This is a critical distinction. A programme with appropriate constraints is one where the constraints reflect genuine contractual or physical realities and the rest of the schedule logic flows around them. A programme with inappropriate constraints is one where activities have been tied to dates the planner wants to show, regardless of whether the logic supports those dates.
The problem with inappropriate constraints is that they destroy prospective analysis. NEC compensation event assessment requires the schedule to demonstrate what would have happened but for the event. If critical activities are constrained to specific dates, the schedule cannot show what would have happened. It shows what the constraints forced it to show. When a compensation event arises, the constraints prevent the delay flowing through to planned completion, which makes the time impact invisible. The contractor has removed its own entitlement by over-constraining the programme.
The discipline is to minimise constraints to those that genuinely exist in the contract. Access dates under the contract. Key dates. Sectional completion dates. Completion date. Any other constraint needs justification. "The client expects it to finish by 31 March" is not a constraint. "Clause X21 sectional completion of the east block by 15 March 2026" is.
P6 allows constraint reports. Running this report on any accepted programme is a good sanity check. If the report shows more than a handful of constraints, and most of them are not tied to contractual dates, the schedule is probably over-constrained and is not capable of supporting proper compensation event assessment.
Float, critical path, and terminal float visibility
NEC treats float differently from most other contracts, and P6's default handling of float does not match NEC's contractual treatment without specific configuration.
The short version is that NEC4 distinguishes between free float, total float, and terminal float. Free and total float sit within the critical path network and are shared between the parties depending on who causes delay. Terminal float is the gap between planned completion and the completion date, and it belongs to the contractor under clause 63.5. This means terminal float is protected against being consumed by compensation events: the completion date moves by the amount planned completion is delayed, preserving the terminal float that existed before.
P6 does not automatically show this distinction. The schedule calculates total float and displays it as a single figure. Terminal float, as a concept, exists only if the schedule is configured to show it. The standard way to do this is to include a dedicated Planned Completion milestone and a separate Completion Date milestone, with the gap between them visible as an activity or clearly labelled on the Gantt view. The article on time risk allowance and terminal float in NEC covers the contractual mechanics in detail.
The scheduling option that most affects critical path behaviour is the Longest Path setting. By default, P6 calculates the critical path as activities with zero or negative total float. This works on most projects but can produce misleading results when the programme has multiple completion dates or sectional completions, or when there is significant terminal float. The Longest Path option identifies the critical path as the longest chain of activities back to the start, regardless of float values. On NEC projects with sectional completions or meaningful terminal float, Longest Path usually produces a more reliable critical path identification.
A related issue is out-of-sequence progress. Activities that are progressed without their predecessors being complete produce logic anomalies that distort critical path calculation. P6 has settings to control how out-of-sequence progress is handled: retained logic (predecessor must still complete), progress override (activity can complete regardless of predecessor), or actual dates. The default is retained logic, which is generally correct for NEC, but planners should verify and document the setting at project outset.
Time risk allowance: visible or invisible
Clause 31.2 of NEC4 explicitly requires the programme to show time risk allowances. These are the contractor's own risk periods within activities, distinct from float. The commercial logic is that the contractor is entitled to carry risk allowance to cover genuine project-specific uncertainty, but the allowance has to be visible so that the project manager and the contract's assessment mechanism can distinguish risk from padding.
P6 does not have a built-in time risk allowance feature. The planner has to decide how to represent TRA in the schedule. There are three common approaches, each with advantages and disadvantages.
The first approach is separate risk activities. Each significant activity that carries risk has a dedicated TRA activity immediately following it in the logic chain, showing the risk allowance as its own visible duration. This is the clearest approach and generally the one NEC assessors prefer, because the risk is explicit and can be separately examined. The disadvantage is that it increases schedule line count significantly on a complex project.
The second approach is risk columns. Activity durations include the risk allowance but a separate user-defined field (a custom column in P6) records the TRA value, and the schedule shows the value in a dedicated column in the layout. The advantage is less schedule bulk. The disadvantage is that the risk is less immediately visible on the Gantt chart and requires knowing to look at the column.
The third approach is TRA within activity durations. The risk is embedded in the duration without being separately identified. This is simplest but does not comply with clause 31.2, which requires TRA to be visible. Programmes using this approach are vulnerable to non-acceptance under clause 31.3 on the grounds that they do not show the information the contract requires.
Whichever approach is used, the principle is that risk allowance should be identifiable on the schedule in a way that a project manager reviewing the programme can see. Hidden risk is one of the most common reasons for programmes being challenged or rejected at acceptance. Visible risk, even if it is generously allowed, is usually accepted because it is transparent.
Baselines and progress: the audit trail NEC actually needs
NEC4 expects every programme revision submitted for acceptance to show progress on activities and the effect of that progress on remaining work. The project manager can compare any revision to the accepted baseline and see what has changed, what progress has been made, and where the critical path has moved. This sounds obvious, but in P6 it requires specific configuration.
The first requirement is a clean baseline. At the moment a programme is accepted, the planner should save a baseline in P6 labelled with the acceptance date and version. This baseline is the reference against which subsequent revisions are compared. Baselines should not be overwritten. If a revised programme is subsequently accepted, a new baseline is saved, and the previous one is kept as a historical record. Over the life of a project, the baseline library becomes the chronological record of what was agreed when.
The second requirement is consistent progress updating. Progress should be recorded against the accepted baseline using actual start, actual finish, and remaining duration. P6's progress features work correctly when used as intended: record actuals as they occur, update remaining durations based on forecast from the current data date forward, and let the schedule calculate the rest. The frequent mistake is to manually type in revised start or finish dates on ongoing activities, which breaks the scheduling logic and produces misleading critical path calculations.
The third requirement is a clear data date discipline. The data date is the point in time that separates actual progress from remaining forecast. P6 uses the data date to calculate when remaining work can start and finish. An accepted programme has a specific data date. The next revision has a new data date. Every revision should move the data date forward consistently, not backwards or to arbitrary dates.
The fourth requirement is variance reporting. P6 can report the variance between the current schedule and any saved baseline: changes in activity dates, changes in logic, additions and deletions, changes in durations. Running a variance report against the accepted baseline at every revision produces exactly the kind of change narrative that clause 32 requires. The report becomes part of the programme submission package and saves the project manager having to reconstruct what changed.
Together, these four disciplines produce the audit trail NEC actually expects. Without them, every programme revision is a fresh submission with no visible relationship to what was previously accepted, and clause 32's change-tracking expectation cannot be met.
Primavera P6 for NEC programmes: the fragnet discipline
When a compensation event occurs, the contractor must demonstrate the time impact through a change to the accepted programme. The standard technique for doing this in P6 is a fragnet: a small network of activities showing the compensation event and its effect on downstream work, built under a dedicated WBS node and linked into the main schedule logic.
A good CE fragnet has a consistent structure. It sits under the Compensation Events WBS node, identified by CE number. It starts with an activity representing the compensation event itself, marked with an appropriate constraint reflecting the dividing date. It includes any new work the CE requires (extra scope, additional activities, resequencing steps). It links into the main schedule logic at the points where the CE affects ongoing or future activities. It shows the time impact as a clear movement of planned completion, with the magnitude of movement calculated by the schedule, not asserted by the planner.
The discipline matters because a well-built fragnet is largely self-demonstrating. The project manager sees the CE, sees the logic, sees the impact, and can verify it within the scheduling environment. The compensation event quotation explaining the time impact is then a narrative of something visible in the programme, not an argument about what should happen.
A poorly built fragnet, by contrast, requires extensive narrative to explain. The CE is dropped into the schedule without clear logic linking it to affected activities. The time impact is asserted in the quotation but cannot be verified from the schedule. The project manager challenges the quotation, the contractor struggles to support it, and the assessment drifts towards retrospective argument rather than prospective analysis.
For contractors handling compensation events regularly, developing a standard fragnet template in P6, a set of standardised activities and relationships that can be adapted per CE, significantly accelerates quotation production and improves defensibility. The article on NEC delay analysis and extension of time covers the contractual context in detail.
Layouts and views: what the project manager actually sees
P6 allows extensive customisation of layouts: which columns are shown, how activities are grouped, what filters are applied, what colours are used for different activity types. Most planners settle into a default layout and rarely change it. On NEC projects, a small investment in layout design pays for itself many times over.
Three layouts are worth setting up at project outset. A submission layout, used for programme submissions under clause 31 and 32, configured to show exactly the information clause 31.2 requires: activity ID, description, duration, TRA, start, finish, calendar, responsibility code, constraint, and CE code. Grouped by WBS, sorted sensibly, filtered to show everything active. This layout produces a submission that visibly shows compliance with clause 31.2, removing the most common grounds for non-acceptance.
A project manager review layout, designed for quick review by the PM. Simplified columns, clear grouping, colour-coded by responsibility, focused on showing the narrative of the programme rather than every technical detail. This is the layout the contractor offers the PM when they ask how the programme works. It reduces the review burden and accelerates acceptance.
A compensation event layout, filtered to CE-affected activities, grouped by CE number, showing the logic relationships into and out of each CE. This is the layout the contractor uses when explaining a CE to the PM or QS, and the layout attached to CE quotation narratives. Having this prepared in advance turns CE quotation production from a per-event exercise into a templated process.
Saving these three layouts at the start of the project and using them consistently throughout signals planning maturity in a way that affects how the entire team is perceived.
What good P6 practice looks like on an NEC project
The planners who do this well do not use P6 any differently from other planners in a technical sense. They use the same features, the same scheduling engine, the same Gantt outputs. What differs is the discipline applied, the contract-awareness built into the structure, and the defensibility of the result.
At project outset, the WBS is designed around the contract as much as the construction. Activity codes are set up to reflect responsibility, compensation events, clause references and status. Separate calendars are defined for different working patterns. Time risk allowances are made visible through whichever method the project adopts. The first programme is built with complete logic, minimal unnecessary constraints, and explicit representation of client obligations, key dates and access dates.
At the moment of first acceptance, a baseline is saved and labelled. Submission, review and CE layouts are set up. A standard fragnet template is developed for compensation event work.
Through the project, revisions are issued at the cadence the contract data requires. Each revision uses consistent data date progression, progress captured correctly, baseline variance reported, and narrative prepared for the project manager. When compensation events occur, fragnets are built under the designated WBS node, linked properly into the schedule, and supported by layout-driven quotations.
None of this is unusual in a technical sense. All of it is unusual in practice, because most P6 schedulers have not been given contract-specific training to know what to do. For contractors without in-house planning resource at this level, specialist contractor planning support provides the discipline as a managed service, at a cost that is small relative to the commercial protection it provides.
Conclusion
Primavera P6 does not make a programme NEC-compliant. How the planner configures P6 and the discipline they apply to it determines whether the programme survives under the contract or fails at the moments that matter most.
NEC-compliant P6 practice is not difficult in the sense of requiring advanced technical knowledge. It requires contract-aware design choices: a WBS that surfaces contractual elements, activity codes that carry the commercial layer, calendars that reflect reality, logic that supports compensation event assessment, constraints that are justified rather than convenient, TRA that is visible, baselines that are preserved, fragnets that are structured consistently, and layouts that make the programme legible to the project manager.
The contractors who apply this discipline produce programmes that are accepted quickly, support compensation event assessment cleanly, and defend entitlement when tested. The contractors who do not produce programmes that look fine and fail under scrutiny, which is where most margin loss on NEC projects originates.
The discipline is not large. The commercial protection it provides is considerable. The difference between the two is invisible until a compensation event tests the programme. At that point, it is the only thing that matters.
FAQ
Is Primavera P6 required for NEC programmes?
No. NEC4 requires the programme to be in the form stated in the scope, and the scope may specify a particular software, but NEC itself does not mandate P6. Common alternatives on NEC projects include Microsoft Project, Asta Powerproject, and increasingly Synchro. P6 is the most widely used on major UK infrastructure projects because of its scale handling, database architecture, and interoperability. For smaller projects, Asta Powerproject is often preferred because of its simpler interface and lower cost. The choice of tool matters less than the discipline applied to using it.
What P6 settings matter most for NEC compliance?
The highest-impact settings are calendars (separate calendars for different working patterns), the scheduling option for critical path (Longest Path is usually preferred on NEC projects), the progress handling method (retained logic is generally correct), and constraint discipline (minimise to contractual dates only). Activity coding structure and WBS design matter more than individual settings because they determine how the schedule can be filtered and reported. These structural choices are made early in the project and affect everything that follows.
How detailed should activities be on an NEC P6 programme?
The level of detail should support compensation event assessment and progress tracking without creating excessive maintenance burden. Activity durations in the range of one to four weeks for typical construction work, shorter for critical interface activities, longer for long-lead procurement or design packages. The test is whether the programme can answer the question "if this activity is delayed, what is the effect?" for any activity selected at random. Too coarse and the answer cannot be produced with sufficient precision. Too fine and the schedule becomes impossible to maintain. Most experienced NEC planners work with 3,000 to 8,000 activities on typical major construction packages.
How should time risk allowance be shown in P6?
Three approaches are common: separate TRA activities after each risk-carrying activity, a user-defined field capturing TRA for each activity and shown in layouts, or TRA embedded within activity durations. The first two are NEC-compliant because they make the risk visible as clause 31.2 requires. The third is not reliably compliant and can be grounds for non-acceptance. Separate TRA activities are generally preferred on projects where risk allowance is significant and likely to be scrutinised. Field-based TRA is preferred on very large schedules where adding activity count is impractical.
How do you handle compensation events in P6?
The standard approach is to build a fragnet for each compensation event under a dedicated Compensation Events WBS node, identified by a consistent CE code that also populates an activity code field. The fragnet includes the compensation event itself, any new work the CE introduces, and the logic links from the CE into the affected activities in the main schedule. The schedule recalculates to show the time impact on planned completion automatically. The CE quotation narrative then explains something the schedule already demonstrates, rather than asserting an impact the schedule cannot support.
What is the Longest Path setting in P6 and why does it matter for NEC?
P6 offers two methods for identifying the critical path: Total Float equal to or less than zero, and Longest Path. The former identifies activities with zero or negative total float as critical. The latter identifies the longest chain of activities from project start to finish, regardless of float values. On NEC projects with sectional completions, significant terminal float, or multiple completion dates, Longest Path usually produces a more reliable critical path identification because it follows the actual time-driving sequence of work rather than just the activities with zero float. For compensation event assessment, Longest Path tends to produce cleaner time impact analysis.
How often should a P6 NEC programme be updated?
At minimum, at the frequency stated in the contract data under clause 32, which is typically four weeks. In practice, revisions should be issued whenever implemented compensation events need to be incorporated, whenever the sequence changes materially, or when progress significantly diverges from the previous forecast. Each revision should use a consistent data date progression, progress captured against the accepted baseline, and variance reporting to show what has changed. The article on NEC clause 31 programme acceptance covers the update discipline in detail.
Can you use a P6 NEC programme template?
Yes, and several commercial templates exist for NEC compatibility. The value of a template is in establishing the WBS structure, activity coding, calendars, and layouts as a starting point. The limitation is that a template cannot replace contract-specific judgement: no template will correctly identify which access dates, key dates, or employer obligations exist on a specific project. A template accelerates project setup but does not eliminate the need for contract-aware planning. Most commercial templates require significant adaptation for individual projects.
Need a P6 NEC programme reviewed or built to survive the contract?
If the current programme is not being accepted, compensation event quotations are being challenged on schedule grounds, or the structure of the P6 schedule is not supporting commercial claims, specialist NEC programme support brings contract-specific discipline to the P6 environment.
