Chapter 36: Integrate Projects with Products, Operations, and Services

The clinics are open, and the phones are ringing

It is the third Tuesday of January at Meridian, and the December gate is behind them. Wave three opened on time: clinics four, five, and six went live under the conditions the steering committee set, the construction passed its hold points, the migration reconciled to zero unexplained gaps, the certification landed, the training cohorts completed, and the grant officer’s calendar ticked the three clinics onto the list of live sites under the access targets. The program delivered. Nobody in the operations review room is disputing that, and that is precisely why the three findings on the table are so uncomfortable. They have nothing to do with construction, or migration, or certification. They have to do with what happens after.

Nora Kariuki, who owns the operational result, has asked for the meeting because the phones are ringing, and the ringing is the first finding. The poster on every clinic wall says the same thing: “For platform questions, call the support line.” The support line is the network’s reception desk number. Between eight and five the receptionist takes a message, and after five the call rolls to voicemail, and the voicemail says someone will call back, and nobody is assigned to call back. The vendor’s support mailbox tells the fuller story: forty-three open tickets, twelve older than three days, three older than a week, one about a medication list that a pharmacist flagged as mismatched across the migration. The vendor’s contract pays for defect fixes under warranty, and the warranty clock runs from acceptance, and it pays for fixes, not for the answering of questions, not for the training of new staff, not for the referral field the district’s new policy made mandatory on the first of January. The two analysts who know the platform well enough to answer most of those tickets are still paid by the project’s time-and-materials line. The project’s last invoice is in March, and nobody has asked what happens in April.

The second finding is the data. The migration closed at zero unexplained gaps at go-live, which was the definition of done chapter 10 wrote and the wave gate enforced. But the reconciliation was a project instrument: run by the migration team, paid for by the project, and retired at the gate. The ongoing check, the one that samples the records as they are created and updated in live clinics, was never funded, because it was never a row in anyone’s plan. A clinical informatics fellow ran the first monthly sample as a favor, and the sample found 4.2 percent of records carrying issues: duplicates from the admission desk, referral fields missing under the policy that took effect on the first, medication lists that did not agree with the pharmacy’s copy. The grant officer, who counts wait times and screening uptake and never percent complete, has asked for the first quarter’s access measures. The measures are in the platform, and the numbers are probably right, and nobody can show the evidence that they are right, because the validation is the favor that someone did once.

The third finding is the money, and it is the one the finance director has been holding for the meeting. Who pays for the platform next year? The project budget closes on the thirty-first of March. The IT department’s budget, built in September, has no line for the platform, because in September the platform was still the project’s. The vendor’s quote for a support contract sits on the table: 240,000 units a year, tier two and tier three, with the definition of tier one left to the buyer. Marcus Chen has estimated what the platform actually needs to run: infrastructure, licensing, monitoring, on-call, the maintenance releases, the informatics review, about 51,000 units a month, 612,000 a year. And the grant, which the network is so careful to protect, values a live clinic meeting its access targets at 250,000 units a clinic-month. Six clinics, 1.5 million units a month of value, the arithmetic that made the December gate worth protecting. The grant’s money was always conditioned on the access outcomes the grant officer counts, wait times and screening uptake, not on platform operations. The outcomes the first quarter’s reporting will be audited against live in a platform whose data nobody validates. Nobody in the room can name the budget line that the 612,000 comes out of.

Nora closes the meeting the way she opened it, with the sentence that is the whole chapter in nine words. “The clinics are open,” she says. “The service has no owner.”

Dana Okafor, who has carried this program for two years, says the other half of it. “The project is on time,” she says. “The service is not funded.”

Nobody in the room has failed. That is what makes the scene the chapter’s opening instead of its cautionary tale. The December gate asked the question it was designed to ask, can the clinics open, and the answer was yes. The support line, the data-quality gap, and the unfunded run cost were not failures of delivery; they were questions nobody asked, because the project’s definition of done ended at the gate, and the service’s definition of done had no owner. The construction stream had a contract with hold points. The platform stream had a release gate with acceptance evidence. The training stream had cohorts and competency checks. The service that would carry all of them into the years had a voicemail message.

This is the chapter where the seam discipline of chapter 33 meets its hardest test, because the seam is the biggest one in the book. Chapter 33 coordinated the streams while they were inside the project. Chapter 34 coordinated the teams. Chapter 35 coordinated the distances. This chapter coordinates the boundary that every one of those streams crosses at the end: the boundary between the project and the operations that must sustain the result, between the delivered system and the service that carries it, between the product as the project built it and the product as it will be run, maintained, changed, and eventually retired. The thesis, in one sentence: the project’s output is a capability, and the capability only becomes value when an operation sustains it, so mastery at the end of the project is not the delivery of a system, it is the integration of the project with the product, the service, and the operations that must carry it, which means naming the four life cycles, owning the operation from the beginning, designing the service, engineering the path from change to live operation, agreeing the change seam, choosing the debts, funding the run, and designing the end.

The decision this chapter improves is the one the January meeting just failed: not whether the delivery worked, but whether the thing will keep working. It is the decision about who owns the operation, who funds the run, who answers the phone, who watches the data, and who plans the end. The field signal is the one the meeting found: the project that reports green, the ceremony that goes well, and the service that has no owner, the voicemail that nobody is assigned to check. The rest of the chapter is the discipline that makes the voicemail visible, and the discipline that replaces it.

Four life cycles, one result

Chapter 1 opened this book with the distinction the program just relived. A project is a temporary organization, designed to end. Operations is the ongoing, repeatable activity that keeps an organization running, treating patients, processing payments, moving commuters, the steady state designed not to end. Products are ongoing value propositions with life cycles of their own, improved by many projects over many years and outliving every one of them. The chapter also made the sharper claim, the one the January meeting proved: the chain from output to benefit can break anywhere, and the handoffs, the points where accountability changes hands, are where projects most often die quietly, because the project’s formal mandate ends at the boundary where value is just beginning.

The integration discipline of this chapter starts by making those clocks explicit, because each clock asks a different question, runs on a different cadence, and answers to a different owner.

The project life cycle asks one question: is the work delivered? It runs from authorization to acceptance, it has a plan, a budget, a team, and a designed end, and its clock stops at the gate. The product life cycle asks another: is the thing improving? The platform is not finished in December; it is a living value proposition with releases, versions, enhancements, and eventually retirement, and its clock runs as long as the thing is used. The service life cycle asks the question the January meeting could not answer: is the promise being kept? The promise is the support line answered, the data quality monitored, the incident resolved, the availability held, and its clock runs as long as the promise is made. The operations life cycle asks the widest question: is the mission being served? The clinics treat patients, the network serves the community, and its clock never ends by design.

The error that produces a January like Meridian’s is the conflation: the project leader treats the project’s end as the thing’s end, as if the gate that closed the delivery also closed the service, the product, and the operation. The gate closes nothing but the project. The other three clocks were running before the project authorized, and they keep running after it closes, and the project’s entire contribution to them is the capability it hands across. The project does not make the clinics operate; it makes the clinics operable. The operation makes them operate. The distinction is not semantic; it is the difference between the acceptance certificate and the first six months.

The consequence for the project leader is that the integration is not a closing activity. It is a design activity, and it belongs in the framing of the work, as much a part of the architecture as the life cycle choice of chapter 13 or the roadmap of chapter 16. The project that designs the integration late designs it badly, because the support model, the funding, the service owner, and the operating change path are decisions that constrain delivery: the platform’s architecture determines what support costs, the contract determines what the warranty covers, the budget cycle determines when the run cost can be funded, the training determines who can answer the phone. Each of those was decided, or not decided, months before the January meeting, and the January meeting is where the non-decisions surfaced.

The geometry matters as much as the timing, and the geometry is the primary picture of this chapter. The boundary between the project and the operation is drawn as a line on every project plan: the gate, the handover date, the acceptance signature. The line is a fiction, and the fiction is the root of the January problem. The project’s work does not stop at the line, because the first months of operation are exactly when the project’s knowledge is most needed, the configuration questions, the edge cases, the workarounds, the people who know the thing. And the operation’s work does not start at the line, because the operators must be present before, in the acceptance criteria, in the readiness review, in the rehearsal, in the training. The boundary is not a line; it is an overlap, a transition zone in which the project and the operation run together deliberately, ownership moving across while the work continues.

Figure 36.1: The project-to-operation boundary redesigned as an
overlapping transition. The project band runs from authorization
to final acceptance; the operations band runs before go-live and
forever after. Between them lies the transition zone, where the
two bands overlap: the operators join the acceptance criteria and
the readiness review before the gate, the project team carries the
runbooks and the hypercare after it, and ownership moves across
the overlap on evidence, not on a date. A gate that fires with no
operator in the zone is the January problem in one drawing.

  AUTHORIZATION                     GO-LIVE                 FINAL ACCEPTANCE
      |                                |                         |
      |  PROJECT BAND  |-------------->|<------------------------|
      |                |   delivery,    |   hypercare, defect     |
      |                |   acceptance   |   response, knowledge   |
      |                |   evidence     |   transfer              |
      |   TRANSITION   |========OVERLAP ZONE========|
      |                |   operators join: acceptance criteria,   |
      |                |   readiness review, rehearsal, training  |
      |  OPERATIONS    |<-----------------------------------------|---------->
      |  BAND          |   operations run, monitored, changed,     |
      |                |   improved, and eventually retired        |
  THE FOUR CLOCKS:  project: does the work deliver?   (ends)
                    product:  is the thing improving?  (runs)
                    service:  is the promise kept?     (runs)
                    operations: is the mission served? (runs)

The overlap is where the instruments of this chapter live: the operational acceptance criteria, the operational readiness model, the service transition plan, the run-cost forecast, the change interface, and the sunset paragraph. Each one is a row in the zone, owned, evidenced, and dated, so that the handover is not a ceremony but a transfer that completes on evidence. The field signal that the overlap is missing is the project that cannot end: the closeout that stalls, the project team still answering the platform’s mail six months after the gate, the acceptance that was signed by the project and countersigned by nobody, or the January meeting, where the clinics are open and the service has no owner. The opposite failure, the line drawn too hard, is the project that ends on the date regardless of the operation’s readiness, the gate that fires with no operator in the zone, which is the failure chapter 43 will meet in full. Both failures share the same root: the boundary was treated as a line when it is an overlap, and the overlap was never designed.

Own the operation before you build it

The second discipline of the integration is the one the charter established and the operating model must make real: operational ownership from the beginning. Chapter 8 filled the empty seat at Meridian when the kickoff became conditional and Nora Kariuki was named operational ownership, accountable for the adoption measures with the grant targets written beside her name, from signing, not from handover. That decision was the precondition for everything this chapter teaches, and it is worth being precise about why. Ownership from signing changes the questions asked during delivery, because the person who will answer for the operation is in the room when the architecture, the contract, the training, and the budget are being decided. Ownership from handover changes nothing, because the handover decision is the one decision the project makes alone.

But the seat alone is not the discipline. The January meeting had Nora in the room, and the service still had no owner, because the seat existed and the instruments of the seat did not. The discipline has three instruments, and the first is the operational acceptance criteria, which is the service’s definition of done. Chapter 10 taught the definition of done that spans the seams, the wave-level statement that the clinic gate requires the platform release accepted on integration evidence, the migration reconciled, the competency check passed, the certification complete. The operational acceptance criteria extend that same discipline across the largest seam of all. The service is not done when the system is delivered; it is done when the service can be operated and is funded to be operated. The rows are specific and owned: the service owner named; the support model decided and funded; the monitoring running with a named owner and a report cadence; the runbook written and rehearsed; the capacity plan sized to the demand forecast; the access lists current and reviewed; the security operations in place, the audit trail continued; the data-quality thresholds defined and sampled; the change path agreed between the project’s control and operations’ change management; the run cost in a budget line with an owner; and the end designed, the sunset paragraph written. Every row has an owner and an evidence date, and every row belongs to the gate, which means the gate does not fire without them.

The second instrument is the operational readiness model, which is the readiness dashboard of chapter 29 asked a second question. Chapter 29 built the readiness dashboard with its five windows and five owners and one gate, the provisional and the nonnegotiable, the conditional release with the control, the owner, the date, and the consequence, and it asked the delivery question: are we ready to open? The operational readiness model asks the other question with the same grammar: are we ready to run? The windows are the same in kind, people, process, technology, data, and support and governance, and the contents are different in every row. People: not only trained, but staffed, the support roster named, the on-call assigned, the turnover covered. Process: not only the clinical workflows, but the operating procedures, the incident response, the escalation, the maintenance. Technology: not only the system working, but the monitoring working, the backups working, the rollback proven, the environment licensed for operations. Data: not only migrated, but continuously valid, the sample, the threshold, the owner, the report. Support and governance: not only the project’s governance, but the service ownership, the change path, the funding line, the review cadence.

The difference in the evidence is the difference in the question. The delivery readiness review gathers evidence from the project: the test results, the inspection reports, the migration reconciliation, the training completions. The operational readiness review gathers evidence from the operator: the support roster, the budget line, the monitoring report, the rehearsal record, the acceptance criteria signed by the person who will run the thing, not the person who built it. The rule is the rule chapter 33 stated for the streams, applied to the boundary: no stream signs for another stream’s row, and no project signs for the operator’s row. The operator’s readiness is evidenced by the operator.

The third instrument is the minimum viable practice, and it is the lightest thing in the chapter: one page, written by the operations owner, not by the project, answering one question, what must be true for this to run without us. The page has a row for each of the readiness windows, and each row has an owner, an evidence, and a date, and the question is asked at every gate from the first one forward. It is the question the January meeting failed to ask, and the one Nora now asks every time a stream reports green: who answers the phone, and who pays? If the stream cannot name both, the stream is not done, regardless of what its tests say.

The failure pattern of the discipline is the readiness checklist as a delivery artifact: the checklist that asks can we open and never asks can it run, the rows that are signed by the project’s own team, the acceptance that was verified and never operated. The tell is the same tell the January meeting produced: every checkbox true, every gate green, and a service with no owner. The repair is not more rows; it is the change in who signs and what the evidence is, the operator’s row evidenced by the operator, the phone number answered by a named person, the budget line with a name beside it, the runbook rehearsed in the operator’s environment by the operator’s hands.

The service that carries the system

The third discipline is the design of the service itself, and it begins with a definition that the word support has been hiding all along. A service is a repeated promise with a measurable rhythm. The promise is not the help desk; the help desk is one instrument of the promise. The promise is that the platform will be available when a clinician needs the record, that a question will be answered, that a data-quality issue will be found and fixed, that a medication list will not silently disagree with the pharmacy, that an incident will be resolved and the cause prevented from recurring. Every promise has a rhythm, a cadence at which it is kept, measured, and renewed, and the service is the design of that rhythm.

The minimum viable service model has six rows, and each row is a decision, not a form.

The first row is the service owner, and it is the row the January meeting was missing. The service owner is the person accountable for the operation of the thing, distinct from the person who led the project that built it. The project leader is accountable for the delivery; the service owner is accountable for the run, and the two seats must not be the same person, because the delivery is designed to end and the run is designed to continue, and the same person holding both seats will optimize for the one that ends, which is the one with the deadline. At Meridian the seat is Tunde Bakare, the network’s IT operations manager, a character who has been in the story since the conditional kickoff reviewed the operations floor, and the naming of the seat at the January review is the naming that makes every other row possible, because every other row needs an owner’s name.

The second row is the support model, and the decision inside it is build, buy, or borrow, the chapter 20 sourcing question asked about the operation instead of the build. Build means the organization hires and trains its own support capacity. Buy means the vendor or a third party carries the tiers under contract. Borrow means the project team keeps answering the mail, on project money, past the project, which is the decision the January meeting discovered it had already made by default. The minimum viable support model is one page: the entry point, one number and one mailbox that a named person checks; the tiers, first-line for the common questions, second-line for the analysts who know the platform, third-line for the engineers who can change it; the escalation, what happens when a tier cannot resolve, with a named path and a time; and the hours, the window in which the promise is made, stated honestly. At Meridian the decision the room makes is build tier one, a service desk with two staff funded from the run budget, and buy tier two and three, the vendor’s 240,000-unit contract, because the vendor’s engineers are the only people who can change the platform’s code, and borrowing the project’s analysts past March was the accident the decision prevents.

The third row is the service-level frame, and it is the promise stated in the operator’s language with the measure defined. The vendor’s service-level agreement is a contract; the service-level frame is the user’s experience, and the two must not be confused. The frame names what the users can expect: the platform available during clinic hours with a defined threshold, the first response to a question within a defined time, the critical incident resolved within a defined time, the data-quality sample reviewed on a defined cadence, and each row has its measure, its owner, its report, and its review. The discipline of the frame is the discipline of chapter 2 applied to the operation: a promise without a measure is a hope, and a measure without an owner is a report nobody reads.

The fourth row is the maintenance window: the answer to the question when does the change happen. The platform will be patched, upgraded, configured, and changed, and the change happens on a calendar that respects the clinic’s hours, the pharmacy’s load, the admission desk’s peak, and the grant officer’s reporting dates. The maintenance window is the schedule of the service’s change, and it belongs to the service owner, not to the vendor, because the vendor’s engineers propose the window and the service owner disposes of it, on evidence about when the clinics can tolerate it.

The fifth row is the capacity plan: the answer to the question what happens when the demand grows. The clinics’ patient volumes grow, the platform’s records grow, the referral field accumulates, the transaction volume climbs, and the capacity plan sizes the infrastructure, the licenses, the support hours, and the informatics review to the forecast, with a trigger that says when the forecast changes, the capacity decision revisits. The capacity plan is the chapter 19 discipline, capacity, capability, availability, and accountability, asked about the operation instead of the delivery.

The sixth row is the two watches: data quality and security operations. The data-quality monitoring is the ongoing version of the migration reconciliation: the sample, the threshold, the owner, the report, the review, the correction path, because the records are created in live clinics by busy people under pressure, and the data degrades exactly as fast as the monitoring retires. The security operations are the floors of chapter 24 carried into the run: the access lists reviewed, the accounts closed when people leave, the incidents logged, the audit trail continued, the records of processing current, because the privacy certification was a gate for the project and a condition for the operation, and the condition does not expire at acceptance.

The minimum viable form of the whole model is one page, the six rows with their owners and their cadences. The failure pattern of the discipline is the support model as an afterthought: the help desk that is the project inbox, the service-level frame that names the vendor and not the user, the monitoring that was a go-live artifact, the capacity plan that was the deployment plan, the maintenance window that was the vendor’s convenience, the security review that was the certification audit. The field signal is the one the January meeting produced in miniature: the poster that says call the support line, and the support line that has no name behind it.

The pipeline that delivers into the live world

The fourth discipline is the engineering of the path from change to live operation, and it borrows its ideas from the delivery practice that grew up in software and transfers them wherever work enters the live world, which is everywhere. The idea in one sentence: how the change gets into production is itself engineered work, as much a part of the system as the system it changes, and the operation is only as trustworthy as the path that carries change into it.

The continuous-delivery idea, described in the vocabulary the practice uses and in this book’s own words, is that software can be released to production safely at any time, not on a schedule of anxious release days, because the path from change to production is automated and rehearsed: the build, the test, the deployment, the verification, all of it a pipeline that runs the same way every time, so that the release is an ordinary event rather than a risky one. The research that made the idea measurable is the one the practitioners call the delivery-performance research: the study of software delivery performance published by Nicole Forsgren, Jez Humble, and Gene Kim, which found that teams with high delivery performance deploy smaller changes more frequently, restore service faster when something breaks, and fail a smaller share of their changes, and that those measures correlate with organizational performance. The four measures are worth naming because they transfer: deployment frequency, how often change reaches the live world; lead time for change, how long a change takes from acceptance to live; change failure rate, how often a change breaks what it touches; and time to restore service, how long the recovery takes when it does.

Every one of the four transfers to a project like Meridian’s, because the clinic’s cutover is a deployment, the migration is a deployment, the go-live is a deployment, and the referral field’s release is a deployment. The discipline has five instruments. The first is the pipeline itself: the engineered, repeatable path from accepted change to live operation, with the steps named, the owners named, and the verification named, so that the question how does a change get in has one answer instead of a story about who happened to be available. The second is the rehearsed deployment: the cutover that was rehearsed in the operator’s environment by the operator’s hands is the cutover that works, which is the rehearsal discipline of chapter 23 and the mobilization rehearsal of chapter 29 carried to the boundary, the runbook exercised before the incident, not after.

The third instrument is the rollback: the ability to return to the known state, tested, not assumed. The reversibility question, can we get back to where we were, is the question that separates the change that is safe to make from the change that is a gamble, and the answer is not a feature, it is a rehearsal, because the rollback that has never been run is the rollback that will not run. The fourth is monitoring: the service must be measurable in operation, not only in acceptance, which means the measures that prove the service is keeping its promise are collected continuously and reviewed on a cadence, the availability, the response times, the data-quality sample, the incident count, the change failure rate, the measures that chapter 37 will build into a system. The fifth is the runbook: the written response to the known failure modes, the incident playbook, the escalation, the call tree, the recovery procedure, held where the operator can reach it and exercised before it is needed.

The point of the whole discipline is the operational acceptance, and the operational acceptance is the chapter’s definition of the seam’s evidence: the acceptance evidence proves the system works; the operational acceptance proves the service can be operated. The operational acceptance is a rehearsal with the operator in the operator’s environment: the deployment runs, the monitoring reports, the rollback works, the runbook guides, the people execute under pressure, and the evidence of each is collected and filed with the acceptance certificate. The project that demonstrates the system works and hands it over without demonstrating that the operation works has demonstrated half of the truth, and the half it did not demonstrate is the half the January meeting discovered, the 4.2 percent, the voicemail, the unanswered ticket.

The failure pattern of the discipline is the release as heroics: the go-live that is a one-time performance, rehearsed once, watched by everyone, and then retired, with no pipeline, no monitoring, no rollback, no runbook, and no operational acceptance, so that the second change, the one nobody is watching, is the one that breaks the service. The field signal is the go-live review that is proud of its success and has no evidence for the next change, the question how do we change it now answered by a shrug, the monitor that was stood up for the acceptance and stood down after.

Two change systems, one seam

The fifth discipline is the agreement between the two change systems, and it is the discipline the referral pathway policy of chapter 33 was preparing. Chapter 33 routed the district’s new referral policy through five streams: the data field, the workflow standard, the training, the acceptance, and the platform release, and the routing was the project’s change control at work, the formal path for the construction baseline, the empirical path for the platform backlog, the routing question, which streams does this change touch. That routing was the project’s change system, and it was the last time that particular change will travel through a project change system, because the policy is mandatory from the first of January, and by the January review the policy is an operating reality, and the change that carries its future amendments is operations’ change management, not the project’s.

The seam between the two systems is the project’s last release becoming operations’ first change. The project approves the release with its acceptance evidence; the operation accepts the change into its own pipeline, with its own evidence, its own authority, its own rollback, and its own calendar. The two systems must agree at the seam, and the agreement is the change interface: one document that answers the questions the operating change will ask, who may change what, with what evidence, under what authority, with what rollback, on what calendar, after the project ends. The change interface names the entry point, the change authority in operations, the evidence standard, the maintenance window, and the rollback rule, and it is signed by the project leader and the service owner at the transition, and it lives in the operation, not in the project archive.

The operating change pipeline is the life of the product after the project: the patches, the upgrades, the configuration changes, the new fields, the policy amendments, each one a change with an owner, an evidence, an authority, a window, and a rollback, each one small enough to fail cheaply and fast enough to be restored, which is the delivery-performance research in operation form. The calendar that carries them is the change calendar: the vendor’s release windows, the clinic’s hours, the pharmacy’s load, the regulatory dates, the grant officer’s reporting schedule, the maintenance window of the service model, one calendar that the service owner owns.

And the data-quality finding of the January review is the seam’s first casualty. The referral fields missing from the records are the referral policy of chapter 33, routed through the project’s change system, released to the platform, and then stranded, because the change that landed in the platform needed a change in the workflow, the training, and the acceptance, and after the project, those changes are operations’ changes, and the operations change system did not exist yet. The field that the district made mandatory on the first was added to the software; the workflow that asks the receptionist to complete it, the training that teaches her, the validation that checks it, those were the seams of the same change, and the seams were the operating change system that nobody had built. The 4.2 percent is the routing question of chapter 33 asked six weeks too late.

The failure pattern of the discipline is the change vacuum: the project ends, the vendor keeps deploying to production on the project’s authority, or on no authority, and nobody in operations signs for the change, which is the configuration and release control of chapters 31 and 32 abandoned at the boundary. The field signal is the change that appears in production with no record in the operation’s log, the release note that names the project that no longer exists, the ticket that was closed by someone who is no longer there. The repair is the change interface signed before the last release, the operating change system running before the project ends, and the referral lesson, that the change that touches the operation is not done when it ships, it is done when the operation carries it.

The debts you choose

The sixth discipline is the naming of the debts, and it begins with the oldest metaphor in the book’s neighborhood. Technical debt is the name the practitioner Ward Cunningham gave to the obligation that accrues when a team chooses speed in the present over correctness in the future: the code that is written quickly to meet a market, a grant, a gate, works today and charges interest tomorrow, and the interest is paid in the rework, the fragility, and the slowed change that follow. The metaphor is older than most of the people reading this chapter, and it is still the sharpest tool the project world has for one reason: it converts an invisible accumulation into an obligation with a payment schedule, and it forces the question every accrual should force, who chose this, and what did it buy.

The chapter extends the metaphor to the two debts that delivery creates but technical debt does not name. Operational debt is the obligation that accrues in the operation: the procedures that exist in heads instead of runbooks, the monitoring that was stood down, the support model that is borrowed, the access lists nobody reviews, the tickets that age past their promise, the data-quality check that was a favor. Change debt is the obligation that accrues between the delivery and the people it must reach: the training that was deferred, the workflow improvements queued, the adoption gaps, the policy amendments waiting for the next cohort, the backlog of updates the organization cannot absorb because its capacity to change was consumed by the delivery itself. All three are the same phenomenon wearing different clothes: the present is being paid for out of the future, and the invoice is silent until it is not.

The discipline is not the avoidance of debt, because some debt is the honest price of speed, and a project that takes no debt is a project that refused the schedule, the market, or the gate. The discipline is the ledger. The debt ledger is the debt made visible and owned: each debt named, priced, given an owner, a payment plan, a review date, and a decision, the decision being pay, service, or default. Pay means the obligation is cleared now. Service means the interest is managed, the debt carried deliberately with a date to revisit. Default means the obligation is walked away from, and defaulting is a legitimate decision only when it is a decision, named on the record with its consequence, because the debt that is defaulted without being named is the debt that compounds. The ledger’s question is the one the January meeting failed to ask of its own findings: is this debt strategic, chosen deliberately for what it bought, or is it accidental, incurred without a decision?

Meridian’s January ledger writes itself in the meeting’s own evidence. The data-quality monitoring is operational debt, priced at about 6,000 units a month, the clinical informatics review that was a favor, owned by nobody, and its payment plan is the 72,000-unit line in the run-cost forecast, because the favor that protects the grant’s measures is the cheapest insurance in the network. The support model is operational debt, the borrowed analysts, priced at the risk that April arrives with no one to answer the phone. The workflow updates queued behind the training waves are change debt, the adoption corridor of chapter 11 still converging above the threshold, the referral fields still missing. The platform’s deferred configuration items, Marcus’s nine items that rode the release, are technical debt, small, priced, and owned. None of the four is a failure; all four are obligations, and the ledger is the difference between the program that knows what it owes and the program that discovers what it owes in the first incident after the ceremony.

The failure pattern of the discipline is the compounding ledger: the debt that is never named, never priced, never owned, and therefore never paid, the workaround that everyone knows and nobody owns, the monitoring that was a favor, the runbook that is a memory, the access list that grew for years, the support line that is a voicemail. The field signal is the question that no one can answer, who owns this, asked about anything the organization runs on, and the answer being a shrug. The repair is the ledger, one page, named, priced, owned, reviewed, because the debt that is on the ledger is a decision, and the debt that is not on the ledger is an accident that has already happened.

The money that starts when the project ends

The seventh discipline is the run-cost forecast, and the argument for it is the argument chapter 18 made with BlueLine’s numbers: the corridor’s capital envelope was 2,400 million units, and the corridor’s operating subsidy was 90 million units a year, and the second number belonged in the same conversation as the first, because the money is the money whether it is spent in year zero or year twenty. The run-cost forecast is the second number for every project, the annual cost of running what the project built, and it is the discipline the January meeting discovered was missing, the line that the IT budget did not have.

The minimum viable form is one page, and the page has the rows that the operation actually costs: the staff who run it, the licenses and infrastructure that carry it, the support that answers it, the maintenance that changes it, the capacity growth that scales it, the renewal that replaces it, and the decommissioning that ends it. Each row has a number, an owner, and an assumption, and the page is written before authorization, in the business case of chapter 7, reviewed at every gate, and owned by the person who will answer for the operation, not by the project that is trying to close.

The Meridian arithmetic, all of it reproducible from the text and stated as teaching numbers rather than measurements, is the arithmetic the January meeting had to do by hand. The platform’s annual run cost: infrastructure, hosting, and licensing, 180,000 units; the support desk contract, 240,000; the clinical informatics and data-quality monitoring, 0.6 of a full-time role, 72,000; the platform improvement and maintenance releases, 120,000. The total is 612,000 units a year, 51,000 a month. The value the run protects: the grant’s clinic-month arithmetic values a live clinic meeting its access targets at 250,000 units a clinic-month, six clinics, 1,500,000 units a month of value, the number the December gate existed to protect, and the access outcomes the grant was conditioned on, wait times and screening uptake, are the measures the grant officer audits from the platform’s records. The run cost is about 3.4 percent of that value, and the monitoring that protects the audited measures costs 6,000 a month, about 0.4 percent of it, which is the cheapest number in the network, and the favor it was funded as was the most expensive. The funding gap: the project budget closes on the thirty-first of March, the IT budget has no line, and the first quarter of the year runs on the vendor’s warranty, the project’s leftover hours, and goodwill, about three months at 51,000, 153,000 units of unfunded operating cost, plus the data-quality review, a number the finance director can name only because the meeting forced it.

And the total-cost view, the chapter 18 lens applied to the platform: over a ten-year life, the run cost of 612,000 a year comes to about 6.1 million units, against a build of about 11.2 million, with renewal and decommissioning adding roughly 400,000 more, so the run cost is more than half the build, and the cheapest delivery decision is often the most expensive operating decision, the architecture that saved 200,000 in the build costing 400,000 a decade in support, the contract that ended at acceptance costing the quarter that no one funded. The run-cost forecast exists to make that trade visible at the moment it can be decided, which is the moment of the architecture, not the moment of the budget cycle.

The failure pattern of the discipline is the run cost discovered in the budget cycle: the question who pays for this asked for the first time after go-live, by the finance director, in the meeting the project did not call, with the project’s budget closing and the operation’s budget never opened. The field signal is the project that is praised for coming in under budget and leaves an unfunded operating liability in its wake, the under-budget project that is the most expensive gift the organization received. The repair is the forecast in the business case, the line in the operating budget, the owner beside the line, and the question at every gate, the question Nora now asks, who answers the phone, and who pays, because the run cost that is forecast before authorization is a decision, and the run cost that is discovered after go-live is an accident with a voicemail.

The end designed at the beginning

The eighth discipline is the end, and it is the one the project world most often refuses to design, because the end feels like a failure of the thing the project built. The platform will end. The clinics will outlive it, or the platform will outlive some of them, and the records will outlive both, and the end is not an event to fear, it is a condition to design, like every other condition of the service. Sunset, decommissioning, and end-of-life are the names the industry gives to the same three questions: when does this thing stop, what does stopping cost, and who owns the remains.

The questions are concrete at Meridian because the migration already made them concrete. Chapter 33 carried the migration’s archive backlog, the nine thousand archive records at clinics four and five, the records that are no longer active and must be retained, searched, and eventually retired under whatever the records rules require. The data has an end: retention, deletion, handover to the next system, and the end of the data is an obligation with dates and owners, whether or not anyone planned it. The platform has an end: the vendor’s product will be superseded, the license will expire, the maintenance will become uneconomic, and the decommissioning will cost money, the migration out, the retirement of the environments, the closure of the accounts, the preservation of the records, and the communication to the clinics whose workflows it carried.

The discipline is the sunset paragraph: one paragraph in the service model, written at the design of the service, not at its end, answering how this ends: the data ownership, who owns the records and what happens to them; the exit clauses, what the vendor contract says about leaving, which is the exit planning of chapter 20 applied to the operation; the decommissioning budget line, a row in the run-cost forecast, small, annual, named; and the sunset criteria, the triggers that say when the end is due, when the cost exceeds the return, when the risk exceeds the value, when the thing is superseded, when the last user leaves. The criteria are the kill criteria of chapter 5 asked about the operation: an operation without sunset criteria is an operation that will be ended by accident, in a budget cycle, by a licensing renewal nobody wanted to fight, and the end that is a decision is the end that is managed.

The failure pattern of the discipline is the abandoned system: the platform nobody decommissions because nobody owns it, the data nobody retires because the records rules expired with the project, the vendor exit nobody planned because the contract was written for the build and not the leaving. The field signal is the system that is still running, still costing, and still unowned, years after its last real user, kept alive by the fact that no one has decided to end it, which is the January problem at the end of the story instead of the beginning. The repair is the paragraph, written early, owned, dated, and reviewed, because the service that has no end is the service that will be ended badly.

The December that worked, and the January that didn’t

The worked application is the January review itself, followed through its decisions, because the review is the chapter in one meeting: the delivery succeeded, the seam failed, and the seam was repaired. The room works through the disciplines in the order the meeting’s own evidence demands.

The naming comes first, because the naming is what makes the rest possible. Nora names Tunde Bakare the platform’s service owner, the operations seat for the run, distinct from Marcus’s project seat for the build, and the naming is recorded in the steering committee’s minutes with the date, because the seat is the row that every other row attaches to. The service transition plan is the document the room builds: the operational readiness model as its spine, the five windows, each with its owner and its evidence and its date, the operator’s rows evidenced by the operator, the project’s rows evidenced by the project, and the overlap zone drawn as this chapter’s figure draws it, the project band and the operations band overlapping through the first quarter.

The support model is the second decision, and the options are the ones the chapter named. The room could build a full in-house support team, the strongest tier one and the beginning of tier two, at 360,000 units a year, the most capable and the slowest to stand up. It could buy the vendor’s full contract, tier two and tier three at 240,000, and staff a tier one from the clinic’s own reception, the cheapest and the riskiest, the support line that is the reception desk with a script. It could borrow, the project’s analysts on the project’s money past March, the fastest and the most expensive, because the borrowing is the debt that compounds. The decision the room makes is the one the arithmetic supports: build a small tier one, two service desk staff funded from the run budget, and buy the vendor’s tier two and tier three at 240,000, the tier one the promise the users see, the tier two the knowledge the project would otherwise lose, the total landing inside the run-cost forecast the room just built.

The run-cost forecast is the third decision, and the room builds it on the wall from the rows the chapter priced: 612,000 a year, 51,000 a month, with the rows owned and the assumptions stated. The funding is the fourth decision, and it is the one the finance director has been waiting for: the 612,000 goes into the IT operating budget as a new line for the new year, and the first quarter, the 153,000 the September budget could not have known about, is bridged by a transition reserve drawn from the project’s contingency pocket, the two-pocket discipline of chapter 15 applied at the boundary, the reserve released by the steering committee on evidence, with the owner, the date, and the consequence named, because the bridge is a transition instrument, not a new budget, and the transition ends when the line begins.

The data-quality monitoring is the fifth decision, and it is the cheapest and the most consequential: the 6,000 a month funded, the owner named, the sample, the threshold, the report, the review, the correction path, and the first corrected report goes to the grant officer before the quarter’s measures are claimed, because the favor that protected the grant’s data becomes the instrument that protects it, and the 0.4 percent of the grant value that it costs is the insurance the network cannot afford to refuse. The debt ledger is the sixth decision, the four debts named, priced, owned, and dated, the monitoring paid, the support model built, the workflow updates scheduled behind the training waves with their review date, the deferred configuration items carried with their owners, the ledger reviewed quarterly, because the debts that are on the ledger are decisions and the debts that are not are accidents.

The change interface is the seventh decision, signed by Dana for the project and Tunde for the operation, one document naming who may change what, under what authority, with what rollback, on what calendar, the operating change pipeline running before the project’s last release, and the referral policy’s next amendment routed through it, because the change that touches the operation is not done when it ships, it is done when the operation carries it. The sunset paragraph is the eighth decision, written into the service model by Tunde, reviewed with the license renewal: the archive records named, the exit clauses checked, the decommissioning line opened, the sunset criteria stated, because the end that is designed at the beginning is the end that is decided instead of discovered.

The room’s last act is the definition of done, written where the old one was written: the service is done when the service owner is named, the support model is funded, the monitoring is running with an owner, the runbook is rehearsed, the capacity is sized, the data quality is sampled, the change path is agreed, the run cost is in a line, and the end is designed. The December gate asked can the clinics open, and the answer was yes. The January gate asks can the service run, and the answer is now yes, on evidence, with owners, and with money.

The three clocks

The integration wears the delivery style differently, and the differences matter at the boundary. At BlueLine, the register is predictive, and the integration is the formal handover: the corridor’s operating regime, the maintenance contract, the ticketing operation, the transit authority’s staff, the handover gates with the operator’s acceptance evidence, and the operating subsidy of 90 million units a year that chapter 18 said belongs in the same conversation as the capital envelope, the run-cost forecast written into the business case before the first authorization, the operator’s rows in the readiness review, the maintenance regime as the operator’s service model, the whole discipline wearing the formal clothes the infrastructure world wears, gates, certificates, and signatures, with the same evidence underneath. The transition zone is the commissioning and the trial operation, the overlap drawn wide because the corridor cannot stop while the operator learns it.

At KijaniPay, the register is adaptive and product-centric, and the integration is inverted: the product is the service, and continuous delivery is the operation. The platform’s settlement promise is kept by the monitoring, the support, and the release pipeline, the merchant experience is the operation, the support calls are the product’s instrument, the incident is the product’s signal, and the boundary between the project and the operation is the boundary between one release and the next, so thin that the chapter’s disciplines are the product’s ordinary practice: the pipeline, the rollback, the monitoring, the runbook, the change cadence, the capacity plan, the debt ledger, all running as the product runs. The chapter’s lesson for the adaptive world is not the handover; it is the naming, the service owner, the run-cost line, the sunset criteria, the disciplines that product teams forget because the product is always the delivery, and the delivery is never the operation, and the merchant who cannot see her settlement is the January problem wearing a different jacket.

At Meridian, the register is hybrid, and the integration is the mixed seam: the construction handover runs formal, the certificate, the hold points, the operator’s maintenance staff, the platform transition runs continuous, the releases, the monitoring, the support contract, and the operational acceptance spans both, the service transition plan carrying the construction band and the platform band through the overlap zone together, the interface calendar of chapter 33 extended past the gate, the seam owner of the boundary named, Tunde, the clock of the overlap, the first quarter, owned. The hybrid’s last seam is the boundary this chapter drew, and the hybrid is complete only when that seam is designed, which is the difference between the program that coordinated its streams and the program that coordinated its future.

The delivered-and-abandoned project

The failure patterns of the integration deserve to be named together, because they are the same character at different ages. The delivered-and-abandoned project is the launch followed by silence: the go-live celebrated, the team released, the system running, and the operation unowned, and the field signal is the closeout report that exists and the service’s first incident that has no owner. The ceremonial handover is the acceptance signed and the operator absent: the certificate with the project’s names and no operator’s signature, the handover date on the plan and no transition zone on the plan, and the field signal is the acceptance that was verified and never operated. The project inbox as help desk is the support mailbox with the forwarding rule: the ticket answered by the person who built the thing, on project time, past the project, and the field signal is the mailbox that predates the service and outlives the project. The dashboard that stopped updating is the monitoring as a go-live artifact: the report that was stood up for the acceptance and stood down after, and the field signal is the last data point on the chart, the go-live date, the chart that is a monument. The hypercare that never ends is the transition zone that became a permanent state: the project team still running the operation a year later, on project money, because the operation was never funded to run itself, and the field signal is the hypercare line item that renews every quarter with no exit date. The run cost discovered in the budget cycle is the finance question asked for the first time after go-live: the question who pays for this, asked by the finance director, in the meeting the project did not call, and the field signal is the under-budget project that leaves the unfunded liability in its wake. And the debt that compounds silently is the ledger that was never opened: the workaround that everyone knows and nobody owns, the favor that was never replaced, the access list that nobody reviews, and the field signal is the shrug, the answer to who owns this being the silence of the voicemail.

Every one of these is the January meeting with a different clock, and every one of them is repaired by the same disciplines, named in the same order: the service owner, the support model, the readiness evidence from the operator, the run cost in a line, the change interface signed, the debts on a ledger, the end designed, the overlap drawn. The repair is not heroic; it is the ordinary work of the transition zone, done on a calendar, on evidence, with owners, before the ceremony, not after it.

Practice

One. A quick check: name the life cycle and the debt. For each scene, name the life cycle whose clock is running, project, product, service, or operations, and the debt, if any, that the scene is accruing, technical, operational, or change. (a) The platform’s code was written quickly to meet the gate, and the team that maintains it now spends every release reworking the parts that were built fast. (b) The clinics are open, and the support line routes to the reception desk, and the tickets age past the promise. (c) The release shipped with the training for it deferred to the next quarter, and the staff who must use the new field are still working the old way. (d) The backup ran, the monitoring reported, the runbook guided, and the incident was resolved in forty minutes, and the review that followed is scheduled. (e) The vendor’s contract ends at acceptance, and the exit clauses were never written, and the platform’s records have no owner for their retirement. (f) The system works, the acceptance was signed, and the operation has no one who has rehearsed the failure it will eventually meet.

(a) is the product clock running, and the debt is technical, the interest paid in the rework, and the repair is the ledger, the debt named, priced, owned, and given a payment plan. (b) is the service clock, and the debt is operational, the support model borrowed, and the repair is the named service owner and the funded tier one. (c) is the operations clock, and the debt is change debt, the training deferred, the adoption corridor of chapter 11 still converging, and the repair is the scheduling of the deferred work with its owner and date. (d) is the service clock running well: the monitoring, the runbook, and the rehearsal are the operational acceptance in action, and the review that follows is the improvement loop, the debt being paid rather than accrued. (e) is the product clock and the operations clock meeting at the end, and the debt is the unplanned end, the sunset paragraph missing, the exit clauses absent, the data unowned, and the repair is the end designed at the beginning. (f) is the operations clock with the operational acceptance missing: the system works and the service cannot be operated, the acceptance evidence and the rehearsal absent, and the repair is the operator’s row evidenced by the operator, the runbook rehearsed in the operator’s environment. The common error is naming the debt by its symptom instead of its mechanism: the fast code is technical, the unreached training is change, the unanswered phone is operational, and the same repair, the ledger, the owner, the date, serves all three.

Two. A field drill: write the minimum viable support model for your own deliverable. Take the last system, service, or facility your project delivered, or the one it is about to deliver, and write the one-page support model: the entry point, one number and one mailbox that a named person checks; the tiers, first-line, second-line, third-line, with the owner of each; the escalation, what happens when a tier cannot resolve, with a named path and a time; the hours, the window in which the promise is made, stated honestly; and the service-level frame, the promise in the user’s language with its measure. Then answer the two questions the model exists for: who answers the phone, and who pays?

The drill passes when the page has names, not roles: the person who checks the mailbox, the person who owns the tier, the number that the user calls, and the budget line with a name beside it. The most common failure is the model written as a description of the current state: the mailbox that is the project’s, the hours that are the building’s, the tier that is the vendor’s, with no decision in the page; the repair is the decision, the build, buy, or borrow made and funded. The second failure is the frame without measures: the promise of support with no response time, the availability with no threshold, the data quality with no sample; the repair is the measure with the owner and the report, because the promise without a measure is the hope that the January meeting found. The third failure is the model that stops at the system and never reaches the user: the support model for the platform that says nothing about the clinic that calls it, the receptionist who takes the message, the pharmacist who flags the medication list; the repair is the user’s journey through the model, the call made, the ticket opened, the promise kept, the evidence filed.

Three. A field drill: build the one-page run-cost forecast. For the same deliverable, write the page: the rows the operation costs, staff, licenses and infrastructure, support, maintenance, capacity growth, renewal, decommissioning; the number for each row; the owner of each row; the assumption under each number. Then add the second column: the value the run protects, the revenue, the grant, the mission outcome, the savings that the operation sustains, and the arithmetic of the run cost as a percentage of that value. Close with the funding answer: which budget line carries the run cost, and who owns it.

The drill passes when the page names the line and the owner, because the run-cost forecast is a decision instrument, not a finance artifact: the line in the operating budget with a name beside it is the difference between the funded service and the January meeting. The most common failure is the forecast with rows and no assumptions, the numbers that look precise and are unreproducible; the repair is the assumption written beside every number, because the assumption is what the review will challenge. The second failure is the forecast without the value column, the cost computed and the protection unnamed, the 612,000 with no 1,500,000 beside it; the repair is the value, because the run cost as a percentage of the value is the sentence that moves the budget decision. The third failure is the forecast written by the project for the project, the rows that the operator will dispute, the numbers that the operator’s budget did not see; the repair is the operator’s hand in the page, the service owner’s signature under the line, because the forecast that the operator does not own is the forecast that will be discovered in the budget cycle, and the budget cycle is the January meeting.

Four. A decision room: fund the platform for the quarter. It is the third Tuesday of January at Meridian, and the room has the run-cost forecast on the wall: 612,000 a year, 51,000 a month, the project budget closing on the thirty-first of March, the IT budget with no platform line, the vendor’s support contract quoted at 240,000, the monitoring at 6,000 a month, the grant’s clinic-month value of 1,500,000 a month for the six live clinics, and the first quarter unfunded. The options: (a) add the 612,000 to the IT operating budget for the new year and bridge the first quarter with a 153,000 transition reserve drawn from the project’s contingency pocket, released by the steering committee on evidence, with the monitoring funded from the first; (b) hold the new line to the vendor’s 240,000 support contract and the project’s analysts on loan until the budget cycle, accepting that the monitoring remains a favor and the tier one remains the reception desk; (c) keep the platform on the project’s books until the grant window closes, funding the run from the project’s remaining contingency and closing the project when the grant does; (d) fund the full in-house team at 360,000 and drop the vendor contract, on the argument that the knowledge should live in the network. Decide the move and say what the record must carry.

The defensible answer is (a), and the reasoning is the chapter’s disciplines in one decision: the run cost belongs in a budget line with an owner, the operating budget, not the project’s contingency, because the contingency is for named delivery risks and the run is an operating reality, the two-pocket discipline of chapter 15 applied at the boundary; the bridge is a transition instrument with an owner, a date, and a consequence, the evidence that the line has opened, and the monitoring is funded from the first because the 6,000 a month protects the 1,500,000 a month of grant value the audited measures underwrite, the 0.4 percent that is the cheapest insurance in the network. (b) is the January meeting’s accident made a policy: the borrowed analysts are the debt that compounds, the monitoring stays a favor, and the reception desk stays the tier one, the support model unfunded and the data quality unowned; it buys three months and pays for them for years. (c) is the most tempting and the most dangerous: the grant window closed with the December openings at month thirty-six, and the platform funded by the project’s contingency is the platform whose run cost has no line when the contingency is gone, the operating liability in the budget cycle; the grant pays for access outcomes, not for platform operations, and the confusion is the one the grant officer has been counting on the network to avoid. (d) is defensible in intent and costly in the quarter: the in-house team is the strongest long-term answer and the slowest to stand up, and the vendor’s engineers are the only people who can change the platform’s code today, so the build replaces the buy on a schedule, not in a decision. The record must carry the run-cost forecast with its assumptions, the new line with its owner, the bridge with its evidence, the monitoring’s threshold and report, the support model’s tiers and hours, and the review date, because the funding decision is a hypothesis about the quarter, and the record is how the hypothesis is tested, the tickets answered, the measures claimed, the data clean.

Five. A decision room: decide the sunset. A regional payments platform, built by a project that closed four years ago, still runs. The monthly run cost is 34,000 units; the platform serves two legacy products that newer systems have replaced; the remaining users, about three hundred merchants and one partner bank, are supported by a third-party contract that renews in six months; the data includes settlement records the regulations require the firm to retain for seven years; and the exit clauses in the original build contract were never exercised because the vendor’s product was acquired and the maintenance is now on a time-and-materials arrangement. The options: (a) decommission at the renewal, migrate the three hundred merchants to the newer platform, archive the retained records, and close the accounts; (b) renew the contract for two more years and plan the migration in the second year, on the argument that the merchants are not ready and the partner bank is not engaged; (c) keep the platform running indefinitely, because the records require retention and the merchants are profitable; (d) negotiate the vendor’s buyout of the platform’s operation, transferring the run cost and the support to the vendor. Decide the move and say what the record must carry.

The defensible answer is (a) with (b)’s migration schedule inside it, and the reasoning is the sunset discipline in one decision: the platform has met its sunset criteria, the cost exceeds the contribution of the legacy products, the newer platform has replaced it, and the end that is decided is the end that is managed, the migration scheduled, the records archived to the retention schedule, the accounts closed, the cost retired, the decommissioning line spent once instead of forever. (b) alone is the renewal as avoidance: the merchants are not ready is the change debt of the platform’s last project, the readiness that was deferred for years, and the partner bank’s engagement is the stakeholder work of chapter 9 that the sunset makes urgent, not optional, so the schedule belongs in (a), not instead of it. (c) is the abandoned system with a justification: the retention requirement applies to the records, not to the platform, the archive is the instrument that satisfies it, and the profitable merchants are the migration’s first cohort, not the platform’s reason to live, the sunset criteria of the service model overridden by the fear of the end; the records do not need the platform, they need an owner. (d) is the risk transfer dressed as a decision: the vendor that operates the platform owns the run cost and the data and the merchants’ continuity, and the firm loses the control of the migration, the records, and the exit it just designed; the exit clauses that were never exercised are the warning, not the path. The record must carry the sunset decision and its criteria, the migration schedule with its cohorts and its owner, the archive plan with the retention dates and the data owner, the account closure list, the decommissioning budget, and the communication to the merchants and the bank, because the sunset is a project, the last project of the service, and it needs the same instruments the first one did.

Six. The mastery drill: what done must include for a new service. Here is a delivered system: a public library system has just opened a network of three new branches, each with a shared self-service kiosk, a booking system for meeting rooms and study spaces, a staff scheduling application, and an online catalogue that replaces a legacy system, all delivered on time and under budget by a project that closed last month. The kiosks are popular; the catalogue is working; the staff were trained in a rollout week; the vendor’s warranty runs for one year; the IT department’s budget, built before the project, has no line for the new systems; and the library’s operating budget has a new line for branch staffing but not for the systems. The first month’s observation finds: the kiosk queue backs up at peak hours on two branches, the booking system’s calendar conflicts recur on Friday afternoons, the catalogue’s search returns outdated availability for one popular collection, and the staff have developed a paper workaround for the booking conflicts that they prefer to the system. Decide what done must include for this service, and say what the record must carry.

The mastery is not the list, it is the completeness of the life-cycle thinking, and the test is the one the chapter gave the January meeting: the service is done when the service owner is named, the support model is funded, the monitoring is running with an owner, the runbook is rehearsed, the capacity is sized, the data quality is sampled, the change path is agreed, the run cost is in a line, and the end is designed. For the library, done includes: the service owner, one person in the library’s operations who answers for the kiosks, the booking, the scheduling, and the catalogue together, because the four systems are one service to the patron; the support model, the entry point, the tiers, the escalation, the hours, the build, buy, or borrow decision, with the borrowing of the closed project’s staff rejected on the record; the capacity plan, the kiosk queue and the Friday calendar conflicts as the demand signals that the model must absorb, the queue at peak hours the capacity question of chapter 19 asked about the service; the data quality, the catalogue’s outdated availability as the sample’s first finding, with the threshold, the owner, the report; the run cost in a line, the IT budget’s new line and the transition bridge for the year between the budget that was built and the line that opens; the change path, the vendor’s warranty releases and the library’s own changes under one interface; the sunset paragraph, the catalogue’s data ownership and the legacy system’s retirement, the records rules that the legacy data carries; and the paper workaround, which is the change debt of the rollout, the training that taught the system and the adoption corridor that did not converge, the workaround that everyone knows and nobody owns, the debt that the ledger must name before the workaround becomes the process. The record must carry the service model with its six rows, the readiness evidence from the operator, the run-cost line, the funding bridge, the change interface, the debt ledger with the workaround as its first entry, and the review date, because done is not a moment, it is the state in which the service runs without the project, and the state is evidenced, not celebrated. The common failure is the list that stops at the system: the warranty, the training week, the acceptance certificate, the systems working, and the service unowned, the January meeting wearing a library card.

Seven. The transfer question. On the project you lead, or the one you work on, who answers the phone? Which number does the poster print, and whose mailbox does it route to, and what happens after five, and when did you last call it and wait for a name? Can you draw the four clocks of your own deliverable: the project clock that will end, the product clock that will run as long as the thing is used, the service clock that runs as long as the promise is made, and the operations clock that never ends by design, and which clock have you been treating as if it stopped at your gate? Where is the overlap in your transition: the zone where the operator joined the acceptance criteria and the readiness review before your gate, and the zone where your team carried the runbooks and the hypercare after it, and who owns the zone, or is your boundary the line that chapter 36 drew to warn you? What is the support model your deliverable will have, build, buy, or borrow, and who decided, and is the decision on the record, or is the borrowed help desk the default you discovered in a January meeting you did not call? What does your operational acceptance prove: that the system works, or that the service can be operated, the deployment rehearsed, the rollback run, the monitoring reporting, the runbook guiding, the operator’s hands on the controls in the operator’s environment? Where is the change interface between your project’s control and your operation’s change management, and who signed it, and what is the referral policy of your own world, the change that shipped to the system and never reached the workflow, the training, and the acceptance, and is it in the 4.2 percent you will find in six weeks? What is on your debt ledger: the debts named, priced, owned, and dated, the monitoring that was a favor, the support model that is borrowed, the training that was deferred, the configuration that rode the release, and which of them are strategic, chosen for what they bought, and which are accidents, incurred without a decision, and who can answer who owns this about the thing you just delivered? What is your run-cost forecast: the rows, the assumptions, the value the run protects, the line in the operating budget with a name beside it, and the percentage of the value that the run costs, and is the number in the business case, reviewed at every gate, or is it the question the finance director will ask in the meeting you did not call? What is your sunset paragraph: the data ownership, the exit clauses, the decommissioning line, the sunset criteria, written at the design of the service, not at its end, and who owns the remains when the thing you built is done? And the question underneath all of them: what must be true for this to run without you, and who wrote the page, and who signed it, because the integration of the project with the product, the service, and the operations is not the closing ceremony, it is the overlap zone in which the ownership moves on evidence, the durable principle of the January meeting, that the project’s output is a capability, and the capability only becomes value when an operation sustains it, the owner named, the support funded, the monitoring running, the change agreed, the debts chosen, the run cost in a line, and the end designed. The most common next failure is the one every integration faces when the ceremony is over: the instruments decay, the support model runs and the tickets age, the monitoring reports and the threshold moves, the debt ledger is reviewed and the review slips, the sunset paragraph is written and the license renews, the overlap zone narrows until it is the line again, which is why the service has its review cadence and the transition has its date, the instrument that is not reviewed is the instrument that becomes the voicemail. And the next chapter turns to the instrument that makes the integration visible: the measurement system that tells the service whether it is keeping its promise, the dashboards and the indicators that turn the run-cost forecast, the data-quality sample, the support tickets, and the operational acceptance into decisions, the measures that drive the right behavior, the discipline that will tell Meridian’s grant officer, and every other owner, whether the thing that was delivered is actually working.*

Notes

• The composite cases remain author-created illustrative material. The Meridian January operations review, the third Tuesday of January, the three wave-three clinics live under the December gate, the support line routing to the reception desk, the forty-three vendor tickets with the twelve older than three days, the 4.2 percent data-quality sample, the grant officer’s first-quarter request, the finance director’s question, the vendor’s 240,000-unit support contract, Tunde Bakare as the network’s IT operations manager, and all named characters and roles are teaching constructions consistent with the facts established in earlier chapters: the six-clinic program with the shared platform, the grant’s 250,000 units per clinic-month, the access outcomes, the wait times, and the screening uptake, and the month-thirty-six window from chapters 1 and 5; the conditional kickoff with Nora Kariuki’s operational ownership, the grant targets beside her name, the governance map, and the external reviewer from chapter 8; the definition of done spanning the seams, the migration reconciliation at zero unexplained gaps, and the privacy certification from chapter 10; the adoption corridor above eighty-five percent, the super-user program, the transition target, and the classroom competency check from chapter 11; the hybrid choice, the predictive construction, the adaptive platform inside gated releases, the acceptance evidence pack, and the vendor’s implementation lead from chapter 13; the capacity plan, the double-booked super-users, and the training cohorts from chapter 19; the make-or-buy, the fixed price on the integration and the migration, and the time-and-materials on the build from chapter 20; the acceptance matrix and the clinical escalation competence from chapter 21; the RTO and RPO and the exercised plan from chapter 23; the privacy certification, the records of processing, the accessibility report, the continuity plan, the obligations register, the assurance map, and the floor rows from chapter 24; the two-pocket discipline from chapter 15 and the readiness dashboard with its five windows and five owners and one gate from chapter 29; the interface register and the formal change path from chapter 31; the empirical loop and the definition of done from chapter 32; the December gate, the wave-three architecture, the five streams, the seam owners, the interface calendar, the migration arithmetic with its sixty-six thousand records, forty-one thousand migrated, sixteen thousand active and nine thousand archive, the referral pathway policy from the district mandatory from the first of the new year routed through the five streams, the grant officer who counts wait times and screening uptake, Marcus Chen’s nine configuration items, Sam Otieno’s cohorts, Esther Njeri’s assessment, the heroics coordinator, and the re-tailoring record from chapter 33; the dependency and interface discipline from chapter 34; and the distributed coordination from chapter 35. The teaching numbers introduced here are fully reproducible from the text: the platform run cost of 180,000 plus 240,000 plus 72,000 plus 120,000 equals 612,000 units a year, 51,000 a month; the grant’s six clinics at 250,000 per clinic-month equals 1,500,000 a month of clinic value; 51,000 divided by 1,500,000 is about 3.4 percent; the 6,000-a-month data-quality monitoring is about 0.4 percent of 1,500,000; the unfunded first quarter at 51,000 a month for three months is 153,000 units; and the ten-year total-cost view, 612,000 a year for ten years, about 6.1 million, against a build of about 11.2 million, with renewal and decommissioning at roughly 400,000, shows the run cost at more than half the build, all stated with their assumptions as teaching judgments rather than measurements, the platform build figure and the operating figures being author-created for this chapter’s exercises. The standards and sources are described in the book’s own words: the technical-debt metaphor, the obligation that accrues when speed in the present is chosen over correctness in the future, originates with Ward Cunningham’s 1992 report on the WyCash portfolio management system, described here in the author’s own words; the four delivery-performance measures, deployment frequency, lead time for change, change failure rate, and time to restore service, and their correlation with organizational performance, come from the software delivery research of Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution Press, 2018, described here in the author’s own words, with the caveat that the research concerns software delivery and this book transfers its measures to other domains as a pattern, not a law; the continuous-delivery idea, that software can be released to production safely at any time through an automated and rehearsed path from change to live operation, follows Jez Humble and Dave Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, Addison-Wesley, 2010, described here in the book’s own words; the service-level objective and error-budget discipline, the promise of reliability measured and traded, is a practitioner pattern associated with the site reliability engineering literature, represented by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, editors, Site Reliability Engineering: How Google Runs Production Systems, O’Reilly, 2016, described here in the author’s own words as a pattern the book adapts; the service-management vocabulary of service desk, incident, problem, change, and service level, the terms the practitioners use for the repeated promise and its rhythm, follows the practitioner pattern popularized by ITIL 4, the service-management framework published by AXELOS, described here in the book’s own words without reproducing its proprietary structure; the general project-management guidance of ISO 21502:2020, Project, programme and portfolio management: Guidance on project management, which treats the handover of outputs to operations and the realization of benefits as part of the project’s scope of concern, is described in the book’s own words as the general frame for the integration discipline; and the PMBOK Guide, Eighth Edition, Project Management Institute, November 2025, per the book’s reference baseline of 1 August 2026, treats the delivery of value and the management of the work’s transition into ongoing operation inside its performance domains, described here in the book’s own words. This book remains independent of PMI, ISO, AXELOS, and all standards and framework bodies, and no proprietary certification manual, commercial text, or framework guide is reproduced or paraphrased here.