Chapter 16: Build the Integrated Roadmap and Management Plan

The date with no address

It is month twenty-one at KijaniPay, and the roadmap is beautiful. Zanele Dlamini, the delivery lead, has the new integrated roadmap up in front of the product council: five color-coded lanes, a market column, a feature column, and dates aligned in the right-hand margin like a typographic grid. Merchant onboarding in Lagos, merchant onboarding in Nairobi, payouts in beta, working-capital lending in January, and at the top, bold, “Launch: 30 November.” The room has seen roadmaps before, and this one finally looks like a plan.

Kwame Mensah, head of risk, squints at the payouts lane. “Where is the settlement rail?”

“The settlement rail is the payouts lane,” says Amara Osei, head of growth. “Settlement is the product. The merchants get paid within 24 hours. It’s right there.”

Kwame shakes his head. “The settlement rail is Savanna. The banking partner. Settlement runs through their system, and their integration is not on this roadmap.”

Thandi Mbeki, head of compliance, opens the folder she carries everywhere. “Our license application must name the settlement provider. The filing is due before the license decision, and the license decision is the launch’s precondition. If the roadmap does not tell me when the provider is signed, I cannot tell you when the license is granted.”

The support lead, who talks to merchants, says nothing, which is the most important sentence in the room. Zanele has learned that. The support lead’s silence means the beta merchants have started asking when their settlements arrive, and no roadmap row answers that question.

Zanele opens the dependency view. The banking partner row is there: “Savanna Settlement Bank, contract negotiation, sandbox access requested.” It has been there for six weeks. It has no owner, no date, no decision trigger, no escalation path. The roadmap hid it because the roadmap was built from dates. Every row answered “when” and none answered “what must be true first.”

This chapter is about that roadmap and the machine it was pretending to be. Chapter 14 decomposed the work without losing the whole, and chapter 15 gave the decomposition numbers that tell the truth about themselves. This chapter builds the thing that holds both: the integrated roadmap and management plan, the plan as a decision system rather than a prediction. The thesis is simple and it is the chapter’s whole argument: a plan is not a description of the future. A plan is a set of commitments arranged so that decisions can be made as evidence arrives. The roadmap that hides a dependency is not a plan; it is a hope with a date attached, and the date is doing the work the dependency should be doing.

What a plan is for

Why does a plan exist at all? Not to predict the future accurately; that is a forecast, and chapter 15 built the honest forecast with its range, its assumptions, and its pockets. A plan exists so that a project can act: it tells the team what to do next, the sponsors what to authorize, the operators what to expect, and everyone what evidence will decide the next question. The plan is the Delivery lens made into a machine. It fails when it tries to be something else: a promise to the calendar, a decoration for the steering committee, a contract to be used against the team when reality disagrees.

The plan’s job is integration. Scope, time, cost, resources, quality, risk, governance, change, and benefits each have their own artifacts: the scope statement from chapter 10, the estimate from chapter 15, the risk system from the chapters ahead, the governance from chapter 8, the benefit profiles from chapter 7. The integrated plan turns those artifacts into one operating model, because a project is not run by any single one of them. It is run by their intersections: the scope the budget cannot fund, the schedule that needs engineers the resource plan does not have, the risk only governance can decide, the benefit that depends on an adoption milestone the plan forgot. Those intersections are where projects actually live, and the plan makes them visible while there is still time to decide.

Every plan row should also answer a question someone will actually ask: “What do we do next?” “What do we authorize?” “What must be true for the next milestone to be real?” “What would we do if the assumption failed?” A plan that answers none of those questions is furniture, and the test is easy: open the plan at the banking-partner row and ask what decision it enables. At KijaniPay the answer was none, because the row said “contract negotiation” with no owner, no trigger, no date, and no escalation. It was not part of a plan; it was a placeholder in a table that was called a plan.

The plan is also the shared reference: people who never meet, never see the same documents, and never share a language must still agree on what happens next, and they do it through the commitments the plan carries. Ownership is a design decision, not an administrative detail.

The plan family

The word “plan” covers five different artifacts, and the discipline of this chapter begins with naming them, because each one serves a different decision and each one decays when it is used for the others.

The roadmap is the strategic layer: where the work is going — the outcomes, the major capabilities, the markets, the releases, the horizons — with dates at the level of direction rather than detail, aligning strategy, governance, and stakeholders and carrying the big assumptions openly. Its unit is the outcome or the capability, not the task, and its failure mode is promising more precision than its horizon supports: a roadmap with month-level dates at a two-year horizon has confused itself with a schedule. The KijaniPay roadmap was the document on the screen, failing exactly this way: the dates in the margin carried the authority of commitments, and the dependencies under them carried none.

The release plan is the empirical layer: what will actually be delivered to users, customers, or operations, in what increment, with what evidence of readiness. It is a forecast in the vocabulary of chapter 15 — the current best estimate of what ships when, grounded in what the team has actually completed, revised as evidence arrives. Its unit is the releasable increment, and its failure mode is the release that ships features but no value: the platform that launches “on time” while settlement, the whole point, remains broken. The release plan is where KijaniPay’s “launch” belongs, and the word itself is the trap: “launch” has four meanings, and a release plan must resolve them into one evidence-based definition of ready, or the plan is four plans sharing a word.

The stage plan is the bounded layer: the plan for a defined period, usually until the next gate or authorization, with scope, budget, and tolerances approved for that period only. It is the predictive discipline that keeps commitment alive: the organization authorizes what it can see, and the next stage is re-authorized on evidence. Its failure mode is the stage that stretches, the plan that quietly extends its boundary because re-authorization felt like overhead.

The baseline is the frozen layer: the approved reference version of scope, schedule, cost, and key controls, changed only through the change control chapter 39 will build. It is not the plan; it is the plan’s point of comparison. It exists so that “how are we doing?” has a stable answer, and its failure mode is the baseline no one changes when the world changes — the honest question “are we on track?” turned into “are we still in line with a promise we should have renegotiated?”

The management plan is the operating layer: the rules of the project itself — how work is authorized, how changes are decided, how risk is escalated, how quality is proven, how decisions are recorded, how people are coordinated. It is not a schedule of work; it is the constitution the work operates under. Its failure mode is the management plan as binder: complete, approved, and untouched, while the real decisions happen in corridors and the plan is updated never.

The five artifacts answer five questions: where are we going, what ships when, what do we commit for this period, what is our reference point, and how do we operate? A project needs all five. A project that collapses them into one document — the roadmap that is also the schedule, the baseline, and the constitution — will discover, at the worst moment, that its date had no address.

The five layers

The integrated plan is best seen as five layers stacked above the work, and each layer answers one question and belongs to one owner. This is the chapter’s primary picture, and it is worth drawing before anything else:

Figure 16.1: The five layers of the integrated plan. Each layer answers
one question, is owned by one role, and connects to the layers above and
below. Authority flows down, evidence flows up, and the seams between
layers are where contradictions appear.

  LAYER 1  STRATEGY AND BENEFITS        owner: sponsor
           "Why does this exist?"       success profile, business case,
           value, outcomes, benefit     benefit owners, stop-or-pivot
           owners, disbenefits          conditions (chapters 2, 7)

                 | authority flows down
                 v

  LAYER 2  RELEASES AND OUTCOMES        owner: product owner
           "What ships, for whom,       outcome-based roadmap, release
           with what evidence of        plan, definition of ready,
           adoption?"                   adoption targets (chapter 11)

                 |                   ^
                 v                   | evidence flows up

  LAYER 3  MILESTONES AND EVIDENCE     owner: delivery lead (integration)
           "What must become true,      milestone dictionary, gates,
           and how will we know?"       learning milestones, decision
           integration points,          dates (chapters 8, 16)

                 |                   ^
                 v                   | evidence flows up

  LAYER 4  WORK AND FORECASTS          owner: team
           "What work, in what         work packages, backlog, capacity
           order, with what capacity    plan, forecasts from throughput,
           and estimate?"               look-ahead (chapters 14, 15, 19)

                 |                   ^
                 v                   | evidence flows up

  LAYER 5  CONTROLS AND GOVERNANCE     owner: governance
           "How do we decide,          baseline register, change
           authorize, and hold?"       thresholds, decision rights,
           baselines, change, risk     escalation, reports (chapters 8,
           escalation, assurance       22, 39)

  The roadmap lives in layer 2. The management plan lives in layer 5.
  The baseline is the frozen surface between layer 3 and layer 5.
  A project whose roadmap contains nothing but layer-2 dates, with no
  layer-3 evidence, no layer-4 capacity, and no layer-5 ownership, is
  the KijaniPay roadmap: beautiful on one layer and empty on the others.

The layers are not a hierarchy of importance; they are a division of questions. The sponsor owns layer 1 because only the sponsor can answer why the work exists and who owns the benefits. The product owner owns layer 2 because only the product owner can decide what ships for whom. The delivery lead owns layer 3, the integration layer, because the milestones are where every other layer’s commitments meet. The team owns layer 4 because only the people doing the work can commit to its sequence and capacity. Governance owns layer 5 because only the authorized decision makers can hold the baseline and approve change.

Two flows bind the layers together, and both matter. Authority flows down: the strategy authorizes the releases, the releases demand the milestones, the milestones schedule the work, and the controls govern it all. Evidence flows up: the work produces forecasts, the forecasts test the milestones, the milestone evidence informs the releases, and the release evidence tests the strategy. A plan works when both flows are real. The KijaniPay roadmap had the top-down flow — dates cascading from strategy to work — and almost none of the bottom-up flow, the evidence that corrects the dates. That is why it looked coherent and was not. Coherence in a plan is not the dates lining up; it is the evidence flowing both ways.

Milestones as evidence, not decoration

The milestone is the unit of the integration layer and the most abused row in project planning. In the popular imagination it is a date with a name — “Launch: 30 November,” “Beta complete: October,” “Milestone 4: Q3” — and the date is the entire content. The discipline this chapter teaches is the opposite: a milestone is a claim that at a named moment, something will become true and checkable. The date is the least interesting part of the claim.

The test is the evidence question. For every milestone, ask: what becomes true, and how will we know? The KijaniPay launch milestone fails the test instantly, because “launch” has four meanings and none of them is evidence. The milestone dictionary is the minimum viable tool that fixes this: one row per milestone, with the evidence that proves it, the owner who certifies the evidence, the due date, the trigger that starts the work, and the dependency that could block it. The dictionary exists because a milestone without evidence is a wish with a date, and a milestone without an owner is a date with no one accountable.

Three kinds of milestones are worth distinguishing, because they serve different decisions.

An acceptance milestone is the predictive kind: work done, inspected, accepted against criteria. “The clinic’s integrated readiness checklist is signed by the clinical operations director” is an acceptance milestone; “clinic opens” is not, because opening depends on things the checklist can only reveal. Its evidence is the acceptance record, and its failure is the milestone that names the event but not the acceptance: the ceremony without the certificate, the ribbon cutting that happens while the ramp remains unfinished.

An outcome milestone is the adaptive and product kind: a measurable change in behavior or value, not a delivered artifact. “Merchants can see their settlements within 24 hours for 30 consecutive days at the target reconciliation rate” is an outcome milestone; “payouts feature shipped” is not, because the feature can ship and the outcome fail — chapter 6’s lesson exactly. Its failure is the milestone that measures activity instead of outcome: “onboarding launched” when the question is “merchants successfully taking payments.”

A learning milestone is the third kind, and the one most plans omit: a named moment when the project must review evidence and decide — a decision date wearing a milestone’s clothes. “By 15 October, review the settlement pilot results and decide whether the 30 November launch holds, splits, or moves” is a learning milestone, not a date decoration: it is a scheduled decision. The project that schedules its deliveries but not its decisions will make its biggest decisions in the corridors, under pressure, without evidence.

The milestone dictionary also does a job the roadmap cannot: it forces the dependency onto the page. The KijaniPay milestone “license decision granted” has an evidence question, the filing, and the filing has a dependency, the named settlement provider, and the provider has a dependency, the signed contract with Savanna, and the contract has a dependency, sandbox access and the partner’s integration team. The dictionary is a chain of evidence running backward from every date to the work that makes it true, and that chain is the roadmap’s honest skeleton. When the chain has a gap, the roadmap has a hidden dependency, and the gap is exactly where the plan will lie.

The pilot the roadmap hid

The settlement pilot is the chapter’s worked calculation, and it shows how a plan row hides work when it is written as a date. The pilot as scheduled: “Settlement pilot closes 15 October, 400 merchants, Lagos.” Four hundred merchants, at an average of 25 transactions a day, is 10,000 transactions a day. Suppose the pilot’s success threshold is that 99.5 percent of transactions reconcile end to end, the settlement reaches the merchant within 24 hours, and the exceptions get investigated. At 10,000 transactions a day, a 99.5 percent reconciliation rate leaves 50 exceptions a day. Each exception — a settlement that did not arrive, a mismatch between the merchant’s records and the bank’s — costs about 15 minutes of a human investigating. Reconciliation exceptions in payments cannot be resolved by a script alone; they need a person to decide whose money it is. Fifty exceptions at 15 minutes each is 750 minutes, 12.5 hours, about a day and a half of one person’s work, every day, just to hold the pilot at its threshold.

The plan did not have that person. The roadmap’s pilot row was a date and a merchant count, and the staffing, the exception-handling work, the follow-the-sun handoff to the bank’s ops team, the escalation path when an exception breaches the 24-hour promise — none of it was on any layer. The pilot was scheduled to close on 15 October, and the plan had no line for the daily exception work that would consume the two QA specialists the resource plan had already double-booked. The date was fine. The plan was not.

The calculation also makes the threshold decision explicit, which is what numbers are for. At a 99.9 percent threshold, the same 10,000 transactions leave 10 exceptions a day, 150 minutes, about a third of a person, and a completely different support design. The choice between 99.5 and 99.9 percent is not a quality slogan; it is a decision about staffing, escalation, merchant trust, and the cost of exceptions, and the plan must carry that decision with its numbers visible. Chapter 15’s discipline applies to the plan itself: the numbers must be reproducible, assumption-labeled, and reconcilable across layers, and when they do not reconcile, the plan has found its own contradiction.

The seams where plans disagree

Chapter 14 taught the seam — the boundary where responsibility changes — and the discipline of owning it rather than assuming it. The integrated plan has the same anatomy one layer up. It is five layers and a dozen artifacts, and where they meet is where contradictions live. Every disagreement is a decision waiting to be made, and a plan that leaves the decision unmade has made it silently.

Four seams matter most, and each has a characteristic contradiction.

The scope-to-schedule seam is where what we promised meets when we promised it. The contradiction is the scope item with no schedule row, or the schedule row with no scope owner. KijaniPay’s scope promised 24-hour settlement in Lagos and Nairobi from launch; the schedule delivered Nairobi at full volume on 26 February. The roadmap was the layer that hid the difference.

The schedule-to-resources seam is where the dates meet the people. The contradiction is the schedule that needs 14 engineers while the resource plan lists 12, or the two QA specialists allocated full-time to two different tests in the same two weeks. Chapter 19 will build the capacity machinery; here the discipline is the check: every committed period on the schedule must have the capacity to match, and when it does not, the plan must choose — add capacity, change scope, or move the date — and the choice is a decision with an owner, not a discovery in month twenty-six.

The budget-to-scope seam is where the money meets the promise. The contradiction is the working-capital lending pilot for 500 merchants with no lending capital and no credit function on the resource plan. The budget is a statement of what the project has decided to buy; when the scope outruns the budget, one of them is lying, and the plan must say which.

The schedule-to-governance seam is where the dates meet the decisions. The contradiction is the milestone that requires a decision no one is scheduled to make: the license decision expected on 1 November while the filing, which depends on a signed settlement provider, has no date because the contract has no owner. The plan that schedules the decision without scheduling its preconditions will meet its decision date with nothing to decide.

The check is a cadence, not an event. At every plan review, walk the seams: take the scope statement and ask where each promise lands on the schedule; take the schedule and ask where each committed period finds its capacity; take the budget and ask what each line buys in scope; take the milestones and ask which one needs a governance decision and whether its preconditions are scheduled. The seam walk is boring, and it is the single most valuable hour in the planning calendar, because it is where the plan discovers what it has been hiding.

Assumptions, decision dates, and learning milestones

The integrated plan has three kinds of rows that most plans leave out, and each one is a commitment wearing a different name.

The assumption row names what the plan is betting on. Chapter 15 gave the assumptions log as the estimate’s nervous system; the plan needs the same rows at its own level. The KijaniPay plan is betting that Savanna’s sandbox will be provisioned in a week, that the regulator’s processing queue is eight weeks, that the acquisition rumor about Savanna changes nothing, that the beta merchants stay patient through November. Each assumption has a price: if it fails, the plan moves, and the movement is a decision, not a surprise. The row carries the assumption, the owner, the test date, and the consequence, so the plan’s bets are visible before they are called. The failure is the silent assumption — the bet never written down, the contract assumed nearly done and discovered in month twenty-four to be nowhere near.

The decision date is the scheduled moment when a choice must be made, and it deserves the same respect as a delivery date, because it is a delivery of judgment. “By 15 October, decide: sign Savanna, sign an alternative provider, or redesign the settlement architecture around a licensed agent network.” A decision date has preconditions, the evidence that must exist before the choice, and an owner, the person with authority to decide. Chapter 8 built the decision rights; the plan operationalizes them by scheduling the decisions themselves. The project that schedules only deliveries will make its decisions late, under pressure, and without the evidence that a scheduled decision would have demanded.

The learning milestone is the decision date with a review attached: the pilot review, the throughput re-forecast, the adoption check. Its evidence is the review pack, its output is the decision record, and every project needs it scheduled explicitly, because learning that is not scheduled does not happen. The adaptive cadence treats learning milestones as its spine; the predictive cadence hides the same idea in its gates; and chapter 15’s re-estimation gate is the same instrument in different clothes — the plan’s scheduled honesty.

Rolling wave and progressive elaboration

The plan cannot be built at one level of detail, and the attempt to build it all at one level is one of the most common planning failures: the roadmap drawn in month-level detail at a two-year horizon, or the schedule that promises task-level precision for work that has not been designed. The craft answer is rolling-wave planning: plan near-term work in detail, plan far-term work at the level its knowledge supports, and refine the far layers as the work approaches and evidence accumulates. The practice is described in the PMBOK Guide’s vocabulary and used by planners across delivery approaches. The principle is chapter 15’s cone of uncertainty applied to the plan itself: the width of the plan’s detail should match the width of its knowledge, and the detail should narrow only as the uncertainty is retired, by decisions and evidence, never by the calendar.

Progressive elaboration is the same idea as a discipline: the plan becomes more detailed as information arrives, and the elaboration is not rework, it is the plan’s normal growth. Plan at the level of knowledge, refine on a schedule, and never confuse a detailed plan with a well-informed one. At KijaniPay the far horizon, the lending pilot and the expansion markets, belongs on the roadmap as direction, with outcome hypotheses and decision triggers, not week-level commitments. Detail without knowledge is false precision, chapter 15’s precise liar in plan form.

The rolling wave has an explicit rhythm: the near layer is re-planned in detail every cadence, the next layer is re-planned as its gates approach, and the far layer is reviewed, not planned, with its assumptions challenged and its direction confirmed or changed. The cadence is where the plan becomes alive, and its design — weekly, monthly, per iteration, per gate — must match the delivery approach and the governance. This is time pacing: Kathleen Eisenhardt and Shona Brown, writing in Harvard Business Review in 1998, called it building strategic rhythm on the calendar rather than on events, and the insight transfers whole: the plan’s reviews must be scheduled by the calendar, because event-driven review, waiting until something goes wrong, is how plans die quietly.

Baseline integrity and change thresholds

The baseline is where the plan meets the commitment, and it deserves its own discipline, because it is the project’s honesty instrument in both directions: it makes “how are we doing?” answerable, and it makes change visible. Chapter 15’s vocabulary applies: the estimate is the analysis, the target is the ambition, the commitment is the obligation, and the forecast is the current evidence-based expectation. The baseline is a particular commitment — the approved reference version of scope, schedule, and cost — and the version against which performance is measured. The earned-value management criteria codified in ANSI/EIA-748, the standard used widely in defense and government procurement, have long required a formal baseline and disciplined change to it. The idea is method-neutral: without a baseline, variance is meaningless, and without disciplined change, the baseline decays into fiction.

The discipline has three parts. First, decide what is baselined: the scope statement, the milestone dictionary, the cost and time forecasts at the approved confidence, and the key controls; and what is not: the near-term detail that rolls forward, the contingency that moves by decision, the management plan that is a living constitution. Second, define the change thresholds: the band within which the project absorbs change and the band that requires governance. A useful threshold is explicit and small: at KijaniPay, changes moving the launch forecast by more than 10 days, or the budget by more than 5 million units, go to the product council with a decision brief; changes inside the band are absorbed by the project and reported, not gated. The threshold exists so that change control does not become the bottleneck of ordinary work, and so that consequential change does not slip through as ordinary work. Third, run the baseline as a surface, not a wall: the forecast moves with evidence, continuously, and the baseline moves by decision, deliberately, and the two are never confused. The project that treats its baseline as a wall refuses to re-baseline when the world changes, and the refusal does not protect the commitment; it protects a number that has already been superseded. The re-baseline is a decision, with the old baseline preserved as history, the change record explaining what happened, and the new baseline presented with its evidence. Chapter 15’s two-pocket discipline applies at plan level: the contingency pocket moves within the project against named risks, the management reserve moves only through governance, and the plan must report both pockets separately, because the project that merges them will spend the unknown-unknowns money on known problems and call it health.

Ownership: who holds each layer

The plan fails most often not because it is wrong but because nobody owns it, and the ownership map is the plan’s least decorated and most consequential design. Every artifact, every milestone, every assumption, every decision date has an owner too, and the owner is the person who answers for it. The milestone dictionary is the ownership instrument: the license milestone has a named owner who certifies its evidence, and the Savanna contract row, the row the roadmap hid, has a named owner who answers for its trigger date. A plan row with no owner is not a plan row; it is a hope with a column.

Co-creation is the other half of ownership, and it is the difference between a plan that is distributed and a plan that is held. The team builds the work layer, the layer where their commitment lives, because a schedule imposed from above is a schedule the team will fight, and a schedule the team built is a schedule the team will defend. The delivery lead builds the integration layer with the owners of each milestone; the product owner builds the release plan with the team’s forecasts and the stakeholders’ readiness; the sponsor builds the strategy layer with the benefit owners. The planning session is not a meeting where the plan is presented; it is the place where the plan is made, and the earlier chapters’ artifacts — the story map from chapter 14, the estimates from chapter 15, the stakeholder map from chapter 9 — are the raw material. The plan’s final test of ownership is the escalation question: when the milestone slips, the assumption fails, or the decision date arrives, there is a named person who must act, and the plan says who.

The planning basis and the baseline register

Two small documents carry the plan’s credibility, and together they are the minimum viable toolkit of this chapter.

The planning basis is the plan’s basis of estimate, from chapter 15, at plan level: one page that says what the plan commits, what it assumes, what evidence the dates rest on, which forecasts are ranges and which are commitments, what was excluded, what would change the plan, who owns each layer, and when the plan is reviewed. Every plan is a bundle of judgments, and the bundle is the real subject of every plan review. A plan without a basis is chapter 15’s orphan in schedule form: a set of dates with no address, impossible to challenge, impossible to improve. The KijaniPay roadmap had no basis, which is why the council could admire it and nobody could audit it; the basis would have shown what the 30 November date was resting on, and the answer — an unsigned banking contract and an unprovisioned sandbox — would have been visible before the admiring.

The baseline register is the plan’s change ledger: one row per baseline change, the artifact, the version, the date, the approver, the reason, the decision record that authorized it, and the link to the change request. Baselines change; the discipline is not that they never change, it is that the change is recorded, approved, and explainable. The register is also the audit trail that chapter 24 will demand, the evidence that the plan was governed rather than drifted, and it is the tool that turns the re-baseline from an argument into a record.

The plan as a living decision system

The last discipline is cadence, because a plan is not a document, it is a rhythm. The plan has a review schedule, and the review schedule is part of the plan: daily coordination to unblock, the weekly look-ahead to confirm the near-term wave and walk the seams, the monthly plan review to test the milestones against evidence and challenge the assumptions, and the gate review, per iteration, per stage, to authorize the next wave on evidence. Each review has a purpose, a participant set, and a decision, and a review with no decision is a meeting. The plan that schedules meetings instead of reviews will look busy and decay — chapter 12’s status theater in calendar form.

The cadence is also the plan’s learning system, which is why the learning milestones live on the plan rather than in the team’s head. Every review produces evidence, the evidence is compared to the baseline and the forecast, the difference is interpreted, and the interpretation feeds the next decision. This is the Learning lens installed inside the Delivery lens, the multiplicative relationship of the Mastery equation, and it is the plan’s deepest purpose: the plan exists to make learning routine, so that the project adapts before the surprise, not after it. The plan that is updated only when someone complains is already a lie; the plan that is reviewed on schedule, with the baseline, the forecast, the assumptions, and the seams all walked, keeps the project honest by keeping the project’s decisions scheduled.

The delivery approaches differ in the cadence’s shape, not in its existence. The predictive project, the BlueLine corridor, runs stage plans and formal gates, with the baseline frozen and change moving through the change control that chapter 39 will build; its reviews are the gates, and its discipline is the acceptance evidence. The adaptive project, the KijaniPay platform at its best, runs iteration cadences, with the release plan as forecast and the commitments at the level the empirical evidence supports; its reviews are the iteration reviews and retrospectives, and its discipline is the definition of done. The hybrid project, the Meridian clinics, runs both at once — construction stage plans and clinical workflow cycles — and its plan lives or dies at the seams, the integration milestones where the stage plan’s evidence and the cycle’s evidence must meet. The chapter 13 lesson applies to the plan itself: the cadence is a design decision, matched to uncertainty, consequence, feedback needs, and governance, and it is re-decided, not defended.

The failure patterns

The plan’s failure patterns deserve to be named as characters, because each one is produced by competent people doing what the room rewarded.

The promise tree is the roadmap of dates with no dependencies, no assumptions, and no owners: every row answers “when” and no row answers “what must be true first.” It is the KijaniPay roadmap on the screen, beautiful and empty, and it is the most common plan in the world, because it is easy to make and pleasant to see. Its tell is the question the room cannot answer: “What has to happen for this date to be real?” Its cost is paid at the first missed date, when the plan’s authority — never earned by dependencies — evaporates with the date.

The furniture plan is the integrated management plan that is complete, approved, and unused: the binder on the shelf, the constitution nobody consults. It is produced by the planning effort that mistakes completeness for value, and it is maintained by the meetings that update the document without updating the project. Its tell is the plan’s last-modified date and the decision made today that the plan says nothing about. Its cost is the project running on oral tradition, every decision re-litigated, every handoff rediscovered.

The hidden dependency is the plan that omits what it cannot resolve: the row that is not there, the contract that is not signed, the partner that is not on the roadmap, the work that lives in no layer. It is chapter 14’s disappearing 100 percent in plan form, and it is the most dangerous character in this chapter, because it is invisible by construction. Its tell is the corridor conversation, the dependency that is discussed everywhere except the plan. Its cost is the date that arrives with the dependency unresolved and the plan claiming it was surprised.

The frozen baseline is the plan that cannot move: the baseline defended past the evidence, the change requests refused to protect the number, the re-baseline treated as failure. It is produced by the confusion this chapter opened with, between a commitment and a prediction: the commitment is real, the prediction is not, and the baseline that never changes is protecting the prediction at the expense of the commitment. Its tell is the forecast and the baseline diverging, month after month, with no decision recorded. Its cost is the commitment itself, which is not preserved by refusing to re-baseline; it is destroyed, because the refusal converts an honest renegotiation into a late surprise.

The four characters share one root, and it is the chapter’s thesis: each one replaced the plan’s job, making decisions possible, with a performance. The promise tree performed confidence, the furniture plan performed completeness, the hidden dependency performed coverage, and the frozen baseline performed stability. The plan that serves decisions needs none of the performances, and it needs all of the substance: the dependencies on the page, the assumptions in the log, the owners on every row, the baseline that moves by decision, and the cadence that checks it all.

The assistant’s narrow lane

The assistant has a genuine and bounded place in planning, and its boundary is the book’s standing boundary. It can draft the roadmap layers from approved strategy documents, benefit profiles, and release notes, labeling what came from where. It can cross-check the layers against each other — comparing the dates in the roadmap against the milestones in the dictionary, the capacity in the resource plan against the demand in the schedule — and flag contradictions for a human to judge, which is the seam walk done at speed. It can draft milestone dictionary entries and assumption rows from provided artifacts, summarize differences between document versions, and generate the planning-basis skeleton from the plan’s own content. The source data is the approved, non-confidential project context, redacted before prompting; the drafts are drafts until a named owner verifies them; and the audit record says what was generated, from what, checked by whom, and decided by whom.

Four boundaries matter in planning, because planning is where the machine’s fluency is most seductive. First, the hidden dependency is not discoverable by cross-referencing documents: the Savanna contract lived in an email thread, not in the roadmap, and no model can find what the documents omit; the dependency map’s completeness is a human judgment, built from conversations and corridors, and the assistant’s flag “no contradiction found” means only that the provided documents agree. Second, the commitment is not delegable: the assistant can draft the milestone dictionary, and the named owner makes the commitment, because the commitment is an acceptance of obligation under the governance of chapter 8, and no draft is an obligation. Third, the interpretation of external timing, the regulator’s queue, the partner’s roadmap, the market’s patience, is judgment grounded in relationships the assistant does not have; its assumptions must be challenged, not accepted. Fourth, the data is sensitive: banking partner commercial terms, merchant settlement data, and regulatory filings do not belong in unapproved systems, and the plan’s commercial and personal content stays on the project’s owned infrastructure. The verification is the room: the leader walks the seams with the owners, tests the assistant’s contradiction flags against the corridor conversations, and makes the decisions the plan exists to support, while the machine accelerates the drafting and the flagging, and the ownership, the dependencies, and the commitments stay human.

Practice

One. A quick classification. For each statement, name the artifact it belongs to, roadmap, release plan, stage plan, baseline, or management plan, and the decision it serves. (a) “The settlement rail must be signed with a licensed provider before the license filing, and the filing must precede the license decision.” (b) “Launch forecast 30 November with an 80 percent range of 24 November to 18 December, from the throughput data.” (c) “Changes moving the launch forecast more than 10 days, or the budget more than 5 million units, require product council approval.” (d) “Merchant onboarding in Lagos, settlement pilot, license decision, lending pilot, all as outcome rows with owners.” (e) “Approved reference version 4.2 of scope, milestones, and cost forecast, changed only through the change register.” (f) “Through 15 December: onboarding wave one, pilot exceptions resolved within 24 hours, capacity 12 engineers at 80 percent focus.”

(a) is the management plan’s operating rule, or the milestone dictionary’s dependency logic, depending on form; either way it serves “what must be true first.” (b) is the release plan as forecast, in chapter 15’s vocabulary; it serves “what will really ship, from evidence.” (c) is the management plan’s change threshold, serving “who decides this change.” (d) is the roadmap, serving “where are we going, in what order, for whom.” (e) is the baseline, serving “what is our reference point.” (f) is the stage plan or near-term wave, serving “what do we commit for this period.” The common error is calling everything a roadmap; the roadmap with 10-day change thresholds has swallowed the management plan, and the plan that cannot say which artifact a statement belongs to has no operating model.

Two. A field drill: build the milestone dictionary. Take an initiative you are currently planning, and write the integration layer for it. (a) Name the five most consequential milestones, and for each one write the evidence that proves it, “what becomes true and how we will know,” not the date. (b) For each milestone, name the owner who certifies the evidence and the dependency that could block it, and for each dependency, name its owner and its trigger date. (c) Identify the three assumptions the plan is betting on, with the test date and the consequence for each. (d) Walk the seams: take your scope statement and check where each promise lands on the plan, and report the contradictions you find.

The drill succeeds when the evidence is checkable, the dependencies have owners, and the seam walk finds at least one contradiction, because every plan has one. The most common failure is the evidence that restates the date, “pilot complete by 15 October,” which is the promise tree wearing a dictionary’s clothes; the repair is the outcome test, “400 merchants paid within 24 hours for 30 consecutive days at the reconciliation threshold,” which is checkable. The second failure is the dependency with no owner, the row that exists and answers for nothing; the drill’s job is to make that visible, because the hidden dependency of the chapter is usually hiding in plain sight as an ownerless row.

Three. A decision room: the launch that cannot be scheduled. It is month twenty-one at KijaniPay, and the product council is deciding the 30 November launch. The evidence: Savanna’s contract is unsigned, its sandbox access has been pending six weeks, the partner’s integration team has gone quiet, and the acquisition rumor is unresolved. The license filing must name the settlement provider, the regulator’s published processing time is eight weeks, and the pilot’s exception staffing is not in the plan. The options on the table: hold 30 November and compress the settlement work, an overtime push on a dependency the project does not control; move the launch to 31 January with both markets; launch Lagos only on 30 November with Nairobi to follow; or keep the date but re-anchor it as an evidence milestone, “merchant onboarding begins when settlement evidence passes,” with the launch redefined per chapter 12’s four meanings. Decide what Zanele should recommend, what she should refuse, and what the milestone dictionary should say about the 30 November row.

The defensible answer combines the re-anchor with the staged market: re-anchor the roadmap from dates to dependencies, make the settlement evidence the gate, and treat 30 November as the earliest credible start for Lagos merchant onboarding, not a public launch, with Nairobi following on evidence. The date was never the commitment; the settlement promise was, and re-anchoring protects the commitment while surrendering the fiction. The refusal is compressing the settlement work: the dependency is the partner’s integration team and its sandbox, which no overtime at KijaniPay can speed, and a plan that schedules work it does not control as if it controlled it is the promise tree in its purest form. Reasonable but risky: holding 30 November with an explicit decision date in October, “if the contract is not signed by 15 October, the launch moves,” which is defensible only if the trigger is enforced, and the enforcement is the whole game. The unsafe choices: the silent hold, keeping the date and the silence; the word-game relaunch, redefining “launch” per chapter 12 without changing the plan, which converts an honest redefinition into the four-plans problem restated; and the compressing push, which spends the team’s credibility on a dependency the project does not own.

Four. The mastery drill: five contradictions. Below are excerpts from four documents of one project, a merchant platform launch. Find five contradictions, name the seam each one lives on, and say what decision each contradiction requires.

Scope statement: “The platform launches in Lagos and Nairobi on 30 November with end-to-end settlement for merchants within 24 hours in both markets. Fraud controls are proven at production volume before public launch. A working-capital lending pilot serves 500 qualifying merchants in Lagos by 31 January.”

Budget: “Approved investment 210 million units: engineering 120, compliance and licensing 35, banking and settlement integration 20, growth and adoption 25, operations and support 10. Funding approved to 31 March. Contingency of 15 million units held by the project against named risks.”

Schedule: “30 November: public launch, both markets. 15 October: settlement pilot closes, 400 merchants, Lagos only. 1 November: license decision expected. 15 November: fraud-control volume test. 31 January: lending pilot opens. 26 February: Nairobi settlement reaches full volume. The schedule assumes 14 engineers across five delivery streams from October.”

Resource plan: “12 product engineers, 2 QA specialists, 1 integration engineer, 1 compliance analyst, 1 support lead, 1 data analyst. The two QA specialists are allocated full-time to the settlement pilot closure from 1 to 15 November and to the fraud-control volume test from 1 to 15 November. The integration engineer owns both the banking-rail integration and the fraud-control instrumentation.”

First, the scope-to-schedule seam: scope commits 24-hour settlement in both markets from launch, while the schedule delivers Nairobi at full volume only on 26 February; the decision is whether launch means both markets or the scope must change, and chapter 12’s four meanings of launch are exactly the instrument for it. Second, the schedule-to-resources seam: the schedule assumes 14 engineers from October, the resource plan lists 12; the decision is add capacity, change scope, or move the date. Third, the resource plan’s own seam: the two QA specialists are double-booked, full-time on the pilot closure and full-time on the fraud volume test in the same two weeks, and the pilot’s 50 exceptions a day from the chapter’s arithmetic would consume them anyway; the decision is who staffs the pilot closure, who staffs the volume test, and who staffs the daily exception work. Fourth, the budget-to-scope seam: the scope commits a lending pilot for 500 merchants, and the budget has no line for lending capital or lending operations, while the resource plan has no credit or collections role; the decision is whether the lending pilot is in scope and what it costs. Fifth, the schedule-to-governance seam: the license decision is expected 1 November, the regulator’s queue is eight weeks, the filing must name the settlement provider, and the provider contract is unsigned; the decision is the filing date’s trigger, the provider decision date, and the 30 November launch’s dependency on both. None of the five is a mistake by a bad planner; each is a commitment made on one layer without the other layers, which is the integrated plan’s whole reason for existing. The unsafe response is to declare one document the source of truth and amend the others to match, because each layer answers a different question, and the contradictions are the plan telling the truth about the decisions that were never made. A defensible alternative is a sixth contradiction if the reader finds one; credit belongs to any finding that names a real seam and a real decision.

Five. The transfer question. Look at the roadmap your project is carrying. Which layer does it actually cover, and which three layers are empty? Where is your banking-partner row, the dependency that has an owner in the corridor and no owner in the plan? If you added one artifact this week, the milestone dictionary, the planning basis, or the baseline register, which would change the next decision more, and why?

The durable principle: a plan is a set of commitments arranged so that decisions can be made as evidence arrives, and its mastery is not the accuracy of its dates but the visibility of its dependencies, the ownership of its rows, the honesty of its assumptions, and the cadence of its reviews. The roadmap that hides a dependency is not a plan; it is a hope with a date, and the date will do the deciding. The most common next failure is quieter than the four characters named here: the plan gets integrated, the layers get drawn, the dictionary gets built, and then the cadence decays, the reviews become meetings, the seams stop being walked, and the plan returns to furniture while the project runs on corridors and email threads. The plan must be carried into execution itself, the rhythm of work, review, and decision that chapter 30 will build, because the integrated plan is not finished when it is written; it is finished when the project’s decisions are made on it, every week, on schedule, in the light.

Notes

• The composite cases remain author-created illustrative material. KijaniPay’s month-twenty-one product council scene, the date-driven roadmap, the Savanna Settlement Bank dependency, the license-filing rule, the pilot arithmetic, and all named characters are the author’s teaching constructions consistent with the facts established in earlier chapters: the merchant platform and the 24-hour settlement promise from chapters 6 and 14, the launch plan and its four meanings of “launch” from chapter 12, the throughput-based forecasting discipline from chapter 15, and the staged Lagos and Nairobi markets from chapter 12. The pilot arithmetic is reproducible from the text: 400 merchants at 25 transactions a day is 10,000 transactions a day; at a 99.5 percent reconciliation threshold, 50 exceptions a day; at 15 minutes each, 12.5 hours of exception work a day; at a 99.9 percent threshold, 10 exceptions and 2.5 hours. The license queue of eight weeks, the 210 million-unit budget, the engineering counts, and the 30 November and 31 January dates are author-created teaching numbers for this chapter’s exercises.
• The plan family, the five layers, the milestone dictionary, the planning basis, the baseline register, the seam walk, and the change-threshold discipline are the author’s method-neutral working instruments. The layer diagram (Figure 16.1) is the author’s synthesis, not a reproduction of any standard’s model; the term “performance measurement baseline” is used in project management literature, and the earned-value management criteria codified in ANSI/EIA-748, “Earned Value Management Systems,” the standard used widely in defense and government procurement, require a formal baseline against which performance is measured and disciplined change to it; readers should consult the current version of the standard for the criteria as they stand at their date of use.
• Rolling-wave planning and progressive elaboration follow their standard practitioner usage: planning near-term work in detail and later work at a level the available information supports, then refining as evidence accumulates. The PMBOK Guide (Eighth Edition, Project Management Institute, November 2025) addresses planning and baselines as part of its performance domains and describes the planning processes in its vocabulary; this book describes the ideas in its own words and remains independent of PMI and the PMBOK Guide. ISO 21502:2020, “Project management: Guidance on project management,” addresses planning, baselines, and change at a general level without prescribing one plan format; this book’s five-layer model is the author’s own.
• Time pacing follows Kathleen M. Eisenhardt and Shona L. Brown, “Time Pacing: Competing in a Market That Won’t Stand Still,” Harvard Business Review, March-April 1998, which argued that firms that time pace, building strategic rhythm on the calendar rather than on events, navigate change more predictably; the idea is applied here at plan-cadence level, and the chapter’s treatment is the author’s.
• The Scrum vocabulary, where it appears, follows the current Scrum Guide, November 2020 version, by Ken Schwaber and Jeff Sutherland: Sprint Planning produces a plan of work for the Sprint, the Product Backlog is refined and re-ordered as learning arrives, and the Definition of Done is the formal description of the state of the Increment. The “definition of ready” used in the release-plan discussion is an industry practice, not part of the Scrum Guide, and is described here as such.
• The failure patterns named in this chapter, the promise tree, the furniture plan, the hidden dependency, and the frozen baseline, are the author’s own constructions, consistent with the failure-aware teaching style established in chapters 13, 14, and 15 and with chapter 14’s disappearing 100 percent. The hidden dependency extends chapter 14’s seam discipline to the planning layer, and the frozen baseline extends chapter 15’s forecast-versus-commitment vocabulary.