Why maturity models fall short
Formal maturity models such as P3M3 and CMMI score an organisation against five levels. P3M3 runs from Awareness to Optimised. CMMI runs from Initial to Optimising. They do two things well: they give an organisation a shared vocabulary, and they let it track its own progress over time. They are weaker as a guide to whether a live programme is being controlled honestly.
Controls maturity is not one dimension. A team can have strong cost reporting, weak risk management and no benefits tracking, and a single level averages those into a number that describes none of them. Models also reward process compliance. A team that completes every template and holds every meeting can score well while the pack misleads the steering group. A lean team that reports honestly and drives decisions can score lower for skipping formal steps.
This guide describes what you can observe instead: what you see in the controls room, the monthly review, the pack and a few direct questions. It is a diagnostic, not a scoring system. If most of the six characteristics below are present, the function is working. If most are absent, there is a problem whatever a model says.
Characteristic 1: one source of truth that people use
Look for: one schedule, one cost plan, one risk register and one set of progress data, each with a named owner and a defined update date, and a ruled-off process so nobody reports from a different version. Tooling matters less than discipline. A single workbook can work where discipline exists, and a full Primavera and Deltek stack can fail where it does not.
Typical failure: three numbers for the same metric in circulation, and the first fifteen minutes of the steering group spent on whose is right.
Test one: ask the project manager and the cost lead for the current EAC. As a SOMA rule of thumb, an unexplained gap of more than 2-3% means the function does not have a single source of truth. Then ask the risk lead for the risk-adjusted outturn and the confidence level it is quoted at (P50, P80 or other). That is the risk lead's number. It should reconcile to the EAC through a stated contingency, not sit alongside it.
Test two: ask which baseline is current, when it was approved and which change is the latest in the log. A good answer is specific: "revision 3, approved at the March board, change log current to compensation event 47." Different answers from different people is the signal.
Characteristic 2: a cadence that holds under pressure
Look for: progress captured by defined people on defined dates, variance analysis done, risk register updated, forecast refreshed and the pack issued, every month, without weekend working. A common practitioner norm is issue within five working days of month-end. It is a norm, not a standard, so set your own target and measure against it.
Typical failure: the cadence works when the project is calm and breaks in the months that matter. A major variation or delay event stretches reporting from five days to two weeks, the variance analysis becomes selective and the pack arrives incomplete.
Test: count how many of the last six packs met the target date, including the difficult months. Six from six is solid. Four from six is marginal. If nobody tracks timeliness, assume the discipline is weaker than claimed.
External assurance can force a cadence, but it should not be the only thing that does. NISTA (formerly the IPA) runs Gateway Reviews (Gate 0 to 5) on projects in the Government Major Projects Portfolio. The MOD has its own approval points, Initial Gate and Main Gate. National Highways schemes face stage-gate assurance under its Project Control Framework. Programmes that only produce good evidence ahead of a review are exposed between reviews, when the external pressure drops.
Characteristic 3: risk integrated with cost and schedule
Look for: the risk register read alongside the forecast, the top risks visible in the steering group pack and risk owners who are real people able to discuss their risks. The quantitative risk analysis (QSRA for schedule, QCRA for cost) should feed the contingency discussion. Qualitative scoring on a register is useful for prioritising, but it cannot produce a confidence-based contingency. The APM Body of Knowledge (7th edition) treats risk management as part of how a project is planned and controlled, and AACE Recommended Practice 57R-09, Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model, describes one way to do the integrated analysis.
Typical failure: risk as compliance. The register is maintained and summarised monthly, but the forecast is built without it, the contingency is an organisational convention and nobody in the room can name the top three risks without looking.
Test: ask the cost lead how the current contingency was derived. An analytical answer points to a recent QSRA or QCRA, the main risk drivers and a stated confidence level. A conventional answer is "10% because that is what we always use."
The difference matters in practice. Illustrative figures: if the base estimate is £100m and the QCRA gives a P80 of £112m, contingency to P80 is £12m, and it changes when the risks change. A flat 10% uplift gives £10m whatever the risks are, so it leaves the project exposed if the analysis says otherwise and gives no basis for challenge.
Characteristic 4: named owners for every significant item
Look for: a named planner for the schedule, a named cost engineer for the cost plan, a named owner for each risk who is a real project team member and not the risk manager by default, and a named commercial lead for each change. When a question arises there is a person to ask. When data is wrong there is a person accountable for fixing it.
Typical failure: shared responsibility, where nobody has the authority to stand behind an item.
Test: pick five items at random from the register and change log and ask who owns each. Ask the owner, not the controls team, what the next action is and when it is due.
Characteristic 5: honest variance reporting
Look for: variance between plan and actual reported with its causes, quantified. Here is an example on an NEC4 contract: "The cost forecast has increased by £2.3m: £1.1m from ground conditions (compensation event 41, quotation accepted and implemented), £0.8m from a change to the mechanical package Scope (compensation event 45, implemented) and £0.4m from steel price movement, assessed under the price adjustment for inflation (Option X1) in the Contract Data." The three drivers sum to £2.3m, and each has a mechanism a reader can check.
Compare: "costs are tracking within expected tolerances subject to ongoing commercial discussions." It sounds reassuring and says almost nothing.
Typical failure: good variances are explained and bad variances are described in general terms. The forecast line stays flat for months on a project with real change, which usually means the forecast is not being challenged.
Test: take the last pack's largest variance and ask for the cause, the contract mechanism and the amount. If the answer takes more than a minute to find, the reporting is not carrying the information.
Characteristic 6: decisions, not information
Look for: reporting that calls for decisions such as approving a change, directing action on a risk, accepting a revised forecast or releasing contingency. The steering group works through decisions. It does not review information.
Typical failure: the group notes the pack passively. Either the reporting is not surfacing the decisions needed, or the governance is unwilling to make them. Both are problems.
Test: read the decision log from the last six meetings. A healthy log has several substantive entries each month: approvals, directions, endorsements, escalations. A weak log is mostly process entries such as "agreed to receive further information." The log is often a more honest indicator than the pack.
What poor maturity looks like
Poor maturity is the presence of process that does not produce honest information. Weak functions often have process manuals, RACI charts, template packs and long monthly reports that meet every formal requirement, and still fail to tell the steering group the truth.
The symptoms are specific. Reports run to 40 pages or more because everything is included to show completeness, and the key messages are buried. RAG ratings are inflated: projects in trouble are rated amber because green feels complacent and red triggers an escalation nobody wants. Risk entries are generic, such as "stakeholder alignment challenges", where a usable entry would read "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."
Change control is the other tell. Changes are logged but the baseline is not updated, or approvals run at a volume that suggests scope drift is being treated as normal. Progress is measured by the contractor with no independent check.
Quantitative health signals
The six characteristics can be backed with numbers. The schedule checks below come from the DCMA 14-point assessment, a US Department of Defense check that is widely used in UK practice. It is not mandated by National Highways, Network Rail or HS2, so treat it as a screening aid. The cost signals are SOMA's own working rules of thumb. For any signal, the trend over several periods tells you more than a single reading.
The five-question test
Ask these on a live project. One: what is the current EAC, and do the project manager and cost lead agree to within 2-3%, with the risk lead's risk-adjusted outturn reconciling to it? Two: when was the last monthly pack issued, and was it inside the target? Three: how was the current contingency derived, and is the answer analytical or conventional? Four: name the top three risks. Does the answer come promptly and specifically, or slowly and generically? Five: show the decision log from the last three steering group meetings. Is it substantive or procedural?
In our experience the five questions take about ten minutes and separate functions that are working from functions that are performing. They test characteristics 1, 2, 3 and 6 directly. Characteristics 4 and 5 show up in how people answer.
What to fix first
Start with the single source of truth. Define who owns each data set, set a ruled-off monthly process and refuse to allow multiple versions into circulation. It is unglamorous and it means telling people they cannot use their preferred figures, but every other improvement is diluted without it.
Second, bring risk into the main cadence. Put the top risks in the steering group pack and derive contingency from a QSRA or QCRA instead of convention.
Third, cut report length. As a guideline from experience, a one-page executive summary, a five-page main pack, a named top-risk section and a technical annex serve most steering groups. Forcing brevity forces editorial decisions about which messages matter.
On a controls review we run the five questions first, then test the answers against the schedule, cost and risk data behind them. The aim is a short list of fixes ranked by how much they improve what the steering group can see.