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.