Product & Delivery · Chapter 10 of 13
Programme management: dependencies, risk, and the status nobody reads
Coordinating work across many teams, where it actually goes wrong, and the report format that gets read.
Programme management is the discipline of getting many teams to deliver something together. It has a poor reputation because most of it is performed as reporting, and it is genuinely valuable when done as risk reduction. This chapter is the difference.
The three things a programme manager actually does
- Make the dependencies visible and reduce them. Not track them — reduce them. A tracked dependency is still a dependency.
- Find the risks early enough to be cheap. A risk identified in week two is a conversation; the same risk in week twenty is a crisis with the same content.
- Give leadership a truthful picture so that decisions are made on the real state rather than on optimism. This is the one that requires courage rather than skill.
Everything else — the meetings, the trackers, the reports — is instrumentation for those three. When the instrumentation becomes the job, the programme is being administered rather than managed.
Dependencies, and the hierarchy of responses
There is an order of preference here and most programmes never get past the last one:
| Response | What it means | Cost |
|---|---|---|
| 1 · Remove it | Change the sequence, the scope, or the team boundary so the dependency no longer exists | Sometimes free — a scope change nobody minds |
| 2 · Break it | Build a temporary stub, a feature flag, or a mock so team A can proceed before team B finishes | Small, and almost always worth it |
| 3 · Invert it | Have the dependent team build the piece themselves, in the other team's codebase, with review | Real, and it converts a queue into a code review |
| 4 · Schedule it | Agree a date and track it | The default, and the weakest. You now own a promise you cannot keep |
The reason the ordering matters: a scheduled dependency is a compound risk. If team B slips two weeks and team A had no slack, the programme slips two weeks — and with several such links the probabilities multiply rather than add. A programme with fifteen scheduled cross-team dependencies is close to certain to slip regardless of how well each team performs, which is a genuinely counter-intuitive point worth making to a sponsor.
Which leads to the structural intervention: if a programme has many dependencies, the team boundaries are wrong. Teams aligned to a product area with the skills to ship independently generate few; teams aligned to a technology layer generate one per feature. Proposing an organisational change is a bigger conversation than managing a dependency board, and it is frequently the correct one.
Risk, done properly
Most risk registers are theatre: a spreadsheet of vague concerns with a colour, reviewed monthly, never acted on. A useful one has three properties:
- Each risk is specific enough to be falsifiable. ‘Integration may be complex’ is not a risk; it is an anxiety. ‘We have not confirmed the vendor's API supports bulk export, and if it does not we need four extra weeks’ is a risk, and it can be resolved with an email.
- Each has an owner and a date by which it will be resolved or accepted. A risk with no date is a worry.
- And the register is ordered by when we will know, not by severity. This is the reordering that changes behaviour: the most urgent risk is not the biggest one, it is the one you could resolve this week and are not. Sorting by resolvability turns a document into a work queue.
The single most valuable programme-management move
Find the assumption that would invalidate the plan, and test it first.
Every programme rests on a small number of load-bearing assumptions — the vendor's API can do X, the legacy data is clean enough, the other team's timeline is real, the regulator will accept Y. Usually two or three.
The default behaviour is to schedule those in the order they appear in the plan, which means the riskiest ones are tested last, when a failure is most expensive.
Invert it. Sequence by risk, not by dependency order, and spend week one proving the thing that would kill the programme rather than building the thing that is easy to start. A spike, a phone call to the vendor, one query against the real data.
This is the highest-leverage thing in the discipline, it costs almost nothing, and it is routinely skipped because starting the easy work makes the first status report look better.
The status report that gets read
Most status reports are unread because they are written to demonstrate diligence rather than to cause a decision. The format that gets read is short and has a specific shape:
- The bottom line first. On track, at risk, or off track — and if it is not on track, what you need from the reader. Everything else is supporting detail.
- What changed since last time. Not the whole state; the delta. A reader who saw the last report should be able to read only this.
- The decision you need, with a date. A status report with no ask is a newsletter, and it will be skimmed accordingly.
- The top risk, with what you are doing about it. One, not fifteen.
- And a confidence statement rather than a date. ‘We expect to finish in the week of the 14th, with about 70% confidence; the main uncertainty is the data migration’ is far more useful than a date presented as a fact — and it protects you, because you told them the uncertainty in advance.
The watermelon problem, which is the failure mode of this whole discipline.
Green on the outside, red on the inside. Every layer of reporting rounds slightly toward optimism — nobody lies, everyone gives themselves the benefit of the doubt — and by the time the status reaches an executive it is green while the team knows it is not.
It is not caused by dishonesty. It is caused by incentives: reporting red invites scrutiny, help you did not ask for, and questions about competence. Reporting amber-becoming-green invites nothing.
The fix is cultural and it starts with the person receiving the report. If the first red status is met with support rather than interrogation, the second one arrives earlier. If it is met with an escalation and a review, you have just trained everyone to report green until it is undeniable.
And a mechanical aid: report a confidence percentage rather than a colour. It is much harder to say 90% when you mean 60% than it is to say green when you mean amber, because a number invites the follow-up question and a colour does not.
What a good programme manager is actually measured on
Not whether the programme hit its original date — that is mostly a function of how the date was set, which frequently predates them. The real measures:
- How early problems surfaced. A programme where the bad news arrived in month two was well managed even if it was cancelled; one where it arrived in month eleven was not, even if it shipped.
- Whether the forecast was honest. A programme manager whose 70% confidence means 70% is worth several who always say 90%.
- How many dependencies were removed rather than tracked.
- And whether the teams would want to work with them again — which sounds soft and is the strongest predictor of whether they will get the truth next time.
Check yourself