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?
It contains only lagging measures, so adoption problems will surface too late to be corrected
It contains only leading measures, so no benefits can be confirmed
It is not proportionate, because too much information has been supplied
It breaches the assurance approach, because the programme office collated it
Which of the following must be included as the baseline in an options analysis supporting a programme decision?
The most expensive option, to establish an upper bound
The option preferred by the largest stakeholder group
The do-nothing option
The option recommended by the supplier with the strongest track record
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?
The issue register only, because the trigger was an issue
The decision register, which records the decision, the rationale, and the options considered
The risk register, because re-sequencing changes the risk profile
The delivery plan, because the sequence of work is changing
Sections you finish are checked off in the contents.