Why Excel cannot run an NEC programme: the calculation problem nobody talks about

By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control

Founder, NEC Planning Solutions Ltd

A specialist subcontractor running a £4 million NEC4 mechanical package on a UK energy project submitted their first compensation event quotation in month three. The notification was timely. The supporting narrative was clear. The cost build-up was traceable. The time impact analysis showed a six-week delay to completion. The project manager rejected the quotation within a week. The reasons given were short: the impact cannot be assessed without a logic-linked programme, the proposed completion change cannot be verified against the accepted programme, and the contractor has not demonstrated the cause and effect pathway from the event to the impact on planned completion.

The subcontractor was confused. The programme had been maintained in Excel since project award. The Gantt chart looked professional, was updated weekly with progress percentages, and had been shared with the client at every progress meeting without complaint. The bid programme had been built in Excel. The accepted programme submission had been built in Excel. The progress reports had been built in Excel. Why was the project manager now telling them the programme could not support a compensation event assessment?

The answer is structural and it is the subject of this article. The subcontractor had not been running a worse planning tool; they had been running a fundamentally different kind of tool that lacked the property the contract was now requiring.

Excel is not a planning tool. It is a calculation tool with planning-shaped output. The distinction sounds technical. It is not. The difference is whether the software stores logic that recalculates when inputs change. NEC contracts are built on logic recalculation. Every compensation event assessment, every programme revision under clause 32, every delay analysis, every progress update requires the schedule to recalculate from new inputs. Excel does not do this. It cannot do this. It is the wrong category of tool for the contractual function it is being asked to perform.

This is the reframing that almost no commentary on Excel programmes on NEC projects gets to. The seven recurring pitfalls that contractors hit when using Excel as the master programme are not seven separate problems with seven separate fixes. They are seven symptoms of one structural mismatch between the tool and the contract. Understanding this changes the practical response from incremental Excel improvements to a recognition that the master programme has to live in a different kind of tool, and the Excel artefacts that exist on the project should be repositioned as registers and dashboards rather than as the master plan.

What follows is the structural analysis: why Excel cannot run an NEC programme, what the seven symptoms of the mismatch look like in practice, what the contract requires that Excel cannot provide, and what the practical migration path looks like for contractors who have inherited or accumulated an Excel-based planning regime that is no longer fit for the contract they are now administering.

What "logic-linked" actually means and why it matters

The term "logic-linked programme" appears in every NEC commentary and in the NEC contract guidance itself. It is one of the most under-explained terms in UK construction administration. Most contractors who have used scheduling tools understand it intuitively. Most contractors who have only used Excel programmes do not, because they have never operated a tool where the property is visible.

A logic-linked programme is a network of activities, each with a duration and each with one or more logical relationships to other activities in the network. The relationships are stored as part of the programme data, not as visual lines on a chart. When any input changes (a duration is extended, a constraint is moved, an activity is added, a progress update is applied), the software recalculates the dates of every dependent activity using the stored logic. The output is a new set of dates that reflects the new inputs through the logical relationships. This recalculation happens in milliseconds. It is the core function of a scheduling tool.

An Excel programme does not have this property. Excel stores dates as cell values. The user enters a start date and a finish date. If the user wants the dates to update when the user changes another date, the user has to write a formula linking the cells. If the user wants progress to affect downstream activities, the user has to write the formula. If the user wants a constraint to be enforced, the user has to write the formula. The logic is not built into the tool. It is built by the user, one cell at a time, and it exists only in the formulas the user has chosen to write.

This produces three structural consequences that cannot be engineered around.

The first is that Excel programmes do not recalculate consistently when inputs change. A change to one activity affects only the cells that the user has explicitly linked. Activities that should be affected through indirect logic but have not been explicitly linked will not change. The user discovers the gap when somebody asks why the downstream activities did not move, and the answer is that the formula was never written.

The second is that Excel programmes cannot model critical path. The critical path of a programme is calculated by the software through the logic network: forward pass to find the earliest finish, backward pass to find the latest finish, then identify the activities with zero total float. Excel cannot do this. The user can build a manual approximation by writing formulas, but the formulas only work for the specific network structure the user has built, and they break when activities are added, removed, or re-sequenced. The critical path in an Excel programme is what the user says it is, not what the software calculates.

The third is that Excel programmes cannot perform impact analysis. When a compensation event arises and the contractor needs to assess the impact on planned completion, a scheduling tool inserts a fragnet (the event's effect on the relevant activities) into the network and recalculates. The new completion date is the output. Excel cannot do this. The user has to manually identify which activities the event affects, manually adjust the dates of those activities, manually trace through the formulas to see which downstream activities also need to move, manually decide what the new completion date should be, and manually justify the decision when asked. The output is a contractor's view of the impact, not a calculated impact.

These three consequences are the core mismatch. NEC4 is structured around the assumption that the programme is a logic-linked network capable of consistent recalculation. The seven failure modes that contractors hit when using Excel are not seven separate problems. They are the same problem appearing in seven different operational contexts.

The article on Primavera P6 for NEC programmes covers the scheduling tool choices that produce genuine logic-linked programmes, and the article on how to structure a time impact assessment under NEC4 covers the impact analysis that depends on this capability.

What NEC4 actually requires the programme to demonstrate

NEC4 clause 31.2 sets out, item by item, what every programme submitted for acceptance must show. The list includes the starting date and access dates, the contractor's planned completion and the completion date, key dates, the order and timing of operations, time risk allowances, float, information needed from the project manager and others, the work of the employer and others, health and safety requirements, and other information stated in the contract data.

Most of these can be displayed in an Excel chart with sufficient ingenuity. The issue is not the display. The issue is whether the underlying data structure supports the contractual functions that the programme has to perform once it has been accepted.

Three contractual functions specifically depend on logic recalculation.

The first is compensation event assessment under clause 63.5. The contract requires the time impact of a compensation event to be assessed as the amount by which planned completion would be delayed, calculated against the accepted programme current at the dividing date. The assessment is not an opinion. It is a calculation. The contractor inserts the event into the schedule, the schedule recalculates, and the difference between the original planned completion and the impacted planned completion is the time impact. The assessment is verifiable by anybody with access to the same scheduling file. An Excel programme cannot perform this calculation. The contractor's assessment becomes a contractor's opinion, which the project manager may or may not accept under clause 64.

The second is programme revision under clause 32. The contract requires the contractor to submit revised programmes at the contract data interval, showing actual progress, any changes the contractor proposes, the effects of compensation events, and any other changes that affect the programme. The revision is not a re-draft. It is a recalculation: the new data date, the new actual progress, the new accepted changes are applied to the network, and the network recalculates to show the new forecast. An Excel programme cannot do this. Each revision requires the contractor to manually rebuild the programme around the new inputs, which produces a sequence of programmes that may or may not be consistent with each other depending on the rebuild discipline applied.

The third is the project manager's review under clause 31.3. The project manager assesses the programme against four grounds: practicability, required information, realism, and scope compliance. The article on what the project manager checks when reviewing your NEC programme covers the review sequence in detail. The realism test specifically depends on the project manager being able to trace through the logic of the programme to verify that the sequence is achievable. An Excel programme has no logic to trace through. The project manager has to take the contractor's word for the dates. The acceptance is therefore based on trust rather than verification, which is a procedurally weaker position for both parties.

These three contractual functions are not optional. They are how the NEC4 programme regime operates. A programme that cannot perform them is not a partially-functional programme; the tool choice has rendered it contractually incomplete. The contractor who has accepted a programme built in Excel has accepted a programme that the contract was not designed to administer.

The seven symptoms: how the structural mismatch shows up in practice

The seven failure modes that the original commentary on Excel programmes correctly identifies are the operational manifestations of the structural mismatch. Each symptom is real. Each fix attempted at the symptom level is genuinely useful but does not address the underlying cause. The symptoms recur because the underlying cause has not been addressed.

Symptom one: dates without dependencies. The Excel programme shows activities with start and finish dates but no logical relationships between them. The contractor cannot demonstrate cause and effect when challenged. This is the symptom that surfaces first because it is the most directly observable: a project manager asks "what drives this date?" and the answer is "what I typed in the cell," which is not an answer the contract can use.

Symptom two: spreadsheet version chaos. Multiple Excel files exist with different dates, different progress, different content. Working files diverge from issued files. The project does not have a single source of truth. This symptom is a consequence of the absence of a master file that the software maintains automatically. A scheduling tool stores the programme as a single project file with a version history. Excel programmes proliferate as users save copies, share copies, and forget which copy is current.

Symptom three: progress updates do not re-forecast the sequence. The contractor updates percentage complete in Excel but the remaining work does not re-sequence. Site runs a separate lookahead because the Excel programme is not trusted to show the genuine forecast. This symptom is the most operationally damaging. The programme that should be the project's master forecast becomes a record of historical progress that nobody uses for planning, and the actual planning happens informally outside the programme.

Symptom four: interfaces live in meeting notes. Access handovers, design release, permits, third-party approvals are tracked in correspondence rather than in the programme. The programme cannot show interface dependencies because the dependencies are not modelled in the tool. This symptom is particularly damaging on NEC projects because under clause 60.1(3), the project manager's failure to provide information by the date shown in the accepted programme is a compensation event. If the dates are not in the programme, the compensation event cannot be triggered. The article on the NEC4 compensation event time bar covers the procedural sequence in detail.

Symptom five: multiple changes become manual date shifting. Compensation events arrive. The contractor pushes dates in Excel. The register grows. Nobody can confidently state whether impacts overlap, are already implemented, or are being claimed twice. This symptom is the operational manifestation of the lack of automated recalculation. Each change requires manual judgement, and the judgement does not scale as the number of changes increases.

Symptom six: Excel creates presentation programmes. The Gantt chart looks professional but has no tested logic, no schedule health metrics, and no defensible critical path. The programme survives surface scrutiny and fails detailed scrutiny. This symptom is particularly common on tender programmes where the visual quality of the chart is mistaken for the planning quality of the underlying plan. The project manager who runs a proper review test at acceptance identifies the absence of underlying structure quickly.

Symptom seven: when the project turns noisy, Excel leaves the contractor exposed. Disputes arise. The contractor tries to prove delay or change with spreadsheets, screenshots, and chronologies. The evidence may demonstrate that disruption occurred, but it cannot demonstrate that the event drove planned completion. Time becomes an argument rather than an analysis. This is the symptom that hurts contractors most commercially, because it surfaces precisely when entitlement is at stake.

Each of these symptoms can be partially addressed within Excel by experienced users with strong discipline. None of them can be fully resolved within Excel, because the underlying tool lacks the property the contract requires. The symptoms recur. The discipline is exhausting to maintain. The cumulative cost across a multi-year project is significant.

Why contractors end up running Excel programmes despite knowing better

Most contractors using Excel as the master programme on NEC projects know that scheduling tools exist. They are not unaware. They have ended up running Excel programmes for one of three reasons that are worth naming explicitly because each has a different fix.

The first reason is cost perception. P6 licences run at several thousand pounds per user per year. MS Project is less expensive but still represents a meaningful commitment. Asta Powerproject sits in between. For a small contractor running a £4 million subcontract package, the licence cost feels significant relative to the project value. Excel is already paid for. The reasoning is real but it underestimates the commercial value of the contractual functions that scheduling tools enable. The licence cost is typically recovered many times over in a single compensation event that is properly assessed because the schedule can support the assessment.

The second reason is capability perception. Many contractors do not have an in-house planner who is comfortable with P6 or equivalent. The team uses Excel because Excel is what the team knows. The capability gap is real. The fix is either to invest in capability (training, hiring, or partnering with specialist support) or to accept that the project will be exposed on programme-driven contractual functions. The fix is not to continue using the tool the team knows for a function the tool cannot perform.

The third reason is inertia from prior projects. The contractor used Excel on previous projects without obvious failure. The team carries the same approach forward to the next project without examining whether the contractual context has changed. NEC4 is materially more demanding of programme infrastructure than the JCT contracts that many smaller contractors started on, and the difference often does not become visible until the first significant compensation event arises and the programme cannot support the assessment.

Each of these reasons is understandable. None of them addresses the underlying structural mismatch. The contractor who continues to run Excel on NEC4 projects because of cost, capability, or inertia is making a commercial decision that has consequences. The consequences may not be visible in the early months of the project. They surface when the project becomes contentious, which is the moment when programme infrastructure matters most.

For contractors who recognise the mismatch but do not yet have the internal capability to migrate, specialist contractor planning support provides the planning tool capability as a managed service, which gives the contractor the contractual functions a logic-linked programme provides without requiring the contractor to take on the licence cost or training investment internally.

Where Excel genuinely belongs

The argument above is that Excel cannot run an NEC master programme. The argument is not that Excel has no role on an NEC project. The opposite is true. Excel is excellent at the tasks it was designed for, and the contractor who positions Excel correctly within the project's control infrastructure gets significant value from the tool.

Excel is the right tool for registers. The early warning register, the interface register, the compensation event register, the change register, the risk register, the assumptions log: all of these are tabular data with attributes that lend themselves to Excel's strengths. The data is queryable, filterable, sortable, and amenable to pivoting and analysis. The article on NEC clause 15 early warning register covers the register discipline that Excel supports well.

It is also the right tool for dashboards and reporting. Performance indicators, KPI tracking, S-curves, resource histograms, cost-loaded schedules, cash flow projections: all of these are derived calculations from underlying project data. Excel performs these calculations efficiently and produces visual outputs appropriate for project communication. The output of a scheduling tool can be exported to Excel for dashboard production, which gives the project the benefit of the scheduling tool's logic recalculation and the benefit of Excel's reporting flexibility.

For ad-hoc analysis, nothing else matches it. Quick what-if calculations, sensitivity analyses, comparison tables, scenario summaries: all of these are situations where the user wants to enter values, see the output, and not commit to a structured model. Excel is fast, flexible, and accessible for this kind of work, and there is no value in trying to do it in a scheduling tool.

What Excel is not is the right tool for the master programme. The master programme is the project's logical model of how the works will be delivered, with the logic stored in the tool and the recalculation happening automatically. This belongs in a scheduling tool. Excel can read from the scheduling tool, can present data derived from it, can support registers that complement it, but cannot be the master programme without producing the seven symptoms covered earlier.

This positioning is not difficult to operate. Many strong contractor planning regimes look exactly like this: P6 or Asta Powerproject as the master programme, Excel for everything else, with clear protocols for how data moves between them. The result is a control regime that is operationally efficient and contractually defensible.

The migration path for contractors currently running Excel programmes

For contractors who have been running Excel programmes and recognise the case for migration, the practical transition has a recognisable shape. It does not have to happen all at once. The strongest migrations are staged.

The first stage is the master programme migration. The current Excel programme is rebuilt in a scheduling tool, with the logic explicitly modelled, the WBS designed for the project's needs (not for the tender), and the activity coding aligned to how compensation events and reporting will be done. This is the most consequential single step. It typically takes two to four weeks for a competent planner to complete on a medium-complexity project. Once the master programme exists in the scheduling tool, the project has the contractual functions that the programme regime requires.

The second stage is the integration of registers and reporting. Excel continues to be used for registers (early warning, interfaces, changes, assumptions) and for reporting, but the registers reference programme activity IDs and the reports are populated with data exported from the scheduling tool. The connection between Excel and the scheduling tool is one-directional: data flows out of the scheduling tool to Excel for analysis and reporting, but the master logic stays in the scheduling tool.

The third stage is the disciplined update cycle. The programme is updated on a fixed data date, using documented progress measurement rules. Each revision is issued formally under clause 13 of the contract. The revisions feed the next reporting cycle. The Excel artefacts are refreshed from the new scheduling data. The cycle becomes routine.

The fourth stage is the integration of compensation event assessment. New compensation events are assessed against the current accepted programme using the scheduling tool's impact analysis capability. Quotations are built with the time impact element traceable to the schedule. Excel continues to support the cost build-up and the evidence index, but the time impact element is produced from the scheduling tool. The article on how to structure a time impact assessment under NEC4 covers the structural elements of properly-built quotations.

These four stages typically span two to three months for a project where the migration is approached deliberately. Done well, the contractor emerges with a control regime that supports every contractual function the contract requires, and the team has the operational confidence that comes from running tools that are designed for the work they are doing.

The decision contractors actually face

The question is not whether Excel is a good tool. It is excellent at the things it was designed for: registers, dashboards, ad-hoc analysis. The question is whether Excel is the right category of tool for the function the contract is asking it to perform when it is positioned as the master programme. The answer is no, and the reasoning is not aesthetic or preferential. It is structural. Excel is a calculation tool with planning-shaped output. NEC contracts are built on logic recalculation. The two are different categories of software, and the contract was designed for the second.

The seven recurring pitfalls that contractors hit when using Excel as the master programme on NEC jobs are the operational evidence of this structural mismatch. Programmes that cannot demonstrate cause and effect. Version chaos that breaks the single source of truth. Progress updates that do not re-forecast the sequence. Interfaces that live outside the programme. Change impacts that cannot be properly modelled. Presentation programmes that fail under scrutiny. Exposure when the project turns noisy and entitlement is at stake. Each symptom can be partially addressed within Excel by experienced users with strong discipline. None can be fully resolved within Excel, because the tool lacks the property the contract requires.

The contract requires three specific functions from the programme: compensation event assessment under clause 63.5, programme revision under clause 32, and project manager review under clause 31.3. Each depends on logic recalculation. The contractor running an Excel master programme on an NEC project is not running a worse version of a planning tool. They are running a tool that lacks the property the contract requires, and the symptoms recur regardless of how disciplined the operation is.

The decision the contractor actually faces is therefore not "how do we improve our Excel discipline." It is: do we keep running the master programme on a tool that cannot perform the contractual functions the project will require, or do we migrate to a tool that can. The migration is straightforward. It typically takes two to four weeks for the initial master programme rebuild and another six to eight weeks to integrate registers, reporting, and compensation event assessment. The cost is modest. The benefit applies to every subsequent compensation event, every programme revision, every progress update, and every dispute through the remaining duration of the project.

Contractors who recognise the structural mismatch and migrate find that the planning function becomes operationally efficient and contractually defensible. Contractors who continue to run Excel as the master programme find that the seven symptoms recur, the operational cost compounds, and the commercial exposure becomes visible at the moment of greatest stress, which is when the project turns contentious and the programme is asked to do work it cannot do. The decision is not difficult to make once the question has been framed correctly. The question is just usually framed incorrectly.

FAQ

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 BEng 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.

Discuss your project | LinkedIn | About NEC Planning Solutions

Running an NEC project on an Excel programme and feeling the limitations?

If compensation events cannot be properly assessed, if the project manager has stopped trusting the programme, or if the planning function is exhausting itself maintaining an Excel master that the contract was not designed to administer, specialist NEC programme support migrates the programme to the right tool and restores the controls infrastructure.