7.2 What Gets Reported and Informing Decisions
Key Takeaways
- Reports typically cover progress against baseline, forecast out-turn, risks and issues, changes, quality, benefits position, and decisions required.
- Data becomes information only when analysed against a baseline and forecast with variance and cause explained.
- A report that presents metrics without interpretation or a recommendation stops at data and never supports a decision.
- Different stakeholders need different cuts of the same data: boards need exceptions and forecasts, teams need priorities and blockers, users need readiness and dates.
- Decisions must be communicated with what was decided, why, who owns the actions, and by when — and written back into the affected plans.
Two learning outcomes sit together here. Outcome 6b requires you to know the factors which would typically be reported on to help ensure successful project outcomes; outcome 6c requires you to understand the importance of producing information and collecting data to inform decision making and communicate actions and decisions to stakeholders. One is about what goes in the report, the other about why the data exists at all.
Factors Typically Reported for Successful Outcomes
The syllabus asks what is typically reported to help ensure successful project outcomes. Reporting should be decision-oriented, not a dump of every task. Core factors usually include:
| Reporting factor | Why it supports successful outcomes |
|---|---|
| Progress vs plan / baseline | Shows whether work is tracking and where variance is growing |
| Forecast to complete (time, cost, effort) | Decisions need where we will end, not only where we have been |
| Scope / product status | Confirms what has been delivered, deferred, or changed |
| Risks and issues | Highlights threats and open problems that could reverse success |
| Quality and acceptance status | Prevents "on time" delivery of unfit products |
| Benefits and business-case viability | Keeps investment linked to outcomes, not activity alone |
| Dependencies and constraints | Surfaces external blockers the team cannot absorb alone |
| Stakeholder / readiness signals | Adoption risk often decides real success after go-live |
| Exceptions and tolerances | Flags what has breached or is approaching delegated limits |
| Actions, owners, and decisions needed | Turns information into accountable next steps |
Good reports use exception-based emphasis: what is on track can be brief; what threatens objectives, tolerances, or viability gets depth, options, and a recommendation. Traffic-light dashboards help only if the criteria behind red/amber/green are defined and honest.
Data for Decision Making — and Communicating Actions
Reviews fail when they are theatre: slides without evidence, or evidence without a decision. The PMQ expects you to understand the importance of producing information and data for decision making and of communicating actions and decisions to stakeholders.
Why information and data matter
- Objectivity — data reduces reliance on the loudest voice in the room.
- Comparability — consistent metrics let boards track trend, not anecdotes.
- Traceability — decisions can be explained later to auditors, funders, and new stakeholders.
- Option quality — re-plan, descope, add resource, or stop all need quantified impact on cost, time, risk, and benefits.
- Tolerance control — only measured variance shows whether delegated authority is still intact.
Evidence should match the decision. A gate to start construction needs design completeness, cost forecast, safety readiness, and supplier commitment — not only a cheerful percentage complete. A benefits review needs operational KPIs and adoption measures — not only a handover certificate.
Why communication of actions and decisions matters
A decision that stays inside the board pack does not change delivery. After a review, communicate at least:
- What was decided (go, conditional go, no-go, re-plan, escalate).
- Why (key evidence and viability rationale).
- What actions follow (who, by when, success criteria).
- What changed for stakeholders (scope freeze, new priorities, stop-work, funding release).
- How progress will be checked (next review date, metrics, escalation route).
Different stakeholders need different depth: the board needs decision and residual risk; the team needs revised plan and priorities; users need impact on go-live and training; suppliers need contractual and schedule implications. Without that cascade, people continue working to an obsolete plan — which creates rework, conflict, and fake progress.
From data to decision: the chain that must not break
The distinction the syllabus draws is between data, information, and a decision. Reports fail at one of three joints, and naming the joint is what earns marks in a scenario.
| Stage | What it is | How it fails |
|---|---|---|
| Data | Raw measurements — hours booked, invoices paid, defects logged, milestones met | Not collected, collected late, or collected inconsistently so periods cannot be compared |
| Information | Data analysed against a baseline and a forecast, with variance and cause | Presented as a status colour with no baseline, no trend, and no explanation |
| Decision | An authorised choice, with an owner and a date | Report circulated to people who cannot decide; no decision requested or recorded |
A very common exam scenario is the report that is technically accurate and completely useless: every metric present, nothing interpreted, no recommendation. The correct critique is that it stops at data and never reaches information or decision.
Reporting to the audience, not to the template
Different stakeholders need different cuts of the same underlying data:
- The steering group / board needs exceptions, forecasts, decisions required, and the business-case position — not activity detail.
- The sponsor needs early warning of anything that threatens justification, benefits, or reputation, usually before the pack is formally issued.
- Team members need near-term priorities, dependencies, and blockers.
- Users and operational owners need readiness, dates, and what will change for them.
- Suppliers need performance against contract obligations and payment position.
Communicating actions and decisions, not just status
Outcome 6c ends with communicate actions and decisions to stakeholders, and this is the half that gets skipped. A decision that is taken but not communicated has the same practical effect as no decision: teams continue on the old assumption, suppliers work to the superseded instruction, and the reason for the change is lost.
For any review outcome, record and issue four things: what was decided, why, who owns the resulting actions, and by when. Then update the affected plans and baselines so the decision is visible in the documents people actually work from, not only in minutes nobody re-reads.
A monthly board pack lists every metric the project collects — hours booked, invoices paid, defects raised, milestones met — each with a status colour, but no baselines, trends, or recommendations. What is the most accurate critique?
A gate review decides to defer a workstream by two months, and the minutes record the decision. Three weeks later a supplier is still working to the original dates. What was most likely missed?