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.