Chapter 13: Choose and Tailor the Delivery Life Cycle

The vendor’s question

It is month eight at Meridian, and the meeting has been going sideways for an hour. Dana Okafor, project leader, has the room she always has: Elena Marchetti, the sponsor, at the head; Marcus Chen, the platform lead; Nora Kariuki, director of clinic operations; and the vendor’s implementation lead, who came to settle one question before the statement of work gets priced.

“Agile or waterfall?” the vendor says. “We need to know before we quote.”

The room assumes this is a simple question with a simple answer, and that is the first problem. The second problem is that the room has been answering it differently all month. Marcus has been running the platform work in two-week cycles with the clinicians, refining the medication-list workflow every time the exam room contradicts the mock-up, and he calls that agile. The construction contractor, who left the meeting before the argument started, is building clinic two to a fixed drawing set and a liquidated-damages date, and the procurement office calls that waterfall. Nora has been mapping adoption wave by wave, clinic one first, clinics two and three next. She learned in chapter 11 that trained staff revert to paper under workload pressure, and that lesson has a schedule attached to it. The certification auditor, who is not in the room, will ask one question at every clinic gate: show the evidence. The grant that funds everything ends at month thirty-six, and the grant’s reporting officer will not care which word the project uses; she will count wait times and screening uptake.

Dana looks at the vendor and says what she has been thinking for a month: “We are not either of those. We are an architecture. The building is predictive, the workflows are iterative, the rollout is incremental, and the platform is adaptive inside a gated release. The question is not what we are. The question is what each workstream is, where the seams are, and who owns them.”

The vendor’s implementation lead, who has priced hundreds of these, relaxes. “That is a hybrid. We can quote that, if you tell us which unit the price attaches to and which evidence opens each gate.” The room is suddenly quiet, because nobody has asked the question that way before. The vendor just did the project a favor: it refused the false binary, and it named the real deliverable of this chapter. The delivery life cycle is not a brand. It is a decision architecture built from two uncertainties, moderated by the price of change, the speed of feedback, and the governance that must be able to hear the feedback. Get those factors right, and the choice of words, agile, waterfall, hybrid, or none of them, becomes a label for a decision already made. Get them wrong, and the label is a promise the work will not keep.

This chapter opens the Delivery lens of the book, Project Mastery = Judgment × Alignment × Delivery × Learning, and the whole lens stands on it: decomposition, estimation, planning, scheduling, quality, risk, and execution all run inside a chosen way of working. Choose the life cycle badly, and every later tool is applied to the wrong problem. The Alignment lens built the intent; the Delivery lens now has to decide how the work will flow from uncertainty to accepted outcome. The thesis of the chapter: the life cycle is chosen, not inherited; it is chosen from two questions, what is uncertain and what costs to reverse; it is tailored deliberately, not adopted wholesale; and it is re-decided as evidence changes. The vendor’s question was a gift. This chapter teaches what to do with it.

Five life cycles, one decision

The vocabulary needs to be precise before the decision can be, because the words are used as if they were one thing and they are five. The PMBOK Guide, Sixth Edition (Project Management Institute, 2017), separated four life-cycle families: predictive, iterative, incremental, and agile. The Seventh Edition (2021) regrouped them as development approaches — predictive, hybrid, and adaptive — with delivery cadence as a separate dial. The regrouping is useful; the underlying distinctions are older and durable. Say them in the project’s own words.

A predictive life cycle fixes the intended outcome early and then executes against it: define the scope, baseline it, build to it, measure progress against it. It is plan-driven, and its central instrument is the baseline with a gate. It suits work where the outcome can be defined well enough up front and where changing it later is expensive, which is why construction, regulated hardware, and long-lead procurement live there. The construction workstream at Meridian is predictive: the clinic is a fixed building program, the drawings are frozen, and the contractor builds to them.

An iterative life cycle refines one deliverable through repeated cycles. The word matters: iteration means the same thing, improved; it does not mean more things. Each pass through the medication-list workflow produces a better version of the same workflow, because the clinicians look at it in a live consult and say “the list must open in three seconds, at arm’s length, with the current dose marked,” and the design absorbs the correction. Iteration is how you reduce uncertainty about a single thing. Incremental life cycles do the opposite: they add capability in slices. Increment means more of the whole, delivered safely, with each slice usable on its own. Meridian’s rollout is incremental: clinic one goes live with the platform, then clinics two and three, each wave adding a fully working clinic to the network.

An adaptive life cycle iterates and increments together, and adds the property that makes it different from the sum of the two: the plan itself is re-decided from the feedback. Adaptive work does not refine toward a pre-fixed definition of done; it re-defines what is worth doing next, every cycle, from evidence of what works and what users value. It is disciplined empirical work: short cycles, visible evidence, explicit re-planning, and acceptance criteria per slice. It is what the platform build becomes once the clinicians stop refining one workflow and start deciding, from usage data, which one to improve next.

A hybrid life cycle is not a fifth brand. It is an intentional architecture that combines two or more of the families, and the craft is naming the unit being hybridized: which component, phase, workstream, team, contract, or risk class runs on which rhythm, and where the seams sit. Hybrid is a decision, not a default. The failure mode is already visible at Meridian: “we are agile” said about the platform, “we are waterfall” said about the construction, and nobody owns the seam where the certified building must receive a platform release the workflow team will not promise by date. The seam is the project’s true organizational chart.

The five families differ in three properties, and everything else, the documents, the meeting names, the ceremonies, is downstream of these three. First, how far ahead the definition is fixed: predictive fixes the outcome, adaptive fixes only the immediate slice. Second, how often the work produces evidence from real use: predictive produces it at gates, adaptive produces it every cycle. Third, how much re-planning is permitted without a change process: predictive treats re-planning as a formal event, adaptive treats it as the operating rhythm. Read a project’s actual behavior, not its labels, and these three properties are observable in a week. The field signal that a life-cycle debate is really something else: the argument is being conducted in brand names, agile versus waterfall, Scrum versus Prince, with no one able to say which workstream, which unit, and which seam is under discussion. Method debate without a unit is identity politics wearing a delivery costume.

Two uncertainties decide everything

The choice of life cycle is decided by two questions, and the map they form is the chapter’s primary instrument. The first question is requirements uncertainty: how well do we agree on what “good” looks like, and how stable is that agreement? A fixed building program has low requirements uncertainty: the clinic’s functions are knowable, and the community’s needs were settled in the charter. A new patient-facing workflow has high requirements uncertainty: clinicians agree it must be fast and safe, but “fast” acquires a different meaning in a live consult than in a workshop, and the answer changes as they use it.

The second question is solution uncertainty: how well do we know how to build it? The construction method for a single-storey clinic is well known: the sequence is standard, the suppliers exist, the local codes are published. The platform integration is less certain: the vendor’s record system has never been configured for Meridian’s referral and follow-up flows, and the interface with the legacy scheduling system is a known unknown. The question is about the method, not about the team’s skill: a brilliant team cannot retire the uncertainty that nobody has configured this integration before.

Plot the two questions against each other and four zones appear, and each zone has a family of workable patterns. The map is a rendering of a diagram Ralph Stacey published for strategy, in Strategic Management and Organisational Dynamics (first edition 1992, elaborated in Complexity and Creativity in Organizations, 1996). Stacey’s axes are agreement on requirements and certainty about the technology, and his quadrants name the management approach that fits. This rendering keeps his axes and redraws the zones for delivery design.

Figure 13.1: The two-question map. Horizontal axis: requirements
uncertainty, from low (we agree on what "good" means and it stays)
to high (the definition of good emerges from use). Vertical axis:
solution uncertainty, from low (we know how to build it) to high
(no one has built this exactly here before). The four corners are
not four methods; they are four situations, each with a family of
suitable patterns. Most real projects occupy several corners at
once, which is why the choice is per workstream, not per project.

        solution uncertainty
        high
          |   ZONE: SOLUTION RISK            ZONE: COMPLEXITY
          |   (know what, not how)           (know neither)
          |   patterns: iterative,           patterns: no fixed plan;
          |   prototype, spike, expert       probe, small batches,
          |   reviews, staged invest-        fast feedback, adaptive,
          |   ment, verification gates       pair risk with learning,
          |                                 stabilize before planning
          |
          |   ZONE: PREDICTABLE              ZONE: POLITICS
          |   (know what and how)            (know how, not what)
          |   patterns: predictive,          patterns: iterative with
          |   baseline, plan, critical       stakeholders, decision
          |   path, gates on evidence,       forums, options, staged
          |   change control, assurance      commitment, negotiation
          |                                 at the right cadence
          |
        low
          +------------------------------------------> requirements
          low                                         uncertainty high

The predictable corner, low on both axes, is the native home of predictive delivery: the outcome is knowable and the path is proven, so fix the outcome, baseline it, and build to it. The complexity corner, high on both, is where no plan can be true: the users do not yet know what they need and the method is unproven, so the only honest posture is small, safe, reversible steps that produce evidence and re-decide. Adaptive delivery lives here, and its discipline is exactly what makes it defensible: the feedback loop is the control. The politics corner, low solution uncertainty and high requirements uncertainty, is where the method is known but the meaning of good is contested; iterative delivery with decision forums and staged commitment fits, because each cycle negotiates the definition of good with evidence. The solution-risk corner, high solution uncertainty and low requirements uncertainty, is where the outcome is agreed but the path is unknown: prototypes, spikes, expert review, and verification gates retire the how before the commitment to a plan.

The map is Stacey territory, but it deserves one note against the Cynefin model from chapter 3, because readers will meet both. Cynefin sorts the situation, clear, complicated, complex, or chaotic, and which sensemaking playbook fits; the map sorts the delivery problem, how much of the uncertainty is about what versus how. They answer different questions and both are needed: Cynefin says how to think about the situation, the map says how to flow the work. A complex situation can occupy the predictable corner if the complexity has been resolved into a known method, and a simple situation can sit in the politics corner if the stakeholders disagree about what simple means.

The corner that deserves the most respect is complexity, because the honest pattern there is a refusal. No delivery method fixes it: you cannot schedule your way to an outcome whose definition and method are both unknown, and the attempt produces manufactured certainty, the big plan with the confident dates, which chapter 3 called the most expensive error. The complexity corner is where the project’s first job is to shrink itself: run probes, build prototypes, run discovery in the shape of chapter 6, and only adopt a delivery rhythm when the uncertainty has moved to a corner the rhythm can serve. Northstar, in the crisis case, spent its first days exactly there: nobody knew what the flooding had done to the roads or what the demand would be, and the response began with a minimal stabilization loop, assess, move, reassess, that only later hardened into routes and schedules. The mastery drill at the end of this chapter is built from this corner.

Reversibility and the price of change

The two-question map says where a life cycle is comfortable. The economics decide whether you may live there. The binding constraint is the price of change, and the classic evidence comes from software engineering, where the cost of fixing a problem depends on when you find it. Barry Boehm’s Software Engineering Economics (Prentice-Hall, 1981) charted how much the cost of rework grows through a system’s life cycle. Barry Boehm and Victor Basili’s 2001 summary, “Software Defect Reduction Top 10 List” (IEEE Computer), put the number on it that is still quoted: finding and fixing a problem after delivery is often on the order of one hundred times more expensive than during requirements and design. The word that carries the truth is “often”: the ratio is an empirical regularity of the environments studied, not a law of nature, and its steepness depends on how hard it is to change the thing once it is built.

That dependence is the point. The price of change is a property of the work, and the life cycle is chosen to match it. A clinic’s load-bearing wall costs the same to move whether the project calls itself agile or waterfall: the price is set by concrete, steel, the drawings, the permits, and the neighbors, not by the method. The platform’s workflow configuration costs little to change early and more later, but how much more is set by the architecture, the test automation, the data model, and the deployment pipeline, all of which the project controls. The deeper name for the property is reversibility: how much of the decision’s value can be recovered if the decision is undone. Reversible decisions can be made cheaply and made often; irreversible decisions demand evidence before they are made. The craft of delivery design is to push irreversibility as late as the work allows, and to put gates and evidence exactly where irreversibility happens.

The cone of uncertainty is the second economic fact, and it explains why the life cycle must also manage expectations, not just work. Boehm’s 1981 analysis charted how much estimates can vary as a project progresses, and Steve McConnell named the pattern the cone of uncertainty in Rapid Development (1996) and Software Project Survival Guide (1998). Early estimates of size and effort can be off by a factor of roughly four in either direction; the range narrows to about half that spread once the requirements are understood, and to a margin near 10 percent by the time the code or the drawings exist. The cone is not a planning failure; it is the honest shape of knowledge. A predictive project that promises a precise date at month one has promised precision the cone does not contain, and a project that refuses to narrow the cone as evidence arrives is refusing to learn. The life cycle is the machine that narrows the cone: each cycle, each prototype, each gate retires a slice of uncertainty, and the plan re-baselines to the new shape. Put the expensive discovery early, where the cone is wide, and reserve commitments for where it is narrow.

There is a subtlety that separates good delivery design from a slogan. The steep cost-of-change curve was used for decades to justify predictive delivery: because change is expensive late, freeze the requirements early. The agile response, born in software, was to flatten the curve: build the architecture, tests, and pipeline so that change stays cheap, and then let the requirements move. Both claims are true inside their conditions, and the project leader’s job is to know which condition holds for each workstream. If the cost of change genuinely stays low, adapt; if it rises steeply, predict. The failure is to import the software answer into the construction site, where the curve is steep by physics, or to import the construction answer into a discovery problem, where the requirements are the deliverable. Method Lens, one sentence: predictive delivery is the answer when the price of change is high and the requirements are knowable; adaptive delivery when the requirements must be discovered and change is cheap enough to fund the discovery; hybrid when both conditions hold in the same project, which is almost always.

Feedback, batch size, and the cadence that fits

The third factor is time: how fast can the work learn? Every life cycle is a feedback loop, and the loops differ in length. The predictive gate is a slow, expensive feedback loop: the evidence arrives at milestones, and between them the plan is assumed. The adaptive cycle is a fast, cheap loop: evidence every cycle, from real use, and the plan re-decides. The right loop length is set by the rate at which the environment changes: if the market, the regulator, the users, or the technology move faster than the project’s feedback loop, the project is permanently steering with old information, and no amount of planning fixes that, only a shorter loop.

Batch size is the lever on loop length, and the logic is older than project management: Ford W. Harris’s 1913 economic order quantity balanced the cost of ordering against the cost of holding stock, and the same trade-off governs delivery. Small batches mean more frequent evidence, less at risk per batch, faster learning, and earlier delivery of value; large batches mean fewer overhead transactions, but each batch carries more risk and returns its verdict later. The modern formulation is Donald Reinertsen’s, from Principles of Product Development Flow (Celeritas, 2009): batch size, queue length, and cadence are design variables, not accidents, and the cheapest way to shorten a feedback loop is to shrink the batch. Meridian’s release-and-gate map is a batch-size decision: the network rolls out in clinic waves, each a whole working unit, and the platform release inside each wave is sliced by workflow. The batch sizes are chosen from the value each batch must carry, not from the calendar.

Cadence is the name for the rhythm, and it deserves to be a first-class decision, because it is the communication architecture of chapter 12 made temporal. The PMBOK Guide, Seventh Edition (2021) made delivery cadence a separate choice from the development approach: single delivery, one release at the end; multiple deliveries, scheduled releases; continuous delivery, release whenever ready; and always-on delivery, where the “release” stops being an event. Cadence is chosen from the same three facts as the life cycle: what is uncertain, what it costs to reverse, and how fast the environment changes. A compliance dashboard for a bank might be single delivery with a gate, because the regulator wants evidence of a finished system. A marketplace recommendation engine might be continuous, because the value is in the frequency of learning. The two belong to the same project, and nobody is confused if different release gates own different cadences — the whole of hybrid delivery in one sentence.

The decision point that matters most is the mismatch nobody audits. The project has chosen its cadence, and then the environment moves faster than the loop: the steering committee meets monthly and the market moves weekly, and the project discovers it is managing with stale evidence. The field signal: decisions are made twice, once when the information arrives and again when the governance hears it, and the second decision is the one that counts. The repair is structural: match the decision cadence to the feedback speed of the most uncertain workstream, and let the predictable workstreams report, not decide. Governance cadence is part of the delivery design, not an afterthought, and it is the subject of the next section.

The product clock and the project clock

The next lens is perspective, and it is the one that trips the best planners: the difference between the project clock and the product clock. A project is a temporary organization with a bounded window, a defined end, and a handover. A product is a living system with an operating life, a user base, and a continuous loop of use, feedback, and improvement that runs after the project ends. The delivery life cycle is where the two clocks must be told, because they tick at different speeds and they answer to different owners.

The clinic is a project: built, certified, handed to operations, done. The patient-record platform is a product: it will be configured, adopted, patched, extended, and governed for a decade, and its users, the clinicians, are part of its loop forever. A project that manages the platform only as a project will deliver it, celebrate, and then discover that adoption is a product problem — exactly the failure chapter 11 predicted: the training numbers were excellent and the behavior was flat, because the clinicians’ daily use was not part of the delivery design. A project that manages the clinic only as a product, forever refining the design, will never finish, because the building has no feedback loop worth running at that cadence; its requirements are knowable and its value is in being done.

The product clock argues for the adaptive rhythm, the empirical loop, and the continuous improvement culture; the project clock argues for the boundary, the gate, the definition of done, and the handover. The life-cycle architecture is where the two are reconciled: the platform’s product loop runs inside the project’s gates, and the project ends, the platform does not. The question that makes the reconciliation operational is ownership: who owns the platform’s product loop after month thirty-six, and what evidence crosses the handover? At Meridian the answer is taking shape across the earlier chapters: Nora owns the adoption outcomes and the operational readiness, Marcus owns the product’s technical health, and the handover evidence is the integrated readiness checklist from chapter 10, the definition of done that spans clinical, technical, regulatory, and operational readiness. The delivery design must create that evidence on a cadence the product loop can continue. A release that the project accepts but the product cannot operate is not a release; it is a debt transfer.

The distinction also settles a common confusion about scope. Product scope, what the platform must do, is defined by requirements; project scope, the work to produce and deploy it, by the delivery plan. Adaptive delivery lives mainly in product space, discovering what the platform should do; predictive delivery lives mainly in project space, producing and deploying what is known. A hybrid is what it looks like when both happen at once, and the seam is the ownership of each requirement, exactly as chapter 10 drew it: any item that crosses the seam has one owner for its acceptance and one place in the register. The two clocks are not in competition; they are two instruments playing the same composition, and the life cycle is the score.

Governance must be able to hear the feedback

The fourth factor is governance, and it is the one that kills more delivery designs than all the others combined, because governance is where the project’s intentions meet the organization’s habits. A life cycle is chosen and tailored at the team level, and then it must be governed by a steering structure that was built, in most organizations, for a different rhythm. The compatibility test is brutal and simple: can the governance hear the feedback the delivery produces, at the speed the delivery produces it, and act on it? If not, one of the two must change.

Predictive delivery produces evidence at gates: the baseline variance, the inspection results, the certification findings. The governance that fits it is the stage gate: the steering committee meets at defined milestones, the evidence is presented against the baseline, and the decision is continue, redirect, or stop, with tolerances from the charter as the tripwires. The gate is a decision instrument, and it fails in exactly one shape: when it becomes a ceremony, a meeting that consumes the evidence and returns the same decision, continue, regardless of what the evidence said. The gate that never stops anything is not governance; it is an audience.

Adaptive delivery produces evidence every cycle: the increment, the measured behavior, the reprioritized backlog. The governance that fits it is the empirical review: the team demonstrates working evidence, the product owner re-decides what is worth building next, and the steering structure governs by boundary and tolerance rather than by milestone. A steering committee that asks an adaptive team for a frozen baseline and a percentage complete is asking for theater, and the team will learn to supply theater, precisely the managed metrics chapter 4 warned about. The reverse failure is symmetrical: an adaptive review imposed on predictive work, a sprint ritual over a construction schedule, produces the same theater in the other direction.

The compatibility rule: the governance cadence must not be slower than the feedback loop of the work it governs, and the evidence it demands must be the evidence the approach actually produces. Meridian’s steering committee meets monthly, which suits the construction gates and the certification milestones, and would drown the two-week workflow loop. The resolution is layered governance: the workflow team reviews with the clinicians every two weeks, the platform release gate meets at defined capability milestones, and the monthly steering committee sees the seams, the release evidence, and the tolerances, not the iteration minutiae. The layers are the communication architecture of chapter 12 made into a decision system: each layer hears the feedback appropriate to it, and the same item is never governed twice at different speeds. The governance map from chapter 8 is the document; this chapter adds the rhythm.

There is one more compatibility that deserves naming, because it is the most common cause of hybrid failure: the contract. The commercial agreements under which the work is bought, internal or external, must match the life cycle of the work they govern. A fixed-price contract with liquidated damages attached to a discovery workstream transfers all the uncertainty to the seller, who will price it, and the price will be the project’s hidden cost. A time-and-materials contract attached to work whose requirements are knowable removes the discipline that makes predictable work predictable. Chapter 20 builds the procurement craft; the principle is established here: the contract is a governance instrument, and it must be hybridized at the same seams as the delivery. This is what the vendor’s implementation lead meant by “which unit the price attaches to,” and it is why the meeting stopped being hostile.

Three clocks at Meridian

The theory lands where the project lives, and Meridian is the chapter’s whole argument in one case, because it is not one project. It is three workstreams with three clocks, joined at seams, and the vendor’s question forced the architecture to be stated out loud. The statement of work that Dana signs in the weeks that follow is the first artifact of the chapter, the life-cycle decision matrix, and it is worth showing in its working form.

The matrix is the vendor’s question answered in four rows, and the rows read as one design. Construction is predictive because its price of change is high and its uncertainties low: the drawings are frozen, the gate is the certificate. The workflow design is iterative because its requirement is the deliverable: the accepted workflow is a clinician’s observation, the three-second medication list under real workload, not a sign-off on a spec. The platform build is adaptive inside the release gate because its integration risk is real: the team discovers the legacy interface by building against it, and each release is a working increment with rollback, governed by evidence rather than a promised date. The rollout is incremental because value at Meridian comes in whole clinics: each wave is complete, certified, staffed, and adopted, and the wave gate is the integrated readiness checklist, so the rollout can slip a week without endangering the network but cannot pass a wave without the evidence.

The seams are where the design succeeds or fails, and the seam discipline is the discipline of chapters 10 and 11 continued: one owner per crossing item, one place in the register. The first seam is the clinic gate: the certified building must receive a platform release, and the release evidence, the integration test, the rollback drill, must exist before the wave gate opens. The second seam is the workflow release: the clinicians’ acceptance of a workflow is a product decision, but the training, the super-user program, and the adoption evidence are Nora’s, and the seam is the readiness checklist row that joins them. The third seam is the certification evidence: privacy certification must precede any clinic connection, the auditor’s evidence must be produced on the formal cadence, and the platform’s adaptive releases must never outrun it. Each seam has a named owner from the governance map of chapter 8, and each seam has a gate in the release-and-gate map, which is the matrix turned into time: the wave gate for clinic one, the capability releases leading to it, the certification gate before it, and the adoption corridor twelve weeks after.

The numbers the case teaches are the batch sizes, and they are worth saying plainly. Six clinics in three waves is a batch-size decision; Meridian chose waves because the grant’s access outcomes, the 10-day wait target and the screening uptake, only move when whole clinics are open and adopted. The two-week workflow cycle is a feedback-length decision: the clinicians’ live-consult corrections arrive on a cadence that can absorb them, and the steering committee never sees the two-week noise because its monthly rhythm is matched to the construction and certification clocks. Every number in the design is a judgment about the four factors, and the design is defensible because the judgments are written down with the evidence that would change them.

The tailoring dials

The chosen life cycle is never adopted whole. It is tailored, and tailoring is the deliberate adjustment of five dials, each of which answers a question about the work. The dials are events, artifacts, roles, controls, and cadences, and the discipline is chapter 4’s tailoring, the protection of the work’s substance, applied to the delivery system itself.

Events are the moments when the work stops and looks at itself: planning, review, demonstration, retrospective, gate, inspection. The tailoring question is whether an event produces a decision or learning the work would not otherwise get. The two-week workflow review at Meridian stays because it is where the clinicians’ corrections enter the work; the monthly steering meeting stays because it is where the seam evidence is witnessed. A planning event that produces a plan nobody uses is not tailored; it is omitted in slow motion. The common event error is keeping an event because the organization has always had it — the status round that consumes an hour and decides nothing, which chapter 27 dismantles in full.

Artifacts are the documents and records: the plan, the register, the backlog, the report, the evidence pack. The tailoring question is whether anyone acts on it. Meridian keeps the readiness checklist because the gate is decided from it, retired the work-package dictionary for the construction workstream because the contractor’s own controls were stronger, and keeps the assumption log from chapter 6 because the seams live there. The tell of an untailored artifact: it is produced, filed, and never read, and the project cannot name the decision it changes. The discipline is the chapter 4 floor: reduce artifacts until removing one would remove a decision or a control, and keep the ones that would.

Roles are the accountabilities: who decides, who approves, who witnesses, who owns the seam. The tailoring question is whether the person can actually carry the decision. The vendor’s implementation lead needs a named counterpart with the authority to accept or reject a release, and the workflow seam needs one owner, not the committee chapter 8 warned about, many seniors and no owner. The common role error is importing a role the framework defines but the work does not need, the ceremony role whose only output is its own existence — or, worse, leaving a real decision with no role at all, the seam nobody owns.

Controls are the safeguards: quality gates, inspection points, authorization thresholds, sign-offs, and their evidence. The tailoring question is whether a control protects something that matters at a cost the work can bear. The privacy certification gate is a control Meridian cannot tailor away: the regulator’s evidence is a nonnegotiable. The invoice approval workflow, two signatures for every supplier payment, is a control Meridian can simplify at the seam, because the risk it protects is small and the delay it imposes is real. The failure is control theater in both directions: keeping controls that no longer protect, and removing controls that do, usually by someone who cannot distinguish the two. Chapter 24 builds the assurance architecture; the principle is set here: tailor controls by what they protect, never by what they cost the calendar.

Cadences are the rhythms, and the tailoring question is whether a cadence matches the feedback speed of the work it schedules, the compatibility rule of this chapter. The two-week workflow cycle, the monthly steering, the per-wave release gate, the annual portfolio review, each is chosen for a clock. The cadence error is the inherited rhythm: the monthly everything, or the weekly status that outlives the project it was built for.

The last artifact of the chapter is the tailoring rationale, the instrument that makes all five dials honest: a short living document that records, for each dial, what was kept, what was changed, what was dropped, why, who approved the change, and what evidence would reverse it. It is not a compliance pack; it is a decision record in the spirit of chapter 4’s ethical decision record, written so that a future project leader can understand the architecture without reverse-engineering it, and so that the project can re-decide when the evidence changes. At Meridian it is three pages: the matrix, the release-and-gate map, and the seam ownership list, with one line per tailoring decision and the evidence trigger for each. When the vendor quotes the hybrid statement of work, the tailoring rationale tells the procurement team which unit the price attaches to and which evidence opens each gate. The document is the chapter’s whole argument made durable: the life cycle is a decision architecture, and the architecture is only as trustworthy as the written record of its decisions.

The approach is a hypothesis

The last discipline is the one the field forgets most often: the chosen life cycle is a hypothesis, and it has a review date. The four factors, uncertainty, price of change, feedback speed, governance fit, all change as the project produces evidence, and a delivery design that was right in month eight can be wrong in month twenty without anyone having made an error. The approach is re-decided, not defended.

The triggers are specific, and each names the evidence that should prompt a re-decision. Retired uncertainty: discovery completes, a prototype proves the method, an integration succeeds, and the workstream moves toward the predictable corner. The price of change: the architecture and test automation make change cheap, or the regulator adds a certification step and the gate structure must grow. The environment’s speed: a competitor ships, a market opens, a policy deadline moves, and the feedback loop must shorten or the governance accelerate. Capability: the team masters the platform, the vendor’s support proves out, and the rhythm can absorb more responsibility — or must not. And the calendar itself: the approach is re-decided at the seam of each major phase, because the work’s shape changes there.

The migration is a normal act of judgment, and it moves in both directions. Discovery work begins adaptive and can become predictive as the method is proven: the platform’s integration work starts as spikes and prototypes, and the evidence from each spike retires solution uncertainty until the team can baseline a build plan. The reverse migration happens too. A predictive workstream that discovers mid-flight that its requirements were wrong — the certification body changes the evidence rules — must shift the affected slice to an adaptive rhythm rather than force the old plan. The honest version of that shift is a re-baseline with a rationale, not a quiet change in the status report. The discipline that makes migration safe is the one this chapter has been building: the approach changes are made at seams, with owners, on the tailoring rationale, with evidence triggers named in advance. A project that re-decides its life cycle without re-deciding its governance, its contracts, and its evidence expectations has changed the label, not the architecture, and it will discover the mismatch at the first gate.

The cone of uncertainty closes the loop. The life cycle exists to retire uncertainty and narrow the cone, and when it works, the project earns the right to make firmer commitments: the wide range of month eight narrows to the inspected, accepted evidence at the gate, and the plan re-baselines to what is known. Re-baselining is not failure; it is the cone doing its job, and the refusal to re-baseline, the plan frozen in its month-eight confidence, is the manufactured certainty that chapter 3 named as the most expensive error in the craft. The approach is the hypothesis, the evidence is the test, and the re-decision is the learning. That is the Learning lens installed inside the Delivery lens, which is what the Mastery equation means when it multiplies rather than adds: delivery that does not learn is just speed.

Why delivery choices go wrong

The failure patterns deserve to be named as characters, because each one is produced by competent people in good faith, and each one kills the delivery design in a different way.

The identity trap. The organization or the team declares itself agile, or waterfall, as an identity, and then the work must fit the identity regardless of what the work is. The construction manager is told the network is “agile now,” and the fixed-price building contract acquires two-week planning cycles that change nothing about the concrete. The platform team is told “we do not do dates,” and the grant’s month-thirty-six deadline acquires an uncomfortable silence. The signal: the method is discussed as a belief, the word “we” precedes the framework, “we are an agile organization,” and the work’s actual uncertainties appear nowhere in the sentence. It is the chapter’s opening scene in reverse: the vendor asked the question as an identity, and the project was rescued by refusing it.

The compromise hybrid. The hybrid that is a political settlement rather than an architecture: every faction gets its favorite method, the construction runs waterfall, the platform runs agile, the training runs whatever it ran last year, and nobody owns the seams, because naming them would reopen the negotiation that produced the compromise. The signal: the project says “we do both,” and there is no release-and-gate map, no seam owner, and no tailoring rationale, because the document would reveal where the delivery fails. This is the most dangerous pattern in the chapter, because it wears the costume of sophistication: it looks like the intentional architecture the chapter teaches, and it is the absence of it. The difference is not the labels; it is the owned seams, and the compromise is discovered at the first gate, where the certified building meets a platform release nobody coordinated.

Label salad. The vocabulary is agile, sprints, standups, reviews, retrospectives, and the behavior is unchanged: the “sprint” is a two-week batch of the same push-to-date plan, the “standup” is a status round, the “review” is a demonstration with no re-decision, and the “retrospective” is a meeting that produces nothing anyone changes. The signal: the ceremonies have agile names and the three properties have not moved, the definition is not re-decided, and the evidence from use does not enter. Label salad is what happens when the identity trap is implemented: the names arrive without the properties, and the project gets the ceremony without the feedback loop.

The frozen approach. The life cycle is chosen at month eight and defended at month twenty-four as if it were a commitment rather than a hypothesis. The uncertainty was retired, the architecture hardened, the environment changed, and the approach did not. The signal: the tailoring rationale, if it exists, has no updated triggers, and the re-decision conversation, “should we still be running this way?”, is treated as an attack on the team rather than the normal work of the craft. The frozen approach is the delivery design’s version of the status theater: the plan looks stable because it never changes, and it is stable for the same reason a stopped clock is accurate twice a day. The repair is the review date on the approach itself, and the discipline of re-deciding at seams, not only when the dashboard turns red.

The four patterns share one root: the life cycle was treated as an inheritance, a label, or a compromise, rather than as a decision to be made, tailored, and re-made. The two-question map, the tailoring rationale, and the review date are the instruments that keep the decision alive, and a project that holds them is harder to fool, including by itself.

The machine drafts the map; the leader owns the seams

The assistant has a genuine role in delivery design, and its boundary is the book’s standing boundary. It can draft a first-pass life-cycle decision matrix from a provided description of the workstreams, propose candidate patterns for each row, flag the seams it noticed, generate the first version of the tailoring rationale skeleton, and summarize the case for and against a predictive or adaptive choice from the materials the team provides. The source data is the approved, non-confidential context; the draft is a draft until a named owner checks it; and the audit record says what was generated, from what, checked by whom, and decided by whom.

Three boundaries are worth naming, because delivery design is where the machine’s fluency is most dangerous. First, the two-question map is only as good as the uncertainty assessment, and the assessment is empirical: it comes from discovery evidence, prototype results, integration tests, and users’ behavior, not from a guess about whether a workstream is uncertain — a fluent paragraph assigning uncertainties is a hypothesis, not a finding. Second, seam ownership cannot be delegated: the machine can propose where the seams are, and the leader must verify them against the governance map, the contracts, and the people who will carry them. Third, the re-decision triggers must be written by the people who will act on them, because a trigger nobody believes is a trigger nobody will pull. The verification is the room: the leader tests the matrix against the four factors for each workstream, the rationale against the dials, and the triggers against the evidence the project can actually see. The machine accelerates the drafting; the judgment, the seams, and the dates of re-decision stay human.

Practice

One. A quick classification. For each workstream below, place it on the two-question map, low or high requirements uncertainty, low or high solution uncertainty, and name the life-cycle family that fits. (a) A network bridge over a river with the route fixed by law and the method well established. (b) A recommendation engine for a marketplace where user behavior is the unknown and the technology is new to the team. (c) A public-consultation process where the method is standard and the outcome is contested among stakeholders. (d) An emergency relief operation where neither the damage nor the demand is yet known. (e) A regulatory data migration with a hard legal deadline, known source systems, and data quality that cannot be assessed until the extract runs.

(a) is the predictable corner, low on both axes; the fit is predictive: baseline the design, gate the milestones, freeze scope through change control. (b) is the complexity corner, high on both; the fit is adaptive with small batches and fast feedback, but the honest first step is smaller: the behavior is discoverable only by shipping and watching, so begin with a probe, a thin live slice, before any plan is promised. (c) is the politics corner, high requirements uncertainty with low solution uncertainty: the method is known, the meaning of good is not, so the fit is iterative with decision forums and staged commitment, each cycle negotiating the definition of good with evidence. (d) is the complexity corner, high on both axes, and no delivery method fixes it: stabilize first, assess, move, reassess, and only harden into a rhythm as the situation clarifies, the Northstar lesson. (e) is a hybrid in one workstream: the deadline and the method are fixed, predictive, and the data quality is a discovery problem, so run the extract early as a spike, retire the solution uncertainty, then baseline the migration against the legal date; the spike is the adaptive slice inside the predictive plan. The common errors: classifying by urgency rather than by the two axes, and assuming the solution-uncertainty axis measures team skill rather than method knowledge.

Two. A field drill: build your matrix. Take one workstream from a project you know well, and build the working form of the life-cycle decision matrix: one row with the two uncertainties, the price of change, the life cycle, the cadence, and the evidence at the seam, exactly as this chapter shows it. Then write the tailoring rationale for that row: what events, artifacts, roles, controls, and cadences you would keep, change, or drop, and what evidence would reverse each choice.

The drill succeeds when the row is defensible in one sentence, “this is adaptive because the requirements are discovered in use and the change is cheap enough to fund the discovery,” and when the tailoring rationale names at least one event or artifact you would deliberately drop, because a row where nothing is dropped is a row that copied an inheritance. The most common failure is filling the matrix from the current labels rather than from the two axes, which reproduces the identity trap in miniature; the second failure is writing a tailoring rationale that reverses nothing, because a rationale without triggers is a justification. If the row says predictive, the drill should name the evidence that would move it to adaptive, and vice versa.

Three. A decision room: the vendor’s quote. The platform vendor’s implementation lead returns with two options for the statement of work. Option A: fixed price for the whole platform, delivered against the workflow milestones the team can name today, with change control for everything else. Option B: time and materials on the platform build, with a fixed price for the integration interface and the data migration, and a defined acceptance evidence pack per release. The certification auditor has confirmed the evidence requirements. The grant’s month-thirty-six deadline is fixed. Marcus argues that option B will let the workflow discoveries happen without renegotiation; the procurement office argues that option A is the only option with a number the board can approve; Nora observes that either way, the wave gates need the release evidence on the calendar. Decide which option to take, what the contract’s unit should be, and what the seam evidence must be before the first wave gate.

The defensible answer starts from the matrix: the platform build has high solution uncertainty, so a fixed price for the whole platform transfers the integration risk to the vendor, who will price it into the quote; the project pays the hidden cost as an inflated price or a contested change control. Option B matches the commercial unit to the delivery unit: the fixed price attaches to the work whose solution uncertainty is low, the integration interface and the migration, and time-and-materials applies to the build whose requirements are discovered in use, with the acceptance evidence pack providing the control the calendar cannot. The seam evidence is the nonnegotiable: the release evidence, the integration test, the rollback drill, and the readiness checklist row for the first wave gate, written into the contract as the definition of acceptance, so a release cannot be accepted by the vendor’s standard and then fail Nora’s adoption corridor. The unsafe choices: option A with a fixed price on the discovery work, which manufactures the certainty chapter 3 warned about and guarantees the change-control war, and any contract that defines acceptance without the seam evidence. Reasonable but risky: option A with a very large contingency and a reserved change-control budget, defensible only if the organization cannot govern time-and-materials.

Four. The mastery drill: four projects, four choices. For each project below, place it on the two-question map and select the delivery life cycle, defending the choice in one paragraph, and if the answer is hybrid, name the unit being hybridized and the seam. (a) A single bridge over a river, route fixed by law, method well established, five years, fixed budget. (b) A merchant payments and working-capital platform in several markets where customer needs are uncertain and competitors move quickly. (c) A clinical network opening six community clinics with a shared digital patient-record platform, a grant ending at month thirty-six, and a regulator’s certification evidence requirement. (d) A temporary relief logistics network after severe flooding, where roads are damaged, information is incomplete, and speed matters.

(a) is the predictable corner: predictive life cycle, baseline, gates, change control, fixed-price contracts, critical path. Requirements uncertainty is low because the route is fixed by law, solution uncertainty is low because the method is established, and the price of change is high, so the plan is the instrument. The temptation to add agile labels is identity; the one hybrid element worth keeping is a small adaptive slice for the genuinely uncertain conditions, community engagement and mitigation, where the BlueLine lessons from chapter 3 live, on a faster feedback loop than the construction, with a named seam between the two. (b) is the complexity corner, high on both axes: adaptive delivery with small batches and fast feedback, and the honest first step is discovery and probing before any delivery plan, the KijaniPay shape. The value is in the learning, the change cost is controllable through architecture and automation, and the environment’s speed outruns any plan’s loop, so the loop must be the plan. The dangerous choice is a fixed-date, fixed-scope commitment before discovery, which converts uncertainty into manufactured certainty. (c) is Meridian, and the defense is the matrix: hybrid by workstream, predictive construction, iterative workflow design, adaptive platform build inside gated releases, incremental rollout, seams owned at the clinic gate, the workflow release, and the certification evidence. The unit hybridized is the workstream and the release; the seam is the readiness checklist. It is genuinely three clocks, and a single life cycle would fail at least one of them. (d) is the complexity corner, high on both axes: no delivery method fixes it; the defense is stabilization first, assess, move, reassess, minimal governance, explicit provisionality, and a deliberate move toward a delivery rhythm as information arrives, the Northstar shape from chapters 3 and 4, with what is provisional and what is nonnegotiable named separately, so improvisation never becomes the excuse for abandoning the floors. The mastery is not the labels; it is the reasoning, the two axes, the price of change, the feedback speed, and the named seams.

Five. The transfer question. In your last project, what was the workstream where the label and the three properties disagreed, what did the chosen life cycle cost you at the first seam, and who owned the seam where the certified thing met the released thing? What would the tailoring rationale have changed?

The durable principle: the delivery life cycle is not an identity to inherit or a label to defend; it is a decision architecture built from two uncertainties, moderated by the price of change, the speed of feedback, and the governance that must hear it, tailored deliberately, and re-decided as evidence arrives. The most common next failure is subtler than the four patterns: the architecture is chosen well, the seams are owned, and then the project never re-decides, the tailoring rationale grows stale, the triggers pass unread, and the approach outlives the evidence that justified it. The re-decision must be scheduled like the gate it protects, at the seams, with the triggers written down. The next chapter takes the chosen life cycle and makes it concrete: decomposing the work without losing the whole, because the work breakdown and the backlog are the life cycle’s shape made visible, and the decomposition is where the seams this chapter drew must appear in the structure of the work itself.

Notes

• Meridian Community Health Network is a composite case created for this book; no real network, vendor, system, regulator, or people are depicted. The month-eight planning meeting, the vendor’s hybrid question, the three-workstream architecture, the wave rollout, and all named characters are author-created illustrative material consistent with the earlier Meridian chapters (chapters 1, 5, 8, 10, and 11). The grant window at month thirty-six, the certification-before-connection rule, the integrated readiness checklist, the adoption corridor, and the wait-time and screening targets follow the facts established in those chapters; the two-week workflow cycle, the release-and-gate map, and the life-cycle decision matrix are this chapter’s additions to the case.
• The distinction among predictive, iterative, incremental, and adaptive life cycles follows the general structure presented in the PMBOK Guide, Sixth Edition (Project Management Institute, 2017), and the regrouping into predictive, hybrid, and adaptive development approaches with delivery cadence as a separate consideration follows the PMBOK Guide, Seventh Edition (Project Management Institute, 2021); the book is independent of PMI, and readers should consult the official publishers for the current text, including the Eighth Edition released in November 2025, which the later chapters of this book reference for principles and performance domains.
• The two-question map is a rendering, in the author’s own words, of the diagram Ralph D. Stacey published in Strategic Management and Organisational Dynamics (London: Pitman, first edition 1992) and elaborated in Complexity and Creativity in Organizations (San Francisco: Berrett-Koehler, 1996). Stacey’s axes are agreement on requirements and certainty about technology; the quadrant names and the delivery-pattern labels are this book’s application, and the labels used by others vary.
• The cost-of-change evidence is from Barry W. Boehm, Software Engineering Economics (Englewood Cliffs, NJ: Prentice-Hall, 1981), and the often-quoted order-of-magnitude summary, that finding and fixing a problem after delivery is often about one hundred times more expensive than during requirements and design, is from Barry W. Boehm and Victor R. Basili, “Software Defect Reduction Top 10 List,” Computer 34, no. 1 (2001): 135-137, which reported the regularity from studies of software projects. The claim that the steepness of the curve depends on the environment, architecture, automation, and testability, and that the ratio is an empirical regularity rather than a law, is the author’s interpretation, stated as judgment.
• The cone of uncertainty, the observation that early estimates can vary by a factor of roughly four in either direction and narrow as evidence accumulates, follows the analysis charted in Boehm, Software Engineering Economics (1981), and the widely used name and presentation in Steve McConnell, Rapid Development (Redmond, WA: Microsoft Press, 1996) and Software Project Survival Guide (Redmond, WA: Microsoft Press, 1998). The exact ratios vary among sources and environments; the chapter uses the shape, not a promise of precision.
• The economics of batch size and cadence follow the argument developed in Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Redondo Beach, CA: Celeritas Publishing, 2009), and the inventory trade-off between ordering and holding costs traces to Ford W. Harris, “How Many Parts to Make at Once,” Factory, The Magazine of Management 10, no. 2 (1913): 135-136, 152. The chapter’s application to release and wave sizing is the author’s.
• The delivery-cadence vocabulary, single, multiple, continuous, and always-on delivery, is presented in the PMBOK Guide, Seventh Edition (Project Management Institute, 2021); this chapter uses the categories in its own words.
• The manifesto of 2001, in which seventeen software developers published the Agile Manifesto as a response to heavyweight, documentation-driven software processes, is a public historical document; the chapter does not reproduce its text and does not treat its values as a method.
• ISO 21502:2020, “Project management: Guidance on project management,” the general ISO guidance, addresses project life cycles and the tailoring of practices at a general level without prescribing a single method; this chapter’s life-cycle decision matrix, tailoring rationale, and release-and-gate map are the author’s method-neutral working instruments, not a reproduction of the standard. Readers should consult the official publisher for the current edition. This book is independent of ISO, PMI, and all named framework owners.
• The agile practices named generically in this chapter, two-week cycles, reviews, retrospectives, spikes, and rollback drills, are described in the book’s own words and are not presented as a proprietary method; the Scrum Guide (2020 edition, by Ken Schwaber and Jeff Sutherland) and other framework documents are cited in later chapters where specific framework mechanics matter, and this book does not reproduce their text.