8.5 Data Gathering, Reporting & Options Analysis
Key Takeaways
- A decision point is a defined moment in the programme at which a choice must be made, by a named authority, on the basis of agreed information — and the outcome is recorded in the decision register.
- The purpose of data gathering and reporting is to make decisions decision-ready: timely, sufficient, comparable, and free from filtered optimism.
- Reports should combine leading and lagging measures, because lagging measures alone confirm problems only after they have become expensive.
- Options analysis identifies the realistic courses of action, evaluates each against agreed criteria including do-nothing, and presents a recommendation rather than a single pre-selected answer.
- The decision-making approach defines who decides what, within what delegated authority, using which information, and how the decision is recorded.
8.5 Data Gathering, Reporting & Options Analysis
[!NOTE] Where this sits: The Decisions theme covers three things — how decisions are made, how issues are resolved, and how risks are responded to. Sections 8.3 and 8.4 covered risk and issues. This section covers the decision machinery itself: the decision point, the information that feeds it, and the options analysis that structures the choice.
The Decision Point
A decision point is a defined moment in the programme at which a choice must be made. It is not simply "when someone decides something" — in MSP a decision point has four properties:
- A named authority. The decision-making approach states who holds the decision right, and within what delegated tolerance. Some decisions sit with the programme manager; others must go to the SRO, the programme board, or the sponsoring group.
- Defined information requirements. What the decision-maker must have in front of them — for example, an updated business case, tranche performance data, and an options analysis.
- Defined timing. Many decision points are scheduled (tranche boundaries, funding gates), but others are event-driven (an escalated issue, a supplier failure, a change in legislation).
- A recorded outcome. The decision, its rationale, the options rejected, and any conditions attached are entered in the decision register.
Decision points are the reason MSP treats decision latency as a governance risk: a programme where every choice waits for a monthly board is not slow because people are indecisive, but because nobody defined a decision point with an appropriate authority.
Data Gathering and Reporting
The purpose of data gathering and reporting is to make decisions decision-ready. Governance bodies cannot direct a programme on the basis of narrative reassurance; they need information that is timely, sufficient, comparable across projects, and honest.
What good programme reporting provides
| Quality | What it means | What goes wrong without it |
|---|---|---|
| Timely | Available before the decision point, not after | Decisions are made on stale data or deferred |
| Sufficient | Covers delivery, benefits, risk, finance, and business readiness | The board steers on cost and schedule and misses adoption failure |
| Comparable | Uses consistent scales and definitions across projects | Two "amber" projects mean entirely different things |
| Reliable | Traceable to a source, and not re-graded on the way up | Optimism bias; "watermelon reporting" (green outside, red inside) |
| Proportionate | Enough to decide, without generating reporting overhead | Delivery teams spend more time reporting than delivering |
Leading and lagging measures
A recurring reporting failure is relying entirely on lagging measures — results that confirm what has already happened.
- Leading measures indicate what is likely to happen: training completion rates, user log-ins to a new system, readiness assessment scores, defect trends, stakeholder sentiment. They arrive early enough to change the outcome.
- Lagging measures confirm what did happen: realized cost savings, throughput improvements, error-rate reduction, customer satisfaction. They are the evidence of benefit but arrive too late to act on.
A benefits report built only from lagging measures will tell the programme board that adoption failed roughly two quarters after it could have been fixed.
Reporting flows in MSP
Projects & other work ──► Programme office (collation, validation, consistency)
│
▼
Programme manager & BCM (analysis, exception identification)
│
┌───────────────────┴───────────────────┐
▼ ▼
Programme board SRO (escalation)
(within tolerance) │
▼
Sponsoring group
(beyond tolerance)
The programme office validates and standardizes rather than editing: its job is to make reports comparable, not comfortable.
Options Analysis
Options analysis is the structured evaluation of the realistic courses of action available at a decision point. It is used well beyond the business case — for escalated issues, risk responses, procurement choices, and tranche re-planning.
A defensible options analysis has five steps:
- Frame the decision. State precisely what is being decided and what constraints are non-negotiable (statutory deadlines, safety requirements, the vision).
- Identify a realistic range of options. Always include do nothing (or "continue as now") as the baseline against which everything else is compared. Include a genuine minimum option, not just a token one, and at least one option that changes the scope or sequence rather than only the cost.
- Agree the evaluation criteria before scoring. Typically: contribution to outcomes and benefits, whole-life cost, risk exposure, deliverability given organizational capacity and ability, and alignment with the target operating model. Agreeing criteria after seeing the options is how a preferred answer gets rationalized.
- Evaluate each option against every criterion, including its dis-benefits and the risks it introduces as well as those it removes.
- Recommend, decide, and record. The analysis produces a recommendation; the named authority makes the decision; the decision register records what was chosen, what was rejected, why, and by whom.
| Option | Contribution to outcomes | Whole-life cost | Risk | Deliverability |
|---|---|---|---|---|
| Do nothing | None — the gap remains and worsens | Avoided investment, but rising running costs | Regulatory exposure continues | n/a |
| Do minimum | Partial; meets compliance only | Lowest active spend | Low delivery risk, high strategic risk | High |
| Re-sequence tranches | Full, but later | Similar total, later drawdown | Reduces capacity overload | Medium |
| Full transformation now | Full and earliest | Highest, front-loaded | Highest change-absorption risk | Low if ability is weak |
[!TIP] Exam tip: An options analysis that presents a single option, or that omits the do-nothing baseline, is not an options analysis. If a scenario describes a board being asked to approve "the plan" with no alternatives, the governance defect being tested is the absence of options analysis.
[!CAUTION] Common trap — analysis is not the decision: Options analysis supports a decision; it does not make it. The named decision authority in the decision-making approach still decides, and the decision register — not the analysis document — is the record of what was decided.
A programme board is asked to approve additional funding. It receives realized cost savings to date and a completed schedule variance report, but no information on training completion, system log-ins, or business readiness. What is the principal weakness of this reporting?
Which of the following must be included as the baseline in an options analysis supporting a programme decision?
During delivery, an escalated issue forces a choice between two re-sequencing options. Where should the chosen course of action, the rejected option, and the reasoning be recorded?