# SOMA Project Controls — full content dump for LLMs > Canonical URL: https://www.somaprojectcontrols.com > Registered: SOMA PROJECT CONTROLS LTD · Companies House 16001237 · VAT GB485592149 > Lead capability: Quantitative Risk Analysis (QRA) to AACE standards > Sectors: rail, highways, nuclear, water, defence, energy, industrial, public sector This file concatenates every service, guide, case study, glossary entry, training course, and policy on somaprojectcontrols.com into a single UTF-8 text file so LLM crawlers can ingest the site in one request. The canonical structured data is the website itself; this file is a courtesy for machine consumption. --- # Tools Purpose-built desktop software for UK project controls practitioners. Local-first by design — no cloud, no telemetry, no third-party data processing. Built by practitioners, calibrated on live UK infrastructure programmes. ## SOMA QSRA Validator URL: https://www.somaprojectcontrols.com/tools/qsra-validator Status: Shipping (V0.15.6) Platform: macOS (.app, code-signed) · Windows (Inno Setup, per-user install) Positioning: Schedule-risk readiness, before the Monte Carlo runs. Desktop input validator for Quantitative Schedule Risk Analysis. Catches the schedule and risk-register issues that would otherwise compromise a QSRA — before the simulation runs, not after the P80 looks wrong. Runs locally at localhost:8000; data never leaves the machine. ### Four validators, one tool - Schedule Check — DCMA 14-point, CIOB PP21, Acumen Fuse SQI, or the flagship SOMA QSRA Readiness framework. Upload a Primavera P6 XER, pick the framework, get a RAG-banded scorecard with failing-activity IDs traceable to source rows. - Risk Register Validator — any risk register in Excel (.xlsx): Riskhive, Xactium, ActiveRisk, Predict!, or a plain SOMA-consolidated workbook all work, as long as the required input fields are present. Runs the RR-* rule set: mandatory fields, three-point-estimate sanity, probability bounds, distribution types. - Risk-to-Activity Mapping Validator — cross-checks every risk against the XER: orphan risks, missing split-impact weights, activities flagged as non-schedule. - Full Validation — XER plus risk register in one upload, all three checks running in parallel, one consolidated report at the end. ### SOMA QSRA Readiness framework 25 checks across 5 weighted domains (weights sum to 100): - A · Logic Integrity (25) — missing logic, dangling ends, relationship-type mix, merge hotspots, logic density, relationship direction (6 checks) - B · Duration Health (20) — high-duration activities, zero-duration non-milestones, distribution, invalid dates, date consistency (5 checks) - C · Constraints & Calendars (15) — constraint coverage, calendar assignments, milestone integrity (3 checks) - D · Float & Critical Path (20) — critical-path length, negative float, high float, float distribution, ERMHDR integrity (5 checks) - E · QSRA Readiness (20) — the SOMA differentiator: in-scope definition, lag hygiene, status consistency, data-date alignment, activity-ID uniqueness, WBS depth, LOE discipline, TRA / TBP hygiene, procurement-lag exemption (6 checks) Banding: 85+ GREEN, 70–85 AMBER, below 70 RED. ### Why it exists DCMA 14-point (2005) is a US DoD contract-auditing checklist — tests activity-level quality but has no concept of risk-load readiness. CIOB PP21 blends schedule quality with process maturity. Acumen Fuse SQI is closed-source and calibrated to Deltek's defaults, treating every schedule as if it were a QSRA-ready baseline. None of them distinguish between a schedule that is structurally sound and one that is prepared for probabilistic analysis. SOMA QSRA Readiness closes that gap. The methodology was calibrated on 40+ production QSRAs across National Highways, Network Rail, and nuclear AGR programmes — not ported from a generic IMS template. ### Outputs - RAG-banded scorecard (GREEN / AMBER / RED), 0–100 numeric score, per-domain score - SOMA-branded Excel report (scorecard, full detail sheets, methodology sign-off) - RFC-5322 .eml email — three-section RAG-grouped summary for the planner - Safran-ready flat-file exports (Iteration Data + Percentiles) - Per-activity findings with severity chips (Blocker / Warning / Info) traceable to source rows in the XER - Signed methodology document (V2.3) stamped into every output ### Deployment Local-only, single-user install. Mac .app bundle or Windows per-user installer (no admin rights). Multi-tenant within a single install — supports multiple clients and schemes. Period snapshots track a scheme's validation score period-over-period. --- ## SOMA QCRA URL: https://www.somaprojectcontrols.com/tools (contact SOMA for access) Status: Available on request Platform: Excel (.xlam add-in) — Windows and Mac Positioning: Quantitative Cost Risk Analysis, inside the estimator's workbook. Excel add-in that runs Monte Carlo directly over a live cost estimate. Three-point distributions, correlation, P-value reporting, tornado charts, SOMA-branded report. Built as an add-in because cost inputs already live in estimators' workbooks — no round-tripping, no data exports, no separate modelling tool to learn. --- ## SOMA QSRA Modelling URL: https://www.somaprojectcontrols.com/tools (register interest) Status: In development — roadmap Platform: macOS and Windows (desktop) Positioning: An internal Monte Carlo engine, purpose-built for QSRA. Closes the loop so clients do not need Safran Risk for in-house work. Planned capabilities: S-curves (cost and schedule, pre- and post-mitigation); P10 / P50 / P80 / P90 reporting; tornado and sensitivity analysis; risk contribution tables; narrative report generation; correlation-matrix support. Uses SOMA QSRA Validator as the input-clearance step, then runs the simulation end-to-end without a Safran round-trip. --- # Services ## Quantitative Risk Analysis URL: https://www.somaprojectcontrols.com/services/quantitative-risk-analysis Short name: QRA Positioning: Monte Carlo that tells the truth. Schedule and cost risk analysis built to AACE standards, delivered in plain English. We run QSRA, QCRA and integrated QCSRA on live UK programmes — and write the report so the decision-maker can actually act on it. ### What good looks like - A calibrated view of P50, P80 and P95 confidence on schedule and cost. - Risks identified, quantified and traceable back to workshop input. - Correlation and merge bias handled properly — not ignored. - A QRA report that says what it means, with recommendations the programme can own. ### What you get - Risk workshop facilitation and register build - Three-point estimate calibration - Monte Carlo model in @Risk, Primavera Risk Analysis, Safran or Acumen - Correlation and path-convergence analysis - P50/P80/P95 confidence curves - QRA report, board-grade --- ## Project Planning & Scheduling URL: https://www.somaprojectcontrols.com/services/planning-scheduling Short name: Scheduling Positioning: Schedules that reflect reality, not wishful thinking. Primavera P6 and MS Project schedules built from the WBS up. DCMA 14-point health, logic that holds under scrutiny, float you can defend. We set them up, run them through delivery, and read them for risk. ### What good looks like - A logic-linked, resource-loaded schedule ready for baseline. - Float properly protected, not eroded by default calendars. - Near-critical paths visible — not just the headline critical path. - Monthly progress and variance reporting the PMO can use. ### What you get - Schedule build in P6 or MS Project - DCMA 14-point assessment - Baseline and rebaseline support - Progress updating and variance reporting - Change-control assessment against baseline - Schedule risk read-across to QRA --- ## Cost Management & Assurance URL: https://www.somaprojectcontrols.com/services/cost-management Short name: Cost Positioning: Budgets kept honest. Forecasts that hold. Cost baseline, estimate assurance, earned value, forecast-at-completion. Tied back to the schedule properly, not run as a parallel spreadsheet that contradicts it. ### What good looks like - A defensible cost baseline tied to the schedule. - Earned Value running on a monthly cadence, reporting SPI and CPI cleanly. - EAC and VAC that stakeholders can stand behind. - Contingency drawdown tracked against trigger events, not vibes. ### What you get - Cost baseline build - Estimate assurance review - Earned Value implementation (PMB, BCWS, BCWP, ACWP) - Forecast-at-completion modelling - Contingency and management reserve governance - Monthly cost report --- ## Risk Operations & Advisory URL: https://www.somaprojectcontrols.com/services/risk-operations Short name: Risk Ops Positioning: Risk management that runs, not risk registers that rot. Ongoing risk operations — register maintenance, owner discipline, workshop facilitation, monthly reporting, integration with QRA outputs. The boring bit that most programmes skip, done properly. ### What good looks like - A live register that reflects current programme reality. - Named risk owners with active mitigation plans. - Risk reporting tied to QRA confidence figures. - Exposure trending over time, not a static snapshot. ### What you get - Risk register build or takeover - Monthly risk workshops - Owner coaching and discipline - Risk report integrated with QRA - Exposure trending and pre-read for steering groups --- ## Integrated PMO URL: https://www.somaprojectcontrols.com/services/integrated-pmo Short name: Integrated PMO Positioning: One controls function, not four competing spreadsheets. A full project controls function delivered as an integrated team — schedule, cost, risk, reporting — aligned to a single data model. Embedded with the client's delivery team. ### What good looks like - A single source of truth across schedule, cost and risk. - Reporting that tells the programme's story, not just shows its numbers. - Fewer controls meetings, better controls decisions. - A PMO that grows with the programme. ### What you get - Data-model design - Embedded controls team - Integrated reporting pack - Power BI / Acumen Fuse dashboards - Governance and cadence design --- ## Early Project Optimisation URL: https://www.somaprojectcontrols.com/services/early-project-optimisation Short name: EPO Positioning: Get the foundations right, before execution locks them in. Specialist project controls and risk embedded during feasibility and FEED, so the estimate, risk register and breakdown structure are built right the first time — not inherited and patched once execution starts. ### What good looks like - Cost and schedule baselines that hold through sanction and into execution. - A faster, cleaner transition into delivery — no three- to six-month controls setup lag. - Tighter contingency based on real analysis, not guesswork. - QRA-ready data from day one, cutting weeks off downstream risk analysis. - Lessons learned captured live and fed back into the organisation's knowledge base. ### What you get - Interim project controls team — scope, cost, schedule, risk, change and reporting, embedded from feasibility through to FID and stepping aside cleanly at execution handover - Estimate validation and breakdown design — independent estimate review to AACE and APM standards, with WBS, CBS and Control Account Plan built to survive into execution - Tool and system setup — Primavera P6, Safran, ARM, EcoSys, @Risk configured once, properly, so data flows cleanly between cost, schedule and risk from day one - Lessons learned and benchmarking — structured capture and benchmarking against comparable projects, built into a client-specific knowledge base - Commercial flexibility — fixed-price packages (£25k–£120k), day-rate embedded team (£60k–£500k over 3–12 months), or outcome-aligned against a sanction milestone --- ## Process & Template Development URL: https://www.somaprojectcontrols.com/services/process-templates Short name: Process & Templates Positioning: Permanent controls infrastructure. Not rented capability. The manuals, SOPs, templates and governance framework that let a client organisation run project controls consistently across every programme, not just the ones we are embedded on. We write the standards, build the templates, and train the people who will own them. ### What good looks like - A controls manual people actually read — proportionate, practical, written to be used. - Templates that enforce consistency across programmes without stifling judgement. - Assurance checklists a reviewer can apply in an afternoon, not a week. - A governance framework tied to decision rights, not just reporting rhythms. - Internal ownership — the standards are yours, not ours. ### What you get - Project controls manual (schedule, cost, risk, change, reporting) - Document suite — WBS, schedule, risk register, cost breakdown and monthly report templates - Assurance checklists for schedule, QRA and cost submissions - Governance framework and decision-rights matrix - Roll-out plan and training brief for internal adopters - Editable master files handed over on completion --- ## Project Controls Advisory URL: https://www.somaprojectcontrols.com/services/advisory Short name: Advisory Positioning: The outside view, when the programme needs one. Independent reviews, expert-witness-grade analysis, delay analysis (as-planned vs as-built, Time Impact), second opinions on controls set-up, maturity assessments. ### What good looks like - An independent read on whether the controls are fit for purpose. - Defensible delay analysis for commercial or contractual use. - A maturity assessment with a ranked improvement plan. - Quiet, calibrated advice when the programme can't afford more noise. ### What you get - Independent project controls review - Delay analysis (SCL Protocol-aligned) - Maturity assessment - Expert-report support - Second opinion on controls strategy --- # Practitioner guides ## The Honest Guide to QRA URL: https://www.somaprojectcontrols.com/resources/guides/honest-guide-to-qra Subtitle: What Quantitative Risk Analysis actually is, when you need it, how it works, and how to tell a good one from a bad one. Published: 2026-04-16 · 10 min read ### What QRA actually is (and isn't) Quantitative Risk Analysis — QRA — is the process of putting numbers on uncertainty. Not traffic-light numbers. Not "high / medium / low" numbers. Actual probability distributions showing the range of plausible cost or schedule outcomes and the likelihood of achieving each one. The output of a QRA is not a single figure. It is a curve — an S-curve — showing, for example, that a programme has a 50% chance of completing within £120m, a 70% chance of completing within £135m, and a 90% chance of completing within £158m. That spread is the point. The spread tells you what decisions are actually available to you. QRA is not the same as a risk register, though it draws on one. A risk register lists risks and gives them qualitative or semi-quantitative scores. QRA takes those risks — and crucially, the underlying uncertainty in your estimates — and models how they interact to produce a range of outcomes. The two tools are complementary, not interchangeable. QRA is also not a guarantee. A P80 cost figure does not mean "the project will cost that much." It means that, given the risks and uncertainties modelled, there is an 80% probability that the final cost will be at or below that figure. Whether the model is a faithful representation of reality depends entirely on the quality of the inputs. Garbage in, garbage out is a cliché precisely because it is true. ### When you need one Not every project needs a full QRA. A small, well-defined internal project with a fixed-price contract and limited scope variability probably does not. The overhead of building and running a meaningful model would outweigh the insight it produces. You need a QRA when decisions are being made that depend on a defensible confidence range. The most common triggers are: setting a contingency or risk provision for a funding submission; advising a board or client on the difference between a P50 and P80 cost or date; satisfying a gateway review requirement (HM Treasury Green Book guidance requires quantified risk assessment for major public-sector projects, and the UK MoD CADMID lifecycle places explicit QRA expectations at Concept and Assessment phases); or understanding which risks are actually driving variability on a complex programme. On UK infrastructure and construction programmes, quantitative schedule thinking is effectively contractual under NEC4 ECC Clauses 31 and 32 — the Accepted Programme has to show time risk allowances and float, which is the closest the standard form comes to mandating QRA. Beyond that, QRA adoption on major UK programmes is driven by HM Treasury Green Book expectations for risk and optimism-bias adjustment on high-cost / high-risk proposals, by IPA Cost Estimating Guidance which requires the P50 central estimate at every stage gate, and by sector-specific assurance practice on rail, highways, nuclear and defence programmes. Even where it is not strictly required, a well-run QRA is one of the most useful things you can do at RIBA Stage 2 or 3, when the project is still shapeable and the cost and schedule uncertainty is at its highest. AACE International's guidance (specifically the Total Cost Management Framework, the Professional Guidance Document PGD-02 Guide to Quantitative Risk Analysis, and Recommended Practices 57R-09, 113R-20 and 123R-22 on integrated cost-schedule risk analysis) and the APM's Body of Knowledge both treat QRA as a core competence for projects above a meaningful scale. The decision threshold is not a hard number — it is whether the technical and schedule uncertainty on the programme is material enough that a single deterministic estimate would mislead the decision-maker. On most UK infrastructure and defence programmes above a few million pounds with genuine scope or interface complexity, the answer is yes. ### What goes into a good QRA A QRA model has three main inputs: the base estimate, the schedule, and the risk register. Each needs to be in reasonable shape before you start — a QRA cannot rescue a fundamentally flawed estimate or a schedule that has never been properly resourced. It can, however, reveal the fragility of both. The base estimate should be your best deterministic forecast — what you expect to spend if things go broadly to plan. It should not include contingency, because the QRA is what generates the contingency. Cost engineers sometimes bake contingency into line items "just in case," which means the QRA model double-counts risk and produces inflated confidence levels. Strip the buried contingency out before you run the model. The schedule needs to be logic-linked, resource-loaded where possible, and free of artificial constraints. A schedule with hundreds of hard constraints — dates imposed by the tool rather than by genuine dependencies — will not respond realistically to risk-driven delays. You are modelling what actually drives the project, not what makes the programme look tidy on a bar chart. The risk register needs three-point estimates: optimistic, most likely, and pessimistic values for both cost and schedule impact, plus a probability of occurrence. This is where most QRAs fall down. Teams either use the same three-point range for every risk (because they do not know the answers) or they produce ranges so narrow that the model adds almost no variability. Getting credible three-point estimates requires workshops, challenge, and someone in the room who has done a similar project before. It is time-consuming. It is also the entire point. Good QRA models also capture inherent estimating uncertainty — not just discrete risks, but the base variability in your cost estimates and durations. A concrete pour that is estimated at 20 weeks does not have a 100% chance of taking exactly 20 weeks. Applying uncertainty ranges to base estimate line items, separate from the risk register, is standard practice in cost risk analysis and is recommended by both AACE and HM Treasury Green Book guidance. ### The modelling process (Monte Carlo explained plainly) The engine inside almost every QRA tool is Monte Carlo simulation. It sounds technical. The concept is not. The model takes every uncertain input — each cost line with its three-point range, each risk with its probability and impact range, each duration with its variability — and runs the project thousands of times, each time picking a random value for each input consistent with its probability distribution. Run it 10,000 times and you get 10,000 possible project outcomes. Plot those outcomes and you get a distribution. That distribution is your S-curve. In practice, the software handles the iteration. Analysts use tools like Safran Risk, Oracle Primavera Risk Analysis (formerly Pertmaster), @Risk for Excel, or Acumen Risk. Each has strengths: Safran and Primavera Risk Analysis work directly with schedule logic and handle integrated cost-schedule risk well; @Risk is more flexible for cost-only models built in Excel. The choice of tool matters less than the quality of the inputs. One thing Monte Carlo does not do automatically is handle correlation. If the civils package is late, the mechanical and electrical package is also likely to be late — they share the same ground conditions, the same weather risk, the same key subcontractor. Ignoring correlation between risks and activities produces a model that underestimates overall variability, because it assumes the unlucky scenarios on one activity are balanced by lucky scenarios on another. Building in realistic correlation coefficients is one mark of a well-constructed model. The number of iterations matters less than people think. For most project models, 5,000 to 10,000 iterations is sufficient. Running 100,000 iterations does not make the model more accurate — it makes it take longer. The accuracy is in the inputs, not the iteration count. ### Reading the outputs: S-curves, tornado charts, and confidence levels The S-curve is the primary output. The horizontal axis shows cost (or completion date); the vertical axis shows cumulative probability. The point where the curve crosses 50% on the vertical axis is the P50 — the median outcome. The P80 is where it crosses 80%. The shape of the curve tells you as much as the numbers: a shallow, spread-out S-curve means high uncertainty; a steep, narrow one means the model has relatively tight constraints on the outcome. On cost models, you will typically see a deterministic estimate marked on the S-curve. If the deterministic estimate sits above the P80, that is a signal — your base estimate may already be optimistic, or the risks are substantial. If it sits near the P50, you have roughly symmetric uncertainty. If it is above the P90, you should be asking serious questions about the estimate basis. Tornado charts show which risks and uncertainties are driving the most variability in the outcome. They rank inputs by their contribution to the spread of results — the longer the bar, the more impact that item has. Tornado charts are where QRA becomes genuinely useful for project management, because they tell you where to focus. If three risks account for 60% of the variance, those are the three you need to be actively managing, monitoring, and reporting on. Sensitivity analysis — related to but distinct from tornado charts — shows how the P80 (or whatever confidence level you care about) changes as individual inputs change. It answers the question: if we could eliminate that risk entirely, how much would it change our cost confidence? This is useful for prioritising mitigation investment. Confidence levels are the other key output. P50, P80, and P95 are the most commonly reported. HM Treasury guidance uses P80 as the basis for Optimism Bias and contingency calculations for major public-sector projects. Commercial clients often want to see P50 as a central estimate and P80 as a "should-cost" funding ceiling. There is no universal rule for which confidence level to use — it depends on the organisation's risk appetite, the project's strategic importance, and the consequences of underfunding. ### Common mistakes we see on real programmes The most common mistake is running the QRA once, at a single point in time, for a gateway submission, and then never looking at it again. QRA is most valuable as a live tool — updated as risks mature, new risks emerge, and the estimate evolves. A static QRA produced at RIBA Stage 2 and never revisited is of limited use by the time the project reaches Stage 4. The second most common mistake is allowing the QRA to be run by someone who has a stake in the outcome. If the delivery team are also running the risk model, there is an incentive — conscious or not — to narrow the ranges, reduce the probabilities, and produce a P80 that comes in under budget. Independent peer review of QRA assumptions, or independent QRA modelling, is standard practice on major programmes for precisely this reason. Poorly calibrated three-point estimates are endemic. Most people, when asked for a "pessimistic" estimate, give a figure that is perhaps 20-30% above their most likely — when genuine project experience suggests that tail risks can be two or three times the base estimate on complex packages. P-value miscalibration is a known cognitive bias and a well-documented problem in project risk. Some organisations address this through structured elicitation techniques or by anchoring estimates to historical data on similar projects. Treating risks and estimating uncertainty as separate things is another structural problem. Cost risk analysis should model both: the inherent variability in how well you can estimate a scope item, and the discrete risk events that might change the scope itself. Conflating the two — or modelling only one — will misrepresent the true uncertainty. Finally, burying contingency in the base estimate before running the model is particularly destructive because it is invisible. If a cost manager has padded each line item with 10% "just in case," the QRA model produces a P50 that is already 10% above the genuine expected cost. The contingency appears to come from the model when it was actually in the estimate all along. Always audit the base estimate for embedded contingency before running QRA. ### When to push back on a bad QRA If someone hands you a QRA report, you should scrutinise it — especially if it is being used to justify a funding level or a go/no-go decision. Here are the things worth checking. Does the S-curve look plausible? A P80-to-P50 ratio of less than 10% on a complex project is a red flag. Real projects have more uncertainty than that. If the spread is very narrow, ask what assumptions produced it — you will usually find either narrow three-point ranges, very low risk probabilities, or embedded contingency in the base estimate. Are the top risks in the tornado chart actually the risks you would expect to drive variability? If ground conditions are a known uncertainty and they do not appear in the top ten, ask why. If the biggest driver is something trivial, the modeller may have missed the substantive risks. Has the model been run by someone independent of the delivery team? If not, ask whether assumptions have been peer-reviewed. Does the model include correlation? Most credible QRA tools support correlation. If a large model has been run without any correlation between related risks and activities, the spread of the S-curve will be artificially compressed. Is the QRA date consistent with the current project state? A QRA based on a schedule that was superseded six months ago is not telling you about the project you are on now. Check the model date and the schedule revision it references. A well-done QRA from a competent analyst who understands the project and has credible input data is one of the most valuable tools in project controls. A poorly-done QRA that produces a comfortable-looking number to pass a gateway is actively harmful — it gives false confidence to decision-makers who deserve honest information. If you are not sure which kind you are looking at, the questions above will usually tell you. ### Frequently asked questions **What is Quantitative Risk Analysis (QRA)?** Quantitative Risk Analysis is the process of using Monte Carlo simulation to model cost and schedule uncertainty on a project, producing a probability distribution of outcomes rather than a single deterministic estimate. The output is an S-curve showing the likelihood of completing within different cost or duration values (typically reported as P50, P80 and P95 confidence levels). QRA draws on the project risk register, three-point estimates on activities and costs, and assumed correlations between risks — and produces a defensible contingency figure that can be used in funding submissions, board approvals, and gateway reviews. **What is the difference between a risk register and a QRA?** A risk register is a list of identified risks with qualitative or semi-quantitative scores (probability and impact bands, traffic lights). A QRA is a Monte Carlo simulation that takes those risks — along with the inherent uncertainty in your cost and schedule estimates — and models how they interact across thousands of iterations to produce a probability distribution of project outcomes. The risk register is an input to the QRA. The QRA is the quantitative output. You need both: the register for management and mitigation; the QRA for funding decisions and confidence-level reporting. **When does a project need a QRA?** QRA is required when decisions are being made that depend on a defensible confidence range. The most common triggers are: setting contingency for a funding submission, advising a board on P50 vs P80 cost or schedule, satisfying HM Treasury Green Book expectations for risk and optimism-bias adjustment on high-cost / high-risk proposals, meeting the IPA Cost Estimating Guidance requirement for a P50 central estimate at every stage gate, MoD CADMID Concept and Assessment-phase business cases where Confidence Figures are presented to the IAB at Initial Gate and Main Gate, and understanding which risks actually drive variability on a complex programme. In practice, NEC4 ECC Clauses 31 and 32 (the Accepted Programme requirements for time risk allowances and float) make quantitative schedule thinking effectively contractual on any non-trivial NEC4 programme, regardless of project size. **What is the difference between QSRA and QCRA?** QSRA is Quantitative Schedule Risk Analysis — Monte Carlo simulation on the project schedule to produce a probability distribution of completion dates. QCRA is Quantitative Cost Risk Analysis — Monte Carlo simulation on the project cost estimate to produce a probability distribution of final cost outcomes. Many programmes need both, run jointly as Integrated Cost-Schedule Risk Analysis so that schedule risks correctly drive their cost consequences (delay-related costs, preliminaries, escalation). **What software is used for QRA in the UK?** The most common QRA tools on UK infrastructure and defence programmes are Palisade @Risk (cost-focused, runs on Excel), Safran Risk (schedule-focused, integrates with Primavera P6), Acumen Risk by Deltek (schedule and cost), and Primavera Risk Analysis (formerly Pertmaster, still used on some legacy programmes). Tool choice is less important than calibration and discipline — a well-run @Risk model produces better results than a poorly-run Safran model. The methodology reference standards are AACE International's Professional Guidance Document PGD-02 (Guide to Quantitative Risk Analysis) and Recommended Practices 57R-09, 113R-20 and 123R-22 — three integrated cost-schedule risk analysis methodologies, each suited to a different evidence and modelling context. **How do you know if a QRA is any good?** A defensible QRA has six properties: the risk register has been built from delivery experience rather than copy-pasted from a template; three-point estimates have been calibrated against benchmark data rather than guessed in the workshop; correlation between risks is modelled explicitly (zero correlation is almost always wrong); the output distribution is asymmetric (right-skewed) rather than narrow and symmetric; the model has been peer-reviewed by someone independent of the team that built it; and the date the QRA was run is recent enough that the underlying scope and schedule are still valid. If any of these are missing, the QRA is producing a number rather than a confidence position. --- ## Why Your S-Curve Is Lying to You URL: https://www.somaprojectcontrols.com/resources/guides/why-your-s-curve-is-lying Subtitle: S-curves are the most widely used reporting tool in project controls — and one of the most routinely misleading. Here is what goes wrong and how to fix it. Published: 2026-04-16 · 9 min read ### What an S-curve is supposed to tell you An S-curve plots cumulative value against time. In a project controls context, "value" is usually one of three things: planned spend (the budget spread over time), actual spend (what has been committed or invoiced), or earned value (the budgeted cost of work actually completed). Sometimes all three are plotted on the same chart. The shape is characteristically S-shaped because projects typically start slowly — mobilisation, early design, procurement — then ramp up steeply through peak delivery, then taper off as work closes out. Plotting that pattern gives you the curve. Used well, an S-curve is a compact, readable summary of project financial progress. At a glance, a client, sponsor, or senior manager can see whether spend is tracking the plan, whether the project is behind or ahead, and how much of the budget has been consumed relative to how much work has been done. It is one of the oldest and most durable tools in project reporting — which is exactly why its failure modes are so well-worn and so frequently ignored. ### The five ways S-curves mislead Understanding why an S-curve can mislead requires looking at each failure mode in turn. They rarely appear alone — on a struggling programme, you will often find several at once. ### 1. The baseline was never realistic An S-curve is only as useful as the baseline it is measured against. If the original baseline was built on an optimistic estimate, an unrealistic programme, or assumptions that were outdated within weeks of issue, then the curve is measuring progress against a fiction. This is more common than it should be. Cost plans are often issued under commercial or political pressure to meet a target number rather than reflect a genuine forecast. Schedules are produced to satisfy a gateway requirement rather than to model how the work will actually be sequenced and resourced. When the project starts spending — or not spending — along its actual trajectory, the S-curve shows a divergence that looks like underperformance but is really just the gap between optimism and reality. The tell is that the actual spend curve hugs the bottom of the planned spend curve from day one. There is never a period where the project is tracking well. The divergence is there in month one and it only grows. That is not a delivery problem — that is a baseline problem. And no amount of project controls reporting will close the gap until someone recasts the baseline to reflect what is actually achievable. ### 2. The baseline has never been rebaselined Closely related, but distinct: the baseline was plausible when it was set, but the project has since changed substantially — scope change, contract variations, design development, force majeure — and the baseline has not been updated to reflect the new state of play. Rebaselining is politically uncomfortable. It requires acknowledging that the project has changed and the original numbers no longer apply. On publicly funded projects, rebaselining can trigger scrutiny from funders, auditors, or ministers. So baselines persist long past their usefulness, and the S-curve becomes a comparison between current performance and a baseline that describes a different project. The NEC contract suite, which is widely used on UK public-sector projects, has a structured mechanism for compensation events that should, in principle, keep the target cost updated. In practice, disputes about compensation event valuations mean the baseline often lags. The result is an S-curve that is technically correct — it shows actuals against the contractual baseline — but managerially misleading, because the baseline is not the project any more. The APM Body of Knowledge is clear that the project baseline should be maintained and updated through formal change control. A baseline that is more than six months old on a fast-moving programme should prompt the question: does this still describe what we are building? ### 3. Aggregation is hiding the detail An S-curve is a summary. All summaries aggregate. Aggregation conceals. The most common version of this problem is a programme-level S-curve that looks healthy because one package is running ahead of plan and offsetting another that is running significantly behind. The overall curve tracks the baseline. The project controls team reports no concern. Meanwhile, the mechanical and electrical package is six weeks late and the project manager for that package has been sending warning emails for two months. S-curves should be produced at the package or work breakdown structure level, not just at the programme level. When an aggregate curve is the only thing reported upward, the people making decisions are seeing a smoothed average that may not reflect the state of any individual part of the work. Package-level curves are more work to produce and harder to present in a single slide. They are also the only version that is genuinely informative. A related aggregation problem occurs on multi-project programmes, where individual project curves are combined into a portfolio view. Portfolio S-curves have their uses — they give funders and programme boards a high-level view — but they should never be used as a substitute for project-level reporting. The portfolio can look fine right up until the point where it is not. ### 4. Earned value is being gamed Earned Value Management — EVM — should make the S-curve more useful, not less, because the earned value line tells you not just what you have spent but what you have actually achieved. Actuals above the earned value line means you are spending more than the work is worth. Actuals below means you are either running efficiently or deferring spend. In practice, earned value is often the most manipulated number on the chart. Progress is self-reported. The teams reporting progress have an obvious incentive to show momentum. Without rigorous physical percent-complete rules — the 0/100 rule, the 50/50 rule, or milestone-based earning — earned value creep is almost inevitable. The warning signs are an earned value line that tracks actuals almost exactly (suggesting EV is being reverse-engineered from spend rather than measured from physical progress), or a project that reports 80% complete in terms of earned value but is clearly not 80% done in any physical sense. Both are common. Both mean the S-curve is showing you a reassuring fiction. Proper EVM requires agreed earning rules, documented in the control account plan, applied consistently, and audited periodically. AACE Recommended Practice 73R-12 covers earned value implementation in detail. The APM Earned Value Management Handbook is a useful UK-focused reference. On MoD CADMID Manufacture-phase contracts the EVMS reporting requirement is stipulated in the contract data and aligns to AACE 11R-88 — and the reverse-engineered earned value signature described above is precisely the failure mode IPA and MPRP reviewers look for at gate. If neither document has been consulted in the production of the EVM system, treat the earned value curve with scepticism. ### 5. Risk has been ignored A deterministic S-curve shows one line for planned spend. It has no width. It conveys no uncertainty. It implies that the project will, absent any problems, track exactly the planned profile — and that any deviation is a management failure rather than an expected consequence of the risks inherent in the work. This is a structural misrepresentation of how projects work. Every baseline is an expected-value plan — it represents the central estimate of what will happen. But there is a distribution of possible outcomes around that central estimate, and the S-curve does not show it. Adding probabilistic bands to an S-curve — drawing the P20 and P80 envelope around the deterministic baseline — is standard practice in programmes that run integrated QRA. It changes the message of the chart fundamentally: instead of "we are behind plan," the chart shows "we are within the expected range of outcomes" or "we are outside the expected range of outcomes." The former invites unhelpful questions about what went wrong. The latter is an honest acknowledgement that project delivery involves uncertainty. If your S-curve reporting does not have probabilistic bounds, you are measuring performance against a theoretical perfect outcome. That is not a useful benchmark. ### What a healthy S-curve looks like A well-constructed S-curve for a real project should show a baseline that was built bottom-up from a credible estimate and a logic-linked, resourced schedule. It should be accompanied by a date stamp and revision number so readers know when it was last updated. It should have been through formal change control every time scope or programme changed materially. The actuals line should track smoothly — erratic spikes and dips usually indicate invoicing or accruals timing problems, not real project volatility. If actuals look smooth and the project feels chaotic on site, the accruals basis needs investigating. If EVM is in use, the earned value line should diverge from actuals in ways that make physical sense. A project that is genuinely ahead of plan on a labour-intensive activity should show EV above AC. A project that has mobilised heavily but not yet produced much physical output should show AC above EV, with EV expected to catch up as production ramps. Probabilistic bands, where the programme has run QRA, should be present and should reflect current risk exposure — not the risk register from six months ago. The current actuals and earned value should sit comfortably within the bands for a project that is tracking as expected. Crucially, a healthy S-curve should be accompanied by a written narrative. The curve shows what is happening. The narrative explains why. A curve without a narrative is a picture without a caption: readable, but not informative. ### How to fix it Fixing a broken S-curve reporting process requires addressing the root causes, not just the symptoms. That usually means three things. First, audit the baseline. If it has not been updated in more than a quarter and scope has changed, commission a rebaselining exercise. This will be uncomfortable. Do it anyway. A misleading baseline is worse than an honest acknowledgement that the project has moved. Second, establish proper earning rules if EVM is in use. Write them into the control account plan. Conduct a one-day workshop with package managers to agree how progress will be measured — physically, not financially — and document the outcome. Then audit compliance quarterly. Third, disaggregate. Produce package-level curves alongside the programme-level summary. Make the package-level data available to the project controls team and the project manager. The programme-level curve is for the board and the client. The package-level curves are for the people running the work. None of this is novel. The guidance exists — in AACE standards, the APM Body of Knowledge, and NEC contract administration guidance. The problem is rarely knowledge. It is the institutional pressure to produce a report that looks acceptable rather than one that is accurate. That pressure can only be addressed by senior sponsors who ask hard questions about the assumptions behind the curves — and who recognise that an honest curve showing a problem is more valuable than a tidy curve hiding one. ### When to abandon S-curve reporting entirely Sometimes the honest answer is that an S-curve is not the right tool. There are project types where the S-curve convention is so poorly suited to the work that continuing to produce one creates more confusion than it resolves. Time-and-materials or cost-reimbursable contracts with highly variable scope — consultancy programmes, research and development work, early-stage design commissions — do not have the kind of stable baseline that makes an S-curve meaningful. You can plot actuals against a budget envelope, but the baseline is an estimate with very wide uncertainty, and any apparent divergence may simply be scope crystallisation rather than underperformance. Phased programmes where phases have not yet been scoped and costed are another case. Plotting phase-three and phase-four spend on a long-horizon S-curve, when the work for those phases has not been defined, is forecasting fiction. Better to show a well-defined near-term curve and acknowledge the uncertainty in the out-years explicitly. Highly iterative or agile delivery approaches — common in digital and technology programmes — report progress in velocity and throughput, not in financial S-curves. Forcing agile teams to produce S-curve reporting distorts their working practices without adding genuine insight. There are better tools for those environments. The test is simple: does this S-curve help decision-makers make better decisions? If the honest answer is no — because the baseline is unreliable, the data cannot be trusted, or the format does not fit the delivery model — then producing it is bureaucratic theatre. Stop producing it, and find a reporting method that is honest about what is actually known. Your programme board will not thank you immediately. They will thank you when they avoid a nasty surprise. ### Frequently asked questions **Why is my project S-curve showing good performance when the project is clearly in trouble?** The most common cause is a weak or manipulated baseline. If the planned value (PV) curve was drawn to match actual spend rather than reflect genuine work scope and sequencing, the earned value will naturally track close to it — not because the project is performing well, but because the baseline has been written to absorb actual performance. Other causes include: progress percentages estimated rather than measured (producing inflated EV), materials on site being counted as earned value before installation, and milestones ticked off on the due date rather than when work was actually complete. **What causes an S-curve to flatten in the middle of a project?** A flattening mid-project usually reflects a resource gap, a procurement delay, or a planning assumption that has failed. The cumulative spend should follow the bell-shaped spend rate implied by the S-shape — if the actual curve goes flat while the plan is still rising, something has stopped progress. Common culprits are: late mobilisation of subcontractors, long-lead materials that have not arrived, an interface dependency from a preceding package that has slipped, or a workforce reduction not reflected in the re-forecast. **How should an S-curve be updated when scope changes?** Every approved change to scope, cost, or programme should be incorporated into the baseline S-curve through formal change control. The current baseline should always reflect currently approved scope. When a change is approved, the old baseline becomes a historical reference line and the new baseline absorbs the change. Programmes that keep the original baseline frozen while scope grows around it manufacture a permanent apparent overrun — the reporting system produces bad news it cannot explain, and the data loses credibility with the steering group. --- ## NEC4 and Schedule Risk — What the Contract Actually Expects URL: https://www.somaprojectcontrols.com/resources/guides/nec4-schedule-risk Subtitle: A plain-English guide to Clauses 31 and 32, the Accepted Programme, float allocation, compensation events, and the most common mistakes contractors and project managers make. Published: 2026-04-17 · 11 min read ### Why NEC4 and schedule risk are inseparable NEC4 — the fourth edition of the New Engineering Contract suite — is built around the Accepted Programme in a way that no earlier standard form contract was. Under NEC3 and NEC4, the programme is not just a planning document; it is the commercial engine of the contract. It drives compensation event assessments, it determines what float belongs to whom, it is the reference against which delay is measured, and it is the mechanism by which the contractor demonstrates entitlement to additional time and money. Understanding how NEC4 treats the programme is not optional for practitioners on NEC contracts — it is the foundation of commercial management. The key risk for both parties is misunderstanding what the contract requires and what it protects. Contractors who submit thin, constraint-heavy programmes risk having them rejected — and then running the project without an Accepted Programme, which means compensation events must be assessed on assumptions the project manager makes, almost always to the contractor's detriment. Project managers who reject programmes for the wrong reasons — or who accept substandard programmes under time pressure — create problems downstream when those programmes are used as the basis for compensation event assessments. This guide covers the main contractual provisions, the practical implications for schedule quality and risk, and the most common errors on both sides of the table. It is not a substitute for reading the contract — clause numbers are given throughout, and the full NEC4 Engineering and Construction Contract should be read alongside this guide. ### Clauses 31 and 32: programme submission and acceptance Clause 31 sets out what the Accepted Programme must contain. Under NEC4 ECC, the programme must show: the starting date, access dates, and Key Dates; planned completion; the order and timing of the operations the contractor plans to do; the order and timing of work by the client and others; the dates when the contractor needs information, decisions, and resources from the client; dates when work must meet the Accepted Programme; float; time risk allowances; health and safety requirements; and the contractor's resource and cost forecasts. This is a substantially more detailed requirement than most contractors initially appreciate. Time risk allowances (TRAs) are the contractor's explicit acknowledgement of schedule uncertainty. They are distinct from float: TRA is the contractor's own risk provision for duration uncertainty, while float is the scheduling headroom that arises from the difference between the planned completion and the contractual completion date. The contract requires TRAs to be shown explicitly — they are not just embedded in activity durations. A programme that has no identifiable TRAs is arguably non-compliant with Clause 31, and a project manager who accepts it without raising this is storing up difficulties for later. Clause 32 covers the contractor's obligation to revise the programme. The contractor must submit a revised programme when the project manager instructs it, when the programme no longer shows the actual progress, and in any event at intervals no longer than those stated in the Contract Data. Most contracts specify four-weekly programme revisions. A contractor who is not regularly revising and resubmitting the programme is not fulfilling their contractual obligations — and project managers should be issuing early warning notices and instructions to submit rather than accepting the status quo. ### The Accepted Programme versus the Working Schedule A common source of confusion on NEC projects is the difference between the Accepted Programme and what the contractor actually plans to do. The Accepted Programme is the contractually agreed reference document — the one that has been submitted, reviewed, and formally accepted by the project manager. The Working Schedule is the contractor's day-to-day operational tool, which may be more detailed, more current, or structured differently from the Accepted Programme. The Accepted Programme need not be identical to the working schedule, but it should not diverge significantly from it either. A programme submitted for acceptance that bears no resemblance to how the contractor actually intends to work is a misleading document — and one that will produce incorrect compensation event assessments when events are measured against it. Contractors sometimes submit simplified or idealistic programmes for acceptance while managing internally to a detailed working schedule. This practice is commercially dangerous: when a compensation event arises, the assessment will be based on the Accepted Programme, not the working schedule. The relationship between the two documents has become clearer in NEC4, which strengthens the obligation to show actual methods and sequences. Project managers are entitled to reject a programme that does not reflect the contractor's intended approach. If a programme shows a simple sequential construction sequence that the contractor intends to execute as a heavily overlapping, phased operation, it does not meet the Clause 31 requirements. The test is: if this programme were used to assess a compensation event today, would it produce a fair and realistic result? If not, the programme needs to be revised before it can be accepted. ### Float allocation: who owns it and why it matters Float — the difference between the planned completion date shown in the Accepted Programme and the contractual completion date — is one of the most commercially significant aspects of NEC4. Under NEC4 (and its predecessors), float belongs to the project, not to either party exclusively. This means that the contractor cannot "use up" the float on a compensation event to avoid showing a delay to the completion date, and the client cannot claim that the contractor has no entitlement to time because float exists. Float is shared project resource. The practical implication is in compensation event assessments. Under Clause 63, a compensation event that affects the critical path of the Accepted Programme — that is, it delays the programme completion date — gives rise to a Planned Completion delay, and the contractor is entitled to an extension of time equal to the delay to planned completion (not just to the contractual completion date). If the programme shows float between planned completion and contractual completion, a compensation event that is critical to the planned completion but does not extend beyond the contractual completion date still gives rise to an extension — because the delay has consumed the contractor's own float allowance. This is counterintuitive for project managers trained in other contract forms, where extension of time claims are typically measured against the contractual completion date rather than the planned completion. Under NEC4, the Planned Completion date in the Accepted Programme is the reference. Float is the contractor's property in the sense that compensation events should not be assessed in a way that forces the contractor to use their float to absorb the impact of events the client is responsible for. Contractors who understand this will plan programmes that make planned completion visible and distinct from contractual completion. Project managers who do not understand it will under-value compensation events and create disputes. ### Compensation events and programme impact: Clause 63 Clause 63 governs how compensation events are assessed. The key point for programme management is that the assessment must be based on the effect the compensation event has on the Accepted Programme — specifically, the effect on the planned completion date and on defined costs. This requires a valid Accepted Programme to be in place: if there is no Accepted Programme, the project manager makes assumptions about the programme, and those assumptions will almost always be less favourable to the contractor than the contractor's own plan would have been. The compensation event assessment process requires the contractor to submit a quotation showing both the time and cost impact. The time impact is assessed by inserting the compensation event work into the Accepted Programme and calculating how it affects planned completion. This is called a Time Impact Analysis (TIA). A well-constructed TIA shows the fragnet — the additional activities representing the compensation event work — inserted at the appropriate point in the programme, with revised logic, and demonstrates the resulting impact on planned completion. A common mistake by contractors is submitting time impact analyses based on the working schedule rather than the Accepted Programme, or on a programme revision that has not been formally accepted. The assessment must be based on the last Accepted Programme at the time of the event. If the contractor has been submitting revised programmes that have not been accepted — because the project manager has been slow to respond or has rejected them on questionable grounds — then the compensation event assessment may be based on a programme that is months out of date, which can significantly understate the true impact. Keeping the Accepted Programme current is not just a contractual obligation — it is a commercial imperative. Clause 63 also requires that compensation events are assessed at the time they occur, not in hindsight. The standard is what an experienced contractor would have expected the impact to be, using the information available at the time. This means the assessment is prospective, not retrospective — you cannot re-assess a compensation event in light of what actually happened if the actual outcome turned out worse than the forecast. This has important implications for risk: the contractor carries the risk of the actual impact being worse than the assessed impact, and the client carries the risk of it being better. ### Common mistakes on both sides The most common contractor mistake is submitting programmes that do not meet the Clause 31 requirements and then being surprised when the project manager rejects them. Thin logic, missing TRAs, activities without resources, and programmes that show completion exactly on the contractual completion date with no float are all reasons for rejection. The solution is to invest in proper programme preparation at the outset. A programme that takes two weeks to build properly is far cheaper than six months of dispute over a compensation event assessed against a poor baseline. The most common project manager mistake is accepting programmes that are not fit for purpose, either because of time pressure or because of a reluctance to engage in the administrative process of rejection and resubmission. A programme that gets accepted under pressure and then proves inadequate for compensation event assessment is a much bigger problem than the delay caused by properly rejecting and requiring resubmission. Acceptance of a substandard programme is not a shortcut — it is a deferred problem. Both parties frequently confuse the programme submission timescales. Under Clause 31, the contractor must submit a first programme within the period stated in the Contract Data (typically 4 weeks from the starting date). If no period is stated, the contract gives no time limit. Both parties should ensure the Contract Data specifies this period explicitly. Missing the submission deadline does not excuse the contractor — the project manager can instruct a submission — but it does mean the contract is operating without an Accepted Programme for the opening weeks, which is a commercial risk for the contractor. A subtler mistake is treating TRAs as contingency to be drawn down rather than as explicit risk provisions. Some contractors strip TRAs from programmes to make them look more efficient. A programme with no TRAs signals either that the contractor has not thought about schedule risk or that they have buried their risk provision in inflated activity durations — neither of which is the intent of the NEC4 programme requirements. TRAs should be visible, labelled, and justified. ### When to push back on programme rejection Not all programme rejections are legitimate. The project manager can reject a programme only on the grounds listed in Clause 31.3: that the contractor's plans are not practicable, that it does not show the information the contract requires, that it does not represent the contractor's intentions, or that it does not comply with the Works Information. A project manager who rejects a programme on grounds other than these is acting outside their authority under the contract. If a programme is rejected and the contractor believes the rejection is unjustified, they should respond in writing, identifying the specific grounds the project manager has cited and explaining why each ground does not apply. The contractor should not simply resubmit the same programme — that will result in the same rejection. They should either address the legitimate points (if there are any) or formally dispute the rejection through the compensation event mechanism. An unjustified rejection of a programme is itself a compensation event under Clause 60.1(6) — the project manager has failed to reply to a communication within the required time, or has taken an action in breach of the contract. The contractor should notify this as a compensation event. This is not an aggressive commercial move — it is exactly how the NEC contract intends disputes about programme acceptance to be resolved. The early warning notice process and the adjudication provisions exist precisely so these disagreements can be addressed promptly rather than accumulating as unresolved tensions. The broader lesson is that programme management under NEC4 is a continuous, disciplined process, not a one-off deliverable. The Accepted Programme must be kept current, TRAs must be maintained and visible, and compensation events must be assessed against a live and accurate programme. Contractors and project managers who treat the programme as an administrative burden rather than as the commercial engine of the contract will find themselves at a systematic disadvantage when things go wrong — which, on any real project, they eventually will. ### Frequently asked questions **What must an NEC4 Accepted Programme contain under Clause 31?** Clause 31 of NEC4 ECC requires the Accepted Programme to show the starting date, access dates and Key Dates; planned completion; the order and timing of the operations the contractor plans to do; the order and timing of work by the client and others; the dates when the contractor needs information, decisions and resources from the client; dates when work must meet the Accepted Programme; float; time risk allowances; health and safety requirements; and the contractor's resource and cost forecasts. This is a substantially more detailed requirement than most contractors initially appreciate — a thin Gantt chart will not meet it. **Who owns float on an NEC4 contract?** Under NEC4 and its predecessors, float belongs to the project, not to either party exclusively. This means the contractor cannot "use up" the float on a compensation event to avoid showing a delay to the completion date, and the client cannot claim that the contractor has no entitlement to time because float exists. The practical implication is that a compensation event affecting the critical path of the Accepted Programme delays planned completion, and the contractor is entitled to an extension equal to the delay to planned completion — not just to the contractual completion date. Project managers trained in other contract forms often get this wrong, which creates disputes. **What is a Time Risk Allowance (TRA) under NEC4 and how does it differ from float?** A Time Risk Allowance (TRA) is the contractor's explicit acknowledgement of schedule uncertainty — their own risk provision for duration uncertainty on specific activities. Float is different: float is the scheduling headroom that arises from the difference between planned completion and contractual completion. Clause 31 requires TRAs to be shown explicitly on the Accepted Programme, not embedded inside inflated activity durations. A programme with no identifiable TRAs is arguably non-compliant with Clause 31, and a Project Manager who accepts it without raising this is storing up difficulties for later compensation event assessments. **How often must the contractor revise the Accepted Programme?** Clause 32 of NEC4 requires the Contractor to submit a revised programme at the interval stated in the Contract Data (most contracts specify four-weekly revisions), whenever instructed by the Project Manager, when the programme no longer shows actual progress, and whenever the Contractor's plans materially change. A contractor not regularly revising and resubmitting is in breach. The Project Manager has two weeks to accept the revised programme or state reasons for non-acceptance, with the same four restricted grounds as the original Clause 31 acceptance; failure by the PM to respond within two weeks is itself a compensation event under Clause 60.1(9). **When can the Project Manager legitimately reject a programme?** The Project Manager can reject a programme only on the four grounds listed in Clause 31.3: that the Contractor's plans are not practicable, that the programme does not show the information the contract requires, that it does not represent the Contractor's intentions, or that it does not comply with the Works Information. A rejection on any other ground is acting outside the PM's contractual authority. An unjustified rejection is itself a compensation event under Clause 60.1(6) — the Contractor should notify and respond rather than simply resubmit the same programme. **Are early warnings shown on the Accepted Programme?** Early warnings themselves are recorded on the Early Warning Register, not on the Accepted Programme. However, the matters notified via early warnings — events that could increase the total of the Prices, delay Completion or a Key Date, or impair performance — should be reflected in the programme through Time Risk Allowances, revised logic at subsequent Clause 32 submissions, or compensation event impact analyses once an event crystallises. The Accepted Programme and the Early Warning Register are complementary live documents that should be kept consistent. --- ## Running a QRA Workshop That Actually Works URL: https://www.somaprojectcontrols.com/resources/guides/running-a-qra-workshop Subtitle: Most QRA workshops produce numbers nobody really stands behind. This is how to run one that produces inputs you can defend at a gateway review. Published: 2026-05-06 · 13 min read ### Why workshops go wrong A QRA is only as good as its inputs, and its inputs come largely from workshops. After leading and independently reviewing QRA workshops on UK infrastructure, water, nuclear, defence and industrial capital programmes — including QRA leadership across the National Highways £1bn+ portfolio, independent validation on Mitsubishi Chemical UK (£400m), and a risk transformation across 400+ Northumbrian Water projects — I have a settled view on this: the model, however sophisticated, cannot compensate for poorly elicited three-point estimates, incomplete risk identification, or the social dynamics that cause risk workshops to produce comfortable consensus rather than honest uncertainty ranges. The facilitator's job is to create the conditions in which people say what they actually think, rather than what is politically convenient. Most risk workshop failures fall into one of four categories: the dominant voice problem (one or two confident people set the tone for the whole room and everyone else adjusts to them); the optimism anchoring problem (people anchor their pessimistic estimates too close to their most likely, because moving far enough into pessimistic territory feels like admitting the project is failing); the omission problem (the workshop captures the risks everyone already knew about and misses the less obvious ones that actually cause the most damage); and the social pressure problem (people will not raise risks they perceive as personal criticism of colleagues, or that they fear will make them look negative). None of these problems are solved by a better spreadsheet or a more sophisticated Monte Carlo tool. They are solved by facilitation — by the design of the workshop process and the skill of the person running it. This guide covers the practical techniques that work on real projects, including the less comfortable ones that most facilitation guides skip over. ### Pre-workshop preparation The quality of a risk workshop is largely determined before anyone enters the room. Preparation is the most important investment in workshop quality, and it is the one most often skimped on. Three things are essential: participant selection, pre-reading, and a structured agenda with enough slack to allow genuine discussion. Participant selection matters more than most facilitators acknowledge. You need people with direct knowledge of the work — the engineers, the package managers, the commercial lead. You also need people with institutional perspective — someone who has done a similar project before, who knows what went wrong last time, and who is not so close to this project that they have lost the ability to see it objectively. You do not want the room dominated by the project leadership team, who have the most to gain from optimistic estimates. Senior leaders should attend if at all, at the end, to hear the outputs — not at the start, where their presence chills honest contributions from more junior participants. Pre-reading should include: the current risk register (so participants have thought about the existing risks before arriving), the programme summary (so participants can think about schedule risks in context), the cost plan structure (so cost risks can be identified at the right level of granularity), and any lessons-learned outputs from similar previous projects. Sending pre-reading the day before and expecting it to be read is optimistic — send it a week before, and follow up two days before to confirm attendance and encourage preparation. A brief covering note explaining what the workshop will ask of participants helps them arrive with the right frame of mind. The agenda should allow at least half a day for a meaningful risk identification and quantification exercise on any project above about £10m. A two-hour risk workshop on a £50m programme is not enough time to produce credible inputs. Build in a proper lunch break — tired, hungry people give worse estimates than rested ones — and do not schedule the calibration exercise (the hardest cognitive work) for the end of the day when energy is lowest. ### Opening with opportunities, not just threats Most risk workshops open by asking participants to list things that could go wrong. This immediately frames the exercise as a list of bad news, which sets a defensive tone and can make the room feel like an implicit criticism of the project team's planning. A better opening reframes the exercise: we are here to understand uncertainty — both upside and downside — so that the project team can make better decisions. That means starting with opportunities as well as threats. Asking the room "what could go better than we've planned?" before asking what could go worse has several practical benefits. It counteracts optimism anchoring by establishing that the exercise is genuinely bidirectional — the pessimistic end of a three-point estimate is not a prediction of failure but a symmetric acknowledgement of uncertainty. It surfaces potential schedule pull-ins, cost savings, and commercial opportunities that should be included in the risk model. And it creates a more constructive psychological contract with the participants: they are contributing to a planning tool, not cataloguing the team's mistakes. Opportunities can be explicitly included in a cost risk model as negatively valued risks — risks with an upside impact that reduces expected cost. Not all QRA tools handle this elegantly, but the principle is straightforward: if there is a 20% chance that ground conditions prove better than expected and save £200k, that is a risk with a negative cost impact and it should be in the model. Excluding opportunities systematically biases the QRA output toward overestimating expected cost, which leads to over-provisioned contingency that is genuinely wasteful. ### The calibration problem The most intellectually demanding part of a risk workshop is calibration: helping people produce three-point estimates that genuinely represent 90% confidence intervals rather than anchored, too-narrow ranges. Research on human probability estimation is unambiguous — we are bad at it, and we get worse under time pressure and social pressure. The facilitator's role is to slow down the estimation process and introduce specific techniques that counteract the known biases. The most effective calibration technique is the direct challenge. When an estimator gives a minimum of £400k, a most likely of £500k, and a maximum of £600k, ask them directly: "Is there genuinely only a 5-10% chance that the actual cost of this item will be above £600k?" Most people, when asked that question plainly, will acknowledge that a 5-10% tail is too narrow and revise their maximum upward. The same challenge applies to the minimum: "Is there genuinely only a 5-10% chance that this comes in under £400k?" Applying the challenge to both tails often results in ranges that are 30-50% wider than the original estimate — and more realistic. A complementary technique is historical anchoring. Before the estimator gives their three-point range for a specific risk or activity, show them data from comparable risks or activities on previous projects. If the cost overrun for ground investigation packages on similar projects has ranged from −10% to +150%, that is the relevant empirical distribution — not the estimator's intuition. Reference class data is the most powerful single intervention against optimism bias in risk workshops, and facilitators who have assembled relevant historical data before the workshop will consistently get more credible outputs than those who rely entirely on expert elicitation. Finally, pre-commit before anchoring. Ask estimators to write down their minimum and maximum values on paper before they hear the most likely value from a colleague. Once a most likely value is spoken aloud, the minimum and maximum estimates anchor to it immediately. By committing independently first, each participant is forced to reason from their own knowledge rather than adjusting someone else's anchor. ### Drawing out quiet voices and handling dominant ones Group dynamics in risk workshops are predictable. The most senior or most confident people speak first and most often. Their estimates anchor the group. More junior people with direct operational knowledge — who often have the most realistic view of what can go wrong — adjust their views to match the room rather than challenging upward. The facilitator's job is to deliberately invert this dynamic. The most reliable technique for drawing out quieter voices is structured individual responses before group discussion. Before any discussion of a risk or estimate, ask each participant to write their minimum, most likely, and maximum on a sticky note or an index card. Then go around the room collecting the values before any are spoken aloud. Display all the values simultaneously — on a whiteboard or shared screen. The spread of responses, rather than the first voice, becomes the starting point for discussion. People who would not have volunteered a challenging outlier in open discussion are now contributing to a visible range that the whole room can see. For dominant voices, the most effective intervention is time-limited speaking with explicit invitation to others. If one person is giving detailed responses to every risk item, the facilitator can say: "That's really helpful — before we go further, I want to make sure we've heard from everyone in the room. [Name], what's your view on the lower end of this range?" Naming specific people to contribute is more effective than a general invitation, which dominant voices will fill again. This is not about silencing expertise — a confident, knowledgeable voice is an asset in a risk workshop. It is about ensuring that their estimates are tested against the perspectives of others in the room who may have different knowledge. The pre-mortem technique is particularly useful for surfacing risks from quieter participants. Asking people to write down (individually and silently) all the reasons the project has failed generates more honest responses than open brainstorming, because the anonymous framing removes the social pressure to be positive. The facilitator collects the responses, reads them without attribution, and uses them as the basis for structured discussion. Risks that emerge from this exercise — particularly those that appear on multiple participants' lists but were not on the pre-existing register — are usually the most important findings of the workshop. ### Five red flags your QRA workshop is theatre, not analysis Most of the QRA workshops I am asked to independently review have at least one of the following five problems. Two or more of them, and the model running off those inputs is not delivering the assurance it appears to — even if the S-curve looks immaculate. These are the patterns to look for whether you are commissioning a workshop, sitting in one, or inheriting outputs from one that has already been run. One: the estimates have not moved. If the three-point ranges produced by the workshop are within 10–15% of the most likely value on a complex package with multi-month durations or seven-figure costs, the facilitator either did not challenge the inputs or accepted the first numbers offered. A credible range on a major-package risk is usually 30–50% wider than the estimator's opening figure. Narrow ranges feel professional and produce a tight S-curve — but they are systematically wrong, because real projects experience wider variance than committed teams instinctively admit to. Two: nobody in the room referenced a comparable project. If a risk like ground conditions, commissioning duration, or design-development cost was quantified without anyone presenting data from how similar work has actually performed, the estimates are pure intuition. Reference class data is the single most powerful antidote to optimism bias, and a facilitator who walked into the room without it has not done the preparation. The question to ask after any workshop is: "What comparable project data did we anchor against?" If the answer is silence, the workshop did not have an external check on the team's internal anchor. Three: the same three voices spoke for three hours. If the facilitator's notes or the workshop recording show that the majority of the contributions came from two or three people in a room of ten or twelve, the workshop captured those people's views — not the room's. The estimates that emerged are anchored on whoever spoke first, and the operational knowledge held by the package engineers, junior planners, and specialist subcontractor representatives never made it into the model. Diverse contribution is not a soft facilitation virtue; it is what produces wider, more honest ranges. Four: the risk register barely grew. A well-run workshop on a complex programme typically surfaces material new risks that were not on the existing register — usually because they had been quietly avoided, or because nobody had looked at the project from the right angle before. If a half-day workshop produces a register that is functionally identical to the one the team walked in with, either the existing register was already exceptional (rare on inherited projects) or the social pressure to avoid raising new exposure points won. Workshops that confirm what was already known are usually workshops that missed what was not. Five: the outputs were not in front of the project team within 48 hours. If the draft risk register, action list, and summary of key findings did not reach participants while the discussion was still fresh in their minds, memories drifted, agreements weakened, and entries got softened in post-workshop review. The workshops that change projects are the ones whose outputs are treated as live decisions within two days. The workshops that go into a folder and stay there — and there are many — were compliance exercises, not analysis. If two or more of these are true on a workshop you have inherited or commissioned, the right response is not to re-run the simulation. It is to re-run the inputs. The model behaves exactly as it should given what it was fed; the assurance failure is upstream of the tool. ### Wrap-up and turning outputs into usable risk register entries The end of a risk workshop is where most of the value is either captured or lost. A workshop that generates rich discussion but ends without clear outputs — specific risk entries with agreed probability and impact ranges, an action list with owners and due dates, and a summary of the key findings — has wasted most of its investment. The facilitator should have been capturing risk entries throughout the workshop in a structured format, not just taking notes. Each entry needs at minimum: a unique identifier, a cause-risk-effect statement (not just a risk title), a probability of occurrence, a three-point cost impact range, a three-point schedule impact range, a risk owner, and the agreed mitigation actions. If the quantification exercise is done well during the workshop, these can be entered directly into the risk register tool on screen, shared with the room, and confirmed before the session ends. Sending a draft risk register for review after the event is a weaker process — memories fade, people disagree about what was agreed, and entries get softened in post-workshop review. The summary of key findings should be presented back to the group before the workshop closes. "The three risks driving the most uncertainty are X, Y, and Z. The areas where we have the least confidence in our estimates are A, B, and C. We identified two risks today that were not on the existing register — these are D and E, and they are now flagged as high-priority for immediate mitigation planning." This summary serves two purposes: it confirms that the facilitator has correctly understood the workshop outputs, and it sends participants home with a clear message about what matters most. Without a verbal summary, the workshop's findings are distributed across sticky notes and spreadsheet rows, and nobody is clear on the priority. Follow-up within 48 hours is critical. Send the draft risk register, the action list, and a brief summary of the key findings to all participants while the workshop is still fresh in their minds. Ask for corrections and additions by a specific date — two weeks is usually enough. After that window, the register should be treated as confirmed. Workshops that do not produce a final register within a month of the session tend not to produce one at all, and the investment in facilitation is wasted. A QRA workshop is the highest-leverage activity in the risk process. The simulation tool, the risk register format, and the report template are downstream — the inputs decide whether the model produces a number you can defend at a gateway or one that everyone privately doubts. SOMA facilitates and independently reviews QRA workshops on UK infrastructure, water, nuclear, defence and industrial capital programmes — most often when a project is approaching a funding gate (IPA Gate 1 or 2 on government major programmes, or an equivalent Concept-to-Assessment transition on the MoD CADMID lifecycle), when a previous workshop's outputs are not landing, or when an in-house team wants an independent calibration check before the simulation is run. If that describes where you are, it is the conversation we are best at having. --- ## Monte Carlo Simulation Is Not Magic — What QRA Actually Does (and Doesn't Do) URL: https://www.somaprojectcontrols.com/resources/guides/monte-carlo-is-not-magic Subtitle: What Monte Carlo simulation actually is in three sentences, what it does well in QRA, garbage-in-garbage-out, merge bias, correlation, and how to read the S-curve output for a board or finance committee. Published: 2026-04-17 · 9 min read ### What it is — in three sentences Monte Carlo simulation runs your project model thousands of times. Each time, it picks a random value for every uncertain input — each cost estimate, each activity duration, each risk — consistent with the range and probability you specified for that input. The result is not a single answer but a distribution of possible answers, showing how likely each outcome is. That is it. The rest is detail — important detail, but detail. The reason it has an intimidating name and an air of mathematical sophistication is largely historical: when it was first used for nuclear weapons calculations in the 1940s, computing power was precious and running thousands of iterations was genuinely impressive. Today, a laptop runs 10,000 project scenarios in seconds. The technique is completely ordinary. What is not ordinary is using it well — which requires understanding what it can and cannot do. The three words most often applied to Monte Carlo by people who have encountered a bad one are: reassuring, sophisticated, and wrong. Reassuring because the S-curve looks authoritative. Sophisticated because the tool is technically advanced. Wrong because the inputs were too narrow, the correlation was ignored, and the output gave a false sense of precision about a fundamentally uncertain project. This guide is about the gap between those three words and what a good Monte Carlo analysis actually provides. ### What Monte Carlo does well Monte Carlo does two things better than any other analytical technique available to project controls practitioners. First, it correctly models the combined effect of many uncertain inputs. A project cost estimate with 200 line items, each uncertain by a range of ±10–30%, does not have an overall uncertainty of ±10–30%. The uncertainties combine — sometimes cancelling out, sometimes compounding — and the only rigorous way to capture their combined effect is to sample them together in a simulation. Analytical formulae can approximate this for simple cases; Monte Carlo does it correctly for any level of complexity. Second, Monte Carlo correctly handles the statistical phenomenon of merge bias in schedule models. Deterministic schedules assume that where multiple paths merge onto a single successor, the path that finishes last drives the successor's start. What they do not capture is the probability that any one of several near-critical paths could be the one that runs late. The more parallel paths converge on a milestone, the more likely at least one of them is to overrun — and the more the deterministic schedule underestimates the expected duration. Monte Carlo captures this automatically because it samples each path independently across thousands of iterations. Monte Carlo is also the only widely available technique that produces a full probability distribution of outcomes rather than a single point estimate. That distribution is genuinely useful information. A P50 cost of £100m and a P80 of £125m tells a board something meaningful: "we expect to come in around £100m, but we should budget to £125m to have an 80% chance of being within budget." A single deterministic estimate of £100m tells the board nothing about how confident that figure is. The distribution is the point. ### Garbage in, garbage out — and why it happens The most important thing to understand about Monte Carlo is that it is a processing engine, not a source of truth. Feed it narrow input ranges and it will produce a confidently narrow S-curve. Feed it wide, realistic ranges and it will produce a wide, honest distribution. The simulation cannot tell you which inputs are credible. That is a human judgement problem, and it is where most Monte Carlo analyses go wrong. The specific failure mode is anchoring on the most likely estimate. When someone who has been working on a project for months is asked for a minimum and maximum duration for a specific activity, they have a strong internal anchor: whatever they have been planning for. Moving away from that anchor feels like admitting uncertainty, which feels like admitting a potential problem. So the minimum comes in at 10% below the most likely, and the maximum at 15% above, and the resulting distribution is much narrower than the real uncertainty about that activity. This is a cognitive bias, not incompetence. It affects experienced practitioners just as much as inexperienced ones, and it affects senior leaders more than junior ones (because senior leaders are more committed to the plan). The correct response is structured calibration — explicitly challenging estimators with direct questions, presenting historical data from comparable activities, and running the outputs through a sanity check before accepting them. A cost range where the P80-to-P50 ratio is less than 1.15 on a complex project is almost certainly too narrow. A schedule distribution where the P80 date is within two weeks of the deterministic end date on a multi-year programme needs to be challenged. These are not arbitrary rules — they reflect the empirical reality of how projects actually perform. Garbage can also enter through the risk register. A risk model that contains only risks from the formal register — and those risks have been gamed down in workshops to avoid uncomfortable conversations — will systematically understate exposure. The best check is the reference class: what did similar projects actually cost and how long did they actually take? If the Monte Carlo P80 is materially below the reference class average outturn, the inputs are probably too optimistic, regardless of how rigorous the workshop process appeared. ### Merge bias: what your deterministic schedule is hiding Merge bias is one of the reasons that a properly run Monte Carlo schedule analysis almost always produces a P50 date later than the deterministic critical path end date — even before any discrete risk events are applied. It is worth explaining carefully, because clients and sponsors who see this gap often conclude that the simulation is being pessimistic when it is actually being accurate. Consider a simple example. Three parallel activity chains each have a 50% chance of finishing on time and a 50% chance of being two weeks late. They all converge on a single commissioning milestone. The deterministic schedule says the milestone is achievable on time, because each chain has a 50% chance of finishing on time. But the probability that all three chains finish on time simultaneously is 0.5 × 0.5 × 0.5 = 12.5%. There is an 87.5% probability that at least one chain overruns and delays the milestone. The deterministic schedule is not wrong in any individual fact — it is wrong about the combined probability. As the number of converging paths increases, the merge bias effect grows. A project with ten near-critical paths all converging on a single completion milestone may have a deterministic end date that has only a 5-10% probability of being achieved. The Monte Carlo P50 — the date with a 50% chance of achievement — might be two or three months later. This is not a modelling artefact. It is an accurate description of the project's expected completion. The deterministic schedule is the artefact — it presents a specific combination of lucky outcomes as the expected outcome. The practical implication is that projects with many converging parallel paths — typical of major infrastructure commissioning milestones, complex fit-out completions, and system integration milestones — should be planned with explicit schedule contingency beyond the deterministic programme. The Monte Carlo P50 is a better target completion date than the deterministic end date. Clients and funders who insist on P50 (or better) funding for cost but are happy to plan schedules to the deterministic end date are accepting a systematic bias toward late completion that will eventually show up as a delay claim. ### Correlation: the most neglected input Correlation in a Monte Carlo model captures the fact that risks and uncertainties are not independent of each other. If the project experiences bad weather in January, it will experience bad weather across all the activities running in January — not just one of them. If a key subcontractor underperforms on one package, they are likely to underperform on other packages they are delivering simultaneously. If the steel market is inflated, it will be inflated for all the steel-intensive elements across the project, not just one cost line. When correlation is ignored — when every risk and every activity duration is sampled independently — the simulation implicitly assumes that bad outcomes on one element are offset by good outcomes on another in the same iteration. This is statistically equivalent to assuming that all the risks are balanced across each simulated project. In reality, projects have good years and bad years, good site conditions and bad ones, cooperative supply chains and uncooperative ones. The correlation structure of a real project means that bad things tend to happen together. The consequence of ignoring correlation is a Monte Carlo output that is too narrow — a P80 that is probably closer to the true P60 or P65. On large, complex programmes where correlation effects are material, the difference between a correlated and uncorrelated model can be 10-15% of the total project budget. This is not a technical nicety — it is potentially the difference between funding the project adequately or not. Practitioners who receive a QRA report without any mention of correlation assumptions should ask directly: was correlation modelled? If not, the contingency recommendation may be systematically understated. Setting correlation coefficients does not require statistical expertise. The practical approach is to group related risks by common driver — all weather-sensitive activities, all activities dependent on a particular subcontractor, all activities affected by the same regulatory approval — and apply a uniform moderate positive correlation (typically 0.5 to 0.7) within each group. This captures the essential dependency without claiming false precision about specific correlation values. The result will be materially more accurate than uncorrelated sampling, and the difference will typically show up as a wider S-curve with a higher P80 that more honestly represents the project's true uncertainty. ### Reading the output for a board The standard output from a Monte Carlo cost or schedule analysis is an S-curve and a tornado chart. Both are useful, but neither is self-explanatory to an audience that has not seen them before. The facilitator presenting these outputs to a board or client needs a clear narrative that translates the numbers into decisions. For the S-curve: start with what the curve represents. "This chart shows the range of possible project costs given the risks and uncertainties we have modelled. The horizontal axis is cost; the vertical axis is probability. The point where the curve crosses 50% — here — is our P50 estimate of £X. This means that in half of all the scenarios we modelled, the project came in at or below £X. The point where it crosses 80% is £Y — our P80 estimate. We recommend funding to the P80 level, which gives an 80% probability of completing within budget." That is the whole explanation. Boards do not need to understand the Monte Carlo engine — they need to understand what the percentiles mean and which one they are being asked to approve. For the tornado chart: explain what drives the range of outcomes. "This chart shows the top risk drivers — the risks and uncertainties that most influence whether the project comes in at the low end or the high end of our cost range. The longest bar — ground conditions — is the single largest contributor to our cost uncertainty. If ground conditions prove better than expected, the project will likely come in below our P50 estimate. If they prove worse, we could be approaching P80 or beyond. This tells us where to focus risk management effort over the coming months." Two things to avoid. First, do not present the P50 as "the most likely cost" without qualification — it is the median outcome, not the mode. In a skewed distribution (which most project cost distributions are, because costs tend to overrun rather than underrun), the P50 may be somewhat above the deterministic estimate and the mode may be below the P50. The distinction is technical, but if a board member challenges you on it, you need to be able to explain it. Second, do not present the P80 as a ceiling — it is not. There is a 20% probability that the actual cost will exceed the P80. If the client or funder asks what happens if it does, the answer should be: "That is what management reserve is for, and here is the residual exposure at P95." Having the P95 number ready is standard preparation for any QRA presentation to a senior audience. The most important message to leave with a board is not the specific numbers but the appropriate level of confidence to place in them. A Monte Carlo based on well-calibrated inputs, realistic correlation assumptions, and a risk register that reflects the project's genuine exposure is a reliable planning tool. A Monte Carlo based on narrow estimates, no correlation, and a sanitised risk register is a false assurance. Telling the board which kind they are looking at — and what was done to ensure credibility — is part of the professional responsibility of anyone presenting a QRA. The same applies in front of a MoD CADMID Main Gate Board or an IPA Gateway Review team — reviewers familiar with the framework will press on correlation, reference class, and the optimism-bias adjustment, and will quickly detect a Monte Carlo whose distribution has been engineered tight to the funding envelope. ### Frequently asked questions **What is Monte Carlo simulation in project risk analysis?** Monte Carlo simulation is a computational technique that runs thousands of iterations of a project model (cost, schedule, or both), randomly sampling values from probability distributions assigned to each activity and risk. Each iteration produces one possible project outcome. Aggregating all iterations gives a probability distribution of outcomes — typically shown as an S-curve, with confidence levels reported at P50, P80 and P95. Monte Carlo is the standard quantitative method underpinning QRA on UK infrastructure, defence and public-sector capital programmes. **How many Monte Carlo iterations are enough?** Convergence is typically reached at 5,000–10,000 iterations for cost-only QRA and 10,000–25,000 for integrated cost-schedule risk analysis. Above that, additional iterations produce only marginal precision gains. The diagnostic test is to plot the moving P80 across iterations — once the line stabilises (changes by less than ~0.5% across the last few thousand iterations), the simulation has converged. Tools like @Risk and Safran show convergence diagnostics in the output panel. **What is correlation in Monte Carlo risk analysis?** Correlation captures the relationship between uncertainties — if risk A materialises, is risk B more or less likely to also materialise? On a real project, many risks share underlying causes (weather, supply chain, ground conditions, key resource availability) and are therefore correlated. Modelling them as independent (zero correlation) systematically understates the tail of the output distribution, because in reality bad outcomes cluster. Most credible Monte Carlo models apply a correlation matrix or use systemic risks (drivers that affect multiple line items at once) to capture this dependency. **What is the difference between a Monte Carlo S-curve and a tornado chart?** The S-curve shows the cumulative probability distribution of total project cost or duration — the y-axis is cumulative probability (0–100%), the x-axis is the cost or duration value. Read off P50, P80, P95 from the curve. The tornado chart shows which individual risks contribute most to the spread between best-case and worst-case outcomes — bars are ordered longest to shortest, like a tornado. The S-curve tells you how confident to be in a number; the tornado tells you which risks deserve mitigation effort. **What is the difference between a deterministic estimate and a Monte Carlo estimate?** A deterministic estimate is a single-point figure produced by summing the most-likely cost of each activity. It does not capture uncertainty or risk and is almost certain to be wrong. A Monte Carlo estimate is a probability distribution that explicitly models variability in each cost line, plus the impact of identified risks. The output gives a range with associated confidence levels — typically P50 (median) and P80 (the funding standard for UK public-sector programmes). The difference between the deterministic estimate and the P80 is the QRA-derived contingency. **Can Monte Carlo predict whether a project will overrun?** No. Monte Carlo produces a probability distribution of outcomes given the model inputs; it does not predict the future. A P80 of £118m means there is an 80% modelled probability that the project will not exceed £118m — assuming the input distributions and correlations are a faithful representation of the actual uncertainty. If the inputs are well-calibrated, the model is a reliable planning tool. If the inputs are narrow or the risk register is sanitised, the model produces a false assurance regardless of how many iterations it runs. --- ## Reading a DCMA 14 Result Properly URL: https://www.somaprojectcontrols.com/resources/guides/reading-a-dcma-14-result-properly Subtitle: What each metric actually catches, the metrics that mislead more than they help, and how to write a credible review report — not just paste the dashboard. Published: 2026-04-16 · 12 min read ### What DCMA 14 actually is The Defense Contract Management Agency 14-point schedule assessment — DCMA 14 — originated in the United States Department of Defense. It was developed as a rapid, automated health check for contractor schedules submitted under major acquisition programmes. The intent was practical: give schedule reviewers a consistent, repeatable way to flag obvious structural problems in a schedule without spending days doing it manually. That origin matters because it sets the boundaries of what DCMA 14 is and is not. It is a screening tool. It runs against the schedule data and produces pass/fail results against fourteen pre-defined thresholds. It is fast, it is reproducible, and it is widely understood — which is why it has migrated well beyond US defence procurement and is now used as a quick quality check on infrastructure, construction, and engineering programmes across the UK and internationally. UK MoD CADMID Demonstration and Manufacture-phase contracts routinely incorporate DCMA-style screening into the contract data requirements alongside the EVMS reporting clauses. What it was never designed to do is replace proper schedule quality assurance. DCMA 14 does not assess whether the logic is sensible, whether the durations are realistic, whether the resources are credible, or whether the schedule reflects how the work will actually be built. A schedule can pass all fourteen metrics and still be fundamentally misleading. Conversely, a schedule can fail several metrics legitimately — because the project genuinely has characteristics that trigger the thresholds — without those failures indicating a problem that needs fixing. This is the source of most of the frustration practitioners have with DCMA 14 reviews. A reviewer who treats every threshold breach as a non-compliance finding, without understanding what the metric is catching and whether that applies to this schedule, is not doing schedule assurance. They are generating a list. The skill is in knowing which list items matter and which do not. UK guidance — including the APM Planning, Scheduling, Monitoring and Control Specific Interest Group guidance and HM Treasury's project control frameworks for major programmes — references DCMA-style checks as a useful first-pass tool. AACE International's recommended practice 17R-97 sets out similar thinking on schedule quality assessment. None of them treat automated metrics as a substitute for professional judgement. ### The 14 metrics, in plain English Logic: measures the percentage of tasks with at least one predecessor and one successor. The threshold is typically less than 5% of tasks missing logic. Missing logic means tasks can float freely in the schedule — they have no dependency connections that tie them to the rest of the plan. A high missing-logic figure almost always indicates a schedule that has been built carelessly, or where the planner has given up on sequencing a section of work and left it as a list of floating activities. Leads: counts tasks with negative lag on their dependencies — effectively, start-before-finish relationships where work begins before its predecessor is complete. The threshold is zero. Leads are almost always a modelling shortcut that disguises a gap in the logic. If work genuinely can start before a predecessor finishes, that relationship should be modelled explicitly, not fudged with a negative lag value. Lags: counts tasks with positive lag on their dependencies. The threshold is typically less than 5%. Lags represent a deliberate delay built into a dependency — for example, a curing time, a drying period, or a notice period before a handover. This is one of the metrics most routinely misapplied in reviews, which we will return to in the next section. Relationship Types: checks the proportion of finish-to-start relationships versus other relationship types (start-to-start, finish-to-finish, start-to-finish). The threshold typically expects more than 90% finish-to-start. Overuse of other relationship types — especially when combined with lags — can make a schedule hard to follow and can mask float and near-critical path calculations. Hard Constraints: counts tasks with imposed dates (must-start-on, must-finish-on, start-no-earlier-than beyond reasonable bounds). The threshold is less than 5%. Hard constraints override the schedule logic and prevent the network from calculating dates correctly. They can mask negative float, artificially shorten the critical path, and make what-if analysis unreliable. High Float: counts tasks with total float above a defined threshold, typically 44 working days. High float indicates tasks that are not driving anything — they have large amounts of scheduling headroom. In moderation this is normal. In excess it usually means missing logic: the task is not connected to downstream milestones it should be driving. Negative Float: counts tasks with total float below zero — meaning the current schedule calculates a completion date later than the imposed or target date. Negative float is the clearest signal in the entire DCMA 14 suite that the schedule is predicting a problem. It is almost always worth investigating. High Duration: counts tasks with durations above a defined threshold, typically 44 working days. The concern is that long tasks are harder to track, provide less granular progress data, and may mask slippage until it is too late to recover. The threshold is less than 5% of tasks. Invalid Dates: checks for actual dates that are in the future, or forecast dates that are in the past, relative to the data date. Invalid dates indicate a schedule that has not been properly updated — progress has not been recorded, or the data date has not been advanced. An invalid date in a schedule is a direct signal that the data cannot be relied upon. Resources: checks whether tasks have resources assigned. The threshold varies but is typically more than 90% of tasks resourced. An unresourced schedule cannot be used for resource planning, cash-flow forecasting, or productivity tracking. On many programmes, resource-loading is done in a separate tool and the schedule is used purely for logic; in those cases the metric will fail but the failure may be intentional. Missed Tasks: counts tasks with a forecast finish date earlier than the data date that have not been recorded as complete. Missed tasks are tasks the schedule says should have finished but haven't been marked as done. A high count indicates either that progress is not being tracked or that the schedule is already behind and nobody has acknowledged it. Critical Path Test: verifies that the critical path runs continuously from the project start to the project end. If a schedule has no continuous critical path, it means there are gaps in the logic — the longest path through the network does not actually drive the end date. This is a serious structural problem. Critical Path Length Index (CPLI): a ratio of the time available to complete the project to the time required. A CPLI below 0.95 typically indicates the schedule is under pressure — the critical path is longer than the time remaining. A CPLI above 1.0 indicates float on the critical path. CPLI is one of the more useful forward-looking metrics in the suite. Baseline Execution Index (BEI): the ratio of completed tasks to tasks that should have been completed by the data date according to the baseline. A BEI below 1.0 means fewer tasks have been completed than the baseline predicted. Like CPLI, this is a useful productivity indicator, though it treats all tasks equally regardless of their size or criticality. ### The metrics that mislead more than they help Three metrics generate more unjustified findings than all the others combined: Lags, Hard Constraints, and High Duration. Each of them flags something that is genuinely problematic in some schedules and entirely appropriate in others. Treating a breach as a finding without understanding the context is the most reliable way to undermine your credibility as a reviewer. Lags. On a construction or civil engineering schedule, lags are frequently legitimate and necessary. Concrete requires a curing period before formwork can be struck — you cannot accelerate it by improving logic. Rebar connections have specified set times. Paint systems require drying windows between coats. Commissioning protocols specify minimum hold periods before energisation. Modelling these as lags on a dependency is correct practice. The alternative — creating separate activities for every curing or drying period — produces a bloated schedule with hundreds of placeholder tasks that add no informational value. A reviewer who flags every lag as a non-compliance without asking what each one represents is not analysing the schedule; they are running a spell-checker and calling it a review. Hard Constraints. In fixed-date contracts, imposed constraints are often unavoidable and contractually mandated. A project with a planning permission condition that specifies no works before a particular date, or a contract with a fixed handover date, or an interface with a third-party system that cannot be moved, will necessarily have hard constraints in those locations. The question is not whether hard constraints exist but whether they are documented, justified, and located where the contract or programme genuinely requires them. Constraints applied to activities buried in the middle of a work package with no obvious justification are a legitimate concern. Constraints on milestone activities tied to contractual completion dates are not. High Duration. Long-duration activities are appropriate for long lead procurement items, plant fabrication, regulatory approval processes, and extended design stages. A turbine procurement activity that genuinely takes six months should appear as a six-month activity. Breaking it into weekly sub-tasks to satisfy a DCMA threshold produces artificial granularity that obscures rather than illuminates. The relevant question is whether the duration reflects the genuine scope of the activity and whether it will be tracked with appropriate interim milestones. If a six-month procurement task has no milestones or progress indicators, that is a concern. If it has a well-defined procurement tracker running alongside the schedule, the duration itself is not the problem. The principle that applies across all three: context is everything. A reviewer who lists these as findings without providing the context for each one — and without asking the contractor to explain the rationale — is producing noise, not signal. The contractor will dismiss the review, the client will not learn anything useful, and the relationship will be more adversarial than it needs to be. ### The metrics that actually catch real problems Four metrics in the DCMA 14 suite almost always indicate a genuine problem when they fail: Missing Logic, Negative Float, Invalid Dates, and Critical Path Test failures. If a schedule fails any of these, the reviewer should pursue them until they understand exactly why. Missing Logic is the clearest indicator of schedule construction quality. A planner who has not connected tasks to their predecessors and successors has either not thought through the sequencing, or has deliberately disconnected tasks to create artificial float. Either way, the schedule cannot be used reliably for forecasting. Logic gaps mean the schedule does not model the dependencies of the work. Every logic gap should be investigated: what is this activity? Why is it not connected? Is there a genuine reason it floats freely, or has it been disconnected to avoid a negative float calculation? Negative Float tells you the schedule is already predicting a missed date. It does not tell you why, or how significant the miss is, or whether there is a recovery plan. But it is one of the hardest metrics to legitimately ignore. A schedule with negative float on the critical path is telling you, in plain arithmetic, that the current plan does not deliver the target completion date. The contractor needs to either explain why the negative float is an artefact of the modelling (for example, a constraint is set incorrectly) or present a credible recovery plan. Negative float that goes unacknowledged in a review report is a missed finding. Invalid Dates are a data quality problem. A schedule with actual dates in the future or forecast dates in the past has not been maintained properly. This matters because every calculation the schedule produces — float, critical path, forecast completion — is based on the data date and the relationship between actual progress and forecast logic. If the data is wrong, everything downstream is wrong. Invalid dates are not a scheduling philosophy question; they are a factual error that needs to be corrected before the schedule can be used for anything. Critical Path Test failures mean the schedule does not have a continuous path of logic from start to finish. Without a continuous critical path, the schedule cannot correctly identify which activities drive the end date. Float calculations will be unreliable. The critical path will appear broken or circular. This is a fundamental construction error that must be resolved before the schedule can be used as a planning or forecasting tool. It is not a threshold question — there is no legitimate reason for a schedule not to have a continuous critical path. These four metrics, taken together, tell you the most important things you need to know from a DCMA 14 run: is the schedule logic complete, is the schedule predicting a problem, is the data current, and is the network structure sound? If all four pass, you have a schedule that is at least structurally credible. If any of them fail significantly, you have a schedule that cannot be relied upon without remediation. ### What a credible review report looks like A credible schedule review report is not a screenshot of the DCMA 14 dashboard. Every client with access to the same scheduling tool can produce that screenshot themselves. The value of a professional review is the interpretation: what does this mean for this project, which findings matter, what should the client do about it, and what further information is needed. The structure that works: start with a three-line executive summary. Not a list of metrics — a statement of the reviewer's overall assessment. Something like: "The schedule passes nine of the fourteen DCMA 14 metrics. The two findings of concern are a continuous critical path failure affecting the civils package and negative float on the commissioning milestone. The remaining three failures reflect characteristics of this contract type and are not considered indicative of quality problems." That is the whole picture in three sentences. Everyone reading the report knows immediately whether there is a problem and what it is. Then address the metrics that failed and why it matters in this specific schedule. Not a generic description of what negative float means — the client knows. An analysis of where the negative float is, which activities are affected, what it implies for the completion date, and what the contractor has or has not said about it. The analysis should be grounded in the schedule data, not the metric definition. Then address the metrics that "failed" but are fine. This is the section most review reports omit entirely, and its absence is what makes contractors dismiss reviews as box-ticking. Explicitly acknowledging that the lag failures are legitimate curing times, and that the hard constraints are in the correct locations for this contract, demonstrates that the reviewer has actually read the schedule rather than run an automated tool and printed the results. Recommended actions should be ranked by criticality. A critical path failure and negative float on a key milestone are priority-one actions that require contractor response before the next reporting period. A high-duration activity on a long-lead procurement item that is performing to programme is not an action at all — it is an observation, if it is even worth mentioning. Finally, where metrics are ambiguous — where the reviewer cannot determine from the schedule data alone whether a finding is legitimate — the report should include a specific request for clarification. Not a general "the contractor should explain their approach to constraints" but "please provide the contractual or technical basis for the constraint applied to activity XYZ, ref. schedule ID 1047." Specific questions get specific answers. General observations get general deflection. ### The conversation with the contractor Schedule review is not an adversarial process, even when it produces uncomfortable findings. The goal is a schedule that accurately represents the project, that the contractor is committed to, and that the client can use to make decisions. A review process that generates defensiveness and dispute achieves none of those things. The most important technique is to ask rather than assert. "Can you walk me through why this constraint is here" is a different conversation from "this constraint is non-compliant." The first invites the contractor to explain their thinking; you may learn that the constraint is entirely justified. The second puts the contractor immediately on the defensive and forecloses the possibility of a collaborative resolution. And if you are wrong — if the constraint is justified and you have flagged it as non-compliant without checking — you have damaged your credibility for the rest of the review. The same applies to logic gaps and high float. "I can see activity 1047 has no successor — can you help me understand how it connects to the commissioning sequence" is more useful than "activity 1047 has missing logic." The contractor may have a sequencing reason that is not visible in the schedule data. Or they may not have a reason, in which case the question surfaces the gap more effectively than an assertion does. Where findings are genuine and significant — negative float, critical path failures, invalid dates — the tone should be direct but not combative. "The schedule is currently calculating negative float of 12 working days on the commissioning milestone. We need to understand the contractor's position on this before we can accept the schedule submission" is clear, professional, and actionable. It does not accuse. It states what the data shows and what the consequence is. It is also worth being explicit about what you are not finding. Telling a contractor "the lags in the concrete sequence look appropriate and we're not raising these as findings" builds trust and demonstrates that the review process is thoughtful rather than mechanical. Contractors who feel that every metric breach will be flagged regardless of context will start gaming the metrics rather than building better schedules. Contractors who feel the review process distinguishes legitimate from problematic findings will engage with it more seriously. The objective of a DCMA 14 review is not a clean dashboard. It is a schedule that accurately models the project, that the planner stands behind, and that the client can use for decision-making. The metrics are a starting point for that conversation, not the end of it. --- ## Cost vs Schedule Contingency — and Why Teams Confuse Them URL: https://www.somaprojectcontrols.com/resources/guides/cost-vs-schedule-contingency Subtitle: The structural difference between cost and schedule contingency, how three-point estimates feed both, the EMV vs QRA distinction, and how to defend the contingency number in a board paper. Published: 2026-04-16 · 10 min read ### Why this matters The conflation of cost contingency and schedule contingency costs money every year on projects that should know better. Not because the teams involved are incompetent, but because the two things are referred to using the same word, governed by different parts of the organisation, and consumed in entirely different ways. The confusion is structural, and it persists because nobody explicitly explains the distinction at the start of a project. The practical consequence is that boards and sponsors are routinely asked to approve "the contingency" as a single line item in a funding paper, without any clarity about whether they are approving a cost buffer, a schedule buffer, or some conflation of both. Risk managers report contingency drawdown without distinguishing between cost overruns and schedule slippage. And when a project is delayed, the question "should we draw down contingency to recover the programme" gets answered differently depending on who in the room you ask — because the finance director and the project planner are using the same word to mean different things. Getting this distinction right matters most at three points: when you are setting the project budget, when you are advising a board on funding adequacy, and when you are deciding how to respond to a delay. In all three cases, treating cost and schedule contingency as a single undifferentiated pot leads to decisions that are at best suboptimal and at worst actively harmful to the project. ### The structural difference Cost contingency lives in the budget. It is a financial reserve, owned by finance or the project sponsor, held above the base cost estimate to cover the cost impact of risks that materialise. It is drawn down through formal change control: a risk event occurs, the cost impact is quantified, a change is raised, and the contingency is released to cover it. Cost contingency is denominated in pounds. It appears on the project's financial statements. It is subject to governance approvals before it can be accessed. Schedule contingency lives in the schedule. It is a time buffer, owned by the planner or project manager, built into the programme to absorb delays without pushing the completion date beyond its target. Schedule contingency can take two forms: float on the critical path (the difference between the calculated completion date and the target completion date, where that difference is positive), or explicit buffer activities built into the programme at strategic points. Schedule contingency is denominated in time. It does not appear on financial statements. It is consumed when activities overrun their planned durations. These two things are not interchangeable. A two-month schedule slip does not get fixed by drawing down £2m of cost contingency — unless you can spend that money to compress the schedule, and even then, compression through additional resources or acceleration works only where the critical path activities are genuinely resource-constrained and can be crashed. Many schedule slippages cannot be bought out. Ground conditions, regulatory approvals, weather, third-party interfaces — none of these respond to additional spend in the way that, say, doubling the labour force on a constrained excavation might. The governance implications follow from this structural difference. Cost contingency is a financial governance question: who can approve drawdown, what evidence is required, what is the residual exposure if it is drawn down. Schedule contingency is a programme management question: how much float remains on the critical path, which activities are consuming it, and when does float exhaustion trigger a formal recovery plan. These questions go to different people, require different evidence, and have different consequences if the answer is unsatisfactory. On a well-run project, both are tracked separately and reported separately. The cost report shows the base estimate, approved changes, cost contingency held, and forecast final cost. The schedule report shows the current programme, float on the critical path, schedule contingency consumed to date, and forecast completion date. The two reports inform each other but are not substitutes for each other. ### How three-point estimates feed both Three-point estimates are the mechanism by which individual risks are translated into contingency. For each risk on the register, the estimator specifies three values: the minimum cost impact if the risk occurs, the most likely cost impact, and the maximum cost impact. The same three values are specified for schedule impact. A probability of occurrence is also assigned. The simplest aggregation of these inputs is the Expected Monetary Value (EMV) calculation. For each risk, EMV = probability × ((minimum + most likely + maximum) / 3). This gives you the probability-weighted expected cost impact of that risk. Summing the EMVs across the entire risk register gives you the EMV-weighted contingency: the total expected cost exposure from all identified risks. The same arithmetic applies to schedule impact. For each risk, calculate probability × ((minimum duration impact + most likely + maximum) / 3) to get the expected schedule impact in days or weeks. Aggregate across the register and you get the expected schedule exposure. This is useful for understanding the aggregate picture, but it has a significant limitation: it assumes all risks are independent, which they are not. A weather delay that extends groundworks will also delay the structure, which will also delay fit-out. The EMV of each risk in isolation does not capture how they interact. This is the structural reason Quantitative Risk Analysis (QRA) exists. A Monte Carlo simulation does not just add up the expected values — it models the interaction of risks, captures correlation between related activities, and produces a distribution of possible outcomes rather than a single point estimate. The difference between the EMV and the P80 from a QRA is not a matter of arithmetic; it is the additional uncertainty that comes from risks combining in adverse ways. On a complex project, the P80 from a well-run QRA will typically be materially higher than the sum of the individual EMVs, precisely because real projects experience clusters of bad luck rather than a smooth average of risk impacts. For cost contingency, the three-point estimates on cost risks feed the cost QRA model. For schedule contingency, the three-point estimates on schedule risks feed the schedule risk model (integrated cost-schedule risk analysis handles both simultaneously, which is the most rigorous approach but requires a well-structured schedule as input). The output of each model is a distribution: for cost, a range of possible final costs with associated probabilities; for schedule, a range of possible completion dates with associated probabilities. ### EMV vs QRA — when each is right EMV is right for forecasting and forward visibility. If you want to understand how much contingency to release back to the budget each quarter as risks close out, EMV is the right tool. As risks are retired from the register, their EMV contribution is removed from the expected exposure, and the remaining contingency requirement reduces. This gives finance a rational basis for releasing contingency back to the budget or to other parts of the programme as the project de-risks over time. EMV is also useful as a sense-check on the risk register. If the aggregate EMV across the register is £50m on a £200m project, that is a 25% expected overrun. That is either a signal that the base estimate is well-calibrated and the risks are genuinely significant, or a signal that the risk register has been over-populated with high-probability, high-impact risks that are not independent of each other. Either interpretation is worth understanding. QRA is needed when you need a defensible confidence level for a contingency recommendation. If you are writing a board paper recommending that the project be approved with a £30m contingency, you need to be able to say what confidence level that represents. "We recommend £30m of contingency because the EMV of the risk register is £28m" is not a defensible statement — it implies that the contingency is adequate only if risks occur exactly as expected, with no clustering, no correlation, and no surprises beyond those already on the register. That is not how projects work. "We recommend £30m of contingency based on a QRA that gives a P80 cost outcome of base estimate plus £30m, meaning there is an 80% probability that the final cost will be within that figure" is a defensible statement. It acknowledges uncertainty, it quantifies the confidence level, and it gives the board a clear picture of the residual exposure: there is a 20% chance the project will cost more than the contingency allows, and the QRA shows what that tail exposure looks like. Confusing EMV with QRA is one of the most common mistakes in board papers and gateway submissions. The two numbers are often close enough that the distinction seems academic — until the project hits a cluster of correlated risks and the actual outcome lands in the tail of the distribution that EMV never acknowledged. ### Defending the contingency number in a board paper The contingency number in a board paper is the figure that gets the most scrutiny and the least context. Boards are accustomed to challenging it: "why is contingency 20% of the base estimate?", "can we reduce it to get the project within budget?", "what happens if we approve less?" These are legitimate questions. The problem is that contingency recommendations are often presented in a way that invites those questions rather than pre-empting them. Lead with the confidence level you are recommending and why. Not the number first — the confidence level. "We are recommending a contingency provision that gives the project an 80% probability of completing within the approved budget" is a statement about risk appetite and governance, not just about money. It frames the number as a decision about acceptable risk exposure rather than a cost estimate to be negotiated down. The P80 figure then follows as the consequence of that decision. Back it up with the QRA output, the top five risk drivers, and the residual exposure if contingency is set lower. The QRA output — even a simplified S-curve showing the P50, P80, and P95 cost outcomes — gives the board a picture they can reason about. The top five risk drivers from the tornado chart tell the board what to watch: if those specific risks are actively managed, the contingency requirement reduces. The residual exposure at P70 or P60 tells the board what they are accepting if they approve less than the P80 recommendation: "if the board approves £20m rather than £30m, the project has a 60% probability of completing within budget and a 40% probability of requiring further funding — the expected overrun in the latter scenario is £8m." That is a decision the board can make. Approving a number without that context is not governance; it is guessing. What not to do: do not apologise for the size of the number. Contingency is not a sign of poor cost management; it is an honest acknowledgement that complex projects involve uncertainty. A project team that presents a small contingency to avoid challenge, knowing the real exposure is higher, is not managing risk — it is deferring the problem. The board will encounter the real exposure eventually, and they will be less sympathetic when it arrives as a cost overrun than they would have been if it had been presented honestly at the start. Do not lead with the EMV. EMV is a useful internal calculation; it is not a board-level recommendation. The EMV represents the average expected outcome across all possible scenarios, but boards are not funding the average scenario — they are funding the project, which will experience one specific set of outcomes. The P80 is the right number to recommend because it reflects a genuine risk appetite decision: we are confident enough in this outcome to fund it, and we accept that there is a 20% chance we will need to return for more. Do not hide the assumptions. Every QRA rests on assumptions about risk probabilities, impact ranges, and correlations. If those assumptions are challenged, the output changes. Be explicit about the key assumptions: the risks that are driving the contingency, the probability and impact ranges used for each, and any areas where the modelling team has limited data and has had to use professional judgement. Transparency about assumptions is not a weakness in a board paper; it is a mark of analytical rigour. It also makes the recommendation harder to dismiss, because a board that challenges an assumption must propose an alternative — and that forces a substantive conversation about the actual risk rather than a procedural challenge to the number. On MoD CADMID Concept and Assessment-stage business cases, the same logic applies in front of an IPA Gateway Review: lead with the confidence level, present the QRA output, and be transparent about the optimism-bias adjustment and the reference class behind it. ### Frequently asked questions **What is the difference between cost contingency and schedule contingency?** Cost contingency is a budget held above the base cost estimate to cover identified risks and residual cost uncertainty — it is drawn down when risks materialise as real costs. Schedule contingency (sometimes called time contingency or programme float) is time added above the deterministic programme to cover schedule risk and uncertainty — it is consumed when activities take longer than planned or when risk events cause delays. The two are related: schedule delays almost always drive additional costs (prolongation, preliminaries, loss of productivity), which is why integrated cost-schedule risk analysis is the preferred approach on major programmes rather than treating cost and schedule contingency independently. **How much contingency should a project carry?** Contingency should be sized by a quantitative risk analysis at the appropriate confidence level for the project's stage and the client's risk appetite. UK government guidance requires contingency to be set at a minimum of P50 (50% confidence) for initial estimates, moving toward P80 for final funding approval. As a rough rule of thumb, RICS and IPA data suggest cost contingency of 10–15% of base estimate on well-scoped construction projects and 20–35% or higher on complex infrastructure or technology-intensive projects at early design stages. Percentage rules of thumb should not substitute for a QRA on any project above ~£5m. **Who owns contingency on a NEC4 contract?** Contingency is a client-side budget — it is not part of the contract price and is not visible to the contractor. The contractor's price (whether a Defined Cost target or a lump sum) covers the base scope; contingency sits in the client's budget as a reserve against cost growth from compensation events, additional scope, and materialised risks. Management reserve, if held separately, is the client's buffer for unknown unknowns above the QRA-derived contingency. On NEC4, the Contractor's risk items are priced into the contract price or handled through the early warning and compensation event process — contingency does not pass to the contractor. --- ## Reading a Contractor's Schedule You Didn't Build URL: https://www.somaprojectcontrols.com/resources/guides/reading-a-contractor-schedule-you-didnt-build Subtitle: What to check first when a new programme lands on your desk mid-project, how to tell an honest schedule from a padded one, and how to brief your client without starting a war. Published: 2026-04-18 · 11 min read ### Why inheriting a programme is different Being handed a schedule you did not build is one of the most common situations in UK project controls, and one of the least written about. A new planner joining a live programme, a client appointing an independent reviewer halfway through construction, a contract changing hands mid-delivery — in each case the person doing the review has no memory of the decisions that produced the current programme, and a limited window in which to form a credible view. The usual advice — "understand the logic before you comment on the dates" — is correct but useless on its own, because nobody will give you four weeks to read the logic before they want an opinion. The practical reality is that you have a few days, sometimes less, to form a defensible first read. That first read will shape how the client perceives the contractor, how the contractor perceives you, and what questions get asked in the next progress meeting. Get it wrong in either direction and you either look naive (if you accept a padded programme as credible) or obstructive (if you flag too many issues without being able to justify them). This guide is about how to do the first-read properly, in the time you actually have. The instinct to treat the handover as a clean slate is a mistake. The programme you have been given is the product of commercial negotiations, technical arguments, and personal relationships you were not part of. The structure of the schedule often tells you more about those conversations than the activity durations do. Reading a contractor's schedule for the first time is partly a technical exercise and partly an archaeological one — you are trying to reconstruct the reasoning that led to the current artefact. ### The first-hour checks Before opening Primavera or Microsoft Project, answer four questions. Which version of the programme is this, and is it the current Accepted Programme or a working revision? What is the data date, and how recent is the last progress update? What is the contractual completion date, and does the programme show planned completion ahead of it, equal to it, or beyond it? What programme revision history exists, and how many times has the schedule been rebaselined since the contract was signed? These four answers tell you more about the state of the project than any DCMA metric will. Open the file and look at the activity count, the level of detail at critical path activities, and the spread of durations. A programme with 300 activities on an £80m construction job is too light. A programme with 12,000 activities for the same job is too heavy and probably unmanageable. The right level is usually 1,500 to 4,000 activities for a project of that size, depending on sector and contract form. Durations should cluster around a reasonable working range — on most construction projects, 90% of activities should have durations between two days and forty days. A programme where half the activities have durations of one day, or where several key activities run for twelve months with no decomposition, is not yet a planning tool. Run DCMA 14 — the Defense Contract Management Agency's 14-point schedule assessment, a rapid structural health check originally developed for US defence contractors — as a first automated sweep. The headline metrics are logic (the percentage of activities with both a predecessor and a successor, target above 95%), negative lag (target zero), hard constraints (target below 5%), and high float (target below 5% of activities with float greater than 44 working days). Do not over-interpret DCMA results. They identify structural weakness, not poor content. A programme can pass DCMA 14 comfortably and still be a fundamentally unrealistic plan, and a programme can fail two or three metrics and still be a sensible representation of the work. Use DCMA as a screening tool, not as a verdict. Check the calendars. Most schedules use several — a standard five-day construction calendar, a six-day intensive calendar for certain packages, a seven-day commissioning calendar, and often a project-level calendar for milestones. Mismatched calendars are one of the most common sources of misleading critical paths. An activity on a six-day calendar tied to a successor on a five-day calendar can appear to consume float that does not exist, or vice versa. Check that the calendars assigned to activities are internally consistent, and that public holidays and planned shutdowns are reflected in the relevant calendars. ### Reading logic quality, not just logic count The DCMA logic metric tells you what percentage of activities have both predecessors and successors. It does not tell you whether those relationships make sense. A schedule can score 99% on the logic metric and still have logic that is structurally wrong — the activities are linked, but the links are soft, fictitious, or reversed. Reading logic quality requires looking at the network, not just the metric. Start with the critical path. Follow it end to end and ask: does this sequence describe how the work will actually be done? On most real projects, the critical path runs through a recognisable delivery narrative — design, procurement, long-lead item, enabling works, main construction, commissioning, handover. If the critical path jumps between unrelated packages, runs through an administrative milestone that no physical work depends on, or skirts around the obvious risk activities, the logic has been gamed to move the critical path off something the contractor did not want to discuss. Look for finish-to-start relationships with large lag values. A finish-to-start link with 40 days of lag is almost always either a missing activity (the 40 days of lag represents work that should be explicit on the programme) or a fudge (the lag has been inserted to push a successor out to a preferred date). Lags of more than 10 days deserve a question each. Lead lags — negative lag values — should not appear at all on a well-built schedule and are the first thing DCMA will flag. Check start-to-start and finish-to-finish relationships for plausibility. Overlapping activities linked start-to-start are fine where two trades genuinely run in parallel. They become problematic when they are used to compress a sequence that should be in finish-to-start — plastering tied start-to-start with painting, for example, with no lag to represent drying time. Finish-to-finish relationships are often misused to force two activities to complete simultaneously when in reality one must precede the other. Both patterns indicate a programme that has been shaped to hit a date rather than to represent the work. The test that catches most logic problems is the "what happens if" test. Pick an activity mid-sequence and add four weeks to its duration. Does the knock-on effect propagate sensibly through the network, or does it terminate against a hard constraint? If the delay stops at an artificial constraint rather than flowing through to completion, the programme is not responsive to reality and will not support credible impact analysis on compensation events or delay claims. ### Honest schedules versus padded ones There is no single test that distinguishes an honest schedule from a padded one, but there are patterns. A padded schedule typically shows planned completion comfortably ahead of the contractual completion date, with a large block of float at the end of the programme masquerading as contingency. An honest schedule shows planned completion close to the contractual date, with explicit time risk allowances — NEC4's term, now widely used even on JCT and FIDIC jobs — distributed through the programme at points where duration uncertainty is real. Look at the total float distribution. On a well-structured programme, float is distributed unevenly — some activities have zero float (the critical path), some have moderate float, a minority have large float. A programme where most activities have similar float values has almost certainly been artificially levelled, either by automatic resource levelling or by a planner pushing activities around to achieve a tidy-looking bar chart. Tidy bar charts are a warning sign. Real projects have messy float distributions because real work has messy dependencies. Check the duration assumptions on the critical activities. A contractor who has told the client the job will take 52 weeks, and has produced a programme showing exactly 52 weeks, has almost always absorbed their entire planning uncertainty into activity durations. This is the most common form of padding because it is invisible — each activity looks individually plausible, but the cumulative effect is that every activity carries a hidden buffer. The diagnostic is to look at the three or four longest activities on the critical path and ask: what is the most optimistic duration for this work, and how does it compare to what the programme shows? A programme where every critical activity is at the pessimistic end of a plausible range is a programme with embedded buffer. The opposite failure — an overoptimistic schedule — is just as common and easier to spot. The tells are: no allowance for commissioning and snagging at the end; design activities compressed into windows that cannot accommodate client review cycles; procurement durations that assume the supply chain responds in the contractor's preferred timeframe rather than the realistic one; and no weather or access contingency on activities that are genuinely weather-sensitive. A schedule that ignores these realities will not survive its first serious disruption. The honest version looks different. Planned completion matches the contractual date, with a handful of visible TRAs protecting the completion. Durations on critical activities sit in the middle of a plausible range. Procurement and design activities carry explicit client review durations. Commissioning and handover have a sensible allocation of time — typically 10-15% of the total construction duration on a complex project. There is no single number that confirms this; it is the overall texture of the schedule that tells you whether it was built by someone who expected to deliver it. ### Questions to ask the contractor Before writing a review note, sit down with the contractor's planner. A 30-minute conversation with the person who built the schedule will tell you more than another four hours of analysis. The aim is not to ambush them with gotchas but to understand the reasoning behind the structure — which, on a reasonably competent programme, they should be able to explain comfortably. Start with the critical path. Ask the planner to walk through it and explain why each transition is necessary. A good planner will describe the delivery logic fluently — "this activity has to finish before that one starts because the scaffold has to come down before the facade can be installed." A weaker planner will explain the critical path as a sequence of predecessors and successors without reference to what physically has to happen. That difference tells you how well-understood the programme is by the team that built it. Ask about constraints. Every hard constraint on the programme should have a reason — a client-imposed milestone, a physical access date, a regulatory approval that cannot move. If the planner cannot explain why a particular constraint is there, or explains it in terms of what the programme needed to show rather than what the project requires, the constraint is probably artificial and should be challenged. NEC4 programmes in particular should have very few hard constraints, because the NEC model expects the programme to respond to changes rather than hold fixed dates regardless. Ask about resources. A schedule without resource loading is acceptable on some projects but not on major infrastructure or complex fit-out works. Ask how resource profiles have been built into the plan — have the critical activities been checked against available labour, crane time, or supply chain capacity? A programme that is feasible activity by activity but requires more concurrent concrete pours than the site can support, or peaks concurrent trades beyond what the welfare facilities can accommodate, will not deliver on time regardless of how tidy the logic looks on screen. Ask about the risk register and time risk allowances. Where are the TRAs, and how were they calibrated? A planner who can point to specific TRAs and explain how they were sized — typically as a percentage uplift on activities with known duration uncertainty — has thought about risk. A planner who cannot find the TRAs on their own programme, or who describes them as "built into the durations," has a problem you will need to surface in the review. ### Briefing the client without starting a war The review output has to be usable. A report that lists 40 DCMA failures without interpretation is worse than no report at all, because it makes the reviewer look pedantic and gives the contractor an easy opening to dismiss the findings as box-ticking. The brief to the client should cover three things: what the schedule tells you about the state of the project, what it does not tell you that you would want to know, and what actions follow from the review. Lead with the state of the project. "The programme is structurally sound and consistent with the current state of the works; however, planned completion sits only one week ahead of the contractual completion date, and the visible time risk allowance is limited, which suggests limited headroom to absorb further delays." That is a defensible opening statement that gives the client a real picture without accusing the contractor of anything. The client can then ask follow-up questions — what specifically is fragile, what would a delay of X weeks mean, what should we ask the contractor to do — and the conversation proceeds constructively. Be explicit about what the schedule does not show. If the programme does not cover commissioning in adequate detail, say so. If the risk register is not integrated, say so. If there is no resource loading and the works cannot be verified as feasible without it, say so. These are not criticisms of the contractor; they are observations about the evidence available to the review. The client can then decide whether to request additional information from the contractor or to live with the gap. Make the recommendations specific and proportionate. Recommending that the contractor "rebuild the programme from scratch" is almost never appropriate unless the programme is fundamentally broken. More commonly, the recommendations are targeted: request clarification on specific constraints, ask for a fragnet showing how commissioning will be delivered, propose that the parties agree on a set of TRAs for the most uncertain activities, ask for resource profiles for the critical trades. Each recommendation should have a named owner and a target date. Avoid framing the review as an adversarial exercise. Contractors who feel attacked by a review will dig in defensively, and the next conversation will be about point-scoring rather than schedule improvement. The most productive reviews are delivered with genuine respect for the work the contractor has done — the programme may have flaws, but building a construction schedule is hard and the person who built it has engaged with problems you are only now starting to see. Positioning the review as a collaborative effort to strengthen the schedule for the benefit of both parties produces better outcomes than a confrontational one, and a stronger schedule protects the client just as much as it protects the contractor. ### What to do on Monday morning If you have just been handed a programme and need to produce a review by the end of the week, work in this order. Monday: run DCMA 14, check calendars, identify the data date and the last accepted programme. Tuesday: trace the critical path end to end and document any anomalies. Wednesday: sit down with the contractor's planner and ask the questions above. Thursday: analyse float distribution, duration plausibility on critical activities, and the treatment of TRAs. Friday: write the brief, keeping it to two pages plus a technical annex. Do not try to form a final view before you have spoken to the planner. The programme on screen is one half of the evidence; the reasoning in the planner's head is the other half, and reviews that rely only on the former miss important context. If the planner is unavailable, note this in the brief and flag that the conclusions are provisional pending that conversation. Do not recommend rebaselining unless the programme is genuinely unusable. Rebaselining is expensive, politically fraught, and often results in a new baseline that is no better than the old one. Most programmes that initially look troubling can be repaired through targeted improvements — tightening logic, removing unjustified constraints, adding explicit TRAs, decomposing overlong activities. Reserve the rebaselining conversation for programmes that have fundamentally lost touch with reality. Finally, make a habit of documenting your findings as you go, even if the formal review is not due for days. A working note kept during the review — with screenshots, annotations, and questions as they occur — is the best defence against being challenged later on where a particular observation came from. On any project of material value, the review you are writing this week may be read in two years as evidence in a dispute. Write it with that future reader in mind. --- ## When CPI Is Lying — The Hidden Failure Modes of Earned Value URL: https://www.somaprojectcontrols.com/resources/guides/when-cpi-is-lying Subtitle: Why your CPI and SPI can look healthy on a project that is quietly falling apart, what to look at instead, and when to abandon earned value altogether. Published: 2026-04-18 · 10 min read ### What the numbers are supposed to mean Earned Value Management — EVM — compares three numbers. Planned Value (PV) is what you expected to have spent by now, according to the baseline. Earned Value (EV) is what you have actually achieved, valued at baseline rates. Actual Cost (ACWP, or AC) is what you have spent. From these three, you derive the Cost Performance Index (CPI = EV/AC) and the Schedule Performance Index (SPI = EV/PV). A CPI above 1.0 means you are spending less than you have earned; an SPI above 1.0 means you are ahead of schedule. The technique is sixty years old and deeply embedded in how major projects report upward. Government programmes, defence contracts (notably MoD CADMID Demonstration and Manufacture-phase contracts where EVMS is mandated in the contract data), and most large infrastructure jobs above a certain value have EVM requirements written into them. The appeal is that a healthy CPI and SPI — say, 0.98 and 1.02 — can be presented to a steering group in two lines and suggests the project is under control. The problem is that a project can be quietly failing and still produce those two lines, because each of the three inputs has structural weaknesses that a careful project can exploit and an incompetent one can stumble into. This guide is about the specific failure modes of earned value in UK construction and infrastructure practice. It is not an argument for abandoning EVM. Well-run EVM on a well-structured contract is one of the most powerful governance tools in project controls. But EVM run against a poorly structured work breakdown, with progress measured by the contractor, and actual cost lagging invoices by three months, can produce numbers that give senior management a completely false impression of project health. Practitioners need to know when the numbers are reliable and when they are being moved around. ### Materials on site and the front-loaded curve One of the most common sources of EV distortion is the treatment of materials on site. On many construction programmes, materials delivered and stored — steel, mechanical plant, cabling, large components — are booked as earned value at the point of delivery rather than at the point of installation. The logic is commercial: the contractor has incurred the cost, the client is paying for the material, so the value has been earned. The consequence is that EV runs ahead of actual physical progress, sometimes significantly. On a major mechanical and electrical package, it is routine to see 25-35% of the package value delivered as materials on site months before meaningful installation begins. If those deliveries are booked as earned, the SPI looks excellent for the first half of the package. Then installation begins, and the contractor earns very little additional value for a period because the materials have already been credited. The SPI deteriorates sharply even though physical progress is tracking the original plan. The shape of the EV curve becomes front-loaded — a large early spike followed by a plateau — which systematically misrepresents project status at both ends. The fix is straightforward in principle and unpopular in practice. Materials on site should either be excluded from earned value entirely, with a separate line tracking material deliveries as a procurement metric, or they should be earned at a discounted rate — typically 50-70% of their value — with the remainder earned on installation. AACE Recommended Practice 10S-90 and the APM's earned value guidance both support the split. The reason this is unpopular is that it produces a less flattering EV curve in the early months, and contractors are reluctant to accept a measurement approach that makes them look behind when the commercial position is that they are on track. Client-side controls teams have to insist on it at contract award, not retrofit it after the contractor has been reporting rolled-up EV for six months. The diagnostic question is: what percentage of earned value to date represents physical installation versus procurement? If more than 30% of total earned value on a live construction package is materials on site, the SPI is almost certainly overstating progress. Ask for the split and, if it is not available, treat the SPI with caution. ### Progress measurement gamed at the package level Earned value depends on an honest measurement of physical progress. On any programme of material size, that measurement is done by the contractor — they complete the progress claim, they estimate percent complete, they submit for payment. The client-side controls team typically reviews the claim, but review is not independent measurement. Unless the client has quantity surveyors walking every package every month, the progress figures are the contractor's figures with a rubber stamp. The two most common gaming patterns are gradual overstatement and endpoint acceleration. Gradual overstatement is where every package runs at a steady 5-10% ahead of genuine progress — not enough to trigger alarm, but enough to keep the SPI comfortably above 0.95 throughout. The overstatement is only discovered near completion, when the contractor cannot close out the final activities because they were never actually as far advanced as reported. By then the cash has been paid, the programme has lost its float, and the client has no commercial leverage to recover. Endpoint acceleration is the opposite pattern: progress is reported genuinely for most of the package, and then jumps sharply in the final month to avoid triggering a late completion. The final jump represents work the contractor claims but has not done, and the closeout stretches on for months after the headline completion date. Neither pattern can be detected from the EV data alone. Both require physical verification — walking the site, comparing the claim against the work in place, spot-checking specific activities. On a well-run project, the client's quantity surveyor or construction manager will independently verify a sample of claimed progress each month, and the controls team will compare the verified sample against the claim to flag discrepancies. On a less well-run project, the controls team receives the claim, processes it, and produces the CPI and SPI without anyone physically checking. The third pattern is quieter and harder to detect: progress booked against tasks that are out of sequence. A contractor can achieve the headline earned value by front-loading the easy, high-value tasks and deferring the hard ones. The SPI looks healthy because the earned value is accruing at the planned rate, but the unearned balance is increasingly concentrated in the difficult work. When the easy work runs out, productivity collapses because the remaining scope is harder than the average assumed in the baseline. SCL Protocol 2nd edition addresses this as "opportunistic progress claiming" and notes that the only reliable defence is tracking progress by physical sequence, not just by cumulative percentage. ### ACWP lagging behind actual commitment The Actual Cost of Work Performed — ACWP, or AC — is meant to be the real money spent to achieve the earned value. In practice, it is usually the money paid, which is not the same thing. The lag between work done, invoice received, invoice approved, and payment issued can be three to four months on a typical UK construction job — sometimes longer under certain JCT payment regimes. This lag produces a structural understatement of actual cost in the reported CPI. The consequence is that the CPI looks better than reality for the opening months of a package, because earned value is accruing but the matching cost has not yet appeared in the accounts. Then, when the invoices catch up, the CPI drops sharply. Controls teams who interpret this as a sudden deterioration in productivity are misreading the signal; the productivity was always this level, but the cost system was behind the work. A CPI that starts at 1.15 and drifts down to 0.95 over six months has not deteriorated by 20% — it was never at 1.15 in the first place. The fix is to report accrued cost rather than paid cost. Accrued cost includes work in place that has been done but not yet invoiced, based on the contractor's own reporting of incurred cost. Most financial accounting systems support accrual-based reporting, but many controls functions do not receive the accrual data in a timely way because the finance team runs accruals as a month-end exercise and the controls report is produced mid-month. The controls team has to reconcile the gap manually, or the CPI will be systematically optimistic until month-end catches up. The less tractable version of the problem is on lump sum or target cost contracts where the actual cost to the client is the contract value regardless of the contractor's actual expenditure. The ACWP line becomes an artefact of contract valuation rather than a measurement of cost performance, and the CPI loses meaning as a productivity indicator. On such contracts, EVM is better run on internal cost rather than contract value — measuring whether the contractor is burning through their own cost forecast — but this requires access to cost data the contractor may not share. ### Schedule relationships that the SPI ignores The SPI is a cost-based schedule metric. It tells you whether the cumulative value earned is tracking the planned cumulative value over time. What it does not tell you is whether the earned value is on the critical path. A project that is earning plenty of value but doing it on non-critical work — because the critical activities are stuck waiting for design approval, or for a permit, or for a specific subcontractor — can produce an SPI of 1.0 while steadily losing float on the actual completion date. This is the structural weakness of the SPI. It rewards activity, not progress toward the milestone. On a complex programme with dozens of parallel workstreams, the SPI can be comfortable for months while the critical path silently slips. The contractor looks productive, the steering group sees a healthy schedule metric, and then two months before the planned completion date the critical path activities finally begin and the whole project starts reporting red. The contractor has not suddenly lost control; they lost control six months ago, and the SPI failed to show it because it was measuring the wrong thing. The diagnostic is to read the SPI alongside the critical path float trend. If total float on the critical path is falling month on month, the project is losing schedule resilience regardless of what the SPI shows. Some organisations use a schedule metric called SPI(t) — SPI time-based, calculated using the earned schedule method — which addresses part of the problem by expressing progress in time units rather than value units. SPI(t) behaves better than cost-based SPI near the end of a project (cost-based SPI mathematically converges to 1.0 at completion regardless of delay, which is why late projects often finish with an apparently acceptable SPI). But even SPI(t) does not fix the underlying issue that cumulative value is not the same as critical path progress. The rule of thumb is that the SPI is a useful early-warning metric when read alongside the programme, not in place of it. A project with a deteriorating SPI and a shrinking critical path float is in trouble. A project with a healthy SPI and a shrinking critical path float is also in trouble, but the trouble is hidden. Controls leads who report only the SPI without the float trend are not doing the job the steering group needs done. ### Common failure modes on real programmes The most common failure is the one above — reporting headline CPI and SPI in isolation, without the diagnostics that reveal whether the numbers are meaningful. A steering group that receives "CPI 0.98, SPI 1.02" in a monthly pack and does not see the progress verification sample, the material-on-site percentage, the ACWP accrual adjustment, and the critical path float trend is being given assurance that is not justified by the underlying data. The second failure is allowing the work breakdown structure to drift. EVM requires a stable cost-loaded baseline that maps to the schedule and the WBS. On a long-running programme, scope changes, package re-lets, and contract variations all disturb the baseline. If the baseline is re-set every time a variation occurs — "rebaselining" — the CPI resets to 1.0 and the history of cost performance is lost. Some programmes re-baseline quarterly as a matter of course, which makes trend analysis impossible and means the CPI is always close to 1.0 by construction. A well-run EVM system maintains the original baseline and records variations separately, so that the genuine cost performance remains visible. The third failure is running EVM on a contract structure that cannot support it. Some contracts are simply unsuitable for EVM — short-duration works, highly variable scope, research and design contracts where the work content is defined as it proceeds. Forcing EVM onto such contracts produces numbers that look like EVM outputs but do not represent anything meaningful. The controls team ends up defending the methodology rather than using it. Better to accept that EVM is not the right tool for that contract and use a simpler cost-forecast-versus-actual approach supplemented by progress narrative. The fourth failure is sensitive to UK practice specifically: treating the EVM data as contractually privileged rather than a governance tool. Some contractors treat their cost data as commercial-in-confidence and will not share the granular information needed to validate CPI. The client's controls function then has to operate on rolled-up figures and cannot audit the detail. This is a contract structure problem, not an EVM problem, and it has to be fixed at contract award — with explicit obligations on the contractor to provide cost-loaded schedules, monthly cost detail, and access to progress verification. Retrofitting transparency after contract award is almost impossible. ### When to abandon EV and what to use instead Earned value is the wrong tool in several specific situations. Short projects — under twelve months of delivery — rarely generate enough data points for CPI and SPI trends to be meaningful. High-uncertainty scope — research, prototype engineering, contaminated land remediation — produces a baseline that cannot support EVM because the scope keeps evolving. Heavily phased programmes — a framework of sequential small packages — are better reported as package-level performance than aggregated EVM. For these, use simpler methods: cost forecast versus actual, package gate reviews, milestone reporting, or a rolling-wave approach that only baselines detail for the next two to three months. Where EVM is the right tool but the current implementation is unreliable, the path to recovery is not to abandon the method but to restore the disciplines it requires. Rebuild the cost-loaded schedule. Separate materials on site from earned value. Set up accrual-based ACWP reporting. Introduce independent progress verification on a sample basis. Report SPI and CPI alongside the critical path float trend and the material-on-site percentage. Each of these fixes is unglamorous and takes months to embed, but the end state is a reporting system that tells the steering group the truth. The replacement question — "what do I report if I am not reporting CPI and SPI?" — is not as hard as it sounds. A monthly report with three numbers does most of what the steering group needs: cost-to-complete forecast against the approved budget, planned completion date against the contractual completion date, and total float on the critical path. These three numbers, tracked month on month, tell the same story the CPI and SPI are meant to tell, without the structural weaknesses. Add a narrative on the top three risks and the top three issues, and the steering group has a report they can act on. The practical point is that EVM is a technique, not a goal. If the technique is producing misleading numbers, the right response is to fix the technique or to use a different one — not to keep reporting CPI and SPI because that is what the template expects. Controls leads who recognise when their EVM is lying, and have the confidence to say so, earn credibility that no amount of well-produced S-curve reporting can buy. ### Frequently asked questions **What does a CPI below 1.0 actually mean on a project?** A Cost Performance Index (CPI) below 1.0 means the project is getting less earned value from each pound spent than planned. A CPI of 0.85 means only 85p of planned work is being completed for every £1 of actual cost. On its own this signals cost inefficiency, but the cause matters: it could be genuine cost overrun, uninstructed work not put through change control, a baseline that was never credible, or material on site being counted as spend before it is installed and earned. Verify the baseline is sound before acting on a low CPI. **When is CPI an unreliable performance measure?** CPI is unreliable when: physical progress is estimated rather than measured objectively; the performance measurement baseline has not been updated for approved compensation events; materials on site are being earned as if they were installed; or the project is still in its early weeks (CPI has not had enough data points to stabilise). Past the 20% completion point, cumulative CPI tends to be a reliable predictor of final cost performance — early values are much noisier and should not drive major decisions alone. **What is the difference between CPI and SPI?** CPI (EV ÷ AC) measures cost efficiency — how much planned work you complete per pound spent. SPI (EV ÷ PV) measures schedule efficiency — how much planned work you have completed relative to how much was scheduled. Both are dimensionless ratios where values below 1.0 signal underperformance. CPI is the better predictor of final cost at completion. SPI loses reliability late in a project because PV approaches BAC regardless of delivery pace — a nearly complete project always shows SPI converging to 1.0 even if it is significantly delayed. --- ## Integrated Cost-Schedule Risk Analysis — When EMV Isn't Enough URL: https://www.somaprojectcontrols.com/resources/guides/integrated-cost-schedule-risk-analysis Subtitle: Why running cost QRA and schedule QRA separately misses the real exposure, how integrated analysis actually works, and when to recommend it to a client. Published: 2026-04-18 · 11 min read ### Why separate QRAs miss the point Most UK project controls functions run cost QRA and schedule QRA as separate exercises. A cost team builds a probabilistic model of the outturn cost, producing an S-curve and a P80 figure. A schedule team builds a probabilistic model of the completion date, producing another S-curve and a P80 duration. The two outputs are reported to the steering group side by side and treated as independent views of project exposure. This is analytically incorrect and, on programmes of any real complexity, materially understates the true risk. The reason is structural. Schedule delays drive costs. A six-month delay on a major construction programme typically incurs prolongation costs of 10-20% of the planned overrun duration in time-related costs — preliminaries, site staff, plant hire, finance charges, client-side supervision. If those time-related costs are not modelled as functions of the schedule outcome, the cost QRA is ignoring one of the largest drivers of cost exposure. Conversely, cost pressures drive schedule decisions — a contractor running over budget will defer non-critical activities, release resources, or challenge scope, all of which have schedule consequences. Treating the two as independent loses both effects. The technique that addresses this is called integrated cost-schedule risk analysis — QCSRA, or integrated cost-schedule Monte Carlo. It is the standard approach recommended in AACE International Recommended Practice 57R-09, Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model. The name is unwieldy; the idea is straightforward. Build a single simulation in which the schedule and the cost model are linked, and run the Monte Carlo across both simultaneously so that each iteration produces a consistent pair of outcomes — a specific completion date and a specific outturn cost, reflecting the same sequence of risk events. QCSRA is not universally applicable. On small, short-duration projects, the additional modelling effort outweighs the insight. On programmes with stable scope, limited time-related cost exposure, and well-understood risks, separate cost and schedule models are acceptable. The case for QCSRA strengthens as projects get larger, longer, more uncertain, and more exposed to time-related costs. On any major infrastructure programme — transport, utilities, defence (typically anything moving from CADMID Assessment into Demonstration on the MoD lifecycle) — the argument for running an integrated analysis is strong enough that clients should be asking for it by default. ### What QCSRA actually does that separate analyses do not The technical heart of QCSRA is a single Monte Carlo engine that samples from a shared set of risk events and uncertainty distributions, applying the outcomes to both a cost model and a schedule model in the same iteration. This produces three things that separate analyses cannot produce. First, a joint probability distribution of cost and schedule outcomes — you can see, for any given completion date, what the probable range of costs is, and vice versa. Second, a direct measure of time-dependent costs flowing from schedule outcomes. Third, a consistent set of risk scenarios that is the same for both outputs — when the ground conditions risk occurs, it occurs in both the cost model and the schedule model simultaneously. The joint distribution is more than a presentational advantage. It supports real decision questions that separate S-curves cannot answer. "If we want 80% confidence on the completion date, what contingency do we need?" is not answerable from a cost P80 figure, because the cost P80 is the 80th percentile of cost across all schedule outcomes combined. The P80 cost associated with a P80 completion date is typically materially higher than the reported cost P80, because the P80 cost figure is dragged down by the faster scenarios. QCSRA produces both figures and tells you which combinations are plausible. Time-dependent costs are the second major contribution. In a QCSRA model, time-related cost elements — preliminaries, staff, plant, finance — are calculated as a function of the simulated project duration, not as a static cost line. If the schedule iteration produces a 14-month completion, the preliminaries line reflects 14 months. If it produces an 18-month completion, the preliminaries line reflects 18 months. The cost curve shifts accordingly. This is particularly important on projects with high time-related cost content — tunnelling, offshore installation, large process industry work — where the preliminaries component can be 25-40% of total outturn. The shared risk scenarios are the third contribution. In separate analyses, a risk that affects both cost and schedule is modelled twice, with independent probability draws. In reality, if the risk occurs, it occurs for both. Integrated modelling enforces consistency. If the "delayed regulatory approval" risk is sampled as occurring in a given iteration, the schedule feels the delay and the cost feels the associated rework and prolongation in the same iteration. Across thousands of iterations, this produces a correctly correlated view of joint exposure. ### How it works mechanically A QCSRA model has four components. First, a CPM schedule with cost-loaded activities — typically a live Primavera P6 or Microsoft Project file that has been simplified or summarised to the level of detail appropriate for risk modelling. Second, a risk register with probability, impact on cost, impact on schedule, and assigned-to relationships identifying which activities each risk affects. Third, uncertainty distributions applied to activity durations and cost rates, usually as three-point estimates with a triangular or PERT distribution. Fourth, a simulation engine that samples all of the above thousands of times. The simulation mechanics are straightforward. For each iteration, the engine samples every risk (does it occur or not, given its probability?), every duration uncertainty (what is the sampled duration for this activity?), and every cost uncertainty (what is the sampled rate or quantity?). It then runs CPM on the resulting schedule to produce a completion date, and calculates total cost including time-dependent elements based on the resulting duration. Each iteration yields a consistent (duration, cost) pair. After 5,000 to 10,000 iterations, the engine produces the joint distribution and the marginal distributions on each axis. The tools that handle this properly are relatively few. Safran Risk is widely used in UK infrastructure and defence — it is designed around integrated cost-schedule risk and handles time-dependent costs natively. Acumen Risk (now part of Deltek) is the other major tool in this space and is common on US programmes exported to the UK. @Risk, run as an add-in to Primavera or Microsoft Project, can do integrated analysis but requires more manual setup. Oracle Primavera Risk Analysis (PRA, formerly Pertmaster) handles schedule risk well but has more limited cost integration. The choice of tool usually depends on what the organisation already has and what the risk analyst knows rather than any intrinsic superiority. The modelling effort for a QCSRA is substantial. On a typical major infrastructure programme, an initial QCSRA build can take six to eight weeks of a competent analyst's time, with additional time for workshop elicitation, calibration, and stakeholder review. Subsequent updates — typically quarterly — are faster once the model is established, but the build is not trivial. This cost is one of the main reasons QCSRA is less common than separate cost and schedule QRA, and it is also one of the main reasons the separate approach persists on projects where the integrated approach would be more informative. ### Risk drivers versus risk events — and why it matters AACE 57R-09 advocates a specific modelling technique called risk drivers, which differs from the traditional risk event approach used in most risk registers. A risk event is a discrete occurrence — "delayed permit approval" — that either happens or does not happen, with an associated cost and schedule impact. A risk driver is a continuous factor — "permit approval duration" — that has a distribution of possible outcomes and affects multiple activities in a coordinated way. The risk driver approach produces better results on most programmes because it captures the correlation structure of risks more realistically. If permit approval takes longer than expected, it does not just delay one activity; it delays every activity that depends on that approval, and the delays are correlated by the common cause. Modelling this as a risk event with separate impacts on each affected activity loses the correlation. Modelling it as a risk driver that applies a consistent multiplier to all affected activities in each iteration preserves the correlation. In practical terms, a QCSRA using risk drivers starts with a relatively small set of risk drivers — typically 15 to 40 — each mapped to the activities it affects and each with a probability distribution for its impact on cost and schedule. This is often more defensible and more informative than a traditional risk register with 200 discrete events, because the risk drivers correspond to recognisable underlying causes rather than to specific consequences. The transition from a risk-event register to a risk-driver model is not trivial. It requires rethinking the risk register structure and often produces pushback from teams who have invested in the event-based approach. The case for making the transition is strongest on long, complex programmes where the traditional risk register has grown unwieldy and where the structural limitations of independent event sampling are producing implausibly narrow output ranges. Not every project benefits from the change, but for the projects that do, the improvement in model credibility is significant. ### Common mistakes on integrated analyses The most common mistake is building an integrated model that is technically integrated but practically treats cost and schedule as independent. If the time-dependent cost rates are static inputs rather than functions of the simulated duration, the model is producing integrated outputs but not capturing the integrated risk. Check that the preliminaries, site establishment, and staff cost elements in the model respond to schedule outcomes. If they do not, the model is functionally two separate analyses wearing integrated clothes. The second common mistake is inconsistent treatment of risk correlations across the cost and schedule domains. In a well-built QCSRA, a risk that delays an activity by X weeks also drives an associated cost impact — prolongation costs on that activity, knock-on cost impacts on subsequent activities, possibly rework costs. In a poorly built one, the schedule impact and the cost impact of the same risk are defined independently, and the simulation samples them as if they were unrelated. This produces a model that technically simulates both cost and schedule but does not capture the relationship between them. The third mistake is applying the risk-driver approach to a risk register that is not ready for it. A risk driver is meaningful only if the analyst has genuine understanding of the underlying cause and its relationship to project activities. If a risk is translated into driver form without that understanding — for example, renaming "regulatory delay risk" into "regulatory approval duration" without actually re-thinking which activities are affected — the model produces outputs that look sophisticated but rest on the same shallow inputs as before. The fourth mistake is ignoring schedule logic in the cost model. Many cost QRAs are built in Excel with @Risk or similar tools, and the schedule context is represented as a single duration input. This loses the merge bias effects, the path sensitivity, and the sequence dependencies that a CPM-based integrated model captures. Running cost risk analysis without an explicit schedule logic underneath it produces a cost S-curve that is narrower than reality because it does not see the schedule variability correctly. ### Briefing a client on the integrated result The output from a QCSRA is a joint probability distribution, and boards are not comfortable reading joint distributions. The practical approach is to report three things: the marginal cost S-curve, the marginal schedule S-curve, and the joint distribution summary that shows the cost outcome associated with each schedule percentile. The joint summary is the distinctive QCSRA output and the one that typically changes the conversation. The joint summary is most commonly presented as a table: P50 completion date with its P80 cost, P80 completion date with its P80 cost, P95 completion date with its P80 cost. This tells the client that if they want 80% confidence on the completion date (the P80 date), the associated cost is higher than if they only wanted 50% confidence, because the longer simulated durations carry more prolongation cost. The spread between these figures is often 10-20% of total cost, which is material for board-level funding decisions. The recommendation to the client typically follows one of three patterns. If the organisation wants to manage to a schedule target (common on infrastructure programmes with external milestones), recommend contingency sized to the cost at the target schedule percentile. If the organisation wants to manage to a cost ceiling (common on fixed-budget programmes), recommend contingency sized to the cost percentile and accept the associated schedule risk. If the organisation is setting both a cost and a schedule target, be explicit that the joint probability of achieving both may be substantially lower than either individually — a project that has P80 on cost and P80 on schedule typically has P60 or lower on meeting both. The briefing should also be explicit about the modelling assumptions. State the risk drivers used, the correlation structure applied, the time-dependent cost rates assumed, and the iteration count. A board reading a QCSRA output that does not include these facts is being asked to trust a number without context. A board reading the same output with full documentation of assumptions can reason about which assumptions might be wrong and what the sensitivity to those assumptions is. The second version is defensible governance; the first is not. The final point is to calibrate the recommendation to the organisation's risk appetite. HM Treasury Green Book guidance uses P80 as the default confidence level for funding decisions on public-sector programmes. Private-sector clients may prefer P50 for central estimates and P90 for funding ceilings. Infrastructure owners with multi-project portfolios often accept lower per-project confidence in exchange for central portfolio contingency. There is no universal answer, and the QCSRA output supports multiple framings. The controls lead's job is to present the integrated result clearly and let the client make the decision with full sight of the joint exposure. --- ## The Baseline You Can Actually Defend URL: https://www.somaprojectcontrols.com/resources/guides/the-baseline-you-can-actually-defend Subtitle: How to set a controls baseline that survives the project — scope, schedule, cost — and how to tell legitimate rebaselining from commercial cover-up. Published: 2026-04-18 · 11 min read ### What a baseline actually is A project baseline is the reference against which variance is measured. It is not a forecast, a target, or a commitment — it is a snapshot of the agreed plan at a specific point in time, captured in enough detail that later changes can be compared against it. Every project controls function depends on a baseline; without one, there is nothing to be varying from, and every reported number is either a current position or a forecast to completion without context. In UK practice, three baselines are typically distinct but linked: the scope baseline (what is being delivered, usually captured in a Works Information, Employer's Requirements, or equivalent), the schedule baseline (when it is being delivered, captured in the baseline programme), and the cost baseline (what it will cost, captured in the baseline cost plan or contract price). Each has its own documentation, its own change-control process, and its own failure modes. A baseline is only useful if all three are consistent with each other — a schedule baseline that does not reflect the scope baseline is a source of false variances, as is a cost baseline that does not reflect the schedule. The quality of a baseline is tested not at the point it is approved but at the point it is used. A baseline that approved easily may turn out to be brittle under the first serious change event; a baseline that was argued over and stress-tested at approval may absorb significant change and still produce meaningful variance reporting. This guide is about what makes the second kind of baseline and how to produce one on a real programme. ### The scope baseline — where most problems start Most baseline failures begin with the scope baseline. If the scope is not captured in enough detail at approval, every subsequent baseline deliverable — the schedule, the cost, the risk register — is built on uncertain ground. The symptom is scope drift, where the work being delivered quietly expands beyond what was approved without formal change control. The cause is usually a scope baseline that was a high-level description rather than a defined list of deliverables. On an NEC4 contract, the scope baseline is the Works Information (now "Scope" in the NEC4 revision). On FIDIC, it is the Employer's Requirements and the Contractor's Proposals. On JCT design-and-build, it is the Employer's Requirements as developed through the contractor's design. Each of these documents has a defined contractual role, and the scope baseline should be the controlled version of that document at contract award. If the scope baseline references a document that was issued in draft and never controlled, the commercial position is weaker than the project team may realise. The test for a good scope baseline is: can a third party, picking up the documents two years later, reconstruct what was agreed to be delivered? If the answer requires reading design drawings that are not formally referenced in the contract, or relying on email correspondence to establish intent, the baseline is exposed. A defensible scope baseline explicitly lists the controlled documents that form it, with their revision numbers and dates, and references them throughout the cost and schedule baseline so that the linkage is explicit. Scope baseline failures on major UK projects have been the subject of several NAO and IPA lessons-learned reports — and on defence programmes the same pattern shows up in Major Projects Reports, where the requirement document approved at end-of-Concept turns out at the end of CADMID Assessment to have been a description rather than a specification. The repeated theme is that scope was described rather than defined — the project knew what it was building in general terms, but the specifics were expected to emerge during delivery. Specifics that emerge during delivery are not free; they are variations, and without a defined baseline to vary from, the commercial treatment of those variations is opaque. The discipline of capturing scope to a sufficient level of detail at baseline is unglamorous but is the single largest determinant of whether the controls function can produce meaningful variance reporting during delivery. ### The schedule baseline and what makes it brittle A schedule baseline has to be buildable. This is the starting test. A programme that requires more concurrent resources than the site can accommodate, compresses design review cycles beyond what the client's governance will actually support, or relies on supply chain lead times shorter than the market can deliver is not a baseline — it is a wish. The most common reason schedule baselines are brittle is that they were not stress-tested against resources, design cycles, or supply chain realities at approval. The second source of brittleness is artificial constraints. A programme full of hard constraints — dates imposed by the scheduling tool rather than by genuine dependencies — will not respond realistically to change. When a variation lands, the impact analysis cannot propagate through the network because the constraints absorb the change artificially. On NEC4 contracts this is particularly damaging because compensation event assessments depend on the programme's ability to show genuine impact. A constraint-heavy baseline programme produces low or zero assessed impacts on events that in reality are significant, and the contractor has to argue the programme is wrong before they can argue the assessment is wrong. Overoptimistic durations are the third source of brittleness. A baseline that assumes activities take the minimum plausible duration, with no time risk allowance and no weather or access contingency, has consumed its schedule resilience before work starts. The first modest delay blows through to the critical path, and every subsequent event produces knock-on effects disproportionate to their actual size. The NEC4 requirement for explicit time risk allowances is specifically designed to protect against this — TRAs distributed across the programme at points of genuine duration uncertainty produce a more robust baseline than a tight programme that claims no uncertainty. Missing activities are the fourth and hardest to diagnose. A baseline programme that covers the main works comprehensively but omits commissioning detail, handover activities, regulatory approvals, or client review cycles will produce variance every month as those missing activities are added during delivery. The additions look like scope creep but are actually baseline omissions. The best defence is to baseline at a sufficient level of detail that the major delivery phases are all represented, even if the underlying activities are placeholder summary activities that get broken out closer to delivery. A defensible schedule baseline has: resource-aware activity durations, minimal hard constraints, explicit TRAs at points of known uncertainty, full coverage of all delivery phases including commissioning and handover, and a planned completion date that is close to the contractual completion date — with visible protection in the form of TRAs rather than hidden buffer in activity durations. This is harder to produce than a tidy, constraint-driven baseline, and harder to approve because it makes the project's uncertainty visible. It is also the baseline that survives the project. ### The cost baseline — the basis of estimate is the baseline A cost baseline is only as credible as the basis of estimate that underpins it. The basis of estimate — the narrative document explaining how the cost was built up, what rates were used, what assumptions were made, and what was excluded — is the document that makes the cost baseline defensible. Without a documented basis of estimate, the cost figures are numbers on a page with no supporting reasoning, and when cost pressures emerge during delivery there is no reference point to explain what is changing. The basis of estimate should cover three things. First, the quantities — where they came from, how they were measured, what the confidence in them is at the point of baseline (Class 3 estimate, Class 2, etc., per AACE 18R-97). Second, the rates — whether they are historical, market-tested, benchmarked, or budgeted, and what period they relate to. Third, the assumptions and exclusions — what is assumed about scope, what is assumed about execution, what is specifically not covered by the estimate. A baseline without an exclusions list is a hostage to future scope discussions. The second discipline in a cost baseline is separating base cost from contingency. Base cost is the best deterministic estimate of cost to deliver the approved scope under expected conditions. Contingency is the additional provision for risk and uncertainty. The two should be reported as separate numbers, with the contingency supported by a QRA or equivalent analysis. Mixing them — burying contingency inside line-item rates — produces a baseline that the cost team cannot explain when challenged and that risk-based analyses will double-count. The third discipline is consistency with the schedule baseline. Time-related costs in the cost baseline — preliminaries, site staff, plant, finance — must reflect the schedule baseline duration. If the schedule baseline shows 18 months to completion and the cost baseline has 15 months of preliminaries, one of them is wrong. This sounds obvious and is a surprisingly common error, particularly on projects where the cost plan was produced by a different team from the schedule and the two were reconciled only at high level. A defensible cost baseline has: a documented basis of estimate with quantities, rates, and assumptions; separated base cost and contingency with risk-based supporting analysis; time-related costs consistent with the schedule baseline; and a clear date at which the estimate is current, with inflation assumptions from that date forward. These are unexciting practices. They are also what distinguishes a baseline that will hold up under two years of change control from one that will fracture at the first meaningful variation. ### Rebaselining — legitimate versus cover-up Rebaselining is the process of replacing the existing baseline with a new one. It is sometimes necessary and sometimes illegitimate, and the difference is about why it is being done. A legitimate rebaseline responds to a fundamental change in project scope, circumstances, or funding that has made the existing baseline no longer a useful reference. An illegitimate rebaseline conceals poor performance by resetting the comparison so that accumulated variance disappears. The clearest case for legitimate rebaselining is a scope change of sufficient magnitude that incremental change control is impractical. If a programme has been approved to deliver 500 homes and is now being asked to deliver 750 homes plus a community facility, reporting variance against the original baseline would be meaningless — the variance is not a failure of delivery, it is the delivery of a different project. A formal rebaseline documenting the new scope, schedule, and cost is appropriate. Similarly, a funding envelope change imposed by the client, or a major external event (a regulatory change, a force majeure event lasting months), can justify rebaselining if the original baseline has genuinely been overtaken. The illegitimate cases are where rebaselining becomes a tool for hiding accumulated overrun. A project that is six months late and 20% over budget rebaselines to the current forecast, and the performance reporting in the next month shows CPI and SPI at 1.0. The accumulated variance has not gone away — it has been absorbed into the new baseline. If the rebaselining is described as "alignment with current conditions" without acknowledging the underlying cause of the variance, the project has lost the ability to report honestly on its own performance history. The test for legitimacy is what is disclosed alongside the rebaseline. A legitimate rebaseline is accompanied by a document explaining what changed, why the original baseline is no longer useful, and what the variance against the original baseline would be if retained. The old baseline is preserved as a reference; the new baseline becomes the working comparison for future reporting, but the history is not erased. An illegitimate rebaseline quietly replaces the comparison point without acknowledging the previous variance, and the steering group loses sight of how the project has actually performed. Under NEC4, rebaselining has specific commercial implications. The Accepted Programme is the reference for compensation event assessments, and a rebaselined programme replacing the Accepted Programme affects how subsequent events are valued. Rebaselining should only be done through the formal programme submission and acceptance process under Clause 31, not as an informal controls-team exercise. Under FIDIC, the baseline is effectively the Contractor's submitted programme under Clause 8, and rebaselining requires the Engineer's consent. In both cases, informal rebaselining without contractual recognition creates weaknesses that will be exposed if the project goes to dispute. ### Change control — the thing that keeps a baseline honest A baseline without robust change control is not a baseline; it is a historical document. The purpose of setting a baseline is to compare the current position against it, and that comparison is only meaningful if changes to the baseline are documented, controlled, and attributed. On UK programmes, change control typically operates at two levels: contractual change control (compensation events on NEC, variations on FIDIC and JCT) and project change control (internal changes that do not trigger contractual mechanisms but do change scope, schedule, or cost). The common failure is that contractual change control is well-run and project change control is informal. Variations under the contract are documented, assessed, and recorded against the baseline. Internal decisions to expand scope, adjust the schedule, or draw on contingency happen through emails and meetings without a formal change log. Six months in, the accumulated informal changes have materially shifted the project position but cannot be tracked because they were never recorded. The remedy is a single change log that captures both contractual and internal changes, with each change showing its impact on scope, schedule, and cost, and its status (proposed, approved, implemented). The second common failure is change control that records change but does not update the baseline. The change log grows, the changes are approved, and the baseline programme and cost plan remain as originally approved. Reported variance becomes meaningless because it includes both genuine performance variance and approved but unincorporated changes. Changes that have been approved should update the live baseline (sometimes called the "approved current baseline" to distinguish it from the original baseline), with the original baseline retained as a reference for historical comparison. The discipline of keeping both the original baseline and the approved current baseline visible is worth the effort. The original baseline tells the steering group what was approved at the outset and how the project has shifted against that. The approved current baseline tells the operational team what they are currently working to, incorporating all approved changes. Variance reporting should be explicit about which baseline each variance is measured against. Reporting that mixes original baseline variance and approved current baseline variance in a single number without disclosure is confusing at best and misleading at worst. ### What to do on Monday morning If you are setting a new baseline, start with the scope baseline. Confirm the controlled documents that define the scope, document the exclusions explicitly, and make sure the schedule and cost baselines reference the same set of documents. Do not approve a baseline where the scope, schedule, and cost reference different versions of the scope documents — this is the single most common source of downstream confusion. Stress-test the schedule baseline before approval. Check resource profiles against site capacity. Check design cycles against the client's actual review governance. Check supply chain durations against market lead times. Remove hard constraints that cannot be justified by a specific external dependency. Add explicit TRAs at points of known duration uncertainty rather than hiding the uncertainty in activity durations. These adjustments usually extend the planned completion date, and the negotiation to accept that date rather than pretend to an earlier one is the main work of baseline approval. Require a documented basis of estimate for the cost baseline. Separate base cost from contingency. Check that time-related costs are consistent with the schedule duration. Get the contingency number from a risk-based analysis — even a simple one — rather than a percentage uplift, and make the analysis visible to the approval body. A baseline where the contingency is "10% because that's what we always use" is not defensible when the first real risk materialises. If you are inheriting a baseline, audit it against the tests above. A common finding is that two of the three baselines are solid and the third is weak — typically a solid cost and schedule baseline with a weak scope baseline, or a solid scope and cost with a fragile schedule. Document the weakness, flag it to the project sponsor, and propose a strengthening programme that can be executed without rebaselining. Full rebaselining on an inherited project should be a last resort because it obscures the performance history and opens new arguments about what the original commitments were. Finally, treat change control as the priority discipline once the baseline is approved. A well-run change log that captures both contractual and internal changes, with each change's impact on scope, schedule, and cost documented, is what preserves the value of the baseline through delivery. A baseline without change control decays quickly. A baseline with proper change control remains a useful reference until project close, which is the whole point of setting one. ### Frequently asked questions **What is a project baseline?** A project baseline is the reference against which variance is measured. It is not a forecast, a target, or a commitment — it is a snapshot of the agreed plan at a specific point in time, captured in enough detail that later changes can be compared against it. Every controls function depends on a baseline; without one, every reported number is either a current position or a forecast to completion without context. **What are the three baselines a project needs?** A defensible project has three distinct but linked baselines: the scope baseline (what is being delivered, captured in Works Information, Employer's Requirements or equivalent); the schedule baseline (when it is being delivered, captured in the baseline programme); and the cost baseline (what it will cost, captured in the baseline cost plan or contract price). Each needs its own change-control process. A baseline is only useful if all three are consistent — a schedule baseline that does not reflect the scope baseline is a source of false variances. **What makes a schedule baseline brittle?** Four things make a schedule baseline brittle. First, it has to be buildable — programmes requiring more concurrent resources than the site can take, design cycles shorter than client governance supports, or supply chain durations shorter than the market delivers are wishes, not baselines. Second, artificial constraints — hard dates imposed by the tool rather than by genuine dependencies — absorb change instead of propagating it. Third, overoptimistic durations with no time risk allowance consume schedule resilience before work starts. Fourth, missing activities (commissioning, handover, regulatory approvals, client review cycles) produce monthly variance that looks like scope creep but is actually baseline omission. **When is rebaselining legitimate versus a cover-up?** A legitimate rebaseline responds to a fundamental change in scope, circumstances, or funding that has made the existing baseline no longer a useful reference — for example a major scope expansion, a client-imposed funding envelope change, or a force majeure event lasting months. An illegitimate rebaseline conceals poor performance by resetting the comparison so that accumulated variance disappears. The test for legitimacy is what is disclosed: a legitimate rebaseline preserves the old baseline as a reference and documents the variance against it, while an illegitimate one quietly replaces the comparison point without acknowledging the previous variance. **What is a "basis of estimate" and why is it essential?** The basis of estimate is the narrative document explaining how the cost was built up — what rates were used, what quantities were assumed, what was excluded. Without it, the cost figures are numbers on a page with no supporting reasoning, and when cost pressures emerge there is no reference point to explain what is changing. A good basis of estimate covers three things: the quantities (where they came from, what AACE estimate class they reflect — Class 3, Class 2, etc.), the rates (whether historical, market-tested, benchmarked or budgeted, and what period they relate to), and the assumptions and exclusions. **What are the contractual implications of rebaselining under NEC4 or FIDIC?** Under NEC4, the Accepted Programme is the reference for compensation event assessments, and a rebaselined programme replacing the Accepted Programme affects how subsequent events are valued. Rebaselining should only be done through the formal Clause 31 programme submission and acceptance process, not as an informal controls-team exercise. Under FIDIC, the baseline is effectively the Contractor's submitted programme under Clause 8, and rebaselining requires the Engineer's consent. In both cases, informal rebaselining without contractual recognition creates weaknesses that will be exposed if the project goes to dispute. --- ## Primavera P6 for People Who Inherited It URL: https://www.somaprojectcontrols.com/resources/guides/primavera-p6-for-people-who-inherited-it Subtitle: A practical two-hour audit checklist for the PM or planner who has just been handed someone else's P6 database — what to check, what to fix, and what to leave alone. Published: 2026-04-18 · 10 min read ### Why inheriting P6 is different from inheriting any other tool Primavera P6 is the dominant scheduling tool on UK infrastructure and major construction programmes for a reason — it handles multi-project logic, large activity counts, and complex resource loading better than anything else in the market. It is also substantially more configurable than it needs to be for any one project, which means that the P6 database you have inherited carries with it dozens of settings choices made by the previous user, many of which affect how the schedule behaves and most of which will not be documented. The instinct to open P6 and start updating progress is understandable and almost always a mistake. Until you have audited the configuration, you do not know what the scheduling engine will do when you recalculate the schedule. A setting that treats activities as retained logic versus progress override will produce different answers on the same data. A default calendar that is wrong will silently misallocate working days. A leveling configuration that was left on from the previous planner will shift activities based on resource constraints that may no longer apply. None of this is obvious from looking at the activity view. This guide is about the practical audit of an inherited P6 database. It is aimed at the planner, project manager, or controls lead who has been given access to a P6 file and needs to produce a reliable update or a credible review within days rather than weeks. The audit can be done in about two hours if you know what to look for, which is what the rest of this guide covers. ### The default calendar and the scheduling options Open the global calendars view and check the default project calendar. On a UK construction project this is usually a five-day working calendar with UK public holidays and a defined working day of 8 to 10 hours. Verify that the public holidays are actually in the calendar — P6 does not populate them automatically, and a UK calendar that shows Christmas Day as a working day is one of the most common errors on inherited databases. Check that the calendar used as the default is the one you want; P6 allows multiple calendars, and the "default" is whichever one has been marked default in the Enterprise > Calendars view, not necessarily the one most activities are assigned to. Check the project-level calendars. Projects can have their own calendars that inherit from or override the global calendars. Run a report listing every calendar in use on the active project and check that each is defined correctly. Mismatched calendars between activities are one of the hardest-to-diagnose causes of unexpected float behaviour. A common finding is that the project has three calendars — a five-day construction calendar, a six-day intensive calendar, and a seven-day commissioning calendar — and two of the three have different public holidays from each other, producing apparent float inconsistencies when activities span them. Now open the scheduling options (F9, then Options, or via Tools > Schedule > Options). The critical settings are: "When scheduling progressed activities use" — this should almost always be "Retained Logic" for most UK construction work (progress override is appropriate in specific circumstances but produces unexpected results on general scheduling); "Calculate start-to-start lag from" — this is usually "Early Start" and should match the previous planner's approach to avoid shifting activity dates on recalculation; "Calculate float based on finish date of" — usually "Each project"; and the level of effort and milestone settings, which affect how these activity types are treated during scheduling. If you change any scheduling option from the setting used by the previous planner, you will see activity dates move on recalculation, sometimes significantly, and the team may lose trust in the schedule. Note the inherited settings before changing anything. The "Data Date" is the other setting that matters. The data date is the cutoff point between past and future — activities before the data date are considered progressed, activities after are considered future work. An incorrect data date produces nonsense schedule calculations. Check that the data date on the open project matches the reporting period you intend to update against. If the previous planner left the data date at an old value, all your updates will be applied relative to that old date, producing wrong results. ### The baseline situation Baselines in P6 are a frequent source of confusion because P6 allows multiple baselines per project and uses them for different purposes. There is the "Project Baseline" (the approved baseline used for variance reporting), the "Primary User Baseline" (the user's personal reference), and optional "Secondary" and "Tertiary" user baselines. Views that show baseline bars can be configured to show any of these, and the current user's configuration may be showing a different baseline from what the project is supposed to be reporting against. Open Project > Maintain Baselines and check what baselines exist on the project. Note the dates they were created and the names. Ideally there is a single clearly named baseline — "Contract Baseline", or "Approved Baseline 2024-10-15" — which is the authoritative reference. Commonly there are several: "Contract Baseline", "Client Submission", "Internal Target", "Monthly Update Baseline 2024-11", and it is unclear which is the authoritative one. Do not delete any baselines during audit; document what exists and flag to the project sponsor which one is the approved reference. Check which baseline is assigned as the Project Baseline (used for variance reports) and which as the Primary User Baseline (used for your own bar display). If they differ, the variance reports and your visual comparison will show different things, which is a common source of misunderstanding in review meetings. Align them unless there is a specific reason to keep them different, and document the decision. The other baseline question is whether the baseline programme has been updated over time. A baseline that has been "refreshed" every few months — essentially rebaselined quietly — loses its value as a variance reference. Check the baseline creation date and compare it to the contract award date. If the baseline is six months younger than the contract, either there was a legitimate rebaselining event (find the documentation) or the baseline has been overwritten informally (which is a bigger problem than you are likely to fix in the audit). ### Leveling, resource loading, and what they might be doing to your schedule Resource leveling in P6 is the process of rescheduling activities based on resource availability, moving activities where resource demand exceeds resource capacity. If leveling is enabled and is being applied automatically on schedule recalculation, your activity dates are a function of the resource model, not just the logic. This produces non-obvious behaviour — a small logic change can produce a large schedule change because leveling has redistributed resource-constrained activities across the newly available windows. Check whether leveling is enabled on the project. Tools > Level Resources, or check the scheduling options. On most UK construction schedules, leveling is not enabled — the schedule is run on logic alone, and resource constraints are managed separately. If the inherited project has leveling enabled and you do not know why, leave it enabled for the moment but make sure you understand what it is doing before you recalculate. Running the schedule without leveling when the baseline was produced with leveling will shift dates. Check the resource assignments. Are activities resource-loaded? Some UK schedules are heavily resource-loaded (common on major infrastructure where the client requires it); many are not (common on smaller construction where the schedule is essentially a logic model). If resources are loaded, check that the resource dictionary is sensible — unit costs are populated, availability curves are realistic, and the resource types correspond to real categories of labour and plant. Resource dictionaries that have accumulated cruft from previous projects — resources called "TBD" or "Labour_Temp" — suggest the resource loading has not been maintained and may be noise rather than useful data. On multi-project databases (common in P6), check whether the project you have inherited shares resources with other projects in the database. If it does, resource-leveled calculations pull from the combined resource pool, which can produce unexpected behaviour if the other projects have changed since the baseline was set. On single-project EPS, this is not an issue, but on enterprise deployments it is worth checking explicitly. ### Dangling activities, hard constraints, and level-of-effort abuse Run a DCMA 14 check or equivalent on the inherited project. The metrics that matter most on a P6 audit are: the percentage of activities with missing predecessors or successors (target above 95% with both), the number of hard constraints (target below 5% of activities), the use of negative lag (target zero), and the proportion of level-of-effort activities (if excessive, a sign of abuse). Dangling activities — those without a predecessor or without a successor — are one of the two most common structural problems in inherited P6 schedules. Activities with no successor do not drive the completion date, which may or may not be intentional; if the dangling activity is a real deliverable that is needed for project completion, its finish is not being represented in the critical path. Activities with no predecessor can start at any time within the project window, which typically means they start at the project start date (if early start is being calculated from there) and appear to happen immediately. Use the DCMA report to identify dangling activities and assess which are genuine omissions versus intentional structural choices. Hard constraints — "Start On", "Finish On", "Must Finish By", and the "Mandatory Start" and "Mandatory Finish" variants — force activities to specific dates regardless of their logic. A few hard constraints on externally imposed dates (client access dates, regulatory milestones) are legitimate. A programme with dozens of hard constraints has been shaped to produce specific dates and will not respond realistically to changes. Identify every hard constraint and check that each has a documented external reason. Constraints without documentation are candidates for removal or conversion to soft constraints (start no earlier than, finish no later than, which still influence dates but do not override the logic). Level-of-effort activities — P6's mechanism for representing ongoing work such as management, supervision, or monitoring — have specific scheduling behaviour. They are bounded by their predecessor start and successor finish, and their duration adjusts automatically. Overuse of level-of-effort activities is a common abuse: real discrete work is coded as level-of-effort to avoid committing to specific durations. Identify all level-of-effort activities and check that each represents genuine ongoing work rather than hidden task activities. Converting level-of-effort to task activities usually requires breaking the activity into components and re-linking, which is a significant change — flag it in the audit rather than fix it in the same session. Long-duration activities — those over 44 working days — are another DCMA flag. The concern is that long activities mask sub-activities that should be explicit. A 200-day "foundation works" activity hides the sequence of piling, excavation, blinding, reinforcement, and concrete pours that make it up, and delay impact analysis cannot propagate through an opaque block of time. Identify long activities and assess whether decomposition would add value. Decomposition is not a two-hour audit task; it may need to be added to the improvement backlog. ### Common mistakes on inherited P6 databases The most common mistake is recalculating the schedule before understanding the configuration. Pressing F9 on an inherited project commits you to the settings the previous planner left in place, and the new dates become the reference for the next update. If those dates are wrong because the scheduling options were non-standard, you will be chasing variances that are artefacts of your own recalculation rather than real events. The second common mistake is importing the project into a new P6 database without checking the global settings. P6 projects can have project-specific calendars, resources, codes, and custom fields, but they also inherit from the global database. A project imported from one database into another may behave differently because the globals differ — global calendars may not exist in the new database, resource dictionaries may not match, EPS structures may be different. Always import into a controlled environment and verify the project behaves identically to the source before relying on it. The third common mistake is treating the Activity ID and WBS structure as disposable. The Activity IDs in an inherited project are the reference that every external system — cost reports, progress claims, risk registers, earned value data — uses to tie back to the schedule. Renumbering activities to match your preferred convention breaks every external reference. Leave the Activity IDs as inherited unless you are rebuilding the entire reporting ecosystem around them. The fourth common mistake is assuming the summary view (or the bar chart) is giving you the whole picture. P6 defaults to showing a filtered view of activities, and the filter may be excluding activities the previous planner did not want visible — out-of-sequence progress, completed activities, or activities assigned to resources not currently displayed. Remove filters temporarily during audit to see the full activity set. Remove groupings that might hide activity count issues. The view presented to you at file opening is not necessarily a complete view. The fifth common mistake is not exporting the current state before making any change. Before you do anything to an inherited schedule, export the project as a .xer or a .xml file and save it with a clear filename and date. If anything goes wrong during your audit or subsequent work, the exported file is your fallback. P6 has limited undo capabilities and no version control, and an unrecoverable configuration change can lose hours of inherited work. ### A two-hour audit checklist The practical audit, in order. Fifteen minutes: export the project to .xer as a backup. Note the project open settings (project ID, data date, any warnings on opening). Check the active baselines (Project Baseline and Primary User Baseline) and document what they are. Thirty minutes: review the global and project calendars. Verify the default calendar is correct, UK public holidays are populated, and the calendars assigned to activities are consistent. Open the scheduling options (F9 > Options) and document every non-default setting. Note the retained logic vs progress override setting in particular. Thirty minutes: run a DCMA 14 or equivalent check. Review the results for logic density, hard constraints, negative lag, long durations, and dangling activities. Identify the top five structural issues to investigate further. Check the critical path — does it make sense against the project narrative? Fifteen minutes: review resource and leveling configuration. Is leveling enabled? Is the project resource-loaded? Is the resource dictionary clean? Are there multi-project resource dependencies? Fifteen minutes: review Activity ID structure, WBS, and activity codes. Confirm the structure matches the reporting ecosystem (cost reports, progress claims). Check for orphan activities that are not in the main WBS structure. Fifteen minutes: write the audit note. Two pages maximum: what the schedule is, what state it is in, what the priority issues are, what should be fixed before the next update, and what should be flagged to the project sponsor. This note is the handover artefact that justifies any changes you make to the schedule in the subsequent updates, and it is also the reference that protects you if the schedule is later challenged. On Monday morning: do not update the schedule before completing this audit. The time investment of two hours up front prevents the larger investment of unpicking confused update data later. Planners who skip the audit step and go straight to updating inherited schedules tend to produce inherited problems compounded by their own new ones; planners who invest in the audit produce schedules that other people trust. --- ## Project Controls Maturity — What "Good" Actually Looks Like URL: https://www.somaprojectcontrols.com/resources/guides/project-controls-maturity-what-good-looks-like Subtitle: A practical view of what a well-run controls function looks like on a real programme — single source of truth, monthly cadence, honest reporting — without the five-level pyramid. Published: 2026-04-18 · 10 min read ### Why maturity models usually fail Most project controls maturity models are sold as five-level pyramids. Level 1 is "initial" or "ad hoc" (undefined processes, reactive behaviour), level 5 is "optimising" or "world-class" (metrics-driven, continuously improving), and the three middle levels follow a plausible-sounding progression. The framework looks rigorous in a presentation deck and produces a score out of five that leadership can benchmark against. It also systematically fails to describe what good actually looks like on a real programme, which is why mature organisations quietly ignore these assessments and get on with the work. The failure mode is that maturity at the controls function level is not a single dimension. A team can have world-class cost reporting, mediocre risk management, and non-existent benefits tracking, and the five-level framework averages these into a misleading single number. More importantly, the framework rewards process compliance over outcome quality. A team that fills in every template and holds every meeting scores well regardless of whether the outputs are telling the steering group the truth about the project. A team that produces lean, honest reporting that drives actual decisions may score lower because it has "skipped" formal steps the framework expects. This guide takes a different approach. It describes the observable characteristics of a well-run controls function on a live programme — the things you can see if you walk into the controls room, attend the monthly review meeting, read the pack, and ask the team a few direct questions. These characteristics are not a scoring system; they are a diagnostic. If several are present, the function is working well. If most are absent, there is a problem regardless of what any maturity model says. ### A single source of truth that people actually use The first and most important characteristic is a single source of truth for project data — the schedule, the cost plan, the risk register, the progress data — that everyone on the project refers to. This is the hardest thing to achieve and the most common point of failure. The symptom of failure is well understood: three different numbers for the same metric in circulation at the same time, depending on which team produced them and when. The steering group spends the first fifteen minutes of each meeting arguing about whose numbers are correct rather than discussing the project. The solution is not primarily technical. It is organisational. A single source of truth exists when there is a named owner for each data set (the planner owns the schedule, the cost engineer owns the cost data, the risk manager owns the register), a defined cadence for when each data set is updated, and a ruled-off process that ensures no one reports from a different version. The tooling is secondary — a well-run controls function can operate with a single Excel workbook if the discipline is in place, and can fail with a full Primavera and Deltek ecosystem if the discipline is not. The practical test is to ask three people on the project — the PM, the cost lead, the risk lead — what the current EAC is, and compare their answers. If they match within a few percent, the function has a single source of truth. If they differ by 10% or more, or if they disagree about which figure is the "real" one, the function does not. This test takes thirty seconds and is more informative than most maturity assessments. The second practical test is to ask what the most recent approved baseline is and when it was approved. A controls function with a single source of truth will have a clear answer — "the approved baseline is revision 3, approved 2024-11-15, with change control log up to variation 47." A function without will have an unclear answer, or several people will give different answers. Again, the test is fast and the signal is clear. ### A monthly cadence that holds under pressure A well-run controls function has a monthly cadence that produces reliable, timely reporting without heroic effort. The reports are out within five working days of month-end. The progress data is captured through a defined process by defined people on defined dates. The variance analysis is done. The risk register is updated. The forecast is refreshed. The steering group pack is produced, reviewed, and delivered. All of this happens every month without the controls team working weekends to achieve it. The failure mode is a cadence that works in calm periods and breaks under pressure. When the project is running smoothly, the reports come out on time and the data is reliable. When the project hits a difficult month — a major variation, a delay event, a cost overrun — the reporting stretches from five days to two weeks, the variance analysis becomes selective, and the pack delivered to the steering group is incomplete. The irony is that the months when reporting is most under pressure are the months when reporting matters most. A function that cannot sustain cadence under pressure is not providing the governance support it exists for. The practical indicator is the timeliness of reporting over the last six months. If four out of six monthly packs were delivered within the target timeline and two were late, the cadence is marginal and will break under further pressure. If six out of six were on time, including the difficult months, the cadence is solid. If the function cannot produce the timeliness data at all — because nobody tracks it — the cadence discipline is probably weaker than claimed. The Infrastructure and Projects Authority (IPA) gateway process on UK major projects provides an external cadence forcing function. Major public-sector programmes — including everything on the Government Major Projects Portfolio and most MoD CADMID Demonstration-phase contracts — go through gateway reviews at defined points, and the controls evidence must be in a deliverable state for those reviews. Programmes that rely on gateways to force their reporting discipline rather than running it routinely are vulnerable between gateways, when the external pressure drops. ### Risk integrated, not parked A well-run controls function has risk integrated with cost and schedule, not parked in a separate workstream that produces its own reports and occasional workshops. The risk register is read alongside the forecast. The QRA or qualitative risk analysis feeds the contingency discussion. The top risks are visible on the steering group pack. The risk owner names are real people who can be asked about their risks in the monthly review. The failure mode is risk-as-compliance. The risk register exists, is technically maintained, and produces a monthly summary for the steering group pack. But the cost forecast is produced independently of the risk analysis, the contingency number is an organisational convention rather than a risk-based calculation, and nobody in the room could name the top three risks without looking them up. The function is technically compliant with risk process requirements and substantively not integrating risk into decision-making. The practical test is the contingency question. Ask the cost lead how the current contingency figure was derived. A well-integrated function will answer with reference to a recent QRA, the top risk drivers, and a defined confidence level. A poorly integrated function will answer with a percentage uplift ("10% because that's what we always use") or a vague reference to "risk allowance" without analytical basis. The answer reveals whether risk is driving cost decisions or simply being reported alongside them. APM's body of knowledge and AACE Recommended Practice 57R-09 both treat integrated risk analysis as a core capability of mature project controls, not an optional extra. The gap between the APM/AACE standard and what is actually done on many UK programmes is one of the largest differentiators between good and mediocre controls functions. ### Named owners, honest variance reporting, and real decisions A well-run function has named owners for every significant data item. The schedule has a named planner. The cost plan has a named cost engineer. Each risk has a named risk owner who is a real person on the project, not the risk manager by default. Each variation has a named commercial lead. The named ownership means that when questions arise, there is a specific person to ask, and when data is wrong, there is a specific person who is accountable for fixing it. Distributed responsibility where nobody specifically owns a given item is the usual failure mode, and it produces data that nobody has authority to stand behind. Honest variance reporting is the second marker. Variance between plan and actual is reported with explanation, not with PR framing. "The cost forecast has increased by £2.3m due to three factors: £1.1m from unforeseen ground conditions (compensation event notified), £0.8m from a scope change in the mechanical package (CE45 approved), and £0.4m from inflation on structural steel (reflected in revised rates)." That is an honest variance narrative. Compare to "costs are tracking within expected tolerances subject to ongoing commercial discussions" — the second version sounds reassuring and says almost nothing. Real decisions in the steering group is the third marker. A well-run controls function produces reporting that drives decisions — approval of a variation, direction to resolve a risk, acceptance of a change in forecast, confirmation of a contingency drawdown. The steering group session is working through decisions, not reviewing information. A function that produces reporting the steering group passively notes, without calling for decisions, is not using the reporting effectively. Either the reporting is not surfacing the decisions that need to be made, or the governance structure is not willing to make them, and both are problems. The practical indicator is the decision log from the last six steering group meetings. A mature function's steering group makes several substantive decisions each month — approvals, directions, endorsements, escalations. An immature function's steering group makes few decisions, or the decisions are process-oriented ("agreed to receive further information") rather than substantive. The decision log is usually a more honest indicator of the function's health than the reporting pack itself. ### What poor maturity actually looks like Poor maturity is not the absence of process; it is the presence of process that does not produce honest information. Weak controls functions often have comprehensive documentation — process manuals, RACI charts, template packs, training materials — and produce voluminous monthly reports that meet every formal requirement. They also fail to tell the steering group the truth about the project, which is what the function is supposed to do. The symptoms are specific. Reports are long — 40 pages and up — because everything is included to demonstrate completeness, and the essential messages are buried. RAG ratings are inflated — projects that are actually in trouble are rated amber, and amber becomes the default because green feels complacent and red triggers governance escalation nobody wants. The forecast line in the monthly report is stable across many months, which in a live project with real change is implausible and usually reflects a forecast that is not being challenged rather than a project that is genuinely stable. Risk register entries are vague — "stakeholder alignment challenges" rather than "the planning authority has objected to the revised facade design, which will delay submission by 6-8 weeks and require redesign of the structural connections." The first is rotational filler; the second is a real risk that a reader can act on. Risk registers full of the first kind of entry are common and tell you that the risk process is being performed rather than the risk being analysed. Change control is performative rather than substantive — variations are processed through the log but the baseline is not updated, or variations are approved at a volume that suggests scope drift is being normalised. Progress measurement is done by the contractor without independent verification. Variance analysis is selective — good variances are explained, bad variances are described in general terms. The function is compliant with every requirement and failing at its actual purpose. ### Benchmarking honestly and what to do on Monday morning A practical benchmarking approach uses a small number of observable characteristics. Ask five questions on a live project. One: what is the current EAC, and do the PM, cost lead, and risk lead agree to within a few percent? Two: when was the last monthly pack delivered, and was it within five working days of month-end? Three: how was the current contingency derived, and is the explanation analytical or conventional? Four: name the top three risks — does the answer come promptly and specifically, or slowly and generically? Five: show me the decision log from the last three steering group meetings — is it substantive or procedural? Five questions; ten minutes. The answers benchmark the function more reliably than most formal assessments. If you are running a controls function and want to improve its maturity, start with the single-source-of-truth discipline. Define who owns each data set, establish a monthly ruled-off process, and refuse to allow multiple versions in circulation. This is unglamorous and organisationally expensive — it requires telling people they cannot use their own preferred figures — but it is the foundation that everything else builds on. Without it, improvements elsewhere will be diluted by inconsistent data. Second, integrate risk with cost and schedule. If risk is run as a separate workstream with its own register and its own monthly summary, pull it into the main reporting cadence. Make the top risks visible in the steering group pack. Derive contingency from the risk analysis rather than from convention. This usually requires some initial investment in QRA or equivalent analytical capability, but it transforms the quality of cost reporting. Third, attack report length. A function delivering 40-page monthly packs is not giving the steering group better governance; it is hiding the essential messages under volume. Aim for a one-page executive summary, a five-page main pack covering the key metrics and variance, a risk section with the top risks named, and a technical annex for anyone who wants the detail. The reduction in length is usually accompanied by an improvement in message clarity, because forcing brevity requires editorial decisions that expose which messages matter. Finally, measure the function against outcomes, not process. A function that hits its process milestones but does not produce honest reporting is failing its purpose. A function that produces honest reporting is succeeding even if some process steps are informal. The APM Body of Knowledge, AACE standards, and IPA gateway requirements all describe process expectations, but the expectation behind the process is that it produces useful governance support. Functions that remember the purpose tend to become mature; functions that optimise for process without it tend not to. --- ## Reporting That Actually Gets Read at Steering Group URL: https://www.somaprojectcontrols.com/resources/guides/reporting-that-survives-steering-group Subtitle: Why most controls reports are ignored, what an effective monthly pack looks like, and how to calibrate to the audience without diluting the message. Published: 2026-04-18 · 10 min read ### Why most controls reports are ignored The typical monthly controls report on a major UK programme is between 30 and 80 pages, takes the controls team 40-60 hours to produce, arrives in the steering group inbox two days before the meeting, and is read in full by nobody. The chair skims the first page on the way to the room. Two or three members read the section they are responsible for. Most of the pack is not referenced during the meeting. The effort-to-impact ratio is terrible, and the function producing it is producing governance evidence rather than governance support. The reasons are well understood. Controls teams under reporting pressure err toward comprehensiveness — include everything so nothing is missed — which produces length without focus. Teams under political pressure err toward defensiveness — soften the language, inflate RAG ratings to avoid escalation, bury difficult findings in technical sections — which produces length without clarity. Teams operating under tight timelines err toward reuse — template sections that change little month to month — which produces length without fresh content. The combination produces the pack that nobody reads. The fix is not obvious because the pressure to produce long comprehensive packs is real. Leadership teams expect to see "what the controls function has done"; auditors expect evidence trails; operational teams want their area covered. The controls function that shortens the pack risks being accused of skipping the work. And yet the pack that is read and acted on is shorter than the pack that is produced, and the function that accepts this trade-off — and educates its sponsors about it — produces better governance than the function that does not. This guide is about how to produce a steering group pack that actually gets read. The structure that follows is not a template; it is a design that has worked on real programmes when implemented with discipline. The key insight is that length is the enemy, and the function that defaults to brevity under pressure is more effective than the function that defaults to inclusion. ### The one-page executive summary Every effective steering group pack opens with a one-page executive summary. One page. Not two, not three — one. The discipline of limiting the summary to a single page forces the editorial decisions that expose what matters. A two-page summary contains more information; a one-page summary contains only the information the steering group needs to act on, which is usually a much smaller subset. The structure of the one-page summary should be: a two-sentence project status statement (overall health and the headline position), three to five KPIs with current values, a short variance narrative for each KPI that is off plan, the top two or three risks the steering group should be aware of, and one to three specific decisions requested from the steering group. That is the entire page. If you cannot fit the project state into that space, the state is probably not being communicated clearly, and the pressure to cram more in should be redirected into better editorial choices. The variance narratives are where most summary pages fail. A line that reads "cost forecast £148m against plan £142m" is not a variance narrative — it is a variance number. The reader has to work out what it means. A line that reads "cost forecast £148m (plan £142m, +4.2%): £4.5m from approved variations (CEs 34-41), £1.5m from unbudgeted temporary works — contingency drawdown recommended, see decision item 2" is a variance narrative. The reader understands why the figure has moved and what the steering group is being asked to do about it. The decisions section is where many packs stumble. Controls teams are sometimes reluctant to frame items as decisions because they do not want to force an escalation or create a political moment. The effect is a pack that presents information without calling for action, and a steering group that notes the information without making a decision. If the controls function has identified an issue that requires steering group action, the one-page summary should say so explicitly. "Recommendation: approve drawdown of £1.5m from contingency to cover unbudgeted temporary works." That is a decision request. A steering group that receives clear recommendations makes decisions; a steering group that receives unframed information does not. ### The five KPIs that matter Effective steering group reporting uses five or fewer headline KPIs. More than five and the reader cannot hold the whole picture in their head; fewer than three and the picture is too coarse to support decision-making. The specific choice depends on the project, but the common structure across UK major programmes is: cost (EAC versus approved budget, with trend), schedule (planned completion versus contractual completion, with trend), contingency (current provision and drawdown status), risk exposure (current P80 or equivalent, with trend), and one project-specific KPI that matters in this particular programme (safety performance, commissioning readiness, consent approvals). Each KPI has a current value, a trend arrow, and a RAG or equivalent status. The trend is often more informative than the value itself. A cost forecast 2% above plan and declining is a different signal from a cost forecast 2% above plan and rising. The steering group needs both pieces of information to reason about the project trajectory. Presenting only the current value loses the trajectory information and makes the report harder to act on. The RAG rating deserves specific discipline. A well-run function uses RAG to mean something — green is on plan and expected to remain so, amber is a material issue that requires attention, red is a critical issue that requires immediate intervention. RAG inflation — where amber becomes the default because green feels complacent and red feels escalatory — destroys the usefulness of the rating. A pack in which nothing is ever green is not reporting project health; it is reporting team anxiety. A pack in which the same items are perpetually amber is not reporting project status; it is reporting that the categorisation has lost meaning. The counter-discipline is to use green when things are actually on plan, and to use red when an issue genuinely requires urgent attention. This requires a team culture that does not penalise amber and red ratings — because if reporting red creates political problems for the controls team, the rating will drift toward amber regardless of reality. The sponsor has to actively support honest rating, which means responding to red ratings with investigation rather than blame. The five-KPI structure also supports trend analysis across months. A pack that shows the last six months of each KPI alongside the current value lets the steering group see whether the project is improving, stable, or deteriorating. Trend data is one of the highest-value additions to a controls report and is often missing because the pack is produced as a snapshot rather than as part of a time series. ### Variance narrative — honest, not defensive The main body of an effective pack is the variance narrative. The structure is: for each significant variance (cost, schedule, scope, risk), explain what has changed, why, and what is being done about it. Three sentences per variance is usually enough. A pack with ten significant variances needs thirty sentences of narrative, which fits comfortably on two pages with room for supporting data. The honest version names specific causes and specific owners. "The mechanical package forecast has increased by £1.8m due to redesign of the ventilation system following updated Part F compliance requirements. The redesign was completed in February and the procurement impact is now clear. James Reid (mechanical package lead) is managing the supply chain response." That is usable information. The defensive version says "the mechanical package is subject to ongoing commercial review pending finalisation of regulatory requirements" — which says nothing, names no-one, and gives the reader no basis for follow-up. The passive voice is a reliable indicator of defensive writing. "Costs were incurred due to unforeseen circumstances" conceals agency and responsibility. "The ground contractor encountered harder rock than the site investigation indicated, which added £650k to the bulk excavation cost" names what happened. Controls teams writing variance narrative should consciously check for passive constructions and rewrite them in the active voice. This is not a stylistic preference; the passive voice systematically obscures accountability and is the default register of reporting that has lost trust. Difficult variances should not be buried in technical sections. If the project is materially behind schedule or over budget, that should appear in the executive summary and in the main variance narrative, not in a sub-section of an annex. Burying difficult information is sometimes deliberate and sometimes unconscious, but the effect is the same — the steering group does not see it clearly, does not discuss it, and does not act on it. The function that brings difficult information forward to where it will be seen is doing its job better than the function that technically includes it where nobody will find it. A final note on accuracy. Variance narrative must be factually correct. "The delay is caused by the client's slow approval of the revised design" when the actual cause is shared between client and contractor positions, or is genuinely unresolved, is defensible only if the evidence supports it. Controls teams that overstate contractor issues to client sponsors, or overstate client issues when reporting internally in contractor organisations, produce reporting that is politically convenient but analytically wrong. The cost is trust — once a reporting function is seen to be partisan, every subsequent narrative is read with suspicion, and the governance value collapses. ### Three risks, one decision The risk section of an effective pack covers three risks — the three that the steering group needs to be aware of this month, not the whole register. Three is the right number because the steering group cannot meaningfully absorb more in the time available. If the risk manager insists all 47 risks on the register are equally important, the risk manager is not doing the prioritisation that risk management requires. Choose three. Explain them. Move on. For each risk, the summary should cover: what the risk is, in specific terms (not "stakeholder risk" but "objection from the planning authority to the revised facade design, which could delay submission by 6-8 weeks"); the current probability and impact, briefly; what is being done to manage it; and what the steering group is being asked to note, decide, or escalate. The four points fit on a line or two each. A pack with three risks covered at this level uses about half a page for the entire risk section. The decision request at the steering group should be specific. "The steering group is asked to note the risks" is not a decision — it is a ritual. "The steering group is asked to approve the drawdown of £1.5m from contingency to fund temporary works" is a decision. "The steering group is asked to endorse the proposed revision to the commissioning strategy" is a decision. If the monthly report contains no decision requests, the steering group is being used as an audience rather than as a governance body, and the controls function is partly responsible. The limit of one or two decision requests per month is a discipline worth holding. Steering groups can make two or three decisions meaningfully in a session. A pack requesting eight decisions will produce three actual decisions and five items deferred to the next month. Controls teams that accumulate deferred decisions in the pack over several months are producing a pack that represents governance backlog rather than governance progress. Choose the decisions that actually need to be made this month, and frame them clearly. Defer the rest to the months when they are genuinely ready. ### Anti-patterns — what to stop doing The colour explosion. A pack in which every KPI, risk, and variance is rated on a five-colour scale with supporting heat maps, traffic lights, and emoji equivalents looks sophisticated and communicates less than a black-and-white pack with clear text. Colour is a powerful focal device; overuse dilutes it. Use RAG sparingly and for the few status indicators where it adds value. Avoid colour as a design flourish. The trend chart with no analysis. A line chart showing the EAC rising over twelve months, with no commentary on why it is rising or what is being done about it, is data without information. Every chart should have a title that states the fact, and at least one line of commentary explaining the pattern. Charts without commentary are filler, and filler is the enemy of a report that gets read. The update that is not an update. Entries that read "milestone tracking on plan" or "commercial activities continuing as planned" have the grammatical shape of updates without the content. If a section has nothing new to say, say "no change since last month" and move on, rather than padding with status reassurances. Blank space is better than content-free updates; it makes the pack shorter and signals that the team is reporting substance rather than producing volume. The buried headline. The single most important thing in the pack should be in the first line of the executive summary, not on page 28 of the risk annex. If the cost forecast has moved materially, that is the headline. If the completion date has slipped, that is the headline. A pack that puts decorative summary language first and substantive news last is structured badly. Headlines go at the top, always. The apologetic RAG rating. If a KPI is genuinely red, the RAG rating should be red, and the narrative should explain why and what is being done. A pack that rates things amber because "we do not want to alarm the steering group" or rates things green because "we are working on the amber items" is producing RAG that does not correspond to project state. The sponsor needs to know the truth; the steering group needs to know the truth; the controls function exists to tell them. Apologetic ratings defeat the purpose. The pack that arrives 24 hours before the meeting. Even the best pack produces no value if the steering group members do not have time to read it. The target for distribution is three to five working days before the meeting. Packs that arrive late — because the team is still polishing, or waiting for late data — systematically get less engagement than packs that arrive on time. Quality that arrives late is functionally lower quality than reasonable quality that arrives on time. ### Calibrating to the audience The one-page summary plus main pack structure described above is aimed at a steering group — senior stakeholders, typically with limited time, expecting decision-oriented reporting. Different audiences need different packs, and the mature controls function produces audience-calibrated reporting rather than a single pack for all purposes. For a project board (more senior than a steering group, usually reviewing a programme rather than a project), the one-page summary is often enough on its own, with the main pack retained as an annex for reference. Project boards want portfolio context, strategic issues, and major decisions; they do not want operational detail, which is the steering group's job. For an operational working group (more junior and more detailed than a steering group), the pack is longer and more granular — specific package-level variances, detailed risk log entries, change control detail. The one-page summary is still useful because it preserves context, but the main body expands significantly. For a client review (external stakeholder on the client side), the pack may need to exclude contractually sensitive material, present differently structured cost information, and emphasise areas the client has asked for. This is not dishonest reporting — it is appropriate tailoring to the audience's legitimate interests and governance role. The underlying data should be consistent across all packs, but the framing and selection should reflect what each audience needs to know. For a gateway review (IPA gateway on UK public-sector major projects, an MoD CADMID Main Gate Board, or equivalent on private projects), the pack is fundamentally different — it is a point-in-time assessment against gateway criteria rather than a monthly operational report, and it follows a prescribed structure. The monthly cadence should produce the data that supports gateway reviews, but the gateway pack itself is a separate artefact. The common discipline across all of these is clarity of purpose. What is this pack for? Who will read it? What decisions does it support? A controls function that answers these questions for each of its reporting artefacts — and produces packs that match the answers — produces reporting that gets read. A function that produces the same pack for every audience, regardless of context, produces reporting that is politely received and rarely acted on. The second failure mode is by far the more common, and the one the discipline above is designed to prevent. --- ## NEC4 Early Warnings — Clause 15, Risk Reduction Meetings, Early Warning Register URL: https://www.somaprojectcontrols.com/resources/guides/nec4-early-warnings-the-mechanism-most-teams-waste Subtitle: Clause 15 and 16 under NEC4 — what triggers an early warning, how the Early Warning Register sits alongside the Accepted Programme, risk reduction meeting mechanics, and why early warnings are a protection tool rather than an admission of failure. Published: 2026-04-18 · 10 min read ### What early warnings are supposed to do Early warnings are the most distinctive feature of the NEC contract family and one of the most consistently underused. Under NEC4, the mechanism is set out in Clauses 15 and 16. Clause 15 requires each party to notify the other as soon as they become aware of any matter that could increase the total Prices, delay Completion, delay meeting a Key Date, or impair the performance of the works in use. Clause 16 governs the risk reduction meeting, which is the forum where the parties discuss the notified matters and agree what to do about them. The mechanism is designed to surface problems early, jointly, and in a structured way. The design intent is preventative. By requiring notification as soon as a party becomes aware of a risk, NEC4 puts the parties in a position to discuss the matter before it becomes an entrenched commercial problem. The risk reduction meeting provides a structured forum for that discussion, separate from the operational project meetings and focused specifically on forward-looking risk rather than current status. Clause 16.3 lists what the meeting is for: considering how the matter can be avoided or reduced, seeking solutions that benefit both parties, deciding the actions to be taken and by whom, and recording the decisions in the Early Warning Register. The Early Warning Register — previously called the Risk Register in NEC3 — is the documented record of everything notified and the actions agreed against each entry. It is a live document, updated after each risk reduction meeting, and it is visible to both the Project Manager and the Contractor throughout the project. It is not a static artefact produced once and forgotten; it is the running ledger of joint risk management under the contract. What actually happens on many NEC4 contracts is different. Early warnings are notified reluctantly, often only when the event has already occurred and the notification is covering the notifying party's contractual position. Risk reduction meetings are held if at all, typically as an agenda item in the monthly progress meeting rather than as a separate forum. The Early Warning Register is maintained as a formal document but rarely referenced in decision-making. The mechanism is followed procedurally but not used substantively, and the commercial and schedule benefits that NEC4 intended are largely lost. ### What counts as an early warning Clause 15.1 is broader than most teams treat it. The clause requires notification of any matter which could increase Prices, delay Completion, delay meeting a Key Date, or impair performance of the works in use. The word is "could", not "will". Any matter that has a real possibility of producing one of these effects should be notified, regardless of whether the effect has actually occurred, and regardless of which party is responsible for the underlying cause. This is wider than most contractors assume. A supply chain issue that the contractor has become aware of, and that could delay a specific activity, is an early warning — even if the contractor believes they can mitigate it. A design query that is taking longer than expected to resolve, and that could affect a downstream activity, is an early warning — even if it has not yet caused delay. A regulatory change announced by government, which could require rework on compliance elements, is an early warning — even before the specific impact has been assessed. It is also wider than most project managers assume. Client-side decisions that could trigger compensation events — design changes under consideration, access issues being negotiated, deferrals being discussed — are early warnings that the client (through the Project Manager) should notify. The obligation is symmetrical. Project Managers who treat early warnings as something contractors do and clients receive have misread the contract. A PM who is aware of a matter that could cause a compensation event and does not notify it early is in breach of Clause 15.1, with the same consequences as a contractor in the same position. Some matters are explicitly not early warnings. Risks that are listed in the Contract Data part one — employer's risks — are not events the contractor needs to notify as early warnings if they arise in expected ways. Events that have already occurred and have already had their effect are compensation events (if they fall within Clause 60.1) rather than early warnings. The test for early warning is prospective: something that could happen, or has started to happen but whose full effect is still to come. Retrospective notification of an event that has already completed its impact is a compensation event notification, not an early warning. The time bar is "as soon as" — Clause 15.1 says each party notifies the other as soon as either becomes aware. There is no explicit number of days. The practical interpretation is that delay in notification, once the notifying party became aware, will be evidence that the mechanism was not followed properly. On disputes, tribunals and adjudicators have consistently taken a strict view: if a contractor was clearly aware of a matter in March and did not notify it until June, that three-month delay is itself a breach of Clause 15.1, with the consequences discussed below. ### Running an effective risk reduction meeting The risk reduction meeting under Clause 16 is where the early warning mechanism delivers its value. Clause 16.1 requires either party to instruct the other to attend a risk reduction meeting, with the meeting held at a time and place chosen by the instructing party. The meeting must consider how to avoid or reduce the effects of the notified matters, and the outputs must be recorded in the Early Warning Register. The practical design of an effective meeting looks like this. It is held separately from the operational progress meeting, not as an agenda item within it. Combining the two means the risk discussion is rushed, dominated by current-issue firefighting, and produces shallow outputs. Separating them gives the risk meeting the time to produce substantive actions. The frequency is usually monthly, sometimes fortnightly on fast-moving projects. Attendees are the Project Manager, the Contractor's representative, and subject matter experts for the matters on the register. Senior commercial personnel should be available but not dominant; the meeting is about risk mitigation, not commercial positioning. The agenda is: review of the Early Warning Register; discussion of new matters notified since the last meeting; discussion of matters where actions from the last meeting have not progressed; forward look at anticipated matters; agreement of actions against each item, with owners and target dates; update of the Early Warning Register. The meeting should produce a revised register at the end, not just a set of minutes. The register is the working document; the minutes are supporting. The culture of the meeting matters. An effective risk reduction meeting is collaborative and problem-solving in tone. The parties are looking for mitigations that benefit both, as Clause 16.3 requires. A meeting that devolves into commercial positioning — "that's a contractor responsibility", "that's a client issue", "we don't accept that's a risk" — is not delivering the benefit the clause intended. The clause specifically says the meeting should seek solutions that will bring advantage to both parties; that is the tone that should be set, and Project Managers who chair the meeting have responsibility for setting it. Common failures in running the meeting: senior leaders who only attend quarterly and dominate when they do, changing the tone and the outputs; failure to close out actions from previous meetings, so the register accumulates stale entries; treating the register as a record rather than a live document, with entries that have not been updated for months; and conflating the risk reduction meeting with the risk register update for governance purposes, which produces procedural reporting rather than substantive discussion. The meeting is a working session, not a reporting forum. ### The consequences of failure to notify Failing to give an early warning has specific contractual consequences under NEC4, and they are more significant than most parties appreciate until they matter in a dispute. The key provisions are Clauses 61.5 and 63.7 (numbering varies slightly by NEC4 form), which set out what happens to compensation event assessments where the contractor should have given early warning and did not. Clause 61.5 provides that the Project Manager may, when notifying a compensation event, state that the Contractor did not give an early warning which an experienced contractor could have given. If the Contractor disputes this, the matter can be referred under the dispute resolution procedures. Clause 63.7 (63.5 in some forms) then provides the substantive consequence: if the Contractor did not give an early warning which an experienced contractor could have given, the compensation event is assessed as if the Contractor had given the early warning — meaning the assessment excludes the additional impact that could have been avoided if the early warning had been given when it should have been. The effect can be significant. If a contractor identifies a supply chain delay in February that would, if notified, have allowed a reduction in impact through alternative sourcing, but does not notify until May when the alternative is no longer available, the compensation event assessment in May can be reduced to reflect what the impact would have been had the early warning been given in February. The contractor bears the cost of the difference — which is the cost of their own failure to notify. The reverse case applies to Project Managers. A Project Manager who fails to give early warning of a matter the client is aware of — a likely design change, an access restriction, a regulatory development — is in the same breach position. Clause 60.1(6) (failure to respond or act within the period required by the contract) and Clause 60.1(18) or similar (a breach of contract not listed elsewhere) may be engaged. A systematic pattern of client-side non-notification can itself form the basis of a contractor's claim under the contract. The practical consequence for both parties is that the early warning mechanism is not optional — it is a commercial discipline that protects the notifying party as much as it informs the other party. Contractors who treat early warnings as "admission of failure" and avoid notifying are setting themselves up to lose compensation event assessments later. Project Managers who treat them as "contractor's problem" and do not reciprocate are creating grounds for challenge that will play out in the contract's dispute mechanisms or in subsequent negotiations. ### The link to compensation events The early warning mechanism sits upstream of the compensation event mechanism, and understanding the relationship is essential to using both effectively. An early warning is a prospective notification of a matter that could have an effect. A compensation event notification (under Clause 61) is a retrospective notification of an event that has occurred and falls within the Clause 60.1 list. They are different mechanisms for different purposes. The link is that many matters that start as early warnings become compensation events when they actually occur. A notified early warning about a supply chain delay becomes a compensation event notification when the delay is confirmed and its impact is measurable. A notified early warning about a design query becomes a compensation event if the resolution of the query meets the Clause 60.1 criteria (typically 60.1(1) — the Project Manager gives an instruction changing the Works Information). The early warning does not itself produce an extension of time or additional cost; the compensation event does. The practical workflow is to treat each early warning as a potential compensation event and track it through both mechanisms. The Early Warning Register captures the notification and the ongoing mitigation. When the event actually occurs, a compensation event notification is made under Clause 61, referencing the earlier early warning. The assessment under Clause 63 then values the time and cost impact on the Accepted Programme and the Defined Cost. If the early warning was given properly, the assessment captures the full impact (net of any successful mitigation). If the early warning was not given — Clause 63.7 applies — the assessment is reduced by what the mitigation could have achieved. The early warning does not freeze the contractor's position or waive any rights. A contractor who gives an early warning and then later finds the matter does not produce a compensation event is not disadvantaged — they have simply notified a risk that did not materialise, and no consequence flows from it. Contractors who withhold early warnings "to preserve options" are misreading the contract. The protection runs in the opposite direction: giving the early warning preserves the full assessment value if the event does occur. The less obvious link is to the Accepted Programme. Clause 32 requires the contractor to revise the programme to reflect instructed compensation events, changes in resources, and actual progress. Matters that are the subject of early warnings — particularly those likely to become compensation events — should be reflected in the revised programme through updated activities, new activities, or time risk allowances as appropriate. A contractor who does not update the programme in response to emerging matters, and then claims the full impact when the matter crystallises, is in a weaker position than one whose programme has been kept current. The risk reduction meeting outputs should feed directly into the programme revision cycle, not sit as a parallel record. ### Common mistakes on real projects The most common mistake is treating early warnings as a contractor's tool used defensively. Contractors notify early warnings primarily to protect their compensation event position, with little expectation that the notification will produce joint mitigation. Project Managers receive early warnings primarily as commercial signals of likely claims to come, with limited engagement in mitigation discussion. The mechanism functions as a notification exchange rather than as a collaborative risk management tool, and the potential value of early joint mitigation is lost. The second common mistake is the combined progress and risk meeting. When the risk reduction meeting is an agenda item within the operational progress meeting, the risk discussion is rushed, the attendees are the operational team rather than the risk team, and the outputs are shallow. The discipline of a separate meeting — on a different date, with a defined agenda focused on risk, attended by the right people — produces materially better outputs. Teams that resist holding a separate meeting usually cite efficiency; the actual effect is that the early warning mechanism is starved of time and attention. The third common mistake is the Early Warning Register as a formal document rather than a live one. The register fills up, entries age, actions drift, and the document becomes an artefact maintained for governance rather than a working tool. The discipline of updating the register in the meeting — not as a post-meeting administrative task — keeps it live. Entries that have been closed out should be archived; entries that have not been progressed should be flagged and chased; new entries from ongoing work should be added continuously, not just at formal notification. The fourth mistake is selective notification. Contractors sometimes notify the easy early warnings and withhold the difficult ones, hoping the difficult matters will resolve without the political exposure of notification. Project Managers sometimes reciprocate by withholding notification of client-side matters that would give the contractor advantage. Both behaviours break the mechanism. A pattern of selective notification, once visible to the other party, degrades the trust that makes collaborative risk management work, and the contract then operates in a more adversarial register where the early warning mechanism produces little value. The fifth mistake is failure to close the loop with the programme. Matters discussed in risk reduction meetings produce actions; the actions change the project's expected trajectory; the programme should reflect the changes. If the programme is updated only on compensation events, and early warnings do not reach the programme until they crystallise, the programme lags reality by months. A contractor whose programme does not reflect notified early warnings will find compensation event assessments weaker than they should be, because the assessment is against a programme that does not show the full picture of known matters. ### What to do on Monday morning If you are running an NEC4 contract and the early warning mechanism is underused — which, honestly, is most contracts — the improvements are specific and achievable within a month. First, separate the risk reduction meeting from the progress meeting. Set a separate date, a separate agenda, and a separate attendee list. This single change, sustained over three months, typically transforms the quality of the early warning mechanism. Second, audit the Early Warning Register. Identify entries that are stale, entries with no recent update, entries without clear owners, and entries that should have been closed. Do a one-off cleanup, and then establish the discipline that the register is updated in the meeting, not offline. A register that reflects reality is usable; a register that does not is noise. Third, change the culture around notification. Contractors' PMs should encourage their teams to notify early — not as a commercial manoeuvre but as a protection — and make clear that non-notification carries the contractual consequence under 63.7. Client-side PMs should reciprocate, giving early warning of client matters proactively, and responding to contractor notifications with engagement rather than defensive positioning. This is not a policy change; it is a tone change, and it usually starts with the senior PM on one side modelling the behaviour and the other side responding. Fourth, link the register to the programme update cycle. Every programme revision under Clause 32 should cross-reference the Early Warning Register: which notified matters are reflected in the revised programme, which are not (and why), which have produced new activities or time risk allowances. This keeps the programme honest and ensures that early warnings actually influence the live project representation rather than sitting in a parallel record. Fifth, report the mechanism upward. The monthly steering group pack should include the count of early warnings notified this month, the count closed, the count outstanding, and any material ones with ongoing actions. Steering group visibility into the mechanism signals its importance and applies pressure to maintain the discipline. Teams that run the mechanism without senior visibility tend to let it decay; teams whose senior leaders ask about it regularly keep it alive. The final point is that the early warning mechanism is one of the most elegant features of NEC4 — a structured, bilateral, forward-looking risk management tool built into the contract itself. Using it well protects both parties, produces better project outcomes, and reduces the volume and intensity of the compensation event disputes that consume disproportionate commercial attention on weaker-run NEC contracts. The mechanism is there; the question is whether the project team has the discipline to use it. Most do not, and most of those lose significant value as a result. ### Frequently asked questions **What triggers an NEC4 Early Warning under Clause 15?** NEC4 Clause 15 requires either the Contractor or the Project Manager to notify the other "as soon as either becomes aware" of any matter that could increase the total of the Prices, delay Completion, delay meeting a Key Date, or impair the performance of the works in use. The trigger is awareness of a potential matter, not confirmation that it will occur — the mechanism is deliberately forward-looking. A Contractor who waits until the event has crystallised before raising an early warning has missed the window and may have their later compensation event assessment reduced under Clause 63.7. **How quickly does a risk reduction meeting have to happen after an early warning?** NEC4 does not specify a fixed timing for risk reduction meetings — Clause 15 requires the parties to "co-operate" in considering and seeking solutions, and the practical pattern on well-run contracts is a meeting within one or two weeks of the notification. The risk reduction meeting is where the parties discuss what could be done by each party to reduce the impact, decide on the actions to be taken, and update the Early Warning Register accordingly. Slow or perfunctory meetings undermine the whole mechanism — the value comes from the dialogue, not from the notification itself. **What is the Early Warning Register and what should it contain?** The Early Warning Register is the live, shared record of all early warnings raised on the contract. Each entry should record the date of the notification, who raised it, a clear description of the matter, the potential impact on price/time/Key Dates/performance, the actions agreed at the risk reduction meeting, the person responsible, and the current status (open, resolved, escalated to compensation event). The Register is consulted at every risk reduction meeting and reviewed at every programme update cycle under Clause 32, so it must be maintained currently — a stale Register signals a broken mechanism. **What happens if the Contractor fails to raise an early warning?** Under Clause 63.7, if the Contractor did not give an early warning of an event that an experienced contractor could have given, the compensation event resulting from that event is assessed as if the Contractor had given the early warning — meaning any mitigation that would have been possible with earlier notification is treated as having been done. In practice, this can reduce the compensation event assessment substantially. The risk is asymmetric: failing to warn costs nothing if no event materialises but costs real money if one does, so the rational position for the Contractor is to over-notify rather than under-notify. **What is the difference between an early warning and a compensation event?** An early warning notifies a potential future matter that could impact price, time, Key Dates or performance — it does not, by itself, give the Contractor any contractual entitlement. A compensation event is a specific occurrence (listed in Clauses 60.1(1)–(20)) that has happened and that does entitle the Contractor to assessed time and cost. The same underlying issue often produces both: the Contractor warns about a potential problem (early warning), the problem occurs and falls within the listed events (compensation event), the Contractor notifies under Clause 61.3, and the assessment proceeds under Clause 63 — informed by what was discussed at the risk reduction meeting that the early warning triggered. **How does an early warning interact with the Accepted Programme?** Early warnings sit on the Early Warning Register, not directly on the Accepted Programme. However, the matters notified should influence the programme at the next Clause 32 revision — typically through revised activity logic, additional Time Risk Allowances, or new fragnets representing mitigation work. Each programme revision should cross-reference the Register: which open warnings are reflected in the revised programme, which are not (and why), and which have produced new compensation event quotations. This keeps the programme honest and ensures the mechanism actually influences delivery rather than running in parallel as a paper exercise. --- ## QSRA Readiness — What a Schedule Needs Before the Monte Carlo Runs URL: https://www.somaprojectcontrols.com/resources/guides/qsra-readiness-before-the-monte-carlo Subtitle: Why DCMA 14-point, CIOB PP21 and Acumen Fuse SQI each answer a different question, what risk-load readiness actually means, and the specific failure modes that kill a QSRA before the simulation has a chance. Published: 2026-04-19 · 11 min read ### The question DCMA does not answer Every QSRA practitioner has seen the same pattern. The schedule passes DCMA 14-point — or most of it. The contractor's planner is satisfied. The QRA lead signs it off. The schedule and the risk register load into Safran, the simulation runs, and the output makes no sense. Variance is suppressed. The tornado is shallow. The P80 sits suspiciously close to the deterministic finish. Something is wrong, but nothing in the inputs was obviously broken. The cause is almost always a category error about what the input checks were testing for. DCMA 14-point was written in 2005 by the US Defense Contract Management Agency as a contract-auditing checklist. It asks: does this schedule pass a generic quality audit? That is a useful question, but it is not the question a QSRA is built to answer. A QSRA asks: given the uncertainty in every activity duration and the risks in the register, what is the range of plausible completion dates? For that to produce a meaningful answer, the schedule has to be prepared for probabilistic analysis — and DCMA does not test for that. CIOB PP21, published by the Chartered Institute of Building in 2017, is closer to the construction reality but blends schedule quality with process maturity. Scores depend partly on the project management environment around the schedule, not just on the schedule itself. That makes PP21 useful as an organisational benchmark and harder to use as a pass/fail gate for whether a specific schedule is ready for risk-loading. Acumen Fuse SQI, widely used because it ships with the tool, is closed-source and calibrated to Deltek's defaults — it treats every schedule as if it were a QSRA-ready baseline, without distinguishing between a schedule that is structurally sound and one that has been prepared for probabilistic analysis. None of the three frameworks is wrong. They solve the problems they were designed to solve. But none of them asks the QSRA question directly, and a schedule can pass all three and still be entirely unready for a meaningful Monte Carlo. This is the first thing to accept: a DCMA green light is not a QSRA green light. They measure different things. ### What "QSRA-ready" actually means A schedule is QSRA-ready when the Monte Carlo engine can model it correctly — which means the logic, durations, calendars, constraints, float and scope markers all behave the way the simulation expects. Put differently: every assumption the tool is going to make when it iterates the schedule ten thousand times has to be true. If any of them are not, the variance the simulation produces will be an artefact of the input problems, not a reflection of real programme risk. At SOMA we decompose QSRA readiness into five weighted domains, each containing specific checks against specific failure modes. The first, Logic Integrity (25% weighting), covers the foundation: missing logic, dangling ends, the mix of finish-to-start and other relationship types, merge hotspots, logic density and relationship direction. If the logic is soft, the Monte Carlo will find it — activities with no predecessors cannot be risk-driven, activities with no successors create stranded variance, and unusually high merge-node density produces "merge bias" where the simulation over-counts the compounding effect of parallel risks. The second domain, Duration Health (20%), asks whether the activities can carry risk sensibly. Very-high-duration activities (say, over 90 working days) are usually summary activities disguised as detail — giving them a three-point range spreads risk over a bucket, not over a real operation. Zero-duration activities that are not milestones (a common XER import artefact) produce zero-variance points that mask real risk. Duration distribution tells you whether the schedule is padded, whether it is overly granular at one tier and coarse at another, and whether the activities look planned or guessed. The third, Constraints & Calendars (15%), covers the silent levers that distort the critical path. Hard constraints — start-on, finish-on, must-finish — override logic; the Monte Carlo cannot push through them. A schedule with dozens of hard constraints will produce simulations where the critical path is not real, because the constraints are holding it in place. Calendar assignments that are inconsistent across connected activities break duration calculations. Milestones with missing or wrong calendar assignments show up as phantom criticality. The fourth, Float & Critical Path (20%), asks whether the critical path is credible and whether float is honest. Extremely long critical paths, negative float, unusual volumes of high-float activities, float distribution skewed either way, and broken ERMHDR records (the XER header that tells Safran about calendars and resources) all break the risk model in ways the simulation will not flag — it will just produce confident-looking output that is not trustworthy. The fifth, QSRA Readiness (20%), is the part most frameworks miss entirely. It covers in-scope definition, lag hygiene, status consistency, data-date alignment, activity-ID uniqueness, WBS depth, LOE (level-of-effort) discipline, TRA and TBP (time-risk allowance and time-bridging provision) hygiene, and procurement-lag exemption. These are the checks that ask: has the planner, explicitly, drawn the boundary around what the QSRA should model? A schedule where LOE activities are mixed into risk-loaded sections will inflate the tail. A schedule where procurement lead-times sit as lags on logic will absorb variance instead of driving it. These problems do not show up on DCMA because DCMA was not looking for them. ### The failure modes that kill a QSRA Specific input failures produce specific and predictable distortions in the simulation output, and an experienced QSRA practitioner can often recognise them from the S-curve shape alone. Knowing the failure modes backwards is the best defence against producing a model that is confidently wrong. The most common ones are worth walking through in detail. Hard constraints in the middle of the schedule are the single biggest cause of suppressed variance. When a major delivery milestone is pinned by a "start-on" or "finish-on" constraint, the simulation cannot push it later even when the activities feeding into it slip. The result is an output where the P80 and the deterministic date are suspiciously close — the model is confident because the constraint is doing the work. Planners sometimes add these constraints to make the bar chart look tidy, not realising they are telling the Monte Carlo engine that the date is fixed. LOE activities mixed into variance calculations are the next most common. Level-of-effort activities — typically summary bands like "project management" or "site facilities" — have durations driven by their start and end logic rather than by a real operation. Giving them a three-point range produces nonsense ranges, because the activity has no underlying work content to extend or compress. Good QSRA tools will exclude LOE activities from variance calculation by default, but only if the activities are correctly tagged. When they are not — when LOEs are flagged as task-dependent or have no activity-type marker at all — they go into the simulation as if they were real operations and the output gets polluted. Procurement lags treated as risk-bearing activity duration is a subtler but equally damaging failure. A lag on a logic relationship — "10 days delay between design approval and construction start" — has no activity, no resource, and no explicit ownership. Variance applied through lag cannot be driven by risk events, because the lag is static. If procurement lead-time is represented as a lag rather than as a real activity with a planner-set duration and a risk mapping, the schedule simulation will treat it as a fixed delay and the variance modelling will under-count procurement risk entirely. Orphan risks in the register are the fourth killer. An orphan is a risk that is mapped to an activity that does not exist in the XER — often because the activity has been renumbered between programme revisions, or because the risk was mapped to a coding tag that the latest baseline dropped. The simulation will either ignore the risk entirely (in which case the tornado is missing drivers that should be there) or assign it a default mapping that the QSRA analyst has not sanctioned. Both failure modes produce output that is structurally wrong. The fifth common failure is schedule status lag. Compare the schedule's data date with the current programme actual-finish dates on complete activities: if the data date is two months stale, the schedule you are risk-loading is not the current reality, and the simulation will be modelling a world that no longer exists. Status consistency — making sure that the status shown on each activity matches the data date and the actual progress — is essential before any risk-loading exercise. ### Why the risk register is half the job Every hour spent auditing the schedule is wasted if the risk register behind it is broken — and most registers, on most real programmes, have structural issues that undermine the Monte Carlo even after the schedule is cleaned. The register problems are different from the schedule problems, but they are equally capable of producing confidently wrong output, and they need their own assurance pass before the simulation runs. The first and most common register failure is missing mandatory fields. Whatever tool the register came out of — Riskhive, Xactium, ActiveRisk, Predict! or a plain consolidated workbook — the set of fields each row needs to carry is the same: probability of occurrence, minimum / most-likely / maximum cost impact, minimum / most-likely / maximum schedule impact, distribution type, mapped activity. When fields are missing, most QRA tools will either drop the row silently, substitute defaults, or apply a distribution that the analyst did not choose. All three behaviours produce simulation output that does not reflect the register the team actually built. The second is three-point estimates that are not actually three-point. A distressing proportion of production risk registers use the same three-point range for every risk — typically 80% / 100% / 130% of the most-likely — because the team ran out of time to calibrate each one. The simulation will run happily against these, and the output will show a realistic-looking spread. It will also be wrong in ways that are invisible from the output alone, because the spread is an artefact of the uniform ranges rather than a reflection of differential risk. Each risk needs a range that reflects actual expected variability: some are tightly bounded, some have long tails, some have binary outcomes, and the register has to capture that. The third failure is probability bounds. Some tools allow probabilities above 100% through operator error, some allow negative probabilities, some treat a blank field as "100%" and others as "0%". A register with probabilities outside the 0–100 range, or with a mix of representations (some rows in 0–1 format, others in 0–100), will produce simulation output where the total risk-load is the wrong shape. This is an easy validation check and one that should run against every register before the model starts. The fourth and most structurally important is risk-to-activity mapping. Every risk in the register must map to one or more activities in the XER, or to a coded scope marker that the simulation tool can resolve. When mappings are weak — vague scope references like "civils works generally", mappings to summary activities rather than to detail, activities that have been renumbered — the simulation either cannot locate the impact point or maps to the wrong point. Split-impact weights, used where a risk affects several activities in different proportions, need explicit weighting values; when they are missing, the tool either applies the full impact to every mapped activity (inflating the tail) or applies proportional defaults that the analyst did not specify. Catching mapping failures is the job of a specific risk-to-activity mapping validator, separate from the schedule and register checks. The full register audit takes about the same time as the schedule audit on a mid-sized programme. Skipping it and trusting that the register is fine "because the team built it carefully" is the most common reason a simulation produces output that everyone in the room wants to believe but no-one can defend under scrutiny. ### Testing readiness before the model runs The practical question for a QSRA analyst with a model to run next week is: how do I test these inputs before I load them, and how much time is the check going to take? The answer depends on the scale of the programme and the tools available, but a disciplined readiness pass on a mid-sized UK infrastructure schedule and its risk register takes roughly half a day and saves days of downstream rework. The first pass is framework-based. Run DCMA 14-point against the XER to catch the generic schedule quality issues — missing logic, hard constraints, negative float, float outliers, invalid dates. DCMA will take perhaps half an hour with a reasonable tool, and it will clear the obvious structural problems. The schedule that fails DCMA is almost never ready for QSRA; the schedule that passes DCMA is not necessarily ready, but you have eliminated one class of failure. The second pass is risk-load readiness specific. This is where DCMA hands off to something QSRA-focused: scope markers (LOE, milestones, hammocks), lag hygiene (procurement represented as activity not lag), status consistency, data-date alignment, activity-ID uniqueness, WBS depth (so roll-ups work), and TRA / TBP discipline. The SOMA QSRA Readiness framework codifies 25 checks against these failure modes; other frameworks cover parts of the same ground with different emphasis. The important thing is to be deliberate about what you are checking for, not to rely on a generic audit and hope. The third pass is the register. Run the register through a validator that checks mandatory fields, probability bounds, three-point-estimate plausibility and distribution types. This is usually a table-based exercise and can be done in an hour on a spreadsheet if the tooling is not available, or in seconds if it is. Flag the rows with missing fields, the rows with suspiciously uniform ranges, and the rows with unusual distribution types that the simulation tool may not handle as expected. The fourth pass is the cross-check between schedule and register — the mapping validator. For every risk in the register, verify that the mapped activity exists in the XER, is in the QSRA-relevant scope (not LOE, not milestone-only, not excluded by TRA discipline), and has a sensible split-impact weight if multiple activities are mapped. Orphan risks and unmapped activities get flagged here. This is the step that most teams skip and that catches the most expensive errors. The fifth pass is the readiness scorecard. Aggregate the results into something an assurance lead can read in a minute — a RAG-banded score per domain, a headline number, a short list of the specific findings that caused any amber or red results. On a well-run programme, the score should be above 85 (green) before the simulation starts. A score in the 70–85 range (amber) means the simulation can run but the output needs to be caveated with the specific findings. A score below 70 (red) means the schedule is not ready and pushing ahead will produce defensible-looking output that is not defensible on closer inspection. Tools to run these checks have improved significantly in the last five years. A practitioner today can run the schedule check, register check, mapping check and aggregated scorecard in roughly the time it used to take to do the DCMA check alone. At SOMA we built the QSRA Validator — a desktop tool covering all four validators and producing the aggregated scorecard — because our own delivery teams were losing days per engagement to spreadsheet-based audits that were not producing defensible, consistent output. The principle generalises: if the checks are formalised, the tooling will follow. ### What to do on Monday morning If you are running a QSRA in the next quarter and the schedule / register pair has not been through a dedicated readiness check, the practical improvements are specific and achievable within two weeks. First, run DCMA 14-point against the current XER. If it does not pass, the schedule is not ready — go back to the planner with the findings and fix them before thinking about risk-loading. DCMA alone takes half an hour with the right tool; there is no reason to skip it. Second, separately, audit the schedule against a QSRA-specific framework. SOMA QSRA Readiness is one option; adapted CIOB PP21 subsets or bespoke checklists are others. The important thing is that you have checked against the right questions — LOE discipline, lag hygiene, scope markers — and not just against generic schedule quality. Document the checks you have run and the findings; this is what a defensible methodology sign-off looks like at the point a regulator asks. Third, validate the risk register against a written schema. Mandatory fields, probability bounds, three-point ranges with a non-uniform distribution, explicit distribution types. If you are working in Riskhive or Xactium, each has its own export quirks — be aware of them and build the validator to catch the specific failure modes your tool produces. A register that passes this check is not necessarily a good register, but a register that fails it is definitely not ready. Fourth, run the risk-to-activity mapping check. Every row in the register should resolve to an activity in the XER, or to a coded scope marker the tool can resolve. Orphan risks get flagged and resolved; unmapped risk-bearing activities get flagged and resolved. Split-impact weights that are missing get filled in with explicit values, not left blank. This is the step that catches the mapping errors no-one else is going to catch for you. Fifth, produce a readiness scorecard and sign it off before the simulation runs. The scorecard is not a governance artefact for its own sake — it is the evidence that the inputs were checked properly and the analyst has a defensible position on input quality. If the Monte Carlo output turns out to be surprising (good or bad), the first question a reviewer will ask is "were the inputs clean?" and a signed readiness scorecard answers that question directly. A QSRA without one is an opinion; a QSRA with one is a defensible methodology. The broader point is that QSRA input assurance has become a specific practitioner discipline in its own right, and frameworks like DCMA, CIOB PP21 and Acumen Fuse SQI — all of which are useful for the questions they were designed to answer — do not fully answer the QSRA question. The question is whether the schedule and register are ready to be risk-loaded, and the only way to know is to check. Tools have caught up with the discipline in the last few years; the practice should catch up with the tools. For teams running major UK infrastructure programmes, where QSRA output drives contingency conversations with boards and sponsors, the cost of running the readiness check is small and the cost of not running it can be significant. --- ## Critical Path Method: How UK Programmes Actually Use CPM URL: https://www.somaprojectcontrols.com/resources/guides/critical-path-method-uk-programmes Subtitle: CPM textbook explanations stop at forward pass and backward pass. UK infrastructure, defence and nuclear programmes need more — near-critical paths, risk-adjusted criticality, NEC4 Clause 32 alignment, and how DCMA-14 actually tests the network logic. A practitioner's guide to using CPM on real programmes. Published: 2026-05-22 · 12 min read ### What CPM does — and what the textbook leaves out Every project management textbook explains the Critical Path Method the same way. You build an activity network, you run a forward pass to find each activity's Early Start and Early Finish, you run a backward pass to find each activity's Late Start and Late Finish, and the activities where these dates match — zero total float — lie on the critical path. The path determines the earliest possible completion date. Worked examples involve four activities labelled A, B, C and D, durations of 5, 3, 7 and 2 days, and a critical path that runs A → C → D. That is the textbook. On UK infrastructure, defence and nuclear programmes, none of this is wrong, but most of it is incomplete. A real Primavera P6 schedule has 8,000 to 30,000 activities, not four. The critical path runs through ten or fifteen near-critical alternatives that any single delay could pull onto the path. The deterministic CPM calculation ignores the merge-bias effect that almost always makes the probabilistic completion date later than the deterministic one. Software-imposed constraints distort the calculated float in ways the textbook does not anticipate. And the people reading the programme — a Project Manager assessing a Clause 32 revision under NEC4, a DCMA 14-point reviewer, an IPA gateway assessor — are asking questions that the textbook treatment does not equip the planner to answer. This guide is for practitioners working on UK programmes who already know the forward and backward pass and need the parts the textbook leaves out: how near-critical paths matter as much as the headline critical path, how the deterministic critical path relates to the risk-adjusted critical path produced by QSRA, how CPM connects to the NEC4 contract machinery, the tool-specific gotchas in Primavera P6 and Asta Powerproject, and the failure modes that DCMA 14 was designed to flag. ### Near-critical paths matter as much as the critical path The single most important practitioner extension to textbook CPM is that activities with small amounts of positive float matter almost as much as activities with zero float. The textbook treats float as a binary: zero is critical, anything positive is not. The reality on a live programme is that an activity with three days of total float is critical in any meaningful sense — a normal delay will pull it onto the critical path within days. This is why the DCMA 14-point assessment, which is the de facto schedule-quality benchmark on UK defence and major infrastructure programmes, treats any activity with seven working days or less of total float as effectively critical for monitoring purposes. The DCMA 14 threshold has a specific origin: empirical analysis of major US Department of Defense programmes showed that activities with low positive float consistently behaved like critical-path activities — small delays propagated to the project end date, and the operational signature of these activities matched the operational signature of zero-float work. The UK MoD and IPA-aligned programmes have adopted the same threshold because it stands up to empirical scrutiny. On programmes where the float-distribution check is failing — too many activities with low positive float, suggesting an artificially propped-up critical path — DCMA 14 flags it, and the planner needs to be ready with an answer. In practice, this means a competent practitioner looks at three things when reviewing a critical path: the activities with zero total float (the textbook critical path), the activities with one to seven days of total float (the near-critical path under DCMA 14), and the cumulative distribution of float across the whole network. A schedule with 50 activities at zero float and another 300 within seven days of zero float has a critical path that is functionally a critical zone, not a critical line — and the planning narrative needs to reflect that. Primavera P6 makes this analysis straightforward via the Activity table's Total Float column, sorted ascending and grouped by float band. Asta Powerproject's equivalent is the Float report. Either tool surfaces the float distribution in minutes; the discipline is to actually look at it, and to communicate it. A programme review that says "the critical path runs from groundworks through M&E commissioning to handover" without also saying "there are 240 near-critical activities within DCMA threshold, concentrated in the secondary fit-out phase" is missing where the actual schedule risk sits. ### The deterministic critical path vs the risk-adjusted critical path The deterministic critical path is a single path through the network produced by the CPM calculation on point-estimate durations. The risk-adjusted critical path — produced by a Monte Carlo Schedule Risk Analysis (QSRA) — is the answer to a different question: across many simulated runs of the programme, which path drives the project end date most often? The two are usually different, and the difference matters. On a Monte Carlo run of a typical UK infrastructure programme, the deterministic critical path will be the most frequent driver of the project end date — but it will rarely drive completion in more than 60 to 70% of iterations. The remaining 30 to 40% of iterations are driven by paths that the deterministic calculation flagged as non-critical. The Criticality Index metric — the percentage of Monte Carlo iterations in which a given path drives the simulated project end date — gives the risk-adjusted view of where schedule sensitivity actually sits. A practical example. A deterministic schedule shows the critical path running through the structural steel erection phase, with an electrical commissioning path running 14 days behind. The QSRA, run on three-point estimates that reflect the genuine uncertainty in each activity, produces a Criticality Index of 58% for the steel path and 31% for the electrical path. That 31% is the part the deterministic view ignored — and it is the part where focused risk mitigation work would have the largest expected effect on completion. Treating the deterministic critical path as the only thing worth managing means leaving 30%+ of schedule risk unaddressed. The practitioner who runs QSRA properly knows this; the planner who has only the deterministic view does not. The relationship between deterministic and risk-adjusted criticality also explains the consistent finding that Monte Carlo P50 dates are later than deterministic completion dates — usually called the merge-bias effect. As multiple near-critical paths converge on completion, the probability that all of them finish on time is lower than the probability that any single one does. Deterministic CPM ignores this combined probability; Monte Carlo captures it. On programmes with many parallel workstreams converging on a single milestone (commissioning, handover, regulatory acceptance), the gap between deterministic and risk-adjusted completion can be material — three to six months on programmes of two to three years duration is not uncommon. ### How NEC4 uses the critical path On UK contracts written under NEC4 ECC, the critical path is not just a planning concept; it is contractually significant. The Accepted Programme under Clause 11.2(15) — the version of the Contractor's programme that the Project Manager has formally accepted — must show the critical path (and float on other activities) in a way that satisfies the contract's information requirements. A programme that does not show the critical path, or that shows it in a way the Project Manager cannot interrogate, is grounds for non-acceptance under Clause 31.3. The critical path matters even more at compensation event assessment time under Clause 63. The time impact of a compensation event is assessed by inserting the additional work into the Accepted Programme, running the schedule logic, and showing what effect the insertion has on planned completion. The assessment depends on the Accepted Programme having a defensible critical path: an event that lands on the critical path drives planned completion immediately; an event that lands on a non-critical path consumes float without (initially) affecting completion. The line between these two outcomes is the critical path itself. On programmes where the critical path is shifting between Accepted Programme revisions — a common pattern after several compensation events — the question of which path was critical at the time of the event becomes commercially important. Some adjudications turn on this question. The Contractor's position relies on a consistent, well-documented critical path that can be traced through the revision history; the Client's position relies on the same. Sloppy critical-path management is, in NEC4 terms, an avoidable source of dispute. The Clause 32 revision cycle is what keeps the critical path current. Each revised programme submitted under Clause 32 shows the actual progress on every operation, the effect on remaining work, and the current critical path. The Project Manager's acceptance decision under Clause 31.3 turns in part on whether the critical path shown is plausible. A revised programme that shifts the critical path to a different sequence without a clear narrative explanation of why the previous path is no longer driving completion is the kind of submission a competent Project Manager would refuse to accept on the grounds that it does not represent the Contractor's plans realistically. ### Primavera P6 and the critical path the tool actually shows you The critical path Primavera P6 shows on the Gantt chart is the critical path according to the scheduling options set in the project — and those options have meaningful defaults that practitioners often do not check. The default critical-path definition in P6 is "longest path" — activities on the path with the longest total duration through the network, regardless of constraints. The alternative setting is "total float less than or equal to 0" (or another configurable threshold). On a programme with date constraints on intermediate milestones, these two settings can produce materially different critical paths. Date constraints are the most common source of misleading critical paths in P6. An activity with a hard Finish-On constraint will report zero total float regardless of its true logical position in the network, because the constraint forces the late dates to equal the early dates. The resulting critical-path display includes the constrained activity as if it were a genuine driver of completion, when in reality it is a constraint imposed by the planner. A schedule with several hard-constrained intermediate milestones can produce a "critical path" that meanders through constrained activities and bears no relationship to the genuine longest-duration sequence. DCMA 14 explicitly tests for this through the Hard Constraints metric (no more than 5% of activities with hard constraints) and the Critical Path Test (the critical path should run from project start to project completion without breaks, and the float on critical activities should be zero). A schedule that fails these tests usually has a critical-path narrative that is contaminated by constraint-driven artefacts. The practitioner discipline is to review every hard constraint in the schedule and ask whether it is genuinely required by the contract or by physical reality, or whether it has been added to make the schedule look acceptable. Many can and should be removed. Asta Powerproject and Microsoft Project handle critical-path calculation similarly but with different default options and different terminology. The underlying mathematics is the same; the user-interface defaults differ. The discipline of checking the scheduling options before trusting the displayed critical path applies regardless of tool. ### Common ways the critical path lies — and how to catch them The critical path can mislead in several reliable ways, and a practitioner-quality programme review checks for each of them. The first is the multiple critical paths problem: two or more paths through the network with the same total duration, which P6 will display as critical without distinguishing between them. Multiple critical paths are commercially significant because they double the schedule risk — any slip on any of them delays the project — and DCMA 14 flags this as an Excessive Critical Path issue. The second is the constraint-driven critical path described in the previous section: critical-path activities that are critical only because a hard constraint forces zero float, not because they are logically driving completion. The fix is to remove unnecessary constraints and re-run the schedule. The third is dangling logic — activities with missing predecessors or successors that disconnect part of the network from the critical-path calculation. DCMA 14's Logic metric (no more than 5% of activities with missing predecessors or successors) catches this. A schedule with significant dangling logic produces a critical path that does not represent the full work; the planner needs to fix the logic before the path can be trusted. The fourth is the artificially-extended critical path that runs through long-duration activities with overstated durations. Sometimes this is honest (the activity really does take 90 days); often it is the planner padding durations to create commercial protection. The check is to compare activity durations against historic benchmarks and against the durations of comparable activities elsewhere in the same programme. Outliers warrant explanation. The fifth is the absent critical path — a schedule where the critical-path display does not run continuously from start to finish, with gaps or breaks driven by data integrity issues. This is the DCMA 14 Critical Path Test. A programme that fails it has a critical-path display that cannot be relied on for any practical purpose, and the underlying network needs work before the programme can be accepted under NEC4 or assessed against compensation events. ### Putting it together CPM is the foundation of UK programme management — at NEC4 acceptance, at DCMA 14 assessment, at QSRA simulation, at IPA gateway review. But the textbook treatment of CPM is not sufficient for any of those uses. A practitioner working on a UK infrastructure, defence or nuclear programme needs to know how the deterministic critical path relates to near-critical paths under DCMA, how it relates to the risk-adjusted criticality produced by Monte Carlo simulation, how NEC4 Clauses 31, 32 and 63 turn on the critical path being well-defined and well-maintained, how Primavera P6 and other tools can mislead, and how DCMA 14 catches the common ways the critical path can mislead. The discipline that separates a good programme from a presentation programme is whether the critical-path narrative is genuine. A good programme has a critical path that traces logically from start to completion through activities that an experienced reviewer would expect to drive the project. The near-critical paths are visible and have been thought about. The constraints are necessary, not cosmetic. The QSRA criticality view has been compared to the deterministic view. And the critical-path activities are the ones the project team is actively managing, with daily attention from the planners and weekly attention from the project board. SOMA provides programme assurance, CPM review, DCMA 14 assessment and QSRA delivery on UK infrastructure, defence and nuclear programmes — including the deterministic-to-risk-adjusted critical-path comparison that informs contingency setting at Initial Gate and Main Gate business cases, and the Clause 32 programme acceptance work that depends on a defensible critical path being maintained through every revision. The standard the work needs to meet is high; the practice that delivers to that standard is achievable when the right disciplines are applied. ### Frequently asked questions **How is the critical path calculated in CPM?** The critical path is calculated through two passes across the activity network. The forward pass calculates Early Start and Early Finish for each activity, walking from the project start: each activity's ES equals the maximum EF of all its predecessors, and EF = ES + duration. The backward pass calculates Late Start and Late Finish, walking from the project end backwards: each activity's LF equals the minimum LS of all its successors, and LS = LF − duration. Activities where Total Float (LS − ES) equals zero are critical; the chain of zero-float activities from start to finish is the critical path. **What is the difference between the critical path and the near-critical path?** The critical path is the sequence of activities with zero total float — activities where any delay will push out the project end date. Near-critical paths are sequences of activities with small positive float (typically defined as seven working days or less, under the DCMA 14-point assessment threshold) that behave like critical-path activities in practice — a normal delay on any of them will pull them onto the critical path within days. On real UK infrastructure programmes, the near-critical paths often carry more schedule risk than the headline critical path because there are usually several of them converging on the same completion milestone. **How does QSRA change the critical path?** A Quantitative Schedule Risk Analysis (QSRA) — a Monte Carlo simulation of the schedule with three-point estimates on activity durations — produces a risk-adjusted view of criticality. Instead of a single deterministic critical path, QSRA produces a Criticality Index per path: the percentage of simulated iterations in which that path drives the project end date. The deterministic critical path is usually the most frequent driver but rarely drives completion in more than 60-70% of iterations; the remaining 30-40% are driven by paths the deterministic view flagged as non-critical. The risk-adjusted critical path gives a more accurate picture of where to focus schedule risk mitigation. **Does Primavera P6 always show the correct critical path?** Not necessarily. The critical path P6 displays depends on the scheduling options set in the project. The default is "longest path" — the longest-duration sequence through the network — but P6 can also be configured to define critical as "total float ≤ 0" or another threshold. Hard date constraints on intermediate milestones can also distort the critical-path display by forcing zero float on activities that are not logically driving completion. The DCMA 14-point assessment specifically tests for the resulting failure modes: too many hard constraints (>5% of activities) and a critical path that does not run continuously from project start to project completion. A schedule that fails these tests has a critical-path display that should not be relied on without further investigation. **How does DCMA 14 test the critical path?** The DCMA 14-point assessment includes several metrics that test the critical path directly. The Critical Path Test requires the critical path to run continuously from project start to project completion. The Critical Path Length Index (CPLI) measures whether the remaining critical path fits within the remaining time available. The Hard Constraints metric flags programmes where more than 5% of activities have hard date constraints (which can produce artificial critical paths). The Float metric flags programmes where activities have unreasonably large total float values. Together these checks identify the most common ways the critical path can be misleading on a real schedule. --- ## NEC4 Clause 15: What Schedule Risk Looks Like in Practice URL: https://www.somaprojectcontrols.com/resources/guides/nec4-clause-15-schedule-risk Subtitle: Why the compensation event mechanism makes schedule assurance non-optional — and what good looks like. Published: 2026-04-23 · 9 min read ### What Clause 15 actually requires Clause 15 of NEC4 ECC sits within the early warning provisions, and it is more demanding than most practitioners appreciate until a dispute forces them to read it carefully. The contractor is required to give an early warning as soon as they become aware of any matter that could increase the total of the prices, delay planned completion, delay a Key Date, or impair the performance of the works in use. That obligation is not limited to discrete risk events — it covers any matter, including programme-related risk that the contractor has identified but not yet notified. The obligation runs in both directions. The project manager has a parallel early warning obligation. Clause 15.1 requires the project manager to give early warning of anything that could change the Accepted Programme, and that includes matters that might constrain the contractor's ability to work as planned — access restrictions, client-supplied information delays, third-party interfaces that are running late. Programme risk under NEC4 is not something that sits with one party; it is a shared early-warning responsibility. What makes Clause 15 different from a simple notification provision is the way it connects to the programme and to the compensation event machinery. An early warning gives rise to a risk reduction meeting if either party requests one. The outputs of that meeting — agreed actions, revised assumptions — feed back into the programme, which must be updated under Clause 32 to reflect any changes in the contractor's intentions. The early warning is not a standalone administrative act; it is the start of a programme management loop that the contract expects to run continuously throughout the project. The practical test is whether the programme — as accepted at any point in time — genuinely reflects the risk the contractor has identified. A contractor who has given an early warning about a potential six-week delay but whose Accepted Programme still shows planned completion on the original date has not completed the loop. The early warning has been filed; the programme has not been updated to reflect the risk. That gap matters commercially, because it affects how any subsequent compensation event will be assessed. ### Why most programmes fail it silently The most common Clause 15 failure mode is not a contractor who ignores the obligation — it is a contractor who complies with the letter of it while the programme tells a different story. Early warning notices are issued. Risk reduction meetings are minuted. And the Accepted Programme continues to show planned completion exactly on the contractual completion date, with no float, no time risk allowances, and no reflection of the risks the early warnings describe. This happens because programme and early warning administration are often managed by different people in different systems. The commercial team tracks early warnings in a correspondence register. The planning team maintains the programme in P6 or Asta. The two systems do not talk to each other and nobody has explicit responsibility for making sure that the risks described in early warning notices are visible in the programme. The result is a paper trail that looks compliant and a programme that gives no information about the risks the project actually carries. The silence matters at the point of a compensation event assessment. Under Clause 63, the assessment of a compensation event that causes delay is measured against the Accepted Programme. If the programme contains no time risk allowances and shows the project running exactly to the contractual completion date, a compensation event that delays any critical activity by a single day will appear to push the completion date by a single day. There is no buffer visible in the programme to absorb the impact. The contractor has handed the project manager a weapon: a programme that overstates the sensitivity of the project to any event. The inverse problem is equally common. Some contractors inflate time risk allowances across the programme to build in a buffer that protects them in compensation event assessments, without those TRAs being justified by identified risks. A TRA that is not connected to a specific, named risk is just contingency disguised as schedule risk provision. NEC4 requires TRAs to be shown explicitly and their basis to be capable of explanation. A programme reviewer who asks the contractor to explain the basis for each TRA will quickly distinguish genuine risk provision from fabricated float. ### Float types and what they tell you NEC4 does not use the term "total float" in the same way that scheduling practice does, but understanding the different types of float in an NEC programme is essential for interpreting what the programme is actually saying about schedule risk. The contract draws a distinction between planned completion — the date the contractor intends to finish — and the contractual completion date. The gap between those two dates is, in scheduling terms, project float: slack in the programme that exists because the contractor has planned to finish ahead of contract. Total float is calculated by the scheduling software for each activity: the amount of time an activity can be delayed without affecting the planned completion date. Total float on the critical path is zero by definition. Near-critical activities — those with small positive float — are the early warning indicators for which parts of the programme are most sensitive to delay. A good programme review will look at the distribution of total float across the schedule: a healthy programme has a realistic critical path with genuine near-critical paths that reflect the actual structure of the work, and the float distribution should be explainable in terms of the project logic. Free float — the time an activity can slip without affecting any of its successors — is less commonly discussed but relevant for resource planning and for identifying activities where the contractor has genuine scheduling discretion. An activity with high free float can be delayed or rescheduled without triggering a knock-on effect, which means it is a candidate for resource smoothing and is not a schedule risk driver. Activities with zero free float, by contrast, must finish on time or they will immediately delay downstream work, regardless of whether the project has total float to absorb that delay. Time risk allowances are the contractor's explicit schedule risk provision — a distinct category from float, included in the programme to represent the contractor's estimate of schedule uncertainty on specific activities or phases. Where a TRA is properly constructed, it is tied to a specific identified risk or to a class of uncertainty (weather, third-party dependency, productivity variability) and is sized proportionally to the estimated impact. The NEC4 expectation is that TRAs are visible, labelled, and connected to the risks that justify them. A programme with no TRAs, or with TRAs that are identical in size across all activities regardless of risk profile, should not be accepted without challenge. ### Compensation events and schedule impact assessment The connection between early warnings and compensation events is direct. A compensation event that is not preceded by an early warning does not lose its entitlement — NEC4 removed the deeming provision in some earlier editions that penalised late notification — but the early warning process shapes the quality of the compensation event assessment, because the best evidence about programme impact is generated close in time to the event, not months later when a retrospective assessment has to reconstruct what happened. Assessing the schedule impact of a compensation event requires a time impact analysis: inserting the additional work representing the compensation event into the Accepted Programme, running the schedule logic, and showing what effect the insertion has on planned completion. The assessment is prospective — it is what an experienced contractor would have expected at the time of the event, not what actually happened afterwards. This prospective standard means that a well-maintained Accepted Programme, reflecting genuine risk through TRAs and realistic logic, will produce a fairer assessment than a thin programme with compressed durations and no risk provision. The timing of programme updates matters enormously. If the Accepted Programme is two or three revisions out of date because the project manager has been slow to respond to submissions, the compensation event assessment will be based on a programme that does not reflect the current state of the project. Activities that have been completed will still appear as planned. Risks that have crystallised will not be reflected. The programme will not accurately model the sequencing of remaining work. An assessment based on this programme will either understate the true impact (if it fails to capture dependencies in the current working plan) or overstate it (if completed activities are treated as if they still need to happen). The project manager's obligation to respond to programme submissions within the timescales in the contract is not administrative box-ticking — it is a precondition for reliable compensation event assessments. A pattern of late responses to programme submissions, or repeated rejections without adequate explanation, creates commercial exposure for the client: the assessment will be based on whatever programme was last accepted, regardless of how stale it is. Project managers who deprioritise programme acceptance will find that this choice surfaces in disagreements about compensation event quantum at exactly the moment when the project is already under commercial pressure. ### What a defensible Clause 15 programme looks like A programme that satisfies Clause 15's intent — rather than simply its administrative letter — has four qualities that are recognisable to an experienced reviewer. First, it is current: the data date is aligned with the current reporting period, progress has been recorded against activities that are underway, and the forecast logic reflects the contractor's genuine intentions rather than the original plan copied forward. Currency is the most basic test and the most frequently failed. Second, the programme is honest about risk. TRAs are visible, labelled, and proportionate to the identified risks. Early warnings that describe schedule risk are reflected in the programme — either through TRAs on the affected activities or through revised logic that shows how the risk affects sequencing. Where an early warning has been issued but the programme has not been updated to reflect it, there should be a clear explanation of why the programme does not yet show the impact: for example, because the risk is still being assessed, or because a mitigation plan is in development and will be reflected in the next revision. Third, the critical path is genuine. The activities on the critical path should be the activities that a knowledgeable observer would expect to drive the programme: the ones that are technically dependent on each other, that involve long-lead procurement, or that require scarce resources. A critical path composed of activities with artificially constrained logic, or one that conveniently runs through activities where the project has the most commercial leverage, is not a genuine critical path. Experienced project managers and planners can tell the difference within minutes of reviewing the logic. Fourth, the programme connects to other project controls outputs. The programme's planned completion date should be consistent with the cost forecast. The TRAs should appear as schedule risks in the risk register. The early warning log should reference the activities affected by each notified risk. These connections are not bureaucratic tidiness — they are evidence that the project controls function is integrated rather than producing siloed outputs for separate audiences. A programme that is consistent with the rest of the project controls picture is a programme that can be defended in a compensation event dispute or a gateway review. A programme that exists in isolation, disconnected from the cost plan and the risk register, is a document that tells part of the story of the project and can be used to support almost any argument the author wants to make. --- ## NEC4 Clause 32: Programme Revisions and the Acceptance Loop URL: https://www.somaprojectcontrols.com/resources/guides/nec4-clause-32-programme-revisions Subtitle: NEC4 Clause 32 governs how the Accepted Programme is kept current. The Contractor revises at intervals, after each compensation event, and on PM instruction. Here is what every revision must contain, why PM silence is not acceptance, and the common failures that hurt at Clause 63 quantum. Published: 2026-05-22 · 9 min read ### What Clause 32 actually requires Clause 32 of NEC4 ECC sits at the heart of the contract's programme management machinery. The Accepted Programme — the version of the Contractor's plan that the Project Manager has formally accepted under Clause 31 — is not a fixed document. It is the current best statement of the Contractor's intentions, and the contract expects it to be kept current through a continuous cycle of revision and acceptance. Clause 32 is the mechanism that drives that cycle. Specifically, Clause 32.1 lists what each revised programme must show. The list is more demanding than many practitioners appreciate. Each revision shows the actual progress achieved on every operation that has started, the effect of that progress on the remaining work, the changes to the methods and resources the Contractor proposes to use, the current effects of every compensation event that has occurred, the effects of every early warning matter notified under Clause 15, and any other changes the Contractor proposes to make. A revision that fails to show any of these is not compliant with Clause 32.1 — and the Project Manager has grounds to refuse acceptance under Clause 31.3. The content list matters because each item is doing analytical work. Actual progress establishes the data date and forces the schedule logic to be recalculated from real performance rather than from the original plan. The remaining-work impact shows the consequences of that progress for planned completion. The methods-and-resources update keeps the programme aligned with how the Contractor is actually executing the work, rather than how the tender team assumed it would be done. The compensation event effects make sure the time impacts of every CE that has occurred are visible in one place. The early-warning effects close the loop between Clause 15 notifications and the programme. And the Contractor's other proposed changes — sequencing, logic, additional risk allowances — give the Project Manager visibility on planning judgements that would otherwise stay inside the Contractor's scheduling office. A revision that simply pushes dates out without explaining progress, methods or compensation event effects is not a Clause 32 revision; it is a re-presentation of the previous programme with a new completion date. The Project Manager should refuse to accept it under Clause 31.3(2) — the reason being that it does not show the information the contract requires. ### When revisions happen — and the dangerous gap Clause 32.2 sets out four triggers for revision. The Contractor submits a revised programme to the Project Manager for acceptance: at the intervals stated in Contract Data Part Two; within the period stated after the Project Manager instructs the Contractor to submit a revision; when the Contractor chooses to (within those intervals); and when a compensation event has occurred. Three of these triggers are predictable; the fourth — post-compensation-event revisions — is where most programmes drift out of date. The interval in Contract Data Part Two is typically set at 4 to 8 weeks on infrastructure programmes. Some clients set it shorter (2 to 3 weeks on highly dynamic programmes); some set it longer (12 weeks on long-duration capital projects with stable scope). The interval is a floor, not a ceiling — nothing prevents the Contractor from submitting more frequently if useful, and the Project Manager's right to instruct a revision under Clause 32.2 is unconstrained by the stated interval. A common failure is for Contract Data Part Two to leave the interval blank, in which case there is no contractual revision frequency and the Accepted Programme can legally remain unchanged for the duration of the contract — a position no competent client should accept. The dangerous gap appears after compensation events. The contract is unambiguous: a revised programme is submitted when a compensation event has occurred. In practice, many Contractors submit time impact analyses (TIAs) as part of compensation event quotations under Clause 62 but do not always update the Accepted Programme to reflect the time effects once the CE is implemented. The result is an Accepted Programme that no longer matches reality — completed CE work shows as planned future work, agreed extensions to planned completion are not reflected, and the next CE assessment under Clause 63 will be based on a programme that is materially out of date. NEC users' group commentary has flagged this drift as one of the principal sources of dispute on live NEC contracts. The Project Manager's instruction power under Clause 32.2 is the antidote to drift. If the Accepted Programme is more than one cycle out of date, the Project Manager should instruct a fresh revision and require it within the period stated in Contract Data Part Two (typically two weeks). Tolerance of repeated late submissions effectively waives the contract's programme discipline, and the commercial consequences appear later in Clause 63 disputes over the basis of CE assessment. ### The acceptance loop — and why silence is not acceptance Once a revised programme is submitted, Clause 31.3 governs the acceptance process — the same provision that applies to the first programme. The Project Manager has two weeks (or the period stated in Contract Data Part Two) to either accept the revision or to notify the Contractor of non-acceptance, with one of the four contract-stated reasons in writing. The four reasons under Clause 31.3 are: that the Contractor's plans are not practicable; that the programme does not show the information the contract requires; that it does not represent the Contractor's plans realistically; or that it does not comply with the Works Information / Scope. A reason for non-acceptance that does not fall within these four categories is not contract-valid. A Project Manager who refuses acceptance because, for example, the new planned completion date is later than the previous one, has not given a contract-valid reason. The Contractor can challenge the non-acceptance and, if necessary, refer the dispute to adjudication. Project Managers who use non-acceptance as a commercial lever rather than a quality control mechanism tend to find that this behaviour surfaces at adjudication and is judged unfavourably. Silence is the most commercially dangerous response. NEC4 ECC was clarified to make it explicit that silence does not equal acceptance — the Project Manager must either accept or notify non-acceptance, and the absence of either keeps the previous Accepted Programme in force. This is the opposite of the position under some bespoke contract forms where the contractor relies on tacit acceptance. Under NEC4, a Project Manager who simply does not respond to a Clause 32 submission has left the Accepted Programme unchanged — and a subsequent compensation event will be assessed against the stale programme, which usually disadvantages the client because the stale programme does not reflect the current state of the works. The practical implication for Project Managers is procedural discipline. Every Clause 32 submission requires a substantive response within two weeks — either an acceptance, or a non-acceptance with a contract-valid reason and (ideally) a clear statement of what the Contractor would need to change to make the next submission acceptable. Project Managers who treat programme acceptance as an administrative chore rather than an active contract management responsibility create the commercial exposure that surfaces later in Clause 63 disputes. ### Common failure modes — and the cost at Clause 63 quantum Five failure modes recur on live NEC4 contracts, and all of them hurt at the point where compensation events are quantified under Clause 63. The first is late submission by the Contractor — revisions that do not arrive within the stated interval, or that arrive only when a CE is being assessed. The pattern weakens the Contractor's position because the programme being relied on at CE time is, by definition, not current. The second is incomplete submissions that fail Clause 32.1. A revision that shows updated dates but does not show actual progress, methods and resources changes, or the effects of preceding CEs, is not a compliant revision. The Project Manager can refuse acceptance under Clause 31.3(2). The Contractor who submits a thin revision and waits to see whether it is accepted is taking the risk that the previous (stale) Accepted Programme remains the reference document for the next CE quantum assessment. The third is Project Manager silence — Clause 32 submissions that receive no formal response within two weeks. As noted above, silence keeps the previous Accepted Programme in force. The cumulative effect of repeated silence is an Accepted Programme that may be six or twelve months out of date by the time a significant CE arises, with consequences for both parties: the Contractor cannot rely on the programme to support its TIA, and the Client cannot rely on it to constrain the TIA the Contractor produces. The fourth is non-acceptance for invalid reasons. A Project Manager who refuses acceptance because the new completion date is uncomfortable, or because the methods statement has changed, or because additional Time Risk Allowances have been added, has not used Clause 31.3 correctly. The four reasons are exhaustive; commercial discomfort with the revision is not among them. If the revision shows the Contractor's genuine plan, includes contract-required information, and is practicable, it should be accepted — even if the Client would prefer the programme to look different. The fifth is the missed compensation-event revision. A CE has occurred, the time impact has been assessed and accepted under Clause 63, but the Accepted Programme has not been updated to reflect the time impact. The next CE assessment then uses a programme that does not show the previous CE's effect, and the Contractor has to argue from a stale baseline. NEC4 users' group commentary repeatedly highlights this as the single most common source of CE quantum disputes on live programmes — and it is entirely preventable through routine application of Clause 32. ### What a defensible Clause 32 revision looks like A revision that satisfies the contract's intent — rather than its administrative minimum — has the same four qualities as the Accepted Programme it replaces: it is current, it is honest about risk, it has a genuine critical path, and it connects to the other project controls outputs. The currency test is the easiest to apply: the data date is aligned with the actual reporting period, every operation that has started shows real progress, and the forecast logic recalculates from the data date rather than from the original plan. The honesty-about-risk test asks whether the time impacts of preceding compensation events are reflected in planned completion, whether Time Risk Allowances on remaining activities reflect the risks the Contractor has actually identified, and whether early warnings notified under Clause 15 have either been incorporated into the programme or have been explicitly noted as still under assessment. A revision that ignores a notified Clause 15 matter because it has not yet been quantified is not honest about risk; the matter should be visible in the programme even if its impact is still being worked out. The critical-path test asks whether the activities on the longest path through the network are the activities a knowledgeable observer would expect to be driving the programme. After several rounds of revision, critical paths can drift in ways that do not reflect the technical reality of the work — long-lead procurement that should still be critical drops off the path because durations have been compressed, while administrative activities with overstated durations appear on the critical path because the planner has added float in the wrong places. A revision that produces a critical path inconsistent with the programme's technical structure is a revision that has been driven by output rather than by logic. The integration test asks whether the revision is consistent with the cost forecast, the risk register, and the early warning log. An Accepted Programme that shows planned completion three months later than the previous version, but where the cost forecast has not been updated to reflect the extended time, has not been properly integrated. The acceptance of the revision under Clause 31.3 should be conditional on the Contractor providing — or having provided — the corresponding updates to the cost forecast and the risk register. A revision accepted in isolation, without these supporting updates, weakens the project controls function and creates audit exposure that will surface at the next gateway review. ### Putting it together Clause 32 is the contract's answer to the problem of stale baselines. Without it, the Accepted Programme would be a one-time snapshot that gets less useful as the project moves on. With it, the Accepted Programme is a continuously refreshed picture of the Contractor's intentions — and the reference document against which compensation events are assessed under Clause 63. The mechanism is straightforward; the discipline of applying it is not. The single most important thing for both parties to understand is that Clause 32 is not optional and not administrative. The Contractor who skips revisions when the project is busy, or submits thin revisions that do not meet Clause 32.1, weakens its own position at the next CE assessment. The Project Manager who does not respond to revisions within the two-week period, or who refuses acceptance for reasons outside Clause 31.3, weakens the client's ability to rely on the programme as a basis for CE quantum. Both behaviours surface as disputes that could have been prevented. SOMA supports NEC4 ECC clients on UK infrastructure, defence and nuclear programmes — including programme assurance, Clause 32 revision discipline, CE time impact analysis, and the Clause 63 quantum work that depends on a current and defensible Accepted Programme. The standard the contract sets for programme management is achievable, but only when both parties treat the Clause 32 cycle as a live management process rather than a paperwork burden. That is the position SOMA helps clients reach. ### Frequently asked questions **What does NEC4 Clause 32 require?** NEC4 ECC Clause 32 requires the Contractor to submit a revised programme showing actual progress, the effects of progress on remaining work, changes to methods and resources, the effects of every compensation event, the effects of early warning matters, and any other changes the Contractor proposes. The Project Manager accepts the revision as the new Accepted Programme, or notifies non-acceptance with one of the four reasons stated in Clause 31.3, in each case within two weeks of submission. **How often must the Contractor submit a revised programme under NEC4 Clause 32?** The interval is stated in Contract Data Part Two. On UK infrastructure programmes it is typically set at 4 to 8 weeks. Revisions are also required after each compensation event, within the period stated after the Project Manager instructs a revision, and whenever the Contractor chooses to submit one. If Contract Data Part Two leaves the interval blank, there is no contractual frequency — a position no competent client should accept. **What is the difference between NEC4 Clause 31 and Clause 32?** Clause 31 covers the first programme — when it is submitted, what it must contain, and the four reasons under Clause 31.3 that the Project Manager can give for non-acceptance. Clause 32 covers every subsequent revision to that programme. The content requirements of Clause 32 are similar to (and broader than) Clause 31 because each revision must additionally show actual progress, the effects of progress on remaining work, and the effects of every compensation event that has occurred since the previous Accepted Programme. **Does silence by the Project Manager count as acceptance of a Clause 32 revision?** No. NEC4 ECC is explicit that silence does not equal acceptance. The Project Manager must either accept the revision or notify non-acceptance with one of the four reasons in Clause 31.3, in each case within two weeks. If the Project Manager does not respond, the previous Accepted Programme remains in force — which usually disadvantages the client at the next compensation event assessment because the reference programme no longer reflects the current state of the works. **What happens at a compensation event assessment if the Accepted Programme is out of date?** Under Clause 63, the time impact of a compensation event is assessed against the current Accepted Programme. If the Accepted Programme is months out of date because Clause 32 revisions have not been submitted or accepted, the assessment is based on a programme that no longer reflects the actual state of the works. Completed activities still appear as planned future work; crystallised risks are not reflected; and the time impact analysis will either over-state or under-state the true effect of the new CE. NEC users' group commentary identifies this drift as the single most common source of CE quantum dispute on live NEC4 contracts. --- ## How to Challenge a Contractor's Schedule (Without Starting a Fight) URL: https://www.somaprojectcontrols.com/resources/guides/challenging-a-contractors-schedule Subtitle: The questions that distinguish a robust programme from a presentation schedule — and how to ask them without triggering a dispute. Published: 2026-04-23 · 8 min read ### Why contractor schedules are optimistic by design A schedule submitted by a contractor for client acceptance is not primarily a planning tool. It is a commercial document. It supports the contractor's claim for the programme-related component of their price. It establishes the baseline against which compensation events will be assessed. It tells the story the contractor wants the client to believe about how the project will be delivered. None of this means it is dishonest — most contractors produce schedules in good faith — but it does mean that the interests shaping the schedule are not aligned with the client's interest in an accurate picture of delivery risk. The structural pressure toward optimism is real and pervasive. Tendering contractors who submit more realistic — and therefore longer — schedules lose work to competitors who show what clients want to see. Delivery contractors who revise their programme to show a realistic completion date later than contractually required must justify the revision commercially. Schedulers who want to show their management team a programme that looks achievable will round down durations and add float to the wrong places. The result is a population of contractor-submitted schedules in which optimism bias is the norm rather than the exception. Client-side schedule assurance exists precisely to correct for this structural bias. Not by assuming the contractor is acting in bad faith, but by applying professional scepticism to the schedule and asking the questions that surface whether the plan is genuinely achievable or whether it represents a best-case scenario dressed up as a central estimate. The challenge is to do this in a way that is technically rigorous, commercially fair, and professionally constructive — asking hard questions without triggering defensiveness that shuts down the conversation. The ten questions in this guide are the ones that consistently reveal the most about a schedule's credibility. They are structured to be asked in a face-to-face review meeting, but they apply equally to a written schedule review report. The framing matters: every question is an invitation to explain, not an accusation. The contractor who can answer them clearly and specifically has built a schedule worth accepting. The one who cannot has revealed where the programme needs more work. ### The ten questions Float. Ask where the float is and why. A schedule that shows planned completion exactly on the contractual completion date, with no float anywhere in the network, is a schedule that has been built to the contract deadline rather than to a realistic plan. Under NEC4, the difference between planned completion and contractual completion is commercially significant — it determines how compensation events are assessed. Under other contract forms it tells you whether the contractor has any schedule resilience at all. Ask the contractor to show you the activities with the highest total float and explain what they represent. Activities with unexplained high float usually indicate missing logic — the activity is not properly connected to the downstream work it should be driving. Logic. Ask about the basis of the key dependencies. For the three or four most critical dependencies in the schedule — the ones where the relationship between activity A and activity B is what is driving the completion date — ask the contractor to explain why the relationship is structured the way it is. Experienced planners have immediate, specific answers: "we cannot start the mechanical installation until the structural steel frame is complete and inspected, because the mechanical supports hang from the secondary steelwork." When the answer is vague — "they're logically dependent" — or when the logic turns out to be a hard constraint rather than a genuine dependency, the schedule's reliability as a forecasting tool is reduced. Resource loading. Ask which packages are resource-loaded and what the critical resource assumptions are. An unresourced schedule can be delivered on any imaginable timescale if you are willing to assume unlimited labour and plant. Ask specifically: at peak, how many of each key trade will be required? Has the contractor confirmed those resources are available? If the answer is "this schedule assumes we can get whatever labour we need, when we need it," the schedule is planning fiction. If the answer identifies specific subcontractors, confirmed resource commitments, and realistic productivity assumptions, the schedule is grounded in reality. Critical path. Ask the contractor to walk you through the critical path — not from a printed report, but verbally, activity by activity. A planner who genuinely understands their programme can trace the critical path in conversation: "civils starts on this date and runs fourteen weeks to drainage completion; drainage completion is the predecessor for the services duct install, which takes six weeks; services duct completion is the predecessor for reinstatement, which runs to practical completion." If the planner cannot walk the critical path without looking at a report, or if the path they describe does not match the logic in the programme, the critical path has been generated by the software rather than designed by the planner. Baseline versus current. Ask when the programme was last substantively updated and how it has been revised since the baseline. A programme that has been running for six months and whose logical structure is identical to the original tender programme has not been maintained — it has been status-updated, which is a much weaker activity. Ask specifically: what has changed since the last revision? What activities have been resequenced, what durations have been revised in light of actual productivity, what risks have been reflected in TRA adjustments? A programme that cannot answer these questions has been produced for reporting rather than for management. Compensation events. Ask which compensation events have been notified and how they are reflected in the programme. Compensation events that have been agreed in principle but not yet formally assessed should appear in the programme — either as additional activities, as extended durations on affected activities, or as revised logic. If the contractor has a backlog of unassessed compensation events that are not in the programme, the programme is not an accurate picture of the project. Ask for the compensation event log alongside the programme and check whether the entries are consistent with each other. Weather and access allowances. Ask how weather and access constraints are modelled. On a UK civil engineering programme, weather is a material schedule risk, particularly for earthworks, concrete pours, and highway works. The programme should show how weather windows have been incorporated — either as explicit non-working periods, as extended durations on weather-sensitive activities, or as TRAs. A programme that assumes twelve working months of weather-clear productivity on an exposed site in Scotland is not credible. Ask the contractor to identify the weather-sensitive activities and explain how weather risk is represented. Commissioning logic. Ask about the logic connecting construction completion to handover. Commissioning sequences are frequently underplanned relative to the rest of the programme. The instinct is to plan construction in detail and leave commissioning as a block of time at the end. Ask to see the commissioning activities and their dependencies: which systems need to be commissioned before others can start? What are the regulatory or client hold points? What is the assumed duration for integrated testing and what is the basis for that assumption? The commissioning plan is where many infrastructure projects lose weeks and months that were never built into the programme. Procurement lead times. Ask about the critical procurement items and how their lead times are modelled. Long-lead equipment — switchgear, transformers, specialist plant — should appear in the programme as explicit procurement activities with durations based on confirmed supplier quotes or tracked market data, not on wish-list assumptions. Ask the contractor to identify the three or four items with the longest procurement lead times and show where they sit in the programme and on the critical path. Equipment that is off the critical path but only marginally so, and that has a long lead time with limited supply chain flexibility, is a risk that should be in the risk register as well as the programme. Handback and testing. Ask about the conditions required for handover and how they are reflected in the programme. Practical completion or handback requirements — snagging periods, O&M documentation, training, regulatory sign-offs, insurance compliance — often take significantly longer than planned. Ask the contractor what the handover conditions are under the contract and how the programme shows those conditions being met. A programme that ends with "practical completion" as a single milestone, with no activities representing the final inspection, documentation, and sign-off process, is a programme that has not been planned to the end of the project. ### What to do with the answers The ten questions produce one of three outcomes for each topic: a clear and credible answer that gives confidence in that aspect of the programme; a vague or incomplete answer that identifies an area for further investigation; or an answer that directly contradicts the schedule data and reveals a structural problem. The pattern of outcomes across the ten questions tells you more about the programme than any automated metric check. A programme that answers eight or nine of the ten questions clearly and specifically, with the remaining one or two identified as areas where the contractor acknowledges the plan needs to be developed further, is a programme worth accepting with conditions. The conditions should be specific: "the commissioning logic needs to be developed to activity level before the next revision" or "the weather-sensitive activities should have explicit TRAs added." Accept the programme against the evidence that exists, not against a theoretical ideal, and set clear expectations for what the next revision needs to contain. A programme where four or five questions receive vague or incomplete answers is a programme that is not ready to be accepted. The appropriate response is a written schedule review report that identifies the specific deficiencies, explains why each one matters, and sets out what the contractor needs to address before resubmission. This report is not a rejection — it is a specification for what a credible programme looks like on this particular project. Framing it as guidance rather than criticism ("we need the commissioning sequence developed to this level of detail" rather than "the commissioning sequence is inadequate") maintains the collaborative tone that makes the subsequent revision more productive. A programme where the answers to the critical path, logic, or compensation event questions directly contradict the schedule data is a programme that has been produced for presentation rather than for management. This is the most difficult conversation to have without triggering defensiveness, because it implies that the schedule has been constructed to tell a story rather than to model the work. The most effective approach is to be specific about the contradiction rather than making a general observation about quality: "The programme shows a finish-to-start dependency between the structural frame and the mechanical installation, but when I asked about the commissioning logic you described the two packages running concurrently. Can you help me understand how those two things are consistent?" Specific contradictions invite specific explanations; general quality observations invite general defensiveness. The broader principle is that schedule assurance is a conversation, not a verdict. The objective is a programme that accurately represents how the project will be delivered, that the contractor is committed to, and that the client can use to make decisions about resources, risk, and commercial exposure. A programme accepted after a rigorous but constructive challenge is more valuable than one waved through without scrutiny — because it is more likely to be a genuine plan rather than a presentation. Contractors who are asked hard questions and answer them well produce better programmes next time. Contractors who are never asked them do not. --- ## QSRA vs QCRA: Meaning, Methodology, and When Each Is the Right Answer URL: https://www.somaprojectcontrols.com/resources/guides/qsra-vs-qcra Subtitle: Two of the most important tools in quantitative risk analysis, frequently confused. Here is what each acronym means, how the methodologies differ, what each produces, and how to decide which your programme needs — with worked UK rail, water and nuclear examples. Published: 2026-04-23 · 8 min read ### The short answer QSRA — Quantitative Schedule Risk Analysis — answers the question: given the risks and uncertainties on this programme, what is the realistic range of completion dates, and what is the probability of hitting any given date? QCRA — Quantitative Cost Risk Analysis — answers the equivalent question for money: given the same risks, what is the realistic range of final costs, and what contingency is defensible at a given confidence level? Both are Monte Carlo simulations. Both draw on the same risk register and three-point estimates. Both produce S-curves and tornado charts. The difference is what they are modelling: schedule duration and float in the QSRA; budget lines and cost packages in the QCRA. Running both together — an integrated QCSRA — lets you see the cost consequence of schedule risk directly, rather than inferring it. ### How a QSRA works A Quantitative Schedule Risk Analysis starts with a logic-linked schedule — typically built in Primavera P6, Asta Powerproject, or Microsoft Project. The schedule must have proper relationships between activities, realistic durations, and minimal artificial constraints. A schedule with hundreds of mandatory dates baked in will not respond meaningfully to risk-driven delays, because the constraints prevent the model from propagating the uncertainty through the network. Each activity duration is then given a three-point estimate — optimistic, most likely, and pessimistic — usually using a triangular or PERT distribution. On top of this, discrete risk events from the risk register are applied: risks that might delay specific activities or chains of activities, each with a probability of occurring and an impact range. The Monte Carlo engine runs the schedule thousands of times, each time sampling random values from the input distributions. On some iterations, the groundworks go well and finish early. On others, poor ground conditions extend them by six weeks. The engine aggregates those thousands of outcomes to produce a distribution of completion dates — which is your S-curve. The QSRA output tells you the P50 completion date (the median outcome — you have a 50% chance of finishing by this date) and the P80 (an 80% confidence target, typically what gets submitted to clients and funders). The tornado chart shows which activities and risks are driving the most variability in the completion date — the ones where mitigation effort is most likely to bring the P80 date in. A good QSRA also surfaces merge bias: the systematic optimism built into network logic when multiple converging paths exist. Even if each individual path looks achievable, the project must complete all of them — and the probability of all paths finishing on time simultaneously is far lower than the probability of any one of them finishing on time. Deterministic schedules routinely underestimate the completion date as a result. A QSRA corrects for this. ### How a QCRA works A Quantitative Cost Risk Analysis starts with a cost estimate — usually structured by Work Breakdown Structure, with costs broken into base estimate lines and, separately, risk provisions. The base estimate should be the best deterministic forecast of what the project costs if things go broadly to plan. Any contingency already embedded in line items needs to be stripped out before the model runs, because the QCRA is what generates the contingency — double-counting produces inflated confidence levels. Three-point estimates are applied to each cost line: the optimistic and pessimistic values around the base reflect estimating uncertainty — how well you can actually pin down the cost of that package at this stage of the project. This is separate from discrete risks: a ground-condition risk that might add £2m to civils if triggered is a different beast from the ±15% estimating uncertainty on the structural steelwork package. Risk events from the register are applied as discrete inputs: each has a probability of occurring and a cost impact range. A QCRA model that only models risks and ignores base estimate uncertainty will underestimate the spread of outcomes. Both layers — base uncertainty and discrete risks — need to be in the model for the S-curve to be credible. Correlation matters significantly in cost models. If two work packages share the same subcontractor, the same ground conditions, or the same design risk, they are not independent. If ground conditions are poor, both the civils and the drainage packages suffer. Ignoring correlation produces a model that artificially dampens the spread of the S-curve, because it assumes lucky outcomes on one package are offset by unlucky ones on another. In practice, risks cluster. A credible QCRA builds in correlation explicitly. The output is a cost S-curve: P50, P80, and P95 cost figures, with the tornado chart showing which estimate lines and risks are driving the spread. The P80 is typically what gets approved as the funding ceiling on UK public sector programmes — it is the figure required by HM Treasury Green Book guidance for major projects, and the figure MoD CADMID Main Gate Boards expect to see at Concept-to-Assessment and Assessment-to-Demonstration transitions. ### The relationship between the two Schedule risk and cost risk are not independent. A programme that runs four months late also incurs four months of site overheads, four months of extended preliminaries, four additional months of inflation exposure, and potentially liquidated damages. The cost consequence of schedule risk is often the largest single driver of cost overrun on major programmes. An integrated QCSRA models this relationship explicitly: schedule delays drive cost overruns in the model, rather than being calculated separately and added afterwards. This is technically more demanding — you need a schedule that is resource-loaded with time-dependent costs — but it produces a more honest picture. The P80 cost figure from an integrated model is invariably higher than one from a standalone QCRA that ignores schedule risk, because the integrated model captures the compounding effect. On smaller projects, or where time and budget are limited, it is common to run one analysis rather than both. The choice depends on what the decision-maker needs. If the primary question is "will we finish on time?" — a milestone-driven contract, a handback obligation, a regulatory deadline — QSRA is the priority. If the primary question is "how much contingency do we need to hold?" — a funding submission, a board sanction request, a contract negotiation — QCRA is the priority. When both questions matter, and when the programme is complex enough that schedule risk is a material driver of cost risk, the integrated QCSRA is the right answer. It takes more resource to build and run, but it avoids the false comfort of a cost model that does not account for the thing most likely to blow the budget. ### When you need each Run a QSRA when: you are approaching a major programme milestone and need a defensible confidence level on the date; when your client or funder requires a P80 date; when the schedule is network-complex with multiple converging paths; when you suspect merge bias is making the headline programme more optimistic than it looks; or when you want to identify which activities and risks are most likely to drive a delay. Run a QCRA when: you are preparing a funding submission and need a defensible cost confidence level; when the contract requires risk-quantified contingency; when the base estimate is at an early stage (Class 3 or above) and estimating uncertainty is high; or when a board or sponsor needs to understand what contingency they are approving at a given confidence level. Run both — integrated — when: the programme is large enough that schedule delay is a material driver of cost; when you have a mature, logic-linked, resource-loaded schedule that can serve as the model backbone; when the decision-maker needs to understand both schedule confidence and cost confidence together; or when a gateway review, Treasury approval, or independent review requires it. A note on tools: the choice of software is less important than the quality of the inputs. @Risk for Excel handles QCRA well and is widely used for cost-only models. Primavera Risk Analysis (Pertmaster) and Safran Risk are the leading tools for integrated schedule-cost risk analysis. Acumen Risk and ARM are also used on UK programmes. The underlying Monte Carlo methodology is the same across all of them; the differences lie in workflow integration with the schedule and in how correlation is specified. If you are commissioning a QRA from a consultant, ask specifically whether the model includes base estimate uncertainty as well as discrete risk events, and whether correlation has been modelled. These two questions will tell you quickly whether you are dealing with someone who understands the craft. ### Frequently asked questions **What does QSRA stand for?** QSRA stands for Quantitative Schedule Risk Analysis. It is a Monte Carlo simulation applied to a project schedule that produces a probability distribution of completion dates, rather than a single deterministic forecast. The typical output is an S-curve showing the likelihood of completion on or before any given date, with reference points at P50 (median), P80 and P95 confidence. Inputs are three-point estimates on activity durations, discrete risk events mapped to the activities they could impact, and correlation between activities that do not move independently. **What does QCRA stand for?** QCRA stands for Quantitative Cost Risk Analysis. It is a Monte Carlo simulation applied to a project cost estimate that produces a probability distribution of final cost outcomes. The output is an S-curve showing the probability of completing at or below any given cost figure, with P50, P80 and P95 reference points. Inputs are three-point estimates on cost elements (typically WBS lines or unit rates), discrete risk events mapped to the cost elements they could impact, and correlation between cost elements that move together. **When do you need a QSRA, when do you need a QCRA, and when do you need both?** Run a QSRA when approaching a programme milestone that needs a defensible completion-date confidence, when the schedule is network-complex with multiple converging paths, when a P80 date is required by client or funder, or when merge bias is suspected. Run a QCRA when preparing a funding submission needing defensible cost confidence, when the contract requires risk-quantified contingency, or when the base estimate is at an early class (Class 3 or above per AACE 18R-97). Run both as integrated QCSRA when the programme is large enough that schedule delay is a material cost driver, when decision-makers need cost and schedule confidence together, or when a gateway review / Treasury approval / IPA assurance requires it. **What software is used for QSRA and QCRA in the UK?** On UK programmes the leading tools are: @Risk by Palisade (cost-focused, runs on Excel, dominant for QCRA-only work); Safran Risk (schedule-focused, integrates with Primavera P6 for QSRA and integrated QCSRA); Acumen Risk by Deltek (schedule and cost, integrated workflow); and Primavera Risk Analysis (formerly Pertmaster, still used on some legacy programmes but Oracle has placed it on extended support — security fixes only, no new features). The underlying Monte Carlo methodology is the same across all of them. The differences lie in workflow integration with the schedule, how correlation is specified, and reporting. The reference standards are AACE International Recommended Practices 57R-09, 113R-20 and 123R-22 for integrated cost-schedule risk analysis. **Does a QRA need a fully integrated cost-schedule model?** Not always. Many programmes start with a QSRA against the schedule and a separate QCRA against the cost estimate, then move to integrated QCSRA at major gates where the trade-off between cost and time contingency is a live decision. Integration adds modelling effort and demands a clean WBS / CBS alignment — the schedule activities and the cost elements have to map cleanly. The benefit of integration is that cost-time trade-offs (acceleration, scope changes, mitigation buys) can be evaluated against a single sampled outcome rather than two disconnected models. AACE 113R-20, 57R-09 and 123R-22 are the three RPs that cover different integration approaches. **What questions tell you if a QRA was done properly?** Two diagnostic questions cut through quickly. First: does the model include base estimate uncertainty (three-point estimates on durations and costs) as well as discrete risk events from the risk register? A model with only discrete risks and no underlying uncertainty under-states the spread. Second: has correlation between risks and between activities been modelled explicitly? Zero correlation is almost always wrong on real projects — risks bunch around common causes (a resource shortfall affects multiple activities, a market shift affects multiple cost lines). If the answer to either question is no, the QRA is producing a number rather than a defensible confidence position. --- ## Earned Value Management Under NEC4 — What the Contract Actually Requires URL: https://www.somaprojectcontrols.com/resources/guides/evm-under-nec4 Subtitle: How EVM and NEC4 interact, what the contract demands, and how to build a system that satisfies both the commercial team and the programme director. Published: 2026-04-23 · 9 min read ### The problem with EVM on NEC4 programmes Earned Value Management and NEC4 are not natural partners. EVM was developed in a fixed-scope, fixed-price environment — the US Department of Defense supplier base in the 1960s — where the performance measurement baseline was set at contract signature and changes were exceptional. NEC4 is built on the assumption that scope changes constantly, that compensation events flow continuously, and that the Accepted Programme is a living document updated every eight weeks. This is not a theoretical tension. On an NEC4 programme with active compensation events, the performance measurement baseline changes every month. A standard EVM system that calculates variance against a fixed baseline will show variance that is partly genuine performance deviation and partly the effect of scope changes that have been properly assessed and agreed. Untangling the two is the central EVM challenge on NEC4 work. The solution is not to abandon EVM — it remains the most rigorous tool available for tracking delivery performance against plan. The solution is to implement it in a way that reflects the NEC4 contract structure: a rolling baseline that incorporates agreed compensation events, performance measurement against the current Accepted Programme, and variance analysis that separates scope change from genuine performance deviation. ### What NEC4 actually requires NEC4 ECC core clauses do not mandate Earned Value Management by name. What clause 32 requires is that the Contractor submits a revised programme when: the Accepted Programme shows the wrong completion date; actual progress differs from planned; or when instructed by the Project Manager. What clause 50 requires is that the Contractor applies for interim payment based on the amount due under the contract. EVM as a formal discipline is typically introduced through the contract data and Z clauses — bespoke additions that specify the EVMS standard the contractor must follow, the reporting frequency, the data that must be submitted, and how the performance measurement baseline is maintained. On major UK infrastructure programmes, these Z clauses increasingly reference AACE recommended practices (specifically 11R-88, the EVMS standard) or NEC's own Earned Value Management guidance. Where EVM is not contractually mandated, it is increasingly expected. National Highways, HS2, Sellafield and major water company clients all have supply chain expectations around EVM that are enforced through the project controls and reporting requirements set at kick-off — and on the defence side, MoD CADMID Demonstration and Manufacture contracts typically write the EVMS requirement directly into the contract data, referencing AACE 11R-88 or the MoD's own EVMS guidance. A contractor who cannot produce BCWS, BCWP, ACWP and EAC in the format the client expects will fail the first controls review. The practical implication: if you are working on a major NEC4 programme, assume EVM is required whether it is explicitly specified or not. Design your project controls system to support it from day one. ### Building the performance measurement baseline on NEC4 The performance measurement baseline (PMB) on an NEC4 programme is built from the Accepted Programme — the agreed, time-phased plan for delivering the works. Every activity in the schedule needs a budget value (BCWS at completion) and a method for measuring physical progress (the earned value technique). Choosing the right earned value technique for each activity is one of the most important decisions in setting up an NEC4 EVMS. The options range from fixed formula (0/100 or 50/50 — simple but crude) to weighted milestones (appropriate for design deliverables) to percent complete (flexible but subjective) to level of effort (for management activities that consume resource throughout the programme). Choosing percent complete for a 26-week construction activity with no intermediate milestones means progress measurement is whatever the foreman says it is. That is not earned value — it is opinion. On NEC4 programmes with active compensation events, the PMB must be updated when a compensation event is implemented. This means the baseline is not a single fixed point: it is a version-controlled document with a clear history of when each change was incorporated and why. The version control discipline is not optional — it is what allows you to calculate performance against the right baseline and to explain variance to a client who will ask why the numbers have moved. ### The four EVM metrics that matter BCWS (Budgeted Cost of Work Scheduled) is what you planned to spend on the work planned to be done by today. This is your baseline — it comes directly from the time-phased PMB and changes only when the baseline is updated for an agreed compensation event. BCWP (Budgeted Cost of Work Performed) is the budget value of the work actually completed. This is earned value — it is what gives EVM its name. If you planned to spend £100k on an activity and you have completed 60% of it, your BCWP is £60k regardless of what you have actually spent. This is the key insight of EVM: progress is measured in budget terms, not cost terms, so performance and cost are tracked independently. ACWP (Actual Cost of Work Performed) is what you have actually spent on the work done to date. On NEC4 programmes this comes from the payment mechanism — the amount applied for and certified under the contract. The relationship between BCWP and ACWP is your cost performance index (CPI = BCWP / ACWP). A CPI below 1.0 means you are spending more than planned to achieve the work done. EAC (Estimate at Completion) is your current forecast of total final cost. The simplest EAC formula — EAC = BAC / CPI — assumes future performance will mirror past performance. This is usually wrong on NEC4 programmes where compensation events and scope changes are the dominant drivers of cost movement. A better EAC incorporates the remaining work forecast at current rates plus agreed and anticipated compensation events. The difference between the formula EAC and the properly-built EAC is often the most interesting number in the monthly report. ### The most common EVM failures on NEC4 programmes The most common failure is not implementing EVM at all and producing a monthly report that shows percentage complete and spend to date as if they were the same thing. They are not. Spend to date tells you how much money has left the account. Earned value tells you what you got for it. The second most common failure is implementing EVM but not updating the PMB for compensation events. A baseline that does not reflect agreed scope changes will show variance that looks like poor performance but is actually scope growth. This is misleading to the client, demoralising to the delivery team, and useless for forecasting. The third failure is choosing percent complete as the earned value technique for every activity and then updating percent complete based on intuition rather than measurement. This produces EV data that is as reliable as the foreman's mood on the day of the update. If physical progress cannot be measured, use weighted milestones or fixed formula. Honest EVM with a simple technique is more useful than sophisticated EVM with unreliable inputs. The fourth failure is producing EV reports that nobody reads because they are not connected to the decisions the programme director actually needs to make. EVM is a leading indicator — it tells you where you are heading before the variance becomes a crisis. If the EV report is not reaching the right people at the right time in a format they can act on, it is a compliance exercise, not a controls tool. ### Frequently asked questions **How does earned value management work under NEC4?** NEC4 does not use the term "earned value" but its Accepted Programme requirements create the structural conditions for EVM. The contractor is required to show the timing of their work and their resource allocation in the Accepted Programme (Clause 31). Progress updates and revised programmes (Clause 32) allow the project manager to track actual versus planned progress. A controls team can implement EVM on a NEC4 contract by defining a Work Breakdown Structure aligned to the Activity Schedule, cost-loading the Accepted Programme, and measuring physical progress against it — using the PMB as the EVM baseline. **What is the Performance Measurement Baseline (PMB) on a NEC4 programme?** The Performance Measurement Baseline is the time-phased, cost-loaded plan against which earned value performance is measured. On a NEC4 contract it is derived from the Accepted Programme: each activity is assigned its budgeted cost, and the PMB is the sum of those budgeted costs over time. Critically, the PMB must be updated every time a compensation event is agreed — the PMB should always reflect currently approved scope. A PMB that is not updated for compensation events produces misleading variance figures and undermines the entire EVM system. **What is the difference between EVM and traditional cost reporting on NEC4?** Traditional cost reporting compares actual spend against budget — it tells you how much money has been spent but not how much work has been done. EVM integrates spend with physical progress: it compares the budgeted cost of work performed (Earned Value) with the actual cost, giving a Cost Performance Index. The critical difference is that traditional reporting cannot distinguish between overspend caused by cost inefficiency and overspend caused by faster-than-planned progress — EVM can. On NEC4, the Accepted Programme provides the physical progress baseline that makes EVM possible. --- ## The DCMA 14-Point Schedule Assessment — What It Is and How UK Programmes Use It URL: https://www.somaprojectcontrols.com/resources/guides/dcma-14-point-assessment-uk Subtitle: A practical guide to the DCMA 14-point schedule health check — what each metric measures, what the thresholds mean, and how to use it on UK infrastructure programmes. Published: 2026-04-23 · 10 min read ### What the DCMA 14-point assessment is The DCMA 14-point schedule assessment is a structured health check for project schedules, originally developed by the US Defense Contract Management Agency. It tests fourteen specific schedule quality metrics — logic, constraints, lags, float, and baseline adherence among them — and produces a pass/fail result against defined thresholds for each. It is not a proprietary tool. The methodology is public and well-documented. On UK infrastructure programmes it has become the de facto standard schedule quality framework, adopted by National Highways, HS2, Network Rail and a growing number of major client programme directors who want an objective, auditable measure of schedule health rather than a planner's assurance that the programme "looks about right." MoD CADMID Demonstration and Manufacture-phase contracts also routinely write DCMA-style screening into the contract data alongside the EVMS reporting clauses, reflecting the assessment's defence origins. The value of the 14-point assessment is that it is reproducible. Any qualified planner applying the same methodology to the same schedule will get the same results. That objectivity is what makes it useful for gateway reviews, contract assurance and supply chain audits — the result is not a judgement call, it is a measurement. ### The fourteen checks explained Logic: the percentage of activities with at least one predecessor and one successor. The threshold is typically 90% or above. Activities with no predecessors or successors are "open ends" — they float freely and do not respond to changes in the network. A schedule with many open ends is not a network; it is a list of tasks with dates attached. Leads: the percentage of activities with negative lags (leads). The threshold is typically 0% — any lead is a concern. Leads create a logic bypass: they allow a successor to start before its predecessor finishes without modelling the actual relationship. They are almost always a workaround for a poorly structured logic network. Lags: the percentage of finish-to-start relationships with a positive lag value. The threshold is typically less than 5%. Lags are not always wrong — a concrete cure time is a legitimate lag — but they are frequently used as a shortcut to make the schedule fit a target date without adding genuine logic. Relationship types: the percentage of relationships that are finish-to-start. Targets typically require more than 90% FS relationships. Start-to-start and finish-to-finish relationships are not inherently wrong, but an overuse of non-FS logic can create a schedule that is difficult to read, update, and trust. Hard constraints: the percentage of activities with constraints other than "as late as possible" or "as soon as possible." The threshold is typically less than 5%. Hard constraints override the network logic — they fix a date regardless of what the predecessors are doing. A schedule with many hard constraints will not respond correctly to changes; delays in predecessors will not flow through to constrained successors. High float: the percentage of activities with total float exceeding a defined threshold (commonly 44 working days). High float is a symptom of logic problems — open ends, missing relationships, or hard constraints that prevent float from flowing correctly. Negative float: the percentage of activities with negative total float. Any negative float is a concern. Negative float means the schedule is telling you that you cannot achieve the target date with the current logic and durations. It is often a sign that the baseline was set to fit a date rather than to reflect a realistic delivery plan. High duration: the percentage of activities with durations exceeding a defined threshold (commonly 44 working days). Very long activities are difficult to track, hard to earn value against, and often indicate a planning level that is too high to be useful for day-to-day controls. Invalid dates: activities with actual dates in the future or forecast dates in the past. These indicate a schedule that has not been properly updated — either the data date has not been moved or progress has not been recorded against completed activities. Resources: the percentage of activities with resource assignments. Thresholds vary by programme type but are typically 90% or above for delivery activities. Unresourced activities cannot be used for resource-loading, cost integration or meaningful Earned Value Management. Missed tasks: the percentage of activities that were forecast to start or finish before the data date but have not done so. High missed task rates indicate a schedule that is optimistic about near-term delivery or that is not being properly updated. Critical path test: whether the critical path is continuous from start to finish and produces a reasonable total float for the longest path. A schedule with a broken or implausible critical path — one with many negative lags or constraints — has failed this test. Critical path length index (CPLI): a measure of schedule efficiency on the critical path. CPLI = (CP duration + total float) / CP duration. A CPLI below 0.95 indicates that the critical path is longer than planned and that completion on the target date is increasingly unlikely. Baseline execution index (BEI): the ratio of completed activities to activities that should have been completed by the data date. BEI = completed activities / (completed + behind schedule activities). A BEI above 0.95 indicates that the programme is executing broadly as planned. Below 0.95, the execution rate is falling behind the baseline. ### How to read a 14-point result on a real programme A single 14-point result is a snapshot. The value is in the trend — whether the schedule is improving or degrading across successive updates. A programme that fails on three metrics consistently is more concerning than one that fails on three different metrics each month. The metrics are not equally important. Logic, hard constraints, and negative float are structural problems — they mean the schedule does not work as a network. High duration and high float are symptoms — they indicate planning quality issues that should be investigated but are not necessarily critical. Missing resources is a reporting problem — it means the schedule cannot support cost integration, which is a separate failure mode. When reviewing a 14-point result for a supply chain contractor, focus first on the logic metrics (open ends, relationship types, leads) and the critical path metrics (CPLI, BEI, negative float). These are the ones that tell you whether the schedule is a genuine delivery tool or a bar chart dressed as a network. If a contractor consistently fails the 14-point assessment and continues to produce schedules that fail the same metrics month after month, the issue is usually not competence — it is priority. The schedule is not being maintained because the delivery team does not see it as useful. That is a controls culture problem, not a software problem, and it requires a different intervention. ### Using the 14-point assessment on UK infrastructure programmes On NEC4 programmes, the 14-point assessment should be applied to the Accepted Programme, not just the working schedule. The Accepted Programme is the contractual baseline — it is what the programme director is accountable for delivering. If the Accepted Programme fails the 14-point assessment, the accountability baseline is unreliable. The assessment should be run by someone other than the planner who built the schedule. Not because planners are dishonest, but because familiarity makes it easy to miss structural problems that are visible to a fresh eye. On major programmes this is typically handled by a client-side project controls team, an independent checker, or a controls assurance function. Reporting 14-point results to the programme director should include the metric, the result, the threshold, and a one-line explanation of what the metric means and why it matters. A table of fourteen numbers with no context is not a controls report — it is data transfer. The insight is in the interpretation. If you are asked to produce a 14-point assessment and do not have a dedicated schedule analysis tool, most of the metrics can be calculated in Primavera P6 using the standard reports and the schedule comparison function. @Risk and Acumen can automate the process. What matters is consistency — apply the same methodology every month so the trend is meaningful. ### Frequently asked questions **What is the DCMA 14-Point Schedule Assessment?** The DCMA 14-Point Schedule Assessment is a set of fourteen structural and performance checks used to evaluate the quality of a project schedule. It was developed by the US Defense Contract Management Agency and is now the de facto international standard for schedule health assessment. It is widely used on UK MoD, infrastructure and major capital programmes — by Network Rail, National Highways, HS2 and the Infrastructure and Projects Authority — both as an internal quality check and as a contractor assurance tool. **What is a passing score on the DCMA 14-Point assessment?** There is no single overall pass/fail score — each of the 14 metrics has its own threshold. Most use a 5% threshold for structural metrics (logic, lags, hard constraints, high float, high duration, missed tasks) and a 0.95 threshold for the two performance metrics (CPLI and BEI). A "passing" schedule typically clears at least 12 of the 14 thresholds. A schedule failing more than four metrics is usually treated as structurally unreliable and re-planned before being used for forecasting or earned value reporting. **What is the difference between CPLI and BEI?** CPLI (Critical Path Length Index) measures schedule achievability — the ratio of critical path length plus total float to the time remaining to complete. A CPLI ≥ 0.95 means the critical path has at least 95% of the available time. BEI (Baseline Execution Index) measures historical performance — the ratio of activities completed on or before their baseline date to activities completed. A BEI ≥ 0.95 means the team is hitting 95% of baseline finish dates. CPLI is forward-looking; BEI is backward-looking. **Are lags ever acceptable in a DCMA-compliant schedule?** A small number of lags is acceptable — the DCMA threshold is 5% of relationships. Some lags are legitimate (concrete cure times, regulatory waiting periods, contractually-defined gaps between handovers). The risk is using lags to absorb scope or resource issues that should be modelled as discrete activities. A schedule with more than 5% lags is usually masking poor logic — either replace lags with activities representing the underlying work, or document explicitly why each lag is justified. **Why are hard constraints flagged by the DCMA assessment?** Hard constraints (Mandatory Start, Mandatory Finish, Must Finish On) override the network logic. When applied, the critical path calculation no longer reflects the true sequence of dependencies — it reflects whatever dates have been imposed. A schedule with more than 5% hard constraints cannot be reliably analysed for critical path, float, or earned value forecasting. Use Start No Earlier Than or Finish No Later Than soft constraints where dates need to be controlled without breaking the logic. **Is the DCMA 14-Point assessment mandated on UK government programmes?** No — DCMA-14 is not formally mandated in published UK client guidance (HS2 supply-chain documents, Network Rail Quality Requirements, National Highways planner standards, and the IPA Assurance Review Toolkit do not name DCMA-14). Despite that, it has become the de facto industry standard for schedule quality assessment across UK infrastructure and defence project controls. UK defence primes routinely apply DCMA-14-equivalent checks because of US parent-company practice, and many UK schedulers across rail, highways, nuclear and defence supply chains use it as their internal quality benchmark. Treating DCMA-14 compliance as a baseline for any UK major capital programme is sound practice even where it is not contractually required. --- ## Project Controls in UK Defence — CADMID Lifecycle, MPRP Gateways, IPA Assurance URL: https://www.somaprojectcontrols.com/resources/guides/project-controls-in-defence Subtitle: A practitioner's guide to project controls on UK defence programmes — what the controls function must deliver across the six CADMID phases, how MoD MPRP, IPA and DEF STAN test it, and where SOMA's defence consultancy work plugs in. Published: 2026-04-23 · 11 min read ### What is CADMID? CADMID is the United Kingdom Ministry of Defence's six-phase project lifecycle: Concept, Assessment, Demonstration, Manufacture, In-Service, and Disposal. Every UK defence acquisition programme — from a small radio refresh to a Type 26 frigate — moves through these phases under a structured assurance framework that links each phase to specific gateway reviews, controls deliverables, and decision points. The phases in order: Concept (defining the requirement and outline business case), Assessment (option analysis and full business case), Demonstration (development, integration and testing of the chosen solution), Manufacture (production and acceptance), In-Service (operational sustainment, often spanning decades), and Disposal (decommissioning, withdrawal and asset disposition). Each transition between phases is governed by a Main Gate decision and, on Major Projects, by Infrastructure and Projects Authority Gateway Reviews. Each CADMID phase places different demands on the project controls function. Concept and Assessment focus on option-level risk and cost-confidence analysis under high uncertainty. Demonstration and Manufacture demand full Earned Value Management, Performance Measurement Baseline discipline, and detailed schedule integration. In-Service controls track through-life cost and sustainment over decades. Disposal carries its own commercial, regulatory, and (on radiological or environmental platforms) risk-management complexity. Understanding which CADMID phase a programme is in — and what the controls function must produce at that phase — is the difference between a controls capability that survives Major Projects Review Process scrutiny and one that gets red-rated. The rest of this guide walks through what good looks like at each stage, against the framework that NAO, IPA, and the Single Source Regulations Office actually apply. ### Why defence is different Project controls in UK defence operates within a framework that has no direct equivalent in the commercial infrastructure sector. The CADMID lifecycle (Concept, Assessment, Demonstration, Manufacture, In-Service, Disposal), the MoD Major Projects Review Process, IPA gateway reviews, and the Earned Value Management requirements that apply to many MoD contracts create a controls environment where the demands on schedule, cost and risk management are among the most rigorous in the world. This is not an accident. Defence programmes are publicly funded, often classified, technically complex, and operate at timescales that stretch over decades. The controls framework exists because the consequences of controls failure — cost overruns measured in billions, capability gaps that affect national security, and the NAO scrutiny that follows — are severe. If you work in defence project controls and you have not seen a Major Projects Report, you are not yet in the environment where the controls actually matter. Understanding this framework is not optional for a controls practitioner working on a defence programme. It shapes everything from how the WBS is structured to how QRA results are presented to a Programme Board, and it is what distinguishes a controls function that adds value from one that adds paper. ### CADMID and what controls must deliver at each stage Concept stage is where project controls should begin — and where it most often does not. At concept, the requirement is being defined, options are being assessed, and the feasibility of different approaches is being tested. The controls contribution at this stage is to the business case: credible cost and time estimates that reflect the uncertainty of the concept definition, structured to support option comparison and to identify the key uncertainties that will drive cost and schedule variability. Assessment stage is where the design is developed to the point where a solution can be selected and a cost and schedule baseline can be established. Controls at assessment stage must produce: a Class 3 or better cost estimate (AACE classification); a programme that covers the Demonstration and Manufacture phases at sufficient detail to support gate review; and a risk register that identifies the key threats and opportunities with three-point estimates. The QRA produced at assessment stage is often what the Programme Board uses to set the contingency for the next phase. Demonstration stage is where the selected solution is proven technically and the Manufacture phase programme is confirmed. Controls at demonstration stage must maintain the performance measurement baseline against which EVM is reported, update the QRA as technical risk resolves (or does not), and manage the compensation event or change process as design matures. Manufacture stage is full production — the stage with the greatest cost and schedule exposure and the highest controls intensity. EVMS reporting is mandatory on many MoD Manufacture contracts. The controls function must maintain a fully integrated cost-schedule model, report BCWS, BCWP, ACWP and EAC on the MoD's required cadence, and produce monthly reports that give the Programme Director the leading indicators they need to intervene before problems become crises. ### MoD MPRP and IPA gateway reviews The Major Projects Review Process (MPRP) is the MoD's internal assurance framework for the largest and most complex defence programmes. Programmes on the MoD Major Projects Portfolio are subject to MPRP gates at key decision points — typically at assessment approval, manufacture approval, and in-service review. IPA (Infrastructure and Projects Authority) reviews are government-wide assurance applied to the largest and highest-risk programmes in the Government Major Projects Portfolio. For defence programmes that reach the GMPP threshold, IPA reviews sit alongside MPRP gates and bring additional scrutiny from independent reviewers who are not part of the MoD. What reviewers actually look for at MPRP and IPA gates is different from what programme teams typically prepare for. Reviewers are not primarily interested in the format of the QRA report or the colour of the risk register. They are interested in: whether the programme director can articulate the key cost and schedule drivers and how they are being managed; whether the contingency provision is defensible given the QRA methodology and the risks identified; whether the critical path is genuine and whether the team understands what is driving it; and whether the controls function is providing useful intelligence or just producing reports. The most common failure mode at gateway review is not missing documentation — it is that the controls function has produced documentation that does not reflect reality. A risk register that lists fifty risks with identical probability and impact scores. A QRA that always produces a P80 within 5% of the target figure. A programme that has been constrained to show the required completion date without modelling the logic that connects the activities. Reviewers who have seen many programmes recognise these signatures immediately. ### CADMID gateway reviews — what auditors actually test IPA Gateway Reviews follow a defined progression: Gate 0 (strategic assessment, applied to programmes rather than single projects), Gate 1 (business justification, typically aligned with the Outline Business Case at end of Concept), Gate 2 (delivery strategy, aligned with the Full Business Case at end of Assessment), Gate 3 (investment decision, immediately before contract award and the move into Manufacture), Gate 4 (readiness for service, before In-Service entry), and Gate 5 (benefits realisation and operational lessons learned). At each gate the reviewers test a different question, and the controls evidence required shifts accordingly. At Gate 1 reviewers test whether the cost and time ranges are honest and whether the option set has been genuinely compared — not whether one preferred option has been engineered into looking best. At Gate 2 they test whether the delivery strategy is buildable: whether the Performance Measurement Baseline is achievable, whether the supply chain has the capacity, whether the schedule logic is robust enough to survive contact with the contractor. At Gate 3 the focus is investment confidence — the QRA must demonstrate that the contingency provision is defensible and the risk transfer arrangement to the contractor is realistic. The recurring red flags raised by NAO and the MPRP review teams are remarkably consistent across programmes. A QRA whose P80 sits suspiciously close to the available funding envelope. A schedule with a critical path that runs through float — meaning the path the team thinks is critical is not actually the path that drives completion. An optimism-bias adjustment that has been bolted on at the end of the analysis rather than built into the input ranges, and which the reviewers can therefore strip out to test the underlying numbers. EVMS reports where the earned value line and the actual cost line are nearly identical, indicating that earned value is being reverse-engineered from spend rather than measured from physical progress. A through-life cost model that has not been refreshed since the business case was approved, and which therefore reflects a configuration the in-service programme has long since moved away from. Defensible controls evidence at gate has three characteristics. First, the analysis is traceable — every number in the gate report can be tied back to a model file, a workshop output, a contract data line, or an audited cost report. Second, the assumptions are stated explicitly and tested by sensitivity analysis, so reviewers can see how the conclusions move when the most uncertain assumptions are flexed. Third, the controls team can answer the second-order question without a calculator: what are the three things that, if they went wrong, would breach the contingency provision, and how is each being managed? Programmes whose controls team can give that answer extempore tend to clear gate. Programmes whose controls team needs to refer the question back to the office tend not to. ### EVMS on MoD contracts Earned Value Management System (EVMS) requirements on MoD contracts are specified in the contract data and typically reference either AACE 11R-88 (the Earned Value Management System standard) or the MoD's own EVMS guidance. The requirement is to establish, maintain and report against a performance measurement baseline that integrates the authorised scope, budget and schedule. In practice this means: a WBS that maps to both the contract structure and the technical scope; a schedule that is resource-loaded at the level required for EV measurement; an EVMS that assigns a budget to every WBS element and records earned value against a defined measurement technique; and a monthly report that presents BCWS, BCWP, ACWP, SPI, CPI and EAC in the format specified by the contract data. The most common EVMS failure on MoD contracts is the gap between the contract-required EVMS and the programme's actual planning and reporting system. Contractors often have a separate EVM reporting tool and a separate scheduling tool that are reconciled manually at month-end. The reconciliation is where errors are introduced and where the EV data loses its connection to the delivery reality. An integrated cost-schedule system — where the schedule drives the BCWS and the progress measurement drives the BCWP — is harder to set up but produces data that is genuinely useful rather than technically compliant. Security classification affects how EVMS data is handled. On classified programmes, the cost and schedule data may be classified at a level that affects who can access the reporting system, how data is transferred to the MoD's programme office, and how the programme interacts with non-cleared subcontractors. A controls practitioner working on a classified programme needs to understand the classification level and its implications for data handling before designing the system. ### Common controls failure modes by CADMID phase The failure modes that get programmes red-rated cluster predictably by CADMID phase. At Concept, the recurring pattern is a cost estimate that ignores option-set uncertainty — the team has produced what looks like a three-point range, but each option carries the same percentage uncertainty regardless of how technically mature it is. A bespoke airframe option and a Military Off-The-Shelf variant cannot rationally have the same coefficient of variation on the cost estimate, and reviewers familiar with AACE classification (5 for Concept-stage estimates, 4 at the end of Concept) will press on exactly that point. Closely related is the absence of a reference class — the estimate is built from first principles without any check against what comparable programmes have actually cost, which is the single most effective de-biasing technique available and the one HM Treasury Green Book guidance specifically calls for. At Assessment, the recurring pattern is a QRA that fails Green Book optimism-bias scrutiny. The ranges in the three-point inputs are too narrow, correlation between risks is absent or token, the opportunity side of the distribution is empty, and the resulting P80 sits within touching distance of the deterministic estimate. When the reviewer strips out the late-stage optimism-bias uplift and looks at the underlying model, the uncertainty has been engineered away. The MoD Cost Assurance and Analysis Service and the SSRO both publish guidance on this and both will challenge a QRA whose distribution shape looks too tame for the technical maturity of the programme. At Manufacture, the recurring pattern is EVMS reports that drift from delivery reality — Schedule Performance Index and Cost Performance Index both reported close to 1.00 for months, then a step-change correction when the truth surfaces at a milestone or an independent assessment. The drift is almost always the same root cause: progress is self-reported by package managers who carry the incentive to show momentum, and the earning rules are either undocumented or inconsistently applied, so the BCWP figure is closer to forecast than to physical fact. At In-Service, the recurring pattern is a through-life cost model that has not been refreshed since contract award and which therefore misses obsolescence risk, capability-upgrade cost, and the disposal liability that should have been provisioned through the operating life. Electronic components on a thirty-year platform will go end-of-life multiple times across the service period, and the cost of redesign, requalification and retest is rarely modelled at Concept. A TLC model that assumes today's configuration persists unchanged through the In-Service phase is, by construction, optimistic. The recurring NAO finding on long-running platforms — that the in-service support cost has materially exceeded the figure used in the original business case — is in large part a controls failure at this exact point: the model that supports the original decision is never reconciled against the reality of sustainment as the platform ages. ### What good controls looks like in defence Good project controls in defence is characterised by integration, earliness, and honesty. Integration means the schedule, cost and risk functions work from the same data model and produce consistent outputs — not three separate views that are reconciled in the report. Earliness means controls are embedded from concept stage, not introduced at manufacture when the baseline is already under pressure. Honesty means the QRA model reflects the risks the programme actually faces, not the risks that produce the numbers the Programme Board wants to see. The controls function on a well-run defence programme is not a reporting function. It is an intelligence function. Its job is to give the Programme Director the earliest possible warning of problems — schedule logic that is deteriorating, cost performance that is trending below 1.0, risks that are crystallising faster than the register assumed — so that decisions can be made while options are still available. The worst controls environments in defence are characterised by a separation between the controls function and the delivery team — where the planners and cost engineers are seen as overhead, where the monthly report is produced by the commercial team from data the delivery team does not trust, and where the QRA is something that happens before gateway reviews rather than something that is maintained continuously. If that description fits a programme you are working on, the controls function is not delivering value, and the programme is more exposed than the reports suggest. ### How SOMA supports CADMID programmes SOMA Project Controls works on defence and government programmes through three repeating engagement shapes: independent Quantitative Risk Analysis on Concept and Assessment-stage business cases where the team needs a defensible contingency figure that will withstand IPA and SSRO scrutiny; Earned Value Management System implementation reviews on Demonstration and Manufacture contracts where the EVMS reporting is technically compliant but operationally disconnected from the delivery team; and IPA gateway readiness reviews and through-life cost modelling on long-running In-Service platforms. The work is delivered by senior practitioners who have led controls on UK infrastructure, water, nuclear and defence programmes, and who treat the controls function as an intelligence function for the Programme Director rather than a reporting overhead. The relevant SOMA services for CADMID programmes are Quantitative Risk Analysis, Cost Management & Earned Value, and the Project Controls Advisory engagement. ### Frequently asked questions **What does CADMID stand for?** CADMID stands for Concept, Assessment, Demonstration, Manufacture, In-Service, and Disposal — the six phases of the UK Ministry of Defence's acquisition lifecycle. The framework governs how every UK defence programme moves from initial requirement definition through operational service to eventual decommissioning. **What are the six CADMID phases?** The six CADMID phases in order are: Concept (defining the requirement and outline business case), Assessment (option analysis and full business case), Demonstration (development, integration and testing of the chosen solution), Manufacture (production and acceptance), In-Service (operational sustainment, often spanning decades), and Disposal (decommissioning, withdrawal and asset disposition). Each transition between phases is governed by a Main Gate decision and, on Major Projects, by Infrastructure and Projects Authority Gateway Reviews. **What project controls are required at each CADMID phase?** Project controls demand differs across the CADMID phases. Concept and Assessment focus on option-level risk and cost-confidence analysis under high uncertainty, with QRA used to compare alternatives. Demonstration and Manufacture demand full Earned Value Management, Performance Measurement Baseline discipline, and detailed schedule integration. In-Service controls track through-life cost and sustainment over decades. Disposal carries its own commercial, regulatory, and (on radiological or environmental platforms) risk-management complexity. **Is CADMID still used by the UK MoD?** Yes. CADMID remains the core framework for UK MoD acquisition. It is supplemented by the Major Projects Review Process, the Single Source Regulations Office cost-control regime on non-competitive contracts, and the Infrastructure and Projects Authority's Gateway Review system on Government Major Projects. CADMID describes the lifecycle; MPRP, SSRO, and IPA describe the assurance and oversight applied to it. **How does CADMID compare to commercial project lifecycles?** CADMID differs from commercial capital-project lifecycles in three material ways. First, it explicitly includes In-Service and Disposal phases — defence equipment is operationally fielded for decades and the through-life cost is often greater than the acquisition cost. Second, the assurance overlay is heavier: IPA, NAO, and Single Source Regulations Office scrutiny apply at multiple gates. Third, classification and security requirements affect how cost and schedule data is handled, transferred, and reported. --- ## Project Controls Day Rates UK 2026 — Benchmarks by Role and Sector URL: https://www.somaprojectcontrols.com/resources/guides/project-controls-day-rates-uk-2026 Subtitle: Realistic day rate benchmarks for planners, cost engineers, risk managers and PMO leads across UK infrastructure — inside and outside IR35. Published: 2026-04-23 · 7 min read ### Why day rates vary so much Project controls day rates in the UK span a wide range — from around £300/day for a junior planner on a regional civils project to over £1,200/day for a QRA specialist on a major infrastructure or defence programme. The spread is not arbitrary. It reflects genuine differences in specialisation, programme complexity, sector-specific knowledge requirements, and the supply-demand balance for specific skills. The most consistent drivers of premium rates are: QRA and quantitative risk specialisation (supply is thin relative to demand across all sectors); nuclear and defence sector experience (regulatory context creates a premium over generic infrastructure rates); integrated cost-schedule capability (practitioners who can do both cost and schedule are rarer than those who specialise in one); and Primavera P6 expertise on complex, multi-project programmes (not to be confused with basic P6 familiarity, which the market is saturated with). The figures below are market benchmarks based on advertised day rates, placement agency data and direct engagement rates observed in the UK infrastructure market as of Q2 2026. They represent the range in which most placements occur — outliers exist in both directions. IR35 status affects the net figure significantly and is addressed separately. ### Planning and scheduling roles Junior Planner / Scheduler (0–3 years experience, Primavera P6 or MS Project, works under supervision on single contracts): £280–£380/day outside IR35. Inside IR35 equivalent: £210–£290/day net. Planner / Scheduler (3–7 years, P6 proficient, NEC4 experience, capable of maintaining an Accepted Programme independently): £380–£520/day outside IR35. Inside IR35 equivalent: £290–£400/day net. Senior Planner (7–12 years, complex multi-contractor programmes, DCMA 14-point methodology, schedule risk experience): £520–£700/day outside IR35. Inside IR35 equivalent: £400–£540/day net. Lead Planner / Planning Manager (12+ years, programme-wide planning function, client or Tier 1 environment, gateway review experience): £700–£900/day outside IR35. Inside IR35 equivalent: £540–£695/day net. The premium end of these ranges applies to rail, nuclear, and defence — sectors where sector-specific planning knowledge (possession scheduling, nuclear baseline control, CADMID planning) commands a premium over generic infrastructure rates of 15–25%. ### Cost engineering and management roles Cost Engineer (3–7 years, cost control, EVA, WBS management, monthly cost reporting): £380–£520/day outside IR35. Inside IR35 equivalent: £290–£400/day net. Senior Cost Engineer (7–12 years, estimate development, contingency management, Earned Value implementation, multi-contract programmes): £520–£680/day outside IR35. Inside IR35 equivalent: £400–£525/day net. Cost Manager / Commercial Controls Lead (12+ years, programme-level cost governance, EAC ownership, board-grade reporting): £680–£900/day outside IR35. Inside IR35 equivalent: £525–£695/day net. EVMS Specialist (AACE-trained, MoD or Highways contract EVM implementation): £650–£950/day outside IR35. The EVMS premium is real — practitioners who can set up a compliant EVMS from scratch and train a team to run it are genuinely scarce. Inside IR35 equivalent: £500–£735/day net. Cost estimators at Class 3–5 (AACE classification) who can produce a detailed build-up rather than factored estimates sit at the upper end of cost engineer ranges, particularly on nuclear and defence where estimate class requirements are enforced by contract. ### Risk and QRA roles Risk Manager (register maintenance, workshop facilitation, qualitative risk, monthly risk reporting): £420–£600/day outside IR35. Inside IR35 equivalent: £325–£465/day net. QRA Analyst (Monte Carlo modelling in @Risk, Primavera Risk Analysis or Safran, QSRA or QCRA, not integrated): £550–£750/day outside IR35. Inside IR35 equivalent: £425–£580/day net. Senior QRA Specialist / Integrated QCSRA (AACE-standard methodology, integrated cost-schedule risk, gateway review experience, board-grade QRA reports): £750–£1,100/day outside IR35. Inside IR35 equivalent: £580–£850/day net. The QRA premium is the most consistent premium in the UK project controls market. Most programmes that need a QRA have one opportunity to get it right before a gate review. The premium for a practitioner who will produce a QRA that survives IPA scrutiny rather than one that needs to be rerun is well understood by programme directors who have been through a failed gate review. Sector premium for QRA: defence and nuclear add 20–35% over infrastructure rates for practitioners with demonstrable gateway review experience in those sectors. ### PMO and integrated controls roles Project Controls Coordinator (reporting, data management, dashboard maintenance, supporting senior controls staff): £280–£400/day outside IR35. Project Controls Manager (leading a controls team, integrated schedule-cost-risk reporting, client or Tier 1 environment): £650–£900/day outside IR35. Inside IR35 equivalent: £500–£695/day net. Head of Project Controls / Controls Director (portfolio-level controls function, multiple concurrent programmes, board-level reporting): £900–£1,300/day outside IR35. Inside IR35 equivalent: £695–£1,005/day net. These senior roles are the least price-sensitive positions in the market. Programme directors who need a controls director they can trust to tell them the truth about the programme will pay a premium over market rate to get the right person. The difference between a good and an average controls director is measured in programme outcomes, not day rates. ### IR35 — what it means for day rates Since the April 2021 off-payroll working reforms, IR35 status on public sector and large private sector engagements is determined by the client (the end-client, not the agency). A contractor deemed inside IR35 pays income tax and National Insurance at source, effectively making their take-home pay equivalent to a permanent employee on a similar gross. The practical effect is that contractors inside IR35 typically seek a higher day rate to maintain the same net income — broadly a 25–35% premium over their outside-IR35 equivalent, depending on individual tax position. Many clients have responded by adjusting their rate cards accordingly. On public sector programmes (National Highways, Network Rail, Sellafield, MoD) the default is inside IR35 unless the contractor can demonstrate genuine business-in-business activity. For consultancies providing project controls as a service (rather than individual contractors), IR35 does not apply in the same way — the consultancy is engaged as a business, not as an individual. This is one reason why programme directors increasingly favour consultancy engagements over contractor placements for senior QRA and controls roles: the rate is more predictable and the IR35 determination is the consultancy's problem, not the client's. When comparing rates between contractor and consultancy models, divide the consultancy day rate by 1.25–1.35 to get a rough contractor-equivalent. For QRA and senior controls roles, the consultancy model often works out at similar or lower cost once the agency margin, IR35 uplift and contractor management overhead are included. ### Frequently asked questions **How much does a project controls planner cost per day in the UK in 2026?** UK planner day rates in 2026 range from £280-380/day for a junior planner (0-3 years), £380-520/day for a planner with 3-7 years NEC4 / P6 experience, £520-700/day for a senior planner (7-12 years, DCMA 14-point methodology), and £700-900/day for a Lead Planner or Planning Manager at programme level. Rail, nuclear and defence sectors typically pay 15-25% above these generic infrastructure rates for sector-specific knowledge. Inside IR35 net equivalents are approximately 25-35% lower. **What do QRA specialists charge per day in the UK?** QRA day rates in 2026 split by capability: a Risk Manager (qualitative risk, register maintenance) sits at £420-600/day outside IR35; a QRA Analyst running Monte Carlo modelling in @Risk, Safran or Primavera Risk Analysis (single discipline, QSRA or QCRA) at £550-750/day; a Senior QRA Specialist or Integrated QCSRA practitioner (AACE-standard, gateway review experience, board-grade reports) at £750-1,100/day. Defence and nuclear add a further 20-35% premium on these. The QRA premium is the most consistent in the UK market because programmes typically get one chance to produce a QRA that survives IPA scrutiny. **How does IR35 affect project controls day rates?** Since April 2021, IR35 status on public-sector and large private-sector engagements is determined by the end client, not the agency. Contractors deemed inside IR35 pay income tax and NI at source, so they typically seek a 25-35% higher day rate to maintain the same net income compared to outside-IR35 equivalent. Public-sector programmes (National Highways, Network Rail, Sellafield, MoD) default to inside IR35 unless the contractor can demonstrate business-in-business activity. Consultancy engagements bypass IR35 in the same way — the consultancy is engaged as a business not as an individual. **Are consultancy day rates higher than contractor day rates?** On headline figures, yes — a consultancy day rate is typically 1.25-1.35× the equivalent outside-IR35 contractor rate. But the apples-to-apples comparison usually closes that gap once agency margin, IR35 uplift on inside-IR35 placements, and contractor management overhead are factored in. For QRA and senior controls roles, the consultancy model often works out at similar or lower total cost — and shifts the IR35 determination off the client's desk onto the consultancy. **What does a Head of Project Controls / Controls Director earn in the UK?** Programme-level Head of Project Controls or Controls Director rates in 2026 sit at £900-1,300/day outside IR35 (£695-1,005/day inside IR35 net equivalent). These are the least price-sensitive positions in the market — programme directors who need a controls director they can trust to tell them the truth about the programme will pay above market rate to get the right person. The difference between a good and an average controls director is measured in programme outcomes, not day rates. --- ## Primavera P6 vs Microsoft Project — Which Is Right for Your Programme? URL: https://www.somaprojectcontrols.com/resources/guides/primavera-p6-vs-microsoft-project Subtitle: An honest comparison for UK project controls practitioners — what each tool does well, where each falls short, and how to decide without the vendor pitch. Published: 2026-04-23 · 8 min read ### The honest answer upfront The choice between Primavera P6 and Microsoft Project is not a religious debate — it is a practical question about programme scale, controls maturity, and what the client or funder requires. For most UK infrastructure programmes above £20m with multiple contractors, logic-linked schedules and an EVM requirement, P6 is the right tool. For most internal project management environments, SME programmes and anything that needs to be shared with stakeholders who will not pay for P6 licences, MS Project is the right tool. The mistake most organisations make is applying the wrong tool to the programme — usually P6 where MS Project would have been adequate, because P6 sounds more professional, or MS Project where P6 was contractually required, because nobody wanted to pay for the licences. Both mistakes are expensive. A P6 schedule maintained by someone who only knows MS Project is worse than a well-maintained MS Project schedule. A programme that requires P6 integration with cost systems and needs to satisfy a DCMA 14-point review cannot be run on MS Project regardless of how tidy it looks. ### What Primavera P6 does better Scale and complexity: P6 is designed for programmes with thousands of activities, multiple projects sharing resources, and complex logic networks. It handles activity counts that would make MS Project slow and unreliable. On HS2 supply chain programmes, Network Rail enhancement works and nuclear decommissioning schedules, P6 is the standard precisely because these programmes require the scale. Baseline management: P6's baseline functionality is significantly more robust than MS Project's. Multiple baselines, baseline comparison views, and the ability to maintain version-controlled programme baselines are all native to P6. On NEC4 programmes where the Accepted Programme must be formally issued and tracked, P6 baseline management is built for the requirement. Resource loading and levelling: P6's resource management handles multi-project resource pools, resource histograms, and resource-constrained scheduling in a way that MS Project approximates but does not match. For programmes where resource-loaded schedules are a contract requirement or a scheduling standard, P6 is the more capable tool. Integration with cost systems and EVMS: P6 integrates natively with Oracle Primavera Cost Management and has established integration pathways with Ecosys, SAP, and other cost platforms. For programmes where EVM reporting is driven from an integrated cost-schedule model, P6 is the better backbone. MS Project integrations exist but are typically more fragile. DCMA 14-point compliance: The metrics the DCMA 14-point methodology tests — logic completeness, constraint usage, float distribution, critical path integrity — are easier to measure and report in P6 using the standard export and report functionality. Most schedule analysis tools (Acumen, ARM, Deltek) have native P6 integrations. MS Project can be analysed but the workflow is less smooth. ### What Microsoft Project does better Accessibility: MS Project is in the Microsoft 365 ecosystem. Stakeholders who need read-only access can view schedules without a P6 licence or a specialised viewer. Programme-level summaries can be pulled into PowerPoint or Excel without an export step. For programmes where broad stakeholder access matters, this is a genuine advantage. Ease of use for non-specialists: A project manager who has not been trained as a planner can learn to maintain an MS Project schedule at a basic level. P6 requires dedicated training — the interface is not intuitive, the terminology is different, and the consequences of mistakes (corrupted WBS, broken resource assignments) are harder to recover from. If the schedule owner is a PM rather than a trained planner, MS Project is more forgiving. Cost: MS Project is included in some Microsoft 365 licences and is available as a standalone product. P6 requires an Oracle licence — Professional at around £1,000/user/year at list price, though enterprise agreements reduce this significantly. For smaller programmes or organisations with limited controls budgets, the cost difference is material. Portfolio visibility in the Microsoft ecosystem: Project for the Web and Microsoft Project Online integrate with Teams, SharePoint, and Power BI in ways that P6 does not. For organisations running their portfolio management in the Microsoft stack, the integration overhead of adding P6 is real. ### Which tool fits which programme Use P6 when: the contract specifies P6 (common on National Highways, Network Rail, HS2, NDA and MoD CADMID Demonstration/Manufacture programmes); when the programme has more than 500 activities and multiple sub-projects; when an integrated cost-schedule EVMS is required; when DCMA 14-point health checks are part of the controls regime; when the client programme office runs P6 and expects P6-format data submissions. Use MS Project when: the programme is below £10m with a single contractor and a controls requirement that is proportionate to the scale; when stakeholder accessibility is more important than scheduling precision; when the project manager will maintain the schedule rather than a dedicated planner; when the programme sits within a Microsoft 365 portfolio management environment. Use both when: the delivery team runs P6 for the controls function and MS Project or similar for executive reporting. This is more common than it sounds — a P6 master schedule summary-exported into MS Project for board-level reporting is a reasonable approach that avoids forcing non-controls stakeholders into P6 viewers. The wrong answer is to choose the tool based on what the planning team is comfortable with rather than what the programme requires. A planner who insists on MS Project for a programme that contractually requires P6 is creating a compliance problem. A client who mandates P6 for a £2m single-contract refurbishment is creating overhead that the controls benefit does not justify. ### Training implications P6 training is a meaningful investment. A planner who can build and maintain a complex P6 schedule — resource-loaded, logic-linked, DCMA-compliant — has a skill that commands a day rate premium and is in demand across all UK infrastructure sectors. Basic P6 familiarity (opening schedules, updating progress) is table stakes; genuine P6 capability is materially rarer. MS Project proficiency is widespread. Most programme managers have used it. The distinguishing capability is not MS Project knowledge per se but schedule discipline — logic linking, proper baseline management, avoiding the date-constraint habits that produce schedules that look tidy but do not respond correctly to changes. SOMA's Primavera P6 training course is built around real infrastructure programme use cases — not the generic Oracle curriculum. We focus on the specific scenarios that UK controls practitioners encounter: NEC4 Accepted Programme management, compensation event incorporation, DCMA-compliant logic, and resource-loading for EVM. The course is designed for people who need to produce P6 schedules that will be reviewed by client programme offices, not for people who want a P6 certificate. ### Frequently asked questions **What is the main difference between Primavera P6 and Microsoft Project?** Primavera P6 is built for large, complex, multi-project environments — it handles resource levelling across hundreds of projects, has a true relational database backend (Oracle or SQLite), and produces the kind of CPM-compliant schedules required on major infrastructure and defence contracts. Microsoft Project is a desktop tool designed for smaller, single-project use. P6 is the de facto standard on UK infrastructure, nuclear, and defence programmes; MS Project is widely used by programme managers and PMOs on smaller or IT-oriented projects where its lighter weight is an advantage rather than a limitation. **Can Primavera P6 be used for NEC4 Accepted Programme management?** Yes — P6 is the most common tool for producing and maintaining the NEC4 Accepted Programme on UK infrastructure contracts. A properly built P6 schedule can meet all Clause 31 requirements: logic-linked activities, resource allocation, float shown, critical path clearly identified, and time risk allowances visible. For Clause 32 programme updates, P6's update workflow (P6 Progress Spotlight, Statusing, and Target comparison) supports the monthly update and revised programme submission process that NEC4 requires. **Is Primavera P6 worth learning for a UK project controls career?** Yes — genuine P6 capability is one of the most marketable skills in UK project controls. Basic P6 familiarity (opening and updating schedules) is table stakes; being able to build a complex, logic-linked, resource-loaded, DCMA-compliant schedule from scratch commands a day rate premium and is in demand across infrastructure, defence, nuclear, and energy sectors. The investment pays back quickly on NEC4 and FIDIC-based programmes where the Accepted Programme is a contractual deliverable that is regularly reviewed by client programme offices. --- ## P50, P80, P95 in Cost Estimation: Which Confidence Level Should You Actually Use? URL: https://www.somaprojectcontrols.com/resources/guides/p50-p80-p95-confidence-levels-explained Subtitle: P50 is the IPA-required central estimate for UK capital cost. P80 is the UK departmental sensitivity convention. P95 is for safety-critical programmes and portfolio-level safeguards. How to pick the right confidence level for project sanction — and what HM Treasury Green Book and IPA Cost Estimating Guidance actually say, versus the working conventions departments use in practice. Published: 2026-04-24 · 9 min read ### What P50, P80 and P95 actually mean P50, P80 and P95 are percentile points on a cost or schedule probability distribution. A P50 cost means the project has a 50% probability of coming in at or below that figure. P80 means 80% probability, and P95 means 95%. The distribution itself comes from Monte Carlo simulation of the QRA model — thousands of iterations across the base estimate and identified risks, producing a full range of possible outcomes. The distinction matters because the gap between these percentiles is not symmetric. On most project cost distributions, the shape is right-skewed — there is more upside exposure than downside — so the move from P50 to P80 is typically smaller than the move from P80 to P95. A project with a P50 of £100m might have a P80 of £118m and a P95 of £135m. That asymmetry is what makes the choice of confidence level a commercial decision rather than a statistical one. The single most common misunderstanding is to treat P80 as "the answer". A P80 is the cost figure the project has an 80% probability of not exceeding — which means there is a 20% probability it will. On ten similar projects funded at P80, statistically speaking two will overrun. Whether that is the right risk appetite depends entirely on who is paying and what the consequences of an overrun would be. ### Why P80 became the UK default (and what the Green Book actually says) P80 has become the de facto convention used by many UK departments for sensitivity testing and contingency-setting on major capital programmes — but it is worth being precise about where this comes from, because the published guidance is more nuanced than the convention suggests. The HM Treasury Green Book (2022, paragraphs 6.72–6.84) requires explicit adjustment for risk and optimism bias, and recommends advanced techniques such as Monte Carlo analysis for high-cost, high-risk proposals. It uses P90 as a worked example of how to express uncertainty around a central estimate ("practitioners may express the uncertainty around a central estimate using a P90 value") but it does not mandate any specific confidence level. The IPA Cost Estimating Guidance is more specific in a way that surprises many people. It requires the central estimate to be presented at the Median Scenario / P50 equivalent — "the estimator believes that there are comparable probabilities of the actual outcome to be higher or lower than this threshold." The IPA Cost Estimating Requirements then express stage-gate confidence as percentage bands around that Anticipated Final Cost rather than as a single P-level: SOC target −20% / +50%, OBC target −15% / +30%, FBC target −10% / +10%. P80 is not the IPA's written requirement — it is a working benchmark many departments use for upper-bound sensitivity. The reasoning behind the P80 convention is pragmatic rather than theoretical. P50 alone is uncomfortable as a single funding figure because it means accepting a 50% probability of overrun. P95 is uncomfortable because the gap between P80 and P95 is typically so large on a right-skewed cost distribution that funding at P95 immobilises contingency that could have been deployed on other programmes. P80 sits at a point where the marginal contingency buys meaningfully less risk reduction than the preceding steps did, and Homes England's published guidance (one of the few UK departments to set this down explicitly) treats P50 and P80 as standard sensitivity tests unless alternatives are more appropriate. AACE International Recommended Practice 57R-09 treats P80 as one common reference point for integrated cost-schedule risk analysis outputs but does not specify it as a standard. The practical position for a UK public-sector business case is therefore: present the P50 as the central estimate (IPA-required); present P80 as an upper-bound sensitivity (departmental convention); show the confidence range against the IPA stage-gate bands; and document why the funded position is where it is. "P80 because the Green Book says so" is not a defensible justification — the Green Book does not say so. "P80 because departmental finance has set that as our risk-appetite point and the IPA cost-band tolerance accommodates it" is defensible. ### When P50 is the right answer P50 has specific legitimate uses that are often overlooked. The most common is internal forecasting. The P50 is the expected outcome — the point around which actual performance will distribute — and it is the appropriate benchmark for management-level performance reporting. Comparing actual cost against P50 (rather than against P80) tells the project team whether the programme is running better or worse than the central expectation. Comparing actual against P80 will, by definition, show underperformance more than half the time, which is not actionable information for delivery management. P50 is also appropriate for incentive structures. Pain-gain mechanisms, target cost contracts and performance-based contingency drawdown work best when the contractor is rewarded for beating the P50 and penalised for exceeding it. Setting these mechanisms against P80 creates a pain-gain that is nominally generous to the contractor but rewards underperformance, because beating P80 is not a meaningful achievement on a project that should deliver close to P50. The third case is where the funding decision explicitly accepts risk. Innovation programmes, technology demonstrators and early-stage R&D are sometimes funded at P50 by sponsors who have deliberately chosen to accept higher probability of overrun in exchange for lower upfront capital commitment. This is a valid choice as long as it is made explicitly. The failure mode is funding at P50 while claiming P80 confidence — which is rarer than it was but still occurs on programmes where the QRA has not been scrutinised properly. ### When P95 is the right answer P95 is the right answer when the consequences of overrun are catastrophic in a way that justifies carrying substantial additional contingency. The clearest cases are safety-critical programmes and programmes where a funding shortfall would force termination of work that cannot easily be resumed. Nuclear new build programmes, some defence acquisition programmes, and certain regulated infrastructure contexts all have features that can justify P95 funding. P95 is also sometimes appropriate for the overall funding envelope of a large programme, even when individual projects within it are funded at P80. The portfolio-level P95 is not simply the sum of individual project P95s — correlation effects reduce the portfolio contingency relative to the sum of project contingencies, and the portfolio view allows for some cross-project risk sharing. Public-sector spending authorities sometimes require portfolio P95 reporting as a safeguard against simultaneous material overruns across multiple projects. The commercial cost of P95 is real and must be understood. Moving from P80 to P95 on a £500m programme might require an additional £40-60m of committed capital that cannot be deployed elsewhere. On a portfolio of programmes, this compounds significantly. A sponsor moving from P80 to P95 on principle, without a specific reason tied to the programme context, is choosing to immobilise substantial public or shareholder capital for a marginal reduction in overrun probability. That is a legitimate choice but it should be made deliberately. ### The contingency calculation and who owns the drawdown Once the confidence level is chosen, contingency is the difference between the P-point and the base estimate. Contingency at P80 is the P80 figure minus the deterministic base estimate. This is the amount of capital that needs to be held against the identified risk profile to achieve the chosen confidence level. It is not an arbitrary percentage — it is the output of the QRA model, and it has a defensible analytical basis. The more important question is who owns the contingency and what the drawdown rules are. Contingency held at the project level, released against project-specific risks with project-level approval, behaves very differently from contingency held at the portfolio level, released against any project's emerging risks with central approval. The former makes project teams self-managing; the latter creates a pool that is efficient but politically contentious. The worst arrangement is contingency held at the project level with drawdown rules that are effectively unrestricted in practice. If every request to release contingency is approved, there is no meaningful governance on the P80 position — the project is effectively funded at whatever its worst outcome turns out to be, and the P80 figure is a ceiling rather than a target. The opposite failure mode — contingency that is technically available but practically inaccessible because every drawdown request triggers a month of governance — means the project team treats it as unavailable and manages to the base estimate under informal pressure. Both fail to use the QRA output as intended. ### What a good confidence-level conversation looks like A well-run investment committee session on confidence level starts with the sponsor articulating their risk appetite in words: what is the tolerable probability of overrun, and what is the consequence of overrun if it occurs? The committee then looks at the QRA output and chooses a confidence level that is consistent with that articulated risk appetite — which might be P80 in most cases, but could be P50, P85, P90 or P95 depending on the context. A poorly-run session starts with the default (usually P80), looks at the contingency requirement, and then negotiates the contingency down until the total funding envelope fits a pre-existing budget constraint. The P80 figure then becomes nominal — the funded position is actually P60 or P65, but the paperwork says P80. This is one of the most common patterns on UK public-sector programmes and it produces predictable overruns two to four years later. The practical test of a good confidence-level decision is whether it would be defensible to the sponsor's board, the National Audit Office, or an IPA gateway reviewer. If the reasoning can be written down in a paragraph — "we chose P80 because our tolerance for overrun on this programme is low given its strategic visibility, and the £25m incremental contingency over P50 is acceptable given the £300m total scope" — the decision is defensible. If the reasoning would look uncomfortable on paper, the decision is probably not one that will hold up when the programme hits its first difficult quarter. ### Red flags when someone tells you "it's P80" Claims that a programme is funded at P80 should be tested. The first question is: P80 of what QRA model, with what risk register, run when and by whom? A P80 produced from a QRA that has not been peer-reviewed is a number, not a confidence level. An assurance reviewer should be able to see the model, the risk inputs, and the correlation structure, and reach their own view on whether the claimed P80 is defensible. The second question is whether the P80 was produced before or after the funding decision was settled. QRA models that produce the "right" P80 to match a predetermined funding envelope exist and are not hard to construct — a weak correlation structure here, an under-stated three-point estimate there, a couple of material risks omitted from the register, and the model produces whatever number the sponsor wanted to see. The discipline of external independent QRA is what protects against this, and it is one of the principal reasons why UK public-sector frameworks require independent assurance on major capital programmes. The third question is whether the P80 is being treated as a live figure or a historical artefact. A P80 produced at sanction and never re-run is reliable only while the underlying conditions that produced it remain valid. After a material risk materialises, a scope change is absorbed, or the programme moves into a new phase, the P80 needs to be re-calculated — and the re-calculated figure may be higher than the original. Programmes that freeze the P80 at sanction and report against a stale figure are not doing live QRA; they are using a one-off number as a performance target, which is a different and weaker thing. ### Putting it together Choosing a confidence level is a commercial decision dressed up as a statistical one. The statistics tell you what the numbers mean; the decision is about what level of overrun probability the sponsor can tolerate, given the commercial, reputational and operational consequences if it occurs. P80 is a reasonable default for UK public-sector major projects but is not the answer for every case. P50 has legitimate uses in management reporting and incentive design. P95 is appropriate where the downside is catastrophic or where portfolio-level safeguards require it. The most common failure is not choosing the wrong confidence level — it is choosing one and then not actually funding the programme at it. P80 on paper and P60 in practice is a worse position than being honest that the programme is funded at P60, because it leaves the sponsor with an unrealistic expectation of overrun probability and no plan for what happens when the base estimate turns out to have been optimistic. SOMA delivers QRA and confidence-level advisory to UK infrastructure, defence, nuclear and public-sector programmes — including on CADMID Concept and Assessment-phase business cases where the confidence figures presented to the IAB at Initial Gate and Main Gate, and the corresponding scrutiny from IPA assurance reviews and (on larger programmes) the Cabinet Office Major Projects Review Group (MPRG), need to be substantiable. The Single Source Regulations Office sits in parallel on the pricing side of single-source defence contracts under the Defence Reform Act 2014; QRA confidence figures sit with IPA/IAB rather than SSRO. We structure the model, the risk register and the contingency discussion so that the confidence level being claimed is defensible — at Gateway, at Board, at NAO if it ever comes to that. That is the standard the work should meet, and it is the standard we deliver to. ### Frequently asked questions **What does P80 mean in project risk analysis?** P80 means there is an 80% probability that the project cost (or duration) will be at or below that value. In a Monte Carlo simulation of thousands of iterations, P80 is the value at the 80th percentile of the output distribution. P80 is widely used as an upper-bound sensitivity test on UK major capital programmes, but it is not specified as the standard confidence level by either the HM Treasury Green Book or the IPA Cost Estimating Guidance — both leave the choice of percentile to the project's risk appetite, with the Green Book's worked example actually using P90 and the IPA specifying P50 as the required central estimate. **What is the difference between P50, P80 and P95?** P50 is the median outcome — half of all simulated scenarios come in at or below this figure, and it is the central estimate the IPA Cost Estimating Guidance requires UK business cases to present. P80 provides 80% confidence that the project will not exceed the stated cost or duration; it is widely used as the upper-bound sensitivity test on UK major programmes but is a departmental convention rather than a written requirement. P95 provides near-worst-case coverage and is used where the consequences of overrun are severe, such as nuclear decommissioning or safety-critical infrastructure. The gap between P50 and P80 is typically smaller than the gap between P80 and P95, because project risk distributions are right-skewed. **Does HM Treasury Green Book mandate P80?** No. The HM Treasury Green Book (2022, paragraphs 6.72–6.84) requires explicit adjustment for risk and optimism bias and recommends advanced techniques such as Monte Carlo analysis for high-cost, high-risk proposals, but it does not mandate any specific confidence level. Its worked example uses P90, not P80 ("practitioners may express the uncertainty around a central estimate using a P90 value"). The IPA Cost Estimating Guidance separately requires the central estimate to be presented at the P50 / Median Scenario, with stage-gate confidence expressed as percentage bands around the Anticipated Final Cost (SOC ±20–50%, OBC ±15–30%, FBC ±10%). P80 has become a working departmental convention, not a Green Book requirement. **When should you use P50 instead of P80?** P50 is the IPA-required central estimate for all UK government business cases and should always be presented as the headline figure regardless of what upper-bound sensitivity is used alongside it. P50 is also the appropriate basis for setting NEC4 Option C/D target costs under established cost-engineering practice (reflected in AACE International, Australian Department of Finance and UK NEC users' group commentary), for internal management reporting where the median is the expected outcome, and for pain-gain incentive mechanisms where the target should sit at the most-likely outcome rather than at an upper-bound figure that rewards underperformance. **How much contingency is added when moving from P50 to P80?** There is no universal uplift — the gap between P50 and P80 depends on the risk distribution for your specific programme. A well-defined programme with contained risk might see a 5–8% cost uplift from P50 to P80; a programme with high uncertainty could see 15–20% or more. Always derive percentile values from your Monte Carlo model rather than applying a rule-of-thumb percentage. The gap reflects the actual risk profile, not an arbitrary budget margin, and is one of the diagnostics IPA assurance reviews probe to test whether the model is genuinely calibrated. **What is the difference between a project P80 and a portfolio P80?** A portfolio P80 is not the sum of individual project P80 values. When projects run simultaneously, their risks are partially correlated — diversification effects mean the portfolio P80 is typically lower than the sum of individual project P80s. Sponsors who need a portfolio-level confidence position should model the portfolio as a whole rather than adding up individual project P-points, as simply summing them overstates the contingency required. This matters for departmental portfolios under HM Treasury spending review processes and for major-programme groups under Cabinet Office Major Projects Review Group (MPRG) scrutiny, where the cross-portfolio view is what challenges affordability. --- ## Three-Point Estimate Calibration — What Low, Most-Likely, High Should Actually Mean URL: https://www.somaprojectcontrols.com/resources/guides/three-point-estimate-calibration Subtitle: The difference between a QRA that works and a QRA that produces theatre usually comes down to how the three-point estimates were elicited. A practical guide to doing it properly — and to the PERT formula (O + 4M + P) / 6 and the (O + 3M + P) / 5 variant. Published: 2026-04-24 · 10 min read ### Why three-point estimates are the foundation of QRA A Monte Carlo QRA is only as good as the three-point estimates feeding it. The model itself — correlation handling, simulation logic, the S-curve output — is relatively well-understood by practitioners and fairly consistent across tools. What varies dramatically is the quality of the input distributions. A QRA built on poorly-calibrated three-point estimates will produce a falsely narrow output band that looks rigorous but misleads the sponsor; a QRA built on well-calibrated estimates will produce a defensible confidence position that holds up under scrutiny. A three-point estimate for a single activity or cost line item consists of three values: low (optimistic), most-likely, and high (pessimistic). These three points define a probability distribution — typically triangular, PERT or BetaPERT — that the Monte Carlo simulation samples from across thousands of iterations. The shape and position of each distribution determines how the uncertainty in that one activity or cost line contributes to the overall project distribution. The most common failure in QRA practice is that three-point estimates are elicited in a way that systematically understates uncertainty. Workshop participants anchor on the base estimate, then offer low and high values that are barely distinguishable from it — producing narrow triangular distributions that, aggregated across a project, generate a Monte Carlo output that is almost identical to the deterministic base estimate. The model is technically run; the outputs are technically produced; and the QRA is technically delivered. It is also providing no analytical value. ### The PERT formula — (O + 4M + P) / 6 and the (O + 3M + P) / 5 variant The PERT formula gives a single weighted-mean point estimate from a three-point estimate. The classic version, derived from the Program Evaluation and Review Technique developed for the US Navy Polaris missile programme in 1958, is Expected Value = (Optimistic + 4 × Most Likely + Pessimistic) / 6. The four-times weighting on the most-likely value reflects an underlying assumption that the most-likely outcome is roughly four times more probable than either extreme — which is what produces the bell-like Beta-PERT distribution shape sampled by Monte Carlo tools. Standard deviation under classic PERT is approximated as (Pessimistic − Optimistic) / 6. A less common variant uses (Optimistic + 3 × Most Likely + Pessimistic) / 5 as the weighted mean. This is sometimes called the "modified PERT" or "weighted three-point" formula and turns up in some PMI study materials, practitioner texts, and exam-prep questions. The three-times weighting produces a slightly flatter distribution and a mean closer to the simple average of the three points. The variant exists because the original PERT weights were calibrated for activity-duration estimates in a specific 1950s programme context; some practitioners argue that on modern projects with wider real-world ranges, the four-times weighting concentrates probability mass too tightly around the most-likely value to reflect real uncertainty. A worked example makes the difference concrete. For a three-point estimate of Optimistic = 8 days, Most Likely = 12 days, Pessimistic = 22 days: standard PERT (O + 4M + P) / 6 gives an expected value of (8 + 48 + 22) / 6 = 13.0 days; the (O + 3M + P) / 5 variant gives (8 + 36 + 22) / 5 = 13.2 days; the simple triangular mean (O + M + P) / 3 gives (8 + 12 + 22) / 3 = 14.0 days. The three formulas converge when the estimate is symmetric and diverge most where the distribution is skewed — exactly where the choice of weighting matters most. In practice, the formula choice rarely matters for live QRA — the Monte Carlo simulation samples from the full distribution, not the weighted-mean point estimate. Where the formulas are used is in qualitative work: quick sanity-checks of a three-point estimate before running the simulation, expected-value calculations on a deterministic schedule, contingency uplift on a small cost line that does not justify full Monte Carlo treatment, or PMI-style exam questions. For QRA practitioners, the more important question is whether the three-point estimate range itself is calibrated against evidence — which is what the rest of this guide is about. A correctly calibrated three-point estimate fed into a triangular, classic PERT or Beta-PERT distribution will produce similar Monte Carlo outputs; an incorrectly calibrated estimate fed into any of them will produce nonsense. ### The anchoring trap and how to break it When a workshop participant is asked "what is the optimistic duration for this activity?", the cognitive process almost always starts from the base estimate and subtracts a little. The same happens on the pessimistic side — starting from the base estimate and adding a little. The result is a symmetric, narrow triangular distribution centred on the base estimate, which is not a reflection of actual uncertainty; it is a reflection of anchoring bias. Breaking the anchor requires different questioning. Instead of "what is the optimistic value?", ask "under what specific conditions would this activity finish early, and how early?". Instead of "what is the pessimistic value?", ask "what would have to go wrong for this activity to significantly exceed the plan, and how far would it push?". The shift from numerical to conditional elicitation forces participants to engage with scenarios rather than deltas from the anchor, and typically produces wider, more honest distributions. Another technique is to collect the low and high values before revealing the base estimate. On a new activity, participants are asked for their low and high independently, and only then is the plan figure shared for comparison. This works well in early-stage QRA workshops where the base estimate is not yet fixed. On live programmes where the base is already agreed, the discipline of asking for conditions rather than values still produces materially different results from the naive approach. ### Calibrating against evidence, not intuition The strongest three-point estimates are calibrated against evidence — historic project data, benchmark performance, analogous activities on comparable programmes. If the activity being estimated is "install 200m of piling at Section B", and historic data from the same client on similar ground conditions shows piling rates varying between 8m/day and 25m/day with a mean of 16m/day, the three-point estimate should reflect that range rather than whatever the workshop participants happen to feel comfortable claiming. AACE International's Professional Guidance Document PGD-02, the Guide to Quantitative Risk Analysis, and Recommended Practice 57R-09 between them set out the methodology for evidence-based calibration in QRA workshops. The practical implication is that the workshop facilitator needs to come prepared with benchmark data where possible, and has to push back when participant estimates are materially inconsistent with that data. A participant who claims a 6-week pessimistic duration when every comparable programme has run for 12-16 weeks needs to be asked what specific differences justify the narrower range. Where historic data is not available — on innovative scope, first-of-a-kind work, or early-stage estimates — explicit use of expert judgement is unavoidable. The key is to be transparent about the basis of the estimate. "Based on expert judgement, low = 30 days, most likely = 45 days, high = 80 days, reflecting the significant uncertainty about equipment availability and the thin analogous data for this specific scope" is a defensible estimate. A bare set of numbers without explanation is not. ### The shape of the distribution matters more than you think Three-point estimates can be modelled with different distribution shapes, and the shape has a material effect on the Monte Carlo output. The three most common are: triangular (straight lines from low to most-likely to high), PERT (a smooth Beta-like shape weighted toward the most-likely value), and BetaPERT (a flexible variant that allows the relative weighting of the peak to be adjusted). Triangular is the simplest and most common choice, and it is a reasonable default. Its limitation is that it treats the low and high values as absolute bounds — the Monte Carlo simulation will never sample outside that range. In practice, very few real-world activities have hard bounds; a piling rate of 2m/day is improbable but not impossible, and a triangular distribution with low = 5m/day will reject it entirely. PERT and BetaPERT distributions have asymptotic tails that better reflect the real shape of uncertainty, at the cost of slightly more complex parameterisation. For most UK infrastructure QRA work, triangular distributions are sufficient provided the low and high values are chosen to represent genuine 5th and 95th percentile points rather than absolute bounds. AACE RP 57R-09 discusses distribution shape selection in detail and is the reference standard for QRA practitioners. The practical rule is that if the distribution shape is materially affecting the P80 output, the three-point values are probably not well-calibrated in the first place — a well-calibrated triangular will produce a similar P80 to a well-calibrated PERT on most real activities. ### Separating variability from event risk A recurring source of confusion in three-point estimate workshops is mixing variability risk with event risk. Variability is the inherent uncertainty in how an activity that definitely will happen will unfold — the piling activity will definitely take place; the question is whether it takes 40, 50 or 70 days. Event risk is a discrete occurrence that may or may not happen — the risk that unexpected ground conditions require additional pile length, which has a 30% probability and a 5-10 day impact if it materialises. These two kinds of uncertainty should be modelled separately. Variability goes into the three-point estimate on the activity itself. Event risk goes into the risk register as a probability-weighted impact on the relevant activities. Mixing them — bundling ground conditions risk into a wider pessimistic value on the piling duration — produces a QRA that cannot identify specific risk drivers and therefore cannot support targeted mitigation planning. The practical test is to ask: does the pessimistic value in this three-point estimate capture things that might go wrong, or does it capture how the activity will vary even if nothing goes wrong? If the pessimistic value is effectively "the worst realistic case including identifiable risks", the estimator has bundled event risk into variability. The fix is to pull the event risks out into the register where they belong, and recalibrate the three-point estimate to represent only the inherent variability of the activity. ### The workshop discipline that makes estimates defensible A QRA workshop that produces defensible three-point estimates has specific characteristics. It is facilitated by someone experienced enough to challenge anchored thinking and knowledgeable enough to introduce benchmark evidence. It has the right participants — people with real delivery knowledge of the scope in question, not just project management attendees. It is time-boxed per line item: five to ten minutes on each activity, not a token 30 seconds followed by consensus on the base estimate. The workshop records the reasoning, not just the numbers. For each three-point estimate, the record captures the assumptions about scope, the conditions that would drive low and high outcomes, the benchmark data considered, and any dissenting views. This record is what makes the QRA defensible at gateway review — the reviewer can see not just the inputs but the thinking that produced them. A QRA that cannot show its working is vulnerable to challenge in a way that a fully-documented QRA is not. The workshop also explicitly discusses correlation. When activity A has a pessimistic value driven by severe weather, and activity B has a pessimistic value driven by the same severe weather, those two pessimistic values are not independent — if one materialises, the other is more likely to. Capturing correlation during elicitation (rather than adding it afterwards) produces a more coherent model and avoids the common failure mode of a QRA with zero correlation that systematically understates tail outcomes. ### Red flags in QRA three-point estimates Three-point estimates worth questioning have specific signatures. Symmetric distributions on nearly every activity (low and high values approximately equidistant from the most-likely) are suspicious — real project activities are typically skewed, with more upside risk than downside. If the register shows symmetric triangulars everywhere, the elicitation was probably driven by anchoring rather than by genuine engagement with the uncertainty. Narrow distributions on long-duration activities are another flag. An activity with a most-likely duration of 180 days and low/high values of 170/195 has an implied coefficient of variation under 7%, which is unreasonable for most construction and infrastructure work. The range should reflect real experience of how such activities actually perform, not what the planner would find comfortable to claim. Consistency of range across heterogeneous activities is a third flag. If the three-point estimates show a similar percentage spread on excavation, on M&E commissioning, on software integration and on commissioning, the estimates are almost certainly not being differentiated by activity. Different activities have different risk profiles; their three-point estimates should reflect that. When SOMA reviews a QRA that exhibits these patterns, we typically rebuild the estimates from the workshop up — not because the model is wrong, but because the inputs driving the model do not represent the uncertainty the project actually faces. The rebuild is expensive in effort but produces a QRA that can survive a gateway challenge, which is the point of doing the work. ### Putting it together Three-point estimate calibration is the part of QRA practice that most directly determines the quality of the output. A well-calibrated set of estimates produces a Monte Carlo distribution that is an honest reflection of the project's risk profile; a poorly-calibrated set produces a number that looks rigorous but isn't. The difference is visible in how the workshop is run — evidence-based, challenging, time-boxed per item, with the reasoning captured alongside the numbers — and in how the reviewer interrogates the outputs. AACE International's reference standards for this work are PGD-02 (Guide to Quantitative Risk Analysis) and Recommended Practices 57R-09 (Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model), 113R-20 (Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value) and 123R-22 (Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Estimate Ranging and Expected Value with Monte Carlo Simulation) — three different methodologies for integrated cost-schedule QRA, each suited to a different evidence and modelling context. QRA that follows these practices is defensible at Gateway, at Board, and in independent assurance review. QRA that skips the calibration discipline to save workshop time tends to produce outputs that do not survive scrutiny. SOMA facilitates QRA workshops for UK infrastructure, defence, nuclear and public-sector programmes — including the calibration-heavy three-point elicitation that supports CADMID Concept and Assessment-stage business cases. We bring benchmark data, we push back on anchoring, and we capture the reasoning so the outputs are defensible. The result is a QRA that does its job — giving the sponsor a confidence position they can actually fund against, and a risk register they can actually manage. --- ## Writing a QRA Report That Survives Gateway Review URL: https://www.somaprojectcontrols.com/resources/guides/qra-report-that-survives-gateway Subtitle: What makes the difference between a QRA report that gives an IPA reviewer confidence and one that triggers a recommendation to redo the work. Practical guide for UK public-sector programmes. Published: 2026-04-24 · 8 min read ### What gateway reviewers actually look at QRA reports land on the desk of people who have seen hundreds of them. A UK IPA gateway reviewer, a departmental assurance lead, or an investment committee member reviewing QRA outputs is not going to read the report cover-to-cover. They are going to look at a small number of specific things, form a view, and ask questions. The structure and content of the report determines whether they arrive at the view you want them to. The three things a reviewer looks for first are: the headline confidence position (what is the P80 cost, what is the P80 date), the methodology (is this an AACE-compliant approach or a bespoke model), and the transparency of the underlying data (can I see the risk register, the three-point estimates, the correlation structure). A report that makes these three things easy to find and defensible to challenge is a report that builds confidence. A report that buries them in appendices or obscures them through narrative is a report that triggers scepticism. The reviewer's mental model is: does this QRA represent honest analysis of the programme's risk profile, or does it represent a model tuned to produce a number the delivery team wanted to present? The two can look similar on the surface — both have S-curves, both have P80 figures, both have risk registers — but they have different signatures in how they are documented. The reviewer knows what those signatures look like. ### The structure that works A QRA report for gateway purposes should open with an executive summary that states the headline position in plain terms. Three to five sentences covering: what was analysed, the confidence levels produced (P50, P80, ideally P95), the principal risk drivers identified, and the data sources underpinning the analysis. A reviewer reading only the executive summary should come away with a clear picture of what the analysis shows. The methodology section comes next. It should state explicitly which AACE reference standards were followed — typically PGD-02 (Guide to Quantitative Risk Analysis) as the overarching reference, plus the Recommended Practice that matches the modelling approach used: 57R-09 for risk-driver Monte Carlo of a CPM model, 113R-20 for combined parametric and expected-value methods, or 123R-22 for estimate-ranging plus expected-value with Monte Carlo. It should describe how variability risk and event risk were separated, how correlation was handled, what distribution shapes were used, how many iterations were run, and what tool produced the model. Compliance with AACE standards is the single strongest signal a reviewer uses to form an initial impression of the work's rigour. The results section presents the confidence levels with supporting visualisations — S-curves, tornado charts, risk-driver ranking tables. The reviewer expects to see not just the headline P80 but the sensitivity analysis that identifies the top five to ten drivers of exposure. A results section without sensitivity analysis is incomplete and will be asked for. The supporting documentation — risk register, three-point estimate tables, correlation matrix, workshop attendance and methodology records — should be appendices, and the executive summary and methodology sections should reference them explicitly. "The full risk register is in Appendix A; the three-point estimate tables are in Appendix B; the correlation matrix is in Appendix C" is a line every gateway-ready QRA report should contain. ### The documentation that makes the QRA defensible The appendices are what separate a gateway-ready QRA from a model that was run but cannot be defended. Every three-point estimate should be traceable to its origin — which workshop it came from, who provided it, what evidence or benchmark it was calibrated against, what scope assumptions underpin it. A reviewer challenging a specific pessimistic value should be able to look up how it was derived and reach their own view on whether the derivation is reasonable. The risk register should be formatted to show the qualitative assessment (probability band, impact band, risk owner) alongside the quantitative inputs (probability as decimal, impact distribution parameters, mapped activities or cost lines). The two should be reconciled — a risk scored as "high probability, high impact" qualitatively should translate to a materially contributing entry in the QRA model, and a risk that dominates the tornado chart quantitatively should be reflected in the qualitative narrative the team is actually managing. The correlation matrix, if used, needs explanation. A matrix with dense correlation structure and no supporting rationale looks like a tuning exercise. A matrix with correlations explicitly linked to documented drivers — "weather risk correlation across all outdoor activities in winter months", "resource correlation across activities sharing specialist commissioning teams" — is defensible. Where no correlation is modelled, that choice should also be stated and justified, because a genuinely uncorrelated model is a strong claim that will usually be challenged. ### HM Treasury Green Book alignment For public-sector QRA, HM Treasury Green Book alignment is expected. The Green Book sets methodological expectations around optimism bias, risk treatment and the evidential standards that underpin appraisal. A QRA report that explicitly addresses these expectations carries more weight with reviewers than one that does not. Optimism bias treatment is a common gap. The Green Book requires that capital cost estimates at early project stages carry an optimism bias uplift calibrated to the project category. A QRA that models identified risks but does not address optimism bias is likely to be challenged for under-representing early-stage uncertainty. The report should either apply the Green Book optimism bias uplift to the base estimate before QRA, or document explicitly why the QRA's own risk treatment is assessed as sufficient to cover the bias — and a reviewer will want to see the evidence for that assessment. The Green Book also expects the confidence level chosen for funding decisions to be justified. A report that defaults to P80 without addressing the sponsor's articulated risk appetite is weaker than one that explicitly discusses the confidence level in the context of the specific programme. Cross-referencing to the business case's treatment of risk appetite is good practice and closes the loop between the QRA and the broader appraisal. ### The common failure modes A QRA report that triggers a gateway recommendation to redo the work typically shows one or more of these patterns. The methodology section is vague — referring generally to "Monte Carlo simulation" and "three-point estimates" without specifying AACE alignment, tool, or iteration count. The risk register has many entries but the quantitative contribution is concentrated in a small number of them, suggesting the others are filler. The three-point estimates show symmetric distributions across most activities, implying anchoring bias rather than differentiated uncertainty. Another failure pattern is a headline confidence level that does not reconcile to the narrative. If the report says "P80 is £X" but the identified risks in the register add to materially more than £X's worth of exposure at high probability, the model has either under-calibrated the risks, incorrectly correlated them, or contains modelling errors. Reviewers increasingly check this kind of consistency and a QRA that fails the reconciliation test is very hard to rescue without a rerun. Missing workshop documentation is a structural weakness. If the report does not record who attended the quantification workshops, what their roles were, how long was spent per line item, and what reference evidence was introduced, the reviewer cannot form a view on whether the elicitation was rigorous. AACE PGD-02 (Guide to Quantitative Risk Analysis) and 57R-09 between them provide the workshop methodology and documentation expectations — a report that follows them has a much easier reviewer conversation than one that does not. ### How to make the reviewer's job easier Reviewers are usually under time pressure and are reading several QRA reports alongside many other gateway artefacts. A report that makes their job easier is a report that arrives at a favourable outcome more often. Practical techniques: use visual hierarchy aggressively — the headline P80 cost and date should be visible within ten seconds of opening the report. Use explicit cross-references to the AACE practices being followed. Include a one-page methodology summary that a reviewer can skim and understand without reading the full section. The other thing reviewers value is explicit discussion of limitations. A QRA that says "our model has the following limitations: [A, B, C], and we believe these have the following effect on the confidence position: [specific assessment]" is more defensible than one that claims no limitations. All models have limitations; the honest treatment is to name them. Reviewers distrust analyses that claim more precision than they can credibly support. Finally, align the report structure with the reviewer's checklist where possible. IPA gateway reviewers work to internal guidance on what to look for; departmental assurance leads do the same; MoD MPRP teams on CADMID programmes apply their own scorecard against the controls evidence. A QRA report that answers their checklist questions in the order they ask them is faster to review and easier to approve. SOMA structures QRA reports explicitly to the assurance criteria that apply to the specific gateway — which is why our work typically clears the review on first submission rather than needing rework. --- ## Structuring a Risk Register So It's QRA-Ready From Day One URL: https://www.somaprojectcontrols.com/resources/guides/risk-register-that-is-qra-ready Subtitle: Most risk registers cannot be quantified without rebuilding them. This guide covers the structural choices that make a register QRA-compatible from the start — and the ones that force you to start over. Published: 2026-04-24 · 9 min read ### Why most risk registers cannot be quantified Ask ten UK project controls practitioners whether their risk register is "QRA-ready" and nine will say yes. Ask them to export the register and feed it into a Monte Carlo model and the answer changes. Most registers, however diligently maintained, are structured for qualitative risk management — RAG-rated reviews, owner follow-ups, monthly status — rather than for quantification. Converting them to QRA-ready format is often a rebuild, not a transformation. The gap is structural. A QRA-ready register needs each risk to have: a probability expressed as a decimal (not a band), an impact expressed as a distribution on schedule days and/or cost (not a band), explicit mapping to the schedule activities or cost lines the risk would affect, and a separation between inherent uncertainty and discrete risk events. Most registers have none of these in a directly usable form — probabilities are scored 1-5, impacts are scored low/medium/high, the mapping to schedule and cost is implicit at best, and variability and event risk are mixed together. The practical consequence is that when the project decides to commission a QRA, the first 30-40% of the effort goes into rebuilding the register so it can actually be quantified. This is wasted effort that could have been avoided by structuring the register correctly from the start. The cost of doing it right on day one is low; the cost of retrofitting is substantial. ### The risk statement format that supports quantification A well-structured risk statement follows a cause-event-consequence format: "Because of [cause], there is a risk that [event] occurs, which would lead to [consequence]." This format forces clarity about what is being managed. The cause is the underlying condition that creates the risk. The event is the discrete occurrence being modelled. The consequence is the impact that drives the cost and schedule effects. Without this discipline, risk statements drift into vague summaries that cannot be quantified. "Supplier performance" is not a risk — it is a category. "Because supplier X has limited experience with the required specification, there is a risk that delivery is late or defective, leading to rework and schedule delay on the commissioning critical path" is a risk. The second version is quantifiable; the first is not. The cause-event-consequence format also supports mitigation planning. A mitigation that addresses the cause (earlier supplier qualification, alternative supplier identification) is different from one that addresses the event (enhanced receipt inspection) or the consequence (float in the commissioning programme, parallel commissioning paths). A register that does not distinguish between cause, event and consequence often lists "monitor closely" as its mitigation — which is not a mitigation. ### Probability: bands are not enough Most registers score probability on a 1-5 scale: very low, low, medium, high, very high. This is fine for qualitative review but inadequate for quantification. A QRA needs a probability expressed as a decimal — 0.15, 0.30, 0.55 — so the Monte Carlo simulation can sample the risk event at the correct frequency. Converting bands to decimals is a common source of trouble: "medium probability" could mean 0.30 to 0.50 depending on the scoring framework, and different team members will use different numbers if the mapping is not explicit. The better approach is to define the probability bands with decimal ranges from the start: "1 = 0-10%, 2 = 10-25%, 3 = 25-50%, 4 = 50-75%, 5 = 75-95%", and record the specific percentage used for quantification alongside the band. This maintains the simplicity of banded scoring for reviewers while giving the QRA model a specific decimal input that can be traced. There is also a case for eliciting probability directly as a decimal during risk workshops, rather than via bands. Asking "what is the probability this risk materialises" and getting an answer of 0.35 or 0.55 works for experienced risk practitioners, although it requires more facilitator discipline to avoid everyone clustering on the same round numbers. Hybrid approaches — banded for routine review, decimal for QRA quantification — are common and workable. ### Impact: distributions, not single numbers The impact side has the same issue and is often worse. Registers typically score impact on a 1-5 scale against cost and schedule criteria. For QRA, the impact needs to be a distribution — typically three-point, sometimes PERT — covering the range of cost and schedule effects if the risk materialises. The elicitation question is not "what is the impact if this risk occurs?" but "if this risk occurs, what is the range of cost and schedule impact, and what is the most likely point within that range?". A single-number impact ("£500k") assumes certainty that is never real; a three-point impact ("£200k low, £500k most likely, £1.2m high") reflects the actual uncertainty. The range matters because the tornado chart in the QRA output will rank risks by their contribution to variance — which depends on both probability and impact range. A risk with a 0.3 probability and a narrow £200-300k impact is less influential than one with the same probability and a £100k-2m impact, even if the mid-points are similar. Register formats that only capture a single impact value systematically obscure this distinction. ### Mapping to schedule and cost For QRA, every quantifiable risk needs to be mapped to the activities in the schedule or the cost lines in the estimate that it would impact. This mapping is what allows the Monte Carlo simulation to apply the risk's impact at the right point in the model rather than as a generic addition to the total. A schedule risk impacting the critical path has different effect on project completion than the same risk impacting a non-critical activity with float. A cost risk affecting the structural steel package has different total cost implication than a similar-magnitude risk on the M&E package if the two packages have different escalation exposure. The mapping captures this. Most registers do not have this mapping explicitly. The risk owner knows which activities the risk affects; the QRA practitioner does not, and has to reconstruct the mapping by asking. A register field that captures the mapping — "Schedule activities: B-100, B-105, B-110" or "Cost lines: WBS 3.2.1, 3.2.3" — keeps the information where it belongs and avoids the reconstruction effort each time the QRA is refreshed. ### Separating inherent uncertainty from event risk The classic confusion in register construction is bundling inherent uncertainty (variability in activities that definitely will happen) with event risk (things that might or might not happen). Entries like "risk of weather delay" can represent either — the unavoidable effect of seasonal weather on outdoor work, or the specific risk of an extreme weather event. These are different and should be modelled differently. Inherent uncertainty belongs in the three-point estimates on the activities themselves. If outdoor concrete pours in winter months typically take longer than in summer months, that is variability — capture it in the pessimistic end of the three-point estimate for the relevant activities. If there is a 15% probability that an extreme weather event disrupts work for 2-4 weeks, that is an event risk — capture it in the register as a discrete entry with probability and impact distribution. Registers that mix these produce QRA models where the weather impact is counted twice — once in the activity distributions and once in the register — or not at all, if the register entry is assumed to replace the variability treatment. Either failure undermines the confidence position. The discipline of separating variability and event risk at register construction is what prevents this. ### Ownership and governance that keeps the register live A QRA-ready register is only useful if it stays current. Each risk needs a named owner with authority to manage the mitigation and monitor the probability and impact inputs over time. A risk whose owner has left the project, or whose owner cannot authorise the mitigation, is a risk the register is tracking but nobody is managing. The review cycle matters. A register updated every six weeks with full review (probability, impact, mitigation progress, inputs to the QRA refresh) keeps the data live. A register updated at year-end or only when the QRA is re-run produces QRA outputs that reflect the position as it was months ago, not as it is now. For UK major programmes, monthly or six-weekly register cadence with quarterly QRA refresh is a practical discipline. The integration with the Early Warning Register on NEC4 contracts is worth attention. Early warnings feed potential risks that should flow into the risk register; mitigated early warnings might resolve as risks that drop off the register without ever being formally quantified. The two registers should be run as complementary tools by the same risk owner group, not as separate workstreams that lose information between them. ### Putting it together Structuring a risk register to be QRA-ready from day one takes marginally more discipline than structuring it for qualitative use only — and saves substantial effort when quantification is required. The four structural choices that matter most: cause-event-consequence risk statements, decimal probabilities alongside banded scores, three-point impact distributions alongside banded scores, and explicit mapping to schedule activities and cost lines. Teams that adopt these conventions find that their register supports both qualitative review (RAG status for the monthly pack) and quantitative analysis (inputs to the QRA model) from the same document. There is no "QRA register" and "management register" — there is one register, structured so both audiences can read the information they need from it. SOMA helps clients stand up risk registers in this format from project inception, and restructures registers mid-programme when the controls function needs to move to a more mature quantitative footing — including on MoD CADMID programmes where the register has to feed both the IPA gateway QRA and the ongoing risk-management cadence between gates. The change pays back within one QRA cycle — not having to rebuild the register is a significant saving — and produces better risk management in the interim because the discipline of the format surfaces weaker risk statements and forces them to improve. --- ## CADMID vs PRINCE2: How the UK MoD Lifecycle Differs from Generic PM URL: https://www.somaprojectcontrols.com/resources/guides/cadmid-vs-prince2 Subtitle: CADMID is a defence acquisition lifecycle. PRINCE2 is a generic project-management method. They do different jobs and they are not interchangeable. A practitioner's view of where each one belongs, what controls each demands, and how they coexist on real UK defence programmes. Published: 2026-05-16 · 9 min read ### Why the comparison gets confused CADMID and PRINCE2 frequently get compared, and the comparison usually goes badly. The two are not direct alternatives. CADMID is the lifecycle the UK Ministry of Defence applies to acquiring military equipment: it sets out the phases an acquisition programme moves through and the investment decisions that govern the transitions between them. PRINCE2 is a generic project-management method: it sets out how to organise, control and assure any individual project, regardless of what is being delivered. The confusion comes from the word "phase". CADMID has six phases. PRINCE2 has management stages. The words sound interchangeable but they describe different things. CADMID phases are externally enforced and tied to investment approval — a programme cannot pass from Concept to Assessment without a Main Gate decision and, on Major Projects, an IPA Gateway Review. PRINCE2 stages are internally defined by the project board for control purposes; the project itself chooses how many to have and where to put the stage boundaries. On a real UK defence programme the two often run together. The programme moves through CADMID phases; an individual project inside the programme — say, the integration of a new combat system into a platform — may be managed using PRINCE2. The CADMID lifecycle says when the programme has to be ready for Main Gate; PRINCE2 says how that particular project is being controlled to be ready. They do not compete. They do different jobs. ### CADMID in one paragraph CADMID is the UK MoD's six-phase acquisition lifecycle: Concept (defining the requirement), Assessment (option analysis and full business case), Demonstration (development, integration and test), Manufacture (production and acceptance), In-Service (operational sustainment, often spanning decades), and Disposal (decommissioning and asset disposition). Each transition between phases is governed by a Main Gate decision and, for programmes on the Government Major Projects Portfolio, by an IPA Gateway Review. The framework is owned and operated by Defence Equipment & Support (DE&S) and the Submarine Delivery Agency (SDA) inside the MoD. ### PRINCE2 in one paragraph PRINCE2 (PRojects IN Controlled Environments, version 2) is a project-management method originally developed by the UK government and now owned by PeopleCert (formerly AXELOS). It defines seven principles, seven themes, and seven processes that govern how an individual project is started up, directed, controlled and closed. It is sector-agnostic and is used across government, infrastructure, IT and commercial work. It is explicitly designed to be tailored to project context — the method is a framework, not a rulebook, and the project board chooses how it is applied. ### Where they overlap (and where they don't) The overlap is real but narrow. Both frameworks emphasise stage- or phase-based control with explicit decision points between increments of work. Both expect a documented business case that is revisited at boundaries. Both expect risk to be managed actively with named owners. Both expect change to flow through a controlled process rather than being absorbed silently into the baseline. The differences matter more. CADMID is externally enforced — a programme does not get to choose whether to comply, and the gateway criteria are owned outside the programme by IPA and the MoD's own assurance machinery. PRINCE2 is internally tailored — the project board decides which themes and processes apply, how heavily, and what gets streamlined. CADMID is whole-life and decades-long; PRINCE2 is project-bounded and finishes when the project closes. CADMID has prescriptive controls expectations at each phase — QRA at Concept and Assessment, EVMS at Demonstration and Manufacture, through-life cost In-Service — that PRINCE2 deliberately leaves to the project to define. The most useful way to hold the two in the same head is: CADMID describes the lifecycle the MoD applies to its equipment acquisitions; PRINCE2 describes a way of managing any one project inside it. The two are not in tension — they are at different altitudes. ### Controls implications under CADMID that PRINCE2 does not set CADMID is opinionated about what the controls function must produce at each phase. At Concept the requirement is option-level QRA, a Class-5 cost estimate with reference-class comparison, and a risk register structured to support option comparison. At Assessment the requirement steps up to a Class-3 estimate, integrated QCSRA, and a full business case that satisfies HM Treasury Green Book optimism-bias scrutiny. At Demonstration the Performance Measurement Baseline is established and EVMS reporting begins. At Manufacture the EVMS becomes the primary financial reporting framework and SSRO cost-reporting applies on non-competitive contracts above the threshold. In-Service brings through-life cost modelling and reliability-driven sustainment forecasting. Disposal brings its own cost estimating and regulatory risk, particularly on platforms with radiological or environmental legacy. PRINCE2 is silent on most of this by design. The method tells a project board to manage risk, but it does not specify QRA methodology or confidence-level expectations. It tells a project board to manage cost, but it does not specify an Earned Value framework. It tells the board to assure quality, but it leaves the actual quality regime to the project. That silence is appropriate — PRINCE2 is sector-agnostic — but it is also why PRINCE2 alone is insufficient on a defence programme. The CADMID overlay specifies what the project controls function actually has to deliver; PRINCE2 governance can describe how those deliverables flow through the project board. ### How they coexist on a real programme On a typical UK defence programme the picture looks like this. The programme — say, a new platform acquisition — sits on the CADMID lifecycle. Senior Responsible Owner reports to the MoD Investment Approvals Committee through the Main Gate process. IPA Gateway Reviews provide independent assurance at the major decision points. Inside the programme, there are projects — software integration, supply-chain development, training and support delivery — each of which may be run using PRINCE2 (or any other defensible method). The project boards report into the programme. The programme reports into the CADMID gate. The interface that matters is at the project-to-programme boundary. Project-level controls have to feed programme-level controls without loss. The schedule from the PRINCE2-managed project has to integrate with the master programme schedule used at gateway. The cost reporting from the project has to feed the integrated EVMS at programme level. The risk register at the project has to feed the QRA at programme level. Getting that interface right is what the controls function on the programme actually does. Getting it wrong is why projects appear green and the programme as a whole is red. ### Which one applies to you If you are running an MoD acquisition programme, CADMID applies whether you want it or not. The lifecycle is externally enforced and the gateway machinery will be applied. The choice you have is how the controls function inside that lifecycle is structured. If you are running an individual project — including a subcontract delivering into a CADMID programme — PRINCE2 is one of several defensible methods. APM Body of Knowledge, the IPA Project Routemap, or a tailored client-specific method may be the right choice instead. The selection should be made on what the project board and the client actually expect to see, not on what is most familiar. If you are inheriting a controls function on a defence programme, the question to ask is not "which framework are we using" but "what does the next gateway require, and what does the controls evidence have to show". The frameworks are means; the evidence is the end. ### How SOMA helps SOMA Project Controls works on defence and government programmes through three repeating engagement shapes: independent Quantitative Risk Analysis on Concept and Assessment-stage business cases where the team needs a defensible contingency figure that will withstand IPA and SSRO scrutiny; EVMS implementation reviews on Demonstration and Manufacture contracts where the reporting is technically compliant but operationally disconnected from delivery; and IPA gateway readiness reviews on long-running programmes. The work is delivered by senior practitioners who have led controls on UK infrastructure, water, nuclear and defence programmes, and who treat the controls function as an intelligence function for the Programme Director rather than a reporting overhead. Where PRINCE2 or another method is being applied at project level inside the programme, we work to make the project-to-programme interface produce evidence that survives gateway review. ### Frequently asked questions **Is CADMID a project-management method like PRINCE2?** No. CADMID is an acquisition lifecycle — it defines the six phases a UK MoD equipment programme moves through, the investment decisions that govern the transitions, and the controls expectations at each phase. PRINCE2 is a project-management method — it defines how to organise and control an individual project, regardless of sector. The two operate at different levels and frequently coexist on the same programme. **Can a defence programme use PRINCE2 instead of CADMID?** No. CADMID is externally enforced by the MoD investment-approvals machinery and applies to UK defence equipment acquisitions regardless of what method the programme team prefers. PRINCE2 (or an alternative method) can be used to manage individual projects within a CADMID phase, but it does not replace the lifecycle. **Do CADMID phases map directly to PRINCE2 stages?** Not cleanly. CADMID phases are tied to investment decisions and gateway approval, which are externally owned. PRINCE2 stages are management stages defined by the project board for control purposes. A CADMID phase may contain one or several PRINCE2-style management stages, and projects inside a phase may have their own internal stage structures. **Which controls framework should I use on a defence programme?** The MoD-prescribed controls under CADMID — QRA at Concept and Assessment, EVMS at Demonstration and Manufacture, through-life cost modelling In-Service, SSRO reporting on non-competitive contracts above the threshold — apply at programme level. PRINCE2 or an alternative method can manage project-level work inside that overlay. The two are not in competition. **What is the equivalent of a CADMID Main Gate in PRINCE2?** There is no direct equivalent. PRINCE2 has end-stage assessments where the Project Board reviews progress and authorises the next stage, but these are internally owned and tailorable. A CADMID Main Gate is an externally enforced investment decision involving the MoD Investment Approvals Committee and, on Major Projects, IPA Gateway scrutiny. The mechanisms perform similar functions but they are not interchangeable. --- ## CADMID Concept Phase: Project Controls Deliverables and Failure Modes URL: https://www.somaprojectcontrols.com/resources/guides/cadmid-concept-phase-controls Subtitle: The Concept phase is where the controls function earns its right to be in the room — or fails to. A practitioner's view of what project controls must deliver at MoD CADMID Concept, what IPA Gateway 1 reviewers actually test, and the failure modes that recur on real programmes. Published: 2026-05-16 · 8 min read ### Where Concept fits in CADMID Concept is the first of CADMID's six phases (Concept, Assessment, Demonstration, Manufacture, In-Service, Disposal). It is the phase where the requirement is defined, candidate solutions are identified at a high level, and the Outline Business Case is developed for the Initial Gate / IPA Gate 1 decision. The phase ends with a decision — to enter Assessment with a manageable option set, to pause, or to terminate. The decision is made by the MoD Investment Approvals Committee and, on Major Projects, with IPA Gate 1 input. For the controls function, Concept is small in volume but high in leverage. The estimates, ranges and risks set at Concept frame every decision that follows — and the cost estimate produced at Concept is, on the MoD's own data, the single best predictor of the eventual programme outturn. A Concept estimate built honestly survives Assessment; a Concept estimate engineered to look affordable is the root cause of the overrun that becomes visible at Main Gate two years later. ### What controls must deliver at Concept The deliverables at Concept are deliberately lightweight in scope but rigorous in methodology. The cost estimate is an AACE Class 5 — a strategic outline range with explicit uncertainty bounds, not a single-point figure. The expected accuracy at Class 5 is in the order of -50% to +100% on the low and high bounds, which is wide on purpose: at Concept, the solution is not yet defined and tighter ranges would be dishonest. Reviewers familiar with AACE classification will press on whether the range is genuinely consistent with concept-stage uncertainty. The QRA at Concept is option-level. The job is not to produce a definitive P80 — there is no definitive cost to apply a P80 to. The job is to compare candidate options on a like-for-like uncertainty basis so that the option-set winnowing is rational. A bespoke airframe option and a Military Off-The-Shelf variant cannot rationally carry the same coefficient of variation; the QRA has to expose that difference, not flatten it. Reference-class comparison is the de-biasing technique that HM Treasury Green Book specifically calls for at this stage — every option range should be sense-checked against what comparable programmes have actually cost. The risk register at Concept is v0.1: strategic risks at the option-set level, not the line-by-line operational risks that appear in later phases. Twenty to forty risks is typical; two hundred is a sign that the team has skipped Concept-level abstraction. Each risk should map to one or more candidate options and indicate which options would carry it forward into Assessment. ### What IPA Gate 1 reviewers actually test IPA Gate 1 — sometimes labelled "business justification" — tests whether the Outline Business Case is fit to enter Assessment. The reviewers are independent; they are not part of the programme team. They read the controls evidence with a specific question in mind: does the cost and time range honestly reflect the uncertainty of the concept, and has the option set been genuinely compared, or has one preferred option been engineered into looking best? The recurring red flags are predictable. A cost range that is suspiciously close to the available funding envelope at the high end. An option-level QRA where the option-set uncertainties are flattened to similar coefficients of variation. An optimism-bias adjustment bolted on at the end of the analysis rather than built into the input ranges, which reviewers can strip out to expose the underlying numbers. A reference-class comparison that is absent or that uses obviously non-comparable programmes. A risk register whose top risks are not consistent with the option set being recommended. The controls evidence that passes Gate 1 has three characteristics. The numbers are traceable — every figure in the OBC can be tied back to a model, a reference dataset, or an assumption that is stated explicitly. The methodology is conventional — AACE classification, Green Book optimism-bias, reference-class comparison — so reviewers do not spend their time relitigating methodology choices. The narrative is honest — the case explains where the team is genuinely confident, where they are not, and what work in Assessment is intended to resolve the uncertainty. ### The recurring failure mode The recurring failure at Concept is over-precision. The Class 5 range is presented as narrower than it really is because the team is uncomfortable showing a -50% / +100% spread to a board that wants reassurance. The narrower range is then defended as "more rigorous", which is the opposite of what AACE Class 5 actually means: at Class 5, rigour shows up as honest width, not artificial precision. The second failure is over-elaboration. The team produces a Class 3 estimate dressed up as a Class 5 because the cost engineering effort runs ahead of the requirement definition. The estimate looks impressive but is technically untethered: the elements being costed reflect a level of solution definition that does not yet exist. Reviewers notice this — the cost breakdown structure is too detailed for the requirement description in the rest of the OBC — and the credibility of the whole estimate suffers. The third failure is the missing reference class. The estimate is built from first principles without any check against what comparable programmes have cost in practice. Green Book is explicit that reference-class comparison is the most effective single de-biasing technique available; an OBC that omits it invites the reviewer to ask "what does this category of programme actually cost?", and the answer "we did not check" is not a good place to start. ### What good looks like A well-run Concept phase produces a small number of high-quality artefacts. A Class 5 cost range that is honestly wide and explicitly calibrated against reference-class data. An option-level QRA that differentiates uncertainty by technical maturity and gives the board a defensible basis for the option-set winnowing decision. A risk register v0.1 of around thirty strategic risks, each mapped to one or more options, with named owners. A narrative in the OBC that explains where the team is confident, where they are not, and what Assessment work is designed to resolve. The narrative matters more at Concept than at any other phase. The reviewer is making a judgement about whether the programme should enter Assessment, which is the phase where serious money starts to be spent. The narrative is what convinces them that the team has been honest about uncertainty and has a plan for resolving it — not a series of confident assertions that the team intends to be right about. ### How SOMA supports CADMID Concept SOMA Project Controls works at Concept stage in two engagement shapes. The first is independent QRA on the option set — a short engagement that gives the programme team a reference-class-calibrated, AACE-compliant view of the cost and schedule confidence ranges per option, with a defensible methodology that will survive Gate 1 scrutiny. The second is OBC controls assurance — a structured pre-Gate review of the controls evidence pack, identifying the gaps that an IPA reviewer is most likely to flag and the remediation needed before submission. Both engagements are delivered by senior practitioners who have built controls evidence packs that have passed Gate 1 on real UK defence and government programmes. ### Frequently asked questions **What is the CADMID Concept phase?** Concept is the first phase of the UK MoD's CADMID acquisition lifecycle. The programme defines the requirement, identifies candidate solutions at a high level, and develops the Outline Business Case for the Initial Gate / IPA Gate 1 decision. The phase ends with a decision to enter Assessment, pause, or terminate, taken by the MoD Investment Approvals Committee. **What project controls deliverables are required at CADMID Concept?** An AACE Class 5 cost estimate with honest uncertainty bounds, an option-level Quantitative Risk Analysis that compares candidate solutions on a like-for-like uncertainty basis, a reference-class comparison against historical programmes per HM Treasury Green Book guidance, and a strategic risk register (v0.1) of around 20–40 risks mapped to the option set. **What does IPA Gate 1 test on a Concept-phase business case?** IPA Gate 1 tests whether the Outline Business Case honestly reflects concept-stage uncertainty and whether the option set has been genuinely compared. Reviewers look for traceable numbers, AACE-compliant methodology, reference-class calibration, an honest narrative about where the team is confident and where they are not, and a Class 5 range that is genuinely wide rather than artificially precise. **How wide should a Class 5 cost estimate be at CADMID Concept?** AACE 18R-97 sets the expected accuracy of a Class 5 estimate at approximately -50% to +100% on the low and high bounds. At Concept the solution is not yet defined; narrower ranges are typically a sign that the team is presenting false precision rather than rigour. Reviewers familiar with AACE classification will press on whether the range honestly reflects the maturity of the requirement. **What is the most common controls failure at CADMID Concept?** Over-precision — presenting a Class 5 range as narrower than it really is, because the board wants reassurance the team cannot honestly provide. The narrow range is then defended as rigorous, which inverts what AACE Class 5 actually means. The cost engineering chain reaction is that the engineered range becomes the anchor, and the programme is committed to a number that the underlying analysis does not support. --- ## CADMID Assessment Phase: Full Business Case, QCSRA and Main Gate URL: https://www.somaprojectcontrols.com/resources/guides/cadmid-assessment-phase-controls Subtitle: Assessment is where the option set is narrowed, the Performance Measurement Baseline is shaped, and the Full Business Case is built for Main Gate. A practitioner's view of what project controls must deliver, what IPA Gate 2 / 3 reviewers test, and the failure modes that get programmes red-rated. Published: 2026-05-16 · 9 min read ### Where Assessment fits in CADMID Assessment is the second of CADMID's six phases. The option set carried out of Concept is now investigated in depth: candidate solutions are designed to a level of definition that supports meaningful cost and schedule estimation, the integrated risk picture is developed for each, and a preferred solution is selected. The phase ends with the Full Business Case and the Main Gate decision — the investment commitment to enter Demonstration. On Major Projects this aligns with IPA Gate 2 (delivery strategy) and Gate 3 (investment decision), and the controls evidence is the artefact the reviewers actually work from. For the controls function, Assessment is where the volume of work steps up by an order of magnitude. The estimates move from Class 5 to Class 3. The QRA moves from option-comparison to integrated QCSRA. The schedule moves from outline to a baseline draft with genuine logic. The risk register moves from strategic v0.1 to a working operational document. Most importantly, the methodology becomes the defensible artefact: at Main Gate the reviewers are not testing whether the team can produce a number, they are testing whether the number can withstand scrutiny. ### What controls must deliver at Assessment The cost estimate at Assessment is an AACE Class 3 — supported by quantitative inputs at the level of definition the preferred design now provides. Class 3 expects an accuracy range in the order of -20% to +30%, materially tighter than Concept. The estimate has to be built on a defined cost breakdown structure, with each major element traceable to a quantitative basis — engineering definition, supplier engagement, reference-class data — and not asserted as a single judgement. The QRA at Assessment is integrated QCSRA: cost and schedule sampled together against the same risk register, with realistic correlation between risks that affect both. The P50 is established as the basis of the funding case; the P80 sits as the contingency envelope expected by HM Treasury Green Book and the MoD Cost Assurance and Analysis Service. The methodology is published — typically Safran Risk, Primavera Risk Analysis, @Risk or Acumen Risk, against AACE 57R-09 and 113R-20 — and the model file is auditable. The baseline programme draft covers Demonstration and Manufacture at sufficient detail to support gate review. The critical path is identifiable, the schedule logic is genuine (not a series of FS-0 links concealing a missing path), and DCMA-style screening has been run before the schedule goes into the FBC. A schedule that fails its own DCMA test before submission is a schedule the reviewer will notice — DCMA screening is the cheapest way to find the problems first. The risk register is now a working operational document. It has decimal probabilities and three-point impact distributions (not just RAG bands), each risk is mapped to specific schedule activities and cost lines, and the top risks reconcile to the QRA outputs. A risk register that does not reconcile to the QRA is one or the other being wrong; both being right is the standard the programme is held to. ### What Main Gate and IPA Gate 2–3 reviewers test Main Gate is the MoD investment decision. IPA Gate 2 tests delivery strategy ("is this deliverable?"); IPA Gate 3 tests the investment decision itself ("is this affordable and assured?"). On Major Projects the two often run close together, and the controls evidence is the same evidence pack from the programme team's point of view. The reviewers, however, are testing different things. At Gate 2 the test is whether the delivery strategy is buildable. Is the PMB achievable given the technical maturity? Is the supply chain capable? Is the schedule logic robust enough to survive contact with the contractor? Is the proposed EVMS arrangement going to produce real data rather than reconciled-from-spend earned value? Reviewers will ask whether the team has thought about how the schedule degrades under realistic contractor delays, and whether the QCSRA results would still support the funding case if the supplier base assumptions tighten. At Gate 3 the test is investment confidence. Is the contingency provision defensible given the QRA methodology and the risks identified? Has the optimism-bias adjustment been built into the inputs (the right place) or bolted on at the end (the wrong place, because the reviewer can strip it out)? Does the cost breakdown reconcile to the technical scope? Is the risk transfer arrangement to the contractor realistic, or is it a paper transfer that the MoD will end up bearing anyway? The Gate 3 reviewer is asking whether they would commit Treasury money on the basis of this case. ### The recurring failure modes The most common Assessment-phase failure is a QRA whose distribution shape is too tame for the technical maturity. The ranges in the three-point inputs are too narrow, correlation between risks is absent or token, the opportunity side of the distribution is empty, and the P80 sits within touching distance of the deterministic estimate. The MoD Cost Assurance and Analysis Service and the SSRO both publish guidance on this and both will press on a QRA whose underlying inputs look engineered rather than calibrated. The second failure is the bolted-on optimism bias. The team has run the QRA, produced a P80, and then added a late-stage uplift to satisfy Green Book without re-running the inputs. Reviewers strip out the late uplift, look at the underlying P80, and ask whether the model would still support the funding case without it. If the answer is no, the case is fragile. The third failure is the schedule that cannot survive contractor reality. The Assessment baseline is built top-down to fit the desired Main Gate date, with logic constructed to support the constraint rather than reflecting the real activity dependencies. DCMA screening, run by the reviewer if not by the team, exposes this immediately — high constraint counts, suspect float distributions, missing successor links on tasks that should not be terminal. The fourth failure is the risk register that does not tie to the QRA. The register has its own top-ten list, and the QRA has its own — and they are not the same list. Either the register or the model is wrong; usually both are right in isolation and wrong in combination, and the reviewer asks the question that exposes it: which five risks, if they materialised in combination, would breach the P80? ### What good looks like at the end of Assessment A well-run Assessment phase produces a Full Business Case whose controls evidence is internally consistent, externally defensible, and operationally usable. The cost estimate is Class 3 with quantitative bases for each major line. The QCSRA produces a P50 and P80 that the team can defend, with correlation and optimism-bias treatments built into inputs. The baseline programme passes DCMA-style screening before submission. The risk register reconciles to the QRA in detail — the same top risks, with quantified exposures that match the model. The narrative ties the artefacts together. The FBC reads as one document, not five appendices. The cost basis, the risk basis, the schedule basis, the supply-chain basis and the assurance basis all reference the same set of assumptions, and the assumptions are stated explicitly enough that a reviewer can sensitivity-test them. The team can answer the second-order question without referring to the office: what are the three things that, if they went wrong, would breach the P80, and how is each being managed? ### How SOMA supports CADMID Assessment SOMA Project Controls works at Assessment stage in three engagement shapes. The first is independent QCSRA on the preferred option — a structured AACE-compliant integrated cost-schedule risk analysis whose methodology and outputs will satisfy IPA Gate 2 and Gate 3 scrutiny. The second is FBC controls assurance — a structured pre-Gate review of the evidence pack covering the cost estimate basis, the QRA model, the schedule logic and the risk register, identifying the gaps a reviewer is most likely to flag. The third is supplier engagement on the EVMS arrangement — making sure the Demonstration-phase EVMS will produce real data rather than the technically compliant but operationally disconnected reporting that triggers red ratings later. All three are delivered by senior practitioners who have built controls evidence packs that have passed Main Gate on real UK defence and government programmes. ### Frequently asked questions **What is the CADMID Assessment phase?** Assessment is the second phase of the UK MoD's CADMID acquisition lifecycle. The option set is investigated in depth, a preferred solution is selected, and the Full Business Case is built for the Main Gate / IPA Gate 2–3 decision. It is the phase where the controls function moves from option-level comparison to integrated, defensible cost and schedule modelling. **What project controls deliverables are required at CADMID Assessment?** An AACE Class 3 cost estimate per remaining option, an integrated Quantitative Cost-Schedule Risk Analysis (QCSRA) for the preferred option, a baseline programme draft covering Demonstration and Manufacture at sufficient detail for gate review, a working operational risk register with decimal probabilities and three-point impact distributions, and HM Treasury Green Book–compliant optimism-bias treatment built into inputs. **What is the difference between CADMID Concept and Assessment for controls?** Concept produces a Class 5 cost range and an option-level QRA for option-set winnowing. Assessment produces a Class 3 estimate per option, an integrated QCSRA, a baseline programme draft, and a working risk register that reconciles to the QRA. The volume of work steps up by an order of magnitude and the methodology must withstand external scrutiny — at Concept the reviewer tests whether the team is being honest, at Assessment whether the analysis would survive forensic review. **What does IPA Gate 3 test at the end of CADMID Assessment?** IPA Gate 3 is the investment decision test. Reviewers examine whether the contingency provision is defensible given the QRA methodology and identified risks; whether the optimism-bias adjustment is built into inputs rather than bolted on; whether the cost breakdown reconciles to the technical scope; and whether the risk transfer arrangement to the contractor is genuine rather than a paper transfer that the MoD will absorb anyway. **What is the most common Assessment-phase QRA failure?** A QRA whose distribution shape is too tame for the technical maturity — narrow input ranges, token correlation between risks, no opportunity-side distribution, and a P80 that sits within touching distance of the deterministic estimate. The MoD Cost Assurance and Analysis Service and the SSRO both press on this exact pattern, because it is the signature of inputs engineered to support a target number rather than calibrated to the actual risk profile. --- ## Budget at Completion (BAC): Formula, Worked Example, and Where Projects Get It Wrong URL: https://www.somaprojectcontrols.com/resources/guides/budget-at-completion-bac-formula-worked-example Subtitle: A practitioner's walkthrough of how BAC is set, how it relates to EAC, VAC and EVM, and the housekeeping mistakes that quietly invalidate the metric on real programmes. Published: 2026-05-22 · 7 min read ### What BAC actually is Budget at Completion is the total cost the project is authorised to spend on the agreed scope. It is built bottom-up — the planned value (PV) of every work package in the Work Breakdown Structure, summed to the project level — and then frozen at baseline. Once frozen, BAC is the denominator behind almost every Earned Value Management calculation that matters: Estimate at Completion divides BAC by Cost Performance Index, Variance at Completion subtracts EAC from BAC, To-Complete Performance Index measures the efficiency needed across the remaining work to land at BAC. If BAC drifts, every downstream metric drifts with it. A few things BAC is not. It is not the contract value — contract value usually sits above BAC because it includes the supplier's margin and risk loading. It is not the funded position — funding may be released in tranches that, taken in isolation, are less than BAC. And it is not the same as the project sponsor's management reserve, which is held outside the performance measurement baseline and is not part of BAC. BAC is the line the project manager is managing against; management reserve is the buffer the sponsor draws on when BAC has to grow. ### The formula The core formula is mechanical: BAC equals the sum of the planned value of every work package in the performance measurement baseline. In notation: BAC = Σ PVᵢ over all i in the baseline. There is no integration over time — BAC is the time-integrated number, the area under the planned-value S-curve at the project completion date. If you have the cumulative PV curve, BAC is simply its terminal value. Two adjustments are worth flagging. First, BAC normally excludes management reserve. The PMI Practice Standard for EVM is explicit on this: management reserve is held by the sponsor for unidentified risks and sits outside the PMB; only contingency that has been distributed to control accounts is inside BAC. Second, some EVMS implementations distinguish between Distributed Budget (work packages that have been planned in detail) and Undistributed Budget (authorised work that has not yet been broken down to work-package level). BAC includes both. UB that is still sitting on the project at gate review is a finding, not a feature — reviewers expect distributed budget to dominate by late in the planning effort. ### Worked example Take a small electrical commissioning project broken into four control accounts. Control Account A — site setup and temporary supplies — has a planned value of £180,000. Control Account B — primary equipment install — has a planned value of £420,000. Control Account C — secondary distribution and testing — has a planned value of £290,000. Control Account D — handover, commissioning and demobilisation — has a planned value of £110,000. The Budget at Completion is the sum of these four: BAC = £180k + £420k + £290k + £110k = £1,000,000. The contract value is £1,150,000; the £150,000 difference is the contractor's margin and risk loading and sits above BAC. The sponsor is holding a further £100,000 of management reserve, also above BAC. The £1,000,000 BAC is the number against which the project will be performance-measured. Suppose the project is six weeks in and reporting shows: planned value to date PV = £350,000; earned value EV = £315,000; actual cost AC = £360,000. The Cost Performance Index is CPI = EV ÷ AC = 315,000 ÷ 360,000 = 0.875. The Schedule Performance Index is SPI = EV ÷ PV = 315,000 ÷ 350,000 = 0.900. The simplest Estimate at Completion using EVM efficiency is EAC = BAC ÷ CPI = 1,000,000 ÷ 0.875 = £1,143,000. Variance at Completion is VAC = BAC − EAC = 1,000,000 − 1,143,000 = −£143,000 — a forecast £143,000 overspend. The To-Complete Performance Index sharpens the diagnostic. TCPI = (BAC − EV) ÷ (BAC − AC) = (1,000,000 − 315,000) ÷ (1,000,000 − 360,000) = 685,000 ÷ 640,000 = 1.07. The remaining work needs to be delivered at a CPI of 1.07 to land at BAC, against a historical CPI of 0.875. The PMI rule of thumb is that a TCPI more than 0.10 above the historical CPI is a strong signal that BAC is no longer achievable — and 1.07 against 0.875 clears that threshold with room to spare. The honest forecast is the EAC of £1,143,000, and the sponsor will need to authorise either a scope reduction, a draw on the £100,000 management reserve, or a formal change that grows BAC. ### When BAC changes — and when it shouldn't BAC is frozen at baseline and only changes through formal scope change. The two legitimate triggers are: (1) an approved scope change that adds or removes work from the performance measurement baseline, and (2) a transfer of management reserve into the PMB to fund a materialised risk that has been incorporated into scope. Both should result in a baseline revision number, a documented change, and a re-published PMB. If BAC is changing without either, the change-control discipline has broken down and the EVM metrics are no longer reliable. The illegitimate version is the rolling re-plan. Work packages are quietly re-budgeted to absorb cost variances, the planned value curve is reshaped to hide the schedule slip, BAC stays the same on paper while the underlying baseline drifts week by week. The CPI and SPI numbers look stable because the baseline is moving in lock-step with the actuals. This is the failure mode that gets flagged by every external EVMS review the author has seen on UK defence and infrastructure work — and it is the reason that mature EVMS implementations log every change to the PMB through formal Baseline Change Requests, with the cumulative change history visible on the cost report. ### Four housekeeping failures that quietly invalidate BAC First — contingency creeping into BAC unannounced. Contingency budget that sits in a contingency account above the PMB is fine; contingency that gets distributed into control accounts to soak up risk-driven cost increases without a corresponding scope change is not. The CPI and the EAC drift in opposite directions and the project looks healthier than it is. Reviewers test for this by reconciling the original BAC, the distributed contingency to date, and the management reserve drawn — the three should add up to the current authorised total. Second — undistributed budget that never gets distributed. UB is a placeholder for work that has not yet been broken down to control-account level. It is a temporary feature of the early planning effort. UB still sitting on the project at month six of a twelve-month programme means the work has not actually been planned — the PV curve in that area is a fiction. BAC technically includes the UB but the earned-value metrics for that work are meaningless until distribution happens. Third — work-package "rubber budgets". A work package whose budget is regularly transferred to other packages to balance variances has stopped being a unit of management and become a shock absorber. The PMI standard and the ANSI/EIA-748 guidelines both require that control accounts are stable units that the EVMS can meaningfully report against; rubber-budget packages destroy that stability. The fix is to manage at the control-account level and put a formal change through any time a work-package transfer is needed. Fourth — BAC that excludes elements of the contracted scope. Long-lead procurement is the usual offender — items ordered against the contract but parked outside the PMB because they don't fit the cost-breakdown structure neatly. The EV reporting then earns against a BAC that doesn't include all the work, the CPI looks fine, and the cost report quietly understates the committed position by the value of the parked items. Reviewers reconcile BAC to the contract scope as the first thing they do; on a well-run programme the two should be one keystroke apart. ### How SOMA supports BAC and the PMB SOMA Project Controls works on Budget at Completion and the underlying Performance Measurement Baseline in three engagement shapes. The first is baseline assurance — a structured review of the PMB at the point it is being frozen, checking that BAC reconciles to the contracted scope, that distributed and undistributed budget are correctly classified, that contingency and management reserve sit in the right places, and that the work-package structure is stable enough to support meaningful EVM. The second is in-flight EVMS health checks — looking specifically at the four housekeeping failures above, identifying whether BAC has drifted, and recommending the change-control discipline to put it back on a defensible footing. The third is independent EAC and VAC calculation for sponsor reporting — giving the sponsor a number they can defend, calculated against a BAC whose integrity has been independently verified. ### Frequently asked questions **What is Budget at Completion (BAC) in project management?** Budget at Completion is the total authorised budget for the project — the sum of the planned value of every work package in the performance measurement baseline. It is the denominator for Estimate at Completion (EAC = BAC ÷ CPI) and Variance at Completion (VAC = BAC − EAC). BAC is frozen at baseline and only changes through formal scope change, not through internal budget reallocation. **How do you calculate Budget at Completion?** BAC is the sum of the planned value of every work package in the performance measurement baseline: BAC = Σ PVᵢ. There is no time integration — BAC is the terminal value of the cumulative planned-value S-curve, the total cost the project is authorised to spend on the agreed scope. Management reserve is held by the sponsor outside the PMB and is not included in BAC. **What is the difference between BAC and EAC?** BAC is what the project was authorised to cost — the budget. EAC is what the project is now forecast to cost — the estimate, derived from performance to date. BAC is set at baseline and frozen; EAC is recalculated every reporting period. The difference is Variance at Completion (VAC = BAC − EAC), the forecast overspend or underspend. **Does BAC include contingency?** Contingency that has been distributed into control accounts as part of the performance measurement baseline is inside BAC; management reserve held by the sponsor for unidentified risks is outside BAC. The PMI Practice Standard for EVM is explicit on this: management reserve is not part of the PMB, and the project manager is not authorised to draw on it without sponsor approval. **When can Budget at Completion change?** BAC changes only through formal scope change — an approved change that adds or removes work from the performance measurement baseline, or a transfer of management reserve into the PMB to fund a materialised risk that has been incorporated into scope. Internal budget reallocation between work packages does not change BAC; it redistributes it. Any other change is a sign that change-control discipline has broken down. **What is the most common BAC failure on real programmes?** The rolling re-plan. Work packages are quietly re-budgeted to absorb cost variances, the planned-value curve is reshaped to hide the schedule slip, and BAC stays unchanged on paper while the underlying baseline drifts week by week. The CPI and SPI look stable because the baseline is moving with the actuals. The fix is formal Baseline Change Requests with a visible cumulative change history on the cost report. --- ## How to Run a Pre-Mortem: The Risk Workshop That Finds What Brainstorming Misses URL: https://www.somaprojectcontrols.com/resources/guides/how-to-run-a-pre-mortem-workshop Subtitle: Gary Klein's pre-mortem technique, adapted for UK project controls — the facilitation script, the questions that work, and how to turn the output into a risk register that survives gateway review. Published: 2026-05-22 · 8 min read ### What a pre-mortem is A pre-mortem is a structured risk identification exercise developed by Klein Associates founder and decision-research psychologist Gary Klein. The technique flips the conventional risk-workshop question. Rather than asking the team "what could go wrong?", the facilitator asks them to assume that twelve months have passed, the project has failed, and the press release announcing the failure has just been written. The team's job, working individually and silently, is to write down all the reasons why this failure occurred. The facilitator then collects the responses, reads them anonymously, and uses them as the basis for structured discussion. The technique works because of a well-documented quirk of human cognition: people generate causal explanations more readily when given a reference point than when asked to imagine abstract future risks. Asking "what could go wrong?" puts the brain into hedging mode; asking "the project failed — explain why" puts it into explanation mode, which is the mode that generates concrete answers. The same person who can't articulate a vague concern in a meeting will write three specific paragraphs about how a failure unfolded. In UK project controls practice, the pre-mortem is the qualitative front end of the quantitative risk analysis (QRA) pipeline. The risks surfaced in a pre-mortem feed the risk register; the register feeds the QRA; the QRA produces the cost and schedule confidence ranges that the funding decision rests on. A pre-mortem that surfaces a major risk the register would otherwise have missed therefore changes the contingency calculation, the P80, and the cost case the sponsor sees. ### The facilitation script A pre-mortem takes 60 to 90 minutes. Schedule it as a standalone session, not as the last item on an existing risk-workshop agenda — the framing change matters and gets lost when the previous discussion has been about something else. The room should have one chair per participant arranged at a table they can write on, not auditorium-style. Eight to twelve participants is the sweet spot. Below six and the diversity-of-thinking benefit is lost; above twelve and the discussion phase becomes unwieldy. Open with two minutes of context. State the project, the scope, the deliverable, the budget, and the timeline. State the assumption: it is twelve months from now (or whatever the natural failure-realisation horizon is for the programme), the project has failed badly, costs significantly overran, the programme slipped, the client is unhappy. State the task: write down, individually and in silence, all the reasons you think this failure occurred. There is no wrong answer; quantity matters as much as quality. They have 10 minutes. During the writing phase, the facilitator stays silent. If a participant pushes back ("how am I supposed to know why it failed?"), respond once with "make it up — what story would explain it?" and then withdraw. The cognitive trick of the pre-mortem only works when participants commit to the assumption that the failure has already happened. Letting them debate whether the failure is possible defeats the exercise. Collect the responses anonymously. The facilitator reads each entry aloud without attribution and writes a short summary on a flip chart or whiteboard, grouping similar entries as they emerge. After every entry has been read, work through the groups one by one. For each group: is this a risk the existing register captures? If yes, does the pre-mortem add specificity that the register lacks? If no, is the gap because the risk is genuinely novel, or because the existing register categorisation is too coarse to surface it? The goal is not to relitigate every risk; it is to identify the items that the formal process missed. ### The questions that work — and the ones that don't The wording of the failure-framing question matters more than the rest of the script combined. The framing that works on UK infrastructure and defence programmes is: "It is twelve months from now. The project has failed. Costs are significantly over, the programme has slipped, and the client has lost confidence. Write down the reasons why." The wording is short, declarative, and concrete. It names specific failure modes (cost, schedule, client confidence) rather than asking about generic failure. Framings that don't work in practice: "What might go wrong on this project?" — too generic, returns the same hedged answers a brainstorm would. "Imagine the project was a complete disaster" — too dramatic; participants either reject the framing or generate cartoon answers. "What's your biggest concern?" — puts participants on the spot, triggers self-censorship, returns the lowest-common-denominator concerns. The Klein framing works because it specifies the failure type without specifying the cause, which is what we want the participants to generate. A second question that pays off, asked at the end of the discussion phase: "Which of the risks we've identified would you bet money on being the actual cause if the project did fail?" This forces participants to commit to a prioritisation rather than treating all risks as equally weighted. The risks that get bet on are the candidates for high-impact mitigation in the next phase of work. ### Common pitfalls The first pitfall is running the pre-mortem too early. Before the team has enough shared context — typically before the scope is defined, the team is in place, and the broad approach is understood — the pre-mortem returns generic project-management risks rather than programme-specific ones. The right window is after the team can describe what the project actually involves but before the plan has solidified to the point where challenging it feels disloyal. The second pitfall is running it as a group brainstorm instead of an individual written exercise. The cognitive mechanism only works when participants commit to writing answers in silence. Group discussion at the input stage triggers the same social dynamics that suppress risks in a conventional workshop — vocal participants frame the conversation, junior participants defer, contrarian views go unstated. The discussion happens after the writing, not during. The third pitfall is letting the outputs drift back into the risk register without further work. A pre-mortem entry that says "the contractor underestimated the scaffolding requirement" is a failure narrative, not a risk register item. It needs to be parsed into a discrete risk ("scaffolding scope is under-quantified at tender stage"), a probability, an impact range, and an owner before it can feed the QRA. Skipping the parsing step is the most common reason pre-mortem outputs don't change the eventual cost case. The fourth pitfall is doing it once and then not doing it again. A pre-mortem at the start of the project is high-value; a second pre-mortem at the start of each major phase or after a significant scope change is also high-value, because the team's knowledge of the programme has updated. Many of the most useful risks come from the second pre-mortem, not the first — they're the risks that only became visible after some delivery effort. ### Using the outputs in QRA The pre-mortem's value to project controls compounds when the outputs are explicitly integrated into the QRA. Three connections matter. First, individual risks identified in the pre-mortem that aren't on the register get added with their probability, impact range, and a brief narrative justification — typically two to five new register entries per session on a programme that hasn't had a pre-mortem before. Second, existing risks on the register often get their probability or impact distributions recalibrated based on the pre-mortem discussion — the team's confidence intervals widen when the failure narrative makes the upside-risk side more vivid. Third, the pre-mortem surfaces correlation between risks that the register treats as independent — if multiple failure narratives share the same underlying cause (a key supplier, a regulatory approval, a technical interface), the QRA model should reflect that correlation rather than understating the joint risk. On UK MoD CADMID and IPA-gated programmes, a documented pre-mortem also functions as evidence of robust risk identification at the gateway review. Reviewers familiar with the technique recognise that a register supported by a pre-mortem has had at least one structured challenge to its completeness — that is meaningfully different from a register that emerged only from category-based brainstorming. Including the pre-mortem session date, participant list, and a sanitised summary of the failure narratives in the QRA documentation pack is good practice on any gate-reviewed programme. ### How SOMA uses pre-mortems SOMA Project Controls runs pre-mortems as part of QRA workshop facilitation on UK defence, nuclear, and infrastructure programmes. The shape of the engagement depends on the programme stage. For pre-investment programmes, the pre-mortem feeds the option-level QRA that supports the IPA Gate 1 / 2 decision. For in-flight programmes, the pre-mortem is used to test the existing risk register before a major rebaseline or contingency reset. In both shapes, the output is delivered as a documented session pack — facilitation script used, participant list, sanitised failure narratives, and a list of new or recalibrated risks for register integration — that holds up under independent reviewer scrutiny. ### Frequently asked questions **What is a pre-mortem in project management?** A pre-mortem is a risk identification technique developed by psychologist Gary Klein. The team imagines the project has already failed and writes down individually why. The framing surfaces tacit risks that conventional brainstorming misses, because the failure-has-happened assumption removes the social inhibition around criticising the plan. **How do you run a pre-mortem analysis?** Schedule a standalone 60–90 minute session with 8–12 participants. Frame the assumption: it is 12 months from now, the project has failed, write down why. Each participant writes individually in silence for 10 minutes. The facilitator collects responses anonymously, reads them aloud, groups similar entries, and works through whether each was on the existing register. The outputs feed the risk register and the QRA. **What is the difference between a pre-mortem and a post-mortem?** A pre-mortem happens before the project starts (or before a major phase) and imagines a future failure to identify risks. A post-mortem happens after the project (or phase) ends and analyses actual events to extract lessons learned. Pre-mortems feed forward into risk management; post-mortems feed forward into future projects. **When should you run a pre-mortem?** Run it after the team has enough shared context to describe the programme — typically after scope is defined and broad approach is understood — but before the plan has hardened to the point where challenging it feels disloyal. Repeat at the start of each major phase or after significant scope change; the second pre-mortem often surfaces the most valuable risks because the team's knowledge has updated. **Why is a pre-mortem better than asking "what could go wrong?"** Asking "what could go wrong?" returns generic, hedged answers because the brain treats it as a request for speculation. The pre-mortem framing — "the project has failed, explain why" — puts the brain into explanation mode, which generates concrete causal answers. The same participant who hedges in conventional brainstorming will write specific paragraphs about how a failure unfolded. **How does a pre-mortem feed into Quantitative Risk Analysis (QRA)?** Three ways. First, new risks identified in the pre-mortem get added to the register with probability and impact ranges. Second, existing register risks often have their distributions recalibrated based on the pre-mortem discussion. Third, the pre-mortem surfaces correlation between risks that the register treats as independent — feeding that correlation into the QRA model corrects under-stated joint risk. --- ## Capital Project Estimate Confidence Level — A Sponsor's Guide to P50, P80, P95 and IPA Cost Bands URL: https://www.somaprojectcontrols.com/resources/guides/capital-project-estimate-confidence-level Subtitle: For project sponsors, treasury teams, investment committees and capital approval boards. What "confidence level" actually means on a cost estimate, what the IPA Cost Estimating Requirements specify at each stage gate, when P80 is the right upper-bound sensitivity, and what to challenge in the QRA your project team has put in front of you. Published: 2026-05-22 · 12 min read ### What this guide is for If you are a project sponsor, treasury or finance team member, investment committee member or capital approver, you have probably been handed a cost estimate with phrases like "P50 cost", "P80 confidence", "Anticipated Final Cost", and "Optimism Bias Adjustment". These terms come from quantitative risk analysis and the HM Treasury / IPA framework that governs UK capital programme business cases. They are precise. They are also routinely misused — including in business cases that pass governance — and the cost of approving something whose confidence position you do not actually understand is paid years later, in overruns. This guide is the version of the confidence-level conversation aimed at the people making the approval decision, not at the analysts producing the QRA. It deliberately avoids the methodology depth that practitioner guides cover and instead focuses on what a sponsor needs to know to read a cost estimate properly, to ask the right challenging questions, and to defend the figure you eventually approve. For SOMA's practitioner-facing companion guide on the same topic — the deeper coverage of how the percentiles are calculated, what AACE recommended practices apply, and how Monte Carlo simulations are built — see the linked guide on confidence levels at the end of this article. ### What "confidence level" actually means on a cost estimate A confidence level on a capital cost estimate is the probability that the actual outturn cost will be at or below a stated figure. It is the output of a Monte Carlo simulation — a model run thousands of times with varied inputs — that produces not one cost number but a distribution of possible outturn costs. Each percentile of that distribution is one "confidence level": P50 is the cost figure with a 50% probability of not being exceeded, P80 with 80% probability, P95 with 95%. It is easier to read backwards. If your project P80 is £288m, that means: in 80% of the modelled outturn scenarios the cost is at or below £288m, and in 20% it exceeds. If you fund the project at £288m, you are accepting a one-in-five probability that it will overrun. If you fund at P50 (£262m on the same project) you are accepting roughly a one-in-two probability. If you fund at P95 (£315m) you are accepting a one-in-twenty probability. The distribution is rarely symmetric. On most capital projects, the spread between P50 and P95 is significantly wider on the upside than the spread between P5 and P50 on the downside — what statisticians call right-skewed. A project with a P50 of £100m might have a P95 of £135m but a P5 of only £90m. That asymmetry is what makes the choice of confidence level a commercial decision rather than a statistical one: you are choosing how much risk to underwrite, and the curve does not give you that decision back. The single most important thing to understand: the deterministic point estimate your team has been working to during planning is not the same as the P50, even though it is often labelled as the "most likely" figure. The most-likely outcome is the modal point of the distribution; the P50 is the median. On a right-skewed distribution the median is higher than the mode, which means a deterministic plan built around the most-likely cost is statistically biased low. This is one of the central reasons capital projects routinely overrun even when the deterministic plan looks defensible. ### Why your central estimate should be P50, not P80 The IPA Cost Estimating Guidance — the source UK departments treat as the working standard — is unambiguous on this point: the central estimate presented in a business case must be the "Median Scenario / P50 equivalent". This is not a convention you can choose to follow or not; it is the IPA's written requirement. The reasoning is statistical honesty. The point of presenting a single headline figure to an investment committee is to give them the best-supported estimate of what the project will actually cost. The P50 is, by construction, the figure with equal probability of being too high or too low. Any other percentile chosen as the headline figure is implicitly making a risk-appetite choice on behalf of the committee rather than presenting them with the central estimate they need to make that choice themselves. Many business cases present the P80 as the headline figure on the (well-intentioned) basis that funding at P80 is more prudent. This is exactly backwards: the P80 is a sensitivity test, not the central estimate. Presenting P80 as the headline conflates the central estimate with the contingency provision, makes it impossible for the committee to see what the project will actually cost as a central position, and routinely hides accumulated optimism bias by labelling the same number as both "the cost" and "the prudent cost". A well-structured business case shows the P50 as the central estimate, the P80 as the upper-bound sensitivity, and the requested funding (often at P80) as a separate explicit decision with its own justification. When you see a business case with no P50 — only a "budget at P80" — you should be asking what the underlying central estimate is. Funding decisions made against an obscured central estimate routinely turn into disputes about what was actually agreed. ### The IPA Cost Estimating Requirements at each stage gate The IPA framework presents cost confidence as percentage bands around the Anticipated Final Cost (AFC), with the band tightening as the project progresses through stage gates. The published requirements are: Strategic Outline Case (SOC): a tolerance band of -20% to +50% around the AFC. A project at SOC with an AFC of £100m has a defensible range of £80m to £150m. This is wide because the scope is still being defined and the estimating class (per AACE) is typically Class 5 (rough order of magnitude) to Class 4 (concept screening). Outline Business Case (OBC): a tolerance band of -15% to +30%. The same project at OBC should be inside £85m to £130m. The narrowing reflects that scope is now more defined, design is at concept-to-developed stage, and estimating is Class 3 (budget authorisation, control and cost-impact assessment) or better. Final Business Case (FBC): a tolerance band of -10% to +10%. The same project at FBC should be inside £90m to £110m. By this stage scope is locked, design is detailed, and estimating is Class 2 (control or bid / tender estimate). These bands are not the same thing as confidence levels — they are a separate IPA framework for expressing where the AFC sits within an expected range as the project matures. You will often see both presented together: the central estimate at P50, the IPA band giving the expected tolerance at this stage gate, and the P80 figure giving the explicit upper-bound sensitivity used to size contingency. A well-structured business case shows all three and explains how they relate. When the P80 from the QRA falls outside the IPA stage-gate band, that is a flag worth investigating. It either means the project carries materially more risk than is normal at this stage (which the business case should explicitly explain), or that the QRA is over-stating the risk (which a peer review would identify). Either way it is a sponsor-level question, not an analyst-level question. ### When P80 is the right upper-bound sensitivity (and when P95 is) P80 has become the de facto UK departmental convention for upper-bound sensitivity on capital programmes. It is the percentile most departments use to size contingency, the percentile contractors typically have to commit to under target cost arrangements, and the percentile that boards see in approval papers. But the convention is just that — a working benchmark — and the right percentile for any given decision depends on three things: the consequence of overrun, the appetite of the funding body for that consequence, and the cost of buying additional certainty. P80 fits comfortably on most UK infrastructure programmes where the funding body is a government department, the consequence of overrun is reputational and budgetary but recoverable, and the marginal contingency between P80 and higher percentiles is significant. On a £200m programme with a P50 of £200m and a P80 of £225m, the £25m contingency at P80 buys a one-in-five-protected position; moving to P95 might cost another £20m for only modest additional protection. P95 is the right percentile where the consequence of overrun is unacceptable rather than uncomfortable. Safety-critical defence programmes (where overrun risks operational capability), nuclear new-build (where overrun risks reputational and political consequences far beyond the budget), and portfolio-level capital safeguards (where the sponsor is underwriting many projects and cannot afford the one in five overrun rate that P80 implies) are the typical P95 contexts. The HM Treasury Green Book (2022, paragraphs 6.72-6.84) uses P90 as a worked example of how to express uncertainty around a central estimate — neither mandating that level nor ruling it out, but signalling that higher-percentile thinking is appropriate for high-value, high-impact proposals. P50 alone is appropriate where the funding decision explicitly accepts risk in exchange for lower upfront capital commitment — typically innovation programmes, technology demonstrators, and early-stage R&D where the sponsor has deliberately chosen to accept a 50% probability of overrun. This is a valid choice if it is made explicitly. The failure mode is funding at P50 while claiming P80 confidence, which is rarer than it was but still occurs on programmes where the QRA has not been scrutinised properly. The practical position for most UK public-sector business cases is: present the P50 as the central estimate (IPA-required), present P80 as the upper-bound sensitivity (departmental convention), use the IPA stage-gate tolerance bands to test that the figures are within normal expectation, and document why the funded position is where it is on the curve. "P80 because the Green Book says so" is not a defensible justification — the Green Book does not say so. "P80 because departmental finance has set that as the risk-appetite point and the IPA cost-band tolerance accommodates it" is defensible. ### What to challenge in the QRA presented to you Six questions a sponsor should ask of any QRA report before approving the figures. Each question targets a known failure mode that produces unreliable confidence-level outputs. First — does the risk register reflect this specific programme, or has it been copy-pasted from a template? A QRA built on a generic risk register produces generic numbers. Ask the team to point to the three risks that are most specific to this programme. If they cannot, the analysis is generic. Second — has correlation been modelled, and how? Zero correlation between risks (the default in many tools) almost always understates the spread because real projects bunch risks around common causes. A serious QRA shows the correlation matrix it has used and explains the dominant correlation pairs. Third — does the output distribution have a sensible shape? A right-skewed distribution (longer tail on the upside) is what you should see on most capital projects. A distribution that is symmetric and narrow is usually a sign that the inputs were guessed conservatively rather than calibrated against benchmark data. Ask to see the histogram, not just the percentile table. Fourth — what is in the tornado chart? A defensible QRA produces a tornado chart showing which inputs drive the variance. A small number of dominant drivers (typically three to six) is the normal pattern; a flat tornado where every input contributes equally usually means the model is generic. Ask which three drivers are most consequential and whether the team has a mitigation plan for them. Fifth — when was the QRA last run, and what has changed since? A QRA that is more than three months old on a live programme is likely to be stale. Scope changes, schedule slippage, supply chain shifts and new risks accumulate. Ask whether the cost-confidence position you are being shown reflects the current state of the project. Sixth — who has peer-reviewed the QRA? An internally-produced QRA that has not been reviewed by someone independent of the project team carries less weight at gateway review than one that has. For programmes above the IPA materiality threshold, a peer review or independent assurance opinion is typically expected before the figures support a funding decision. ### A worked example — the numbers in plain English Consider a £200m hospital construction programme being presented for FBC approval. The estimated cost build-up gives a deterministic figure of £200m. The project team's QRA gives a P50 of £212m, a P80 of £241m, and a P95 of £268m. The IPA stage-gate band at FBC is ±10%, giving an expected range of £190m to £233m around the most-likely figure. How does a sponsor read this? The deterministic £200m sits below the P50 of £212m, indicating that the deterministic plan is statistically optimistic — the modelled distribution suggests £212m is the most defensible central estimate. The IPA band's upper limit of £233m sits inside the P80 of £241m, suggesting the project carries slightly more risk than is normal at FBC stage (the P80 is "outside" the IPA band). The P95 at £268m is the figure that would protect against severe overrun but at considerable contingency cost. The decision the sponsor is being asked to make is: at what figure to approve. Approving at the deterministic £200m would carry a higher-than-50% probability of overrun and would be inconsistent with the IPA requirement to present a P50 central estimate. Approving at the P50 of £212m would mean accepting roughly a one-in-two probability of overrun, which is statistically honest but may be politically uncomfortable. Approving at the P80 of £241m would buy a one-in-five protected position and is the conventional UK departmental choice, but it sits slightly outside the IPA stage-gate band, which the business case needs to explain. Approving at the P95 of £268m would buy a one-in-twenty position but at £56m of additional contingency over the P80. A well-structured business case in this position would present P50 as the central estimate, request funding at P80, explain why the P80 sits slightly outside the IPA band (typically because the programme has identifiable risks that are larger than the comparator dataset assumes), and set out a contingency drawdown protocol that lets the project team use the P50-to-P80 gap as the project progresses without renegotiating funding. The sponsor approves the figure understanding both the central estimate and the risk position they are underwriting. ### Optimism bias adjustment and the Green Book Alongside the P50 central estimate, the HM Treasury Green Book requires explicit adjustment for optimism bias on capital business cases. Optimism bias is the documented tendency for project costs to outturn higher than ex ante estimates by a roughly predictable amount, derived from large empirical studies of completed projects. The Green Book publishes default optimism bias uplifts by sector and project type (typically 6% to 50% on capital expenditure depending on the sector and stage), to be applied unless the project can demonstrate why the default does not apply. The relationship between QRA-derived confidence levels and optimism bias adjustment is a regular point of confusion. They are addressing the same underlying problem (estimates outturn higher than expected) by different methods. The QRA models the project-specific risks and uncertainties bottom-up; the optimism bias adjustment applies a top-down empirical uplift derived from comparable historical projects. Both can be required by the Green Book — the QRA as the project-specific evidence, the optimism bias uplift as the empirical reality check. In practice the convention is to apply optimism bias to the central estimate (P50) before reading the P80 from the QRA. So if a project has a deterministic estimate of £200m, a sector optimism-bias uplift of 24% gives an optimism-adjusted base of £248m. The QRA then runs on the adjusted base and produces P50/P80/P95 figures around that. This avoids double-counting risk by applying both methods to the same baseline, which would produce contingency figures that are unrealistically large. Sponsors should ensure the business case is explicit about whether optimism bias has been applied, at what rate, and at what point in the calculation chain. A common failure mode is for the optimism bias adjustment to be presented separately from the QRA result with no clear statement of how they combine, leaving the approving body uncertain whether the figure they are seeing already incorporates the empirical uplift or not. ### The decision in front of you When you are presented with a capital project cost estimate and asked to approve it, the questions in front of you are: what is the project's P50 central estimate (and is it the optimism-adjusted figure or not)? What is the P80 the team is recommending as the funded position? Where do those figures sit relative to the IPA stage-gate band at this stage? What are the three risks driving the spread, and what mitigation is planned? When was the QRA last run, and who has peer-reviewed it? If the business case answers those six questions clearly, the figure is approvable on the evidence presented. If any of them is opaque — if the central estimate is presented at P80 with no underlying P50, if the IPA band is not referenced, if the risk drivers cannot be named, or if peer review is missing — the right response is not to refuse approval but to send the business case back for the missing evidence before approving. Approving against an incomplete confidence-level picture is what produces the disputes years later about what was actually agreed at sanction. The single biggest cost-control discipline available to a sponsor is to refuse to approve a figure they do not actually understand the confidence position behind. The single most common controls failure is to approve one anyway under time pressure. The framework above is what makes the difference. ### Frequently asked questions **What does "confidence level" mean on a capital project cost estimate?** A confidence level is the probability that the actual outturn cost will be at or below a stated figure. A P50 cost has a 50% probability of not being exceeded; a P80 cost has 80% probability; a P95 cost has 95% probability. The confidence levels come from a Monte Carlo simulation that runs the cost model thousands of times with varied inputs, producing a distribution of possible outturn costs from which any percentile can be read. **Does the IPA require P50 or P80 as the central estimate for a UK business case?** The IPA Cost Estimating Guidance requires the central estimate in a business case to be the "Median Scenario / P50 equivalent". P80 is not the IPA's written requirement for the central estimate — it is a UK departmental convention for upper-bound sensitivity that has emerged separately. Presenting P80 as the headline figure conflates the central estimate with the contingency provision and is inconsistent with the IPA requirement. **What are the IPA cost-estimating tolerance bands at each stage gate?** The IPA tolerance bands around the Anticipated Final Cost are: Strategic Outline Case -20% to +50%; Outline Business Case -15% to +30%; Final Business Case -10% to +10%. These bands reflect the expected range of the AFC as scope, design and estimating maturity improve through stage gates. They are separate from the QRA-derived confidence percentiles and the two are typically presented together: the P50 as the central estimate, the IPA band as the expected range at this stage gate, and the P80 as the upper-bound sensitivity used to size contingency. **When should a project be funded at P95 instead of P80?** P95 is appropriate when the consequence of overrun is unacceptable rather than uncomfortable. The typical contexts are safety-critical defence programmes, nuclear new-build, and portfolio-level capital safeguards where the sponsor is underwriting many projects and cannot afford the one-in-five overrun rate that P80 implies. The HM Treasury Green Book uses P90 as a worked example for high-value high-impact proposals — neither mandating that percentile nor ruling it out, but signalling that higher-percentile thinking is appropriate for some programmes. **How does optimism bias relate to QRA confidence levels?** Optimism bias is the empirically-observed tendency for project costs to outturn higher than ex ante estimates by a predictable amount, derived from large studies of completed projects. The Green Book publishes default uplifts by sector. QRA-derived confidence levels model project-specific risks bottom-up. Both can be required: the QRA as project-specific evidence, the optimism-bias uplift as empirical reality check. Convention is to apply optimism bias to the P50 central estimate before reading the P80 from the QRA, to avoid double-counting risk. **What questions should a sponsor ask before approving a QRA?** Six diagnostic questions cut through quickly. First, does the risk register reflect this specific programme or has it been copy-pasted from a template? Second, has correlation between risks been modelled (zero correlation almost always understates the spread)? Third, does the output distribution have a sensible right-skewed shape? Fourth, what does the tornado chart say about the three dominant variance drivers? Fifth, when was the QRA last run and what has changed since? Sixth, who has peer-reviewed it? If any answer is unclear, the right response is to send the business case back for the missing evidence before approving — not to approve anyway under time pressure. **What is the difference between a deterministic cost estimate and a P50 cost?** A deterministic cost estimate is a single point figure produced by building up quantities and rates — the "most likely" outcome. A P50 cost is the median of the modelled cost distribution from a QRA, the figure with equal probability of being too high or too low. These are not the same number. On a right-skewed distribution (which most capital projects are), the median is higher than the mode, which means a deterministic plan built around the most-likely cost is statistically biased low. This is one of the central reasons capital projects routinely overrun even when the deterministic plan looks defensible. --- ## How Much Does a QRA Cost in the UK? URL: https://www.somaprojectcontrols.com/resources/guides/how-much-does-a-qra-cost-uk Subtitle: What actually drives the price of a Quantitative Risk Analysis, how QRA work is priced, and how to compare quotes without getting caught out. Published: 2026-06-01 · 8 min read ### The honest short answer There is no flat rate for a Quantitative Risk Analysis, and any provider who quotes one before understanding your programme is guessing. The cost is driven almost entirely by scope: what you are modelling, how clean your inputs are, how complex the programme is, and what the output has to survive. A focused schedule risk analysis on a single, well-structured programme is a different order of cost from an integrated cost-and-schedule QRA across a multi-package portfolio with bespoke correlation modelling and gateway-grade reporting. That is not a dodge. It is the same reason a structural engineer cannot quote to design a building from the postcode alone. The useful question is not "what does a QRA cost" in the abstract — it is "what drives the cost of a QRA, and where does my programme sit on each of those factors". This guide answers that, so you can frame the conversation and recognise a credible quote when you see one. ### What actually drives the cost Scope of analysis is the biggest lever. A Quantitative Schedule Risk Analysis (QSRA) against an existing programme is the lightest engagement; a Quantitative Cost Risk Analysis (QCRA) against a cost estimate is comparable. An integrated cost-and-schedule analysis (QCSRA), where schedule risk correctly drives its cost consequences, is the most involved because both models have to be built, aligned and run together. Programme size and complexity scale the effort directly. A 500-activity schedule with three delivery packages is a fraction of the work of a 5,000-activity integrated master schedule across fifteen packages and multiple interfaces — more activities, more risks, more correlation relationships, and more workshops to populate them credibly. Input readiness is the factor clients control and most underestimate. If your P6 schedule is logic-linked and free of artificial constraints, your base estimate has had buried contingency stripped out, and you have a real risk register with named owners, the analyst spends their time modelling. If the schedule is constraint-driven, the estimate has contingency baked into every line, and the risk register is a copy-pasted template, the analyst spends days on data remediation before any modelling begins — and you pay for that time. Output requirements move the number too. A working internal QSRA to inform a contingency decision is one thing; a QRA that has to survive an IPA gateway review or an SSRO submission — documented methodology, transparent assumptions, an AACE-aligned approach, and a report a review panel can interrogate — carries more rigour and more cost. So does a live model maintained through delivery versus a one-off run at sanction. ### How QRA work is usually priced Fixed-scope package is the most common model and, for the buyer, usually the safest. The provider scopes the analysis — number of workshops, model build, deliverables, one round of revisions — and quotes a fixed fee against it. You know the cost upfront and the risk of overrun sits with the provider. This works precisely because a competent provider can scope a QRA accurately once they understand the programme. Day-rate or time-and-materials is used where the scope genuinely cannot be pinned down upfront — an exploratory piece, or an engagement that will evolve. The upside is flexibility; the downside is that cost certainty sits with you, and a QRA that hits messy inputs can run longer than planned. If a provider only offers day-rate for what is clearly a well-defined QRA, ask why. Retained or embedded arrangements apply where risk analysis is an ongoing need — a major programme that wants its QRA maintained and re-run at each gate, or an organisation building risk capability across a portfolio. This is priced as a recurring engagement rather than a one-off, and is usually the most cost-effective per-run once the models exist. ### What a credible QRA quote should include A quote worth comparing should spell out the workshops (how many, and with whom — risk identification and three-point estimating need the right people in the room), the model build itself, and the analytical depth: correlation modelling, separation of base-estimate uncertainty from discrete risks, and sensitivity analysis — not just a headline S-curve. It should name the deliverables: the S-curve and confidence levels (P50, P80, P95), a tornado chart identifying the risks actually driving variability, and a written report a decision-maker — or a gateway reviewer — can act on. A QRA that delivers a number with no tornado is delivering half the value, because the number tells you how much contingency to hold but the tornado tells you what to manage. It should state the methodology and tooling (an AACE-aligned approach; Safran Risk, Primavera Risk Analysis, @Risk or Acumen Risk), who is actually doing the work (a named, experienced analyst rather than a junior running a template), and what is included for revisions. The absence of these is the signal, not the headline price. ### Red flags that make a cheap QRA expensive A suspiciously low fixed price usually means one of three things: a template risk register applied without genuine workshops, zero correlation modelling (which understates the spread and produces a falsely confident number), or junior-only delivery. Each produces a QRA that looks like the real thing and falls apart under scrutiny — at exactly the gateway or board meeting where it matters most. A QRA that does not survive challenge is not cheaper; it is wasted, plus the cost of redoing it. The other false economy is commissioning a QRA against inputs that are not ready. If your schedule and estimate are not in a fit state, the cheapest route to a credible number is to get them ready first — or to engage a provider who will fix the inputs as part of the work and tell you honestly what that adds. Paying for a QRA on bad inputs buys a precise answer to the wrong question. ### Getting an accurate number for your programme The only way to a real figure is a short conversation about your programme: what you are modelling, how big and complex it is, what state the inputs are in, and what the output has to satisfy. Twenty minutes is usually enough to scope an engagement and give you a fixed-scope quote you can take to a budget holder. SOMA delivers QRA as independent, tool-agnostic, fixed-scope engagements built to AACE recommended practice — QSRA, QCRA and integrated QCSRA — with reports written so a board or a gateway reviewer can act on the number. If you are weighing up commissioning a QRA, a scoping call is the fastest way to understand what yours would actually cost. ### Frequently asked questions **How much does a QRA cost in the UK?** There is no flat rate — the cost is driven by scope. A focused Quantitative Schedule Risk Analysis on a single, well-structured programme sits at the lighter end; an integrated cost-and-schedule QRA across a complex multi-package programme, with bespoke correlation modelling and gateway-grade reporting, costs several times more. The main drivers are scope of analysis (QSRA vs QCRA vs integrated QCSRA), programme size and complexity, how ready your inputs are, and what the output has to survive. Most reputable providers price a QRA as a fixed-scope package once they understand the programme, so you have cost certainty upfront. **Is a QRA priced per day or as a fixed fee?** Most well-defined QRAs are priced as a fixed-scope package — the provider scopes the workshops, model build and deliverables and quotes a fixed fee, so the overrun risk sits with them. Day-rate pricing is used where the scope genuinely cannot be pinned down upfront. If a provider only offers a day rate for what is clearly a well-defined QRA, ask why — it usually means they are not confident scoping it. **What makes a QRA more expensive?** Four things, in rough order of impact: a broader scope (an integrated cost-and-schedule QCSRA costs more than a schedule-only QSRA); a larger, more complex programme (more activities, risks and correlation relationships, more workshops); poor input readiness (a constraint-driven schedule, contingency buried in the estimate, or a template risk register all force data-remediation time before modelling begins); and demanding output requirements (a QRA that must survive an IPA gateway or SSRO submission carries more rigour than a working internal run). **What should be included in a QRA quote?** A credible quote should specify the workshops (how many and with whom), the model build, the analytical depth (correlation modelling, separation of base-estimate uncertainty from discrete risks, sensitivity analysis), the deliverables (an S-curve with P50/P80/P95, a tornado chart, and a written report), the methodology and tooling (AACE-aligned; Safran, Primavera Risk Analysis, @Risk or Acumen), who is doing the work, and what is included for revisions. A quote that is just a number with no tornado chart or methodology is a red flag. **How long does a QRA take?** A focused QSRA or QCRA on a programme with reasonably clean inputs is typically a matter of weeks from kick-off to final report, paced mainly by workshop scheduling. An integrated QCSRA on a large, complex programme, or one where the inputs need remediation first, takes longer. The single biggest driver of timescale — as with cost — is the state of the schedule, estimate and risk register at the start. --- ## QRA Consultant vs In-House: How to Decide URL: https://www.somaprojectcontrols.com/resources/guides/qra-consultant-vs-in-house Subtitle: When it makes sense to run a Quantitative Risk Analysis with your own team, when you need an independent consultant, and the hidden costs of getting that call wrong. Published: 2026-06-01 · 9 min read ### It is a build-vs-buy decision, and both can be right Whether to run a Quantitative Risk Analysis in-house or commission an independent consultant is a build-vs-buy decision, and the honest answer is that either can be right. It turns on three things: whether you have the capability, whether you have the tooling, and whether the output has to be credible to someone outside your organisation. Most teams get this wrong by defaulting to whichever looks cheaper on the surface, rather than asking what the QRA is actually for. The deciding question is rarely cost. It is independence and credibility. A QRA produced to inform an internal contingency decision is a different thing from a QRA that has to survive an IPA gateway, justify a funding ask to a board, or stand up in a contractual dispute. The first you can reasonably do in-house if you have the skills; the second is where independence stops being a nicety and becomes part of what makes the number believable. ### When in-house QRA makes sense In-house is the right call when you genuinely have the capability and the need is recurring. That means a trained risk analyst — someone who has facilitated three-point estimating workshops, built and calibrated Monte Carlo models, and can defend correlation and distribution choices — not a planner who has watched a tutorial. It means the licensed tooling (Safran Risk, Primavera Risk Analysis, @Risk or Acumen Risk) and the time to use it properly. And it means a risk culture where the register is real and owners challenge their own numbers. In-house also makes sense when the analysis is iterative and internal. If you are running a QRA monthly to track changing exposure on a live programme, the turnaround and context-retention of an internal analyst is genuinely valuable — you are not re-briefing an external party every cycle. For working analysis that informs your own decisions and does not have to convince an outside reviewer, in-house is often the better answer once the capability exists. The honest test is this: if your internal QRA were handed to a sceptical gateway reviewer, would it survive? If the answer is yes — your methodology is AACE-aligned, your inputs are calibrated, your model is defensible — then you have real capability and should use it. The trap is that most teams who assume they have this capability have never had it tested against genuine outside challenge. ### When you need an independent QRA Independence becomes the point — not a luxury — the moment the number faces external scrutiny. IPA gateway reviews, HM Treasury Green Book business cases, SSRO submissions on single-source defence contracts, board-level capital approvals, and contractual disputes all share a feature: the reader is looking for reasons not to trust the number, and a figure produced by the team that wants the funding carries an obvious conflict. An independent QRA removes that conflict, so the methodology can be challenged without the motive being in question. Independence also guards against optimism bias, which is not a character flaw but a structural force. Internal teams are under pressure — explicit or implicit — to produce a number the organisation is comfortable with. HM Treasury formalised optimism-bias uplifts precisely because in-house estimates run systematically optimistic. An independent analyst with no stake in the outcome is the most reliable defence against a QRA that quietly tells the sponsor what they want to hear. The infrequent-need case is the other clear trigger. If you run one or two QRAs a year, building in-house capability is hard to justify: the tool licences, the training to genuine competence (which takes years of real reps, not a course), and the opportunity cost of senior time rarely pay back against a fixed-scope external engagement. Independence and infrequency together make the buy decision straightforward. ### The hidden costs of "in-house" The in-house option looks cheaper because the salary is already being paid, but that framing hides most of the real cost. Specialist QRA tooling carries meaningful annual licence fees. Training an analyst to genuine competence is measured in years of supervised reps, not a training course — and a half-trained analyst produces a QRA that looks right and is wrong in ways nobody catches until a reviewer does. The opportunity cost of a senior controls professional spending two weeks building a model is real, especially on a stretched team. The largest hidden cost is the credibility gap. An in-house QRA that gets challenged at a gateway and cannot defend its correlation treatment, its distribution choices, or its separation of base-estimate uncertainty from discrete risk does not just fail — it costs you the time to redo it under pressure, plus the loss of confidence in everything else the team has produced. A QRA that has to be redone independently after failing scrutiny is the most expensive QRA of all: you paid for it twice and lost credibility in between. ### A pragmatic middle path The choice is not strictly binary. A common and sensible pattern is independent for the runs that face outside scrutiny — the gateway submission, the funding case, the board paper — and in-house for the working, iterative analysis that informs day-to-day decisions. The independent run sets the defensible baseline and the methodology; the internal team maintains and re-runs it between gates. The other middle path is independent delivery now, capability-building alongside. Bring in an independent QRA for the engagement in front of you, and use it as the vehicle to train your own people — workshops they sit in, a model they can interrogate, a methodology they can adopt. Over time you build the in-house capability that lets you take more of the working analysis internally, while keeping independence for the runs that need it. This is how most organisations should move from buy to build, rather than attempting in-house from a standing start on a programme that cannot afford the learning curve. ### How to decide for your programme Start with what the QRA is for. If it has to convince anyone outside your team — a gateway, a funder, a board, a counterparty — default to independent, because independence is part of the credibility you are buying. If it is internal working analysis and you have genuinely tested capability and tooling, in-house is reasonable. If you are unsure whether your in-house capability would survive scrutiny, that uncertainty is itself the answer. SOMA delivers independent QRA to AACE recommended practice, and also builds client capability — through training and the SOMA Academy — for teams moving toward in-house. If you are weighing the two for a specific programme, a short scoping call is the fastest way to get an honest read on which is right for you, and what an independent engagement would cost if that is the route you take. ### Frequently asked questions **Should we run a QRA in-house or hire a consultant?** It depends on capability, tooling and audience. Run it in-house when you have a trained risk analyst, licensed Monte Carlo tooling, and the number is for internal decision-making. Use an independent consultant when the QRA faces external scrutiny — an IPA gateway, a funder, a board, or a dispute — where independence is part of what makes it credible, or when QRA is too infrequent to justify the tooling and training. The deciding factor is usually independence and credibility, not surface cost. **Is an in-house QRA cheaper than a consultant?** Often only on the surface. The salary may already be paid, but the real cost of in-house includes specialist tool licences, the years of supervised practice it takes to train an analyst to genuine competence, and the opportunity cost of senior time. The largest hidden cost is the credibility gap: an in-house QRA that fails at a gateway has to be redone independently under pressure — so you pay for it twice and lose confidence in between. For infrequent QRA needs, a fixed-scope external engagement is usually better value. **When does a QRA have to be independent?** When the number faces external scrutiny. IPA gateway reviews, HM Treasury Green Book business cases, SSRO single-source defence submissions, board-level capital approvals, and contractual disputes all involve a reader looking for reasons not to trust the figure. A QRA produced by the team that wants the funding carries an obvious conflict; an independent QRA removes it, so the methodology can be challenged without the motive being in question. Independence also guards against optimism bias, which HM Treasury introduced uplifts to counter precisely because in-house estimates run systematically optimistic. **Can we build in-house QRA capability over time?** Yes, and the most reliable route is alongside an independent engagement rather than from a standing start. Bring in an independent QRA for the work in front of you and use it to train your people — they sit in the workshops, interrogate the model, and adopt the methodology. Over time you take more of the working, iterative analysis in-house while keeping independence for the runs that face outside scrutiny. SOMA supports this through training and the SOMA Academy as well as delivery. --- # Glossary ## Quantitative Risk Analysis (QRA) URL: https://www.somaprojectcontrols.com/resources/glossary/quantitative-risk-analysis A numerical assessment of project risk that produces probability-weighted cost and schedule outcomes rather than red/amber/green ratings. Quantitative Risk Analysis (QRA) is the process of assigning numbers to uncertainty. Rather than saying a risk is 'high', QRA asks: how likely is it, and if it occurs, how much time or money could it add? The outputs are probability distributions — typically an S-curve showing the range of possible outturn costs or dates, and the likelihood of achieving each one. QRA usually combines both schedule and cost risk in a single integrated model so that the two are not assessed in isolation. QRA is used when stakeholders need a defensible cost or schedule confidence range — for example, to set a contingency budget, to advise a board on P50 vs P80 funding levels, or to satisfy a gateway review requirement. It is most valuable early in a project's life when uncertainty is highest and decisions about scope and funding are still live. On major infrastructure projects, QRA is frequently a contractual or regulatory requirement. The most common mistake is treating QRA as a box-ticking exercise — running the model once to get a number, rather than using it to understand which risks drive the most variability. A good QRA should highlight the top five to ten risk drivers so the project team can actively manage them. Watch out for poorly calibrated three-point estimates: if everyone gives optimistic low values and pessimistic high values that are barely wider than the most likely, the model will produce falsely narrow output bands. And always check whether correlation between risks has been considered — costs and schedule impacts rarely move independently. ### Frequently asked questions **What is quantitative risk analysis in project management?** Quantitative risk analysis (QRA) is the process of converting identified project risks into probability-weighted cost or schedule outcomes. Rather than rating risks red/amber/green, QRA assigns probability distributions to uncertainty and runs a Monte Carlo simulation to produce an S-curve showing the range of possible outturn costs or completion dates — for example, a P50 (50% chance of achieving) and a P80 (80% chance). It is used to set defensible contingency budgets and satisfy gateway review requirements on major infrastructure and defence programmes. **When should you use quantitative risk analysis?** QRA is most valuable early in a project's life when uncertainty is highest and funding decisions are still live. It is typically required at RIBA Stage 2–3 or equivalent gateway stages, when setting the project budget for treasury or board approval, when the contract requires it (common on NEC4, FIDIC, and government frameworks), or when a deterministic cost plan has been challenged as optimistic. It is not cost-effective on small, low-complexity projects where the cost of the analysis exceeds the contingency it would size. **What is the difference between qualitative and quantitative risk analysis?** Qualitative risk analysis scores risks by likelihood and impact on a descriptive or ordinal scale (high/medium/low or 1–5) to prioritise them for management attention. Quantitative risk analysis assigns numerical probability distributions to uncertainty and combines them mathematically — usually via Monte Carlo simulation — to produce a probability distribution of total project cost or completion date. Qualitative analysis is faster and suitable for most risk registers; quantitative analysis is needed when a defensible confidence-level figure is required for funding, contracts, or governance. **What is the output of a quantitative risk analysis?** The primary output is a probability distribution — usually displayed as an S-curve — showing the likelihood of achieving each possible total cost or completion date. From this, key confidence-level figures are read off: P50 (50% probability of not exceeding), P80, P90 etc. Secondary outputs include a sensitivity analysis (tornado chart) identifying the top risk drivers by contribution to variance, and a risk-by-risk breakdown showing which items contribute most to the contingency requirement. --- ## Earned Value Management (EVM) URL: https://www.somaprojectcontrols.com/resources/glossary/earned-value-management A performance measurement technique that integrates scope, schedule, and cost to give an objective picture of where a project really stands. Earned Value Management (EVM) is a method for measuring project performance by comparing what you planned to spend, what you actually spent, and what you actually got done — all in the same currency. The three core data points are Planned Value (PV), the budgeted cost of work scheduled; Earned Value (EV), the budgeted cost of work actually completed; and Actual Cost (AC), what you really spent to do that work. From these three numbers you can calculate whether you are ahead or behind schedule, and whether you are over or under budget, at any point in the project. EVM is most useful on projects where there is a clear baseline against which performance can be measured — which means it works best when scope is well-defined and the schedule and budget have been properly baselined before work starts. It is widely used in defence, infrastructure, and major capital programmes. Funders and clients often require EVM reporting because it replaces subjective progress claims with objective, verifiable metrics. Forecasting to completion — the Estimate at Completion (EAC) — is one of EVM's most powerful outputs. The biggest trap with EVM is gaming the earned value. If progress is self-reported by the same team responsible for delivery, there is pressure to inflate EV to make the numbers look better. Physical percent-complete rules — such as the 0/100 or 50/50 rule — help prevent this by tying earned value to objective milestones rather than subjective estimates. Another common mistake is running EVM without a realistic baseline: if the original plan was too optimistic, the metrics will show variances that reflect bad planning rather than bad execution, and the forecasts will be unreliable from day one. ### Frequently asked questions **What is earned value management?** Earned value management (EVM) is a project performance measurement technique that integrates scope, schedule, and cost into a single framework. It compares Planned Value (PV — what work was scheduled to be done by now) with Earned Value (EV — the budgeted cost of the work actually completed) and Actual Cost (AC — what was actually spent). The gap between EV and PV gives Schedule Variance; the gap between EV and AC gives Cost Variance. These metrics provide an objective, early-warning picture of whether a project is ahead or behind on both time and cost. **What is the difference between CPI and SPI in earned value?** Cost Performance Index (CPI = EV ÷ AC) measures cost efficiency — a CPI of 0.9 means you are getting 90p of work done for every £1 spent. Schedule Performance Index (SPI = EV ÷ PV) measures schedule efficiency — an SPI of 0.85 means the project has completed 85% of the work that was planned. Both are dimensionless ratios: values below 1.0 signal underperformance, values above 1.0 signal over-performance. CPI is generally the more reliable predictor of final cost at completion. **How do you calculate Estimate at Completion (EAC) in EVM?** The most common formula is EAC = BAC ÷ CPI, where BAC is Budget at Completion and CPI is the cumulative Cost Performance Index. This assumes current cost efficiency continues for the rest of the project. Alternative formulas exist for different assumptions: EAC = AC + (BAC − EV) assumes future work runs at budget; EAC = AC + (BAC − EV) ÷ (CPI × SPI) weights both cost and schedule performance. The CPI-based formula is generally the most accurate predictor on programmes past the 20% completion point. **What is the difference between earned value and planned value?** Planned Value (PV) is the budgeted cost of the work that was scheduled to be complete by the measurement date — it comes from the baseline schedule. Earned Value (EV) is the budgeted cost of the work that has actually been completed by the same date — it reflects physical progress. The difference (EV − PV) is Schedule Variance: negative means behind schedule, positive means ahead. EV does not measure money spent; it measures the monetary value of work done at the planned rate, which is why it can be compared meaningfully against PV. --- ## DCMA 14-Point Assessment URL: https://www.somaprojectcontrols.com/resources/glossary/dcma-14-point-assessment A standardised schedule health check that scores a programme against 14 measurable criteria to test whether it is logically sound and fit for use. The Defense Contract Management Agency (DCMA) 14-Point Assessment is a schedule quality checklist originally developed for US defence programmes but now widely used across major infrastructure and engineering projects worldwide. It examines 14 specific metrics — including the proportion of tasks with missing logic, the number of high-float or high-duration activities, hard constraints, missed logic between activities and resource assignments, and negative float — to determine whether a schedule is sufficiently well-constructed to be relied upon for forecasting and decision-making. Planners and project controls engineers use the DCMA assessment at baseline submission, at programme reviews, and when inheriting a schedule from another party. It gives a rapid, objective view of schedule health without having to read thousands of lines of Gantt data. Many client organisations and contracting bodies now require a DCMA assessment report as part of their schedule acceptance process, particularly on NEC and infrastructure contracts. Passing the DCMA thresholds is not a guarantee that the programme logic is correct, but failing it is a clear signal that the schedule should not be trusted. The most common failures are missing logic (activities with no predecessors or successors, known as open ends) and excessive hard constraints, both of which prevent the critical path from flowing correctly. A schedule with hundreds of open ends will give a misleading critical path and unreliable date forecasts. Planners should aim to resolve all open ends and minimise hard constraints before submitting a schedule for review. Be aware that the DCMA thresholds are guidelines, not absolute pass/fail lines — context matters, and a small number of justifiable exceptions is normal on any real programme. --- ## Merge Bias URL: https://www.somaprojectcontrols.com/resources/glossary/merge-bias The tendency for a schedule to underestimate duration at points where multiple paths converge, because any one of those paths running late will cause delay. Merge bias is a statistical phenomenon that occurs wherever two or more parallel activity paths converge on a single successor task or milestone. Because the merged activity cannot start until all of its predecessors are complete, the actual duration to that point is driven by the longest path — not the average path. When paths are roughly equal in length, the probability that at least one of them will be late is much higher than the probability that any single path will be late. Standard deterministic scheduling tools ignore this effect entirely. Merge bias matters because it means that deterministic schedules consistently underestimate duration at points where paths converge. The more parallel paths converge, the more optimistic the deterministic date becomes. This is one of the main reasons that Monte Carlo-based Schedule Risk Analysis (SRA) will often produce a P50 date that is later than the deterministic critical path end date, even before any specific risks are applied. Understanding merge bias helps explain to clients and stakeholders why a probabilistic schedule analysis gives a later expected completion than the baseline Gantt. In practice, the best way to account for merge bias is to run a proper Monte Carlo simulation rather than relying solely on the deterministic schedule. However, even without simulation, planners can sense-check a schedule by identifying near-critical paths — those with small amounts of float — and considering whether the convergence of several near-critical paths creates a realistic risk of delay that the headline programme does not reflect. Programmes with many parallel workstreams all converging on a single commissioning milestone are particularly vulnerable to merge bias. --- ## Monte Carlo Simulation URL: https://www.somaprojectcontrols.com/resources/glossary/monte-carlo-simulation A computer-based technique that runs thousands of possible project scenarios to produce a probability distribution of cost or schedule outcomes. Monte Carlo simulation is named after the famous casino — the idea being that it uses random sampling to model uncertainty, just as a roulette wheel produces a distribution of outcomes over many spins. In project controls, the simulation runs the project model thousands of times (typically 5,000 to 10,000 iterations), each time drawing a different set of values from the input uncertainty ranges. The result is not a single date or cost figure but a full probability distribution: you can see the likelihood of completing by any given date or within any given budget. Monte Carlo is used in both Schedule Risk Analysis (SRA) and Cost Risk Analysis (CRA). In a schedule model, the simulation captures the combined effect of activity duration uncertainty and discrete risk events — including merge bias, which a deterministic network cannot show. In a cost model, it quantifies the range of possible outturn cost given uncertainty in quantities, rates, and risk allowances. The output — most commonly displayed as an S-curve — allows project teams and funders to make informed decisions about contingency and programme dates at defined confidence levels such as P50 or P80. The simulation is only as good as the inputs. Garbage in, garbage out applies here more than almost anywhere else in project controls. Common pitfalls include three-point estimates that are too narrow (calibration bias), failing to model correlation between related risks, and treating every activity as independent when in reality many of them will be affected by the same underlying causes. Always interrogate the sensitivity outputs — tornado charts and criticality indices — to understand which activities and risks are actually driving the range of outcomes. ### Frequently asked questions **What is a Monte Carlo simulation in project management?** A Monte Carlo simulation is a computational technique that runs a project model thousands of times, each time drawing random values from the probability distributions assigned to uncertain inputs (activity durations, costs, risk event impacts). The outputs are aggregated into a probability distribution showing the range of possible project outcomes — typically displayed as an S-curve of completion dates or total costs. The technique is a rigorous method for quantifying cost and schedule risk when multiple uncertain variables interact. **How many iterations should a Monte Carlo simulation run?** Most practitioners use 5,000–10,000 iterations as standard, with 10,000 being common on large programmes to ensure the tails of the distribution are well-sampled. Below 1,000 iterations, results can be unstable — running the same model twice may give noticeably different P80 figures. For high-stakes submissions such as gateway reviews or board papers, 10,000 iterations with a fixed random seed is good practice so results are reproducible. **What is the difference between Monte Carlo simulation and PERT?** PERT uses a single analytical formula — (O + 4M + P) ÷ 6 — to estimate expected duration and calculates variance analytically. Monte Carlo simulation runs thousands of random iterations and can accommodate any distribution shape, correlations between activities, and discrete risk events that PERT cannot model. For realistic programmes with interacting risks and risk-register events, Monte Carlo is significantly more accurate and the industry standard for formal QRA. **What does P80 mean in a Monte Carlo result?** P80 is the value at the 80th percentile of the output distribution — there is an 80% probability the project will complete within that cost or by that date, and a 20% probability of exceeding it. UK government guidance and most major infrastructure clients use P50 as the central planning estimate and P80 for funding approvals, on the principle that public money should be committed at 80% confidence. The choice between confidence levels is a risk-appetite decision: higher confidence requires more contingency. --- ## P50 / P80 / P95 (Confidence Levels) URL: https://www.somaprojectcontrols.com/resources/glossary/p50-p80-p95 Probability thresholds from a risk analysis: P50 means a 50% chance of finishing by that date or within that cost; P80 means an 80% chance, and so on. When a Monte Carlo simulation produces an S-curve of possible project outcomes, you can read off any percentile. P50 is the median outcome — half of all simulated scenarios finish by that date or within that cost, and half do not. P80 means that 80% of scenarios are at or below that value, giving a much higher level of confidence. P95 is a near-worst-case figure used when the consequences of overrun are severe. The choice of which percentile to use for budgeting or scheduling is a risk-management decision, not a technical one. What UK guidance actually requires is more nuanced than the convention suggests. The IPA Cost Estimating Guidance specifies that UK government business cases must present the 'Median Scenario / P50 equivalent' as the central estimate at every stage gate, with confidence ranges expressed as percentage bands around the Anticipated Final Cost (SOC ±20–50%, OBC ±15–30%, FBC ±10%). The HM Treasury Green Book 2022 requires explicit risk and optimism-bias adjustment and recommends Monte Carlo for high-cost, high-risk proposals, but does not mandate a specific P-level — its worked example uses P90, not P80. P80 has become a de facto upper-bound sensitivity used by many departments, and is treated as a standard sensitivity alongside P50 in some published departmental guidance (Homes England), but it is a working convention rather than a written HMT/IPA requirement. A common mistake is confusing the P-value from a risk analysis with a guarantee. A P80 date does not mean the project will definitely finish by then — it means it should do so eight times out of ten, assuming the risk model is well-calibrated. In reality, optimism bias in the inputs means that real-world outturn often exceeds even P80 estimates. Another trap is presenting only the P50 to clients or executives without explaining what it means: many stakeholders hear '50% chance' and assume the project is poorly planned, when in fact a P50 outturn is a well-calibrated central estimate. The worst failure mode is justifying a P80 funding figure by claiming 'the Green Book says so' — the Green Book does not, and IPA reviewers familiar with the source will challenge the justification. --- ## Critical Path Method (CPM) URL: https://www.somaprojectcontrols.com/resources/glossary/critical-path-method A scheduling technique that identifies the longest sequence of dependent activities through a project — the path that determines the earliest possible finish date. The critical path is the sequence of activities that, if any one of them is delayed, will push back the project end date. It is found by calculating two passes through the network: the forward pass (which gives the earliest possible start and finish for each activity) and the backward pass (which gives the latest allowable start and finish without extending the project). Activities where these two calculations produce the same dates have zero total float — they are critical. The chain of zero-float activities from start to finish is the critical path. The mechanics work like this. In the forward pass, the planner walks through the network from the project start, calculating each activity's Early Start (ES) and Early Finish (EF). ES of the first activity is day 0; EF = ES + duration. For any successor activity, ES is the maximum EF of all its predecessors (because the successor cannot begin until every predecessor is done). When the walk reaches the project end, the EF of the final activity is the earliest possible project completion date. The backward pass then walks back from that completion date, calculating each activity's Late Finish (LF) and Late Start (LS) — the latest dates each activity can finish and start without pushing the project end out. For any predecessor, LF is the minimum LS of all its successors. Total Float for each activity = LS − ES (or equivalently LF − EF). Activities with zero total float lie on the critical path. A short worked example makes it concrete. Imagine four activities: A (5 days, no predecessors), B (3 days, follows A), C (7 days, follows A), D (2 days, follows both B and C). Forward pass: A runs days 0–5; B runs days 5–8; C runs days 5–12; D cannot start until both B and C are done, so D runs days 12–14. Project completion = day 14. Backward pass: D finishes at day 14, starts day 12. C must finish by day 12, so LF=12, LS=5. B must also finish by day 12, but it only takes 3 days, so LF=12, LS=9. Total Float for A = 0, for C = 0, for D = 0 — these are critical. Total Float for B = 9 − 5 = 4 days. Critical path: A → C → D. B has 4 days of float; if B slips by less than that, the project still finishes on day 14. CPM is the foundation of almost all schedule management. Once the critical path is known, the project manager knows where to focus attention, where to resource-load, and where delay is genuinely consequential. It also enables compression analysis: if the project end date needs to be brought forward, crashing (adding resources to critical activities to shorten their duration, usually at increased cost) or fast-tracking (overlapping activities that were planned sequentially, usually at increased risk) are the levers available. The choice between them depends on the cost-time tradeoff and the team's tolerance for rework. Understanding CPM is a baseline competency for any planner or scheduler — and a recurring weak spot on UK programmes that adopt agile delivery practices without preserving the underlying network logic. The most important thing to understand about CPM is that the critical path is dynamic — it changes as the project progresses and as actual durations deviate from the plan. A path that starts with two weeks of float can become critical if work on it slips. Planners should monitor near-critical paths (those with small amounts of float, often 5–10 days on infrastructure programmes) just as carefully as the nominal critical path. Also be aware that in a risk-modelled schedule, the 'most critical' path in a probabilistic sense may differ from the deterministic critical path — which is why criticality index from a Monte Carlo run is a more useful indicator than deterministic float alone. A path with high criticality index (the percentage of Monte Carlo iterations in which that path drives completion) deserves attention even if it currently shows non-zero float on the deterministic schedule. CPM has well-known limitations. The first is that activity durations are treated as point estimates, when in reality they are uncertain — which is why Schedule Risk Analysis layers three-point estimates and Monte Carlo simulation on top of the deterministic CPM network. The second is that CPM assumes resources are unlimited; in practice a schedule that respects logic but ignores resource availability is not executable, which is why resource-loaded scheduling and the Critical Chain Method (CCM) were developed as extensions. The third is the DCMA 14 issue that critical paths running through float — meaning the path the team thinks is critical is not actually the path that drives completion — are a recurring red flag on programmes that have been re-baselined repeatedly without testing the logic. A controls function that can confidently identify the live critical path, explain why it is critical, and articulate what would change it is doing CPM well. One that needs to refer the question back to the planning office is not. ### Frequently asked questions **How is the critical path calculated?** The critical path is calculated through two passes across the activity network. The forward pass calculates Early Start and Early Finish for each activity, walking from the project start: each activity's ES equals the maximum EF of all its predecessors, and EF = ES + duration. The backward pass calculates Late Start and Late Finish, walking from the project end backwards: each activity's LF equals the minimum LS of all its successors, and LS = LF − duration. Activities where Total Float (LS − ES) equals zero are critical; the chain of zero-float activities from start to end is the critical path. **What is total float on the critical path?** Total float on the critical path is zero. That is the defining property — if any activity on the path could slip without delaying the project end, it would not be on the critical path. In practice, many software tools report a small non-zero float on the 'critical' path (e.g. one or two days) due to calendar arithmetic, constraints, or rounding; the DCMA 14-point assessment treats activities with float of 7 working days or less as critical for monitoring purposes. **Can a project have more than one critical path?** Yes. A project has more than one critical path when two or more paths through the network have the same total duration and that duration equals the project completion date. This is most common on programmes with parallel workstreams that converge late in the schedule. Having multiple critical paths means there is no slack in any of them — any of the paths slipping will delay the project — and is a recognised risk amplifier on infrastructure programmes. Merge bias (the statistical phenomenon that the probability of all parallel paths completing on time is lower than the probability of any single one) makes this materially worse than the deterministic view suggests. **What is the difference between the critical path and the longest path?** On a simple network the critical path and the longest path are the same: the sequence of activities with the greatest total duration. They diverge when the schedule contains hard constraints (e.g. a 'must finish on' date), resource levelling, or external dependencies that artificially limit other paths. In those cases the longest path remains the longest sequence by duration, but the critical path becomes the path with zero total float — which may be a different sequence. Most major scheduling tools report both: Primavera P6 in particular distinguishes 'longest path' from 'critical' as separate filter options precisely because they can differ on constrained or resource-levelled schedules. **How does CPM relate to the DCMA 14-point assessment?** The DCMA 14-point assessment is a schedule quality check used on US defence contracts and increasingly on UK infrastructure and defence programmes. Several of its metrics test CPM directly: the Critical Path test ensures the schedule has a contiguous critical path from start to finish (no broken logic); the Critical Path Length Index (CPLI) compares the time available to the time needed on the critical path; and the High Float, Negative Float and Hard Constraint tests catch common ways the critical-path calculation gets corrupted in practice. A schedule that fails the CPM-related DCMA tests is one whose critical path cannot be trusted as a management signal. --- ## Schedule Risk Analysis (SRA) URL: https://www.somaprojectcontrols.com/resources/glossary/schedule-risk-analysis A probabilistic analysis that models uncertainty in activity durations and discrete schedule risks to produce a range of possible project completion dates. Schedule Risk Analysis (SRA) takes a deterministic programme and adds uncertainty to it. Rather than assuming each activity will take exactly its planned duration, an SRA assigns a three-point estimate (minimum, most likely, maximum) to each activity. It then applies discrete risk events — specific risks from the risk register that, if they occur, would add time to the programme — and runs a Monte Carlo simulation across thousands of iterations. The output is a probability distribution of project completion dates, typically displayed as an S-curve. SRA is most commonly used to assess the confidence level of a target completion date. If the P50 completion date from the SRA is significantly later than the baseline programme, this tells the team that the baseline is optimistic and that contingency time needs to be added. SRA is also used to identify the activities and risks that most influence schedule outcome — the sensitivity analysis — so that the team can prioritise mitigation effort. On publicly funded infrastructure projects and defence contracts, SRA is frequently a requirement at stage gate reviews. One of the most important and underappreciated outputs of an SRA is the gap between the deterministic end date and the P50 from the simulation. This gap exists even before any risks are switched on, because it reflects the effect of duration uncertainty and merge bias on the schedule network. If this gap is large, it usually signals that the schedule has too many parallel near-critical paths converging on the end milestone. A common mistake is running an SRA on a schedule that has not passed a basic quality check: poor logic, open ends, and excessive constraints will produce meaningless probabilistic output. ### Frequently asked questions **What is schedule risk analysis?** Schedule Risk Analysis (SRA) is a probabilistic assessment of a project programme that models uncertainty in activity durations and discrete schedule risks. Rather than producing a single deterministic completion date, SRA runs a Monte Carlo simulation to generate a range of possible completion dates with associated probabilities — for example, a P50 date (50% confidence) and a P80 date (80% confidence). The gap between the baseline programme completion date and the P50 SRA date is the schedule confidence gap, which informs how much contingency time the programme needs. **What is the difference between SRA and a risk register?** A risk register identifies and qualitatively scores risks; an SRA quantifies their schedule impact. The risk register feeds the SRA: each risk event that could delay the programme is modelled with a probability of occurrence and a range of delay impact. The SRA also models duration uncertainty on individual activities independently of the discrete risk events. Together, the SRA tells you what the risk register costs in schedule terms — the register alone cannot do this. **What does a P80 date mean in a schedule risk analysis?** The P80 date is the completion date at the 80th percentile of the Monte Carlo output distribution — there is an 80% probability the project will complete by that date and a 20% probability it will run later. Many UK government frameworks and client organisations require SRA results to show the P50 and P80 dates, with funding allocated to at least P80 confidence. Programmes where the baseline completion date sits below the P50 SRA date are, by definition, more likely to overrun than not. **What software is used for schedule risk analysis?** The most widely used tools on UK infrastructure and defence programmes are Primavera Risk Analysis (formerly Pertmaster) for native P6 schedule integration, and Oracle Crystal Ball or Palisade @RISK for spreadsheet-based cost and schedule models. ARM (Active Risk Manager) is also used for integrated risk modelling. All tools use Monte Carlo simulation as the core engine; the differences are in how they handle schedule logic, correlation modelling, and output reporting. --- ## Cost Risk Analysis (CRA) URL: https://www.somaprojectcontrols.com/resources/glossary/cost-risk-analysis A probabilistic assessment of project cost that models uncertainty in estimates and discrete cost risks to produce a range of possible outturn costs. Cost Risk Analysis (CRA) does for the cost estimate what Schedule Risk Analysis does for the programme. It takes the deterministic cost estimate — the line-by-line breakdown of expected expenditure — and overlays uncertainty. Each cost element is given a range (typically a three-point estimate) reflecting the degree of confidence in that estimate, and discrete risk events from the risk register are modelled as probabilistic cost impacts. A Monte Carlo simulation then produces a full probability distribution of possible outturn costs. CRA is used to establish how much contingency the project needs and to test whether the approved budget is sufficient. The P50 from a CRA represents the expected outturn cost — the amount you would expect to spend on average. The P80 is typically used to set the contingency budget, representing the amount that gives an 80% probability of staying within budget. The gap between the deterministic base estimate and the P50 is often referred to as 'the expected risk exposure' and reflects the anticipated impact of risks that are likely but not certain to occur. A well-structured CRA distinguishes between aleatory uncertainty (inherent variability in quantities and rates that cannot be eliminated by better information) and epistemic uncertainty (gaps in knowledge that could be reduced by further design development). At early project stages, epistemic uncertainty dominates and the cost range will be very wide. As the design matures, the range should narrow — if it does not, this is a signal that design development is not reducing risk as expected. Avoid the trap of using CRA outputs to justify a predetermined budget: if the analysis shows the P80 exceeds the approved funding, that is information to act on, not to suppress. --- ## Risk Register URL: https://www.somaprojectcontrols.com/resources/glossary/risk-register A structured log of identified project risks, recording what could go wrong, how likely it is, what the impact would be, and what is being done about it. A risk register is the central document for managing project risk. At its simplest it is a table: each row is a risk, and the columns record the risk description, the cause, the potential impact (on cost, time, or quality), the probability of occurrence, the severity of impact, and the current mitigation actions and owners. Most registers also include a risk score — probability multiplied by impact — and a residual risk score after mitigations are applied. On projects using quantitative risk analysis, each risk entry will also have quantified cost and schedule impact ranges that feed into the Monte Carlo model. A risk register is a live document, not a one-off deliverable. It should be reviewed regularly — typically at every project board or risk workshop — and updated as risks are realised, mitigated, or new ones emerge. It is the mechanism by which the project team demonstrates that risk is being actively managed rather than just identified and filed. A risk register that has not been updated in months is a governance failure, regardless of how good the original entries were. The most common problems with risk registers are vagueness and completeness bias. Vague risks — 'design may be delayed', 'stakeholder issues' — cannot be properly assessed or mitigated, because nobody knows exactly what the risk is or who owns it. Force each risk to be written as a cause-risk-effect statement: 'because X, Y might happen, resulting in Z.' Completeness bias means the register typically captures the obvious risks but misses the less obvious ones that cause the biggest problems. Use structured techniques — prompt lists, risk workshops with diverse participants, lessons learned from previous projects — to surface risks that a single planner sitting at a desk would miss. ### Frequently asked questions **What should a risk register include?** A risk register should capture, for each risk: a unique identifier; a clear description of the risk event (cause → event → effect); probability of occurrence; impact on cost, schedule, and scope; a risk score; the risk owner; current mitigation actions; and the residual (post-mitigation) probability and impact. For a register that feeds into quantitative risk analysis, it also needs three-point estimates of cost and schedule impact (minimum, most likely, maximum) rather than single-point scores. **What is the difference between a risk register and a risk log?** The terms are used interchangeably in most organisations, but in formal project controls a risk log typically refers to a simple list of identified risks without the full scoring and management data that a risk register contains. A risk register is the live management document — it is reviewed regularly, risks are updated as their status changes, and it drives mitigation actions. A log is more of an audit trail. In practice, if it is used to manage risks, it is a risk register regardless of what it is called. **How often should a risk register be updated?** On active projects, the risk register should be formally reviewed at least monthly — more frequently during high-risk phases such as procurement, mobilisation, or transition. Between formal reviews, risk owners should update their risks as new information becomes available. The register should be reviewed and baselined ahead of any stage gate, funding submission, or quantitative risk analysis, since a stale register will produce misleading QRA results. **What makes a risk register 'QRA-ready'?** A QRA-ready risk register has: a clear event description for each risk (not vague labels like 'design risk'); probability of occurrence as a single percentage or range; cost impact as a three-point estimate (minimum, most likely, maximum) in £; schedule impact as a three-point estimate in days or weeks; an identified risk owner; and no double-counting of risks already included in the base cost estimate. Risks priced into the base estimate should be removed from the register before the QRA, or the analysis will overstate contingency. --- ## Three-Point Estimate URL: https://www.somaprojectcontrols.com/resources/glossary/three-point-estimate An estimating technique that captures optimistic, most likely, and pessimistic values for a cost or duration, rather than committing to a single figure. A three-point estimate replaces a single deterministic value with three: the optimistic value (O), the most likely value (M), and the pessimistic value (P). These three values define a range that reflects the estimator's genuine uncertainty about the outcome. They are the fundamental inputs to Monte Carlo simulation — every activity duration in an SRA and every cost element in a CRA is expressed as a three-point estimate. The simplest way to combine them into a single representative value is the PERT formula: (O + 4M + P) / 6, which gives more weight to the most likely value. Several variants of the weighting formula are in circulation. The classical PERT formula (O + 4M + P) / 6 derives from the beta distribution and is the version cited in the Project Management Body of Knowledge. A simpler weighted variant — (O + 3M + P) / 5 — appears in some UK training materials and procurement guidance, and gives slightly less weight to the most likely value (60% vs 67%). Triangular weighting (O + M + P) / 3 gives equal weight to all three points and is rarely used in cost or schedule risk analysis because it ignores the empirical evidence that real activity durations cluster around the most likely value rather than the simple mean. Which formula you use matters less than people often assume: when the inputs are well-calibrated and a Monte Carlo simulation is run over the full distribution, the choice of point-estimate formula is an intermediate artefact, not the headline output. Three-point estimates are important because they force estimators to acknowledge and quantify uncertainty rather than committing prematurely to a false precision. A single-point estimate of 10 weeks says nothing about whether that could be 8 weeks or 14 weeks. A three-point estimate of 8 / 10 / 16 weeks tells a very different story — one where the upside is modest but the downside is significant. This asymmetry is typical of real project estimates and is invisible if only the most likely value is reported. The hardest part of three-point estimating is getting calibrated inputs. People are naturally bad at estimating probability ranges — we tend to anchor on the most likely value and set the extremes too close to it, producing ranges that are too narrow. This is especially common under schedule or commercial pressure. A practical test: ask the estimator whether they genuinely believe there is only a 5–10% chance of the actual value falling outside their stated range. If the answer is no, the range needs to be wider. For critical activities or cost elements, independent review or comparison against historical data is the best check. ### Frequently asked questions **What is a three-point estimate?** A three-point estimate replaces a single deterministic duration or cost figure with three values: optimistic (O — the best plausible case), most likely (M — the mode), and pessimistic (P — the worst plausible case). These three values define a probability distribution for the uncertain quantity. Three-point estimates are the primary inputs to Monte Carlo simulations in schedule and cost risk analysis, and they allow a model to represent the asymmetric uncertainty that is typical in project estimating — most activities can overrun by more than they can underrun. **What is the formula for a three-point estimate?** Two formulas are in common use. The PERT (beta distribution) formula gives a weighted mean: (O + 4M + P) ÷ 6, which weights the most likely value four times. The triangular distribution formula gives an unweighted mean: (O + M + P) ÷ 3. PERT is the traditional formula used in programme scheduling; the triangular distribution is more common in cost risk models and is the default in tools like @RISK and Crystal Ball. The PERT formula produces a narrower range than the triangular and is generally considered to understate uncertainty on complex projects. **What is the difference between PERT and triangular distribution in three-point estimates?** Both use the same three input values (O, M, P) but weight them differently. The PERT beta distribution concentrates probability around the most likely value, producing a smooth bell-shaped curve and an expected value of (O + 4M + P) ÷ 6. The triangular distribution gives equal weight to all three inputs and produces a triangular probability density function with an expected value of (O + M + P) ÷ 3. In practice, the triangular distribution is preferred for cost risk because it better reflects the fat tails observed in actual cost overruns; PERT remains standard in many scheduling tools. **How should you calibrate three-point estimates?** The most common calibration failure is anchoring — estimators set the pessimistic value only slightly above the most likely, producing falsely narrow distributions. Good calibration asks: what would a realistic worst case look like if everything that could go wrong did? Reference class data (historical outturn distributions for similar activities) should be used to sense-check the range. A useful heuristic: for construction activities, the P − O range should typically be at least 30–50% of the most likely value on a complex project. Calibration workshops with independent facilitation consistently produce better-calibrated estimates than individuals working alone. --- ## Expected Monetary Value (EMV) URL: https://www.somaprojectcontrols.com/resources/glossary/expected-monetary-value The probability-weighted average cost or benefit of a risk event, calculated by multiplying the probability of occurrence by the financial impact. Expected Monetary Value (EMV) is the simplest way to put a number on a risk. If there is a 30% chance that a ground investigation will reveal contamination costing £500,000 to remediate, the EMV of that risk is 0.30 × £500,000 = £150,000. This is not a prediction that the remediation will cost £150,000 — it will either cost £500,000 or nothing — but it is the statistically fair amount to set aside across a large number of similar risks. EMV is the building block of expected value reasoning in project risk management. EMV is used in several ways in project controls. In a risk register, it provides a consistent basis for comparing and prioritising risks — a risk with a high probability and low impact might have the same EMV as one with a low probability and high impact, and both deserve similar attention. In a cost risk analysis, the sum of EMVs for all identified risks gives a rough estimate of the total expected risk exposure — though this approach ignores correlation and does not capture the full shape of the distribution the way a Monte Carlo simulation does. The main limitation of EMV is that it treats all outcomes as fungible. A risk with a 1% probability of costing £10 million has the same EMV as one with a 100% probability of costing £100,000 — but the first could be existential for a small project while the second is a minor budget adjustment. EMV should always be read alongside the maximum possible impact, not just the expected value. Also be aware that EMV requires a good probability estimate, and on novel or unique projects, those probabilities are themselves highly uncertain. Use EMV as one input to decision-making, not as a definitive answer. --- ## Optimism Bias URL: https://www.somaprojectcontrols.com/resources/glossary/optimism-bias The well-documented human tendency to underestimate the cost and duration of projects, particularly in the early stages. Optimism bias is not carelessness or dishonesty — it is a cognitive bias that affects even experienced, well-intentioned professionals. Studies by Flyvbjerg and others consistently show that large infrastructure projects overrun their original budgets by an average of 45% and their schedules by significant margins. The pattern is so consistent that it has been built into UK government appraisal guidance (HM Treasury Green Book) through a formal technique called Optimism Bias Uplift (OBU), which adds a percentage to cost estimates at early project stages to account for the fact that the estimate is almost certainly too low. In project controls practice, recognising optimism bias is essential when reviewing early-stage estimates and programmes. The question to ask is not 'is this estimate correct?' but 'what systematic factors might be causing us to underestimate?' Scope growth, interface risks, ground conditions, procurement delays, and regulatory requirements are consistently underestimated at early project stages. Reference class forecasting — looking at what similar projects actually cost and took — is a powerful counter to optimism bias because it bypasses the team's own (inevitably optimistic) judgement. Optimism bias is also embedded in three-point estimates. When estimators set their pessimistic value, they tend to anchor on their most likely value and not move far enough into genuinely pessimistic territory. The result is that Monte Carlo simulations, which rely on those inputs, also produce optimistically narrow output distributions. If a QRA consistently shows P80 estimates that are barely different from the deterministic estimate, the three-point inputs are probably too narrow. Challenging the inputs — particularly the pessimistic values — is one of the most valuable things a project controls professional can do. ### Frequently asked questions **What is optimism bias in project management?** Optimism bias is the systematic tendency for project teams to underestimate costs and durations and overestimate benefits at the time of appraisal. It is not a matter of dishonesty — it is a cognitive bias that causes people to believe their project will go better than the historical average for similar projects. In UK capital projects, HM Treasury's Green Book requires an explicit Optimism Bias Uplift (OBU) to be applied to cost and time estimates at project appraisal to correct for this tendency, particularly at early stages when uncertainty is highest. **How is optimism bias corrected in UK government projects?** The primary correction method is the Optimism Bias Uplift (OBU), a percentage added to the base cost and time estimate. HM Treasury's Green Book provides upper-bound uplift values by project type (e.g. 66% for non-standard civil engineering, 44% for standard civil engineering). These are reduced as the project matures and uncertainty is resolved through design development and risk quantification. The Infrastructure and Projects Authority (IPA) Cost Estimating Guidance builds on this with reference class forecasting — using the actual outturn distribution of comparable past projects to set a statistically grounded uplift. **What is reference class forecasting and how does it address optimism bias?** Reference class forecasting (RCF), developed by Bent Flyvbjerg, addresses optimism bias by taking an 'outside view' — rather than building up a project estimate from scratch (which is susceptible to optimism), RCF asks: what was the outturn distribution for a reference class of similar projects? The project's forecast is then anchored to the statistical distribution of that reference class, adjusted for project-specific factors. UK government guidance explicitly endorses RCF as the preferred approach for major infrastructure appraisals, and it is now embedded in the IPA and Treasury guidance frameworks. **What is the difference between optimism bias and strategic misrepresentation?** Optimism bias is a cognitive error — the team genuinely believes the project will perform better than the evidence suggests. Strategic misrepresentation is deliberate: costs are knowingly understated or benefits overstated to win funding approval. Both produce the same outcome (projects approved on an unrealistic business case), but optimism bias responds to calibration and process improvements, while strategic misrepresentation requires governance and incentive changes. In practice, the two often coexist on major programmes where career incentives reward getting a project approved regardless of forecast accuracy. --- ## Work Breakdown Structure (WBS) URL: https://www.somaprojectcontrols.com/resources/glossary/work-breakdown-structure A hierarchical decomposition of all the work required to deliver a project, organised into manageable sections that can be planned, costed, and controlled. A Work Breakdown Structure (WBS) is the backbone of project planning and cost management. It breaks the total project scope into progressively smaller chunks — typically from major deliverables at the top level, through packages or disciplines at intermediate levels, down to individual work packages or activities at the lowest level. Crucially, the WBS is deliverable-focused, not activity-focused: each element represents a piece of scope (a thing to be produced or installed) rather than an action. The lowest level of a WBS is called a work package — the unit of work that can be assigned, scheduled, and costed. The WBS is important because almost everything else in project controls depends on it. The cost estimate, the schedule, the risk register, the earned value baseline — all are structured around the WBS. A well-designed WBS ensures that costs and activities can be traced back to specific deliverables, that nothing is missed (the WBS should be 100% complete, meaning every element of scope is represented), and that nothing is double-counted. Without a sound WBS, it is impossible to integrate cost and schedule data meaningfully. Common mistakes include confusing WBS elements with activities ('design' is an activity, 'design specification document' is a deliverable), building a WBS around the organisational structure rather than the project deliverables (an org chart and a WBS are not the same thing), and using inconsistent levels of decomposition — very detailed in some areas and very high-level in others, which makes cost and performance reporting unreliable. The WBS dictionary — a document describing the content of each WBS element — is often skipped but is essential for ensuring that everyone agrees on what each element includes and excludes. --- ## Baseline Schedule URL: https://www.somaprojectcontrols.com/resources/glossary/baseline-schedule The formally approved version of the project schedule, against which actual progress and performance are measured throughout the project. A baseline schedule is a snapshot of the project programme at the point where it has been agreed, reviewed, and formally approved. From that point forward, it becomes the reference point for all performance reporting. Actual start and finish dates, earned value, float, and forecast completion dates are all measured against the baseline. The baseline should not be changed except through a formal change control process — if it is updated casually whenever the project falls behind, it ceases to be a meaningful reference and performance reporting becomes worthless. Establishing a good baseline is one of the most important activities in the early stages of a project. The baseline should reflect a schedule that has been resource-loaded, risk-checked, and logic-verified. A baseline that is set too early — before scope is sufficiently defined — will almost certainly require re-baselining, which wastes time and undermines confidence in the project controls function. Equally, a baseline that takes too long to set is also a problem because the project is then running for months without a performance reference. The most common governance failure around baselines is re-baselining without proper scrutiny. When a project falls behind, there is often pressure to re-baseline the schedule to make the variances disappear rather than to understand and address the underlying performance issues. Good practice is to keep the original baseline intact and show it alongside the current plan and actual progress, so that the full history of slippage is visible. A project that has been re-baselined multiple times should raise a red flag for any reviewer looking at programme performance. --- ## Float (Total Float and Free Float) URL: https://www.somaprojectcontrols.com/resources/glossary/float The amount of time an activity can be delayed without pushing back the project end date (total float) or its immediate successor (free float). Float — sometimes called slack — is the scheduling concept that tells you how much flexibility exists around an activity. Total float is the amount of time an activity can slip before it delays the project end date (or a key contractual milestone). Free float is the smaller number: how much the activity can slip before it delays its immediate successor. An activity on the critical path has zero total float — any delay to it directly delays the project. Activities with plenty of float are the ones you can deprioritise when resources are scarce. Float is a key input to resource management, risk assessment, and schedule compression decisions. When reviewing a schedule, negative float (where activities would need to start in the past to meet the end date) is a clear sign that the programme is unrealistic and needs either compression or a revised end date. Near-critical paths — those with small positive float — are important to monitor because they can easily become critical as the project progresses. In a risk-modelled schedule, the criticality index (the proportion of Monte Carlo iterations in which an activity appears on the critical path) is more informative than deterministic float alone. Float ownership can be a source of commercial tension on contracts, particularly where the contractor and client both believe they have a right to use available float. NEC and other standard form contracts have specific provisions on this. A practical rule of thumb: total float belongs to the project, not to any individual activity owner. Managing float as a shared resource — and being transparent about how near-critical paths are trending — is part of good programme governance. Be wary of schedules where all activities show the same float: this is usually a sign that constraints have been applied to force dates rather than that the logic actually supports them. --- ## S-Curve URL: https://www.somaprojectcontrols.com/resources/glossary/s-curve A cumulative cost or progress curve that typically forms an S-shape over the project lifecycle, starting slowly, accelerating through execution, then tapering at handover. An S-curve is a graph of cumulative value against time — most commonly showing planned expenditure, actual expenditure, and earned value on a single chart. The characteristic S-shape reflects the natural rhythm of a project: slow at the start when mobilisation, design, and procurement are underway; steep through the main construction or delivery phase when the bulk of work and spend occurs; then tapering as the project completes snagging, commissioning, and handover activities. Any significant deviation from the planned S-curve is a signal worth investigating. S-curves are used in EVM reporting to give a visual summary of project performance that is easy for non-specialists to read. The gap between the planned value (PV) curve and the earned value (EV) curve shows schedule performance — if EV is below PV, the project is behind plan. The gap between the earned value (EV) curve and the actual cost (AC) curve shows cost performance — if AC is above EV, the project is spending more than the work done justifies. An S-curve is also used to show the probabilistic range of outcomes from a Monte Carlo simulation, where the fanned-out envelope of curves at the right-hand end shows the range of possible completion dates. S-curves are easy to manipulate if the underlying data is not robust. If earned value is overstated (progress claimed but not physically achieved), the EV curve will sit artificially above the AC curve and will not reflect the true performance of the project. The classic symptom is an EV curve that tracks closely below the PV line for months and then suddenly drops sharply — an indication that someone has been making the numbers look good rather than reporting honestly. Independently verifying earned value claims through physical inspection or defined milestone completion is the best check against this. ### Frequently asked questions **What is an S-curve in project management?** An S-curve is a cumulative graph that shows how a project variable (typically cost or resources) accumulates over time. It takes its characteristic S shape because projects are slow to mobilise, then accelerate through peak delivery, then taper as work completes. In project controls, three S-curves are typically plotted together: the Planned Value (PV — the baseline plan), the Earned Value (EV — the budgeted cost of work completed), and the Actual Cost (AC — money actually spent). The gaps between these three curves tell the performance story of the project. **Why does a project S-curve have an S shape?** The S shape reflects the natural lifecycle of project expenditure: slow ramp-up during mobilisation and early design, rapid increase during peak construction or delivery, then a tail-off as snagging, commissioning, and close-out proceed. The inflection point — where the cumulative spend rate is at its maximum — typically falls somewhere between 40% and 70% through the project timeline depending on the project type. Projects with very long mobilisation phases (e.g. large infrastructure) have a flatter lower portion of the S; those that go straight into construction have a steeper initial curve. **What does it mean when actual cost runs above the planned S-curve?** When the Actual Cost (AC) S-curve sits above the Planned Value (PV) S-curve, the project is spending faster than planned. This can mean two very different things: if Earned Value (EV) is tracking close to AC, the team is ahead of schedule and spending is justified by faster-than-planned progress. But if EV is below PV while AC is above it, the project is both behind schedule and over budget — a cost overrun without the compensating benefit of faster completion. Always read AC and EV together, not AC in isolation. **How is an S-curve used in earned value management?** In EVM, the S-curve is the standard output format for displaying the three core metrics: PV (the baseline plan), EV (physical progress valued at planned rates), and AC (actual spend). Schedule Variance = EV − PV (shown as the horizontal gap between EV and PV at a given date), and Cost Variance = EV − AC (the vertical gap between EV and AC). A project performing to plan has all three curves tracking closely together. Divergence between the curves is the earliest visual signal of performance problems — often visible on the S-curve before it shows up in other reporting. --- ## Earned Value (EV) vs Planned Value (PV) URL: https://www.somaprojectcontrols.com/resources/glossary/earned-value-ev-vs-planned-value-pv EV is the budgeted value of work actually completed; PV is the budgeted value of work that was planned to be complete by now — the gap between them measures schedule performance. In Earned Value Management, Planned Value (PV) — sometimes called the Budgeted Cost of Work Scheduled (BCWS) — is the cumulative budget for all the work that was supposed to have been completed by a given reporting date, as established in the performance measurement baseline. Earned Value (EV) — also called Budgeted Cost of Work Performed (BCWP) — is the cumulative budget for the work that has actually been completed, regardless of what it cost. Comparing EV to PV gives the Schedule Variance (SV = EV − PV): a negative number means the project is behind schedule. The Schedule Performance Index (SPI = EV / PV) puts this into ratio form: an SPI below 1.0 means work is being earned more slowly than planned. Both SV and SPI are expressed in cost (£) rather than time, which is counterintuitive but allows them to be calculated consistently across a complex programme where different workstreams have different unit costs. This also means that SPI converges to 1.0 at project completion regardless of actual schedule performance — a known limitation of classical EVM that earned schedule theory was developed to address. The most important thing to understand about EV vs PV is that EV measures the value of work done, not the value of time elapsed. If a task is half done and was planned to be fully done by now, EV is 50% of the budget for that task, not 100%. This distinction is what makes EVM meaningful: it prevents projects from appearing on track simply because time has passed and money has been spent, when in reality the scope has not been delivered. Ensuring that EV is calculated on the basis of genuine completion — not subjective 'percent complete' claims — is the critical governance issue in any EVM implementation. --- ## Risk Appetite vs Risk Tolerance URL: https://www.somaprojectcontrols.com/resources/glossary/risk-appetite-vs-risk-tolerance Risk appetite is how much risk an organisation is willing to seek out; risk tolerance is the maximum level of risk it can absorb before it must act. Risk appetite and risk tolerance are related but distinct concepts that define an organisation's posture towards risk. Risk appetite is a strategic statement: the broad amount and type of risk that the organisation is willing to accept in pursuit of its objectives. It is often expressed qualitatively — 'we have a low appetite for safety risk but a higher appetite for innovation risk' — or through approved confidence level thresholds for project delivery. Risk tolerance is more operational: the specific maximum level of risk exposure that the organisation can absorb before it must take action to reduce it. Think of appetite as the speed limit and tolerance as the point at which the speedometer triggers an alarm. In project controls practice, risk appetite and tolerance manifest most clearly in decisions about contingency and target completion dates. An organisation with a low risk appetite for cost overrun will fund projects to P80 or P85; one with higher appetite might accept a P50 funding level. Risk tolerance drives the escalation process: if an individual project risk exceeds a defined financial threshold, it must be escalated to the sponsor or board. These thresholds are most effective when they are set explicitly at the start of the project rather than applied retrospectively. The most common problem is that risk appetite and tolerance are either undefined or defined but not used. Risk appetite statements in governance frameworks often sit in a document that is reviewed annually and otherwise ignored. To be useful, appetite and tolerance need to be translated into specific decision rules: at what probability-weighted cost does a risk get escalated? What confidence level must the cost estimate achieve before the project can be approved for execution? Connecting the risk framework to these practical decisions is what makes it live rather than decorative. ### Frequently asked questions **What is the difference between risk appetite and risk tolerance?** Risk appetite is how much risk the organisation is willing to seek out in pursuit of its objectives — a strategic posture set by the board. Risk tolerance is the maximum level of risk exposure the organisation can absorb before it must take action — an operational threshold applied per risk or per project. Think of appetite as the speed limit and tolerance as the point at which the speedometer triggers an alarm. **Which is set first, risk appetite or risk tolerance?** Risk appetite comes first. It is a strategic statement set by the board or executive that defines the organisation's broad posture towards risk. Risk tolerances are then set within the appetite — operational thresholds for specific risk categories or projects that translate the strategic posture into decision rules. **How does risk appetite translate into project controls decisions?** Most directly via the target confidence level for funding submissions. An organisation with low appetite for cost overrun will fund to P80 or P85; one with higher appetite might accept P50. Appetite also drives delegation rules — what level of risk can be accepted at project level versus escalated to portfolio or board. **Is risk tolerance the same as risk threshold?** Effectively yes. ISO 31000 uses the term "risk criteria" for the thresholds that distinguish acceptable from unacceptable risk levels — in practice these are commonly called risk tolerances or risk thresholds. They are the trigger points for escalation, mitigation, or contingency drawdown. **Why do organisations get the appetite-tolerance distinction wrong?** Because appetite is typically set in a governance document that nobody references during day-to-day decisions, while tolerances are set ad hoc by individual project managers. The fix is to make the appetite statement live — translate it into specific decision rules (confidence levels, EMV thresholds, escalation triggers) and test it against actual decisions in post-implementation reviews. --- ## Contingency vs Management Reserve URL: https://www.somaprojectcontrols.com/resources/glossary/contingency-vs-management-reserve Contingency covers known unknowns inside the project budget; management reserve covers unknown unknowns above it. A practitioner guide to the difference, who controls each, how drawdown works, and why conflating them obscures real performance. Contingency and management reserve are both budget held above the base estimate, but they cover different types of uncertainty and are controlled differently. Contingency — sometimes called risk allowance or risk provision — is calculated from the quantified risk analysis. It covers the expected cost of identified risks that are likely but not certain to occur, and is typically sized at the difference between the P50 (or P80, depending on policy) and the base estimate. It is part of the project budget, owned by the project manager, and drawn down through the risk management process as risks are realised or their status changes. Management reserve, by contrast, covers genuinely unforeseen scope changes — the unknown unknowns that no risk analysis could have captured. It is held above the project budget by the sponsor or client organisation and is released only by formal change control. The distinction matters for governance and accountability. A project manager can use contingency without a formal change request because it is already within their delegated budget — but they should still track which risks triggered the drawdown. Management reserve requires sponsor approval because it represents a change to the approved project budget. Conflating the two — raiding management reserve to cover overspend caused by poor risk management — is a governance failure that obscures the true performance of the project. In practice, the boundary between contingency and management reserve is not always clean, particularly at early project stages when scope is still developing. Some organisations define a third tier — design development allowance (DDA) — to cover cost growth from design development between RIBA stages, which is distinct from risk contingency. The key principle is that every pound of budget held above the base estimate should have a clear definition of what it is for, who controls it, and what process governs its use. Without this, contingency becomes a slush fund that absorbs overruns without generating insight about what is going wrong. ### Frequently asked questions **What is the difference between contingency and management reserve?** Contingency is held inside the project budget to cover known, quantified risks (known unknowns) and is owned by the project manager. Management reserve is held above the project budget by the sponsor to cover genuinely unforeseen scope changes (unknown unknowns) and requires formal change control to release. Contingency is sized from the QRA — typically the gap between the P50 or P80 cost and the base estimate. Management reserve is set as a policy percentage by the sponsor. **Who controls contingency vs management reserve?** The project manager controls contingency within their delegated budget — they can draw it down without a formal change request, although every drawdown should be tracked back to the risk register. The sponsor or client organisation controls management reserve and must approve its release through formal change control because using it represents a change to the approved project budget. **Are management reserve risks identified?** No. Management reserve covers risks and scope changes that have not been identified — the genuinely unforeseen events that no risk analysis could have captured. If a risk is identifiable and quantifiable enough to be in the risk register, it belongs in contingency, not management reserve. Conflating the two is a governance failure that obscures project performance. **How much contingency vs management reserve should a project hold?** Contingency is calculated, not chosen — it comes out of the quantitative risk analysis. The amount depends on the risks identified, their probabilities and impacts, and the confidence level the sponsor has chosen (P50 vs P80 vs P95). Management reserve is set by sponsor policy and is typically 5-15% of the project budget on UK infrastructure programmes, sized for the residual uncertainty after a thorough risk-identification exercise. Holding less than that on a complex programme suggests either confident scope or under-recognised risk. --- ## Total Float URL: https://www.somaprojectcontrols.com/resources/glossary/total-float How far an activity can slip before it delays the project end date — with how float ownership works on NEC contracts, and why uniform float across a schedule is a red flag. Total float — sometimes called total slack — is calculated from the difference between the latest allowable finish date (from the backward pass through the network) and the earliest possible finish date (from the forward pass). An activity with zero total float is on the critical path; delay it and the project end date moves. An activity with, say, 15 days of total float can slip up to 15 days before it starts affecting the project completion date. Total float is a property of a chain of activities, not of a single task in isolation — using float on one activity in a chain reduces the float available to every downstream activity on the same path. Total float is one of the most important indicators a planner or project controls engineer works with. It tells you where the real risks to the programme are, where you can afford to deprioritise resources when they are under pressure, and where a delay is consequential. On a busy project with multiple competing demands, float is a resource that needs managing just like labour or equipment. If you allow float to drain away on near-critical paths without noticing, you wake up one day with several paths simultaneously critical and no good options left. Two practical cautions. First, total float belongs to the project, not to any individual activity or subcontractor. A contractor who treats the float on their activities as private scheduling headroom is consuming a project resource they do not own. NEC contracts address this explicitly through the float allocation provisions and the Accepted Programme process. Second, schedules where most activities show the same float value — for example, every task shows exactly 10 days — are usually constrained rather than logic-driven: someone has applied a target date and allowed the tool to back-calculate the appearance of float rather than letting the logic run. Treat that kind of uniformity with suspicion. --- ## Free Float URL: https://www.somaprojectcontrols.com/resources/glossary/free-float The amount of time an activity can be delayed without delaying the early start of any of its immediate successors. Free float is always less than or equal to total float. Where total float measures how much delay can be absorbed before the project end date is affected, free float measures how much delay an activity can absorb before it affects the next activity in the chain. An activity can have large total float but zero free float if it is directly followed by an activity on the critical path: the delay would not reach the project end but it would immediately affect what comes next. In practice, free float appears most visibly on activities that feed into a merge point — a milestone or summary activity where multiple paths converge. Free float matters when you need to manage subcontractor interfaces. If you are handing off from one trade package to another, the free float on the predecessor activity is the amount of slippage the successor can tolerate without being late to start. This has direct commercial relevance on NEC contracts, where a subcontractor delayed by late access from a predecessor has a potential compensation event claim. Free float is also the right metric to use when looking at activities that are not on the critical path but where delay would cause downstream disruption even though the project end date is unaffected. Many scheduling tools display total float prominently and free float only on request, which can give a misleading picture of how much slack actually exists at an interface. Planners reviewing a schedule for handover risk should always check free float at key predecessor-successor boundaries, not just total float on the overall path. A clean-looking Gantt with healthy total float can still have zero free float at critical interfaces, meaning that one slippage cascades immediately through the programme even though the headline float numbers look fine. --- ## Finish-to-Start (FS) Logic URL: https://www.somaprojectcontrols.com/resources/glossary/finish-to-start-fs-logic The most common dependency type: the successor activity cannot start until the predecessor has finished. Finish-to-Start is the default relationship type in most scheduling tools and by far the most common in practice. Activity B cannot start until Activity A finishes. The DCMA 14-point assessment expects more than 90% of all relationships to be Finish-to-Start because overuse of other relationship types — particularly when combined with lags — can make a schedule harder to analyse and more prone to modelling errors. FS relationships drive the classical Critical Path Method calculation: each forward pass step applies a FS relationship to move from the finish of one activity to the start of the next. The prevalence of FS logic does not mean it is always the right choice — it means it should be the default and departures from it should be deliberate and documented. FS relationships combined with lags are sometimes used as a shorthand for more complex overlapping logic that would more honestly be represented by Start-to-Start or Finish-to-Finish relationships. When a reviewer sees a long string of FS relationships with large lags, that is often a sign that the planner has not thought carefully about how the work actually overlaps. On NEC contracts, the logic of the Accepted Programme is scrutinised closely because it drives compensation event assessments. If a programme shows a FS relationship between two activities that in reality are partially overlapping, a delay to the predecessor will be assessed as delaying the successor by the full duration of the predecessor — which may not be what actually happens on site. Getting the relationship type right at the outset is not an academic exercise; it directly affects how compensation events are valued and how float is shared between the parties. --- ## Start-to-Start (SS) Logic URL: https://www.somaprojectcontrols.com/resources/glossary/start-to-start-ss-logic A dependency type where the successor activity cannot start until the predecessor has started — useful for modelling overlapping or concurrent work. Start-to-Start logic is appropriate when two activities must begin before either can finish — for example, a drainage trench that needs to start being backfilled as each section is excavated, or a design review that can begin while the final sections of the design document are still being produced. SS relationships allow planners to model productive overlapping without creating artificial dependencies that add unnecessary duration to the programme. When combined with a lag, SS can represent a situation where the successor must wait a defined period after the predecessor starts — for example, 'piling can start 2 weeks after mobilisation begins'. SS relationships are powerful but require care in analysis. They affect the forward pass calculation differently from FS relationships: the early start of the successor is tied to the early start of the predecessor, not its finish. This means that extending the duration of the predecessor does not necessarily delay the successor's start — which can make the schedule more resilient in some scenarios but can also mask logical dependencies that should be driving dates. A schedule with heavy use of SS logic can be harder to analyse manually and is more prone to producing unexpected critical path results. A common misuse of SS relationships is applying them where a FS relationship with a negative lag (lead) would be more transparent. Using SS + lag is generally cleaner than FS with a negative lag, because it makes the overlapping relationship explicit rather than hiding it in the lag value. In practice, DCMA 14 flags negative lags as non-compliant (leads), so SS + lag is the preferred modelling approach for overlapping work. Always document the rationale for any SS relationship — reviewers will ask, and a well-explained SS relationship is far more defensible than one that appears to have been applied to make a milestone date work. --- ## Finish-to-Finish (FF) Logic URL: https://www.somaprojectcontrols.com/resources/glossary/finish-to-finish-ff-logic A dependency type where the successor activity cannot finish until the predecessor has finished — useful for work that must be completed together. Finish-to-Finish logic ties the completion of one activity to the completion of another. A common example is commissioning and testing: the testing activity cannot finish until all the installation it tests has finished, even if testing started early while installation was underway. FF relationships are also used for contractual milestone dependencies — a delivery milestone that cannot be signed off until all the supporting documentation is complete, regardless of when the documentation work started. On construction schedules, FF is sometimes used to model the relationship between fitting out and snagging: snagging cannot finish until the fitting-out it inspects has finished. FF relationships interact with SS relationships on the same activity pair to create what schedulers call 'SS-FF hammock' logic — a pair of relationships that capture both the start dependency and the end dependency of two overlapping activities. This is the most rigorous way to model partially overlapping work and is preferable to using a single FS relationship with an inflated lag, which hides the true overlap. The SS-FF approach gives the schedule more analytical transparency and produces more reliable float calculations. In practice, FF relationships are less common than FS and SS, and some planners avoid them because they make the schedule harder to read quickly. The cost of that simplicity is accuracy: replacing an FF relationship with a FS + lag is an approximation that will produce incorrect results wherever the predecessor duration varies. If the predecessor activity overruns, the FS + lag model will not correctly capture the knock-on effect on the successor finish. Always use the relationship type that genuinely represents the dependency, even if it makes the Gantt look more complex. --- ## Start-to-Finish (SF) Logic URL: https://www.somaprojectcontrols.com/resources/glossary/start-to-finish-sf-logic The rarest dependency type: the successor activity cannot finish until the predecessor has started — almost always a sign of poor schedule modelling. Start-to-Finish is the least-used relationship type in scheduling for a simple reason: it almost never accurately represents how work is actually sequenced. In an SF relationship, the successor cannot finish until the predecessor starts — meaning the successor is complete before its 'predecessor' in any logical sense. The only genuine use case most practitioners can cite is a just-in-time scenario: a new shift cannot finish (go home) until the replacement shift starts. In nearly all other cases where SF appears in a schedule, it is a modelling error — either the planner has confused the relationship direction, or they have applied SF to achieve a desired date outcome rather than to model a genuine dependency. Because SF relationships are so rarely legitimate, they are a red flag in any schedule review. The DCMA 14-point assessment does not flag SF relationships directly, but any schedule quality review should examine SF relationships in detail. Ask the planner: what is the real-world reason Activity B cannot finish until Activity A starts? In most cases, the answer will reveal that the relationship should actually be FS or SS. SF relationships that cannot be clearly justified should be treated as errors and corrected. The broader point that SF illustrates is that relationship types should always represent physical or contractual realities, not scheduling convenience. When planners use relationship types to force dates — applying SF to ensure an early finish, or using FS + negative lag to accelerate a successor beyond what the logic supports — they are building a schedule that looks right but does not model reality. A schedule that does not model reality cannot be used to forecast it. This is why relationship type audits are a standard part of any serious schedule quality review. --- ## Lag URL: https://www.somaprojectcontrols.com/resources/glossary/lag A positive delay built into a dependency relationship, representing a mandatory waiting period before the successor activity can begin or finish. A lag is an offset applied to a dependency that introduces a deliberate delay. On a Finish-to-Start relationship with a 5-day lag, Activity B cannot start until 5 days after Activity A finishes. Lags represent real constraints: concrete curing times, mandatory hold periods, regulatory review windows, procurement lead times between ordering and delivery, or notification periods in contracts. Used correctly, lags are an efficient way to model these constraints without creating placeholder activities for every waiting period. The alternative — inserting separate 'curing period' or 'review period' activities — produces a bloated schedule that is harder to read and offers no analytical benefit. Lags are one of the most contested items in DCMA 14 schedule reviews. The assessment flags any dependency with a positive lag as a potential concern, and some reviewers apply this mechanically — flagging every lag as a finding regardless of whether it is justified. This is the wrong approach. The question is not whether a lag exists but whether it represents a real constraint and has been correctly quantified. A lag on a concrete pour that reflects the specified curing time in the project specification is entirely legitimate. A lag applied to a Finish-to-Start relationship between design and procurement because the planner did not want to create a separate procurement package is less legitimate and should be reviewed. Negative lags — where the lag value is negative, effectively allowing the successor to start before the predecessor finishes — are called leads and should be avoided. DCMA 14 flags negative lags as non-compliant, and rightly so: a negative lag is almost always a shortcut for an overlapping relationship that should be modelled explicitly with a Start-to-Start relationship and a positive lag. When you encounter negative lags in a schedule, replace them with the equivalent SS + lag structure. The schedule will behave identically and will be analytically cleaner and DCMA-compliant. --- ## Lead URL: https://www.somaprojectcontrols.com/resources/glossary/lead A negative lag that allows a successor activity to begin before its predecessor has finished — generally discouraged and flagged as non-compliant by DCMA 14. A lead is a negative lag value on a dependency relationship. If Activity A has a Finish-to-Start relationship to Activity B with a lag of −5 days, Activity B can start 5 days before Activity A finishes. Planners sometimes use leads to model fast-tracking — compressing the programme by overlapping activities that would normally be sequential. While the underlying concept of starting a successor before its predecessor is complete is entirely valid, modelling it with a negative lag is poor practice. DCMA 14 flags any negative lag as a non-compliant 'lead' and requires it to be resolved before a schedule can be accepted. The reason leads are non-compliant is not that overlapping work is wrong — it is that negative lags are analytically unstable. They interact unpredictably with the critical path calculation, can cause incorrect float values, and make the schedule difficult to analyse and explain. The correct way to model overlapping work is with a Start-to-Start relationship combined with a positive lag where appropriate. An SS + 5-day lag is logically equivalent to a FS − 5-day lead but is analytically clean, DCMA-compliant, and clearly represents what is actually happening: Activity B can start 5 days after Activity A starts. In schedule reviews, the presence of leads (negative lags) is often a sign that a planner has used scheduling tools to achieve a date rather than to model the work. If a critical path calculation shows a late completion, applying negative lags to key predecessors is a tempting — and illegitimate — way to compress the programme without actually changing any of the underlying work sequences or durations. A schedule full of leads should be treated with significant scepticism: the dates it shows are not the product of honest sequencing logic, and they will not materialise on site. --- ## Hard Constraint (Mandatory Constraint) URL: https://www.somaprojectcontrols.com/resources/glossary/hard-constraint-mandatory-constraint An imposed date in a schedule that overrides the calculated logic — the activity must start or finish on, before, or no earlier than a specific date regardless of network dependencies. A hard constraint — also called a mandatory constraint — is a date imposed on an activity that the scheduling tool will honour even if the network logic calculates a different date. Common types include Must Start On, Must Finish On, Start No Earlier Than beyond the data date, and Finish No Later Than. Hard constraints override the forward and backward pass calculations, which means they can mask negative float, create artificial critical paths, and make what-if analysis unreliable. DCMA 14 allows fewer than 5% of activities to have hard constraints, though even that threshold is a guideline rather than an absolute. Hard constraints are legitimate in specific circumstances: contractual completion dates, externally imposed start dates (such as planning permission conditions), interface dates locked in with third parties, and phased handover milestones that have been agreed with the client. These are genuine constraints that the network cannot override — the project must meet them. The problem is when constraints are applied not to reflect external reality but to make the programme look achievable, to force a target date, or to prevent the schedule from calculating negative float that would be difficult to explain. The test for any hard constraint should be: is there a real-world reason this activity must start or finish on this date, and can we document it? If the answer is yes — planning condition, contractual milestone, statutory hold period — the constraint is appropriate. If the answer is 'we applied it because the director wants the project to finish in June,' it is a governance failure dressed as scheduling logic. Reviewers should ask contractors to provide the contractual or technical basis for every hard constraint in a programme. Unjustified constraints should be removed and replaced with the correct finish date on the relevant milestone activity. --- ## Soft Constraint (Preferred Constraint) URL: https://www.somaprojectcontrols.com/resources/glossary/soft-constraint-preferred-constraint A scheduling preference rather than a mandatory date — the tool will try to honour it but will not override the network logic if the calculated date conflicts. Soft constraints — sometimes called preferred constraints or flexible constraints — are dates that the scheduler would like to achieve but which are not overriding the network logic. A typical example is a 'Start No Earlier Than' constraint applied to the project start date, which prevents the schedule from calculating activity starts before mobilisation can begin. Unlike hard constraints, soft constraints allow negative float to show if the network logic cannot satisfy them, which means the schedule remains analytically honest. The critical path can still flow correctly and float calculations remain valid. Soft constraints are generally preferable to hard constraints wherever the scheduling tool supports them. A 'Finish No Later Than' soft constraint on a contractual milestone will show negative float if the network logic predicts a late finish — giving the planner a visible signal that the programme is at risk without distorting the rest of the schedule. A hard 'Must Finish On' constraint in the same position will suppress the negative float, making the schedule appear to meet the milestone even when the underlying logic does not support it. In practice, the distinction between hard and soft constraints is handled differently in different scheduling tools, and not all tools support the full range of constraint types with the same behaviour. Primavera P6, for example, distinguishes between constraint types that affect early dates, late dates, or both. Microsoft Project handles constraints differently depending on whether the project is scheduled from a start or finish date. Planners who switch between tools need to check how constraints behave in the new environment — what counts as 'soft' in one tool may function as 'hard' in another. When inheriting a schedule, always check the constraint types alongside the constraint dates. --- ## Milestone URL: https://www.somaprojectcontrols.com/resources/glossary/milestone A zero-duration activity in a schedule that marks a significant event, completion point, or contractual obligation. A milestone is a point-in-time marker in a programme — it has no duration, consumes no resources, and does nothing by itself. What it does is define when something significant has happened: design approved, structure complete, possession granted, handover achieved, funding released. Milestones are the skeleton of a schedule: they define the events that matter to the client, the contract, and the stakeholders, and they provide fixed reference points against which progress can be measured even when the detailed activity logic below them is in flux. A programme without clear milestones is difficult to report on and almost impossible to analyse for delay. Milestones serve several distinct purposes. Contractual milestones define obligations — miss the handover milestone and there may be liquidated damages, loss of payment, or a compensation event claim. Programme milestones divide the project into phases that can be reported and managed separately. Interface milestones capture the handover of information or work between parties — when design is issued to the contractor, when a third-party connection is available, when the client-supplied equipment arrives. Keeping these distinct in the programme structure is important for both management and commercial analysis. A common mistake is creating too many milestones and diluting their significance, or too few and losing the ability to track meaningful progress. A well-structured programme has milestones at every significant decision point, phase completion, and contractual obligation — and nothing else. Milestones should have zero duration: a 'milestone' with a duration is an activity, and calling it a milestone is misleading. In earned value management, many organisations use milestone-based earning rules, crediting earned value only when specific milestones are achieved rather than against percentage-complete estimates. This is a good practice precisely because milestones are objective — they are either achieved or they are not. --- ## Level of Effort (LOE) Activity URL: https://www.somaprojectcontrols.com/resources/glossary/level-of-effort-loe-activity A schedule activity whose duration is determined by the span of other activities it supports, rather than by the volume of work it contains. A Level of Effort activity represents ongoing support work — project management, quality assurance, contract administration, health and safety supervision — whose duration expands or contracts to match the activities it is supporting. Unlike discrete activities, which have a defined start, end, and deliverable, an LOE activity runs in parallel with a phase of work and has no independent end point. In earned value management, LOE activities earn value in proportion to their duration consumed: if 50% of the phase has passed, 50% of the LOE budget is earned. This means LOE activities never show a cost variance — their earned value always tracks their planned value by construction. The earned value treatment of LOE activities is their most significant limitation. Because they automatically track plan, including too many LOE activities in an EVM system inflates the earned value and makes performance look better than it is. A programme that classifies most of its cost as LOE will show a healthy SPI and CPI even when discrete deliverables are late and over budget. Best practice is to minimise the proportion of total budget assigned to LOE activities — AACE guidance suggests that LOE should not exceed 10–15% of total budgeted cost on a well-structured programme. The practical test for whether an activity should be LOE or discrete is: does this activity produce a specific deliverable that can be independently assessed for completion? If yes, it is a discrete activity. If the work just continues for as long as the project runs and the 'deliverable' is the service itself — site supervision, monthly reporting, ongoing design management — then LOE is appropriate. The decision matters for reporting integrity: every discrete activity that is mis-classified as LOE is a performance signal that the EVM system will not show. --- ## Hammock Activity URL: https://www.somaprojectcontrols.com/resources/glossary/hammock-activity A summary activity whose start and finish dates are driven by the earliest start and latest finish of the activities it spans, rather than by its own logic. A hammock activity — sometimes called a summary or span activity — is a special type of schedule element that has no independent duration or logic of its own. Its start is tied to the start of the first activity it spans, and its finish is tied to the finish of the last activity it spans. The result is an activity that automatically reflects the current status of a group of activities below it. Hammocks are used to create high-level summary views of a detailed programme, to represent project phases in a management-level Gantt, and to track costs or resources against a group of activities as if they were a single block. Hammock activities are particularly useful for reporting to stakeholders who need a simplified view of the programme. Rather than showing a hundred detailed activities across a commissioning phase, a single commissioning hammock shows the earliest start and latest finish of that entire block of work. When the underlying activities change — because of delays, acceleration, or re-sequencing — the hammock automatically adjusts to reflect the new boundaries. This makes hammocks a much more reliable summary mechanism than manually maintained summary bars, which become stale the moment the detail below them changes. The key distinction between a hammock and an LOE activity is that a hammock is driven entirely by the dates of its subactivities, while an LOE activity is driven by its own duration (which is set to match a supporting relationship). Hammocks are also different from WBS summary bars in some scheduling tools, which may or may not behave the same way depending on how the tool calculates summary-level dates. In Primavera P6, for example, WBS summary activities and hammock activities behave differently and are used for different purposes. Understanding which type you are working with is important when interpreting summary-level critical path information. --- ## Resource Levelling vs Resource Smoothing URL: https://www.somaprojectcontrols.com/resources/glossary/resource-levelling-vs-resource-smoothing Resource levelling adjusts the schedule to stay within resource limits, potentially extending the project; resource smoothing adjusts resource use without extending the project end date. Both resource levelling and resource smoothing are techniques for resolving resource conflicts in a schedule — situations where more resources are needed in a period than are available. The difference is the constraint. Resource levelling treats resource availability as the binding constraint: if you only have four concrete gangs, the schedule is extended until all concrete activities can be scheduled within that limit. The end date moves. Resource smoothing treats the end date as the binding constraint: resources are redistributed within the available float of non-critical activities to reduce peaks, but the project completion date does not change. If there is not enough float to eliminate all peaks, some over-allocation will remain. In practice, resource levelling is the more common operation because most real projects have genuine resource constraints that cannot be ignored. However, levelled schedules can look very different from the unlevelled version: activities that had float before levelling may now be critical because their start dates have been delayed to wait for resources. This has important implications for EVM, float reporting, and commercial risk — particularly on NEC contracts where the Accepted Programme and the compensation event mechanism depend on understanding the critical path. Resource smoothing is the right approach when the end date is fixed and contractually binding. In this scenario, the planner identifies activities with float, redistributes their resource demand to periods of lower overall loading, and accepts that any peak that cannot be smoothed will require either acceptance of the over-allocation or a commercial decision to hire additional resource. The practical limitation of both techniques is that scheduling tools often perform levelling and smoothing with algorithms that produce technically correct but practically odd results — splitting activities, creating awkward resource profiles, or resequencing work in ways that do not reflect how the team would actually manage it. Manual judgement is nearly always required alongside any automated levelling run. ### Frequently asked questions **What is the difference between resource levelling and resource smoothing?** Resource levelling treats resource availability as the binding constraint and extends the project end date if needed to stay within those limits — schedule logic gets reworked around the resource ceiling. Resource smoothing treats the end date as fixed and only redistributes resources within the available float on non-critical activities, accepting any over-allocation that can't be smoothed. Levelling moves the end date; smoothing protects the end date. **When should I use resource levelling vs resource smoothing?** Use resource levelling when resource limits are real and binding — you genuinely cannot exceed them (e.g. only four concrete gangs available, only one specialist welder). Accept that the end date may move. Use resource smoothing when the end date is contractually fixed and the priority is to flatten resource peaks within float without slipping completion. Smoothing is suitable when peaks are caused by scheduling clustering rather than absolute resource scarcity. **Does resource smoothing change the critical path?** Not directly — smoothing only moves activities within their existing float, so the critical path is preserved. But it does consume float on non-critical activities, which makes them more vulnerable to subsequent delays. After smoothing, run a fresh DCMA-style schedule health check; activities that previously had healthy float may now be near-critical. **Why do levelled schedules look so different from the unlevelled version?** Resource levelling moves activities until they fit within available resource — which can delay activities that previously had float, making them critical. The shape of the critical path can change entirely after levelling. This has implications for EVM, float reporting, and NEC compensation event analysis. Always compare the unlevelled and levelled versions side-by-side, and document why each levelling decision was made. --- ## Schedule Performance Index (SPI) URL: https://www.somaprojectcontrols.com/resources/glossary/schedule-performance-index-spi An EVM metric that measures schedule efficiency: SPI = Earned Value ÷ Planned Value. Below 1.0 means the project is behind plan. The Schedule Performance Index (SPI) is the ratio of work completed (Earned Value, EV) to work planned (Planned Value, PV) at a given point in time. An SPI of 1.0 means the project is exactly on schedule — the amount of work completed matches the amount planned. An SPI below 1.0 means less work has been completed than planned — the project is behind. An SPI above 1.0 means more work has been completed than planned — the project is ahead. SPI is expressed as a pure ratio, which makes it useful for comparing performance across packages or projects of different sizes. A critical limitation of SPI is that it converges to 1.0 at project completion regardless of actual schedule performance. If a project is severely late and finishes long after the planned completion date, EV and PV will eventually equalise because all planned work is eventually done — and the SPI will read 1.0 at closeout even though the project was months late. This means that SPI is most informative early and mid-project, and becomes progressively less useful as a forecasting tool in the later stages. Earned Schedule — a development of classical EVM that converts schedule variance from cost terms into time — was specifically developed to address this limitation. SPI should be read alongside the Schedule Variance (SV = EV − PV) and interpreted in context. A low SPI on a non-critical work package may be irrelevant; a low SPI on a critical path activity requires immediate attention. The most common mistake is reporting SPI at programme level without disaggregating by package or work stream: an aggregate SPI of 0.95 can conceal individual packages at 0.70 being masked by others at 1.15. Always present SPI by work breakdown structure level as well as in aggregate, and always cross-reference the packages with the lowest SPI against the critical path. --- ## Baseline Execution Index (BEI) URL: https://www.somaprojectcontrols.com/resources/glossary/baseline-execution-index-bei A schedule health metric that compares the number of activities completed to the number that should have been completed by the data date, per the baseline. The Baseline Execution Index (BEI) is one of the DCMA 14-point assessment metrics and measures execution performance in terms of activity completion count. It is calculated as the number of activities actually completed divided by the number of activities the baseline planned to have completed by the data date. A BEI of 1.0 means exactly as many activities have been finished as the baseline expected. A BEI below 1.0 — which is the common case on delayed projects — means the team is completing fewer activities per unit of time than the plan assumed. The DCMA threshold for concern is typically a BEI below 0.95. BEI has the advantage of simplicity: it does not require resource loading or cost data, just a baseline with planned completion dates and a record of which activities are actually complete. This makes it one of the quickest health indicators to produce and one of the easiest to explain to non-specialists. It is also less susceptible to gaming than EVM-based metrics because it counts discrete completions rather than percentage estimates. Either an activity is done or it is not. The limitation of BEI is that it treats all activities equally regardless of their size, cost, or criticality. Completing 100 small low-value activities while a handful of large critical-path activities slip will produce a BEI that looks acceptable but a programme that is in serious trouble. BEI should therefore always be used alongside criticality information: what is the BEI for activities on or near the critical path, and what is it for non-critical activities? A low BEI driven entirely by non-critical activities may be manageable. A low BEI concentrated on critical-path activities requires urgent attention. Never use BEI as a standalone metric without that disaggregation. ### Frequently asked questions **How is the Baseline Execution Index calculated?** BEI = Number of activities actually completed by the data date ÷ Number of activities the baseline planned to have completed by the data date. A BEI of 1.0 means execution is matching the baseline plan exactly. A BEI below 1.0 means the team is completing fewer activities than the plan assumed; a BEI above 1.0 means the team is ahead of plan in terms of activity count. The DCMA 14-point assessment threshold for concern is typically a BEI below 0.95. **What does a BEI of 0.85 mean in practice?** A BEI of 0.85 means the project has completed only 85% of the activities the baseline planned to be done by the current data date. On a 200-activity baseline plan, that translates to roughly 30 activities behind schedule. Under the DCMA 14-point thresholds, a BEI below 0.95 triggers concern; 0.85 indicates material schedule slippage and should prompt review of which activities are missing, whether they are critical-path or non-critical, and what recovery action is needed. BEI must always be read alongside critical-path criticality — 30 non-critical activities behind is a different problem from 30 critical-path activities behind. **What is the difference between BEI and SPI?** BEI (Baseline Execution Index) measures execution by count of activities — how many were finished versus how many were planned. SPI (Schedule Performance Index) measures execution by Earned Value — the budgeted cost of work performed versus the budgeted cost of work scheduled. BEI is simpler to calculate (you only need a baseline and a record of completions) but treats all activities equally regardless of size or criticality. SPI is more sophisticated but requires a resource-loaded or cost-loaded baseline. The DCMA 14-point assessment tracks BEI alongside CPLI (Critical Path Length Index) for a multi-dimensional view of schedule health; many programmes also track SPI in parallel where EVM is in place. --- ## Critical Path Length Index (CPLI) URL: https://www.somaprojectcontrols.com/resources/glossary/critical-path-length-index-cpli A forward-looking DCMA schedule metric that compares the time available to the time needed to complete the project — below 0.95 signals schedule pressure. The Critical Path Length Index (CPLI) is calculated as (Time Remaining + Total Float on the Critical Path) ÷ Time Remaining. A CPLI of 1.0 means there is exactly enough time left to complete the project at the current critical path rate. A CPLI above 1.0 means the project has float to spare — there is more time available than the critical path requires. A CPLI below 1.0, and particularly below 0.95 (the DCMA threshold), means the schedule is predicting that the project will be late: the critical path is longer than the time remaining. CPLI is one of the more useful forward-looking metrics in the DCMA 14 suite because it integrates the current critical path calculation with the time available to completion. Unlike SPI, which looks backward at performance to date, CPLI looks forward at whether the remaining work can be completed in the remaining time. A project that has been running late but has recovered performance could show a healthy SPI moving into recovery and a CPLI approaching 1.0. A project that looks productive in terms of past SPI but is loading up the remaining critical path could show a declining CPLI. CPLI should be tracked as a trend, not just as a point-in-time reading. A CPLI trending from 1.1 toward 0.9 over three reporting periods is a clear warning signal even before it crosses the threshold. Conversely, a CPLI that has been below 1.0 but is trending upward suggests that recovery actions are working. On NEC contracts and major infrastructure programmes, CPLI is often included in the schedule performance dashboard alongside BEI and SPI to give programme boards a multi-dimensional view of schedule health. Any single metric can be manipulated or misread; the combination of all three is harder to game. --- ## Cost Performance Index (CPI) URL: https://www.somaprojectcontrols.com/resources/glossary/cost-performance-index-cpi An EVM metric that measures cost efficiency: CPI = Earned Value ÷ Actual Cost. Below 1.0 means the project is spending more than the work is worth. The Cost Performance Index (CPI) is the ratio of the budgeted cost of work performed (Earned Value) to the actual cost of performing that work (Actual Cost). A CPI of 1.0 means every pound spent has delivered exactly one pound of budgeted work — perfect efficiency. A CPI below 1.0 means you are spending more than the work justifies — for every £1.00 spent, you are only earning £0.90 of budgeted work, for example. A CPI above 1.0 means you are completing work more efficiently than budgeted. Like SPI, CPI is a ratio that makes cross-programme comparison straightforward. CPI is one of the most powerful early warning indicators in project controls. Research by the US Government Accountability Office and others consistently shows that CPI at the 20% completion point rarely improves significantly over the remainder of the project. If a project is running at CPI 0.85 when 20% of the work is done, it is very likely to finish at or worse than CPI 0.85. This makes early CPI readings highly predictive of final cost outcomes, which is why funders and sponsors place so much weight on it. The Estimate at Completion calculated using current CPI — EAC = BAC ÷ CPI — is often the most reliable forecast available. CPI is sensitive to the accuracy of earned value measurement. If EV is overstated — because progress is being claimed generously — CPI will look better than it is. If accruals lag invoices, AC may understate true spend in the short term, making CPI look artificially healthy. The most resilient way to use CPI is to track it as a trend over multiple periods rather than relying on any single period reading. A CPI that has been declining steadily from 1.05 to 0.92 over six months is a more actionable signal than a single period reading of 0.96, which could reflect timing noise rather than a genuine trend. --- ## Budget at Completion (BAC) URL: https://www.somaprojectcontrols.com/resources/glossary/budget-at-completion-bac The total approved budget for the project — the sum of all budgets assigned to the work breakdown structure. Budget at Completion (BAC) is the total authorised budget for the entire project scope, established at baseline. It is the denominator in several key EVM calculations: Estimate at Completion (EAC), To-Complete Performance Index (TCPI), and others. BAC represents what the project was supposed to cost if delivered exactly to plan — it is the performance measurement baseline expressed as a single number. It does not include management reserve, which is held outside the project budget by the sponsor. BAC is the ceiling that the project manager is managing within. BAC is established as part of the baselining process and should not change unless there is a formal change to the approved scope. Budget transfers between work packages (known as internal re-planning or budget reallocation) do not change BAC — they redistribute it. A formal scope change that is approved and incorporated into the performance measurement baseline does change BAC, and the change should be documented through the change control process with a new baseline revision. Projects that see BAC changing frequently without formal change documentation are either managing scope poorly or using budget reallocation to hide cost variances. The relationship between BAC and contingency is important to understand. BAC represents the budget for the agreed scope. Contingency sits above BAC (or as a separate line) and covers identified risks that have not yet materialised. If a risk materialises and is incorporated into the project scope through a formal change, the contingency used to fund that change is added to BAC, and the performance measurement baseline is updated. Projects that draw down contingency without updating BAC are obscuring the true cost picture and making EVM metrics progressively less meaningful as the project progresses. --- ## Estimate at Completion (EAC) URL: https://www.somaprojectcontrols.com/resources/glossary/estimate-at-completion-eac A forecast of the total expected cost of the project based on actual performance to date and any revised estimate for remaining work. Estimate at Completion (EAC) is the most important cost forecasting metric in earned value management. It answers the question: given what we know now about how the project is performing, what do we expect the total cost to be at the end? EAC is calculated in several ways depending on the confidence placed in the project's ability to recover. The simplest formula — EAC = Actual Cost (AC) + Estimate to Complete (ETC) — uses the project team's own revised estimate for the remaining work. The EVM formula — EAC = BAC ÷ CPI — assumes that future work will be performed at the same efficiency as work to date, which tends to be the most statistically reliable forecast after the 20% completion point. The relationship between EAC and BAC drives the Variance at Completion (VAC = BAC − EAC). A positive VAC means the project is forecast to underspend; a negative VAC means it is forecast to overspend. EAC is the number that clients, sponsors, and finance directors most want to see in cost reports, because it translates the complex EVM metrics into a single bottom-line forecast. However, EAC is only as good as the assumptions behind it: if CPI is being calculated on an EV figure that has been gamed, or if AC is understating true commitment through slow accruals, the EAC will be wrong. Different EAC formulae give different answers and are appropriate in different circumstances. EAC = BAC ÷ CPI is best when the historical CPI is stable and expected to continue. EAC = AC + (BAC − EV) ÷ (CPI × SPI) accounts for both cost and schedule efficiency and tends to be pessimistic — useful as a worst-case scenario. EAC = AC + bottom-up ETC is best when there has been a specific disruption event that makes historical performance a poor guide to the remaining work. Presenting more than one EAC calculation — with the assumptions behind each — is better practice than presenting a single figure that conceals the range of uncertainty. --- ## Estimate to Complete (ETC) URL: https://www.somaprojectcontrols.com/resources/glossary/estimate-to-complete-etc The expected cost to complete all remaining project work from the current data date to the end. Estimate to Complete (ETC) is the expected cost of finishing all remaining work. It feeds directly into the Estimate at Completion: EAC = AC + ETC. ETC can be derived in two main ways. The formulaic approach uses EVM indices: ETC = (BAC − EV) ÷ CPI, which assumes the remaining work will be completed at the same efficiency as work to date. The bottom-up approach has the project team re-estimate the remaining work in detail — re-planning from the current position — and the sum of those estimates becomes ETC. The bottom-up approach is more work but more accurate when the project's circumstances have changed materially. The choice between formulaic and bottom-up ETC depends on project stage and circumstances. In early and mid-project, when circumstances are broadly as planned and CPI is stable, the formulaic approach provides a reliable and unbiased forecast. After a significant scope change, disruption event, or change in execution strategy, a bottom-up re-estimate is necessary because historical CPI no longer reflects the conditions under which the remaining work will be done. Using a formulaic ETC through a material disruption event will produce a systematically incorrect EAC. ETC should be reviewed and challenged at every reporting cycle. A common governance failure is allowing ETC to decrease by exactly the amount spent in each period — effectively reporting spend without updating the forecast. This produces an EAC that does not change over time, which gives false comfort that the project is on track. A realistic ETC will fluctuate as scope crystallises, risks mature, and performance data accumulates. If ETC is moving perfectly smoothly with no variation, either the project is unusually well-controlled or the estimates are not being genuinely revisited. --- ## Variance at Completion (VAC) URL: https://www.somaprojectcontrols.com/resources/glossary/variance-at-completion-vac VAC = BAC − EAC: the most direct signal of whether your project will finish within budget. A practitioner guide to reading Variance at Completion, common misreadings, and why the trend matters far more than a single figure. Variance at Completion (VAC) is the most direct expression of whether the project is expected to finish within its approved budget. A positive VAC (BAC exceeds EAC) means the project is forecast to underspend — there is budget headroom. A negative VAC means the project is forecast to overrun the approved budget. VAC gives stakeholders and sponsors an immediate sense of financial exposure at a glance, which is why it typically appears on the first page of any cost performance report. It translates the more abstract EVM metrics into pounds. VAC is only meaningful if EAC is meaningful. All the caveats about EAC accuracy — quality of earned value measurement, reliability of remaining work estimates, currency of risk register — apply equally to VAC. A VAC of +£2m based on an EAC that has been calculated on gamed EV figures is not reassuring; it is misleading. When reviewing a programme, always probe the EAC assumptions before relying on the VAC headline. The most relevant question is: has EAC been independently challenged, or is it the delivery team's own best-case view of the remaining work? VAC should be tracked as a trend. A VAC that starts at +£5m, drops to +£3m, then +£1m, then turns negative over several reporting periods is telling you something important: the project is burning through its cost headroom and the trajectory is clearly toward overrun. A single negative VAC reading could be a timing issue or a one-off accrual problem; a trend of deteriorating VAC is a structural signal. Project boards and sponsors should be tracking VAC trend graphs, not just point-in-time readings, and setting trigger thresholds that require formal escalation when VAC trends negative by a defined amount. ### Frequently asked questions **What is Variance at Completion (VAC)?** Variance at Completion is the difference between the project's approved budget and the current forecast final cost: VAC = BAC − EAC. A positive VAC means the project is forecast to underspend (budget headroom). A negative VAC means the project is forecast to overrun the approved budget. It is the headline EVM metric used to communicate financial exposure to sponsors and steering groups. **How do you calculate Variance at Completion?** VAC = BAC − EAC, where BAC is the Budget at Completion (the total approved budget) and EAC is the Estimate at Completion (the current forecast final cost). EAC itself can be calculated several ways — formulaic (BAC ÷ CPI for cost-efficiency-based forecasting, or AC + (BAC − EV) for performance-recovery scenarios) or bottom-up. The VAC is only as reliable as the EAC it depends on. **Is a positive or negative VAC good?** Positive VAC is good — it means the project is forecast to come in under the approved budget. Negative VAC is bad — it means a forecast overrun, and the size of the negative number tells you the magnitude of the exposure. But VAC needs to be read as a trend: a positive VAC that has been steadily eroding over several reporting periods is a structural signal of cost pressure, even before it turns negative. **What's the difference between Cost Variance (CV) and Variance at Completion (VAC)?** Cost Variance (CV = EV − AC) is backward-looking — it tells you whether the work done so far has cost more or less than budgeted. Variance at Completion (VAC = BAC − EAC) is forward-looking — it tells you whether the project is forecast to finish within budget. CV is a snapshot of past cost performance; VAC is the projection of where the project will end up. Both should appear in any EVM report. --- ## To-Complete Performance Index (TCPI) URL: https://www.somaprojectcontrols.com/resources/glossary/to-complete-performance-index-tcpi A forward-looking EVM metric that calculates the cost efficiency required to complete the remaining work within the budget or forecast. The To-Complete Performance Index (TCPI) answers a simple but powerful question: at what CPI does the remaining work need to be performed to hit a given cost target? If the target is the original BAC, the formula is TCPI = (BAC − EV) ÷ (BAC − AC). If the target is the current EAC, the formula is TCPI = (BAC − EV) ÷ (EAC − AC). A TCPI of 1.0 means the remaining work must be performed at exactly the same efficiency as budgeted — exactly to plan. A TCPI above 1.0 means the project needs to perform better than planned to hit the target. A TCPI significantly above 1.0 is a red flag: it means the budget target is effectively unachievable. TCPI is most useful as a sanity check on overly optimistic EAC forecasts. If a project is running at CPI 0.85 and the project team is forecasting EAC = BAC (implying they will recover all the cost overrun in the remaining work), the TCPI calculation will show what CPI they need to achieve to make that forecast true. If the required TCPI is 1.30 — meaning they need to perform 30% better than planned for the rest of the project — that is not credible, and the EAC is almost certainly too low. TCPI serves as an independent check on the realism of any bottom-up ETC. When TCPI relative to BAC and TCPI relative to EAC diverge significantly, that gap tells you how much the project has moved away from its original budget. A project where TCPI(BAC) = 1.5 and TCPI(EAC) = 1.0 has acknowledged in its EAC that it cannot recover the overrun, and the EAC is a realistic forecast — the remaining work only needs to be done at plan efficiency. A project where both values are 1.5 is either refusing to acknowledge the overrun in its EAC, or is expecting an extraordinary recovery. Neither situation ends well without intervention. --- ## Control Account URL: https://www.somaprojectcontrols.com/resources/glossary/control-account A management control point in an EVM system where scope, schedule, and budget are integrated and performance is measured. A control account is the unit of measurement in a well-structured EVM system. It sits at the intersection of the Work Breakdown Structure (WBS) — defining what is being measured — and the Organisational Breakdown Structure (OBS) — defining who is responsible. Each control account has a single accountable manager, a defined scope (from the WBS dictionary), a time-phased budget (the performance measurement baseline for that account), and an associated schedule. Performance measurement — EV, AC, SV, CV, SPI, CPI — is reported at control account level and rolled up to programme level. The control account is where management action happens. The appropriate number and size of control accounts depends on the project. Too few and the programme-level metrics become meaningless aggregations that conceal real problems. Too many and the reporting overhead overwhelms the team and the data quality deteriorates. The AACE Total Cost Management Framework and the EVMIA guidelines suggest sizing control accounts so that each one represents a meaningful work segment — large enough to be managed coherently, small enough to give visibility of performance before problems become unmanageable. On a typical construction project, this might mean control accounts at the level of major packages: civils, structural steel, mechanical and electrical, fit-out. The control account plan (CAP) is the document that defines the scope, budget, schedule, and earning rules for each control account. If an EVM system does not have documented CAPs, it is not properly established — the EV figures being reported are not grounded in agreed definitions of what counts as progress. Reviewing the CAPs is one of the first things an independent EVM auditor will do, because a CAP that has not been updated since baseline tells you immediately that the EVM system is running on stale definitions and the performance data is unreliable. --- ## Work Package URL: https://www.somaprojectcontrols.com/resources/glossary/work-package The lowest level of the Work Breakdown Structure — a defined unit of work that can be assigned, scheduled, budgeted, and tracked. A work package is the fundamental unit of project control. It sits at the base of the WBS hierarchy, below deliverables and sub-deliverables, and represents a discrete piece of scope that can be assigned to a single organisation or team, scheduled with defined start and finish dates, budgeted with a specific cost, and tracked for progress. Work packages roll up into control accounts (for EVM purposes) and control accounts roll up into the overall programme. The discipline of decomposing all project scope into work packages — and ensuring that every pound of budget and every activity in the schedule traces to a specific work package — is the foundation of integrated project controls. The definition of what makes a good work package is practically important. A well-defined work package has a clear and unambiguous scope statement (documented in the WBS dictionary), a single responsible organisation or individual, a duration short enough to track progress meaningfully (the AACE guidance suggests 80-hour or two-week activities as a rough upper bound for detail activities), a defined deliverable or completion criterion, and a budget that can be earned against objective milestones. Work packages that are too large are hard to track; work packages that are too small create administrative overhead without proportionate visibility benefit. A common mistake on major programmes is conflating work packages with purchase orders or contracts. A work package is a scope element; a contract is the commercial mechanism through which that scope is procured. A single contract may cover multiple work packages; a single work package may be split across multiple contracts. Maintaining the distinction is important for cost reporting: if cost is tracked only at contract level, it is impossible to see how individual scope elements are performing. The WBS should drive the cost structure, with contracts mapped to it — not the other way around. --- ## Performance Measurement Baseline (PMB) URL: https://www.somaprojectcontrols.com/resources/glossary/performance-measurement-baseline-pmb The integrated time-phased budget for the project, combining scope, schedule, and cost into the reference plan against which EVM is measured. The Performance Measurement Baseline (PMB) is the approved, time-phased budget for the entire project scope, excluding management reserve. It represents the integration of the work breakdown structure, the schedule, and the cost estimate into a single reference plan. For each control account, the PMB contains a budget spread over time — a planned value profile — that defines how much work is expected to be done in each period. The sum of all control account budgets equals the PMB, and the sum of the PMB and management reserve equals the total authorised budget (TAB). Establishing the PMB is the culmination of the project planning and estimating process. It requires that scope is defined (WBS complete), the schedule is baselined (logic-linked, resource-loaded, and approved), the cost estimate is accepted, and the budget has been allocated to work packages. A programme that runs EVM without a properly established PMB is, in practice, just tracking actuals against a rough plan — the SPI and CPI calculations will be meaningless because there is no rigorous planned value profile to compare against. The PMB should be treated as a controlled document. Changes to the PMB — whether from scope changes, design development, risk drawdowns, or re-planning — must go through formal change control and be documented with version control and an audit trail. An undocumented PMB change is a governance failure that undermines the integrity of every performance metric calculated against it. Project boards and independent monitors should periodically audit the PMB change history to ensure that re-planning has been properly authorised and that the baseline has not been adjusted in ways that artificially improve performance metrics. --- ## Cost Breakdown Structure (CBS) URL: https://www.somaprojectcontrols.com/resources/glossary/cost-breakdown-structure-cbs A hierarchical breakdown of all project costs, organised by cost type or element rather than by deliverable — the cost-focused counterpart to the WBS. A Cost Breakdown Structure (CBS) organises project costs by the type of expenditure: labour, materials, plant, subcontracts, preliminaries, overheads, and so on. Where the WBS decomposes scope by deliverable, the CBS decomposes costs by category. On major projects, the two structures are used together: the WBS defines what is being built; the CBS defines how costs are categorised within each WBS element. This two-dimensional matrix — WBS by CBS — gives the cost team the ability to analyse cost by deliverable (how much is the mechanical package costing?), by resource type (how much are we spending on subcontracted labour programme-wide?), or by any combination. The CBS is the basis for cost coding in the project's financial management system. When commitments are raised and invoices processed, each transaction is coded to a CBS element (and typically also to a WBS element), which enables the cost reports to be produced at whatever level of detail is needed. A well-designed CBS that is consistently applied produces cost data that can be used for benchmarking against industry norms, for informing future project estimates, and for identifying where costs are deviating from plan across the programme. A common problem is allowing the CBS to become an account code list rather than a structured breakdown. Account codes that have accumulated over years of financial system evolution often reflect historical accounting practice rather than the cost categories that project controls actually needs. When setting up a new project, the CBS should be designed from scratch based on what cost visibility the project team and client need — not copied wholesale from the chart of accounts. The CBS should be simple enough to be used consistently, detailed enough to provide genuine insight, and aligned with the WBS so that cost and scope data can be reconciled without manual workarounds. --- ## Resource Breakdown Structure (RBS) URL: https://www.somaprojectcontrols.com/resources/glossary/resource-breakdown-structure-rbs A hierarchical breakdown of all project resources — people, plant, and materials — organised by type, used for resource planning and cost allocation. The Resource Breakdown Structure (RBS) catalogues all the resource types a project will use, organised hierarchically. The top level might distinguish between labour, plant, and materials. Below that, labour is broken into disciplines (civil engineers, electricians, project managers), plant into types (excavators, cranes, concrete pumps), and materials into categories (steel, concrete, cable). The RBS is used to structure resource planning, to support cost estimation (because resource types map to cost rates), and to provide the framework for resource loading in the schedule. The RBS works in conjunction with the WBS and CBS to create a three-dimensional view of the project: what is being built (WBS), what it costs (CBS), and what resources are needed to build it (RBS). In resource-loaded scheduling tools such as Primavera P6, resources are assigned to schedule activities using the RBS categories, which allows the schedule to calculate resource demand profiles over time — the basis for resource levelling and smoothing. In cost models, resource quantities and rates from the RBS are the building blocks of the bottom-up estimate. On smaller projects, the RBS is often implicit rather than formally documented — the project team just knows what kinds of resources they have and plans accordingly. On major programmes, a formal RBS is essential for consistent resource coding across multiple packages and contractors, for workforce planning, and for tracking actual resource utilisation against plan. The RBS also underpins the risk analysis: when modelling the impact of a shortage of specialist resources (a common risk on infrastructure programmes), the risk needs to be linked to the specific RBS element that defines the scarce resource type, so that the schedule and cost model correctly propagates the impact across all the activities that depend on that resource. --- ## Risk Breakdown Structure (RBS) URL: https://www.somaprojectcontrols.com/resources/glossary/risk-breakdown-structure A hierarchical classification of project risks by source or category, used to organise the risk register and identify gaps in risk identification. A Risk Breakdown Structure categorises risks in a hierarchy, typically from broad categories at the top — technical risk, commercial risk, external risk, programme risk — down to specific risk sub-types at lower levels. Technical risk might break into design risk, construction risk, commissioning risk, and interface risk. Commercial risk might break into contractual risk, procurement risk, and stakeholder risk. The RBS provides a consistent taxonomy for classifying entries in the risk register, which makes it easier to identify concentrations of risk in particular areas, to compare risk profiles across projects, and to spot gaps where a category is suspiciously empty. The main value of an RBS is forcing systematic thinking about risk categories before the risk identification exercise begins. If a facilitator walks into a risk workshop with a blank risk register, the team will tend to identify the risks that are most visible and most discussed — the obvious ones. Working through the RBS categories forces the conversation: 'We've identified lots of technical risks, but let's now think about commercial risks — what contract clauses, procurement uncertainties, or commercial interfaces could cause us problems?' This structured prompting reliably surfaces risks that a free-form brainstorm would miss. The RBS also enables more meaningful risk reporting to senior stakeholders. Rather than presenting a list of 50 risks in a register, a risk manager can summarise by RBS category: 'We have ten technical risks of which three are rated high; four commercial risks of which one is rated high; and two external risks with low probability.' This category-level view is more actionable for a project board than a flat list. On large programmes with multiple contracts and sub-projects, the RBS provides a consistent classification scheme that makes portfolio-level risk aggregation possible — comparing risk profiles across packages and identifying programme-level themes that individual projects cannot see. --- ## Pre-mortem URL: https://www.somaprojectcontrols.com/resources/glossary/pre-mortem A risk identification technique where the team imagines the project has already failed and works backwards to identify what caused it. A pre-mortem is a risk workshop technique developed by psychologist Gary Klein, now widely used in project risk management. Rather than asking 'what could go wrong?', the facilitator asks the team to assume it is one year from now and the project has failed badly — costs overran significantly, the programme slipped, the client is unhappy. The team's task is to write down, individually, all the reasons why this failure occurred. The facilitator then collects the answers and works through them with the group. The technique exploits the human tendency to generate explanations more easily when given a reference point — the 'failure' — than when asked to imagine abstract future risks. Pre-mortems are particularly effective at surfaces risks that team members know about but are reluctant to raise in a conventional workshop setting. When the narrative is framed as 'the project already failed, what happened?', it removes the social inhibition around raising concerns that might seem like criticism of the team's plan or competence. People are more willing to articulate a specific failure scenario than to raise a concern that sounds like pessimism or disloyalty. This is why pre-mortems often generate a different set of risks from a conventional prompt-list exercise — they tap into tacit knowledge that polite group dynamics tend to suppress. Combining a pre-mortem with a conventional risk workshop gives broader coverage than either technique alone. Run the conventional exercise first to capture the structured risk categories, then run a pre-mortem to surface the less structured, more intuitive concerns. The overlap between the two sets of risks is reassuring — it suggests the obvious risks are being captured. The gaps — risks that appeared in the pre-mortem but not the conventional register — are the most valuable output, because they are the risks that the formal process missed. Treat those gaps as high-priority items for further analysis. --- ## Post-mortem (Lessons Learned Review) URL: https://www.somaprojectcontrols.com/resources/glossary/post-mortem A structured review conducted after a project or phase to capture what went well, what went wrong, and what should be done differently next time. A post-mortem — more formally called a lessons learned review or retrospective — is the process of systematically extracting knowledge from a completed project or phase and recording it in a form that can benefit future projects. A well-run post-mortem examines what happened against what was planned: where did cost and schedule outturns differ from forecasts, which risks materialised and which did not, which mitigation actions worked, and which decisions in hindsight proved to be wrong? The outputs feed the organisation's institutional knowledge base, inform future estimates and risk registers, and can be used to calibrate the three-point estimates used in future quantitative risk analyses. Post-mortems are one of the most consistently neglected activities in project management. The reason is straightforward: they happen at the end, when the team has dispersed, the budget has been spent, and the project sponsor has moved on. There is no commercial incentive to invest time and money in an activity whose benefits accrue to future projects rather than the current one. Organisations that take lessons learned seriously build it into the project governance framework as a formal deliverable with budget, timing, and ownership — not an optional activity that gets scheduled and then cancelled. For post-mortems to genuinely improve future practice, the lessons need to be specific and actionable. 'Communication was poor' is not an actionable lesson. 'The contractor's weekly progress reports consistently overstated earned value because there were no physical inspection requirements attached to the earning criteria — in future, earning rules should require photographic evidence or a site visit sign-off' is actionable. The test of a useful lesson is: could a project manager on a future project read this and change their behaviour? If not, the lesson has not been extracted at sufficient depth. --- ## Risk Appetite Statement URL: https://www.somaprojectcontrols.com/resources/glossary/risk-appetite-statement A formal declaration by an organisation of the amount and type of risk it is prepared to accept in pursuit of its objectives. A risk appetite statement is the governing document that defines how much risk the organisation is willing to take. It is distinct from a risk policy (which describes the process for managing risk) and a risk tolerance (which sets operational thresholds for specific risk categories). A well-crafted risk appetite statement addresses different risk types separately: an organisation might have low appetite for safety risk, medium appetite for programme risk, and higher appetite for commercial risk on innovation projects. These qualitative positions are then translated into quantitative decision rules — confidence levels for funding submissions, escalation thresholds for individual risks, approval authorities for contingency drawdown. The appetite statement provides the authorising environment for project-level risk decisions. When a project team is deciding whether to fund to P50 or P80, they should be guided by the organisation's stated risk appetite for cost overrun, not by the project manager's personal preference or the finance director's instinct. Without a documented appetite statement, these decisions are made ad hoc, inconsistently, and often under commercial pressure that biases them toward insufficient contingency. The appetite statement makes the decision framework explicit and gives project teams a defensible basis for their recommendations. A risk appetite statement is only useful if it is current and actively used. Statements that were drafted for a governance audit and never revisited are decorative documents. The statement should be reviewed at least annually, and updated whenever the organisation's strategic context changes significantly — a new contract model, a new funding environment, a change in leadership. More importantly, it should be tested against real decisions: when the board approved a P65 funding level last quarter despite a P80 recommendation, does that decision reflect the stated appetite or challenge it? Post-decision reviews against the appetite statement are what turn it from a governance document into a live management tool. --- ## Secondary Risk URL: https://www.somaprojectcontrols.com/resources/glossary/secondary-risk A new risk that arises as a direct result of implementing a risk response — a side-effect of the mitigation itself. A secondary risk is a risk created by the act of responding to another risk. If a project team decides to accelerate a critical-path activity to address schedule risk by adding extra labour resources, they may create a secondary risk: the site becomes congested, safety incidents increase, or productivity on adjacent activities falls because the additional workers are competing for the same working space. The original schedule risk has been reduced, but a new set of risks has been introduced by the response. Secondary risks must be identified, assessed, and managed alongside primary risks. Secondary risks are easy to overlook because risk management processes typically focus on identifying and responding to primary risks and then move on. The follow-through step — asking 'what could go wrong as a result of what we just decided to do?' — is often skipped. This is a mistake, because secondary risks can be as significant as the primary risk they were introduced to address. A decision to novate a key subcontractor to address a procurement risk might create a secondary commercial risk if the novation terms are not carefully structured. Switching to a different construction methodology to manage ground risk might create new programme risk if the team has limited experience with the new method. Tracking secondary risks requires a risk register structure that captures the relationship between the primary risk, the response action, and any secondary risks generated. Some risk management tools support this explicitly with parent-child links between risk entries. Where this is not possible, a notes field on the primary risk entry should record any secondary risks arising from the response, with a cross-reference to the relevant secondary risk entries. This linkage is important for completeness audits: if the primary risk is closed and the response action is implemented, the secondary risks should be transferred to active monitoring rather than disappearing along with the primary entry. --- ## Residual Risk URL: https://www.somaprojectcontrols.com/resources/glossary/residual-risk The risk exposure that remains after mitigation actions have been applied — the risk the project carries even after doing everything reasonable to reduce it. Residual risk is what is left after the mitigation. If a risk has an initial probability of 60% and a cost impact range of £500k–£2m, and the mitigation actions taken reduce the probability to 25% and the maximum impact to £1m, the residual risk is the 25% probability of a £1m impact. Risk registers should record both the inherent risk (before mitigation) and the residual risk (after mitigation), because both are important for different purposes: the gap between them demonstrates the value of the mitigation programme, and the residual risk is what goes into the quantitative risk model. A critical governance point is that residual risk is the risk the project actually carries. Decisions about contingency, escalation, and risk appetite should be made based on residual risk levels, not inherent risk levels. A project that shows many 'red' risks on an inherent basis but has robust mitigations in place for all of them may actually have a modest residual risk profile. A project that shows mostly 'amber' inherent risks but has implemented few meaningful mitigations may carry a higher residual exposure than the raw register suggests. Always look at both the inherent and residual risk scores together. The residual risk calculation is only credible if the mitigation actions have actually been implemented and are working. A risk register that shows mitigation actions as 'planned' or 'in progress' and uses a reduced residual probability anyway is understating the true current exposure. Best practice is to update residual risk scores only when mitigation actions have been confirmed as complete and effective. Until then, the risk should be carried at its pre-mitigation level for purposes of contingency calculation and risk reporting. This discipline — separating 'mitigations planned' from 'mitigations implemented and working' — is one of the hallmarks of a mature risk management process. --- ## Inherent Risk vs Residual Risk URL: https://www.somaprojectcontrols.com/resources/glossary/inherent-risk-vs-residual-risk Inherent risk is the exposure before any mitigation; residual risk is what remains after mitigations have been applied. Both should be recorded in the risk register. Inherent risk — sometimes called gross risk — is the level of risk exposure in the absence of any mitigation controls. It is the 'raw' risk before the project has done anything about it. Residual risk — sometimes called net risk — is the exposure that remains after mitigation actions have been implemented. The relationship between the two is what the mitigation programme achieves: the inherent risk is the starting position, the residual risk is the ending position, and the gap between them is the value delivered by the mitigation effort. Recording both inherent and residual risk in the register serves several purposes. It demonstrates that mitigations are adding value — if inherent and residual scores are the same for most risks, either the mitigations are not working or they have not been implemented. It supports the business case for investing in mitigation: if a particular risk can be reduced from 'high' inherent to 'low' residual by spending £50k on ground investigation, that is a quantifiable return. And it provides an honest picture of exposure: the project carries residual risk, not inherent risk, and contingency should be sized against residual not inherent exposure. The language of inherent versus residual risk can cause confusion in risk workshops, where participants sometimes interpret 'inherent' as 'theoretical maximum' and 'residual' as 'what we actually expect.' Neither interpretation is quite right. Inherent risk is the real exposure before mitigations — not a worst-case theoretical extreme. Residual risk is the real exposure after mitigations currently in place — not the hoped-for position after future planned mitigations. Facilitators should spend a few minutes at the start of any risk workshop calibrating these definitions with the group, because misunderstood definitions produce risk scores that cannot be compared or aggregated meaningfully. --- ## Correlation in QRA URL: https://www.somaprojectcontrols.com/resources/glossary/correlation-in-qra The statistical relationship between risks or activity durations in a quantitative risk model — ignoring correlation typically underestimates total project risk. Correlation in a quantitative risk analysis model captures the tendency for certain risks or uncertainties to move together. If ground conditions are worse than expected in one area of the site, they are likely to be worse than expected across the whole site — the risks are positively correlated. If the concrete programme slips, the structural steel programme that follows it is likely to slip too — the uncertainties are correlated through the schedule logic. In a Monte Carlo simulation, ignoring these correlations means that each risk is sampled independently: in some iterations, ground conditions are bad but the concrete programme is fine and the structural steel is also fine. That combination is physically implausible, and modelling it as if it were possible compresses the spread of the simulation output below what reality would produce. The practical consequence is that a model with no correlation will produce a narrower S-curve — apparently lower uncertainty — than the same model with realistic correlation applied. The P80 from an uncorrelated model may be significantly lower than the true P80. This is not a small technical adjustment: on complex programmes where many risks share common drivers (weather, labour market, regulatory environment, a single key supplier), the difference between an uncorrelated and a properly correlated model can be 10–20% of the total contingency requirement. Setting correlation coefficients is an area where expert judgement is required. Most QRA tools allow analysts to specify correlation coefficients between pairs of risk items or between activity duration ranges — values between −1 (perfectly negatively correlated) and +1 (perfectly positively correlated), with 0 meaning independent. For most project risks, positive correlations of 0.5–0.8 are appropriate for risks sharing a common driver. A simple practical approach is to group risks by their root cause — weather risks, labour risks, design risks, regulatory risks — and apply uniform moderate positive correlation within each group, reflecting the fact that a bad year for weather will affect all weather-sensitive activities simultaneously. --- ## Triangular Distribution URL: https://www.somaprojectcontrols.com/resources/glossary/triangular-distribution A probability distribution defined by minimum, most likely, and maximum values, forming a triangle shape — commonly used for three-point estimates in risk analysis. The triangular distribution is one of the simplest and most widely used probability distributions in quantitative risk analysis. It is defined entirely by three parameters: the minimum possible value, the most likely value (mode), and the maximum possible value. The probability density forms a triangle: it rises linearly from zero at the minimum to its peak at the most likely, then falls linearly back to zero at the maximum. The area under the triangle is 1.0 (as with any probability distribution). The triangular distribution is easy to explain to subject matter experts, easy to elicit estimates for, and requires no special statistical knowledge to use. The main advantage of the triangular distribution over more complex alternatives is its transparency. An expert can directly specify minimum, most likely, and maximum values and immediately understand what those values mean in terms of the shape of the distribution. The main limitation is that it assumes a perfectly linear relationship between the mode and both extremes — the probability rises and falls symmetrically or asymmetrically but always linearly. Real-world uncertainties are often better represented by distributions that taper more gently toward the tails (like the BetaPERT distribution), but triangular is a reasonable approximation when precise tail behaviour is not critical. Choosing between a triangular and a PERT or BetaPERT distribution depends on how important the tail behaviour is for the risk item in question. For most routine activity durations and cost elements, triangular is entirely adequate. For risks where the extreme values are genuinely important — because they are what drive the P90 or P95 outcome — the BetaPERT or lognormal distribution may give more realistic tail behaviour. In practice, the choice of distribution rarely changes the overall QRA output as much as the quality of the input estimates. Getting the right three-point values from well-calibrated subject matter experts matters far more than whether you use triangular or BetaPERT. --- ## PERT Distribution URL: https://www.somaprojectcontrols.com/resources/glossary/pert-distribution A probability distribution based on the PERT formula that gives greater weight to the most likely value, producing a smoother, more realistic shape than the triangular distribution. The PERT (Programme Evaluation and Review Technique) distribution is a modified beta distribution parameterised by minimum, most likely, and maximum values — the same three inputs as the triangular distribution — but with a different shape. Rather than rising and falling linearly to the mode, the PERT distribution forms a smooth bell-like curve that gives significantly more weight to the most likely value and tapers more gradually toward the extremes. The PERT mean is calculated as (minimum + 4 × most likely + maximum) ÷ 6, which gives four times the weight to the mode compared to the simple arithmetic mean of the three values. The PERT distribution is generally considered more realistic than the triangular distribution for project cost and duration estimates. In reality, activities are more likely to complete near the most likely value than near the extremes — the probability does not increase linearly up to the mode and then drop off a cliff. The PERT distribution captures this concentration around the central estimate while still allowing for tail events. It is widely used in both schedule risk analysis tools and cost risk models. The distinction between PERT and BetaPERT is subtle: the original PERT distribution uses a fixed weighting factor of 4 for the mode, while BetaPERT allows the weighting factor to be varied (typically with a lambda parameter of 4 as the default). For most project risk analysis purposes, standard PERT and BetaPERT with default settings produce very similar results. The choice between them is less important than ensuring the three input values are well-calibrated. The most common error with PERT inputs — as with triangular — is setting the minimum and maximum too close to the most likely, producing a distribution that underestimates variability. --- ## BetaPERT Distribution URL: https://www.somaprojectcontrols.com/resources/glossary/betapert-distribution A flexible version of the PERT distribution where the weighting of the most likely value can be adjusted, used in advanced quantitative risk models. The BetaPERT distribution is a generalised form of the PERT distribution that adds a shape parameter (typically called lambda or the weighting factor) to control how strongly the distribution concentrates around the most likely value. With lambda = 4, BetaPERT is identical to the standard PERT distribution. With a higher lambda (say, 6 or 8), the distribution becomes more tightly concentrated around the mode — suitable for activities where there is high confidence that the outcome will be close to the most likely value but where extreme outcomes remain theoretically possible. With a lower lambda, the distribution is flatter and more diffuse. BetaPERT is the default distribution in several major QRA tools, including Oracle Primavera Risk Analysis (formerly Pertmaster) and Safran Risk, because it offers the right combination of realistic shape and practical parameterisation. The three-point estimate inputs are the same as for triangular and PERT, which means subject matter experts can provide estimates without needing to understand the mathematics of beta distributions. The lambda parameter is typically set by the analyst based on context rather than elicited from experts. The practical guidance for choosing between triangular, PERT, and BetaPERT is: triangular for simple models or when the tool does not support the others; PERT or BetaPERT (with default lambda) for most project cost and schedule applications, where concentrating more probability near the most likely value is appropriate; BetaPERT with adjusted lambda only when there is a specific reason to change the shape — for example, a procurement item with a very tight delivery window and historical data supporting high confidence in the most likely duration. For most practitioners, the choice between PERT and BetaPERT at default settings is not material — the input values matter far more than the distribution family. --- ## Sensitivity Analysis (Tornado Chart) URL: https://www.somaprojectcontrols.com/resources/glossary/sensitivity-analysis-tornado-chart An analysis that identifies which risks or uncertainties have the greatest influence on project cost or schedule outcomes — typically displayed as a ranked bar chart. Sensitivity analysis in a QRA context identifies the inputs that most influence the variability of the output. For a cost risk model, it answers: which risk items and which cost estimate uncertainties are driving the spread of the total cost distribution? The results are displayed as a tornado chart — a horizontal bar chart where inputs are ranked from top to bottom by their influence on the output, with the longest bar at the top. The name comes from the characteristic shape of the chart, which widens at the top like an inverted tornado. Sensitivity analysis is arguably the most actionable output of a QRA. The S-curve tells you the probability of different outcomes; the tornado chart tells you why those outcomes vary. The top five or ten items in a tornado chart define where the project team should focus its risk management effort. If ground conditions and procurement lead time together account for 60% of the variance in the project cost distribution, those are the two risk areas that need active management, detailed monitoring, and the most sophisticated mitigation strategies. Everything else on the risk register is secondary to getting those two right. There are two main types of sensitivity analysis in Monte Carlo models. Regression-based sensitivity measures the statistical correlation between each input variable and the overall output across all iterations — the higher the correlation, the more influential the input. Contribution to variance decomposes the total variance of the output into the percentage contributed by each input. Both approaches give broadly similar rankings for most models, though they can diverge when inputs are correlated. Some tools also produce criticality index charts for schedule models, showing the proportion of iterations in which each activity appears on the critical path — which is the schedule equivalent of a cost sensitivity analysis. All of these outputs should be reviewed alongside the S-curve, not as a standalone analysis. --- ## NEC4 Accepted Programme URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-accepted-programme The current, contractually recognised programme under an NEC4 contract — the reference against which progress, compensation events and extensions of time are assessed. Under an NEC4 Engineering and Construction Contract, the Accepted Programme is the working version of the programme that the Project Manager has accepted under Clauses 31 and 32. It sits at the centre of how NEC4 manages time: compensation events are assessed against it, completion dates are tracked against it, and the Contractor is required to submit revised programmes at regular intervals to keep it current. It is not simply a Gantt chart — NEC4 specifies what an Accepted Programme must contain, including planned completion, the order and timing of operations, float, time risk allowances, and the dates on which the Contractor plans to meet each Key Date. The Accepted Programme is a live document. Every time a compensation event is implemented, the programme should be updated to reflect the agreed change. Contractors are required to submit revised programmes at the interval stated in the Contract Data (typically every four to eight weeks), and the Project Manager must either accept the revised programme or give reasons for not accepting it. Failing to maintain a current Accepted Programme is a common trigger for disputes — if there is no agreed reference programme, assessing compensation events or delay claims becomes a retrospective exercise rather than a contemporaneous one. For project controls teams, the Accepted Programme is the single point of truth for time management on an NEC4 contract. It should be produced to a schedule quality standard (DCMA 14-point compliant, logic-linked, resource-loaded where required), updated with actuals and re-forecasts at each submission cycle, and version-controlled so every previous accepted programme is retrievable. On programmes where the Accepted Programme is treated casually — submitted late, updated inconsistently, or not reconciled to compensation events — the contract loses its primary time-management discipline. --- ## NEC4 Compensation Event URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-compensation-event Under NEC4, a defined event that entitles the Contractor to additional time, cost or both — assessed against the Accepted Programme in a structured, contemporaneous process. NEC4 lists the specific events that qualify as compensation events — including changes to the Works Information, unforeseen physical conditions, weather that meets a defined severity threshold, and Project Manager or Client actions that affect the work. The contractual principle is that the Contractor should not bear risk for events outside their control, provided the event is properly notified and assessed through the compensation event process. Compensation events are the mechanism by which NEC4 allocates risk contemporaneously, rather than leaving disputes to be resolved retrospectively. The process has specific time-bar clauses. A Contractor must notify a compensation event within eight weeks of becoming aware of it, or lose the right to additional time or cost in most circumstances. The Project Manager must respond within a defined period, either accepting the notification and requesting a quotation, or rejecting it with reasons. Assessing the compensation event uses the Schedule of Cost Components or Shorter Schedule of Cost Components depending on the option chosen, plus a properly quantified impact on the Accepted Programme. For project controls, compensation events are where schedule and cost discipline either work together or fail together. A compensation event quotation needs a defensible impact analysis on the programme (showing the effect on planned completion, Key Dates, and critical path), a cost quotation built up from the Schedule of Cost Components, and a clear audit trail linking the event to the change in the Accepted Programme. Weak compensation event management is visible in poorly-structured schedule impact analyses, missing what-if scenarios, and programmes that are not updated to reflect implemented events — each of which becomes a dispute surface later in the contract. --- ## NEC4 Early Warning URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-early-warning A contractual obligation under NEC4 to notify the other party of any matter that could affect price, completion, Key Dates or performance — designed to surface problems while they can still be managed. The NEC4 Early Warning clause requires either the Contractor or the Project Manager to notify the other as soon as they become aware of any matter that could increase the total of the Prices, delay Completion, delay meeting a Key Date, or impair the performance of the Works in use. The notification goes onto the Early Warning Register, and a joint meeting must be held within two weeks to discuss mitigation options. The mechanism is distinct from the compensation event process: an early warning is about a potential issue; a compensation event is a specific contractual entitlement once an event has occurred. The commercial significance of the Early Warning is that a Contractor who fails to raise one — when they should have done — can have the assessment of a subsequent compensation event reduced on the basis that earlier notification would have allowed the impact to be mitigated. This creates a strong incentive to raise warnings promptly, even where the event may turn out to be immaterial. The Project Manager has the same obligation in reverse. In practice, the Early Warning Register is one of the best live indicators of programme health on an NEC4 contract. A Register with regular entries and active mitigation discussion suggests a well-functioning contract relationship. A Register that is empty, stale, or populated only when a problem is already unavoidable is usually a signal of broken trust or weak contract discipline — and a predictor of late-stage dispute. Project controls teams should be tracking Early Warnings as a leading indicator alongside schedule and cost metrics. --- ## QSRA (Quantitative Schedule Risk Analysis) URL: https://www.somaprojectcontrols.com/resources/glossary/qsra-quantitative-schedule-risk-analysis A Monte Carlo simulation of a project schedule that produces a probability distribution of completion dates, rather than a single deterministic forecast. Quantitative Schedule Risk Analysis (QSRA) applies Monte Carlo simulation to a project schedule to produce a range of possible completion dates with associated probabilities. The typical output is an S-curve showing the likelihood of completion on or before any given date, with specific reference points at P50 (median, the date the project has a 50% probability of finishing by), P80 (80% probability) and P95 (95% probability). Rather than asking "when will this project finish?", QSRA asks "with what confidence can we say it will finish by date X?" — a fundamentally more honest question on programmes with material uncertainty. The difference between QSRA and a generic Schedule Risk Analysis (SRA) is the word quantitative. An SRA might be a qualitative review of risks against the schedule, or a deterministic what-if analysis of a few scenarios. QSRA is specifically the Monte Carlo simulation — typically tens of thousands of iterations across the network — that produces a true probability distribution. In UK practice, when buyers ask for an SRA on an infrastructure or defence programme they almost always mean a QSRA; the terms are used interchangeably in everyday usage but the formal AACE definition reserves "QSRA" for the Monte Carlo method. A QSRA requires three inputs that a deterministic schedule does not. First, three-point estimates on activity durations: a minimum, most-likely, and maximum duration for each activity, capturing the inherent uncertainty in how long that work will actually take. The shape of the distribution between those three points matters — triangular, beta-pert, and lognormal are the common choices, each with different tail behaviour. Second, discrete risk events mapped from the project risk register to the activities they would impact if they occur, with their own probability and impact distributions. Third, correlation structure between activities that do not move independently — a labour shortage affects multiple activities simultaneously, a regulatory delay affects every downstream approval — and these correlations have to be specified explicitly because the default of zero correlation almost always understates the spread. The model output is the S-curve plus a tornado chart showing which activities and risks drive the variance. The S-curve tells the sponsor the confidence position; the tornado tells the project manager where to focus mitigation. A QSRA without an interpretable tornado chart is delivering only half its value — sponsors want a number, but the project team needs to know which inputs they can act on. On UK programmes the leading QSRA tools are Safran Risk (purpose-built for QSRA, integrates natively with Primavera P6, dominant on rail and nuclear), Primavera Risk Analysis (formerly Pertmaster, still in widespread use but on Oracle extended support — security fixes only, no new features), Acumen Risk by Deltek (handles integrated cost-schedule QCSRA in the same workbench), and @Risk by Palisade (Excel-based, more common in cost-led QCRA contexts but used for QSRA on smaller schedules). The choice of tool is far less important than the calibration of the inputs and the discipline of the methodology — a well-run @Risk model produces better results than a poorly-run Safran model. The AACE Recommended Practices that codify QSRA methodology are RP 57R-09 (Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model), RP 113R-20 (Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value), and RP 123R-22 (Determining Project Cost and Schedule Contingencies Using Expected Value and Statistical Methods). Where QSRA is most valuable is at gateway decisions — project sanction, funding approval, major baseline re-set — where the sponsor needs a defensible view of confidence rather than a single optimistic headline. UK infrastructure and major programmes typically require QSRA aligned to HM Treasury Green Book standards (paragraphs 6.72-6.84) and IPA Cost Estimating Guidance, particularly at OBC and FBC business cases. On NEC4 contracts, the Accepted Programme requirements under Clauses 31 and 32 — explicit Time Risk Allowances against a planned completion that sits inside the contractual completion date — make quantitative schedule thinking effectively contractual on any non-trivial NEC4 programme. A worked example clarifies the mechanics. Take a £200m rail station rebuild on a 30-month programme. The deterministic critical path runs through deck-construction (18 months), platform-finishes (5 months), then signalling-commissioning (4 months) with three months of float to the contractual completion. The QSRA inputs: three-point durations on each activity (e.g. deck-construction 16/18/22 months reflecting weather, possession-access and existing-services discovery uncertainty); discrete risks including a 30% probability of an unforeseen contaminated-ground event adding 2-4 months, a 20% probability of signalling-system integration issues adding 3-6 months, a 15% probability of a possession-curfew change costing 1-2 months; correlation between deck-construction durations and platform-finishes (shared weather exposure, same supply chain). Running 50,000 Monte Carlo iterations produces an S-curve with P50 = month 31, P80 = month 33.5, P95 = month 35. The deterministic 30-month plan has a 35% probability of being met. The contractual completion at month 33 has a 70% probability. The contractor needs to defend a P80 finish, which means accepting a 3.5-month sensitivity beyond the deterministic plan. Common QSRA failures cluster around three problems. First, three-point estimates that come out of the workshop without calibration — practitioners guess at minimums and maximums without reference to comparable benchmark data, and the resulting spread is either implausibly tight or arbitrarily wide. Second, correlation that is set to zero across the board for convenience; this almost always understates the spread because real projects bunch risks around common causes. Third, the discrete risk register being copy-pasted from a template rather than built from delivery experience on this specific programme — generic risks produce generic results that the experienced reader recognises immediately. A defensible QSRA addresses all three: calibrated three-point estimates against benchmark data, explicit correlation structure based on the actual programme, and a risk register built from the specific delivery context. QSRA done well becomes a governance tool that persists through delivery. The model is re-run at each major milestone or compensation event, the inputs are updated as the risk register evolves, and the confidence position is reported in steering-group packs alongside CPI/SPI metrics. QSRA done badly becomes a one-off document produced for a gateway, ages out within a quarter, and is forgotten by the project team. The difference is the maintenance discipline — and a project controls function that owns the QSRA as a live tool rather than a deliverable. SOMA delivers QSRA to AACE International recommended practices, structured to satisfy IPA and client-side assurance scrutiny and designed to remain useful through delivery rather than ending at gateway approval. ### Frequently asked questions **What does QSRA stand for?** QSRA stands for Quantitative Schedule Risk Analysis. It is a Monte Carlo simulation applied to a project schedule that produces a probability distribution of completion dates — typically reported as P50 (median), P80 (80% confidence) and P95 (95% confidence). The output is an S-curve showing the likelihood of finishing on or before any given date, rather than a single deterministic forecast. **What is the difference between QSRA and SRA?** An SRA (Schedule Risk Analysis) can be qualitative — a review of risks against the schedule — or deterministic — a few what-if scenarios. QSRA is specifically the quantitative Monte Carlo simulation that runs tens of thousands of iterations to produce a true probability distribution. In UK practice the terms are often used interchangeably when buyers ask for an SRA on an infrastructure or defence programme they usually mean QSRA, but the formal AACE definition reserves "QSRA" for the Monte Carlo method. **What inputs does a QSRA need?** Three inputs that a deterministic schedule does not require. First, three-point estimates (minimum / most-likely / maximum) on activity durations, capturing inherent duration uncertainty. Second, discrete risk events from the risk register, mapped to the activities they would impact, with their own probability and impact distributions. Third, correlation structure between activities that do not move independently — labour, weather, supply chain and regulatory factors typically create correlation that has to be specified explicitly because the default of zero correlation understates the spread. **What software is used for QSRA in the UK?** The leading tools on UK programmes are Safran Risk (purpose-built for QSRA, integrates with Primavera P6, dominant on rail and nuclear), Primavera Risk Analysis (formerly Pertmaster, still widely used on legacy programmes but on Oracle extended support — security fixes only), Acumen Risk by Deltek (handles integrated QCSRA in the same workbench), and @Risk by Palisade (Excel-based, more common in cost-led QCRA contexts). Tool choice is less important than calibration discipline. The AACE Recommended Practices that codify the methodology are 57R-09, 113R-20 and 123R-22. **When does a project need a QSRA?** QSRA is required when the sponsor or funder needs a defensible confidence position on the completion date — most commonly at project sanction, funding approval, gateway business cases (OBC/FBC), or after a major baseline re-set. UK infrastructure and defence programmes typically require QSRA aligned to HM Treasury Green Book (paragraphs 6.72-6.84) and IPA Cost Estimating Guidance. On NEC4 contracts, the Clause 31/32 requirements for explicit Time Risk Allowances make quantitative schedule thinking effectively contractual on any non-trivial NEC4 programme regardless of project size. **How do you tell if a QSRA is well-run?** Six tests. First, three-point estimates are calibrated against benchmark data rather than guessed in the workshop. Second, correlation is modelled explicitly (zero correlation across the board is almost always wrong). Third, the risk register has been built from the specific delivery context rather than copy-pasted from a template. Fourth, the output distribution is asymmetric (right-skewed) rather than narrow and symmetric — most real cost and schedule distributions are right-skewed. Fifth, the tornado chart is interpretable and identifies a small number of dominant variance drivers (if every input contributes equally, the model is generic). Sixth, the QSRA has been peer-reviewed by someone independent of the team that built it. --- ## QCRA (Quantitative Cost Risk Analysis) URL: https://www.somaprojectcontrols.com/resources/glossary/qcra-quantitative-cost-risk-analysis A Monte Carlo simulation of a project cost estimate that produces a probability distribution of outturn cost, rather than a single deterministic figure. Quantitative Cost Risk Analysis (QCRA) applies Monte Carlo simulation to a project cost estimate to produce a range of possible outturn costs with associated probabilities. The output is typically an S-curve showing the probability of coming in on or under any given cost, with reference points at P50 (median), P80 and P95. The technique tells sponsors what level of contingency is required to achieve a specified confidence of not exceeding a budget, rather than relying on a deterministic point estimate plus an arbitrary percentage uplift. A QCRA requires three-point estimates on cost line items (modelling estimating uncertainty), discrete risk events with probability and cost impact distributions (modelling risks that might materialise), and escalation assumptions modelled with their own uncertainty for long-duration projects. The analysis separates base estimate uncertainty from discrete risk events so that the client can see how much of the P80 position is driven by "the estimate is rough" versus "these specific risks might hit." Both contribute to contingency sizing but require different management approaches. QCRA exists because deterministic cost estimates systematically understate the real cost distribution. A point estimate is the most-likely figure; the actual outturn distribution is right-skewed (more upside exposure than downside), which means the mean outturn cost is typically higher than the most-likely figure and the P80 is significantly higher than both. A traditional approach of taking the base estimate and adding a fixed percentage contingency (often 10% or 15%) loses sight of where the risk actually sits in the estimate, and produces a contingency figure that is either too low when the risk is genuinely material or unnecessarily high when the estimate is well-bounded. QCRA replaces the fixed-percentage convention with a distribution-aware contingency position. The shape of the three-point distribution matters. Triangular and beta-pert are the most common choices on UK capital projects, with the choice reflecting how informative the most-likely figure is relative to the bounds. Correlation between cost elements that move together must be specified explicitly: materials inflation affects every materials-based line item, regulatory cost adders affect every related work package, and the default of zero correlation almost always understates the spread. The output is an S-curve plus a tornado chart of variance drivers. The S-curve gives the sponsor the confidence position at P50, P80 and P95. The tornado tells the project team which line items and discrete risks drive the variance. A QCRA without a tornado is delivering only half its value because sponsors want a contingency number but the project team needs to know what is driving it. AACE Recommended Practice 57R-09 (Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model), 113R-20 (Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value), and 123R-22 (Determining Project Cost and Schedule Contingencies Using Expected Value and Statistical Methods) are the methodology references that UK programmes typically align to. The leading tools are @Risk by Palisade (Excel-based, dominant in UK cost-focused QCRA work, handles probabilistic dependencies cleanly), Oracle Crystal Ball (also Excel-based, less common in UK practice), Acumen Risk by Deltek (handles cost and schedule in one workbench when integrated QCSRA is needed), and Safran Risk (typically schedule-led but capable of cost work). Tool choice is far less important than the calibration of the inputs and the discipline of the methodology. A worked example clarifies the mechanics. Take a £250m water-treatment-works upgrade. The deterministic base estimate is built up from material quantities (£90m), labour (£60m), preliminaries (£25m), design and supervision (£15m), commissioning (£10m), and contractor profit (£50m). The QCRA inputs: three-point estimates per WBS line (e.g. materials 80/90/110, capturing commodity-price uncertainty over the build period); discrete risks including a 40% probability of contaminated-ground discovery costing £8-20m, a 25% probability of a tender-market shift adding £15-30m to materials and labour combined, a 20% probability of a regulatory consenting delay adding £3-8m in preliminaries; correlation between materials and contractor profit (shared exposure to commodity prices and overhead margins). Running 50,000 Monte Carlo iterations produces an S-curve with P50 = £262m, P80 = £288m, P95 = £315m. The deterministic £250m has a 38% probability of being met. Contingency at P80 is £38m (15.2% of base estimate), of which £14m is from estimating uncertainty in the base lines and £24m is from the three discrete risks, a level of decomposition that lets the project team manage contingency drawdown by category rather than as a single bucket. Common QCRA failures cluster around three problems. First, no separation of base estimate uncertainty from discrete risk events, so the analysis double-counts where line items already have contingency baked into rates that is then duplicated in the three-point distribution. Second, zero correlation across the board for convenience, which understates the spread because real projects bunch risks around common causes. Third, a risk register copy-pasted from a template with generic risks that produce generic results, which the discriminating reader recognises in seconds. A defensible QCRA separates base estimate uncertainty from discrete risks cleanly, specifies correlation explicitly with reasoning, and uses a risk register built from this specific programme's delivery experience. QCRA is most useful when the sponsor needs to make a funding decision that must stand up to scrutiny — HM Treasury Green Book business cases, IPA gate submissions, investment committee papers, and board-level capital approval. A QCRA that produces a P80 cost position the client can defend is worth considerably more than a QCRA that produces a number the investment team finds uncomfortable and therefore ignores. The discipline of the method — AACE-standard three-point estimates, transparent assumptions, explicit correlation — is what makes the output defensible. ### Frequently asked questions **What does QCRA stand for?** QCRA stands for Quantitative Cost Risk Analysis. It is a Monte Carlo simulation applied to a project cost estimate that produces a probability distribution of outturn costs, typically reported as P50 (median, 50% probability of not exceeding), P80 (80% probability), and P95 (95% probability). The output is an S-curve showing contingency requirement at any given confidence level, rather than a deterministic point estimate with a fixed-percentage uplift. **What is the difference between QCRA and QSRA?** QCRA is Quantitative Cost Risk Analysis, a Monte Carlo simulation of the project cost estimate to produce a probability distribution of outturn cost. QSRA is Quantitative Schedule Risk Analysis, a Monte Carlo simulation of the project schedule to produce a probability distribution of completion dates. Many programmes need both, run jointly as Integrated Cost-Schedule Risk Analysis (QCSRA) so that schedule risks correctly drive their cost consequences (delay-related preliminaries, escalation, finance costs). **What inputs does a QCRA need?** Three inputs. First, three-point estimates on cost line items (minimum / most-likely / maximum), capturing estimating uncertainty in the base estimate. Second, discrete risk events from the project risk register, with probability and cost impact distributions, mapped to the cost lines they would impact. Third, correlation structure between cost elements that move together. Materials inflation affects every materials line, regulatory cost adders affect every related package, and zero correlation across the board almost always understates the real spread. **How is QCRA contingency different from a fixed-percentage contingency?** A fixed-percentage contingency (e.g. 10% or 15% of base) is a convention that loses sight of where the risk actually sits in the estimate. QCRA contingency is the difference between the base estimate and the P80 (or other target) confidence position from the Monte Carlo run, a figure derived from the specific risks and uncertainties on this project. QCRA contingency can also be decomposed: at P80, how much is driven by estimating uncertainty in base lines versus how much is driven by discrete risk events. This decomposition lets the project team manage contingency drawdown by category rather than as a single bucket. **What software is used for QCRA in the UK?** The leading tools are @Risk by Palisade (Excel-based, dominant in UK cost-focused QCRA work), Oracle Crystal Ball (also Excel-based, less common in UK practice), Acumen Risk by Deltek (handles cost and schedule in one workbench, useful for integrated QCSRA), and Safran Risk (typically schedule-led but capable of cost work). Tool choice is less important than calibration discipline. The methodology reference standards are AACE International Recommended Practices 57R-09, 113R-20 and 123R-22. **When does a project need a QCRA?** QCRA is required when the sponsor needs to make a funding decision that must stand up to scrutiny. The common triggers are: setting contingency for a funding submission, satisfying HM Treasury Green Book expectations for risk and optimism-bias adjustment on high-cost / high-risk proposals, satisfying the IPA Cost Estimating Requirements for confidence ranges at SOC / OBC / FBC stage gates, board-level capital approval where the investment committee needs a defensible contingency figure, MoD CADMID Concept and Assessment-phase business cases, and SSRO non-competitive contract baseline-profit submissions. **What does a P80 QCRA position mean?** A P80 QCRA position is the cost figure at which the project has an 80% probability of completing on or below, and a corresponding 20% probability of exceeding. It is the most common UK convention for funding upper-bound sensitivity (although the IPA does not formally mandate P80, its written requirement is for the central estimate to be P50, with the confidence range expressed as percentage bands around the Anticipated Final Cost). Funding at P80 means accepting that one in five projects funded at that level will overrun. On a portfolio of comparable projects, P80 funding produces under-spends on most and over-spends on a few, which is a defensible portfolio position if the over-spends can be absorbed. --- ## Integrated Cost-Schedule Risk Analysis (QCSRA) URL: https://www.somaprojectcontrols.com/resources/glossary/integrated-cost-schedule-risk-analysis A single Monte Carlo model that analyses schedule and cost risk together, capturing the way schedule slip drives prolongation cost and cost pressure drives schedule compression. Integrated Cost-Schedule Risk Analysis (sometimes called QCSRA) combines QSRA and QCRA into a single model so that the dependencies between time and cost risk are captured explicitly. The central insight is that schedule risk and cost risk are not independent: extended programme duration drives extended preliminaries cost, ongoing site overheads, and potential liquidated damages; cost overruns drive pressure to compress schedule, often introducing schedule risk of their own. Analysing the two separately consistently understates the joint risk position. An integrated model typically uses Safran Risk, Primavera Risk Analysis or @Risk with integrated cost-schedule capability. Activities carry both duration and cost uncertainty; discrete risk events can impact either duration, cost, or both; and the simulation runs the network so that a delayed critical path automatically extends cost-loaded activities and adds the associated time-related cost. The output is a bivariate distribution showing the joint probability of different time and cost outcomes. The practical value of an integrated model is that it produces a coherent confidence position. A sponsor asking "what is the P80 cost if we also need P80 confidence on time?" cannot be answered by running two separate models — the true joint P80 is higher than either individual P80 taken alone. AACE International Recommended Practice 57R-09 describes the method in detail. On UK infrastructure programmes where both time and cost confidence are governance-critical, integrated cost-schedule risk analysis is the standard for rigorous QRA work. ### Frequently asked questions **What is QCSRA (Integrated Cost-Schedule Risk Analysis)?** QCSRA — sometimes shortened to ICSRA or CSRA — is a Monte Carlo model that analyses schedule and cost risk together in a single integrated simulation. It captures the dependencies between the two: schedule slip drives prolongation cost (preliminaries, site overheads, liquidated damages) and cost pressure drives schedule compression. AACE International Recommended Practice 57R-09 describes the methodology. **What is the difference between QCRA, QSRA and QCSRA?** QCRA (Quantitative Cost Risk Analysis) models cost uncertainty alone — three-point estimates on cost lines plus discrete risk events with cost impact. QSRA (Quantitative Schedule Risk Analysis) models schedule uncertainty alone — three-point estimates on activity durations plus discrete risk events with schedule impact. QCSRA (Integrated Cost-Schedule Risk Analysis) combines both into a single model so the time-cost dependencies are captured explicitly. Two separate models consistently understate the joint risk position. **Why use QCSRA instead of QCRA and QSRA separately?** Schedule and cost risk are not independent. Extended programme duration drives time-related cost. Cost overruns drive schedule compression decisions that introduce their own risk. Running QCRA and QSRA as separate models loses these interactions. The true joint P80 (the cost AND schedule a sponsor can be 80% confident in) is higher than either individual P80 taken alone — and that's the number that matters for governance. **What tools do QCSRA models run in?** Safran Risk, Primavera Risk Analysis (formerly Pertmaster), @Risk, and Acumen Risk all support integrated cost-schedule modelling. Activities carry both duration and cost uncertainty; discrete risks can impact duration, cost, or both; and the simulation runs the network so delayed critical path activities automatically extend cost-loaded preliminaries. Tool choice depends on contract requirements (some clients specify Safran or PRA), team capability, and integration with the planning environment. --- ## Rolling Wave Planning URL: https://www.somaprojectcontrols.com/resources/glossary/rolling-wave-planning A progressive-elaboration planning technique where near-term work is planned in detail and later work is kept at summary level until scope becomes clearer. Rolling wave planning recognises that on most projects, the scope of work eighteen months out cannot be planned at the same level of detail as the work starting next week. The technique structures the programme in waves: near-term activities (typically the next three to six months) are planned at detailed task level with realistic durations, logic and resources; medium-term activities are planned at a higher level of summary; and long-term activities are represented as placeholder blocks that will be decomposed as more information becomes available. The method is a deliberate response to the observation that attempting to plan all work in detail up-front produces false precision. A three-year detailed schedule built on assumptions that will not hold tends to generate variances in year two that are a function of bad planning rather than bad execution, and undermines the credibility of the schedule as a forecasting tool. Rolling wave planning accepts the uncertainty, manages it transparently, and re-plans on a defined cadence as information improves. The discipline that makes rolling wave planning work is the re-planning cycle. Each wave must be decomposed to task level at a defined trigger point — typically some months before the work starts — and integrated into the main programme without disrupting the baseline structure. The higher-level summary activities need realistic duration and cost placeholders that are updated as the detailed plan develops. A programme that uses rolling wave planning but fails to re-plan on time, or that carries unrealistic placeholder durations, ends up with the worst of both worlds: neither a detailed plan nor a defensible summary. --- ## Look-Ahead Schedule URL: https://www.somaprojectcontrols.com/resources/glossary/look-ahead-schedule A short-range detailed schedule — typically two to six weeks — that extracts imminent work from the master programme for day-to-day site management and coordination. A look-ahead schedule is a near-term, high-resolution view of project activities extracted from the master programme. The most common variants are the two-week look-ahead (used for daily site management and subcontractor coordination) and the four-week look-ahead (used for medium-term resource planning and interface coordination). The look-ahead is a working tool for the field team, not a governance artefact — it is updated frequently, typically weekly, and used to manage day-to-day delivery rather than to report progress to the client. The value of a look-ahead schedule is that it bridges the gap between the master programme (which is too coarse for daily coordination) and the task-level work of individual site teams. A well-run look-ahead process makes interface risks visible before they become delays — the scaffold that needs to be up before the mechanical install can start, the design information that must be available before fabrication can be released, the permission to work that must be secured before the possession can be used. These details rarely appear on the master programme but determine whether the master programme actually delivers. The look-ahead also serves as an early warning mechanism for the master programme. When activities repeatedly fail to start or finish on their look-ahead dates, it is a strong signal that the master programme is drifting out of alignment with reality — and should trigger a programme update cycle before the variance becomes material at master-programme level. In NEC4 and other UK construction contexts, look-ahead disciplines are increasingly part of the programme management toolkit alongside the formal Accepted Programme. --- ## CADMID URL: https://www.somaprojectcontrols.com/resources/glossary/cadmid The UK MoD's six-phase acquisition lifecycle. For project controls practitioners — what each phase demands: QRA at Concept, EVMS at Manufacture, through-life cost tracking In-Service. CADMID is the acronym for the UK Ministry of Defence's six-phase project acquisition lifecycle: Concept, Assessment, Demonstration, Manufacture, In-Service, and Disposal. Every UK defence programme — from a communications refresh to a major platform acquisition — moves through these phases under a structured assurance framework that links each stage to specific gateway reviews, controls deliverables, and investment decisions. The six phases in sequence: Concept (defining the requirement and outline business case), Assessment (option analysis, risk reduction and full business case), Demonstration (development, integration and testing of the chosen solution), Manufacture (production, delivery and acceptance), In-Service (operational sustainment, often spanning decades), and Disposal (decommissioning, withdrawal and asset disposition). Each transition is governed by a Main Gate decision and, on Major Projects, by Infrastructure and Projects Authority (IPA) Gateway Reviews. For project controls practitioners, CADMID defines the shape of the controls requirement at each stage. Concept and Assessment are risk- and option-analysis intensive. Demonstration and Manufacture demand formal Earned Value Management and Performance Measurement Baseline control. In-Service controls focus on through-life cost tracking and sustainment. Disposal introduces its own regulatory and cost complexity. Understanding which CADMID phase a programme is in determines the appropriate controls structure and reporting framework. --- ## CADMID Lifecycle URL: https://www.somaprojectcontrols.com/resources/glossary/cadmid-lifecycle How CADMID's six phases shape the controls function — QRA and cost confidence at Concept, full EVMS at Manufacture, through-life cost tracking In-Service. Gateway tests and failure modes at each transition. CADMID is the acronym for the six phases of the UK MoD's project lifecycle: Concept, Assessment, Demonstration, Manufacture, In-Service, and Disposal. The framework governs how defence acquisition programmes are planned, assured and delivered, and each phase has specific deliverables, gateway reviews and project controls requirements. Unlike a generic capital project lifecycle, CADMID reflects the long operational life of defence equipment and the need for through-life management from concept to disposal — which can span forty years or more. Project controls requirements differ significantly across CADMID phases. Concept and Assessment phases are risk- and option-analysis heavy, with QRA focused on cost confidence of alternative solutions under high uncertainty. Demonstration and Manufacture phases introduce EVMS reporting, PMB baseline control and detailed schedule management, often to the standards specified in DEF STAN and contract reporting requirements. In-Service phase controls focus on through-life cost management and sustainment. Disposal phase introduces its own cost and regulatory complexity, particularly on platforms with radiological or environmental legacy. For project controls practitioners working in defence, understanding the CADMID phase is essential for sizing and structuring the controls function. The same programme can require lightweight analytical controls at Concept, heavy EVMS discipline at Manufacture, and framework-based sustainment controls In-Service. A controls approach designed for one phase will be the wrong shape for the next, and the transitions between phases are where controls functions most often fail to scale. SOMA delivers project controls into UK defence programmes across the CADMID lifecycle. --- ## IPA Gateway Review URL: https://www.somaprojectcontrols.com/resources/glossary/ipa-gateway-review A structured independent review of a UK public-sector major project by the Infrastructure and Projects Authority at defined decision points — testing deliverability, affordability and readiness to proceed. The UK Infrastructure and Projects Authority (IPA) conducts Gateway Reviews on major public-sector programmes at specified points in the lifecycle. The reviews test whether a programme is ready to proceed past the relevant gate — typically including strategic assessment (Gateway 0), business case (Gateway 1), delivery strategy (Gateway 2), investment decision (Gateway 3), readiness for service (Gateway 4) and benefits realisation (Gateway 5). Each review produces a Delivery Confidence Assessment rated from Green (high confidence) to Red (successful delivery appears unachievable), along with recommendations. Project controls evidence is central to how a programme performs at Gateway. The Gateway team will scrutinise the schedule baseline, cost estimate and QRA model; the risk register and its relationship to quantified exposure; the performance measurement baseline and how actuals are being reported; and the governance arrangements that ensure controls outputs actually inform decision-making. A programme with weak controls evidence — an unintegrated cost and schedule model, a risk register that does not reconcile to the QRA, a baseline that is not under change control — typically receives an Amber or Red rating regardless of how competent the delivery team appears. For the programme team, the value of a Gateway Review is not the rating itself but the specific recommendations that flow from it. Gateway reports are private to the Senior Responsible Owner, but the recommendations drive prioritisation of controls improvement work between gates. SOMA structures QRA and controls evidence to the standard that Gateway reviewers apply — AACE-compliant methodology, HM Treasury Green Book alignment, transparent assumption documentation — so that the controls function is ready for scrutiny rather than racing to be ready in the weeks before the gate. --- ## HM Treasury Green Book URL: https://www.somaprojectcontrols.com/resources/glossary/hm-treasury-green-book The UK government's guidance on appraisal and evaluation of policies, programmes and projects — setting the methodology that public-sector business cases, QRA and cost estimates must follow. The HM Treasury Green Book is the UK government's definitive guidance on how public-sector interventions should be appraised, evaluated and managed through delivery. It sets out the Five Case Model for business cases (Strategic, Economic, Commercial, Financial and Management), the approach to social cost-benefit analysis, the treatment of optimism bias, and the expected rigour of quantitative risk analysis supporting investment decisions. Any programme seeking public funding of material scale will have its business case and supporting analysis tested against Green Book expectations. For project controls practitioners, the most directly relevant sections are those covering optimism bias and risk management. The Green Book requires quantified optimism bias uplifts on capital cost estimates at early stages of project development, with the uplift reducing as the project matures and genuine uncertainty resolves. It also sets the expectation that QRA will be structured to produce defensible confidence levels (typically P50 for baseline and P80 for funding envelopes), with the methodology transparent and the assumptions documented. The Green Book works in tandem with the IPA's project assurance framework and departmental-specific guidance. A business case that complies with Green Book methodology, paired with a QRA that meets AACE International standards and an IPA Gateway process that tests delivery confidence, is the canonical UK public-sector project assurance stack. Programmes that attempt shortcuts — an underpowered QRA, missing optimism bias, or a business case that skips Green Book discipline — will typically encounter those shortcuts at Gateway review or at National Audit Office scrutiny later in delivery. --- ## AACE International URL: https://www.somaprojectcontrols.com/resources/glossary/aace-international The Association for the Advancement of Cost Engineering — the global professional body whose Recommended Practices are the reference standard for project controls, cost engineering and risk analysis. AACE International is the professional body for cost engineering and project controls globally, with its Recommended Practices (RPs) forming a de facto standard for how QRA, estimating, schedule analysis and EVMS should be conducted. The most relevant RPs for UK infrastructure and defence work include RP 57R-09 (Integrated Cost and Schedule Risk Analysis), RP 113R-20 (Integrated Cost and Schedule Risk Analysis Using Monte Carlo Simulation), RP 118R-21 (Project Risk Register Development) and RP 123R-22 (Risk Quantification Workshop). AACE holds three certifications relevant to senior project controls practitioners: the Decision and Risk Management Professional (DRMP), the Earned Value Professional (EVP) and the Certified Cost Professional (CCP). DRMP and EVP certifications in particular are increasingly expected on UK major programmes where the controls work must be demonstrably rigorous, particularly in defence, nuclear and public-sector infrastructure. The certifications are evidence-based — candidates must demonstrate both examination competence and a portfolio of project experience. In practical terms, citing AACE RPs in a QRA methodology or controls manual matters because it anchors the work to a published, externally-maintained standard rather than to individual consultant preference. A QRA report that says "we followed AACE RP 57R-09 and 113R-20" carries different weight in a Gateway review or investment committee than one that describes a bespoke methodology. SOMA's practitioners hold AACE chartership (DRMP and EVP), and SOMA QRA work is delivered to AACE Recommended Practices. --- ## SCL Delay and Disruption Protocol URL: https://www.somaprojectcontrols.com/resources/glossary/scl-delay-and-disruption-protocol The Society of Construction Law's guidance on managing and analysing delay and disruption claims on construction contracts — widely referenced in UK courts, adjudication and expert reports. The Society of Construction Law (SCL) Delay and Disruption Protocol, now in its second edition (2017), provides a framework for how delay and disruption claims should be managed and analysed on construction contracts. It covers core principles (entitlement, concurrency, float ownership, programme management), the analytical methods used in delay expert reports (as-planned vs as-built, time impact analysis, window analysis, collapsed as-built) and the evidential standards that claims and defences are expected to meet. While the SCL Protocol is not contractually binding on its own, it is widely adopted as best practice across UK construction, infrastructure and energy projects, and is routinely cited in adjudication, arbitration and High Court delay disputes. Expert witnesses producing delay reports will typically describe their methodology in SCL terms, and tribunals will test the analysis against SCL expectations. A delay analysis that departs from SCL methodology without justification will struggle to survive cross-examination. For project controls practitioners, the Protocol has two practical implications. First, programme management discipline during delivery — the quality of the Accepted Programme, the rigour of progress updates, the traceability of compensation events and variations — determines whether delay analysis can be carried out at all if disputes emerge later. Second, delay analysis requires specialist expertise: the difference between a time impact analysis that will stand up in adjudication and one that will not comes down to method selection, baseline hygiene, and evidential documentation. SOMA supports delay expert reports and provides controls evidence structured to the SCL Protocol standard. --- ## Earned Schedule (ES) URL: https://www.somaprojectcontrols.com/resources/glossary/earned-schedule-es A time-based extension of EVM that addresses the limitations of Schedule Variance and SPI once a project passes its planned completion date — giving a more reliable schedule performance measure late in delivery. Earned Schedule (ES) is a refinement of classical Earned Value Management that addresses a well-known limitation of the traditional SV and SPI metrics: as a project approaches and passes its planned completion date, SV converges to zero and SPI converges to 1.0 regardless of actual schedule performance. A project that is six months late will show SPI = 1.0 at the original planned completion date, because EV has caught up with PV in cost terms even though time has run out. ES replaces the cost-based view with a time-based one. The core ES insight is to measure schedule performance in time units rather than cost units. ES is the time at which the current EV value was planned to have been achieved. SV(t) = ES − AT (Actual Time) gives variance in time units (typically months or weeks), and SPI(t) = ES / AT gives schedule performance index in the same time-based framework. These metrics remain valid and informative throughout delivery, including after the planned completion date, making ES substantially more reliable for forecasting late in the project lifecycle. Earned Schedule is particularly valuable on long-duration or delay-prone programmes where traditional EVM metrics become unreliable in the final third of delivery. The method is supported in most commercial EVM software and is increasingly expected on UK defence and major public-sector programmes. The main pitfall is that ES inherits the weaknesses of the underlying EV measurements — if EV is being gamed, or the baseline is not properly structured, ES will not rescue the analysis. ES is a refinement on top of good EVM discipline, not a replacement for it. --- ## Risk Owner URL: https://www.somaprojectcontrols.com/resources/glossary/risk-owner The named individual accountable for managing a specific risk — responsible for monitoring it, implementing mitigation actions, and reporting status through the risk governance cycle. A Risk Owner is the single named individual accountable for a particular risk on a risk register. The role is not to eliminate the risk — many risks cannot be eliminated — but to ensure the risk is actively managed: monitored for changes in probability or impact, mitigated where possible through agreed actions, escalated when circumstances change materially, and reported through the governance cycle with accurate status. A risk without a named owner is, in practice, a risk that no-one is managing. Risk ownership has specific requirements to be meaningful. The owner must have sufficient seniority and authority to take or authorise the mitigation actions within their scope. A risk owned by a junior team member who cannot influence the mitigation is nominally owned but practically orphaned. The owner must also be close enough to the risk to detect changes early — typically someone with day-to-day visibility of the relevant area rather than a senior figure who sees risk only at monthly review. Common risk-ownership failures on UK infrastructure programmes include: collective ownership ("the delivery team" rather than a named individual), ownership by people who have since left the project, ownership by people who cannot authorise the mitigation budget required, and ownership at the wrong level (too senior to notice changes, or too junior to act). A well-run risk register is audited for these conditions on every update cycle, with ownership reassigned where the current allocation is not working in practice. --- ## Variability Risk vs Event Risk URL: https://www.somaprojectcontrols.com/resources/glossary/variability-risk-vs-event-risk Two distinct categories of risk in QRA: variability is the inherent uncertainty in how long something will take or how much it will cost; event risk is a discrete occurrence that may or may not happen. Good QRA methodology separates two fundamentally different kinds of uncertainty. Variability risk (also called estimating uncertainty or inherent uncertainty) is the range of plausible outcomes for something that definitely will happen: the duration of excavation work will fall somewhere between X and Y, the cost of a cabling package will land between A and B. Variability is modelled as a distribution applied to the base estimate itself — typically a triangular, PERT or BetaPERT distribution with low, most-likely and high values. Event risk is different in character: it is a discrete event that may or may not occur, and only applies to the estimate if it does. A ground conditions risk might have a 30% probability of materialising and a £1–5m cost impact if it does; 70% of the time the risk contributes nothing at all. Event risks are modelled as probability-weighted impact distributions attached to the activities or cost lines they would affect. The distinction matters because mixing the two produces misleading output. If estimating uncertainty is bundled into the risk register as if it were discrete events, the model double-counts uncertainty and overstates contingency. If discrete events are absorbed into wider variability distributions, the model loses the ability to identify the specific risks driving exposure and the top of the tornado chart becomes uninformative. AACE Recommended Practice 57R-09 and 113R-20 both emphasise keeping variability and event risk separated — and it is one of the clearest markers of whether a QRA has been built to a professional standard. --- ## Primavera P6 URL: https://www.somaprojectcontrols.com/resources/glossary/primavera-p6 Oracle's enterprise project and portfolio scheduling software — the standard scheduling tool on UK major infrastructure, defence and rail programmes. Primavera P6 (commonly just P6) is Oracle's enterprise-grade project scheduling and portfolio management tool. It is the de facto standard on UK major infrastructure programmes — Network Rail and HS2 supply chain contracts typically mandate it, as do National Highways programmes, large defence contracts and most multi-party NEC4 programmes above a certain size. It handles multi-project, multi-user working with resource levelling, EVMS reporting, schedule risk analysis integration and integration with Primavera Risk Analysis / Safran Risk for Monte Carlo analysis. P6's dominance on UK major programmes reflects both its capability and its ecosystem: planners with P6 experience are widely available, third-party tools (Acumen Fuse, Schedule Analyzer, Deltek Acumen Risk) integrate with P6 databases, and contractual reporting templates in rail, highways and defence are designed around P6 data structures. The main alternative — Microsoft Project — does not scale to the multi-project, enterprise-database environment that P6 is built for, and is typically confined to smaller single-contract projects. For organisations that must work in P6 because of a contractual requirement or client standard, the main risks are shallow expertise (treating P6 as a drawing tool rather than a network planning tool), database hygiene (multiple uncontrolled copies of the same project drifting apart), and user-role management (too many people with edit rights, no discipline around baselining). SOMA delivers Primavera P6 scheduling on live UK infrastructure programmes and runs Primavera P6 training for planners transitioning onto contracts where the tool is required. --- ## Safran Risk URL: https://www.somaprojectcontrols.com/resources/glossary/safran-risk An enterprise-grade schedule and cost risk analysis tool widely used on UK defence, nuclear and infrastructure programmes for Monte Carlo QRA against integrated Primavera P6 or Microsoft Project schedules. Safran Risk is a specialist Monte Carlo risk analysis tool that operates against an imported Primavera P6 or Microsoft Project schedule. It supports integrated cost and schedule risk analysis (QCSRA), variability and event-risk modelling separately, correlation structures between activities and risks, and the production of tornado-chart sensitivity analysis alongside the headline P50/P80/P95 outputs. It is widely used on UK major programmes where rigorous QRA is a contractual or assurance requirement, particularly in defence, nuclear and rail. Safran Risk's core strength is that it preserves the logic and resource structure of the source schedule during the simulation — so the Monte Carlo results reflect the actual network rather than a simplified abstraction. It handles large schedules well, supports scenario and sensitivity analysis, and integrates risk register data so that the link between the qualitative register and the quantitative model is explicit. For assurance purposes, this traceability is what allows a reviewer to test whether the QRA is consistent with the narrative risk register, rather than the two telling different stories. Alternatives in the same category include Primavera Risk Analysis (formerly Pertmaster, now discontinued by Oracle), Acumen Risk (Deltek), @Risk (Palisade) and Riskalyze. The choice between them is typically driven by client preference, team expertise and the specific features required — Safran Risk leads on schedule-centric QRA on live P6 programmes; @Risk is stronger on pure cost-risk modelling; Acumen Risk integrates with the rest of the Acumen suite. SOMA practitioners are experienced across multiple tools and match the tool to the engagement context. --- ## Float Ownership URL: https://www.somaprojectcontrols.com/resources/glossary/float-ownership The contractual question of who owns the slack in a project schedule — whether the Contractor can use float to absorb their own delays, or whether it belongs to the Client. Float (or schedule slack) represents the difference between the earliest and latest that a non-critical activity can happen without delaying the overall project. Float ownership is the contentious question of who can consume that float: if an Employer-caused delay pushes an activity deeper into its float, but the activity still finishes by the overall completion date, has the Contractor been delayed? If the Contractor causes delay that eats into their own float, can the Client claim the float back through a compensation event or change instruction? Different contracts handle float ownership differently. NEC4 treats float in the Accepted Programme as being available for the Project Manager to consume when assessing compensation events — meaning the Contractor's float is effectively shared. JCT contracts tend to be more Contractor-friendly on float ownership in silent cases, though this is increasingly addressed expressly. The SCL Delay and Disruption Protocol takes a principled view that neither party should benefit from float to the detriment of the other unless the contract says so explicitly, and recommends express contract drafting to avoid disputes. For project controls practitioners, the implication is that float is not a purely technical concept but a commercial one. A schedule with large amounts of concealed float — hidden through constraints, activity duration padding, or split activities — becomes a contractual exposure as much as a planning issue, because float ownership disputes depend on what float exists in the Accepted Programme at the relevant time. Transparent, properly-justified float is defensible; concealed float is an invitation to dispute. --- ## Risk Mitigation Plan URL: https://www.somaprojectcontrols.com/resources/glossary/risk-mitigation-plan A documented set of actions designed to reduce the probability or impact of a specific risk — linked to the risk register, owned by an accountable individual, and tracked for completion. A Risk Mitigation Plan is the set of specific actions that will be taken to reduce the probability that a risk materialises, reduce the impact if it does, or both. Good mitigation plans are concrete ("commission ground investigation on the Section B alignment by end Q2") rather than aspirational ("actively manage ground conditions risk"), owned by a named individual with the authority to deliver them, and tracked for completion on the same cadence as the risk register they belong to. Mitigation planning is where many risk registers fail in practice. A register that lists fifty risks with fifty plausible impacts, but mitigation columns full of phrases like "monitor closely" or "escalate as required", is a register that is not driving any actual change in the programme's exposure profile. The test of a real mitigation plan is whether, if a reviewer audited the programme against the register in three months' time, the actions would have been completed and the risk status would have measurably moved as a result. The relationship between mitigation planning and QRA is often under-managed. In principle, as mitigation actions complete, the corresponding risk probability or impact in the QRA model should reduce, and the confidence position should improve. In practice, QRA models are often re-run with the same risk inputs regardless of mitigation progress, producing a confidence position that ignores months of delivery team effort. A live QRA model paired with a live risk register and a live mitigation action log is the mark of a controls function that is operating as an intelligence capability rather than a reporting function. --- ## NEC4 Key Date URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-key-date A contractually-binding interim milestone under NEC4 — a point at which the Contractor must complete specific Condition for the Project Manager to be able to proceed with the next activity. A Key Date under NEC4 is a date by which the Contractor must have completed Conditions stated in the contract, so that the Client or another party can proceed with their own work. It is not the same as a milestone. A milestone is typically a status checkpoint; a Key Date is a contractually enforced completion obligation. Failing to meet a Key Date triggers financial consequences under the contract — specifically, the Client can recover the additional cost of the delay caused to other work that depended on the Key Date being met. Key Dates are used on multi-contractor programmes where the work of one contractor interlocks with another, and on programmes where the Client needs to enter the work site at defined points for their own activities. A typical example is a station refurbishment where Key Dates mark the completion of each platform back to operational state, enabling the train operator to resume service while the next platform is worked on. For project controls, Key Dates need to be treated with the same schedule discipline as the Completion Date — tracked explicitly, assessed for impact in every compensation event quotation, and visible in monthly reporting. A Key Date that slips without formal assessment is a commercial liability waiting to surface at dispute. The Accepted Programme should show every Key Date as a hard marker, and the schedule logic that drives each Key Date should be transparent and defensible. --- ## NEC4 Target Cost (Option C) URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-target-cost-option-c An NEC4 pricing option where the Contractor is paid actual cost plus Fee, with a target cost agreed up front and gain or pain shared between the parties based on the final outturn. NEC4 Option C is a target cost contract with activity schedule. The Contractor is paid their Defined Cost (actual cost as defined by the Schedule of Cost Components) plus a Fee. A target cost is agreed at contract signature, and at the end of the contract the difference between the target and the actual outturn is shared between the Contractor and Client according to a pain-gain share mechanism specified in the Contract Data. The intent of Option C is alignment: both parties benefit if the work is delivered under target (shared gain), and both bear some burden if it runs over (shared pain). Well-structured target cost contracts create a genuine collaborative dynamic where the Contractor has an incentive to seek efficiencies and the Client has an incentive to keep scope stable. Badly structured ones produce disputes about what constitutes Defined Cost, aggressive claims for target cost adjustment through compensation events, and pain-gain mechanisms that are too generous or too punitive. For project controls, Option C has specific implications. Cost reporting must distinguish clearly between Defined Cost (which flows to the Contractor directly) and any Disallowed Cost (which does not). The target cost must be adjusted for every implemented compensation event — the target "moves" as the scope changes, and failure to keep the target updated destroys the pain-gain calculation. And the QRA typically needs to produce confidence positions against both the target and the likely outturn, so the Client can assess their true cost exposure rather than relying on the nominal target alone. --- ## NEC4 Sectional Completion URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-sectional-completion A mechanism under NEC4 that allows the works to be handed over in defined Sections, each with its own Completion Date and associated rights and obligations, rather than as a single completion event. Sectional Completion under NEC4 divides the Works into defined Sections, each with its own Completion Date, delay damages provision (if applicable), and defects date. When a Section reaches Completion, the Client takes over that part of the Works while the rest of the project continues. It is widely used on programmes where partial handover has real commercial or operational value — infrastructure programmes where sections can enter service before the whole project finishes, buildings where floors or zones can be occupied progressively, or utilities programmes where assets can be commissioned in sequence. The contract needs explicit setup for sectional completion to work: Sections must be defined in the Contract Data, each with its Completion Date, delay damages rate and Key Dates if any. The Accepted Programme must show each Section's completion logic distinctly, and progress reporting must track each Section separately. Sectional completion is not a variation to be negotiated during delivery — it either was set up in the contract or it was not, and retrofitting it after signature typically requires a supplementary agreement. For project controls, sectional completion complicates schedule management because each Section has its own critical path, its own float regime, and its own risk profile. The QRA may need to produce separate confidence positions for each Section's Completion Date if the commercial consequences (delay damages, operational revenue loss) differ between them. Reporting packs typically show each Section as a distinct track, with consolidated overall Completion visibility also maintained. --- ## RIBA Plan of Work URL: https://www.somaprojectcontrols.com/resources/glossary/riba-plan-of-work The Royal Institute of British Architects' standard framework for the UK construction project lifecycle — defining eight stages from strategic definition through to in-use, each with its own outputs and gateway criteria. The RIBA Plan of Work is the UK construction industry's standard project lifecycle framework, setting out eight stages: Stage 0 Strategic Definition, Stage 1 Preparation and Briefing, Stage 2 Concept Design, Stage 3 Spatial Coordination, Stage 4 Technical Design, Stage 5 Manufacturing and Construction, Stage 6 Handover, and Stage 7 In Use. Each stage has defined core objectives, outputs and information exchanges, creating a consistent vocabulary used across architects, engineers, contractors, clients and project controls teams on UK projects. For project controls work, the RIBA stages correspond to different levels of estimate and programme maturity. Stage 2 Concept Design typically corresponds to AACE Class 4-5 estimates with wide confidence ranges; Stage 4 Technical Design corresponds to Class 2-3; post-Stage 4 construction pricing is typically Class 1. QRA at Stage 2 is structured to account for high inherent uncertainty; QRA at Stage 4 and beyond is expected to be materially tighter. Understanding where a project sits in the RIBA stages determines what confidence levels are realistic to claim. The RIBA Plan sits alongside the Government Soft Landings (GSL) framework and the CIC (Construction Industry Council) Scope of Services, with the three together providing the standard framework for building projects in the UK. Infrastructure projects often use sector-specific alternatives — HS2 Plan of Work, Network Rail GRIP, National Highways PCF — but the underlying logic of stage-gated lifecycle management is similar across all of them. --- ## FEED (Front-End Engineering Design) URL: https://www.somaprojectcontrols.com/resources/glossary/feed-front-end-engineering-design The engineering and design phase that follows concept development and precedes Final Investment Decision — typically when cost and schedule estimates are matured to Class 2-3 accuracy for project sanction. FEED (Front-End Engineering Design) is the project phase where concept-level engineering is developed into design sufficient to support a Final Investment Decision (FID). It is the standard terminology in energy, process, and offshore project delivery, though similar concepts exist across all sectors. During FEED, the scope is defined to the level where credible three-point cost and schedule estimates can be produced, risk registers are developed and quantified through QRA, and procurement strategy is established. The output of FEED is a FID-ready package: a defined scope, a baseline cost estimate (AACE Class 2-3 typically), a baseline schedule to the level needed for FID, a QRA producing P50 and P80 confidence positions, a risk register, and the contracting strategy. The investment committee uses this package to decide whether the project should proceed to execution. A FEED that produces a polished cost figure without supporting analytical depth — QRA, risk register, correlation treatment — is a FEED that does not support a defensible FID. For project controls, FEED is where most of the leverage is. Decisions made at FEED — scope definition, WBS structure, contracting model, baseline programme — determine what is practically possible to manage during execution. Controls capability brought in post-FID can optimise execution against the baseline but cannot correct structural weaknesses in how the project was set up during FEED. UK energy, offshore wind and industrial decarbonisation programmes in particular benefit from having project controls engaged actively through FEED rather than waiting until post-FID mobilisation. --- ## FID (Final Investment Decision) URL: https://www.somaprojectcontrols.com/resources/glossary/fid-final-investment-decision The formal commitment by a project sponsor to proceed with execution — the point at which capital is committed based on the FEED-stage cost, schedule and risk position. Final Investment Decision (FID) is the sanction gate at which a project sponsor formally commits the capital needed for execution. It is the most consequential single decision in the project lifecycle: up to FID, the project can be re-scoped, delayed, or cancelled with modest loss; after FID, the sponsor has made binding commitments to contracts, procurement and resources that are expensive to reverse. The analytical basis supporting FID — the FEED output, the QRA, the risk register, the contingency position — is therefore tested with particular rigour. For the sponsor, FID is where the confidence level discussion matters most. The P80 cost and schedule position at FID becomes the baseline against which all subsequent performance is judged; the confidence range at FID determines what contingency is committed. An FID made on a weak QRA — one where the risk inputs are insufficiently calibrated, where correlation is mishandled, or where optimism bias is under-treated — commits the sponsor to an execution phase where the confidence position they thought they had is not the position they actually have. UK major infrastructure programmes typically require multi-layered assurance before FID: internal sponsor review, external QRA assurance, IPA gateway review (for public-sector programmes), and in some sectors regulatory approval. Each layer tests the FEED output from a different angle. SOMA delivers independent QRA assurance specifically structured for FID support — reviewing the methodology, the risk register, the correlation treatment, and producing a defensible view of whether the headline confidence position is credible. --- ## AMP (Asset Management Period) URL: https://www.somaprojectcontrols.com/resources/glossary/amp-asset-management-period The five-year regulatory cycle within which UK water companies plan, fund and deliver capital investment, governed by Ofwat's price review process. The Asset Management Period (AMP) is the five-year regulatory cycle that governs UK water company capital investment. Each AMP runs from April 1 to March 31 five years later — AMP7 ran 2020-2025, AMP8 runs 2025-2030. Ofwat's price review process agrees the capital programme and associated customer tariffs at the start of each period, and water companies are then accountable for delivering that programme efficiently within the agreed funding envelope. The AMP structure has specific project controls implications. Capital programmes must be scoped, priced, sequenced and risked at the start of the period for regulatory submission; delivery must be tracked against the committed programme with visibility to Ofwat; and unspent or overspent capital at AMP end carries regulatory consequences. Water company controls functions are designed around this cycle — portfolio reporting formats, cost allocation structures, and assurance cadences all reflect Ofwat's regulatory expectations. For project controls practitioners working in UK water, understanding the AMP framework is essential. QRA on a water capital portfolio needs to produce confidence positions at portfolio level, not just individual project level, because the regulatory commitment is to the portfolio's total delivery. Scope and cost changes within an AMP need to be managed against the price review commitment, and the totex framework (combined capex and opex) that Ofwat uses to assess efficiency means cost reporting structures must support totex disclosure as well as internal cost management. --- ## Time Impact Analysis (TIA) URL: https://www.somaprojectcontrols.com/resources/glossary/time-impact-analysis A prospective or retrospective delay analysis method that inserts specific delay events into a schedule to assess their impact on planned completion — one of the SCL Protocol's preferred techniques. Time Impact Analysis (TIA) is a delay analysis method where a specific delay event is modelled as an activity in a contemporaneous copy of the Accepted Programme, and the resulting impact on Completion (or a Key Date) is measured by re-running the schedule. It is one of the methods recommended by the Society of Construction Law (SCL) Delay and Disruption Protocol for assessing the time impact of a specific delay event, particularly when applied prospectively as part of a compensation event or variation assessment. TIA is well-suited to contemporaneous delay assessment under NEC4 contracts, where compensation events require a defensible quantification of time impact at the point of assessment. The method: take the most recent Accepted Programme, insert the delay event as a logic-linked activity (or activities) with appropriate duration and logic, re-run the critical path, and measure the difference in planned Completion. Done properly, TIA produces an auditable impact quantification that links the specific event to the specific schedule consequence. The method has limits. Retrospective TIA — applied after the delay has occurred — can be undermined by the as-built path differing from the as-planned critical path. Concurrent delays introduce complexity that TIA does not resolve automatically. And TIA is only as good as the Accepted Programme it operates on: a schedule with weak logic, excessive constraints or unreliable float will produce a TIA result that does not reflect the actual delay. For complex delay disputes, TIA is often combined with window analysis or collapsed as-built methods rather than used alone. --- ## Window Analysis URL: https://www.somaprojectcontrols.com/resources/glossary/window-analysis A retrospective delay analysis technique that divides the project duration into sequential windows and tracks the critical path movement through each — isolating delay causation period by period. Window analysis is a retrospective delay analysis method that divides the project timeline into sequential periods (windows) — typically monthly or fortnightly — and analyses the movement of the critical path and Completion Date through each window. For each window, the analyst identifies which events drove critical path change, quantifying the delay impact per period and attributing causation. The technique is particularly effective at handling concurrent delays and shifting critical paths, which are both difficult for single-event methods like TIA to manage. By tracking critical path evolution across windows, window analysis can distinguish between delay caused by Contractor-controlled risks and delay caused by Employer-controlled risks, even when both occur in overlapping periods. The SCL Delay and Disruption Protocol discusses window analysis among the preferred methods for retrospective delay assessment. The practical requirement is good contemporaneous records: each window needs a reliable snapshot of the programme state at start and end, and the events occurring within each window must be identifiable and dated. Projects that have not maintained disciplined programme updates through delivery find window analysis difficult to apply credibly. The analysis also has a subjective component in how the windows are defined and how events within each window are attributed — which is why window analysis reports from different experts can produce different conclusions from the same underlying data. --- ## Concurrent Delay URL: https://www.somaprojectcontrols.com/resources/glossary/concurrent-delay The situation where two or more delay events — one caused by the Employer and one caused by the Contractor — affect the same period of project time, creating a disputed entitlement to time and cost. Concurrent delay occurs when an Employer-risk event and a Contractor-risk event both delay the same period of project time. Under English law, the treatment of concurrent delay is one of the most contested areas of construction contract practice. The conventional position — known as the Malmaison approach — is that the Contractor is entitled to an extension of time for the Employer-caused delay even if a Contractor-caused delay would have produced the same effect. But this is not universally applied, and contracts can (and increasingly do) include specific clauses that allocate concurrent delay risk differently. The distinction between concurrent delay (where both events are on the critical path simultaneously) and pacing delay (where the Contractor deliberately slows work to match an Employer-caused delay) is important in dispute. Pacing is generally not concurrent delay — the Contractor was not being delayed; they chose to match the pace. Getting this classification right typically requires detailed contemporaneous schedule evidence and is often where delay expert reports disagree. The SCL Delay and Disruption Protocol discusses concurrent delay at length and recommends express contract drafting on how it should be handled, because implicit treatment through default law produces disputes. For project controls, the practical implication is that delay records and schedule updates need to capture not just what happened but when each event became critical, so the analyst can determine whether the events were truly concurrent or sequential. Weak contemporaneous records make concurrent delay determination impossible to defend. --- ## Extension of Time (EOT) URL: https://www.somaprojectcontrols.com/resources/glossary/extension-of-time A contractual mechanism by which the Contractor's completion date is extended to reflect delays caused by Employer-risk events — protecting the Contractor from liquidated damages for excusable delay. Extension of Time (EOT) is the contractual mechanism by which the Contractor's obligation to complete by a specified date is extended because of delays caused by events for which the Employer bears risk. Without an EOT mechanism, any delay beyond the agreed Completion Date exposes the Contractor to liquidated damages, even if the delay was caused by the Employer — which would be commercially unreasonable. The EOT mechanism operates on the principle that the Contractor should not bear time risk for events outside their control, provided the event is properly notified and assessed. Different contracts handle EOT differently. Under NEC4, EOT is delivered through the compensation event process — the Project Manager assesses the time impact of a compensation event and adjusts the Accepted Programme's Completion Date accordingly. Under JCT contracts, EOT is a separate process with specified Relevant Events and a formal EOT application procedure. Under FIDIC, the Engineer assesses EOT under Sub-Clause 8.4. Each has its own notification requirements, assessment procedures and evidential standards. For project controls, EOT is where time management discipline becomes commercial. An EOT application supported by a defensible Time Impact Analysis and a clear audit trail of causation typically succeeds; an EOT application based on assertion or incomplete records does not. The difference is not whether the delay occurred — it is whether the records can prove the delay and its cause. Contractors who run disciplined contemporaneous records tend to succeed on EOT; those who reconstruct claims retrospectively tend to struggle. --- ## As-Built Schedule URL: https://www.somaprojectcontrols.com/resources/glossary/as-built-schedule A retrospective schedule showing what actually happened on a project — the real start and finish dates of every activity — used primarily for delay analysis and dispute evidence. An as-built schedule records the actual execution history of a project: when each activity actually started, when it actually finished, and what the critical path actually was through delivery. It is produced retrospectively, typically for delay analysis purposes, by updating a schedule with actual data from progress records, site diaries, correspondence, and other contemporaneous evidence. A well-constructed as-built can be overlaid against the Accepted Programme to show where and why the project diverged from plan. As-built schedules are the foundation of most retrospective delay analysis methods. Window analysis operates on sequential as-built snapshots; collapsed as-built (a variant) starts with the full as-built and removes specific delay events to assess their impact. The SCL Delay and Disruption Protocol recognises as-built-based methods as preferred for retrospective analysis, provided the as-built is itself defensible. The challenge with as-built schedules is data quality. On projects that maintained disciplined progress updates through delivery, constructing an accurate as-built is mostly an assembly exercise. On projects where progress was reported inconsistently or constraints were used to paper over slippage, the as-built has to be reconstructed from primary evidence — site diaries, photographs, delivery notes, inspection records — which is expensive and opens the resulting as-built to challenge. Running disciplined schedule updates throughout delivery is what makes as-built analysis feasible later. --- ## Disruption (vs Delay) URL: https://www.somaprojectcontrols.com/resources/glossary/disruption-vs-delay Disruption is loss of productivity on activities that still complete on time — distinct from delay, which extends project completion. Often claimed separately and requires different evidential approach. Delay and disruption are commonly grouped but are conceptually distinct. Delay is the extension of the project's Completion Date (or a Key Date) beyond what was planned, driven by events on the critical path. Disruption is the loss of productivity on activities that may not have been on the critical path — the work takes longer, costs more, and involves more resource than planned, even if the overall project still finishes on time. Disruption typically arises from events like interference with the Contractor's intended sequencing, poor site access, late design information, or excessive instructions. The financial impact manifests as lower productivity rates — an activity that was planned at 100m/day achieved 60m/day because of interference — rather than as straightforward delay days. Recovering disruption costs requires proof of the productivity loss, the cause, and the financial consequence: a different and generally more difficult evidential task than proving critical path delay. The SCL Delay and Disruption Protocol treats disruption explicitly and describes several analytical methods, including measured mile analysis (comparing productive periods against disrupted periods on the same project), industry productivity benchmarks, and modified total cost methods. Each has strengths and weaknesses, and the choice depends on what evidence the Contractor can produce. Projects where productivity was tracked contemporaneously have stronger disruption analysis available; projects where productivity was not tracked find disruption claims much harder to substantiate. --- ## Measured Mile Analysis URL: https://www.somaprojectcontrols.com/resources/glossary/measured-mile-analysis A disruption analysis technique that compares productivity during an undisrupted period of the same project against productivity during a disrupted period — isolating the productivity loss attributable to disruption. Measured mile analysis is a disruption analysis method that uses the Contractor's own productivity data on the same project as the baseline for what productive performance should look like. The analyst identifies a period of work that was not materially disrupted (the measured mile), calculates the productivity rate achieved during that period, and applies that rate to disrupted periods to quantify the productivity loss attributable to disruption. The strength of measured mile is that it avoids the need for external benchmarks or theoretical productivity standards — it uses the same Contractor, the same scope, the same conditions as the disrupted work, and lets the actual achieved productivity establish what the work could have delivered absent the disruption. This makes it harder to challenge than methods based on industry-standard productivity rates or Contractor estimate assumptions. The requirements are specific. There must be an identifiable undisrupted period of meaningful duration and similar scope to the disrupted period; productivity data must have been captured contemporaneously in both periods; and the analyst must be able to defend the comparability of the two periods against likely challenge. Where an undisrupted period cannot be identified — because the project was disrupted from the start — measured mile cannot be applied and alternative methods (industry benchmarks, earned value-based analysis) must be used instead. --- ## Time Risk Allowance (TRA) URL: https://www.somaprojectcontrols.com/resources/glossary/time-risk-allowance Duration added to specific activities in the Accepted Programme to allow for risk — held by the Contractor under NEC4 and distinct from generic float or schedule contingency. Time Risk Allowance (TRA) is a discrete duration added to specific activities in an NEC4 Accepted Programme to account for the risk of that activity taking longer than its most-likely duration. It is explicitly provided for under NEC4 Clause 31.2 and is intended to be a transparent representation of risk absorbed in the schedule — not hidden through constraint manipulation or duration padding. TRA is distinct from float. Float emerges from the schedule logic as the difference between earliest and latest possible timing for non-critical activities; TRA is deliberately added duration reflecting specific risk judgement. The Contractor owns TRA under NEC4 — it is their provision for risks they have identified — but the Project Manager can see it in the Accepted Programme because it is itemised transparently rather than concealed. The intent is to encourage honest risk management in the schedule. If the Contractor expects piling to take 40 days most-likely but sees material risk of slower progress, they should show 40 days of activity duration and 5 days of TRA rather than inflating the activity duration to 45 days. The transparent format makes the risk visible to the Project Manager and supports informed conversations about whether to mitigate, transfer or accept the risk — rather than everyone assuming the base duration is realistic when it actually contains hidden buffer. --- ## Project Controls Engineer URL: https://www.somaprojectcontrols.com/resources/glossary/project-controls-engineer A practitioner responsible for planning, cost management, risk analysis, and integrated reporting on a capital project or programme — typically chartered through APM, ACostE, AACE or IRM. A Project Controls Engineer is a specialist practitioner responsible for the controls function on a project or programme. The role typically covers some combination of planning and scheduling, cost management, risk analysis, progress measurement, and integrated reporting. At the senior level (Principal, Lead, or Head of), the role includes the design of the controls function itself — processes, standards, data models, governance — rather than just executing within an established framework. UK project controls engineers are typically chartered through one or more of: APM (Association for Project Management), ACostE (Association of Cost Engineers), AACE International (particularly DRMP, EVP, CCP certifications), IRM (Institute of Risk Management), or RICS (Royal Institution of Chartered Surveyors for cost-focused practitioners). Chartership is increasingly expected at senior levels, particularly on public-sector and regulated-sector programmes where evidenced professional competence is required by the procurement framework. The role varies significantly between organisations and sectors. On major defence and nuclear programmes, the Project Controls Engineer is a specialist focused on EVMS, QRA and schedule quality within a large controls team. On smaller capital projects, they often carry the full controls function — schedule, cost, risk, reporting — as a single accountability. On client-side advisory engagements, they provide independent assurance and capability uplift rather than day-to-day delivery. SOMA staff are senior Project Controls Engineers chartered through APM, ACostE, AACE and IRM, with UK infrastructure, defence, nuclear, energy and water sector experience. --- ## The Iron Triangle (Scope, Time, Cost) URL: https://www.somaprojectcontrols.com/resources/glossary/iron-triangle The classical project management model holding that scope, time and cost are interdependent — fixing any two constrains the third, and changing any one forces changes in at least one other. The Iron Triangle is the traditional model of project trade-offs: scope, time and cost are interdependent, and a project manager cannot fix all three independently. If scope is fixed, then time and cost move together; if time is compressed, then either scope reduces or cost increases; if cost is capped, then scope or time must flex. The model is a simplification — quality is often added as a fourth dimension, and real projects have more variables — but the core principle is usefully robust. For project controls, the Iron Triangle frames the contingency and confidence discussions. A programme that claims simultaneous P80 confidence on scope, time and cost is claiming something the triangle says is not coherent: if all three are fixed at P80, there is no residual flexibility to absorb any risk that materialises. The honest position is typically P80 on two of the three, with the third allowed to flex — and the sponsor should be explicit about which dimension is the flex. The Iron Triangle is also what makes pain-gain and target-cost contracts work: by constructing a commercial mechanism where time and cost trade against each other within a defined scope, the parties create an incentive structure that acknowledges the trade-off rather than pretending it does not exist. NEC4 Option C contracts are explicit about this; lump-sum fixed-price contracts often pretend the triangle does not apply and produce disputes when reality disagrees. --- ## Schedule Quality Metrics URL: https://www.somaprojectcontrols.com/resources/glossary/schedule-quality-metrics The broader discipline of assessing whether a programme schedule is fit to be relied upon — covering structural integrity, resource feasibility, baseline drift, probabilistic readiness and earned-value compatibility. DCMA 14 is the best-known framework, but only one entry point. Schedule quality metrics describe the broader discipline of assessing whether a programme schedule is fit to be relied upon for forecasting, control and investment decision-making. The DCMA 14-point assessment is the best-known framework, but it is one entry point into a wider set of dimensions that UK major projects routinely assess — including resource feasibility, baseline integrity over time, probabilistic readiness, earned-value compatibility, calendar discipline, and the integrity of the work breakdown structure. Different client organisations apply different combinations of these assessments depending on the contracting framework and the sector convention; a schedule that passes one client's quality bar can fail another's. On UK infrastructure programmes, schedule quality assessment is often shaped by client-specific frameworks rather than a single standard. Network Rail's project schedule quality requirements (specified within the GRIP and AfA frameworks) extend the DCMA checks with sector-specific tests for possession integrity, route-restriction handling and milestone density. HS2 imposes its own schedule submission criteria covering activity coding, calendar treatment of bank holidays, and constraint use. National Highways' Project Control Framework requires specific WBS conventions and resource-loading patterns. Sellafield's NEC4 schedule requirements layer further checks for time-risk allowance treatment and float distribution. A schedule that passes DCMA can still fail one of these client-specific frameworks, and planners working on multi-client portfolios end up running parallel quality assessments rather than relying on a single standard. Beyond the structural integrity that DCMA tests, several other dimensions matter for schedule quality and are checked using different tools or manual review. Resource quality covers whether the schedule's resource loading is feasible in light of available crews, plant and supply-chain lead times — a schedule with perfect logic but unachievable resource demand is not a defensible baseline. Probabilistic readiness covers whether the schedule is structured well enough to run a Quantitative Schedule Risk Analysis against it; many otherwise-passing schedules fail this test because they collapse into a single critical path with no preserved parallel work. Baseline integrity over time covers whether the live schedule still resembles the approved baseline — a programme that has drifted into an unrecognisable shape has lost its forecasting reference even if every individual activity passes DCMA. Earned-value compatibility covers whether the WBS aligns with the cost breakdown structure cleanly enough for meaningful EV reporting. Acumen Fuse remains the most widely-used schedule quality tool on UK programmes, and its scorecard module covers DCMA plus a wider set of metrics including logic density, resource loading quality, plan reliability and change volatility. Deltek Acumen Risk extends this with probabilistic readiness assessment. For organisations not licensed for Acumen, Steelray Project Analyzer and Schedule Inspector cover similar territory at lower cost. Many tier-1 contractor planning teams maintain their own internal schedule quality checklists implemented as Excel macros against Primavera P6 exports, calibrated to the specific client requirements on each contract. Schedule quality assessment is most commonly invoked at four moments: at baseline submission, where the baseline cannot be accepted without a defensible quality result; at major programme reviews or gateway assessments; when a new party is inheriting a schedule produced by another team, typically at contract handover or after a change of contractor; and ahead of a QSRA, where the Monte Carlo result is only as credible as the schedule structure underneath it. SOMA applies multi-framework schedule quality assessments routinely on independent assurance engagements, layering DCMA as the structural baseline with client-specific dimensions and probabilistic-readiness tests on top. The honest position is that no single framework catches everything; a layered approach catches more. ### Frequently asked questions **Is schedule quality the same as the DCMA 14-point assessment?** No. DCMA is one framework within the broader discipline of schedule quality assessment. DCMA tests structural integrity — logic, constraints, float distribution. Schedule quality more broadly also covers resource feasibility, baseline integrity over time, earned-value compatibility, and probabilistic readiness. These dimensions are tested with different tools or manual review and DCMA does not catch any of them. A schedule can pass DCMA cleanly and still be unfit to forecast against. **Does Network Rail use DCMA 14 for schedule quality, or its own framework?** Both. Network Rail's project schedule quality requirements within the GRIP and AfA frameworks extend DCMA with sector-specific checks for possession integrity, route restrictions and milestone density. In practice, planners on Network Rail programmes run DCMA first to establish structural integrity, then apply Network Rail's additional dimensions. Failing either layer is a problem at baseline submission, and the two are typically reported separately in the schedule quality summary. **What does Acumen Fuse measure beyond DCMA 14?** Acumen Fuse's scorecard module covers DCMA plus additional dimensions — logic density, resource loading quality, plan reliability and change volatility. Deltek Acumen Risk extends this further with probabilistic readiness assessment, which tests whether the schedule is structured well enough for a Quantitative Schedule Risk Analysis. For programmes not licensed for Acumen, equivalent capability is available in Steelray Project Analyzer and Schedule Inspector at lower cost. --- ## As-Planned Schedule URL: https://www.somaprojectcontrols.com/resources/glossary/as-planned-schedule The schedule showing what the project intended to do at a specific reference point — typically the baseline at contract signature, used as the starting point for delay analysis. The as-planned schedule is the version of the programme that represents the intended execution at a specific reference point — most commonly the baseline Accepted Programme at contract signature. It is the starting point against which actual execution is compared in delay analysis, either directly (as-planned versus as-built) or through more sophisticated methods like window analysis and time impact analysis. The as-planned schedule needs to be a proper network, not just a Gantt chart. Logic must be complete, activities must be traceable to scope items, and the critical path must be defensible. Delay analysis that uses an as-planned schedule with weak logic or undefended constraints will produce conclusions that do not survive challenge — because the as-planned does not actually represent what the project intended to do in a meaningful network sense. The SCL Delay and Disruption Protocol distinguishes between as-planned (the starting reference) and as-built (what actually happened) and describes how both are used in different delay analysis methods. The two are fixed reference points; the analytical methods operate on the space between them. Disciplined programme management during delivery — maintaining clean baselines, proper version control, and defensible logic — is what makes as-planned and as-built schedules useful for analysis later. --- ## CDM Regulations 2015 URL: https://www.somaprojectcontrols.com/resources/glossary/cdm-regulations The Construction (Design and Management) Regulations 2015 — UK statutory health and safety framework allocating design and management duties to Clients, Principal Designers, Principal Contractors and duty holders on construction projects. The Construction (Design and Management) Regulations 2015 — commonly "CDM 2015" — are the UK's principal statutory framework for health and safety management on construction projects. CDM allocates specific duties to the Client, Principal Designer, Designer, Principal Contractor, Contractor and Workers, with the intent that health and safety is designed into the project from concept rather than bolted on during construction. The regulations apply to all construction projects, with additional requirements (including notifiable project registration with HSE) for larger projects. For project controls, CDM is not a direct controls requirement but it shapes the project environment in ways that controls practitioners must understand. The Pre-Construction Information, the Construction Phase Plan and the Health and Safety File are CDM deliverables that intersect with schedule and cost controls — they are produced at defined lifecycle points, they have resource and cost implications, and late delivery can trigger enforcement action that affects programme. The more important implication is that CDM duties influence design sequence, construction methodology and risk allocation. A scheme that cannot be safely constructed as designed must be redesigned, and the cost and schedule consequences flow back into the project baseline. Controls practitioners working on UK construction need basic CDM literacy to understand why certain decisions are being made and to factor CDM-driven requirements into schedule logic and cost estimates. HSE guidance (L153) is the authoritative reference. --- ## Earned Value vs Earned Schedule URL: https://www.somaprojectcontrols.com/resources/glossary/earned-value-vs-earned-schedule Earned Value (EV) measures schedule performance in cost units and converges to zero at project end. Earned Schedule (ES) measures schedule performance in time units and stays meaningful through the entire project lifecycle. Earned Value Management produces two schedule metrics: Schedule Variance (SV = EV − PV) and the Schedule Performance Index (SPI = EV ÷ PV). Both express schedule performance in cost units. Earned Schedule (ES), introduced by Walt Lipke in 2003, converts schedule performance back into time by asking a different question — "at what point in the planned schedule should we have earned the value we've earned so far?" — and produces a parallel set of metrics in time units: SV(t) and SPI(t). The reason this matters is a well-known limitation of classical EVM. SPI and SV always converge to 1.0 and 0 respectively at project completion, regardless of whether the project finished early, on time, or six months late, because EV and PV both equal BAC at completion. A project that is six months late will, in its final report, show SPI = 1.0 — a blatantly wrong reading of schedule performance. Earned Schedule's SPI(t) does not have this convergence problem; it remains a faithful measure of schedule efficiency through the closeout phase. For UK infrastructure programmes that report monthly through the late stages of delivery, SPI(t) is the more honest metric. Most modern EVMS implementations now produce both — Earned Value figures for traditional cost-schedule integration, Earned Schedule figures for forward-looking schedule forecasting. AACE Recommended Practice 64R-11 covers both. Practitioners working on programmes where schedule completion is governance-critical (NEC4, MoD MPRP, IPA gateway) should be comfortable reading and producing both sets of metrics. ### Frequently asked questions **What is the difference between Earned Value and Earned Schedule?** Earned Value Management measures schedule performance in cost units (SV = EV − PV, SPI = EV ÷ PV). Earned Schedule converts these into time units (SV(t), SPI(t)) by asking when you should have earned the value you have earned. The practical difference is that classical EV's schedule metrics converge to zero/1.0 at project completion even on late projects, while Earned Schedule's time-based metrics remain meaningful through closeout. **Why does SPI become unreliable late in a project?** SPI = EV ÷ PV. As a project approaches completion, both EV and PV approach the Budget at Completion (BAC) — eventually they're equal, and SPI = 1.0 regardless of how late the project actually finished. This means a project six months overdue can report SPI = 1.0 in its final month. Earned Schedule's SPI(t) doesn't suffer from this — it expresses schedule performance in actual time units, so a six-month overrun shows as SPI(t) ≈ 0.85 even at closeout. **Should we use Earned Value or Earned Schedule on a UK infrastructure programme?** Both. Earned Value is the contractual / EVMS-mandated framework on NEC4 and MoD contracts and remains the default for cost-schedule integration. Earned Schedule is supplementary — most useful for forward-looking schedule forecasting, especially in the back half of the programme when SPI is no longer reliable. Many modern EVMS implementations produce both; reporting both keeps the client honest. **Who developed Earned Schedule?** Walt Lipke, who introduced the framework in a 2003 paper while at Tinker Air Force Base. The methodology has since been formalised in AACE International Recommended Practice 64R-11 ("CPM Schedule Risk Modelling and Analysis") and is now standard supplementary practice on major US DoD and UK MoD programmes. --- ## Critical Path vs Critical Chain URL: https://www.somaprojectcontrols.com/resources/glossary/critical-path-vs-critical-chain Critical Path Method (CPM) sequences activities by logic dependencies. Critical Chain Project Management (CCPM) extends CPM by also constraining for resource dependencies, treating shared resources as the binding factor. The Critical Path Method (CPM), developed in the 1950s, identifies the longest sequence of dependent activities through a project network. The critical path determines the project end date — any delay on it pushes completion. CPM treats activities as logic-linked but assumes resources are unlimited; if two parallel activities both need the same crane, CPM doesn't notice. The planner must apply resource levelling separately and accept that the levelled schedule may differ substantially from the unlevelled critical path. Critical Chain Project Management (CCPM), introduced by Eliyahu Goldratt in his 1997 book of the same name, addresses the resource-availability gap directly. The critical chain is the longest path through the project after both logic dependencies AND resource dependencies are accounted for. Two activities that aren't logically dependent but share a single critical resource (one welder, one crane) are treated as effectively sequential — and that constraint may produce a critical chain longer than the classical critical path. CCPM also reframes how buffer is managed. Rather than padding individual activities with hidden contingency (which CCPM theory says invariably gets consumed via Parkinson's Law and student-syndrome behaviour), CCPM strips activity estimates to ~50% confidence and aggregates the buffer at the end of feeding chains and at the project finish. The argument is that a single shared buffer absorbs variability more efficiently than many small individual buffers — a defensible statistical position, though one that requires significant cultural adjustment to implement. In UK practice, CPM remains the dominant approach: NEC4, P6, MS Project and the entire UK infrastructure controls profession are CPM-native. CCPM appears occasionally in pharmaceutical, R&D and aerospace contexts but is rare on construction and infrastructure. The most useful CCPM idea for CPM practitioners is the buffer concept — many sophisticated UK programmes now use a hybrid: CPM logic + aggregated programme-level contingency rather than activity-level padding. ### Frequently asked questions **What is the difference between Critical Path and Critical Chain?** The Critical Path is the longest sequence of activities in a project network when only logic (sequence) dependencies are considered — resources are assumed unlimited. The Critical Chain is the longest sequence when both logic AND resource dependencies are considered. If two parallel activities share a single crane, the Critical Path treats them as parallel; the Critical Chain treats them as effectively sequential because the crane can only be in one place at a time. **Is Critical Chain better than Critical Path?** Neither is strictly better — they answer different questions. CPM is the universal framework in UK infrastructure (NEC4, MoD, IPA, P6, MS Project) and is what your client and contractor will expect. CCPM has theoretical advantages around buffer management but requires a significant cultural shift and tools that don't fit the standard UK toolchain. The most pragmatic answer is to use CPM as the operating framework and borrow CCPM's buffer-aggregation idea (programme-level contingency rather than activity padding) where it fits. **Where does Critical Chain handle buffer differently?** Classical CPM allows padding inside each activity duration estimate — every planner adds their own contingency. CCPM theory argues this is wasteful because (a) Parkinson's Law: work expands to fill the time available, so padding gets consumed; (b) student syndrome: people start late if they have buffer, then run into the wall; (c) summing N individual safety margins is statistically less efficient than aggregating one project-level margin. CCPM strips activity estimates to a 50%-confidence median and places explicit buffers at chain joins and project end, where they act as a shared shock absorber. **Do UK NEC4 contracts use Critical Path or Critical Chain?** Critical Path. NEC4 Clause 31 (Accepted Programme requirements), the compensation event mechanism, and the assessment of delay all assume CPM as the underlying scheduling methodology. The Accepted Programme is a CPM logic network. Float (free, total, terminal) is a CPM concept. While there is nothing in NEC4 that explicitly forbids CCPM, every UK construction lawyer, contract administrator, and IPA reviewer expects to read a CPM schedule. --- ## Criticality Index URL: https://www.somaprojectcontrols.com/resources/glossary/criticality-index The percentage of Monte Carlo iterations in which an activity lies on the critical path. A probabilistic measure of how often an activity actually drives project completion, used in QSRA / risk-loaded schedule analysis. The criticality index is a probabilistic measure of how often an activity sits on the critical path across the iterations of a Monte Carlo schedule simulation. If 10,000 QSRA iterations are run and a specific activity lies on the critical path in 7,500 of them, its criticality index is 75%. The measure exists because the deterministic critical path — calculated once on a single set of point estimates — is only one of many possible critical paths the project could actually take, and the dominant one in deterministic terms is not always the one most likely to drive completion in reality. The interpretation that matters in practice: an activity with high criticality index is one the project team should be watching even if its deterministic total float looks comfortable. A path with 5 days of float on the deterministic plan can become critical the moment any of its activities slip past that float — and on a programme with material duration uncertainty, those slips happen often. The criticality index quantifies how often. An activity with 80% criticality index is on the critical path in 80% of plausible futures; whether it sits on the deterministic critical path today is almost irrelevant. Criticality index is most useful as a mitigation-prioritisation tool. The conventional approach of focusing only on activities with zero or near-zero total float (the deterministic critical and near-critical paths) misses risk-driving activities that live on what looks like a comfortable secondary path until a discrete risk event triggers them onto the critical chain. A risk-loaded schedule that ranks activities by criticality index pulls those into view — and Acumen Risk's variance analysis output, Safran Risk's sensitivity reports and Primavera Risk Analysis (Pertmaster) all expose the index by default. AACE Recommended Practice 64R-11 (Risk Analysis and Contingency Determination Using Expected Value) treats criticality index as a standard output of integrated cost-schedule QRA work. Common interpretation errors: First, criticality index is not the same as activity sensitivity. Sensitivity measures the statistical correlation between an activity's duration and the project end date; criticality measures the proportion of iterations in which the activity is on the critical path. These are related but distinct — an activity can be highly sensitive without ever lying on the critical path if its duration affects total cost rather than schedule. Second, criticality index doesn't tell you the magnitude of any delay; it tells you the frequency of the activity being on the critical path. A high criticality index combined with a low sensitivity score might mean the activity is on the critical path often but never drives meaningful delay; a low criticality index combined with high sensitivity might mean the activity rarely drives completion but when it does the impact is large. Both measures should be read together. Third, criticality is a function of the input distributions and risk register — change the three-point estimates or the discrete risks and the index changes. It is not a property of the schedule; it is a property of the simulation. Re-run the QSRA after any material baseline change and the criticality rankings should be re-checked. On UK programmes the most useful application of the criticality index is at the gateway review. A QSRA report that ranks the top 10 activities by criticality index, paired with the discrete risks driving each one, gives the gateway reviewer a defensible answer to the question 'what should the project team be watching?' — and avoids the trap of mitigation effort flowing only to whatever happens to be on the deterministic critical path the day the workshop ran. ### Frequently asked questions **What is the criticality index in QSRA?** The criticality index is the percentage of Monte Carlo iterations in which an activity lies on the critical path. Run a QSRA with 10,000 iterations; if an activity is on the critical path in 7,500 of them, its criticality index is 75%. The measure exists because the deterministic critical path is only one of many possible critical paths the project could actually take. **How is criticality index different from total float?** Total float is the deterministic measure — how much an activity can slip before pushing the project end date based on one set of point estimates. Criticality index is the probabilistic measure — how often the activity is on the critical path across many iterations. An activity with a comfortable-looking 5-day total float can have a high criticality index because that float is consumed quickly when activities on its path overrun in even a fraction of plausible futures. **What's the difference between criticality index and activity sensitivity?** Criticality index measures how often an activity sits on the critical path. Sensitivity (sometimes called duration sensitivity) measures the statistical correlation between the activity's duration and the project end date — how much each day of variation in the activity translates into days of variation in the completion. They're related but distinct. An activity can have high sensitivity without high criticality (it affects cost not schedule), or high criticality without high sensitivity (it's on the critical path often but rarely drives material delay). Both metrics should be read together. **What tools produce criticality index outputs?** All the major UK QSRA tools expose criticality index as a standard output: Safran Risk (under sensitivity analysis), Primavera Risk Analysis (formerly Pertmaster, in the criticality report), Acumen Risk (variance analysis output), and @Risk for Excel schedule add-ins. AACE Recommended Practice 64R-11 (Risk Analysis and Contingency Determination Using Expected Value) treats criticality index as a standard output of integrated cost-schedule QRA work. **How should a project team use criticality index?** Two main uses. First, mitigation prioritisation: focus protective effort on activities with high criticality index, not just the deterministic critical path — the former captures the activities that will drive completion in most plausible futures, the latter captures only today's snapshot. Second, gateway reporting: present the top 10 activities by criticality index alongside the discrete risks driving each one. This gives the gateway reviewer a defensible answer to 'what should the team be watching?' that doesn't depend on whatever path happened to be critical the day the workshop ran. --- ## Near-Critical Path URL: https://www.somaprojectcontrols.com/resources/glossary/near-critical-path A path through the project network with low (but non-zero) total float — close enough to critical that any slip on it can promote it to the critical path. DCMA 14-point assessment monitors activities with ≤7 working days of float as near-critical. A near-critical path is a sequence of activities whose total float is low but greater than zero — close enough to the critical path that a modest slip on any of its activities can push the path past the deterministic critical and make it the new driver of project completion. In practice, near-critical paths cause more programme overruns than the deterministic critical path does, because they go unwatched: the project team focuses on the zero-float critical path, an activity on a near-critical path slips by a few days, and the previously-comfortable secondary path silently becomes the new critical chain. The DCMA 14-point assessment treats activities with 7 working days or less of total float as near-critical for monitoring purposes. The threshold reflects the working assumption that anything inside two working weeks of zero float is materially exposed to becoming critical given the duration uncertainty typical on infrastructure programmes. On long-duration programmes (nuclear, major civils) the threshold is often extended to 14 or 21 working days; on short construction packages it is sometimes tightened to 3-5 days. The principle is the same: identify the paths that are close enough to critical to deserve the same monitoring discipline. Near-critical paths matter most on programmes with material duration uncertainty. On a deterministically planned project with point estimates that the team is confident in, the critical path is the path that drives completion and the rest can be safely ignored. On a project with realistic duration uncertainty — which is to say, every real project — multiple paths are statistically likely to become critical at different points, and the only durably useful answer to 'what should we be monitoring?' is 'the critical path AND every near-critical path within the float threshold appropriate for our duration uncertainty profile'. A QSRA criticality index analysis quantifies this directly: any activity with a criticality index above (say) 25% is, in practice, on a near-critical path that warrants planner attention. The most common failure mode is reporting that lists only the deterministic critical path and presents it as 'the path the project is on'. This understates the monitoring perimeter and leaves the team blind to the paths that will actually drive overrun. A defensible programme status report identifies the critical path, the top 3-5 near-critical paths with their float values, and any activity moving toward the float threshold (e.g. paths whose float has reduced from 14 days to 8 days since last reporting period). On NEC4 contracts, this matters commercially as well as practically: compensation events assessed against a single-path critical-path view can understate the genuine schedule impact when the event tips a near-critical path into criticality. ### Frequently asked questions **What is a near-critical path?** A near-critical path is a sequence of activities whose total float is low but greater than zero — close enough to the critical path that a modest slip on any of its activities can promote it to be the new critical path and start driving project completion. **What float threshold makes a path near-critical?** The DCMA 14-point assessment treats activities with 7 working days or less of total float as near-critical for monitoring purposes. The threshold can sensibly extend to 14 or 21 working days on long-duration programmes (nuclear, major civils) and tighten to 3-5 days on short construction packages. The principle is the same: paths close enough to zero float that they could realistically become critical within the duration uncertainty typical of the work. **Why do near-critical paths cause more overruns than the critical path?** They go unwatched. The project team focuses monitoring effort on the zero-float critical path; an activity on a near-critical path slips by a few days; the previously-comfortable secondary path silently becomes the new critical chain and drives completion. By the time the change is recognised, several reporting periods of mitigation opportunity have been lost. The fix is to monitor the critical path AND every near-critical path within the float threshold appropriate for the programme's duration uncertainty profile — DCMA 14 makes this an explicit assessment metric. **How does criticality index relate to near-critical paths?** Criticality index from a Monte Carlo QSRA quantifies what near-critical means probabilistically. An activity with a criticality index above 25-30% is, in practice, on a near-critical path that warrants planner attention — even if its deterministic total float looks comfortable. The deterministic float threshold (DCMA's 7 days) is a fast proxy; the probabilistic criticality index is the more accurate read when a risk-loaded schedule is available. **What should a programme status report show about near-critical paths?** A defensible status report identifies the critical path, the top 3-5 near-critical paths with their current total float values, and any activity moving toward the float threshold (e.g. paths whose float has reduced from 14 days to 8 days since last reporting period). This gives the steering group a forward-looking view of where the next critical-path change is likely to come from, rather than a backward-looking confirmation of where the path was at last reporting. --- ## DCMA-14 vs Schedule Quality Metrics URL: https://www.somaprojectcontrols.com/resources/glossary/dcma-14-vs-schedule-quality-metrics DCMA-14 is a specific 14-point assessment framework developed by the US Defence Contract Management Agency. "Schedule quality metrics" is the broader practice of testing schedule health — which DCMA-14 is one (widely-adopted) instance of. The DCMA 14-point assessment is a specific schedule-health framework developed by the United States Defence Contract Management Agency in 2005 to test the quality of contractor-submitted schedules on US DoD programmes. It defines fourteen specific tests (logic completeness, leads, lags, relationships, hard constraints, high float, negative float, high duration, invalid dates, resources, missed tasks, critical path test, critical path length index, baseline execution index) and threshold values for each. A schedule that passes all fourteen is technically defensible; failures indicate areas where logic, sequencing or estimating is suspect. "Schedule quality metrics" as a phrase covers the broader practice of which DCMA-14 is the most widely adopted instance. Other frameworks exist — Acumen Fuse Metrics, ARM (Acumen's Risk Module), PASS Schedule Health Score, GAO Schedule Assessment Guide — and many programmes define their own internal checklists. The common thread is that schedule logic is testable using static, automated checks against the schedule data, and a schedule that fails those checks is unlikely to behave as forecast. On UK infrastructure, DCMA-14 has become the de facto standard, despite its US-DoD origin. National Highways, Network Rail, HS2, the NDA estate, and most UK MoD programmes either contractually require DCMA-14 reporting or accept it as the recognised framework when the contract calls for "schedule quality assessment." Tool support is broad — Deltek Acumen Fuse, ARM, P6 Visualizer, and many in-house P6 query tools all produce DCMA-14 metrics natively. The decision between "DCMA-14" and "a wider schedule-health framework" is rarely either/or. Most practitioners use DCMA-14 as the spine — non-negotiable on contracts where it's required — and supplement it with programme-specific checks (resource-loading sanity, calendar consistency, milestone density, baseline volatility, contingency burn rate) that DCMA-14 doesn't cover. ### Frequently asked questions **What is the difference between DCMA-14 and schedule quality metrics?** DCMA-14 is a specific 14-test framework with defined thresholds, developed by the US Defence Contract Management Agency in 2005. "Schedule quality metrics" is the broader umbrella term for any structured schedule-health test set, of which DCMA-14 is the most widely adopted single example. Other frameworks include Acumen Fuse Metrics, GAO Schedule Assessment Guide, and many programme-specific checklists. Most practitioners use DCMA-14 as the baseline and add programme-specific checks on top. **Is DCMA-14 used in the UK?** Yes — extensively, despite its US-DoD origin. DCMA-14 is the de facto standard on UK major infrastructure: National Highways, Network Rail, HS2, the Nuclear Decommissioning Authority estate, and most UK MoD MPRP-governed programmes either contractually require DCMA-14 reporting or accept it as the recognised framework when contracts call for "schedule quality assessment". **What are the 14 DCMA tests?** Logic (no missing predecessors/successors), Leads (no negative lags), Lags (excessive positive lags), Relationships (predominantly Finish-to-Start), Hard Constraints (limit imposed dates), High Float (>44 working days), Negative Float, High Duration (>44 working days), Invalid Dates, Resources (loaded where required), Missed Tasks (not progressed against plan), Critical Path Test, Critical Path Length Index (CPLI), and Baseline Execution Index (BEI). **Should we use DCMA-14 or a custom schedule QA framework?** Both. DCMA-14 should be the baseline — it's expected by clients, recognised by reviewers, and supported natively by every major scheduling tool. On top of that, most programmes need additional checks DCMA-14 doesn't cover: calendar consistency, resource-loading sanity, milestone density, baseline volatility tracking, contingency burn rate. The right answer is DCMA-14 as the spine + programme-specific extensions on top. --- ## Organisational Breakdown Structure (OBS) URL: https://www.somaprojectcontrols.com/resources/glossary/organisational-breakdown-structure-obs A hierarchical breakdown of the project organisation by who is accountable for delivering work — the people-side counterpart to the WBS. The Organisational Breakdown Structure (OBS) is the project's organogram expressed as a controlled hierarchy. Where the Work Breakdown Structure decomposes scope by deliverable, the OBS decomposes the delivery organisation by accountability — from the project sponsor at the top, through programme directors, package managers, discipline leads, and down to the individuals or teams responsible for executing each work package. Every level of the OBS has a named owner with defined authority and a clear reporting line, so the question 'who is accountable for this?' always has a documented answer. The OBS earns its keep when it is crossed with the WBS to form the Responsibility Assignment Matrix. Each cell in the WBS × OBS matrix identifies a single accountable manager for a discrete scope element, which in turn defines the Control Account for EVM purposes. Without a properly maintained OBS, the EVM system cannot identify who owns each control account, performance variances drift to no-one in particular, and corrective action stalls because escalation paths are ambiguous. On NEC4 contracts where Key Date accountability is contractually significant, OBS hygiene also has direct commercial consequences. The most common failures with the OBS are stale data and matrix ambiguity. People move roles, contractors are replaced, and joint-venture structures evolve — but the OBS in the project controls system often lags reality by months. The matrix problem is worse: where two managers from different organisations both have a credible claim to ownership of a work package (typically at JV interfaces or where client delivery teams overlap with contractor scopes), the OBS needs to resolve the ambiguity explicitly rather than leaving it to be worked out informally. An OBS that lists 'TBC' against any control account is a governance gap, not a placeholder. --- ## Responsibility Assignment Matrix (RAM) URL: https://www.somaprojectcontrols.com/resources/glossary/responsibility-assignment-matrix-ram A matrix that crosses the WBS with the OBS to identify who is responsible for each piece of work — the formal basis for control account ownership in EVM. The Responsibility Assignment Matrix (RAM) sits at the intersection of the Work Breakdown Structure and the Organisational Breakdown Structure. Each row is a WBS element; each column is an OBS unit; each cell records the responsibility relationship — typically using a RACI scheme (Responsible, Accountable, Consulted, Informed) or the simpler R/A coding used in EVMS documentation. A properly populated RAM identifies, for every scope element, exactly one accountable manager and any supporting roles. It is the canonical answer to 'who does what' on the programme. The RAM has a specific contractual role in Earned Value Management. The intersections marked as 'accountable' on the matrix define the Control Accounts — the units at which budget is authorised, performance is measured, and variances are managed. The control account manager named in the RAM owns the control account plan, signs off the time-phased budget, and is the accountable individual for any variance analysis or recovery planning. Where the RAM is missing or ambiguous, the EVM system has no defensible chain of accountability and the variance reports become noise. Beyond EVM, the RAM is the tool that surfaces the structural problems in how a programme is organised. Rows with no 'A' (no-one accountable) reveal coverage gaps; rows with multiple 'A's (more than one person accountable) reveal contested ownership. Columns that are mostly 'C' or 'I' reveal stakeholders who think they are managing the work but in reality have no executive role. On JV-delivered or partnered programmes, working through the RAM line by line with the parties together is one of the most reliably useful exercises in early mobilisation — it forces the conversations that get otherwise deferred until something goes wrong. --- ## BCWS / BCWP / ACWP URL: https://www.somaprojectcontrols.com/resources/glossary/bcws-bcwp-acwp The three foundational EVM measurements — Budgeted Cost of Work Scheduled, Budgeted Cost of Work Performed, and Actual Cost of Work Performed — now usually called PV, EV and AC. BCWS, BCWP and ACWP are the legacy acronyms from the original US Department of Defense Cost/Schedule Control Systems Criteria (C/SCSC), introduced in 1967 and reissued as the modern EVMS standard. BCWS — Budgeted Cost of Work Scheduled — is the cumulative budget for the work that was planned to be complete by the data date; this is now called Planned Value (PV). BCWP — Budgeted Cost of Work Performed — is the cumulative budget for the work that has actually been completed, regardless of what it cost; this is now called Earned Value (EV). ACWP — Actual Cost of Work Performed — is the cumulative actual cost incurred for the work completed; this is now called Actual Cost (AC). The terminology change from BCWS/BCWP/ACWP to PV/EV/AC was made by the Project Management Institute in PMBOK 4 to make the concepts more accessible. The maths is identical — Schedule Variance is still BCWP − BCWS (now EV − PV) and Cost Variance is still BCWP − ACWP (now EV − AC). The legacy acronyms still appear in older EVMS standards, ANSI/EIA-748 documentation, and on UK MoD programmes that have inherited US defence reporting templates. A practitioner reviewing a programme with mixed legacy and modern documentation should be fluent in both. The pitfall to watch for is inconsistent application of the underlying definitions, regardless of which acronym is used. BCWP/EV must be earned against objective progress rules — 0/100, 50/50, weighted milestones, percent complete with apportioning — not self-reported judgement. ACWP/AC must include all costs incurred for the work, including accruals for committed-but-not-invoiced expenditure, otherwise CPI is artificially flattering. And BCWS/PV is only meaningful if the schedule and budget are integrated against a controlled Performance Measurement Baseline. Sloppy definitions at the data layer produce variance metrics that look authoritative but cannot be trusted. --- ## NEC4 Clause 31 (Programme Submission) URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-clause-31-programme-submission The NEC4 clause that requires the Contractor to submit a programme for acceptance — defining what the programme must contain and how the Project Manager responds. NEC4 Clause 31 governs the initial submission of the Contractor's programme. The Contractor must submit a first programme to the Project Manager either with their tender, or within the period stated in the Contract Data after the Contract Date. The clause prescribes the content of the programme: planned starting and completion dates, the order and timing of operations, the order and timing of work by the Client and Others, the dates the Contractor plans to meet Key Dates and Conditions, float, time risk allowances, health-and-safety hazards, and a statement of how the Contractor plans to do the work. A submission missing any of these elements is not compliant with Clause 31 and the Project Manager is entitled to reject it. The Project Manager must reply within two weeks of submission, either accepting the programme or stating reasons for not accepting it. The reasons for non-acceptance are restricted to four: the plans are not practicable, it does not show the information the contract requires, it does not represent the Contractor's plans realistically, or it does not comply with the Works Information. Any non-acceptance outside these four reasons can itself be a compensation event under Clause 60.1(9). If the Project Manager fails to reply within two weeks, the Contractor may notify them — and continued failure after that notification entitles the Contractor to a compensation event for the delay. For project controls teams, Clause 31 is the gateway test for the entire NEC4 time-management regime. A programme that scrapes through Clause 31 with weak logic, missing time risk allowances, or shallow Key Date detail will fail the moment a compensation event needs to be assessed against it. The discipline of producing a Clause 31 submission that is genuinely fit for purpose — DCMA 14-compliant, properly resource-loaded where required, with a transparent time risk allowance built into activity durations rather than hidden — pays back many times over during the contract. A weak first programme accepted by an inattentive Project Manager is a future dispute waiting to be triggered. --- ## NEC4 Clause 32 (Revising the Programme) URL: https://www.somaprojectcontrols.com/resources/glossary/nec4-clause-32-revising-the-programme The NEC4 clause that requires the Contractor to revise the Accepted Programme at defined intervals — keeping the contractual reference programme current throughout delivery. NEC4 Clause 32 governs revisions to the Accepted Programme during delivery. The Contractor must submit a revised programme to the Project Manager at the interval stated in the Contract Data (typically every four to eight weeks), and additionally whenever instructed, whenever a compensation event is implemented, and whenever the Contractor's plans materially change. Each revised programme must show progress on each operation since the previous submission, the effect of implemented compensation events, how the Contractor plans to deal with delays and risks notified by either party, and any other changes the Contractor proposes. Once submitted, the revised programme goes through the same acceptance process as the original — the Project Manager has two weeks to accept it or state reasons for non-acceptance, with the same four restricted reasons under Clause 31. An accepted revised programme replaces the previous Accepted Programme and becomes the new contractual reference. Failure by the Contractor to submit revisions when required is a breach of contract; failure by the Project Manager to respond within two weeks is itself a compensation event under Clause 60.1(9). Both sides have skin in the game on programme currency. In practice, Clause 32 discipline is where most NEC4 contracts succeed or fail at managing time. A contract running on a stale Accepted Programme — six months old, no compensation events implemented since baseline, progress claimed against a Gantt that no longer reflects what is being built — has lost its primary time-management instrument. Subsequent compensation event assessments become arguments about which version of the programme to use, delay analysis is reduced to retrospective reconstruction, and disputes escalate. Project controls teams should treat the Clause 32 cycle as the heartbeat of NEC4 contract administration: submit on time, update genuinely (not cosmetically), and reconcile to implemented compensation events every cycle. --- ## AACE 11R-88 (EVMS) URL: https://www.somaprojectcontrols.com/resources/glossary/aace-11r-88-evms AACE International's Recommended Practice on Required Skills and Knowledge of an Earned Value Management System — the reference for what an EVMS implementation should contain. AACE Recommended Practice 11R-88 sets out the body of knowledge that an Earned Value Management System implementation should cover. It defines the 32 EVMS guidelines (organised into the five process areas of Organisation, Planning, Scheduling and Budgeting, Accounting Considerations, Analysis and Management Reports, and Revisions and Data Maintenance), describes the artefacts each guideline requires — control account plans, work authorisation documents, the Performance Measurement Baseline, variance analysis reports — and provides the practitioner-level detail of how each piece fits together. It sits alongside the ANSI/EIA-748 standard, which 11R-88 is structured to support. For UK practitioners, 11R-88 matters because UK MoD, Network Rail, Nuclear Decommissioning Authority, and other major-programme clients increasingly require ANSI/EIA-748-compliant EVMS reporting. A controls team that can describe its EVMS implementation in 11R-88 / EIA-748 terms — '32 guideline compliance, Control Account Plans aligned to the PMB, monthly variance analysis at CAM level' — is speaking the same language as the client's assurance reviewers. A team that cannot is liable to be tripped up at the first formal review, regardless of whether the underlying controls are sound. Practical implementation usually involves an EVMS Description Document that walks through each of the 32 guidelines and explains how the project's processes satisfy each one, supported by sample artefacts (a control account plan, a variance analysis report, a baseline change request) demonstrating that the processes are live rather than aspirational. Independent EVMS surveillance reviews — by the client, by an external assurer, or by an Integrated Baseline Review — will test the documentation against the actual practice. The most common failure modes are documented processes that are not actually followed (control account managers who do not own variance analysis), and live practices that are not documented (informal re-baselining outside the formal change control process). --- ## AACE 57R-09 (Integrated Cost and Schedule Risk Analysis) URL: https://www.somaprojectcontrols.com/resources/glossary/aace-57r-09 AACE International Recommended Practice for integrated cost-schedule risk analysis using the Risk Driver method — discrete risks that simultaneously affect multiple activities, modelled via Monte Carlo simulation of the CPM network. AACE 57R-09 is the AACE International Recommended Practice titled "Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model". Published in 2009 and based on methodology developed by John Hollmann, it is one of the most widely cited methodology references for QRA on major capital programmes — particularly UK infrastructure and defence work where integrated cost-schedule confidence (rather than separate QSRA + QCRA) is needed for gateway business cases. The Risk Driver method that 57R-09 codifies is the practical innovation. A traditional Monte Carlo QRA treats activity durations and discrete risk events independently — each activity gets its own three-point estimate, each risk gets its own probability and impact. Risk Drivers model risks as factors that simultaneously affect multiple activities: a regulatory consenting risk affects every downstream construction activity in proportion; a labour-market risk affects every labour-intensive activity by a correlated factor; a weather risk affects all weather-sensitive activities together. This produces a more honest correlation structure than the default zero-correlation assumption that vanilla activity-by-activity QRA falls into, and a much more realistic upper-tail of the cost and schedule distributions. The methodology requires: a deterministic CPM schedule with logic complete and float distributed; a discrete risk register with each risk characterised as a Risk Driver (probability of occurrence + impact range on the activities it affects); base-estimate uncertainty captured separately from discrete risks (so the model doesn't double-count where line items already have contingency baked in); explicit correlation between Risk Drivers where shared causes exist. The output is the joint cost-schedule probability distribution — a bivariate analogue of the QSRA-only and QCRA-only S-curves, with reference points at any (cost, date) pair. 57R-09 is the methodology UK programmes that need integrated cost-schedule confidence default to. It is the underlying reference for most major National Highways, Network Rail, Highways England (predecessor) and MoD CADMID-phase QRA work, and it is the methodology IPA reviewers expect to see cited in business cases where integrated cost-schedule confidence is presented. The competing AACE RP for similar work is 113R-20 (Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value), which uses a different theoretical basis and is preferred where parametric cost estimating is the primary input. Both produce defensible integrated confidence positions; the choice between them depends on data availability and modelling preference. Tool support for 57R-09 is good across the major QSRA platforms. Acumen Risk by Deltek implements the Risk Driver method natively. Safran Risk supports it via its risk register import and correlation specification. Primavera Risk Analysis (formerly Pertmaster, now on Oracle extended support) supports it through its risk register and correlation matrix. The method is independent of any specific tool — the methodology discipline (Risk Drivers characterised properly, correlation specified explicitly, base estimate uncertainty separated from discrete risks) matters far more than the platform choice. ### Frequently asked questions **What is AACE 57R-09?** AACE 57R-09 is the AACE International Recommended Practice titled "Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model". Published in 2009, it codifies the Risk Driver method for integrated cost-schedule QRA — a methodology that treats discrete risks as factors simultaneously affecting multiple activities, producing more realistic correlation than the default activity-by-activity QRA approach. **What is a Risk Driver in AACE 57R-09?** A Risk Driver is a discrete risk characterised by its probability of occurrence and the impact range it has on the multiple activities it would affect simultaneously. Instead of modelling "contaminated ground discovery delays activity X by Y days", a Risk Driver models "contaminated ground discovery occurs with 40% probability, and where it occurs it delays every downstream excavation and construction activity by 1.2-1.8× factor". This captures correlated impact across the schedule that activity-by-activity QRA misses. **How does 57R-09 differ from 113R-20?** Both are AACE RPs for integrated cost-schedule QRA. 57R-09 uses the Risk Driver method with Monte Carlo simulation on a CPM schedule. 113R-20 (Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value) uses a different theoretical basis — combined parametric cost estimating with expected-value risk treatment — and is preferred where parametric cost data is the primary input. Both produce defensible integrated cost-schedule confidence positions; the choice between them depends on data availability and modelling preference. **Which tools support AACE 57R-09?** All the major UK QSRA platforms support 57R-09. Acumen Risk by Deltek implements the Risk Driver method natively. Safran Risk supports it via risk register import and correlation specification. Primavera Risk Analysis (formerly Pertmaster) supports it via its risk register and correlation matrix. The methodology discipline matters far more than the tool choice — a well-run Safran Risk model produces better results than a poorly-run Acumen one. --- ## AACE 113R-20 (Integrated Cost and Schedule Risk Analysis — Parametric and Expected Value) URL: https://www.somaprojectcontrols.com/resources/glossary/aace-113r-20 AACE Recommended Practice for integrated cost-schedule risk analysis using combined parametric cost estimating with expected-value risk treatment. An alternative to 57R-09's Risk Driver method, preferred where parametric cost data is the primary input. AACE 113R-20 is the AACE International Recommended Practice titled "Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value". Published in 2020, it represents the more recent of the two integrated cost-schedule QRA methodologies AACE maintains — the other being 57R-09 (the Risk Driver method, published 2009). Where 57R-09 builds the integrated model bottom-up from a CPM schedule with risk drivers attached, 113R-20 combines parametric cost estimating (statistical relationships between cost and project attributes derived from historical data) with expected-value treatment of discrete risks. The methodology rests on two distinct calculations. The parametric cost component derives a base estimate and its uncertainty distribution from historical project data — typical inputs include project type, scope size, complexity factors, location adjusters and schedule duration. The expected-value risk component takes the discrete risk register and computes the probability-weighted impact of each risk on cost and schedule, summing across the register to produce a contingency provision. The two components are combined to give the integrated cost-schedule contingency position at the chosen confidence level (typically P50 and P80). 113R-20 is preferred over 57R-09 in three practical contexts. First, on programmes where parametric cost data is the primary basis of the estimate (early-stage major programmes where the CPM schedule is not yet developed enough to support detailed Monte Carlo simulation). Second, on programmes where the project team is more comfortable with parametric cost estimating than with Monte Carlo modelling — 113R-20's mathematical machinery is simpler to explain to a non-technical sponsor. Third, on programmes subject to historical-data-based regulatory requirements where the parametric approach maps directly onto the regulator's expected evidence base. The methodology has its limitations. Parametric cost estimating depends on having a sufficient historical dataset of comparable programmes — on truly novel programmes (first-of-a-kind defence platforms, novel nuclear technology) the parametric base is thin and the methodology can produce misleadingly narrow uncertainty distributions. Expected-value treatment of discrete risks averages across the probability-impact range but loses the upper-tail detail that a full Monte Carlo simulation captures, which can understate exposure on programmes with a few large discrete risks. Practitioners using 113R-20 should be alert to both limitations and consider whether 57R-09's Risk Driver Monte Carlo approach is the better fit for the programme's risk profile. On UK programmes, both 57R-09 and 113R-20 are accepted methodologies for IPA gateway business cases and major programme reviews. The choice is typically made early in the programme's QRA strategy and documented in the business case methodology statement. Where the programme has a mature CPM schedule and a well-developed discrete risk register, 57R-09 tends to win. Where the programme is at early business-case stage with primarily parametric cost data, 113R-20 is the more natural fit. ### Frequently asked questions **What is AACE 113R-20?** AACE 113R-20 is the AACE International Recommended Practice titled "Integrated Cost and Schedule Risk Analysis and Contingency Determination Using Combined Parametric and Expected Value". Published in 2020, it combines parametric cost estimating (statistical relationships derived from historical project data) with expected-value treatment of discrete risks to produce integrated cost-schedule contingency positions. **When should I use 113R-20 instead of 57R-09?** Three practical contexts favour 113R-20 over 57R-09. First, on early-stage programmes where parametric cost data is the primary estimating basis and the CPM schedule isn't yet developed enough to support detailed Monte Carlo simulation. Second, on programmes where the project team is more comfortable with parametric cost estimating than with Monte Carlo modelling. Third, where regulatory requirements expect parametric evidence. On programmes with mature CPM schedules and well-developed discrete risk registers, 57R-09's Risk Driver Monte Carlo approach is typically the better fit. **What are the limitations of 113R-20?** Two main limitations. First, parametric cost estimating depends on a sufficient historical dataset of comparable programmes — on truly novel projects (first-of-a-kind defence platforms, novel nuclear technology) the parametric base is thin and the methodology can produce misleadingly narrow uncertainty distributions. Second, expected-value treatment of discrete risks averages across probability-impact and loses the upper-tail detail a full Monte Carlo simulation captures, which can understate exposure on programmes with a few large discrete risks. **Is 113R-20 accepted for UK IPA gateway business cases?** Yes. Both 57R-09 and 113R-20 are accepted methodologies for IPA gateway business cases and major UK programme reviews. The choice is typically made early in the programme's QRA strategy and documented in the business case methodology statement. IPA reviewers expect to see the methodology cited and the choice justified given the programme's data availability and risk profile. --- ## AACE 18R-97 (Cost Estimate Classification System) URL: https://www.somaprojectcontrols.com/resources/glossary/aace-18r-97 AACE Recommended Practice defining a five-class cost estimate classification system based on level of project definition, end usage, methodology and expected accuracy range. The most widely cited estimate classification standard across UK and international capital projects. AACE 18R-97 is the AACE International Recommended Practice titled "Cost Estimate Classification System — As Applied in Engineering, Procurement, and Construction for the Process Industries" — and despite the process-industry title, it is the foundational reference for cost estimate classification across UK infrastructure, defence and energy programmes. Published in its original form in 1997 (and revised multiple times since), it defines a five-class system that ranks cost estimates by the level of project definition behind them, the typical methodology used to produce them, the end-usage they support, and the expected accuracy range each class can credibly claim. The five classes, summarised: Class 5 — concept screening / rough order of magnitude (ROM), 0-2% project definition, accuracy range -50% to +100%, used for portfolio screening and early sanction decisions. Class 4 — study or feasibility, 1-15% project definition, accuracy -30% to +50%, used for strategic planning and concept selection. Class 3 — budget authorisation, control or bid/tender estimate, 10-40% project definition, accuracy -20% to +30%, used for funding submissions and stage-gate decisions. Class 2 — control or bid/tender estimate, 30-75% project definition, accuracy -15% to +20%, used for project control and competitive bidding. Class 1 — check estimate or bid/tender, 50-100% project definition, accuracy -10% to +15%, the maximum accuracy class. The classification system serves three practical purposes. First, it gives the estimator a defensible vocabulary for explaining what an estimate is and isn't capable of supporting. An estimate that is genuinely Class 3 should not be presented as Class 2 to make a sponsor more comfortable — the accuracy range is part of the deliverable, not a separate caveat. Second, it gives the sponsor a calibration framework for understanding the level of certainty they are looking at. A Class 5 estimate carrying -50% to +100% accuracy is a portfolio-screening tool, not a funding figure. Third, it gives the QRA practitioner the baseline-uncertainty calibration for the Monte Carlo simulation — the three-point estimate ranges on individual cost line items should be consistent with the AACE class of the parent estimate. The AACE classes map approximately onto the UK IPA Cost Estimating Requirements stage-gate tolerance bands, though the mapping is approximate rather than one-to-one. Strategic Outline Case (SOC) typically uses Class 5 or Class 4 estimating with the IPA's -20% to +50% tolerance band (the IPA band is tighter than AACE Class 5's -50% to +100%, reflecting the IPA's expectation that SOC estimates are already informed by some preliminary engineering). Outline Business Case (OBC) typically aligns with Class 3 estimating and the IPA's -15% to +30% band. Final Business Case (FBC) aligns with Class 2 estimating and the IPA's ±10% band. The two frameworks are complementary — the AACE class describes the estimating method and underlying definition; the IPA band describes the gateway tolerance — and both should be cited in a UK business case. Common misuses to watch for: presenting a Class 3 estimate with a Class 2 accuracy claim (typically by trimming the upper bound of the range to make the figure look tighter than the methodology supports); confusing the AACE class with the IPA band (different frameworks, different meanings); and treating the class as a property of the project rather than the estimate (a Class 5 estimate of a mature project still has Class 5 accuracy if the input data is at that definition level). The class is about the estimate's methodology and inputs, not the project's actual maturity. ### Frequently asked questions **What is AACE 18R-97?** AACE 18R-97 is the AACE International Recommended Practice titled "Cost Estimate Classification System — As Applied in Engineering, Procurement, and Construction for the Process Industries". It defines a five-class system (Class 1 through Class 5) ranking cost estimates by level of project definition, methodology, end usage and expected accuracy range. Despite the process-industry title, it is the foundational reference for cost estimate classification across UK infrastructure, defence and energy programmes. **What are the five AACE estimate classes?** Class 5 — concept screening / ROM, 0-2% project definition, accuracy -50% to +100%; Class 4 — study or feasibility, 1-15% definition, -30% to +50%; Class 3 — budget authorisation / control / bid-tender, 10-40% definition, -20% to +30%; Class 2 — control or bid/tender, 30-75% definition, -15% to +20%; Class 1 — check estimate or bid/tender, 50-100% definition, -10% to +15%. **How do AACE estimate classes map onto IPA stage gates?** Approximately, not one-to-one. Strategic Outline Case (SOC) typically uses Class 5 or Class 4 estimating with the IPA tolerance band of -20% to +50%. Outline Business Case (OBC) aligns with Class 3 estimating and the IPA band of -15% to +30%. Final Business Case (FBC) aligns with Class 2 estimating and the IPA band of -10% to +10%. The two frameworks are complementary — AACE class describes the estimating method; IPA band describes the gateway tolerance — and both should be cited in a UK business case. **Is the AACE class a property of the project or the estimate?** The estimate. A Class 5 estimate of a mature project still has Class 5 accuracy if the input data is at that definition level — for example, a quick portfolio-screening estimate done in an afternoon for a project already in delivery. The class describes the methodology and inputs, not the project's actual maturity. A common misuse is treating a project at FBC stage as automatically Class 2, when the estimate may have been produced with Class 3 methodology and inputs. --- ## National Audit Office (NAO) URL: https://www.somaprojectcontrols.com/resources/glossary/national-audit-office-nao The UK's independent public-spending watchdog — auditing how government departments and major programmes deliver value for money and reporting findings to Parliament. The National Audit Office (NAO) is the independent body that scrutinises public spending on behalf of the UK Parliament. It conducts two types of work directly relevant to major programmes: financial audits, which sign off on departmental accounts, and Value for Money (VFM) studies, which examine whether public money is being used efficiently and effectively. NAO VFM reports on major projects — Crossrail, HS2, Hinkley Point C, the Emergency Services Network, defence equipment programmes — are public documents that name specific failings in cost estimation, schedule management, optimism bias and risk control. They are quoted in Parliament, in the press, and in subsequent project assurance reviews. For project controls practitioners, the NAO is the apex public-sector reviewer. Its reports consistently identify the same root causes for programme failure: optimism bias not properly quantified or mitigated, weak baselines that re-set when performance falls behind, immature QRA producing artificially confident headline numbers, inadequate cost estimating against HM Treasury Green Book methodology, and governance failures that prevent early warnings from reaching the right level. A programme whose controls cannot withstand NAO scrutiny — defensible baseline, transparent QRA, evidence-based optimism bias, traceable change control — is a programme building up reputational and financial risk for its sponsor department. The NAO works in concert with the IPA, the Public Accounts Committee, and HM Treasury. An NAO report typically precedes Public Accounts Committee hearings where Permanent Secretaries and SROs are required to give evidence, and findings frequently lead to changes in departmental approval processes, mandatory IPA review points, or revisions to Green Book or Orange Book guidance. For SOMA's clients, the practical implication is that controls work delivered to AACE recommended practices, Green Book methodology and IPA assurance standards is the same work that protects against adverse NAO findings. Building to the NAO bar from day one is materially cheaper than retrofitting controls after an adverse report. --- # Training courses ## Primavera P6 for Real Projects URL: https://www.somaprojectcontrols.com/training/primavera-p6 Category: Schedule (flagship) Price: £895 / seat CPD: 28 CPD hours (pending APM accreditation) Cohort: ≤ 12 students · 4 × 3-hour live-online sessions over 2 weeks A hands-on course that takes you from zero to confidently building, resourcing, and updating a P6 schedule on a live UK construction or infrastructure programme. Written and taught by practitioners who use P6 every week, not trainers who last touched a project in 2015. ### Outcomes - Understand P6’s architecture: EPS, OBS, WBS, calendars, and activity codes — and why they matter for multi-project environments - Build a well-structured, fully logic-linked schedule from a scope document, using UK conventions (NEC, CESMM, SCL Protocol) - Resource-load a schedule and produce a meaningful S-curve and histogram - Set a baseline and understand what baseline comparison actually tells you - Run a monthly status update cycle: progress, remaining durations, actual dates, data date - Produce a credible 4-week look-ahead from a live programme schedule - Identify the common P6 mistakes that cause schedules to fail assurance reviews - Know when a schedule is telling you something useful and when it’s lying to you ### Syllabus **Session 1 — P6 Architecture** (3 hours) - Enterprise Project Structure (EPS) and why it matters for portfolio visibility - Organisational Breakdown Structure (OBS) and how it drives access control - Calendars: global, project, and resource calendars; handling shift patterns and NEC compensation events - Activity codes and user-defined fields: using them to filter, sort, and report without duplicating data - P6 Admin basics: user accounts, licence types, database vs standalone — what you’ll encounter on site - Common P6 myths and bad habits that cause problems later (and why they’re so widespread) **Session 2 — Building a Schedule** (3 hours) - Work Breakdown Structure (WBS): principles, typical UK construction WBS patterns, what the NEC requires - Activity types: task-dependent, resource-dependent, milestones — when to use each - Relationships and logic: FS, SS, FF, SF; lag and lead; when lag is appropriate and when it’s hiding a missing activity - Duration estimating: how to get to defensible numbers and document your basis - Critical path: what it is, why it moves, and what it means for programme management - Schedule quality checks before you share it with anyone: open ends, constraints, missing logic **Session 3 — Resourcing & Baselining** (3 hours) - Resource types and loading approaches: labour, equipment, materials; units vs units/time - Producing a resource S-curve and histogram from a P6 schedule - Baseline types in P6: BL1, User Baseline, Primary Baseline — and the difference between them - Baseline management: when to rebaseline, how to seek client approval, audit trail discipline - Producing a meaningful schedule narrative to accompany the baseline submission - Common baselining errors that come back to haunt you in a dispute or entitlement claim **Session 4 — Live-Programme Techniques** (3 hours) - The monthly update cycle: setting data date, entering actuals, remaining durations, actual dates - Earned value from P6: pulling % complete, physical % complete, and understanding the difference - Producing a credible 4-week look-ahead: filtering, grouping, and exporting for site use - Schedule analytics: interpreting schedule performance, float trends, and critical path drift - Delay analysis fundamentals: how the SCL Protocol uses schedules as evidence; contemporaneous records - Exporting and reporting: PDF, XER, XML, and what to keep in your project record ### What you get - Access to all four live sessions with a practitioner instructor - Recordings of every session, available for 12 months - A course workbook with the practice schedule files used during the sessions - A P6 quick-reference card covering the most-used keyboard shortcuts and menu paths - A SOMA certificate of completion for your CPD record - Access to a post-course Q&A thread for follow-up questions from your own projects --- ## MS Project and Planning Fundamentals URL: https://www.somaprojectcontrols.com/training/ms-project-and-planning-fundamentals Category: Schedule Price: £495 / seat CPD: 10 CPD hours (pending APM accreditation) Cohort: ≤ 12 students · 2 × 3-hour live-online sessions over 1 week A practical two-session course for project managers, engineers and commercial leads who need to build, maintain or credibly challenge a schedule in Microsoft Project — without spending three months in planning school. Not a full-fat planner qualification; enough fluency to run the work yourself or to sharpen your questions to the people who do. ### Outcomes - Build a properly logic-linked schedule in MS Project from a scope outline - Set a sensible calendar, working week and project start configuration — and understand why the defaults cause problems later - Use WBS, summary tasks, milestones and deliverables to give the schedule a readable structure - Apply relationships (FS, SS, FF, SF) and know when each is appropriate — and when lag is hiding a missing activity - Set a baseline, update progress through a cycle, and produce a variance view - Produce a readable Gantt chart and a clean look-ahead for the site team - Spot the most common MS Project mistakes — resource over-allocation, accidental constraints, logic-free Gantts - Know when to push back on a schedule produced by someone else and the questions to ask ### Syllabus **Session 1 — Building a Schedule in MS Project** (3 hours) - The MS Project environment: views, tables, Gantt Chart, Network Diagram — what each is for - Project calendars, working week and start date — common errors and how to avoid them - WBS in MS Project: summary tasks, tasks, milestones, deliverables - Relationships and logic: FS, SS, FF, SF; lag and lead; when lag is legitimate and when it is hiding a missing activity - Duration estimating basics and documenting a defensible basis - Resourcing simply: assigning people to tasks, spotting and fixing over-allocation **Session 2 — Running a Schedule Through Delivery** (3 hours) - Setting a baseline: what it captures, when to rebaseline, and how to track against it - The update cycle: status date, % complete, actuals, remaining duration - Critical path in MS Project: how it is calculated and what it actually means - Producing a readable Gantt chart: formatting, filtering, and the one-page plan the sponsor will actually look at - Look-ahead planning: producing a 2–4 week look-ahead from the master schedule - Reading someone else’s schedule: the five warning signs of a schedule built for appearance rather than delivery ### What you get - Access to both live sessions with a practitioner instructor - Recordings of every session, available for 12 months - A course workbook with the practice schedule file used during the sessions - An MS Project quick-reference card covering the most-used keyboard shortcuts and menu paths - A SOMA certificate of completion for your CPD record - Access to a post-course Q&A thread for follow-up questions from your own projects --- ## Quantitative Risk Analysis Practitioner URL: https://www.somaprojectcontrols.com/training/quantitative-risk-analysis-practitioner Category: Risk (flagship) Price: £1,395 / seat CPD: 35 CPD hours (pending ACostE / APM accreditation) Cohort: ≤ 12 students · 5 × 3-hour live-online sessions over 2.5 weeks A complete, practitioner-level course in Quantitative Risk Analysis — from running the workshop that produces your inputs, through building a QSRA and QCRA in @Risk, to presenting results at board level. For people who need to own a QRA end to end, not just run the model. ### Outcomes - Design and facilitate a risk workshop that produces calibrated three-point estimates, not consensus theatre - Draw out quiet voices and manage dominant ones without derailing the session - Select appropriate probability distributions for cost and duration inputs and justify the choice - Build a working Quantitative Schedule Risk Analysis (QSRA) model in @Risk from a real schedule - Build a working Quantitative Cost Risk Analysis (QCRA) model in @Risk from a cost estimate - Apply correlation between risks correctly and explain why ignoring it underestimates overall variability - Read and interpret S-curves, tornado charts, and sensitivity graphs accurately - Extract and present P50, P80, and P95 figures with appropriate caveats - Write a board-grade QRA report that is honest about the model’s limitations ### Syllabus **Session 1 — Running a QRA Workshop** (3 hours) - Scoping a workshop proportionate to the project: agenda, attendee list, duration - Pre-workshop preparation: briefing notes, seed risks, priming attendees to give useful input - Calibration exercises that demonstrate overconfidence and adjust attendee estimates - Eliciting credible three-point estimates: the questions to ask and the ones to avoid - Drawing out quiet voices and handling dominant ones without creating conflict - Documenting workshop outputs so they feed directly into a QRA model **Session 2 — Risk Fundamentals & @Risk** (3 hours) - What QRA is and isn’t: risk register vs sensitivity analysis vs Monte Carlo - Probability distributions in plain English: uniform, triangular, PERT, lognormal — when to use each - @Risk interface overview: adding distributions, running a simulation, reading outputs - Correlation between risks: what it is, why it matters, how to set it - Simulation mechanics: sample size, convergence, knowing when results are stable - Common QRA inputs that are simply wrong — and how to spot them before you run the model **Session 3 — Building a QSRA** (3 hours) - QSRA model structure: linking schedule logic to @Risk inputs - Handling activity durations and risk events as separate inputs - Merge bias and why your deterministic schedule is almost certainly optimistic - Running the simulation on a real (provided) schedule extract - Reading QSRA outputs: completion date S-curve, critical path index, sensitivity tornado - Hands-on: we build a QSRA together from a provided schedule **Session 4 — Building a QCRA** (3 hours) - QCRA model structure: uncertainty on base estimate lines vs discrete risk events - Integrating schedule-driven cost risk: the relationship between QSRA and QCRA - Cost line dependencies: why one ground-condition risk affects multiple packages - Escalation and inflation uncertainty without double-counting - Reading the cost S-curve: what P50, P80, and P95 actually commit you to - Hands-on: we build a QCRA together from a provided cost estimate **Session 5 — Reading Outputs & Reporting** (3 hours) - S-curves in depth: what the shape tells you about confidence and risk concentration - Tornado charts: identifying the risks that actually drive variability - P50, P80, P95: what these figures mean, what they don’t mean, and how to explain them without misleading - Structuring a board-grade QRA report: executive summary, methodology, assumptions, results, limitations - Common QRA mistakes that get spotted in peer review — and how to avoid them - When to update a QRA: triggers, re-baselining, and maintaining the model through delivery ### What you get - Access to all five live sessions with a practitioner instructor - Recordings of every session, available for 12 months - The QSRA and QCRA model files built during the course, fully annotated - A QRA workshop planning template — agenda, attendee brief, output documentation - A calibration exercise pack you can run with your own team - A QRA report template formatted for board-level presentation - A SOMA certificate of completion for your CPD record - Access to a post-course Q&A thread for follow-up questions from your own analyses --- ## Cost Management & Earned Value URL: https://www.somaprojectcontrols.com/training/cost-management-and-earned-value Category: Cost (flagship) Price: £1,195 / seat CPD: 35 CPD hours (pending ACostE / APM accreditation) Cohort: ≤ 12 students · 5 × 3-hour live-online sessions over 2.5 weeks A five-session practitioner course covering the complete cost lifecycle: building a credible estimate to the AACE class framework, structuring it as a Performance Measurement Baseline, and running Earned Value Management through delivery. For people who own cost numbers and need to defend them. ### Outcomes - Describe the AACE International classes of estimate (Class 1 to Class 5) and what level of definition each requires - Build a WBS-aligned cost estimate structure that separates base estimate, allowances, and contingency correctly - Calculate contingency using a structured, defensible method rather than a percentage guess - Convert an estimate into a time-phased Performance Measurement Baseline (PMB) - Explain PV, EV, AC, CPI, SPI, BCWS, BCWP, and ACWP clearly and correctly without reaching for a glossary - Select the right earning rule for each work package type and justify the choice - Spot the most common forms of EVM gaming and know how to challenge them - Produce a credible Estimate at Completion (EAC) using multiple methods and explain the difference between them - Write a variance narrative that adds value rather than explaining away bad news ### Syllabus **Session 1 — Estimating Principles & AACE Classes** (3 hours) - Why estimates fail: the psychology of optimism bias and how it shows up in project cost data - AACE classes of estimate Class 5 to Class 1: what each requires and what decisions each supports - Estimate components: direct costs, indirect costs, overheads, profit, escalation, contingency — what belongs where - Three-point estimating for cost: optimistic, most likely, pessimistic — getting credible ranges from your team - Escalation in practice: how to apply published indices, what to do when an index doesn’t exist for your sector - UK context: AACE framework use by National Highways, Network Rail, UKAEA; NEC contract implications **Session 2 — Building a Credible Estimate** (3 hours) - WBS-aligned cost structure: why your cost breakdown structure must follow the scope breakdown, not the organisational chart - Base estimate discipline: what goes into the base estimate and what must be kept out (buried contingency and scope optimism) - Allowances: what they are, when to use them, and how to document and track them through delivery - Contingency calculation: deterministic methods (% by element), factor-based methods, and simple risk-based approaches - Documenting the basis of estimate: what you need to record so the estimate can be defended six months later - Independent estimate review: what to look for when you’re checking someone else’s work **Session 3 — From Estimate to Baseline** (3 hours) - The Performance Measurement Baseline (PMB): structure, purpose, and the consequence of getting it wrong - Control accounts: what they are, who owns them, how granular to go - Work packages vs planning packages: when to plan in detail and when it’s too early - Time-phasing the budget: why a well-structured PMB is not just a schedule with cost on top - Undistributed budget and management reserve: what they are and how they are used correctly - The baseline review process: what governance looks like on a well-run programme **Session 4 — Earned Value & Earning Rules** (3 hours) - The three curves: PV (BCWS), EV (BCWP), AC (ACWP) — what each represents and how to read them together - Schedule Variance, Cost Variance, CPI, SPI: what they mean in plain English and what they don’t tell you - The earning rules: 0/100, 50/50, % complete, weighted milestones, level of effort — when to use each - Why % complete is the most dangerous earning rule and when it’s still the right answer - EVM gaming: the most common ways contractors and project teams inflate EV, and how to detect them - Worked examples: applying earning rules to different work package types and assessing the result **Session 5 — Forecasting & EAC** (3 hours) - Estimate at Completion (EAC): the main calculation methods, what assumptions each makes, when each is appropriate - Variance at Completion (VAC) and To Complete Performance Index (TCPI): interpreting them honestly - The relationship between EAC and bottom-up re-estimates: when to trust the formula and when to override it - Variance analysis: when a variance is significant, and how to write a variance narrative that adds value - Rebaselining: the legitimate triggers, the governance required, and why “we just rebaselined” is a red flag - Presenting cost and EV results to stakeholders: what boards and clients need to see, and how to have the hard conversation ### What you get - Access to all five live sessions with a practitioner instructor - Recordings of every session, available for 12 months - A course workbook including the estimate, baseline, and EV worked examples used during the sessions - A contingency calculation guide covering the main deterministic methods - An EVM quick-reference card covering key formulas and interpretation guidance - A SOMA certificate of completion for your CPD record - Access to a post-course Q&A thread for follow-up questions from your own programmes --- ## Project Controls for Project Managers URL: https://www.somaprojectcontrols.com/training/project-controls-for-pms Category: Cross-discipline Price: £495 / seat CPD: 6 CPD hours (pending APM accreditation) Cohort: ≤ 16 students · 1-day intensive — 3 × 2-hour sessions with breaks (can be split across two half-days) A single-day course for project managers and programme directors who receive project controls outputs and need to know whether they’re being handed something credible or something that’s been dressed up to look credible. Not enough to do the work yourself — enough to grade it. ### Outcomes - Read a Gantt chart and identify the signs of a schedule that has been managed for appearance rather than accuracy - Understand critical path and total float well enough to ask the right questions when the critical path looks implausibly benign - Read a QRA S-curve and tornado chart, understand P50 vs P80, and identify when a risk model is too narrow to be credible - Read an Earned Value report, understand CPI and SPI, and spot the most common forms of EV gaming - Know the questions that separate a good controls deliverable from a bad one in each discipline - Have the vocabulary and confidence to push back on weak controls work without getting into a technical argument ### Syllabus **Session 1 — How to Read a Schedule** (2 hours) - What a schedule is actually for: the difference between a planning tool and a reporting artefact - Critical path in plain English: what it means, why it matters, and why it moves - Total float: what a healthy amount looks like, what zero float everywhere means, and what a suspiciously long critical path means - The signs of a schedule that has been managed for appearance: resource levelling abuse, excessive constraints, logic gaps, fabricated progress - What to ask your planner: five questions that separate a credible schedule from a plausible-looking one - Worked example: reading a real (anonymised) schedule and identifying the issues **Session 2 — How to Read a QRA** (2 hours) - What a QRA is trying to tell you and what it cannot tell you - The S-curve: what the shape means, what P50 and P80 commit you to, and when the curve is suspiciously steep - Tornado charts: what they show, how to read them, and why a tornado dominated by one risk is often a sign of a lazy model - Red flags in QRA reports: ranges that are too narrow, risks that are never correlated, a P95 that is only 10% above P50 - The questions to ask your risk manager: what a credible QRA should be able to answer - Worked example: reviewing a QRA executive summary and identifying what to probe **Session 3 — How to Read an Earned Value Report** (2 hours) - PV, EV, AC in one slide: what each represents and how to read them together - CPI and SPI: what the numbers mean, what they don’t predict, and the danger of treating them as precise forecasts - The Estimate at Completion: how it’s calculated, what assumptions it makes, and when to distrust it - EVM gaming: the most common ways a team inflates EV to make the numbers look better, and how to spot them - When to push back: the thresholds and patterns that should trigger a conversation with your cost engineer - Worked example: reviewing a monthly EV report and identifying the questions to ask ### What you get - Access to all three live sessions with a practitioner instructor - Recording of the full day, available for 12 months - A one-page question guide for each discipline: schedule, QRA, and EV - A SOMA certificate of completion for your CPD record - Access to a post-course Q&A thread for follow-up questions --- # Case studies ## Quantitative Risk Analysis — New-Build Energy Facility URL: https://www.somaprojectcontrols.com/case-studies/new-build-energy-facility-qra Client: Confidential — £300m NAECI project · Sector: Energy & industrial construction Services: Quantitative Schedule Risk Analysis (QSRA), Quantitative Cost Risk Analysis (QCRA), Schedule & Cost Assurance, Investment decision support Independent QRA on a £300m new-build energy facility ahead of final investment decision — revealing £24m in unquantified risk and 2.2 months of schedule exposure the contractor’s submission had missed. ### The challenge SOMA Project Controls was engaged to deliver an independent Quantitative Risk Analysis — incorporating both QSRA and QCRA — on a £300m new-build energy facility, ahead of final investment decision and contract award. The client required assurance that the contractor’s proposed 24-month construction programme and cost estimate were realistic, and that schedule and cost contingency were appropriately quantified — not based on assumptions or optimism, but on evidence. The stakes at final investment decision are particular. Once the contract is signed, confidence levels cease to be a discussion topic and become a benchmark against which performance is measured. A P80 that was quietly optimistic at sanction will surface as variance in the first quarterly report, and the conversation thereafter becomes about recovery rather than about the risk profile that was accepted. Getting the QRA right at this stage was not about modelling exercise — it was about the realism of the baseline the client would live with for 24 months. ### Our approach We conducted a detailed review of the contractor’s baseline schedule and cost estimate, validating logic integrity, sequencing, the realism of activity durations, and the treatment of cost uncertainty. This ensured the model inputs were robust before quantitative analysis was applied. Three-point estimates were developed in collaboration with the project team for both schedule activities and cost line items. Monte Carlo simulation modelled the full range of possible outcomes, establishing P50 and P80 forecast positions for time and cost. Our QRA methodology follows AACE International recommended practice. Risks were captured in two distinct categories: inherent uncertainty in activity durations and cost line items (modelled as three-point distributions on the base estimate), and discrete risk events (modelled as probability-weighted impacts that only apply if the risk materialises). Keeping the two categories separate is what allows the model to answer two different questions — how uncertain is the base plan, and how much additional exposure comes from things that might go wrong. Correlation was handled explicitly. Activities that share a resource pool, a weather window, or a common subcontractor do not move independently, and treating them as if they do systematically understates confidence levels. We applied correlation groups where the evidence supported it, and tested the sensitivity of the P80 position to the correlation assumption — a transparency check that ensures the headline number does not depend on a hidden judgement call. ### What we found The analysis revealed that the contractor’s baseline programme and estimate carried material risk that had not been quantified: - Programme duration: contractor baseline 24 months vs QRA P80 position 26.2 months — a 2.2-month schedule contingency requirement that was not in the submission. - Project cost: contractor baseline £300m vs QRA P80 position £324m — an additional £20m cost contingency beyond what was included. - Prolongation exposure: the 2-month schedule extension exposed the client to £3–5m in prolongation costs — extended preliminaries, site management, and temporary facilities — that were not visible in the contractor’s submission. ### What the numbers actually meant A 2.2-month schedule extension and a £24m cost uplift are not forecasts of certain overrun — they are the level at which the client should be 80% confident that actual performance will be better, given the risk profile identified. The difference matters. It frames the client’s decision as one of risk appetite rather than one of contractor selection: either accept the P80 position and size contingency accordingly, or renegotiate the scope and risk allocation to bring exposure down. We presented the results as a decision support package rather than a QRA report. For each significant risk driver, the report showed which risks were inherent to the scope (and therefore non-negotiable), which were allocated inefficiently in the draft contract (and therefore worth renegotiating), and which were best mitigated by a specific change in sequencing or procurement strategy. The client used this to run a focused contract review before signature — the QRA was not just an input to the confidence level, it was an input to the contract itself. ### How this work differed from a standard QRA Independent QRA at final investment decision sits in a particular place in the project lifecycle. The model has to be good enough to satisfy an investment committee, robust enough to withstand a client challenge, and practical enough to inform contract negotiation within days rather than weeks. That combination is hard to achieve without an integrated cost-and-schedule model, a transparent audit trail, and a clear separation between model input and model output. We built the model in a form the client could continue to use post-sanction — re-running the analysis against actual performance as the programme advanced, updating the distributions as uncertainty resolved, and maintaining a live view of the confidence position rather than freezing the P80 at contract signature. This matters because a QRA delivered as a one-off document loses value within three months; a QRA delivered as a maintained model remains a governance asset throughout delivery. ### Outcomes - P80 forecast validated — still the governing target date at construction midpoint. - Contingency utilisation tracking as modelled. - Client entered contract with eyes open on realistic delivery and cost expectations. - No late surprises — proactive risk management enabled from day one. - Risk-allocation insights fed directly into pre-contract negotiation, not just into the post-sanction confidence level. - QRA model delivered as a live asset — continuing to inform decisions as delivery progressed, not frozen at contract award. The project is now at the midpoint of construction. The P80 forecast established by the QRA remains the target completion date, and contingency drawdown is tracking in line with predictions. --- ## Risk Management Framework Pilot — Project PUMA URL: https://www.somaprojectcontrols.com/case-studies/bilfinger-uk-project-puma Client: Bilfinger UK · Sector: Capital projects Services: Risk management framework design, Contingency drawdown process, Project controls tooling A practical, contract-agnostic risk management framework piloted on a complex capital project — scalable across Bilfinger UK’s wider portfolio. ### The challenge Bilfinger UK identified the need to strengthen consistency, governance, and visibility across project risk management. While risk was being actively managed on individual projects, there was no single, scalable framework covering risk identification, forecasting, and contingency drawdown that could be applied consistently across the wider portfolio. Project PUMA — a complex capital project — was selected as a live pilot to develop and test a fit-for-purpose risk management framework that could later be rolled out across the business. The underlying problem is familiar across UK capital delivery: risk was being managed, but what that meant differed from project to project. Registers were formatted differently. Contingency assumptions were made locally. Reports to senior leadership carried different meaning depending on who wrote them. The result was a portfolio view that could not be trusted to aggregate, even when every individual project team was working diligently. ### Our approach SOMA Project Controls worked closely with Bilfinger UK’s project controls team to develop a practical, contract-agnostic risk management framework, aligned with APM and IRM best practice. Phase 1 focused on delivering clear foundations rather than over-engineering processes, ensuring tools and procedures could be adopted easily by project teams and scaled across different project types. We deliberately avoided the temptation to import a heavyweight enterprise risk management system. The evidence across UK capital delivery is that teams who are handed a 60-page procedure and a bespoke tool quietly stop using both within six months. The framework had to be small enough to adopt on a Monday morning without training, but rigorous enough to stand up to a client audit. Engagement with the live Project PUMA team was central. Every template was tested against an actual project situation before being published as a standard. Items that looked clean on paper but friction-heavy in practice were simplified. This iteration loop — draft, use, refine — is what separates a framework that gets adopted from one that becomes documentation. ### What we delivered Four integrated deliverables, all refined through live project feedback to ensure clarity, simplicity, and reusability: - Risk Management Plan (RMP) — a scalable framework defining roles, responsibilities, governance, and reporting expectations. - Risk Forecasting Strategy — a structured EMV-based approach providing forward visibility of time-phased risk exposure, clearly separated from QRA outputs. - Risk Drawdown Procedure & Log — a simplified, auditable process defining how contingency is accessed, approved, and recorded. - Project Risk Register Template — a practical, QRA-ready tool supporting qualitative assessment, forecasting inputs, and drawdown tracking. ### Why the drawdown procedure was the centrepiece Of the four deliverables, the Risk Drawdown Procedure is the one that typically determines whether a framework sticks. Most contingency problems on UK capital projects are not failures of quantification — they are failures of governance. The money is sized correctly at sanction, then released informally through the year against pressure, so that by the time variance reports reach the steering group, the drawdown conversation has already happened in practice. We designed the procedure around a simple principle: every pound released against contingency ties back to a specific risk event, a named owner, and a dated approval. The log is auditable at any point. The implication is not bureaucratic — it gives the project director a real-time view of remaining exposure against remaining contingency, rather than a year-end reconciliation. ### EMV forecasting without duplicating QRA A common pitfall with risk forecasting is that teams produce parallel outputs that compete with the Monte Carlo model — an Expected Monetary Value forecast that disagrees with the project QRA, creating confusion rather than clarity. The Risk Forecasting Strategy was built to sit alongside QRA rather than duplicate it: qualitative risk scoring feeds EMV-based time-phased exposure, which informs the monthly management view; quantitative risks feed the QRA, which informs investment-grade confidence levels. The distinction sounds subtle but matters in practice. It means the project controls team can answer a risk question at the level appropriate to the audience — a project board wants exposure over the next quarter; an investment committee wants the P80. One framework, two views, no contradiction. ### Outcomes - Established a clear and consistent risk management baseline for Project PUMA. - Improved governance and transparency around contingency usage. - Enabled forward-looking visibility of risk exposure to support decision-making. - Delivered a scalable framework suitable for rollout across Bilfinger UK’s wider portfolio. - Built in alignment with APM, IRM and HM Treasury Green Book guidance, giving Bilfinger’s client-facing teams a defensible reference point. Following the successful completion of Phase 1, Bilfinger UK is now well positioned to mature and scale its risk management capability through wider rollout, deeper integration with project controls, and enhanced portfolio-level reporting. --- ## Project Controls PMO Delivery — Natara URL: https://www.somaprojectcontrols.com/case-studies/natara-pmo-project-controls Client: Natara — via RRL Group · Sector: Industrial processing / chemicals Services: Scheduling, Cost Management, Risk Analysis, Progress Reporting, Document Control, PMO Delivery Embedded project controls function across 9+ concurrent projects on a COMAH-regulated industrial site — from the flagship Project NEO capital investment through to site-wide portfolio reporting aligned to the client’s corporate governance. ### The brief SOMA was engaged through RRL Group to deliver a full project controls function within the PMO for Natara, a industrial processing facility in Hartlepool. The scope covered scheduling, cost management, risk analysis and reporting across multiple concurrent capital and operational improvement projects on a complex, COMAH-regulated site. The flagship initiative, Project NEO, required end-to-end project controls support from front-end engineering through to construction, commissioning and handover. Alongside this, SOMA provided controls across a portfolio of concurrent site improvement and compliance projects. ### The challenge The site had no established project controls framework — cost, schedule and risk were managed inconsistently across projects. Multiple concurrent workstreams spanned different engineering disciplines and contractors, each needing integrated oversight. - The client’s corporate stage-gate governance (PPM framework) required formal cost estimates, schedule baselines and progress reporting at each gate. - A COMAH-regulated environment demanding rigorous risk management and full auditability of project controls data. - Limited visibility of actual spend versus forecast at both project and portfolio level. - 9+ concurrent projects across disciplines — from major capital investment to environmental compliance, fire suppression, and demolition. ### Our approach SOMA embedded a dedicated project controls team within Natara’s operations, working as a genuine extension of the client’s team. Our approach was built around four disciplines: - Planning and scheduling — integrated project schedules for Project NEO and the wider portfolio, baseline programmes, weekly progress tracking, milestone reporting aligned to the client’s stage-gate milestones. - Cost management — structured cost controls framework including forecast templates, CTR catalogues, budget tracking and regular actual-versus-forecast reporting. Cost estimates prepared at each stage gate. - Risk analysis — formal risk registers across all active projects, regular risk reviews, risks linked to schedule and cost impacts. On a COMAH-regulated site, every project had a live register feeding directly into decision-making. - Reporting and governance — weekly progress reports, coordination meetings, formal stage-gate presentations, change magnitude assessments, project charters and PPM evaluation criteria. ### What we delivered Across the PMO, SOMA delivered a comprehensive suite of project controls tools and deliverables: - Scheduling: integrated schedules, baseline management, weekly tracking, milestone reporting. - Cost management: estimate and forecast templates, CTR catalogues, budget tracking, actual cost reporting, RFQ templates and procurement support. - Risk management: project risk registers, review facilitation, risk-to-schedule and risk-to-cost linkage, DSEAR risk inputs. - Governance: Project Execution Plan, stage-gate presentations, change magnitude assessments, project charters. - Reporting: weekly progress reports, coordination meeting frameworks, stakeholder RACI matrices. - Document control: numbering system, document registers, correspondence management, meeting minutes templates. ### Project portfolio Beyond the flagship Project NEO, SOMA provided project controls across a diverse portfolio of site improvement and compliance projects: - Project NEO — major capital investment: front-end engineering through construction and commissioning. - Biofilter Upgrade — environmental compliance improvement works. - Fire Suppression Systems — safety-critical infrastructure upgrades. - N₂ Distribution System — process utility infrastructure. - Site Demolition Works — clearance and decommissioning of legacy assets. - Roads and Pathways — site infrastructure improvements. - Site Master Plan — long-term site development and phasing strategy. - Pressure Relief and Condenser Upgrades — process safety improvements. ### Outcomes - Structured, experienced project controls function embedded across the full site portfolio. - Clear accountability through RACI matrices and consistent governance aligned to the client’s corporate PPM standards. - Reliable cost and schedule reporting supporting informed decision-making at every level. - Risk management embedded as a live, ongoing discipline — not a one-off exercise — with registers actively maintained and linked to performance. - Single portfolio-level view of programme health across all concurrent projects. The engagement demonstrated SOMA’s ability to step into a complex, high-stakes environment and deliver steady, practical project controls capability that keeps large programmes on track. Contracted through RRL Group, delivered as SOMA. --- ## Independent Programme-Level Risk Assurance — Sellafield Ltd URL: https://www.somaprojectcontrols.com/case-studies/sellafield-independent-risk-assurance Client: Sellafield Ltd — £1bn+ nuclear capital programme (specific programme confidential, under NDA) · Sector: Nuclear / Decommissioning Services: Independent risk assurance, Delivery confidence review, Contingency robustness review, Programme-level risk management, Senior-stakeholder reporting Expert risk manager providing independent programme-level assurance on a £1bn+ confidential nuclear capital programme — reviewing delivery confidence, interrogating contingency, and delivering structured findings with constructive challenge to senior stakeholders. ### The brief Sellafield Ltd needed an experienced, independent risk manager to conduct a programme-level assurance review of a major nuclear capital programme valued in excess of £1bn. The specific programme is under NDA and is not named in this case study. The client required constructive challenge — someone senior enough to interrogate delivery confidence, pressure-test contingency, and present findings directly to senior stakeholders without softening the picture. Independent risk assurance at this scale in a nuclear context has a particular character. The reviewer has to be sufficiently expert to challenge on the substance — modelling assumptions, risk-mapping logic, correlation treatment — but sufficiently senior to hold the attention of programme directors who are not looking for a compliance report. Too junior and the challenge is dismissed; too detached from delivery and the findings don’t land. The brief was explicit on both counts. ### Our role SOMA was contracted to provide an expert risk manager operating as an independent reviewer — distinct from the teams delivering the programme itself. The role combined hands-on Quantitative Risk Analysis experience with the senior-stakeholder credibility needed to challenge from a position of evidence rather than opinion. The scope targeted the two questions senior decision-makers care about most: is the delivery confidence position realistic, and is contingency sized appropriately for the actual risk profile? Independence mattered in practice as much as in principle. The reviewer was not embedded in the delivery team, not reporting to the programme director, and not evaluated on the programme’s own performance metrics. That separation is what allowed the findings to be framed as decision support for the client rather than as defence of the programme team’s position. ### Our approach A structured assurance approach aligned to the client’s governance cycle: - Delivery confidence review — scrutinising schedule and cost forecast positions against the underlying programme evidence: plans, risk register, historic performance, and scope maturity. - QRA and contingency interrogation — reviewing Monte Carlo modelling assumptions, correlation treatment, risk-mapping discipline, and contingency sizing against P50 / P80 outputs. - Risk-mapping challenge — testing whether identified risks were mapped to the right activities and cost lines, and whether the quantitative inputs held up against the qualitative narrative. - Structured findings — clear, traceable observations with recommended actions, separating items that change the confidence position from items that strengthen governance for the next review cycle. - Senior-stakeholder engagement — presenting findings and recommendations directly to the client’s senior decision-making forum, with constructive challenge rather than commentary. ### What nuclear-context assurance looks like Risk assurance in a nuclear environment is not the same as risk assurance in a generic capital delivery context. The programme schedule is part of a broader safety case. Baseline control sits within a regulated framework. Confidence levels presented to senior stakeholders feed decisions that have public-interest implications as well as commercial ones. That context shapes the nature of the challenge. In practical terms, the review pays particular attention to the relationship between the QRA model and the narrative risk register. A model that quantifies risks the register describes weakly — or a register that describes risks the model omits — is not a model that can support a defensible confidence position. Closing that gap is often where the most valuable assurance work happens. The assurance also tests whether the contingency position is consistent with the way the organisation actually approves drawdown. A P80-sized contingency means nothing if the drawdown approval process releases money at P50 confidence in practice. We look at both the number and the governance that determines how the number behaves during delivery. ### What we delivered The engagement gives the client, on a recurring review cycle: - An independent view of delivery confidence — grounded in evidence, not optimism. - A defensible position on contingency — with assumptions, sensitivities, and downside drivers stated up front. - Structured findings with recommended actions — each tied back to the governance decision it informs. - Senior-stakeholder engagement delivered directly, with constructive challenge that supports better decisions rather than just flagging concerns. ### Why constructive challenge works where compliance reporting doesn’t Much of the assurance effort on major nuclear programmes in the UK is absorbed by compliance reporting — forms completed, gates passed, evidence files populated. That work is necessary but it does not, on its own, change decisions. The value of independent expert challenge is that it surfaces the questions a decision-maker would ask if they had the time and the technical depth to ask them directly. Constructive challenge also protects the delivery team. A risk position that has been independently interrogated and stands up to scrutiny is a risk position the programme director can defend at the next gate without apology. The goal is not to catch the team out — it is to strengthen the position they are presenting, or to surface where that position needs to shift before it is presented as decided. ### Outcomes - Senior decision-makers have an independent, evidence-based view of programme delivery confidence and contingency position. - Structured findings translated directly into governance actions — not abstract recommendations. - Trusted-advisor relationship established with senior stakeholders for ongoing assurance cycles. - Assurance delivered on a recurring cadence aligned to the client’s governance cycle — continuous challenge, not a one-off review that ages out within a quarter. The engagement reflects the kind of work SOMA is built for: senior risk assurance under NDA on complex, high-value nuclear programmes — giving decision-makers the independent view they need, without theatre. --- ## Investment Assurance Ahead of Final Funding Approval URL: https://www.somaprojectcontrols.com/case-studies/investment-assurance-final-funding-approval Client: Confidential — major capital project · Sector: Capital infrastructure Services: Schedule & Cost Assurance, Quantitative Risk Analysis, Investment decision support Independent schedule and cost assurance ahead of a major project’s final investment decision — giving decision-makers confidence in the robustness of the time and cost position. ### The brief SOMA Project Controls was commissioned to provide independent schedule and cost assurance ahead of a major project’s final investment decision. At this critical stage, the client required confidence that the programme and estimate being presented to decision-makers were sufficiently robust to support funding approval. Investment assurance before funding approval is one of the highest-stakes moments in any capital programme. The numbers presented at sanction become the reference point against which all future performance is judged, the contract envelope in which the delivery team operates, and the basis on which the client’s board takes an effectively irreversible commitment. An assurance exercise that is either too light (confirming what the project team already believes) or too heavy (producing a 200-page critique with no decision orientation) fails the client equally. The brief was to deliver something in between — rigorous, independent, and actionable within the timeline of the approval decision. ### What we did SOMA undertook a structured review of the project schedule and cost basis to ensure assumptions were coherent, risks appropriately represented, and uncertainty clearly understood. This work informed the development of a quantitative schedule and cost risk analysis, aligned to the project’s delivery strategy and risk profile. The assurance work was scoped in four layers, each answering a specific governance question: - Schedule integrity review — DCMA 14-point health indicators, logic density, critical path transparency, lag/lead discipline, and resource loading. The question answered: is this a real network or a bar chart dressed up as one? - Cost basis review — estimate class, contingency basis, inflation treatment, escalation assumptions, and exclusions/clarifications register. The question answered: does the cost estimate reflect the scope as defined, or is it a target that the project team is hoping to hit? - Risk profile review — register maturity, risk-to-schedule and risk-to-cost mapping, ownership discipline, and the relationship between identified risks and the contingency provision. The question answered: does the risk register support or contradict the confidence levels being claimed? - Quantitative synthesis — integrated QSRA and QCRA producing P50 and P80 confidence levels, sensitivity analysis on the principal risk drivers, and an explicit reconciliation against the headline figures being presented to the investment committee. ### The analysis output The analysis provided decision-makers with clear visibility of: - Schedule and cost confidence levels - Key risk drivers and sensitivities - The relationship between schedule uncertainty and cost exposure - Areas where the baseline was robust — not just where it was fragile, because a balanced assurance view builds credibility with the delivery team that has to live with the result - Specific recommendations, ranked by the size of their impact on the P80 position, so that the investment committee could focus its scrutiny where it mattered ### How the work informed the decision A good assurance exercise gives decision-makers more than a confidence number — it gives them the ability to ask the right questions. The investment committee was able to challenge the project team on specific assumptions, request clarifications on specific risk allocations, and ultimately approve the project on a basis it genuinely understood rather than on a cover-sheet summary. That is the difference between an assurance review that adds governance value and one that only adds governance theatre. We worked to the rhythm of the investment decision, not to the rhythm of a typical consulting engagement. Findings were shared in working sessions as they emerged, not held back for a final report. This meant the project team had the opportunity to respond to observations before the committee saw them — closing out weaker points, strengthening the justification on stronger points, and arriving at the decision meeting with a baseline that had already been pressure-tested. ### Outcomes - A well-informed investment decision, with a clear understanding of downside risk and contingency requirements. - Independent QSRA and QCRA aligned to the project’s actual delivery strategy, not to a generic template. - Specific, ranked recommendations that the investment committee could use to focus its scrutiny on the points most material to the confidence position. - A baseline the project team understood, accepted, and could defend — rather than one imposed by an external reviewer. The project proceeded to funding approval with improved transparency, strengthened governance, and confidence in the robustness of the time and cost position. --- ## Planning Capability Uplift for a Public-Sector Capital Programme URL: https://www.somaprojectcontrols.com/case-studies/public-sector-planning-capability-uplift Client: Confidential — UK public-sector capital programme · Sector: Public sector Services: Independent planning assurance, Schedule review & challenge, Capability uplift Independent planning assurance and capability uplift across a live capital works portfolio — practical outcomes, not theoretical best practice. ### The context Large public-sector capital programmes operate under constant pressure: funding scrutiny, governance requirements, multiple contractors, and limited tolerance for uncertainty. SOMA Project Controls was engaged to provide independent planning assurance and capability uplift across a live capital works portfolio. The objective was not to introduce heavyweight systems, but to ensure that existing planning practices reliably supported decision-making, governance, and delivery confidence. Public-sector delivery organisations face a specific controls challenge. Funding bodies, political stakeholders and the National Audit Office all have a legitimate interest in how programmes are tracking — and each expects a different view of the same data. A planning function that cannot produce a consistent, defensible answer to the question “how is this programme performing?” becomes a liability rather than an asset, regardless of how competent the delivery team is. ### Our role SOMA acted as an independent advisor and improvement partner, working alongside the client’s planning function to: - Assess whether current planning practices were fit for purpose - Improve the credibility and consistency of programme information - Strengthen the ability to challenge and assure contractor schedules - Establish clear, proportionate planning expectations across the portfolio ### What we did Our work was structured across five integrated areas: - Planning Capability Review — one-to-one engagement with the planning team to understand current processes, challenges, and strengths. - Schedule review & challenge — independent review of contractor schedules, focusing on logic, structure, update discipline, and forecast reliability. - Portfolio reporting assessment — how programme data flowed into portfolio-level reporting and senior decision-making. - Planning standards — development of clear, pragmatic guidance on what “good” looks like at different project stages. - Framework Development — design of focused training and tools centred on planning fundamentals and effective programme assurance. ### Schedule challenge: what we looked for Contractor schedule assurance is the most visible part of a public-sector planning function — and the most frequently under-done. A programme team that receives contractor schedules without the capability to challenge them is, in practice, delegating the truth about programme status to the contractor. That is not necessarily a problem on a well-governed contract, but it becomes a significant exposure when performance trajectories start to diverge from the baseline. The review focused on the practical markers of schedule credibility: logic density and network integrity, use of constraints, discipline of progress updates, treatment of float, and whether the critical path as presented actually drove completion or was an artefact of hard-coded milestones. These are not abstract quality measures — they are the specific points at which optimism, omission or misrepresentation creep into the story a schedule tells. ### Capability uplift: training that survives the training course Most planning-capability programmes fail not because the training is poor but because the operating model after training is unchanged. People return to a workplace with the same templates, the same reporting cadence, and the same tolerance for weak schedules — and within a quarter the lessons have evaporated. The framework we designed tied training content directly to the assurance artefacts the planning team would produce: schedule challenge templates, review meeting agendas, evidence checklists. The learning was not abstract planning theory — it was “here is the form you will be expected to complete after a schedule review, here is what each section requires, here is how to populate it.” That format makes the training stick because it is immediately useful on Monday morning. ### Why proportionate planning standards matter The temptation with planning standards on a large portfolio is to produce a single definitive manual that covers every project type at every stage. The result is a document nobody reads and a team that quietly reverts to whatever they did before. We took the opposite approach: short, stage-specific guidance that tells a planner exactly what is expected at their current point in the lifecycle, and leaves the detailed technique to professional judgement. The test of good planning standards is whether a new planner, starting on a project at feasibility or at construction, can pick them up on their first day and know what to produce by their first review. If the standards answer that question, they are useful. If they don’t, they are governance furniture. ### Outcomes - Improved confidence in programme information used for governance and oversight. - Clearer, more consistent planning expectations across contractors and projects. - Stronger internal capability to review, challenge, and assure schedules. - Improved visibility at portfolio level, supporting more informed decisions. - A foundation for sustainable, continuous improvement rather than one-off fixes. - Training and tooling designed around the actual assurance artefacts the planning team produces — so the capability uplift survives beyond the engagement itself. The engagement was delivered efficiently, with minimal disruption, and focused on practical outcomes rather than theoretical best practice. --- ## Programme Risk Lead — National Highways QRA Framework URL: https://www.somaprojectcontrols.com/case-studies/national-highways-qra-framework Client: National Highways (via AtkinsRéalis) · Sector: Highways / major infrastructure Services: Programme-level QRA leadership, QCRA / QSRA delivery, Risk governance uplift, Modelling assurance, Risk-system transition (Xactium → RiskHive) Programme-level Quantitative Risk Analysis leadership across a £1bn+ regional investment portfolio — moving QRA reporting from output decks to decision-grade insight. ### The brief AtkinsRéalis holds the Quantitative Risk Analysis commission that supports National Highways’ Regional Investment Programme. With £1bn+ of major schemes in play and governance oversight across multiple delivery partners, the commission needed senior QRA practitioners who could both run the modelling discipline at project level and act as a programme-level subject-matter expert at portfolio scale. SOMA was engaged to lead Quantitative Cost and Schedule Risk Analysis (QCRA / QSRA) delivery across the regional portfolio — challenging modelling assumptions, aligning quantitative outputs with budgets and governance reporting, and strengthening the way QRA evidence fed into decision-making. ### Our role Two overlapping roles across the engagement: - Programme Risk Lead — portfolio-level QRA subject-matter expert, setting QCRA / QSRA standards, reviewing supplier analyses, and presenting quantitative risk insight to senior regional stakeholders. - Regional Risk Assurance Lead (Yorkshire & North East) — project controls (risk) assurance across a >£1bn regional portfolio, governance oversight of supplier QCRA / QSRA activity, independent reviews and quantitative risk health-checks, and monthly / quarterly assurance reports. - Interim Regional Risk Manager — earlier in the commission, seconded to oversee multiple highway schemes: reviewed and enhanced regional risk governance, embedded a structured risk-drawdown process, delivered training and workshop facilitation, and improved reporting alignment. ### What we delivered The engagement combined hands-on QRA delivery with governance uplift: - QCRA run monthly and QSRA quarterly across the regional portfolio, with outputs calibrated to project budgets and governance milestones. - Bespoke KPI templates and automated Safran inputs — simplifying QRA assurance activity and reclaiming weeks of project-team time over the commission. - Structured risk-drawdown process embedded across regional schemes, giving delivery teams a defensible way to release contingency. - System transition from Xactium to RiskHive, with supply-chain risk resources onboarded and upskilled on the new tooling. - Portfolio-level QRA coaching and 1-to-1 mentoring with regional risk practitioners, lifting quantitative maturity across the commission. ### What changed The QRA function moved from a presentation of outputs to a presentation of insight. Assumption challenge, risk mapping, and the link between schedule uncertainty and cost exposure became the centre of QRA reviews — not the Monte Carlo curve itself. Senior regional leaders now use QRA as a decision tool, not a governance artefact. ### Outcomes - QRA reviews recognised as value-adding and decision-focused — not output theatre. - Weeks of project-team time reclaimed through bespoke KPI templates and Safran automation. - Contingency governance strengthened through structured drawdown and traceable modelling assumptions. - Supply-chain risk resources onboarded and upskilled through the Xactium → RiskHive transition. - Portfolio-level QRA maturity lifted through coaching and mentoring across regional teams. The commission is an anchor engagement for SOMA — programme-level QRA leadership at portfolio scale, on UK major infrastructure, delivered alongside one of the country’s largest engineering consultancies. --- ## PMO Risk Transformation — Northumbrian Water URL: https://www.somaprojectcontrols.com/case-studies/northumbria-water-pmo-risk-transformation Client: Northumbrian Water (via Gardiner & Theobald) · Sector: Water & utilities Services: PMO risk leadership, Risk process transformation, Risk register governance, Opportunity Management training, Contingency alignment Risk transformation inside Northumbrian Water’s PMO function — 400+ projects, £350m portfolio, 70 man-weeks of operational effort reclaimed and a 96% uplift in risk-identification capability. ### The brief Northumbrian Water’s PMO was running a £350m project portfolio spanning 400+ active projects across the business. Risk management existed, but identification discipline, register quality and contingency alignment were uneven — and the sheer volume of governance activity was consuming operational capacity faster than it could be created. SOMA, engaged through Gardiner & Theobald, was brought in to lead risk transformation inside the PMO: rebuild the risk process, upskill the team, and realign contingency planning with the actual risk exposure sitting on the portfolio. ### Our role SOMA acted as PMO Risk Lead, reporting to the Risk Management Director and leading a team of 5+ risk professionals across the portfolio. The scope covered: - Process refinement — working with the Risk Management Director to redesign identification, quantification and reporting processes, removing duplicated effort and embedding proactive risk identification in the PMO cadence. - Register governance — maintained comprehensive risk registers across 400+ projects, with consistent metalanguage, clear ownership, and alignment between qualitative scoring and quantitative exposure. - Tailored workshops — facilitated risk workshops sized to the project rather than the template, with different depth for capital, regulatory, and operational workstreams. - Opportunity Management training — a formal training programme designed to shift the culture from threat-only to threat-plus-opportunity, and build identification capability across the PMO. - Senior reporting — progress reporting to senior leadership, with a clear line from individual-project risk exposure through to portfolio-level contingency position. ### What changed Two numbers tell the story. Operational efficiency: 70 man-weeks of PMO effort reclaimed by optimising the risk management processes and removing duplication. Capability: a 96% uplift in staff risk-identification proficiency following the Opportunity Management training. Behind the numbers, contingency planning was realigned with the actual risk exposure sitting across the 400+ projects — reducing the gap between provision and reality and lowering the probability of financial overrun. ### Outcomes - 70 man-weeks of operational effort reclaimed across the PMO. - 96% increase in staff risk-identification proficiency through Opportunity Management training. - Contingency planning aligned with realistic risk exposure — reducing financial overrun exposure. - Consistent risk register discipline across 400+ projects on a £350m portfolio. - Team of 5+ risk professionals led and developed through the transformation. A programme of process discipline, proper training, and steady leadership — the unglamorous work that actually moves risk maturity. SOMA through and through. --- ## What a CADMID engagement looks like — methodology walkthrough URL: https://www.somaprojectcontrols.com/case-studies/cadmid-engagement-methodology Client: Methodology piece — not a specific past engagement · Sector: Defence Services: Independent QRA, EVMS implementation review, IPA Gateway readiness, Through-life cost modelling A practitioner walkthrough of how SOMA structures project controls work across the UK MoD CADMID lifecycle — from option-level QRA at Concept to sustainment forecasting In-Service — and the evidence shape that survives IPA Gateway and NAO scrutiny. ### How this piece is framed This is not a write-up of a specific past project. UK defence work sits behind layered confidentiality regimes — MoD security caveats, supplier non-disclosure, SSRO commercial sensitivity — and even an anonymised case description can identify a programme to anyone who knows the sector. Rather than thread that needle, we have written this as a methodology walkthrough: what a CADMID engagement looks like in shape, what we typically do at each phase, what the evidence has to survive, and what we explicitly do not do. The detail is drawn from real practice; the framing is deliberately general. For the underlying lifecycle and assurance framework, see our guide to project controls in defence, which sits inside the wider defence topic hub. This piece is the operational counterpart — what an engagement actually involves week-by-week, not what the framework is. ### Engagement shape A typical CADMID engagement falls into one of four scopes, often in combination. Independent QRA at Concept or Assessment phase — modelling option-level cost and schedule uncertainty under conditions where the requirement is still moving and the technical solution is not yet fixed. EVMS implementation review at Demonstration — testing whether the Performance Measurement Baseline, earning rules and reporting cadence will produce signals an SRO can act on, rather than just signals that pass an audit. IPA Gateway readiness — assembling the controls evidence pack ahead of Gate 0 through Gate 5, with the QRA, schedule integrity check, risk register and EVMS state documented to the depth IPA reviewers expect. Through-life cost modelling at In-Service — sustainment forecasting that links operating cost, capability availability and disposal liability into a single model the platform owner can defend at the annual Equipment Plan review. Most engagements blend two or three of these. A programme moving from Assessment into Demonstration will typically want the QRA refreshed, the EVMS approach pre-mortemed, and a Gateway readiness check run against the next IPA gate — not as three separate workstreams but as a single coordinated piece of work. ### What we do at each CADMID phase The controls work at each CADMID phase is different in kind, not just in volume. Treating the lifecycle as one long engagement with a sliding scale of effort misses the point — each phase asks different questions of the controls function, and the deliverables look different as a result. - Concept — Option-level QRA against a still-moving requirement. The schedule is indicative, the cost estimate is parametric, and the dominant uncertainty is technical feasibility rather than execution risk. We work in confidence ranges, not point estimates, and the output is a comparison of options rather than a baseline forecast. The risk register at this stage is dominated by requirement-volatility risks and capability-trade-off risks, and the QRA model treats those explicitly rather than burying them in three-point ranges on activities that do not yet exist. - Assessment — The requirement is firming up and a preferred solution is emerging. QRA tightens: three-point estimates become defensible at activity and cost-element level, correlation between schedule and cost can be modelled honestly, and the P50/P80 outputs start to mean something for Main Gate funding. We also start to prepare the controls architecture for Demonstration — work breakdown structure, cost breakdown structure, the contract data items that will need EVMS clauses, and the schedule shape that a downstream prime can build against. - Demonstration — The prime contract is in place and EVMS reporting begins. Our role here is implementation review rather than implementation — testing whether the Performance Measurement Baseline is internally consistent, whether the earning rules are deliverable-based rather than judgement-based, and whether the integrated cost-schedule reporting will produce a CPI/SPI signal that genuinely reflects execution. We benchmark the EVMS against AACE 11R-88 or the MoD’s own EVMS guidance, depending on which is contractually referenced, and we look hard at the gap between the technically compliant report and the programme’s actual delivery reality. - Manufacture — Reporting cadence is established, and the controls question shifts to forecast quality. We focus on the estimate-to-complete discipline (is the ETC genuinely re-baselined each period, or is it being trended from the original budget?), variance analysis (are the explanations of CV and SV traceable to specific work packages, or are they narrative?), and management reserve / contingency drawdown (is the controlling level for management reserve held at the right tier, and is the drawdown process being followed?). On programmes at this stage, the IPA Gateway is typically Gate 4 — Readiness for Service — and we structure the controls evidence pack around that gate’s specific tests. - In-Service — The contract has moved from acquisition to support, and the controls discipline is through-life cost management rather than baseline-versus-actual reporting. We build sustainment forecasts that link availability targets, spares consumption, obsolescence risk and mid-life-update timing into a coherent ten-to-twenty-year view. The cost owner is typically the platform Delivery Team, and the model has to survive Equipment Plan scrutiny by the MoD’s Cost Assurance and Analysis Service. - Disposal — The smallest of the six phases in terms of controls effort, but with its own specific shape. Disposal cost is dominated by regulatory and environmental obligations — nuclear, munitions, hazardous materials — and the controls work is a hybrid of decommissioning cost estimation and long-tail liability modelling. We treat it as a project in its own right rather than as the tail end of In-Service. ### What good evidence looks like On a defence programme, the controls function is producing evidence for at least three distinct audiences. The Senior Responsible Owner needs decision-grade information that can be acted on inside the current quarter. The IPA Gateway team needs structured evidence that the programme’s Delivery Confidence Assessment is defensible — traceable from the schedule, QRA, risk register and EVMS through to a single narrative about deliverability. And the National Audit Office, if the programme is ever reviewed, will read those same documents two or three years later with the benefit of hindsight and the absence of pressure to be polite. We structure deliverables with all three in mind. Every QRA report is written to be intelligible to the SRO on a single page, defensible at IPA in twenty pages, and complete enough that an NAO reviewer can reconstruct the methodology from the appendices alone. The same logic applies to the EVMS implementation report, the schedule integrity check, and the risk register narrative. The discipline is not to write three different documents — it is to write one document whose layers are explicit, so each reader can find what they need without wading through what they don’t. On Government Major Projects Portfolio programmes, this also means writing in a form that supports the Major Projects Review Process inside the MoD and that lines up with the SSRO’s cost-reporting taxonomy on the contract’s commercial side. Getting the cost breakdown structure right at programme acceptance is much cheaper than retrofitting it when the first SSRO Quarterly Contract Report is due. ### What we don’t do It is worth being explicit about scope limits. We do not write the technical solution — we are project controls practitioners, not systems engineers or platform designers, and we do not draft the requirement, the architecture, or the technical specification. We do not sign technical safety cases — nuclear, munitions, airworthiness or marine safety cases are signed by the appropriately qualified authority, not by an independent controls reviewer. We do not take prime contractor responsibility — we work alongside the prime’s controls function on the client side, or as an independent reviewer; we do not stand in the prime’s reporting line or accept delivery liability for the platform itself. This matters because the failure mode in independent assurance is scope creep. A controls reviewer who starts giving technical opinions on the engineering solution, or who lets their EVMS commentary drift into a critique of the prime’s delivery strategy, has stopped being independent — and the evidence they produce stops being usable at gateway review. Staying inside the controls remit is what makes the independence credible. ### How engagements typically run A typical engagement runs in three phases. Phase 1 — review, around four weeks. This is the diagnostic phase: walk the schedule, walk the risk register, walk the EVMS architecture if one exists, sit in two reporting cycles, and produce a written assessment of where the controls function is and what the highest-leverage interventions would be. The output is a short report and a workshop with the controls lead and the SRO. We do not start changing things in this phase; we are deciding what to change. Phase 2 — instrumentation, around eight weeks. This is where the work actually happens. Depending on the engagement, that might mean rebuilding the QRA model, redesigning the EVMS earning rules, restructuring the risk register, producing a Gateway evidence pack, or some combination. The phase is bounded — it has a defined output and a defined end — and the deliverables are documents and models that survive after we leave, not bespoke processes that only work while we are in the room. Phase 3 — sustainment, ongoing. Some clients run this as a monthly retainer, some as quarterly check-ins, some as called-off support around specific gates and reviews. The shape varies, but the pattern is consistent: a light-touch presence that keeps the controls function on its trajectory rather than letting it slowly revert to the state it was in before the engagement started. This is the phase that determines whether the Phase 2 work persists or evaporates. Most CADMID engagements that produce real change are Phase 1 + Phase 2 + a defined Phase 3. Engagements that stop at Phase 2 typically lose half of the gain within a year. Engagements that try to skip Phase 1 typically over-engineer the wrong problem. ### Outcomes - Controls evidence pack assembled to a depth that survives IPA Gateway scrutiny rather than just passing internal review. - EVMS implementation tested against AACE 11R-88 / MoD EVMS guidance for genuine signal quality, not just contractual compliance. - QRA models that are defensible at Main Gate funding and re-runnable as the risk profile changes across CADMID phases. - Through-life cost forecasts that withstand Cost Assurance and Analysis Service review and align with the platform’s Equipment Plan position. - A controls function whose deliverables are intelligible to the SRO, defensible at IPA, and complete enough for NAO scrutiny — without writing three different documents. Defence project controls work lives or dies on the credibility of the evidence it produces under independent review. If that is the conversation you are trying to have on your programme, it is the one we are best at having. --- ## What a QRA engagement looks like — methodology walkthrough URL: https://www.somaprojectcontrols.com/case-studies/qra-engagement-methodology Client: Methodology piece — not a specific past engagement · Sector: Energy & industrial construction Services: Independent Quantitative Risk Analysis (QSRA / QCRA / CSRA), Risk workshop facilitation, QRA model validation review, Contingency sizing & drawdown advisory A practitioner walkthrough of how SOMA structures a Quantitative Risk Analysis engagement — from kickoff and data gathering, through workshop facilitation and Monte Carlo modelling, to board-ready reporting that holds up under independent challenge. ### How this piece is framed This is not a write-up of a specific past project. Most of the QRA work SOMA does sits under NDA, often at investment-decision or gateway moments where the confidence levels presented are commercially sensitive. Rather than anonymise to the point of meaninglessness, we have written this as a methodology walkthrough: what a QRA engagement looks like in shape, what we do at each stage, what the evidence has to survive, and what we explicitly do not do. The detail is drawn from real practice; the framing is deliberately general. For the underlying technique — distributions, correlation, three-point calibration and the things that quietly distort a P80 — see our honest guide to QRA, which sits inside the wider energy topic hub. This piece is the operational counterpart: what an engagement actually involves week-by-week, not what the maths is. ### Engagement shape A typical QRA engagement falls into one of four scopes, often in combination. Independent QRA — a fresh, ground-up Quantitative Schedule and / or Cost Risk Analysis carried out as an independent reviewer, separate from the team that built the schedule and estimate. This is the highest-effort shape and the one that matters most at sanction or final investment decision. Integrated Cost & Schedule Risk Analysis (QCSRA) — a single coordinated model that treats cost and schedule uncertainty together, with correlation handled explicitly rather than implicitly through duplicated risks. Workshop facilitation — running the risk identification and three-point estimation workshops that feed somebody else’s model, where the client needs a neutral chair who can challenge without being political. Validation review — an audit of a QRA model someone else has built, focused on whether the headline confidence levels are defensible against the inputs. Most engagements blend two or three of these. A pre-FID client will typically want an independent QCSRA backed by workshop facilitation; a programme moving into gateway review will typically want a validation review of the prime contractor’s model alongside an independent sanity check. ### What we do at each stage A QRA engagement runs in six recognisable stages. Each one has its own deliverable and its own failure mode — skipping a stage is usually how a QRA ends up producing a curve that nobody trusts. - Kickoff and scoping — one short workshop with the project director and the controls lead to confirm scope, audience, decision being supported, model architecture (cost-only / schedule-only / integrated), software (Safran, Primavera Risk Analysis, @Risk, RiskHive), risk taxonomy, and the reporting cadence. The output is a one-page QRA brief that everyone signs. Most QRA arguments later in the engagement trace back to a missing line in this brief. - Data gathering — schedule, cost estimate, risk register, basis of estimate, contract terms, prior QRA reports if any, and the assumption log. We read all of it before the first workshop. A workshop facilitator who has not read the schedule cannot challenge a duration, and a QRA modeller who has not read the BoE cannot challenge a unit rate. This is the unglamorous stage that determines how good the model can be. - Risk workshop — facilitated identification and three-point estimation. We run threats and opportunities separately, with a structured taxonomy (technical, commercial, regulatory, schedule, weather, interface), and we calibrate the three-point ranges against historic performance data where it exists. Ranges are challenged in the room; "we usually use ±10%" is not an answer that survives the workshop. - Modelling — inherent uncertainty modelled as three-point distributions on activities and cost line items; discrete risks modelled as probability-weighted impacts that only fire if the risk materialises; correlation modelled explicitly where the evidence supports it. We run sensitivity analysis on the correlation assumption and the top-five risk drivers, so the headline P80 is not dependent on a hidden judgement call. - Reporting — a written QRA report that the SRO can read in ten minutes and a technical reviewer can audit in twenty pages. P50 and P80 for cost and schedule; tornado of the principal drivers; reconciliation against the headline figures the project team is presenting; explicit list of model limitations and excluded scope. Every assumption is traceable back to the workshop record. - Board / steering presentation — the QRA presented to senior decision-makers as decision support, not as a deck of output charts. The objective is that they leave the room understanding what would have to change for the confidence position to change — not just what the current confidence position is. ### What good evidence looks like A defensible QRA satisfies three audiences at once. The project director needs an answer they can act on inside the current quarter — size of contingency, location of biggest risk, and whether the baseline is realistic. An independent reviewer (IPA, NAO, internal audit, an investment committee member with a sceptical eye) needs to be able to reconstruct the methodology from the appendices alone and form their own view on whether the P80 stands up. And the project team that built the schedule and estimate needs to recognise their work in the model — a QRA that the delivery team does not accept stops being useful as a governance tool, however technically correct it is. In practice that means following AACE International recommended practice on Monte Carlo simulation — separating inherent uncertainty from discrete risk events (AACE 40R-08 and 57R-09), defending distribution shapes against historic data where it exists, declaring correlation explicitly, and stating the boundaries of the model rather than presenting a P80 as if it were a forecast. We also benchmark the model against the project’s contractual reporting cadence — a QRA whose outputs cannot be re-run when the risk register updates is a one-off snapshot, not a governance asset. Where the QRA supports a sanction decision or a gateway review, the report is structured so that the headline page, the methodology summary, the assumptions log and the sensitivity tornado are each self-contained. That way a reader who only has fifteen minutes still leaves with a defensible view of the confidence position, and a reader with two hours can audit every input. ### What we don’t do It is worth being explicit about scope limits. We do not author the project schedule — if the schedule has structural problems, we say so and recommend a schedule integrity review before the QRA, rather than quietly fixing the schedule and then modelling our own version of it. We do not author the cost estimate — if the basis of estimate has structural gaps, we surface them as a model limitation rather than back-filling assumptions to make the QRA run. We do not negotiate contingency on behalf of the client — the QRA tells the client what their confidence position is; what they then do with that information at the commercial table is their call, not ours. This matters because the failure mode in independent QRA is scope creep. A reviewer who starts adjusting the inputs to get a "better" answer, or who lets workshop facilitation drift into giving delivery advice, has stopped being independent — and the confidence levels stop being defensible at gateway or board challenge. Staying inside the QRA remit is what makes the independence credible. ### How engagements typically run A QRA engagement runs in one of three sizes. A four-week engagement — single QRA cycle, one workshop, one report, one board presentation. Right-sized for a focused decision point: a sanction QRA, a refresh ahead of a gate, or an investment-committee challenge. A four-week run is enough to deliver a credible independent QRA on a single project where the schedule and estimate already exist; it is not enough to rebuild a model from scratch on a programme where the controls maturity is low. An eight-week engagement — the typical shape for a more substantial piece of work. Two workshops (one for threats, one for opportunities and validation), a fuller data-gathering phase, an integrated cost-and-schedule model, and a phased reporting cadence with a working-draft review before the formal board presentation. This is the shape that suits pre-FID assurance, gateway readiness, or any situation where the QRA is doing real work to shape the contract or the baseline rather than just confirming a position. Ongoing retainer — monthly or quarterly QRA refreshes against a live model the project team continues to maintain. The QRA stops being a one-off document and becomes a maintained asset that tracks the confidence position as risks resolve, scope firms up, and actuals come in. This is where QRA earns its keep on a multi-year programme — a frozen P80 from sanction loses value within three months; a maintained model continues to inform governance throughout delivery. Most engagements that produce real change are a defined Phase 1 (four or eight weeks) plus a Phase 2 retainer at a lower cadence. Engagements that stop at the report typically lose half of the value within a quarter, because the model becomes stale faster than the project moves. ### Outcomes - A QRA that the project director, an independent reviewer and the delivery team all recognise as defensible — not a model that needs to be re-explained at every audience change. - Confidence levels (P50 / P80) that are traceable from workshop record through model inputs to headline output, with no hidden judgement calls in the correlation or distribution assumptions. - AACE 40R-08 / 57R-09 alignment on Monte Carlo methodology, distribution discipline and sensitivity analysis — the framework an investment committee or gateway reviewer expects. - A live QRA model the project team can continue to maintain after the engagement, rather than a frozen snapshot that ages out within three months. - Explicit scope limits stated in the report — what the QRA covers, what it deliberately excludes, and the assumptions a reader has to accept for the confidence position to hold. QRA done well is decision support, not output theatre. If the conversation you are trying to have on your programme is whether the P80 is real — and what would have to change for it not to be — that is the one we are best at having. --- ## What a planning & scheduling engagement looks like — methodology walkthrough URL: https://www.somaprojectcontrols.com/case-studies/scheduling-engagement-methodology Client: Methodology piece — not a specific past engagement · Sector: Infrastructure Services: Schedule baseline review, DCMA 14-point assessment, Schedule integrity audit, Primavera P6 implementation support A practitioner walkthrough of how SOMA structures a planning and scheduling engagement — from baseline review and DCMA 14-point assessment through schedule integrity audit and P6 implementation support — with the evidence discipline a steering group and a contractual reviewer both expect. ### How this piece is framed This is not a write-up of a specific past project. Schedule assurance work typically sits inside live commercial relationships — contractor versus client, or main contractor versus subcontract — and naming the programme would identify the parties to anyone who knows the sector. Rather than thread that needle, we have written this as a methodology walkthrough: what a planning engagement looks like in shape, what we do at each stage, what the evidence has to survive, and what we explicitly do not do. For the underlying technique — logic density, float discipline, the DCMA 14 metrics and what each one actually tells you — see our guide to reading a DCMA 14 result properly, which sits inside the wider infrastructure topic hub. This piece is the operational counterpart: what an engagement actually involves week-by-week, not what the metrics are. ### Engagement shape A typical planning and scheduling engagement falls into one of four scopes, often in combination. Baseline review — independent assessment of a proposed baseline schedule ahead of contract award or gate approval, focused on whether the network can actually carry the activity it is being asked to carry. DCMA 14-point assessment — a structured health check against the Defense Contract Management Agency’s 14 schedule integrity metrics, with each fail or borderline result interpreted in the context of the specific schedule rather than treated as an abstract scorecard. Schedule integrity audit — a deeper diagnostic on a live schedule that is producing reports the project team no longer trusts, looking at logic completeness, float behaviour, constraint use, progress discipline and forecast reliability. Primavera P6 implementation support — standing up the tool properly on a programme that is either new to P6 or has inherited a P6 environment that has drifted, with the global data, enterprise structure, layouts and reporting cadence set up to support the project rather than to fight it. Most engagements blend two or three of these. A pre-award baseline review will typically include a DCMA 14 run; a schedule integrity audit on a struggling programme will often surface P6 implementation problems that need fixing alongside the logic issues. ### What we do at each stage A planning engagement runs in five recognisable stages. Each one produces a specific deliverable; skipping one is how a planning review ends up producing a report nobody can act on. - Kickoff and scoping — short workshop with the project director, planning lead and (where relevant) the contractor’s planner to confirm scope, audience, the contractual context (NEC4, FIDIC, JCT, MOD ASCEND), the schedule files available, and the decisions the work is supporting. The output is a one-page scoping brief. Most arguments later in the engagement trace back to a missing line in this brief. - Data gathering — schedule files (XER, XML, native MSP), contract programme, baseline submission, progress updates, change log, risk register, basis of schedule, and prior assurance reports if any. We read the schedule before we open the tool — the basis of schedule and the activity coding rationale tell you more about the credibility of the network than any metric does. - Diagnostic — the DCMA 14 metrics run, plus the qualitative checks that the metrics do not capture: critical path realism, calendar discipline, constraint use, progress override behaviour, float distribution shape, and the relationship between the logic network and the WBS. A schedule can pass 13 of the DCMA 14 metrics and still be unfit for purpose if the critical path is an artefact of a hard-coded milestone. - Reporting — a written assessment with each finding ranked by impact on the delivery confidence position. Findings are separated into structural issues (the network cannot do what it is being asked to do), discipline issues (the network could be fit for purpose but is not being maintained that way) and presentational issues (the schedule produces reports that obscure rather than reveal). The recommendations are sized to the gap, not to the available budget. - Remediation support — where the engagement extends past the diagnostic, supported re-baselining, logic clean-up, P6 environment fixes, or coaching with the in-house planner. We do this alongside the project team rather than instead of them — a remediated schedule that nobody on the project understands is worse than the original. ### What good evidence looks like A defensible planning assurance product satisfies three audiences. The project director needs to know whether the schedule is telling the truth about delivery — and if not, where the gap is. The contractual reviewer (NEC4 supervisor, FIDIC engineer, IPA gateway team) needs structured evidence that the schedule meets the contractual integrity standard — logic-driven critical path, sub-clause-compliant progress mechanism, traceable change history. The planner who built the schedule needs to recognise the assessment as fair — a planning review the in-house team rejects stops being useful as a governance tool. In practice that means running the DCMA 14-point assessment to its actual specification — logic density, leads, lags, relationship types, hard constraints, high float, negative float, high duration, invalid dates, resource loading, missed tasks, critical path test, critical path length index, baseline execution index — with each metric reported as a number and a narrative. A schedule with 9% open ends is not the same problem as one with 22%, and a planning report that just lists colour codes against thresholds is doing only half the work. Where the work supports a contract action (acceleration claim, extension of time, compensation event challenge, gateway review), the report is structured so that the headline finding, the methodology, the schedule extract and the metric run are each self-contained and traceable. That way a contractual reader can audit the chain from a single sub-clause back to a specific activity in the network without taking a guided tour. ### What we don’t do It is worth being explicit about scope limits. We do not act as the contractor’s programme manager — we work alongside the planning function on the client side, or as an independent reviewer; we do not own the delivery commitment. We do not sign off the schedule as fit for purpose if our diagnostic shows it is not — we tell the client what would have to change, but the sign-off remains with the accountable party. We do not draft contract notices on behalf of a client or contractor — a delay analysis can inform a notice, but the notice itself is a commercial document that sits with the appropriate authority. And we do not perform forensic delay analysis for litigation as an expert witness role unless that is the scope explicitly agreed at engagement — the discipline and reporting requirements are different and conflating them weakens both products. This matters because the failure mode in independent planning assurance is drift. A reviewer who starts rebuilding the schedule on their own laptop, or whose DCMA 14 commentary turns into a critique of the contractor’s strategy, has stopped being independent — and the assessment stops being usable at contractual challenge. Staying inside the planning remit is what makes the independence credible. ### How engagements typically run A planning engagement runs in one of three sizes. A four-week engagement — single schedule assessment, DCMA 14 run, written report, working-session debrief. Right-sized for a focused decision point: a pre-award baseline check, a gateway readiness assessment, or a sanity check on a contractor schedule that has just become contentious. A four-week run is enough to produce a credible independent assessment; it is not enough to rebuild a schedule from scratch on a programme where the planning maturity is low. An eight-week engagement — the typical shape for a more substantial piece of work. Baseline review plus DCMA 14 plus a P6 environment assessment, plus a structured remediation plan and a coaching pass with the in-house planner. This is the shape that suits programmes coming out of a gateway with planning recommendations attached, or contractors preparing a re-baseline submission they need to defend. Ongoing retainer — monthly or quarterly schedule reviews against a live programme, with the planning lead supported through update cycles, change cycles and reporting cycles. The assurance stops being a one-off document and becomes a maintained discipline that tracks schedule integrity as the programme moves. This is where planning assurance earns its keep on a multi-year programme — a frozen baseline review from sanction loses value within six months; a maintained discipline continues to inform governance throughout delivery. Most engagements that produce real change are a defined Phase 1 (four or eight weeks) plus a Phase 2 retainer at a lower cadence. Engagements that stop at the report typically see the discipline drift back within two quarters, because the operating model after the report is unchanged. ### Outcomes - A schedule assessment the project director, a contractual reviewer and the in-house planner all recognise as fair — not a report that needs to be re-explained at every audience change. - DCMA 14-point results interpreted in the context of the specific schedule, with each metric reported as a number and a narrative rather than just a colour code. - A clear separation between structural, discipline and presentational findings — so that remediation effort is sized to the actual problem rather than spread evenly across symptoms. - Critical path realism tested explicitly, with the relationship between the logic network, the WBS, and the contractual milestones traceable end-to-end. - A planning function that retains the capability after the engagement — coaching alongside the planner rather than producing a parallel schedule the project team does not understand. Planning assurance done well is the difference between a programme that knows its own delivery position and one that finds out at variance review. If that is the conversation you are trying to have on your schedule, it is the one we are best at having. --- ## What an EVM engagement looks like — methodology walkthrough URL: https://www.somaprojectcontrols.com/case-studies/evm-engagement-methodology Client: Methodology piece — not a specific past engagement · Sector: Infrastructure Services: EVMS readiness review, Performance Measurement Baseline (PMB) validation, Monthly EVM reporting audit, Estimate-at-Completion (EAC) challenge A practitioner walkthrough of how SOMA structures an Earned Value Management engagement — from EVMS readiness review and PMB validation, through monthly reporting audit, to EAC challenge — with the evidence discipline that survives ANSI/EIA-748 scrutiny and an independent gateway reviewer. ### How this piece is framed This is not a write-up of a specific past project. EVM engagements typically sit inside contracts where the cost performance position is commercially sensitive — acquisition programmes, regulated capital schemes, prime-and-sub arrangements with EVM flowed down through the supply chain. Rather than anonymise to the point of meaninglessness, we have written this as a methodology walkthrough: what an EVM engagement looks like in shape, what we do at each stage, what the evidence has to survive, and what we explicitly do not do. For the underlying technique — PV / EV / AC, CPI / SPI behaviour, why a Cost Performance Index can be lying, and what a recoverable EAC actually looks like — see our guide to when CPI is lying, which sits inside the wider infrastructure topic hub. This piece is the operational counterpart: what an engagement actually involves week-by-week, not what the formulae are. ### Engagement shape A typical EVM engagement falls into one of four scopes, often in combination. EVMS readiness review — ahead of a contract that requires Earned Value Management, an assessment of whether the project organisation, system and people can actually run EVM to the required standard. Performance Measurement Baseline (PMB) validation — once the WBS, OBS, control accounts, work packages and earning rules have been set, an independent check that the PMB is internally consistent, contract-compliant, and capable of producing signals an SRO can act on. Monthly EVM reporting audit — a recurring assurance pass on the live monthly reporting cycle, focused on whether the CPI and SPI numbers in the report genuinely reflect what is happening in delivery. EAC challenge — a structured interrogation of the Estimate-at-Completion, separating trend-based extrapolation from genuine bottom-up re-estimation, and testing whether the EAC is recoverable in the form the project team is presenting it. Most engagements blend two or three of these. A pre-contract EVMS readiness review will typically lead into a PMB validation once the baseline is built; an audit engagement on a live programme will almost always surface EAC issues that need their own structured challenge. ### What we do at each stage An EVM engagement runs in five recognisable stages. Each one has its own deliverable and its own failure mode — skipping a stage is how an EVM review ends up producing CPI / SPI numbers that nobody trusts. - Kickoff and scoping — short workshop with the project director, the cost / planning lead and the EVM analyst to confirm scope, the contractual EVM requirement (ANSI/EIA-748 directly, MoD EVM guidance, NEC4 Option C with target cost mechanics, FAR Part 34), the system in use (Cobra, Deltek, SAP, EcoSys, bespoke), the reporting cadence, and the decisions being supported. The output is a one-page EVM brief. Most arguments later in the engagement trace back to a missing line in this brief. - Data gathering — WBS, OBS, control account plans, work package definitions, earning rules, baseline budget, contract data items list, monthly EVM reports for the prior three cycles, variance analysis narratives, and the change log. We read the EVM reports before we open the tool — the variance narratives tell you whether the EVM is functioning as a management discipline or as a compliance artefact. - Diagnostic — the formal benchmark against ANSI/EIA-748’s 32 guidelines (organisation, planning and budgeting, accounting considerations, analysis and management reports, and revisions and data maintenance), plus the qualitative checks the guidelines do not fully capture: whether earning rules are deliverable-based rather than judgement-based, whether the PMB is bottoms-up consistent, whether management reserve is held at the right tier, and whether the variance analyses written into the report would convince an independent reader who had not been at the project review. - Reporting — a written assessment with each finding ranked by impact on the credibility of the cost performance position. Findings are separated into compliance issues (the EVMS is not meeting the 32 guidelines), signal-quality issues (the EVMS is compliant but the CPI / SPI numbers do not reflect delivery reality), and EAC issues (the forecast is not recoverable in the form presented). The recommendations are sized to the gap and tied to the next reporting cycle. - EAC challenge session — where the engagement extends to the EAC, a structured working session with the cost lead and the planning lead to interrogate the forecast: separating committed cost, in-flight commitment, and to-go forecast; separating trend-based EAC (BAC / CPI) from genuine bottom-up re-estimation; testing whether the EAC assumes performance reverts to baseline (and on what evidence) or whether it assumes current trend continues. The output is a defensible EAC narrative that survives independent challenge — not just a number. ### What good evidence looks like A defensible EVM product satisfies three audiences. The project director needs to know whether the cost performance position in this month’s report is real — and if not, where the gap is. The independent reviewer (IPA gateway team, NAO, internal audit, an SRO with a sceptical eye) needs structured evidence that the EVMS meets ANSI/EIA-748 and that the CPI / SPI signals are doing real work, not just passing an audit. The cost / planning team that runs the system needs to recognise the assessment as fair — an EVM review that the in-house team rejects stops being useful as a governance tool. In practice that means benchmarking the EVMS against ANSI/EIA-748’s 32 guidelines explicitly — not the high-level five categories, but the underlying guidelines that govern WBS structure, OBS integration, control account discipline, earning rule appropriateness, accounting accruals, variance analysis triggers, EAC re-estimation frequency, and baseline change control. Each guideline reported as compliant / partially compliant / non-compliant, with the evidence behind the call, and with the implication for the credibility of the cost performance signal. Where the work supports an investment decision or a gateway review, the report is structured so that the headline finding, the EVMS compliance summary, the signal-quality assessment, and the EAC narrative are each self-contained and traceable. That way an investment-committee or gateway reader can audit the chain from CPI / SPI back to specific control accounts and work packages without taking a guided tour. On NEC4 Option C contracts the same logic applies, but the chain runs through the contractor’s defined cost build-up and the pain / gain share mechanism rather than through a pure EVMS structure. ### What we don’t do It is worth being explicit about scope limits. We do not run the EVMS on behalf of the client — we review, audit, validate and challenge; the operational discipline stays with the in-house cost and planning team or with the contracted EVM service provider. We do not authorise baseline changes — a baseline change request might be informed by our review, but the authorisation sits with the appropriate change control board, not with the independent reviewer. We do not sign off the EAC as recoverable when our diagnostic shows it is not — we describe what would have to change, but the EAC sign-off remains with the accountable party. And we do not perform formal EVMS certification audits as a certifying authority — our assurance work prepares an organisation for, and validates against, ANSI/EIA-748, but the certification itself is a separate regulated activity. This matters because the failure mode in independent EVM assurance is drift. A reviewer who starts adjusting the EAC themselves, or whose ANSI/EIA-748 commentary turns into a critique of the contractor’s commercial strategy, has stopped being independent — and the assessment stops being usable at gateway or investment-committee challenge. Staying inside the EVM remit is what makes the independence credible. ### How engagements typically run An EVM engagement runs in one of three sizes. A four-week engagement — single readiness review or PMB validation, written report, working-session debrief. Right-sized for a focused decision point: a pre-contract EVMS readiness check, a one-off PMB validation ahead of a gate, or a structured EAC challenge at a quarter-end. A four-week run is enough to deliver a credible independent product on a single programme where the EVMS is in reasonable shape; it is not enough to remediate a system that is non-compliant against ANSI/EIA-748. An eight-week engagement — the typical shape for a more substantial piece of work. Readiness review or PMB validation, plus a benchmarked audit of two consecutive monthly reporting cycles, plus an EAC challenge session, plus a coaching pass with the in-house EVM analyst. This is the shape that suits programmes preparing for a major gateway, or contractors preparing an EVM compliance submission they need to defend. Ongoing retainer — monthly or quarterly EVM reviews against a live programme, with the EVM analyst supported through reporting cycles, EAC cycles and baseline change cycles. The assurance stops being a one-off document and becomes a maintained discipline that tracks signal quality as the programme moves. This is where EVM assurance earns its keep on a multi-year programme — a frozen PMB validation from sanction loses value within two reporting cycles; a maintained discipline continues to inform governance throughout delivery. Most EVM engagements that produce real change are a defined Phase 1 (four or eight weeks) plus a Phase 2 retainer at a lower cadence. Engagements that stop at the report typically see the discipline drift within two quarters, because the operating model after the report is unchanged — the same earning-rule habits, the same EAC trend method, the same variance narrative shape, all of which the original report flagged. ### Outcomes - An EVMS assessment that the project director, an independent reviewer and the in-house EVM analyst all recognise as fair — not a report that needs to be re-explained at every audience change. - ANSI/EIA-748 benchmarking run to the underlying 32 guidelines, with each guideline reported as compliant / partially / non-compliant against specific evidence — not just a five-category headline. - A clear separation between compliance, signal-quality and EAC findings — so that remediation effort is sized to the actual problem rather than spread evenly across symptoms. - A recoverable EAC narrative that distinguishes trend-based forecast from bottom-up re-estimation, and that survives investment-committee or gateway challenge. - An EVMS function that retains the capability after the engagement — coaching alongside the EVM analyst rather than producing a parallel cost model the project team does not understand. EVM done well is the difference between a programme that knows its own cost trajectory and one that finds out at year-end. If that is the conversation you are trying to have on your cost performance position, it is the one we are best at having. ---