Product & Delivery · Chapter 5 of 13
Dependencies, critical path and honest status
The core of delivery work: knowing which of six teams can actually move the date.
With six workstreams, most of them are not on the critical path at any given moment. Treating them all equally is how a programme manager becomes a status collector.
Why status reporting is unreliable, and what to use instead
Green is the socially safe answer until it is undeniably false, so it is the least informative signal available. What to watch instead:
- Has anything been delivered and accepted by the team downstream? Not ‘in progress’, not ‘ninety percent’ — percentage complete is unfalsifiable and hovers at ninety for weeks.
- Have the handoff dates moved since last month? Silent drift in a dependency date is the clearest leading indicator there is, and it shows weeks before anyone declares a problem.
- Is scope shrinking quietly? Teams protect dates by reducing what they deliver without announcing it. The date is then met and the thing is smaller.
- Is unplanned work rising? If a team's capacity is being consumed by escalations, the plan is already invalid whatever the status says.
Ask a different question
Not “are you on track?” but “what would have to go wrong for you to miss this, and how likely is that?”
People will discuss risk far more readily than they will change a status colour, because the first is a conversation and the second is an admission. Your job is to make amber socially safe — a programme where nobody reports amber until week eleven is not a well-run programme, it is a badly-lit one.
Float, and why it beats the critical path
The critical path method came out of industrial scheduling in the late 1950s, and the encyclopaedic summary of it is unusually blunt: the original approach is no longer used, and the term now means network-logic analysis generally.
What survived is the underlying quantity, and it is not the critical path. It is float — how far an item can slip before it moves the end date. The critical path is simply the set of items with zero float; it is an output, not an input.
- Report float, not colour. ‘Three dependencies have zero slack and one of them is with a team that has slipped twice’ is information. ‘Amber’ is not.
- A status that can be green while a zero-float dependency is late is decorative. Tie the status to the float, or do not publish it.
- Full network schedules do not work for software, because the duration estimates carry error bars wider than the float they are being used to compute. The critical path is then unstable week to week and cannot be acted on.
- What does work is a small dependency graph maintained live, with each edge expressed as a dated, negotiated commitment plus a fallback: not ‘team B owes us X’, but ‘B delivers X by date D, and if it passes D we take path Y’.
- Re-baselining is how a programme lies to itself. When the date moves, keep the original visible next to the new one. A programme that has re-baselined four times has a forecasting problem, and erasing the history removes the only evidence of it.
On RAID logs: the letter that earns its place is A, for assumptions — and it is the one everyone treats as filler. An assumption is a risk nobody has priced: ‘the vendor's API will support batch by Q3’ is not a risk while everyone believes it, and it is the thing that sinks the programme when it turns out to be false. Every assumption should have a date by which it will be checked.
And the test for a real risk register: every entry has a decision date — a point by which the mitigation must fire or the risk has become an issue. Entries scored on a probability-by-impact grid and never revisited after the kick-off workshop are the same ordinal arithmetic problem as the prioritisation chapter, with the added flaw that nobody looks again.
Check yourself