Managing scope, risk, and dependencies across workstreams

Most delivery slips come not from slow coding but from unmanaged scope, surprise risks and dependencies that nobody confirmed, and, as scope widens, from status that has stopped being true. The competency is seeing the whole of a piece of work rather than the part in front of you: defending scope by naming additions and trading them against the date, making risk explicit and attacking the highest-uncertainty items first, treating a dependency the other party has not confirmed as not yet a plan, and matching deliberation to reversibility. At organisational scope it becomes the management of an information system, because the facts themselves arrive filtered. It matters because a team can be fast, well estimated and well prioritised and still miss, through the addition nobody named, the risk kept in someone's head, or the other team that was assumed to deliver on a timeline it never agreed. The examinations test it because the failures are quiet until they are not: the masked slip, the watermelon status, the programme with no owner.

1. Name scope additions and trade them. Scope creep is the silent accumulation of small yeses. Each addition is named, its cost stated, and traded against the date or against something else, never absorbed.
2. Make risk explicit and attack the biggest unknown first. A risk kept in a head materialises as a surprise. Write it down, size it, and de-risk the item with the highest uncertainty before the ones that are merely hard.
3. An unconfirmed dependency is not a plan. Until the other team has agreed the timeline, the plan contains a hope. Confirm early, track visibly, and prepare a fallback.
4. Match deliberation to reversibility. Agonising over reversible calls while rushing irreversible ones is the characteristic misallocation; spend the scrutiny where the door is one-way.
5. Fix boundaries with ownership and contracts, not with meetings. Coordination cost is reduced by clearer ownership, explicit interfaces and fewer shared surfaces. More coordination meetings mostly convert engineering time into calendar time.
6. Go to ground truth when status smells wrong. Above team scope, risk management is really the management of the reporting system. Status defined by objective criteria, reviews that examine evidence rather than colour, and visible safety for bad news are what keep green meaning green.

The models here are practitioner tools of clear provenance; one is an old observation with an empirical literature behind it that the unit grades as practice in its management form.

The pre-mortem practice

The technique described in Gary Klein, Performing a Project Premortem (2007): before committing to a plan, assume it has failed and ask the team to write down why. It legitimises dissent, surfaces the risks that optimism was suppressing, and is dramatically cheaper than the postmortem it prevents. It produces candour only where safety already exists; in a low-trust room it generates the same silence as every other meeting.

One-way and two-way doors practice

Jeff Bezos's classification in Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016), used in this unit for the allocation of scrutiny: irreversible decisions — data models, public contracts, vendor lock-in — deserve deliberation; reversible ones should move fast. Reversibility is often misjudged, and "temporary" choices calcify, so the rule of thumb is to treat a door as one-way until it has been shown otherwise.

Conway's law practice

The observation in Melvin E. Conway, How Do Committees Invent? (1968) that a system's structure mirrors the communication structure of the organisation that built it. For this unit its use is diagnostic: chronic delivery friction at the same boundary, surviving repeated process fixes, is often the organisation's structure presenting a bill, and the durable fix may be organisational design rather than another working group. The empirical support and the design consequences are treated in TJ-1 Evaluating architectural decisions and their organisational consequences and SV-6 Organisational design and leading change.

Contract at the boundary practice

The practice, given its team-level form in Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019), of making the agreement between a service and its consumers explicit — an interface, a versioning and deprecation policy, and automated contract tests that catch a breaking change before integration does. It is the technical half of "ownership and contract at the boundary", and it verifies only the contract that was written down; it cannot invent interface discipline where none exists.

Ground truth and status criteria practice

Not a named model but the organisational practice this unit treats as central above team scope: status defined by objective criteria rather than sentiment — what green means, what triggers red, what escalation each state demands — reviews that examine evidence rather than colour, and more than one channel to reality. Its absence is what "every team reports green while the programme is visibly late" describes, and the broken thing in that picture is the reporting system, which has learned to optimise for reassurance, not the teams.

The scope ledger

Every addition to a committed piece of work is written down with its cost and the trade that paid for it — a date moved, a feature deferred. The ledger is what makes "the requirements kept changing" a list of decisions rather than a complaint, and it is the artifact that stops the silent accumulation.

The risk list, ordered by uncertainty

A short living list of what could go wrong, each item with its likelihood, impact, and the action that would reduce the uncertainty. Ordered by uncertainty, not by severity, because the highest-uncertainty items are the ones that surprise. Reviewed weekly; a risk list nobody reads is a risk list.

Dependency confirmation

For each dependency on another team or a vendor: who agreed it, when, to what date, and what the fallback is if it slips. An entry with "assumed" in the first column is a risk, and it moves to the risk list. Vendors get the same treatment as internal teams, with less trust.

The pre-mortem at the start

At the start of any significant initiative, an hour in which the team assumes the initiative has failed and writes down why. The output seeds the risk list with the things optimism would have hidden.

The cross-team delivery review

A regular review across teams whose purpose is to surface risks and dependencies while they are still cheap, not to perform status. It examines evidence: what was meant to be true by now, and is it. Its health check is whether it ever produces bad news; one that is always green is a ceremony.

At team scope the object is one workstream's scope, risks and dependencies, and the manager keeps the ledger, the list and the confirmations directly. At organisational scope the object becomes the dependencies between teams and the risks that fall between them because each team's view stops at its boundary; the first job is ground truth when status smells wrong, the second is fixing boundaries with ownership and contracts rather than meetings, and a maintained dependency map replaces hope. At executive scope the object is systemic risk — the dependencies no team's view contains, the programme that spans the organisation and has no owner, the vendor or person the whole business quietly depends on — and the executive's scarcest commodity is true information, which they secure by engineering the reporting system and by verifying critical programmes against evidence rather than reassurance. The pattern is in How Judgment Scales; chronic boundary friction as a structural signal is SV-6 Organisational design and leading change.

• Names scope additions and trades them against the date instead of absorbing them. team
• Keeps an explicit risk list and attacks the biggest unknown first. team
• Confirms cross-team dependencies with the other team, early, and tracks them. team
• Matches deliberation to reversibility.
• Failure mode — silently absorbing additions. team
• Failure mode — keeping risks in your head until they materialise. team
• Failure mode — assuming another team will deliver on your timeline. team
• Failure mode — agonising over reversible calls while rushing irreversible ones. team
• Goes to ground truth directly when status smells wrong, stabilises the delivery, then addresses why the truth felt unsafe to report. org
• Fixes two teams that repeatedly break each other with ownership and contract at the boundary — interfaces, contract tests, clear responsibility — not with mandated goodwill. org
• Maintains a shared dependency map across teams, reviewed on a cadence. org
• Treats concentration of critical context in one person as a risk to engineer away — pairing, documentation, rotation — before it hurts. org
• Handles a vendor slip by establishing impact and mitigation options first, then escalating with the vendor and communicating the revised picture. org
• Reads duplicated work discovered late as a missing shared view of what is being built, not as a communication failure. org
• Failure mode — managing by status report. org
• Failure mode — punishing the masked slip before stabilising the delivery. org
• Failure mode — prescribing "more communication" for a boundary failure. org
• Failure mode — celebrating the hero who is also the single point of failure. org
• Engineers the reporting system so that green means green: objective status criteria, evidence-based reviews, visible safety for bad news. exec
• Verifies a critical programme against evidence when a confident leader keeps reassuring them; reassurance is not data. exec
• Forces a single accountable owner with authority across the boundary onto cross-organisation work. exec
• Fixes an incentive conflict between two directors' organisations at the level that owns the incentives, rather than urging them to cooperate against their own goals. exec
• Reads chronic friction at the same boundary as a structural signal and considers organisational design as the fix. exec
• Failure mode — running the organisation on watermelon status, green outside and red inside. exec
• Failure mode — accepting a confident leader's word for a programme you have independent reason to doubt. exec
• Failure mode — letting cross-organisation initiatives drift ownerless. exec
• Failure mode — process-patching a boundary the organisation chart itself created. exec

Scope discipline versus responsiveness. Refusing every addition makes the work irrelevant by the time it ships; accepting every addition means it never ships. The ledger is the resolution: additions are accepted as trades with a visible cost, not refused and not absorbed.

Risk visibility versus alarm. A long, honest risk list can read as a team in trouble; a short, reassuring one hides the surprise. The judgment is in the ordering and the framing — risks with actions attached, reviewed and retired — so that visibility reads as control rather than as panic.

Trust versus verification. Going to ground truth on a team's status can feel like distrust of its manager, and accepting a confident report can be how a two-month slip stays hidden. The resolution is that verification is a property of the system, applied to every programme, not a judgment about a person; and that the person who masked a slip is asked why the truth felt unsafe before they are asked anything else.

Contracts versus goodwill. Explicit interfaces and contract tests feel bureaucratic between teams that get along, and they are what remains when the people who got along have moved on. The judgment is in where the contract earns its cost — at boundaries with many consumers or a history of breakage — and where goodwill genuinely suffices.

Ownership versus autonomy. Forcing a single owner onto cross-organisation work takes authority from the organisations it spans. Leaving it ownerless preserves their autonomy and guarantees drift. The executive decides, and the failure is in not deciding.

A senior manager runs a programme that spans four teams and is three weeks from a committed launch. In a corridor conversation an engineer mentions, in passing, that their team's piece is "probably two months out". The team's status in the weekly programme review has been green for six weeks. The manager of that team is competent, well liked, and has said nothing.

The two reflexes are to confront the manager about the masking, or to escalate the slip immediately with the information as it stands. The first addresses the wrong thing first; the second escalates a rumour. Neither gets the launch under control.

The senior manager goes to ground truth. Within a day they have looked at the team's actual state — the work remaining, the integration tests not yet passing, the dependency on another team that was never confirmed — and have a real estimate: not two months, but six weeks, and only if the dependency lands. The status was wrong, and the corridor was also wrong, and the difference between them was worth a day. They then re-baseline the programme: the committed launch cannot hold at full scope, and the stakeholders are told this week, with three options — move the date six weeks, launch on the date with the fourth team's piece descoped, or launch on the date with a reduced rollout that does not depend on it. The stakeholders choose. The cross-team dependency review, which exists precisely to catch this, is examined for why it did not: the review had been reporting colour, not evidence, and the senior manager changes it so that each team states what was meant to be true by now and whether it is.

Only after the delivery is stabilised do they turn to the manager, and the question they ask is not "why did you hide this" but "what made the truth feel unsafe to report". The answer — that the last team to report a slip in the programme review had been publicly pressed for a recovery plan on the spot — is a fact about the senior manager's own review, and they change how it runs. The masking is still feedback for the manager, given as situation, behaviour and impact, and it is given second.

What the senior manager does not do is manage by the status report, in either direction: neither trusting the green nor acting on the corridor. Both were a substitute for looking.

• DE-2 Estimation, planning, and honest commitments — the range that widens when a risk materialises, and the re-forecast that follows.
• DE-1 Prioritisation under constraint — the shared bottleneck as a dependency, and the single ranked view that manages it.
• SV-6 Organisational design and leading change — organisational design as the durable fix for chronic boundary friction.
• PL-2 Feedback and difficult conversations — the feedback owed to the manager who masked a slip, and the reaction to bad news that decides whether it is reported next time.
• TJ-1 Evaluating architectural decisions and their organisational consequences — architecture and the coordination cost it creates; Conway's law in its design form.

1. Why is an unconfirmed dependency not a plan?
   Answer

   Because until the other team has agreed the timeline, the plan contains a hope rather than a commitment. Confirm early, track visibly, and prepare a fallback; an entry marked "assumed" belongs on the risk list.
2. What should a risk list be ordered by, and why?
   Answer

   Uncertainty, not severity. The highest-uncertainty items are the ones that surprise; de-risking them first narrows the plan fastest.
3. A team masked a two-month slip in a four-team programme three weeks from launch. What do you do first, second, and why in that order? org
   Answer

   First, get ground truth directly and re-baseline the plan with options for stakeholders — stabilise the delivery. Second, address the masking, as a question about why the truth felt unsafe to report, then as feedback. Delivery first because choices are disappearing; the masking second because it is a fact about the reporting system as much as about the person.
4. Two teams repeatedly break each other's integrations and blame flows both ways. What is the root-level fix, and what is the fix that does not work? org
   Answer

   Ownership and contract at the boundary: explicit interfaces, contract tests, clear responsibility. Mandating more communication or more coordination meetings converts engineering time into calendar time and leaves the boundary as it was.
5. Every team reports green and the flagship programme is visibly late. What exactly is broken, and why will better dashboards alone not fix it? exec
   Answer

   The reporting system, which has learned to optimise for reassurance. Dashboards display what the system reports; the fix is objective status criteria, reviews that examine evidence rather than colour, and visible safety for bad news, so that the inputs become true.
6. A critical programme is in trouble by every indirect signal and the responsible vice-president keeps reassuring you. What do you do? exec
   Answer

   Respect the vice-president and verify anyway: go and look at the evidence. Reassurance is not data, and an executive maintains more than one channel to reality.
7. Delivery friction keeps recurring at the same boundary despite three process fixes. What should you consider? exec
   Answer

   That the structure is the problem. Chronic boundary friction is often the organisation's design presenting a bill, and the durable fix may be organisational design rather than another working group.

• Gary Klein, Performing a Project Premortem (2007) — the pre-mortem technique.
• Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016) — one-way and two-way doors.
• Melvin E. Conway, How Do Committees Invent? (1968) — systems mirror the organisations that build them.
• Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019) — team boundaries, interaction modes and explicit contracts between teams.