Chapter 14: Decompose Work Without Losing the Whole

The station is in three plans

It is month sixteen at BlueLine, and station four is in three plans. Lena Voss has called a planning session because the consortium’s finance director, Daniel Osei, needs one integrated cost picture for the second-half authorization, and the project cannot seem to produce one. Each delivery partner has brought the breakdown of its own world.

The design-build contractor has brought a breakdown by physical asset: each station, each segment of trackway, the depot, the roadworks, the systems. The ticketing supplier has brought a breakdown by software component and release: the fare collection module, the passenger information module, the back office, the interface layers. The operations team has brought a view by capability. The transit operator’s readiness lead asks one question of everything: can the corridor take a fare, move a bus, inform a passenger, and do it safely on opening day? And Miguel Alvarez has brought the transport model’s geographic segments, because the model is where the corridor’s promise lives and dies, and the model does not care about contracts.

Each document is competently made. None of them meets any of the others. Station four appears three times, with three different meanings and three different completion dates. The contractor’s station four is civils, 14.2 million units, done in month 21. The ticketing supplier’s station four is the fare gates, the validators, and the displays, 4.4 million units, done in month 22. The capability view’s station four is “ready to serve a passenger,” which depends on both, plus the access standard Grace Njoroge’s federation co-authored, plus operators who have rehearsed the opening, and none of that appears in either contract. Daniel adds the columns three ways and gets three different totals, and for a moment the room concludes the contractor is hiding overruns.

Lena stops the search for blame. “The problem is not the numbers,” she says. “The problem is that we asked for the breakdown of the project, and everyone brought the breakdown of their own thing. A station is a physical asset, a software scope, a capability, and a location. It is all four at once. We keep treating our four views as if one of them were the truth and the others were mistakes.”

This chapter is about that sentence. Decomposition, the act of turning an intended outcome into manageable work, is the Delivery lens made structural. The multiplier in Project Mastery = Judgment × Alignment × Delivery × Learning shows up here as the shape of the plan. Chapter 13 chose the life cycle; this chapter turns the choice into structure. The craft is not finding the one correct way to break down the work. The craft is knowing which structure answers which question, choosing the views the decisions actually need, holding the views together so they reconcile, and never losing the whole inside the parts. The corridor is the whole; the station is a part; and the part is only useful when someone can still see the corridor through it.

Five structures, five questions

The word “breakdown” covers five different instruments, and the opening scene failed because the room used the word as if it were one. Each instrument answers a different question, and each earns its place only when the question is the one being asked.

The product breakdown structure answers the question “What must exist?” It is the anatomy of the delivered thing: the corridor made of twenty-four stations, a depot, trackway, roadworks, and systems; the platform made of modules, integrations, and data migrations. It is a structure of nouns, and its purpose is to make sure the project knows what it is producing before it decides how to produce it. The classic source of the distinction is older than project management. In The Mythical Man-Month (Addison-Wesley, 1975), Frederick Brooks separated a program, the code that runs, from a programming product, a program made usable by others, with documentation, training, and tests. He then separated a programming system, a set of programs that work together through interfaces, and the full combination, a programming systems product. Brooks was writing about software, and the discipline transfers whole: the delivered thing is not the work, and the anatomy of the thing is not the anatomy of the effort that makes it. A station as a product breakdown node is a place with platforms, roofs, gates, and access routes. A station as a work package is a bundle of effort, inspections, and sign-offs. Confusing the two is where the trouble starts.

The work breakdown structure answers “What work must be done?” It decomposes the project’s scope, the total work required to produce and deliver the accepted outcome, into components, ending in work packages that can be estimated, scheduled, owned, and accepted. Its discipline is the 100-percent rule, the subject of the next section, and its orientation is deliverable-first: the WBS is a hierarchy of the things to be produced and the work that produces them, not a calendar, not an organization chart, not a phase list. The PMBOK Guide, Seventh Edition (Project Management Institute, 2021), carries the work breakdown structure as one of the project’s planning artifacts; the Eighth Edition (November 2025) continues the same principles-and-performance-domains structure. The vocabulary has been reshaped; the artifact has not disappeared. It never does, because the decision it supports is fundamental: how will this outcome be estimated, scheduled, and accounted for as a set of owned, verifiable pieces?

The story map answers “What does the user experience as a whole, and which slice of it should we build first?” It arranges the user’s journey as a backbone of activities, with the details of each activity beneath. The team can then slice horizontally across the map and take a thin but complete piece of the journey to production. Jeff Patton, who developed and popularized the technique, calls it story mapping and demonstrates it in User Story Mapping (O’Reilly, 2014): the map is the whole journey made visible, and the slicing is how the whole is preserved while work is staged. The story map is the product perspective on decomposition, and it is the instrument that keeps a backlog honest.

The backlog answers “What should we build next, and in what order?” It is the ordered queue of candidate work, each item carrying enough description to be understood and enough agreement to be started. In its disciplined form it is not a wish list; it is a priority order derived from outcomes, risk, and learning. It is the adaptive delivery system’s planning instrument, the place where the sequence of work is re-decided from evidence — the adaptive rhythm of chapter 13. A backlog without a story map or a product goal degenerates into a feature list, which is a failure pattern later in this chapter.

The deliverable dictionary answers “What is the one true name of each thing, and where does every view find it?” It is the coding structure, the single register that gives each deliverable one canonical identifier, one owner, one home in the structure. With it, the asset view, the segment view, the capability view, and the contract view can all refer to the same station four without inventing four station fours. It is the lightest artifact in this chapter and the most important, because it is the reconciliation mechanism. In the earned-value tradition this is the code of accounts, the numbering that lets cost, schedule, and accountability attach to the same node; the chapter will build its own version from BlueLine’s mess.

The five instruments answer five different questions, and the field signals tell you when they are being confused. The loud one is the opening scene: a room full of competent documents that cannot be summed. The subtler one is a project that uses only one instrument, a WBS and nothing else, or a backlog and nothing else. It has never noticed that the questions it does not ask are the questions it keeps getting wrong. Read the room: if the cost people argue with the engineers about what a node means, the dictionary is missing. If the team argues about whether a feature is “phase two,” the calendar has crept into the structure. If nobody can say what the whole journey is, the map is missing.

Four views of one corridor

The corridor cannot be decomposed one way, because the corridor is not one thing. It is four things at once, and the chapter’s primary picture is the same outcome broken down four ways, with the risk each view reveals.

Figure 14.1: One corridor, four views. The whole is identical in
every row; the structure differs, and each structure reveals a
different class of risk.

  THE WHOLE: a working bus rapid-transit corridor serving about
  180,000 passenger trips a day, opened within a 24-month program,
  under a grant-funded, politically exposed delivery.

  VIEW 1: BY PHYSICAL ASSET      reveals: integration risk, where
  corridor, stations 1-24,        assets meet. The station is the
  depot, trackway, roadworks,     node where civils, systems, and
  systems                         access all land at once.

  VIEW 2: BY GEOGRAPHIC SEGMENT  reveals: location risk. The
  northern, central, southern,    eastern flood-plain segment
  eastern (flood plain)           carries the drainage approval;
                                  the central segment carries the
                                  market and the relocations.

  VIEW 3: BY SYSTEM CAPABILITY   reveals: readiness risk. The
  fare collection, passenger      seams between construction,
  information, depot operation,   software, and operations are
  traffic interface, access       where opening day is won or
                                  lost, and the acceptance
                                  evidence lives per capability.

  VIEW 4: BY CONTRACT PACKAGE    reveals: commercial risk. Where
  design-build, ticketing,        risk is allocated, where
  operations, trader support      incentives end, and where a
                                  contract boundary becomes a
                                  work boundary nobody owns.

The asset view is the engineer’s map. It shows what must be built and where the physical parts touch: the station where the trackway meets the entrance, the depot where the fleet meets the maintenance staff, the roadworks where the corridor meets the city’s existing streets. Its risk is integration, the moment two assets that were built and priced separately must connect. Its question is whether the connections have an owner before the two contracts discover the gap at the seam.

The segment view is the schedule’s geography and the community’s map. The eastern segment sits on the flood plain, with the drainage approval that chapter 3 recorded as still outstanding, so the segment’s schedule risk is regulatory and environmental. The central segment carries the market, the two relocated stations, and the staged stall relocation the market association co-designed in chapter 9. Its risk is human and political, measured in trader closures and the councillor’s trust ledger. The segment view is Aisha Bello’s map, the one the field counts and the petition belong to, and it is the view where the project’s social risk becomes location-specific rather than abstract.

The capability view is the operator’s map, and it is the opening day’s map. A passenger must be able to enter a station, pay a fare, board a bus, and be carried safely, and the depot must turn the fleet around, and the traffic system must give the buses priority without strangling the streets. The capability view decomposes the outcome “the corridor is open” into the things the service must actually do. Its risk is readiness: the civils certificate proves the station exists, and proves nothing about whether a passenger can use it. It is the view where Ibrahim’s drivers and Grace Njoroge’s access standard live, and it is the view the public will experience as success or failure.

The contract view is the commercial map. The design-build contract, the ticketing supply contract, the operations contract, the trader-support program: each package allocates risk, defines incentives, and creates a boundary. Its risk is the boundary itself. A contract boundary becomes a work boundary, and a work boundary with no owner is where scope falls through: the ticketing supplier’s contract ends at the station door, and the door itself is in no contract. The contract view is Daniel’s map, the one with the money attached, and the one that most easily convinces a project it is complete.

None of the four views is wrong. The design is engineered by asset, the schedule is controlled by segment, the opening is defined by capability, and the money is committed by contract. What is wrong is using any one of them as if it were the whole. What is missing when that happens is reconciliation: the dictionary that lets all four views point at the same station four, and the arithmetic that proves they all describe the same corridor.

The decision point arrives in practice as a simple question: which view governs which decision? Cost is governed by the contract view and the asset view reconciled, because the money is committed by package and spent on assets. Schedule is governed by the segment view, because the works move through the city in space and time. Opening-day readiness is governed by the capability view, because the public does not experience contracts. And the engineering itself is governed by the asset view, because that is where physical truth lives. When two views disagree, the disagreement is not a mistake to be settled by picking a winner; it is information, and the reconciliation is the moment the project finds the work that one view carries and the other does not.

The 100-percent principle

The work breakdown structure is governed by one rule, and the rule is where the whole is protected. The 100-percent principle states that the next level of decomposition must represent 100 percent of the work of the element above it, no more and no less, and that the full structure must represent 100 percent of the project’s scope. The Project Management Institute’s Practice Standard for Work Breakdown Structures (second edition, 2006) makes the rule the standard’s foundation. Gregory Haugan’s Effective Work Breakdown Structures (Management Concepts, 2002) develops it for practitioners: every parent node is exactly the sum of its children, and the top node is exactly the project. The rule sounds like bookkeeping, and it is bookkeeping. Bookkeeping is exactly what protects the whole: the whole is the only node nobody can lose, and everything else is a part of it.

The rule has two edges, and both matter. The first edge is the boundary: the structure contains 100 percent of the project’s scope, and therefore it must exclude everything outside the scope. Operations after handover are not in the project’s WBS, but the transition work that makes operations ready is. The chapter 10 scope statement is the instrument that draws the line. A WBS that quietly absorbs the operating team’s running costs has lost the boundary. A WBS that excludes the transition evidence because “that is operations’ job” has lost 100 percent in the other direction.

The second edge is the completeness test: the work that has no obvious deliverable still must appear, because the rule counts it. Project management itself, the certification evidence, the integration work between contracts, the training and handover records: none of these produces a station, and all of them must appear as nodes. The corridor does not open without them. The disappearing work is the classic cost of a vague structure, and the field signal is the sentence that starts “the plan doesn’t include…” That sentence is the alarm: whatever follows it is a node the structure lost, and the structure must be repaired, not the excuse accepted.

The rule also settles the orientation of the structure, because only deliverables make the rule testable. A WBS decomposed by phase or department cannot honor the principle. “Design” and “engineering” are not deliverables, and a phase box cannot tell the design of station four from the design of the depot. The testable structure is the deliverable-oriented one, built of nouns, where every node is a thing to be produced or the work directly producing it. There the sum can be checked: the children of “station four” are the civils package, the ticketing package, the access-standard package, the inspection and certification package, and the opening rehearsal. Their sum is station four. If two people at a planning meeting cannot agree which box a piece of work lives in, the structure is wrong, and no amount of spreadsheet polish repairs it.

Work packages and the level of usefulness

Decomposition has a bottom, and the bottom is a work package: the lowest level where scope, estimate, schedule, cost, and accountability converge into one owned unit of work. Above the work packages sit control accounts, the management points where the project aggregates packages for performance measurement. They are the nodes where earned value attaches and where the project manager’s attention lands. The practice standard’s structure and the earned-value vocabulary differ in detail across sources. The essence is stable: the bottom is where the work becomes real, and the level above the bottom is where it becomes manageable.

The question every decomposition must answer is how far down to go, and the honest answer is: down to the level where further decomposition stops changing a decision. The discipline has a long practitioner history. The earned-value management criteria codified in ANSI/EIA-748, the standard used widely in defense and government procurement, have long called for work packages short enough that progress can be measured within a reporting period, usually a month or less. The familiar practitioner heuristic, one to two weeks of effort or roughly eighty hours per package, is a sharper translation of that idea, not a law. The heuristic exists because a package of a week or two can be estimated, started, finished, and checked while the evidence is still fresh. But the heuristic is a symptom of the real test, and the real test is decision relevance: decompose deeper only while the deeper level changes an estimate, an owner, a sequence, a risk, or an acceptance.

The forward-looking form of this judgment is rolling-wave planning: the decomposition version of chapter 13’s cone of uncertainty. The near future is decomposed in detail, because it will be executed and can be estimated; the far future is decomposed coarsely, because its shape is still being discovered and detailed decomposition would be fiction. The corridor’s month-21 station four is decomposed to its packages now, because the contracts are signed and the work is real. The month-23 capability rehearsal is a single node, to be decomposed when the ticketing release is proven, exactly as the tailoring rationale from chapter 13 re-decides as evidence arrives. Rolling wave is not laziness; it keeps the project from paying the decomposition cost before the uncertainty is retired.

The failure on this dial is over-decomposition, and it deserves attention because it is produced by diligence. A structure decomposed past the level of usefulness looks like rigor and behaves like fiction. The plan is stale the day it is published, and progress becomes a bookkeeping exercise performed after the facts have moved. The tell is maintenance: if keeping the structure current costs more than the decisions it improves, the structure is too deep. The repair is upward, to the level where the structure is maintained at the speed the work actually moves.

Vertical slices and the walking skeleton

The adaptive family decomposes differently. Its question is not “what must be done” but “what value can be learned and delivered next.” The instrument that keeps the whole visible is the story map from the previous section: the journey as a backbone of activities, the details stacked beneath, the whole always in view while the work is staged in slices across the map. The map is the anti-feature-list: it decomposes the experience, not the inventory, and a slice across the map is a thin but complete piece of the journey, not a random feature.

The thinnest slice that proves the whole architecture is the walking skeleton. Alistair Cockburn introduced the term in Crystal Clear (Addison-Wesley, 2004) for a sliver of the system that exercises every major component end to end, built early and then thickened. It is decomposition’s answer to chapter 13’s complexity corner. Before the team commits to the full structure, it builds the smallest thing that walks — one market, one payment type, one station, one journey — through the entire system, and watches it walk. The skeleton reveals the interfaces, the real dependencies, and the integration risk — the things decomposition on paper cannot see — with the smallest possible batch. It is the batch-size economics of the previous chapter applied to learning.

The vertical slice is the unit the map and the skeleton share, and it is the contrast that matters most here: vertical slices versus technical layers. A technical layer is a horizontal slice of the stack: all the data migration, then all the interface work, then all the user screens. Layers feel efficient because each skill works uninterrupted. They are the shape most decomposition takes when departments decompose the work: engineering takes its layer, operations takes its own. The vertical slice cuts the other way: one small piece of the journey, from the screen through the rules through the data to the settlement, delivered end to end. The value is real and testable at the end of each slice. The Meridian platform workstream from chapter 13 is a vertical-slice design: the medication-list workflow is built as a complete slice — clinician screen, rules, record, referral handoff — rather than all screens first and all rules later. The clinician’s acceptance, the three-second list under a real workload, can only be observed in a whole slice.

The items that populate the map have their own disciplines, and the disciplines are worth naming because they are the decomposition rules of the adaptive family. The user story, the card-sized unit of customer value, was introduced by Kent Beck in Extreme Programming Explained (Addison-Wesley, 1999) as a planning unit small enough to estimate and prioritize. Ron Jeffries codified its craft in 2001 as the three C’s: the card, the placeholder for the conversation; the conversation, where the detail actually lives; and the confirmation, the acceptance criteria that prove the story is done. Bill Wake added the test for a well-formed story in 2003, the INVEST mnemonic: independent, negotiable, valuable, estimable, small, and testable. The words have been re-explained many times; the content has not changed. An epic is simply a story too large for one slice, the map’s coarse level, to be decomposed when the work approaches. A spike is a time-boxed experiment whose output is knowledge — the discovery unit from chapter 6 — used exactly where the structure has a question the team cannot estimate. An enabler is infrastructure with no user-facing value of its own, the wiring that later slices need, and the unit where the 100-percent rule is most often violated: teams leave it out and discover the wiring missing when the slices try to connect.

Two definitions complete the adaptive structure, and both are team decisions rather than standards. The definition of ready names the conditions a story must meet before the team will start it: enough clarity, the dependencies known, the acceptance criteria written, the value and the risk named. The definition of done names the conditions the finished slice must meet to count: the functionality works end to end, the evidence exists, the integration is tested, the operations handoff is prepared. Chapter 10’s acceptance criteria and chapter 21’s definition of done will build the full quality machinery; the point here is structural. Ready and done are the acceptance gates of the decomposition itself. A team that cannot state them has no way to know whether a slice is complete — the same hole as a WBS with no completion criteria for its packages. The adaptive family is not less disciplined than the predictive family; it is disciplined around a different unit, the slice of the journey rather than the package of the deliverable. Its discipline is exactly what keeps the whole in view while the parts ship.

KijaniPay is the case for this half of the chapter, and the merchant journey is the backbone. The map’s backbone runs from a merchant first hearing about the platform, through sign-up and verification, to taking a first payment, seeing settlement arrive, and eventually drawing working capital. The chapter 6 discovery reframed the whole map: the merchants’ real pain was not another payment button but predictable settlement and cash-flow visibility. The backbone’s most valuable activity is not “accept payments” but “see your money, predictably.” The walking skeleton follows from the backbone: one market, one payment type, one verification path, and the settlement run end to end with real merchants, proven before the feature breadth is built. The enabler in the skeleton is the settlement engine itself, invisible to merchants, unglamorous, and exactly where the chapter 6 evidence said the value lives. A feature-list decomposition of KijaniPay would order work by what is easy to build or what the loudest stakeholder requested. The story map orders it by the journey. The difference is between a backlog that ships and a backlog that ships the wrong whole.

The seams the structure reveals

Decomposition is not only a way of organizing work; it is a discovery instrument, and the discoveries it makes are dependencies and interfaces. The act of breaking the corridor into assets reveals that station four is where the civils, the ticketing, the access standard, and the operators all land at once. The act of breaking the platform into slices reveals that settlement sits under every slice and must be an enabler before the screens have anything to show. The act of breaking the program into contracts reveals that the door of station four belongs to no contract, and that the boundary has become an orphan. None of these facts was visible before the decomposition, and all of them are the decomposition’s real output.

The discipline that follows is ownership at the seams, and it connects directly to the governance map of chapter 8 and the seam discipline of chapter 13. Every interface has one owner, every dependency has one owner, and the owners are named people with authority, not committees. The interface register is the minimum viable tool, the lightest artifact that supports the discipline: one row per interface, the two sides, the data or physical exchange, the acceptance evidence, the owner. At BlueLine the register starts with the interfaces the four views revealed: the civils to ticketing interface at each station door, the trackway to traffic-management interface, and the depot to operations interface. The register is small, it is maintained at the same cadence as the risk register, and it is the reconciliation point where the views meet.

The coding structure is the second half of reconciliation, and it is the chapter’s quiet workhorse. Every deliverable receives one canonical identifier, the code of accounts in the earned-value vocabulary, and every view refers to the deliverable by its code, never by a phrase that can drift. Station four is a code that the asset view, the segment view, the capability view, and the contract view all carry; the reconciliation is then arithmetic, and the numbers from the opening scene demonstrate the check. The asset view shows station four civils at 14.2 million units; the contract view shows the ticketing package at 4.4 million units; their sum, 18.6 million units, is what the capability view’s “station ready to serve a passenger” must contain. Add the 1.9 million units of integration and rehearsal that live in the capability view and in no contract, and the capability total is 20.5 million units. When the three views reconcile — 14.2 plus 4.4 plus 1.9 equals 20.5 — the structure is telling the truth. When they do not, the difference is not an accounting error; it is the work that one view carries and another does not, and the discovery of that gap is the point of the exercise. Every cross-view variance is a missing or double-counted deliverable wearing a spreadsheet costume, and the check that finds it is cheaper than the surprise.

The owner of the reconciliation is the project leader’s office, and the reconciliation is a standing practice, not a one-time audit. After every material change the views are re-summed: a change in one view — a ticketing release date, a segment’s drainage approval, a contract variation — propagates into the others and must be visible when it does. The chapter 39 change control will formalize this; the structure is established here. The dictionary is the single source, the views are projections, and the projection is rechecked whenever the underlying deliverable changes.

When the structure becomes the enemy

The failure patterns of decomposition deserve to be named as characters, because each is produced by competent people doing the sensible thing, and each one loses the whole in a different way.

The phase WBS is the most common, and it is the calendar’s twin. The structure is decomposed by phase, design, build, test, deploy, or by department, engineering, communications, procurement, with the same deliverable appearing under two parents and a bottom bucket called “other” holding whatever fit nowhere. The tell is verbs and department names where nouns should be, the word “phase” in the tree, and the mixed feelings every costing meeting produces, because the numbers cannot roll up to anything the engineers recognize. The cost is the opening scene repeated forever: double counting where the deliverable appears twice, orphaned work where it appears nowhere, and reconciliation arguments that consume the energy the project needs for the work. The repair is the 100-percent principle applied with a noun test: every box names a deliverable or the work directly producing it, and every deliverable lives in exactly one place. The bottom bucket is deleted, because its contents were the missing nodes.

The disappearing 100 percent is the structure that looks complete and is not. The visible work — the stations, the modules, the releases — is all there. The invisible work — management, evidence, integration, training, handover records — is nowhere, because it has no obvious deliverable and no department that claims it. The cost is the late discovery that the corridor cannot open because the opening rehearsal was never a package, or the platform cannot be handed over because the training assessment records were never a deliverable. The repair is the completeness review at every decomposition: walk the scope statement and the acceptance criteria from chapter 10 and ask, for each, which node produces the evidence, and if no node does, add one.

The single view is the structure that convinced itself it was the whole. The contract view rules because it has the money; the schedule is kept by segment; the capability view is a nice-to-have that never quite got built. The seams between them are nobody’s, because the single view does not contain them. The tell is the two-department meeting where both plans look complete and neither contains the interface, and the price is paid on opening day, when the door meets the fare gate and neither contract contains the moment. The repair is the question this chapter has been asking: which views do the decisions need, and which seam does each view hide?

Decomposition to ashes is the structure that outgrew the work. The three-thousand-package WBS, the backlog refined into ten thousand stories, the map so detailed that mapping is the project’s real occupation: the update cycle runs longer than the work, and the plan becomes a document the work has quietly abandoned. The cost is not only wasted effort; it is the false confidence of a structure that looks rigorous and is fictional — the manufactured certainty chapter 3 warned about. The repair is upward, the rolling-wave discipline: decompose the near future to the level of decision, keep the far future coarse, and re-decompose as the work approaches and the uncertainty retires.

The feature-list story map is the adaptive family’s version of the same disease. The backlog is a long queue of stories, each a feature, each independently valuable, and the backbone is gone. Nobody can say how the slices add up to a journey; the ordering is by the loudest voice rather than the outcome; the product goal is a slogan. The tell is the prioritization meeting that argues about which feature without ever looking at the journey. The cost is the KijaniPay outcome inverted: the platform ships features and misses the settlement promise the evidence said was the whole point. The repair is the backbone: draw the journey, hang the stories beneath it, and slice across the map, so that every increment is a complete piece of a visible whole.

The drift dictionary is the quiet one, and it undoes the others. The codes are maintained casually, a station renamed, a module renumbered, a package relabeled in one view and not the other, and the reconciliation that once worked fails without explanation. The tell is the variance that nobody can find, the sums that refuse to close, and the spreadsheets with two station fours. The cost is the slow return of the opening scene, because the dictionary was the thing that kept the views honest, and its drift is the structure’s memory loss. The repair is discipline at the point of change: the code changes only through the same control as the scope, and the dictionary is updated in every view at once. This is chapter 39’s configuration management in its minimum viable form.

The six characters share one root: the structure was treated as a document to be produced rather than a system to be maintained. The dictionary, the reconciliation check, the noun test, and the backbone are the practices that keep the structure alive, and a project that holds them is harder to fool, including by itself.

The machine proposes, the leader reconciles

The assistant has a genuine and bounded role in decomposition, and its boundary is the book’s standing boundary. It can draft a candidate product breakdown and work breakdown from a provided scope statement. It can propose the first version of a story map from documented user research. It can check the 100-percent arithmetic, flagging nodes whose children do not sum to their parent and deliverables that appear twice under different names. It can generate the first pass of an interface register from contract documents and plans. The source data is the approved, non-confidential context, redacted before prompting. The draft is a draft until a named owner checks it. The audit record says what was generated, from what, checked by whom, and decided by whom.

Three boundaries are worth naming, because decomposition is where the machine’s fluency is most dangerous. First, the scope boundary is not discoverable from the documents alone. What is in scope, and what belongs to operations or to a different program, is a decision argued with the sponsors and the operational owners. The machine’s proposed boundary is a hypothesis until the people who own the work confirm it. Second, the seams and their owners cannot be delegated. The machine can propose where the interfaces are, and the leader must verify them against the contracts, the people, and the chapter 8 decision rights. An interface that exists in the register and not in ownership is the single view in a new costume. Third, the reconciliation is a judgment, not a calculation. When two views disagree, the machine reports the variance, and the project decides what the variance means. The meaning is either missing work or double-counted work, and only the people who know the work can tell which. The verification is the room. The leader tests the proposed structure against the scope statement, the acceptance criteria, the contracts, and the owners — the way the opening scene’s room should have. The machine accelerates the drafting; the boundary, the seams, and the reconciliation stay human.

Practice

One. A quick classification. For each statement, name the structure it belongs to, product breakdown, work breakdown, story map, backlog, or deliverable dictionary, and the decision it supports. (a) “Station four civils, 14.2 million units, code A-04, owner: design-build lead.” (b) “As a merchant, I can see my settlement within 24 hours of a sale.” (c) “The corridor consists of twenty-four stations, a depot, trackway, roadworks, and systems.” (d) “Verify the access standard at the station entrance before the opening rehearsal.” (e) “Fare collection is ready when a passenger can tap, travel, and be charged correctly end to end.” (f) “Deliver the training program and its signed assessment records to operations by month 20.”

(a) is the dictionary and the work breakdown together: the coded, owned, estimated node, supporting cost, accountability, and reconciliation. (b) is a story, one slice of the merchant journey, supporting ordering by value and learning. (c) is the product breakdown, the anatomy of the delivered thing. (d) is an acceptance activity, work tied to the access-standard deliverable, supporting the quality gates chapter 21 builds. (e) is the definition of done for the fare-collection capability, supporting the opening-day readiness decision. (f) is a work package, a deliverable with an owner, a date, and evidence, supporting the schedule and the handover. The common error is classifying by which department uses the item rather than by the question it answers: a dictionary entry and a story can describe the same settlement feature, and the classification is about the question, not the thing.

Two. A field drill: build the dictionary. Take one bounded deliverable from a project you know well, one station, one module, one release, and do three things. (a) Write its product breakdown, the anatomy of the thing, down two or three levels. (b) Build the deliverable-oriented work breakdown of the work that produces it, applying the 100-percent rule and naming the invisible work, management, evidence, integration, training, that a first pass will miss. (c) Give every deliverable one coded identifier, list the three views of your slice, asset, location or segment, capability or contract, and write the reconciliation check, the sum that must close, that proves the views describe the same thing.

The drill succeeds when the 100-percent check is performed as arithmetic: the children sum to the parent, and the parent sums to the slice, and the invisible work is visible as nodes, not as an assumption. The most common failure is the phase WBS creeping in, design, build, test as boxes, and the repair is the noun test. Ask what deliverable each verb produces; if the verb produces several, it is hiding several nodes. The second failure is the reconciliation that is skipped because the views are comfortable. If the slice is a station, the capability view must total the civils, the ticketing, the access standard, and the rehearsal. The moment the total does not close is the moment the drill has found something real.

Three. A decision room: whose station is it? It is month seventeen at BlueLine, and the ticketing supplier’s delivery director has proposed taking ownership of “station readiness” for the four central stations, arguing that the fare system is the critical path to opening. The design-build contractor objects: the civils are on the critical path in the segment schedule, and the station door is inside its works. The operations readiness lead wants the capability definition to decide, and Daniel Osei wants one number he can take to the second-half authorization. Decide: which view governs opening-day readiness, who owns the interface at station four, and what the acceptance evidence must be. Defend the trade-off.

The defensible answer keeps the three structures and owns the seam. Civils readiness is measured in the asset view, by inspection and certificate. The fare system is measured in the contract view, by its acceptance tests. Opening-day readiness is measured in the capability view, which governs the gate, because the public experiences the corridor as a service, not as contracts. Nobody owns station four wholesale, and the interface at the station door is owned by a named integration lead, in Lena’s office or an integrated delivery team, with the authority to force both sides to deliver the seam. The acceptance evidence for the gate is the capability proof: a passenger can enter, pay, board, and travel, and the fare records reconcile with the ticketing back office. The unsafe answers: granting the ticketing supplier “station readiness” with no explicit interface contract, which transfers the civils risk into a contract that does not contain it, or defining readiness by either certificate or acceptance alone, the single view in action. Reasonable but risky: giving the ticketing supplier station-readiness ownership with a fixed date and a written interface agreement. It is defensible only if the civils risk is genuinely proven lower and the interface contract is explicit — a judgment about evidence, not a preference.

Four. The mastery drill: repair the mixed decomposition. Here is a fragment of a decomposition from a clinic-and-platform program like Meridian’s, adapted for the drill. Identify what is wrong, rebuild it as a deliverable-oriented structure, and name what the original hid.

Program work
- Phase 1: Design
  - Engineering
    - Clinic layouts
    - Platform mock-ups
  - Communications
- Phase 2: Build
  - Construction, six clinics
  - Platform modules
- Engineering
  - Civil works
  - Software build
  - Data migration
- Testing
  - Clinical testing
  - Integration testing
- Communications
  - Public updates
  - Staff updates
- Training
  - Clinician training
- Procurement
  - Vendor contracts
- Other
  - Integration
  - Contingency

The fragment mixes phases, Phase 1 and Phase 2, departments, Engineering, Communications, Testing, Procurement, and deliverables, clinics and platform modules, in one tree, and the mixes are not cosmetic. Engineering appears twice, once under Phase 1 and once as a parent, so the same work lives in two places and the sum cannot be tested. Testing is a department that will test everything, so the testing of station-equivalent work — the clinic certification evidence, the platform integration evidence — is counted once at best and never attached to its deliverable. Training sits alone, so the clinician training that chapter 13’s rollout depends on is separated from the platform module it trains, and the seam between them disappears. And “Other” contains integration and contingency: contingency is not work, it is money, and its presence in a work structure hides the real gap, which is that integration had no home and was added as an afterthought. The rebuilt structure is deliverable-oriented: six clinic deliverables, each decomposed into building and fit-out, equipment, certification evidence, training and assessment records, and operational readiness; the platform deliverable, decomposed into its modules, the data migration, and the integration test evidence; the rollout deliverable per wave, the gate evidence pack and the adoption corridor; and the program-level packages, governance and assurance evidence, benefits baseline, and program management. Integration moves from “Other” to the platform and rollout nodes where it actually lives. Certification evidence becomes a named deliverable instead of a testing department. Training attaches to the module it trains. The contingency line is deleted from the structure and becomes a budget decision — chapter 18’s subject. What the original hid: the integration work and the certification evidence had no home and would have been discovered missing at the first wave gate, and the “contingency” bucket was disguising missing scope as financial prudence.

Five. The transfer question. Look at the plan you are building or inheriting. Where does the same deliverable appear twice, or appear nowhere? Which view is the only view your organization uses, and what does it hide? If you added one dictionary entry and one reconciliation check this week, which would they be?

The durable principle: decomposition is not the mechanical splitting of work into smaller boxes. It is a set of structures, each answering a different question, chosen for the decisions at hand, held together by a deliverable dictionary, and governed by the 100-percent principle. The whole is preserved in every part, and the seams between the views are owned, not assumed. The most common next failure is quieter than the six characters named here. The structure is built well, the dictionary works, and then the project stops re-checking. The views drift as the work changes, the reconciliation that once closed starts hiding a gap, and the whole is lost gradually rather than dramatically — the way a station falls out of three plans one update at a time. The re-check must be scheduled like the gate it protects, after every material change, with the sums closed and the seams re-owned. The next chapter takes the structure and gives it numbers: estimating honestly under uncertainty, because the estimate lands on the work packages this chapter built, and the cone of uncertainty from chapter 13 narrows one owned package at a time.

Notes

• BlueLine Urban Mobility Program is a composite case created for this book; no real city, corridor, contractor, supplier, or people are depicted. The month-sixteen planning session, the four delivery partners and their breakdowns, the station-four arithmetic, and all named characters are author-created illustrative material consistent with the earlier BlueLine chapters (chapters 3, 7, and 9): the 24-month program, the corridor expected to serve about 180,000 passenger trips a day, the eastern flood-plain segment with its outstanding drainage approval, the market and the two relocated stations, the staged stall relocation co-designed with the market association, the co-authored access standard, and the consolidated finance role. The station-four figures, 14.2 million units of civils and 4.4 million units of ticketing, are author-created teaching numbers within the corridor’s 2,400 million-unit capital envelope established in chapter 7, and they are illustrative, not an audit.
• The product breakdown and work breakdown distinction follows the general treatment of decomposition in the PMBOK Guide, Seventh Edition (Project Management Institute, 2021), which carries the work breakdown structure as a planning artifact, and the Eighth Edition (November 2025), which continues the principles-and-performance-domains structure; the chapter’s definitions are the author’s own words, and this book is independent of PMI. The 100-percent rule follows the Project Management Institute’s Practice Standard for Work Breakdown Structures (second edition, 2006), and its practical development follows Gregory T. Haugan, Effective Work Breakdown Structures (Vienna, VA: Management Concepts, 2002). Readers should consult the official publishers for current editions.
• The distinction between a program, a programming product, a programming system, and a programming systems product is summarized from Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering (Reading, MA: Addison-Wesley, 1975), chapter 2, “The Tar Pit,” where Brooks analyzes the difference between the bare code and the delivered, documented, integrated thing; the chapter’s application to product versus work breakdown is the author’s.
• The story-map discipline follows Jeff Patton with Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product (Sebastopol, CA: O’Reilly Media, 2014), including the backbone and the slicing of the map; the walking skeleton follows Alistair Cockburn, Crystal Clear: A Human-Powered Methodology for Small Teams (Boston: Addison-Wesley, 2004), where Cockburn names and explains the term.
• The user story as a planning unit traces to Kent Beck, Extreme Programming Explained: Embrace Change (Reading, MA: Addison-Wesley, 1999); the three C’s, card, conversation, and confirmation, follow Ron Jeffries, “Essential XP: Card, Conversation, Confirmation” (2001); and the INVEST mnemonic, independent, negotiable, valuable, estimable, small, and testable, follows Bill Wake, “INVEST in Good Stories, and SMART Tasks” (2003). The words are presented in the author’s own summaries, and the reader can consult the original sources for the full arguments.
• The work-package sizing guidance follows the general requirement of the earned-value management system criteria codified in ANSI/EIA-748, used widely in United States defense and government procurement, that work packages be discrete and short enough to measure progress within a reporting period; the specific one-to-two-week or roughly eighty-hour heuristic is presented here as practitioner practice, not as the text of the standard.
• ISO 21502:2020, “Project management: Guidance on project management,” addresses planning and the decomposition of work at a general level without prescribing a single mandatory breakdown format; this chapter’s structures, dictionary, and reconciliation checks are the author’s method-neutral working instruments. This book is independent of ISO, PMI, and all named framework owners.
• The composite cases, including Meridian Community Health Network, KijaniPay, and Northstar Relief Logistics, remain author-created illustrative material; the Meridian drill fragment and the KijaniPay merchant journey are the author’s teaching constructions consistent with the facts established in chapters 6, 10, and 13.