Managing scope, risk, and dependencies across workstreams

Slow coding causes few delivery slips. Most come from unmanaged scope, from risks that arrive as surprises and dependencies nobody confirmed, and, as scope widens, from status that has stopped being true. The competency is seeing the whole of a piece of work, beyond the part in front of you. That means defending scope by naming each addition and trading it against the date, making risk explicit and attacking the most uncertain items first, treating a dependency the other party has not confirmed as something short of a plan, and matching the amount of deliberation to how reversible a decision is. At organisational scope it turns into managing an information system, because the facts arrive filtered. A team can be fast, well estimated and well prioritised and still miss, because of the addition nobody named, the risk that stayed in someone's head, or the other team that was assumed to deliver to a timeline it never agreed. The examinations test this because the failures stay quiet until suddenly they do not: the masked slip, the watermelon status, the programme with no owner.

1. Name scope additions and trade them. Scope creep is small yeses piling up unnoticed. Each addition is named, its cost is stated, and it is traded against the date or against something else. It is never absorbed.
2. Make risk explicit and attack the biggest unknown first. A risk kept in someone's head turns into 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 it where people can see it, and prepare a fallback.
4. Match deliberation to reversibility. The typical misallocation is agonising over reversible calls while rushing irreversible ones. Spend the scrutiny where the door is one-way.
5. Fix boundaries with ownership and contracts, not with meetings. Clearer ownership, explicit interfaces and fewer shared surfaces reduce coordination cost. Adding coordination meetings mostly turns engineering time into calendar time.
6. Go to ground truth when status smells wrong. Above team scope, managing risk is really managing the reporting system. Green keeps meaning green when status is defined by objective criteria, reviews examine evidence instead of colour, and people can see that bad news is safe to bring.

The models in this unit are practitioner tools with clear provenance. One is an old observation with an empirical literature behind it, which the unit grades as practice in its management form.

The pre-mortem practice

Gary Klein, Performing a Project Premortem (2007) describes the technique. Before committing to a plan, the team assumes it has failed and writes down why. This makes dissent legitimate, brings out the risks that optimism was holding down, and costs far less than the postmortem it prevents. It produces candour only where safety already exists. In a low-trust room it produces the same silence as every other meeting.

One-way and two-way doors practice

This is Jeff Bezos's classification in Jeff Bezos, 2015 Letter to Shareholders (Amazon.com, Inc.) (2016), used here to decide where scrutiny goes. Irreversible decisions, such as data models, public contracts and vendor lock-in, deserve deliberation. Reversible ones should move fast. People often misjudge reversibility, and "temporary" choices harden into permanent ones, so the rule of thumb is to treat a door as one-way until it has been shown to be otherwise.

Conway's law practice

Melvin E. Conway, How Do Committees Invent? (1968) observed that a system's structure mirrors the communication structure of the organisation that built it. This unit uses it as a diagnostic. When delivery friction keeps recurring at the same boundary and survives repeated process fixes, it is often the organisation's structure presenting a bill, and the lasting fix may be organisational design rather than another working group. TJ-1 Evaluating architectural decisions and their organisational consequences and SV-6 Organisational design and leading change cover the empirical support and the consequences for design.

Contract at the boundary practice

This practice, given its team-level form in Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019), makes the agreement between a service and its consumers explicit. It consists of 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". It verifies only the contract that was written down, and it cannot create interface discipline where there is none.

Ground truth and status criteria practice

This organisational practice has no formal name, and the unit treats it as central above team scope. Status is defined by objective criteria in place of sentiment: what green means, what triggers red, and what escalation each state requires. Reviews examine evidence instead of colour, and leaders keep more than one channel to reality. When it is missing, every team reports green while the programme is visibly late. In that picture the teams are not what is broken. The reporting system is, because it has learned to optimise for reassurance.

The scope ledger

Every addition to a committed piece of work is written down with its cost and the trade that paid for it, such as a moved date or a deferred feature. With a ledger, "the requirements kept changing" becomes a list of decisions instead of a complaint, and the ledger is the artifact that stops additions piling up unnoticed.

The risk list, ordered by uncertainty

This is a short, living list of what could go wrong. Each item carries its likelihood, its impact, and the action that would reduce the uncertainty. The list is ordered by uncertainty, and severity does not set the order, because the most uncertain items are the ones that surprise. It is reviewed weekly, because a list nobody reads reduces no risk at all.

Dependency confirmation

For each dependency on another team or a vendor, record 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 moves to the risk list. Vendors are treated the same way as internal teams, with less trust.

The pre-mortem at the start

At the start of any significant initiative, the team spends an hour assuming the initiative has failed and writing down why. What comes out seeds the risk list with the things optimism would have hidden.

The cross-team delivery review

This is a regular review across teams. Its purpose is to surface risks and dependencies while they are still cheap to deal with, and performing status is no part of it. It examines evidence: what was meant to be true by now, and whether it is. The test of its health is whether it ever produces bad news. A review that is always green is a ceremony.

At team scope the object is the scope, risks and dependencies of one workstream, and the manager keeps the ledger, the list and the confirmations personally. At organisational scope the object becomes the dependencies between teams and the risks that fall between them, since each team's view stops at its own boundary. The first job is to get to ground truth when status smells wrong. The second is to fix boundaries with ownership and contracts in place of meetings, and a maintained dependency map takes the place of hope. At executive scope the object is systemic risk: the dependencies that no single team's view contains, the programme that spans the organisation and has no owner, the vendor or person the whole business quietly depends on. True information is the executive's scarcest commodity. They secure it by engineering the reporting system, and by checking critical programmes against evidence and not against reassurance. How Judgment Scales sets out the pattern, and SV-6 Organisational design and leading change treats chronic boundary friction as a structural signal.

• 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) and 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 through pairing, documentation and 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, and 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, because 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, instead of 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. If every addition is refused, the work is irrelevant by the time it ships. If every addition is accepted, it never ships. The ledger resolves this, because additions are accepted as trades with a visible cost, neither refused nor absorbed.

Risk visibility versus alarm. A long, honest risk list can make a team look as if it is in trouble, while a short, reassuring one hides the surprise. The judgment lies in the ordering and the framing. Risks that have actions attached and are reviewed and retired make visibility read as control, and stop it reading 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 way through is to make verification a property of the system, applied to every programme, so that it is no judgment on a person. And 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 is left once the people who got along have moved on. The judgment is in knowing where a contract earns its cost (at boundaries with many consumers or a history of breakage) and where goodwill is enough.

Ownership versus autonomy. Forcing a single owner onto cross-organisation work takes authority away from the organisations it spans. Leaving it without an owner preserves their autonomy and guarantees drift. The executive decides, and the failure lies 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". For six weeks that team's status in the weekly programme review has been green. Its manager is competent and well liked, and has said nothing.

There are two reflexes. One is to confront the manager about the masking, and the other is to escalate the slip immediately on the information available. The first deals with the wrong thing first, and the second escalates a rumour. Neither brings the launch under control.

The senior manager goes to ground truth. Within a day they have looked at the team's real state (the work remaining, the integration tests not yet passing, the dependency on another team that was never confirmed) and have a real estimate. It is six weeks, short of the rumoured two months, and only if the dependency lands. The status was wrong and so was the corridor, and finding the difference was worth a day. They then re-baseline the programme. The committed launch cannot hold at full scope, and the stakeholders hear this the same week with three options: move the date by 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 exists to catch exactly this, so the senior manager examines why it did not. It had been reporting colour instead of evidence, and they change it so that each team states what was meant to be true by now and whether it is.

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

The senior manager does not manage by the status report in either direction: they neither trust the green nor act on the corridor. Both would have been 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

   Until the other team has agreed the timeline, the plan contains a hope where a commitment should be. Confirm early, track it 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 most uncertain items are the ones that surprise, and 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, which stabilises the delivery. Second, address the masking, first as a question about why the truth felt unsafe to report and then as feedback. Delivery comes first because the choices are disappearing. The masking comes second because it says as much about the reporting system 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 turns 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 instead of colour, and visible safety for bad news, so that what goes in becomes 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 by going to look at the evidence. Reassurance is not data, and an executive keeps 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 friction at a boundary is often the organisation's design presenting a bill, and the lasting 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.