Chapter 8: Authorize with a Charter and Govern with Clarity

The signature that changed nothing

In the fifth month after the board approved the clinic program, the Meridian steering committee meets to authorize the start. Twelve people sit around a table built for eight: the chief operating officer, the finance director, the clinical director, the digital platform lead, the director of clinic operations, the privacy officer, the community liaison, three deputies who attend because their directors attend, Dana Okafor the project manager, and the external reviewer the board assigned after the selection review.

Elena Marchetti holds up the draft. “The charter is one page,” she says, “because one page is what everyone in this room will actually read. Let us go through it and approve.”

They do. Purpose, outcomes, scope boundaries, constraints, assumptions, top risks: each line gets a sentence or two, no argument. Then they reach the bottom, where four names sit under four seats. Sponsor, Elena Marchetti. Project leader, Dana Okafor. Product ownership, Marcus Chen, the platform lead. Operational ownership, blank.

Elena reads the blank line aloud. “Operational ownership. Who owns clinical adoption when the platform goes live? Who answers for whether the clinics actually use it, whether wait times fall, whether screening uptake rises? The grant pays on those numbers, not on certificates of occupancy.”

Hana Lindqvist, the clinical director, answers first. “My clinicians will be involved in the workflows. We cannot adopt a system we do not trust.”

Marcus Chen adds: “My team builds the training and the configuration. Adoption after go-live is beyond the build.”

The finance director looks at the grant schedule and says nothing.

The external reviewer asks from the side of the table: “Elena, the cell is blank. Whose name goes in it?”

“We will name the owner at the first gate,” Elena says. “The program needs to start. The window closes at month thirty-six, and every month we deliberate is a month the grant cannot pay.”

Dana waits, then says it plainly: “We can name the owner at the first gate. The program needs to start.”

Elena signs. The cell stays blank. Twelve people have authorized a project that does not say who answers for the outcome the grant actually buys.

Eight weeks later, at the first gate, the blank cell has a price. The platform foundation is done: the software is installed, the interfaces are open, the configuration environment is ready. What is not ready is the clinical workflow standard, the decision about how a clinic will schedule, book, check in, escalate, and document under the new system. Marcus’s team can configure the system; no one has decided what the system will say about care. Hana says the workflow standard is a governance decision, not a project decision. Dana says she cannot set clinical policy, and she is right. The community liaison reports that the neighborhoods are asking when the clinics open, and the grant clock is running.

The next steering committee meeting is three weeks away, and its agenda is already written. It begins with eleven status updates.

This chapter is about what happened between those two scenes. The business case from the last chapter produced decisions, conditions, triggers, and owners. The charter is where those decisions get written down as a decision to begin, and the governance system is what keeps them alive after the signing. The two scenes are the same failure at two distances: an authorization that did not decide, and the governance that could not.

Authorization is a decision, not a signature

A charter converts an approved business case into authorized work. The business case argues: here is the value, the options, the costs, the benefits, the swing assumption, the trigger, the owner. The charter decides: this work exists, for this purpose, under these names, governed this way. The case is the argument; the charter is the permission, and the permission is only as good as the decisions it contains.

Three decisions the charter must make possible. The value decision: why this work exists and how the organization will know it worked — outcomes with measures and benefit owners, carried over from the case. The accountability decision: who answers for delivery, for the product, for adoption, for the money — names in seats, not committees. The decision-machinery decision: how the project is governed as conditions change — forums, decision rights, tolerances, and escalation. A charter that covers the first two and skips the third authorizes a project with no way to steer it. A charter that covers the third and skips the first authorizes machinery with no destination.

The one-page discipline is not formatting. It is a test. A constitution of a temporary organization that requires a binder has not been read by the people it governs, and an authorization is only alive when the people who must honor it have actually read it. One page forces the choices: outcomes, exclusions, constraints, assumptions, risks, names, and a governance note. If the draft will not fit on a page, the decisions have not been made yet; what you have is a list of aspirations.

The field signal that reveals a charter that was never a decision: it reads like a brochure. “Deliver world-class integrated care through a state-of-the-art platform” is a wish with letterhead. An authorization is a set of statements someone can be held to: “the shared platform is live in six clinics by month twenty-four, adoption measured by workflow completion and the grant’s access targets, owned by Nora Kariuki.” One sentence carries the value, the measure, the date, and the name. That sentence is the difference between authorizing an idea and authorizing a decision.

The load-bearing lines

The charter’s lines, in the order they are most often faked.

Outcomes come first, and they are not outputs. “Six clinics delivered by December” was the sentence that opened this book’s first chapter, and it is an output list wearing a success definition. The charter’s outcome line is a changed state for a named stakeholder, with a measure and a benefit owner: “access outcomes meet the grant threshold in six neighborhoods, owned by the clinic operations director, measured from the grant’s own reporting.” The failure at Meridian was not that this line was missing; it was that the outcome line carried the grant targets and the seat line carried no one, so the outcome was authorized without an owner. The two lines only work together.

Scope boundaries have two parts, and the second is the one that gets skipped: what is in, and what is out. Exclusions are the charter’s honesty. Meridian’s charter should have written: “clinical workflow design is in; the patient-facing app is out, deferred by selection; claims integration is out.” An out list stops the slow death by creep, because every future request must be evaluated against the boundary the room agreed to when no one was asking for anything. A charter with only an in list is an invitation: everything is in scope until someone remembers to fight, at the worst possible moment, under schedule pressure, against a stakeholder who was never told they were excluded.

Constraints are the non-negotiables, and they must be distinguished from preferences. A constraint cannot be traded: a license condition, a safety requirement, a deadline with a penalty, a fixed funding envelope. A preference can be traded, with a decision: a target date with no penalty, a design standard, a staffing ratio. The failure pattern is preferences written as constraints, which over-constrains the plan and blocks every trade, or constraints hidden, which builds the plan on ground that will move. Meridian’s constraints are real: the grant window at month thirty-six, the privacy certification before any clinic connects, the community commitments made to the two neighborhoods that remember the closed clinic. Each belongs in the charter with the authority who will enforce it.

Assumptions are the statements the plan depends on that are not yet true, and in the charter each one carries an owner and a review date. “The platform vendor delivers the integration interface by month nine, owner Marcus Chen, check date month eight.” This is the assumption backlog from chapter 6 growing up into the authorization: the charter is where the project’s most load-bearing guesses stop being private and become owned. The failure is the assumption line that says “stable funding” with no owner, which is not an assumption, it is a hope that the plan’s foundation is someone else’s problem.

Top risks are the few the sponsor accepts. The full risk register belongs to the team; the charter carries the risks that can kill the value and that only the sponsor can own: the grant-window risk, the adoption risk, the vendor dependency. Naming them in the charter makes the sponsor’s acceptance explicit and dated. The sponsor is not approving a risk-free project; no such project exists. The sponsor is approving this set of risks, in writing, knowing the ones named are the ones that will come back to their desk.

The whole-charter failure pattern deserves its own sentence. A charter that takes ten minutes to approve was written by one person and read by no one; a charter that takes two hours to approve is alignment. The Meridian signing took forty minutes, and the one line that mattered was the line the room agreed to postpone, because postponing the seat was the path of least resistance for twelve people with no disagreement. Approving an unfinished decision is not faster; it is faster now and slower at the first gate, where the time is billed at the grant’s rate.

Four seats, and the one that was empty

The charter’s accountability section is four seats, and the seats are the chapter’s load-bearing wall. Fill the seats and most governance problems become tractable; leave one empty and no governance design can save it.

The sponsor is accountable for the value case. The sponsor holds the authority and the money, removes obstacles above the team’s ceiling, defends the project against competing priorities, and is visible when the news is bad. The United Kingdom’s public sector makes this idea unusually concrete: its project delivery standard requires each project to have a named senior responsible owner, a person who is personally accountable for the project’s success, not a committee that collectively owns it. The title varies across organizations; the seat does not. The tell of a sponsor seat that is occupied in name only: every escalation from the team lands on the project manager’s desk anyway, because the sponsor has no appetite for the hard call.

The project leader is accountable for integrating delivery: the work, the schedule, the budget, the quality, the risk, the evidence, and the decisions within tolerance. At Meridian that is Dana, and her seat is the only one that was always occupied, which is why the committee could drift: the integrator was working, so the missing seats were invisible.

Product ownership is accountable for what the project produces: the definition of the product, the priorities, and the acceptance. For the platform, this seat is the interesting one. The person who decides what the platform does for care should be clinical, not technical. If Marcus Chen alone holds product ownership, the platform will be well engineered and clinically awkward, because the person answering for the product is answering for the build. The seat belongs to someone who answers for whether care works on the system — the workflows, the order of capabilities, the acceptance of what is ready for a clinic — with Marcus answering for whether it can be built. That is a clinical call with a technical counter-signature.

Operational ownership is accountable for the state after the project: adoption, operation, and the benefits the grant pays for. This was the empty seat at Meridian. It belongs to someone who owns the operating result, not someone who is merely involved in the outcome. Nora Kariuki, the director of clinic operations, owns access outcomes at the existing sites; she is the natural owner for the new ones. Chapter 1 named this correction early: name the benefit owners in the charter before the work starts. That is this seat: the grant targets beside a name, from signing, not from handover.

Two failure patterns make the seat system fail. The empty seat: the sponsor seat empty, so the project manager acts as sponsor and every escalation becomes a personal favor; or the operational seat empty, so everyone is “involved in” adoption and no one is accountable for it. The tell is the sentence that appears in the charter instead of a name: “we will work closely with operations.” And the wrong occupant: the clinical director is not the adoption owner. She owns the clinical standards; the adoption owner owns the measured outcome and has operating authority over the sites. In a small project the same person may hold several seats, and that is fine. The seats still exist, because the questions they answer are different questions; merging them in one person without noticing is how a single over-stretched name becomes four silent gaps.

Governance is the decision machinery

Governance is the system that answers four questions for the life of the project: who decides what, with what information, within what latitude, and how does something move up? It is not the organization chart, and it is not the meeting calendar. It is decision machinery. A structure that meets but cannot decide is not governance; it is a status ritual with a budget.

Four parts, and each part must be explicit or the machinery seizes.

Forums are when decisions get made. The cadence should match the speed of the decisions that matter: monthly for tranche funding, weekly for the integrated risk review, immediate for anything that crosses a tolerance. The governing error is a single cadence for everything: a committee that meets monthly is the wrong place for a decision that costs 250,000 units a week to postpone, and the right place for a decision that should never be made on a Tuesday.

Decision rights are who decides what, and they are the governance map, the chapter’s primary picture. Figure 8.1 shows the architecture at Meridian: decisions flow to the level with the knowledge and the accountability, the committee decides only what exceeds the team’s tolerance, and assurance looks in from the side, reporting to the sponsor rather than through the team.

Figure 8.1: The governance architecture. Decisions flow to the
level with the knowledge and the accountability; the steering
committee decides only what exceeds the team's tolerance.
Independent assurance reports to the sponsor, not through the
project team.

  BOARD / ENTERPRISE OVERSIGHT
    |   approves the funding envelope and the outcome commitments
    v
  STEERING COMMITTEE  (sponsor chairs)
    |   decides: tranche funding, scope change above tolerance,
    |   risk acceptance above tolerance, re-scope or stop
    |   inputs: exception report, forecast, assurance findings
    |   tolerances: cost +/- 5 percent on a tranche, schedule
    |   +/- 2 weeks, outcomes not changeable without a board call
    v
  PROJECT LEADER  (Dana)
    |   decides within tolerance: work, schedule, budget, risk
    |   escalation: decision, options, recommendation, deadline
    v
  TEAM  (delivery, product, operations seats)
        ^
        |   independent evidence and challenge
  ASSURANCE  (reports to the sponsor)

Pairing the right to decide with the knowledge required to decide well beats routing every decision upward to people who know less; organizational economics has argued exactly this for decades. The design conclusion: the right to decide the clinical workflow standard needs the person who knows care; the right to re-scope above tolerance needs the sponsor; the right to reorder the platform backlog within tolerance sits with product ownership.

Tolerances are the bands within which the team decides without escalation: time, cost, scope, quality, risk. A tolerance is a delegation with a boundary. Dana can absorb a cost variance of 5 percent on the tranche, or a schedule slip of two weeks, without a meeting; beyond that, the committee decides. Tolerances are written, agreed, and tested. A tolerance that is never used is either a sign that variance is being hidden to avoid the conversation, or a sign that the governance is theater. The test is simple: ask at the next gate what variance occurred since the last gate and who decided. If the answer is “none, everything is on plan,” either the plan is lucky beyond reason or the tolerance is being protected instead of used.

Escalation is the designed path for decisions above tolerance, and it is a normal channel, not a failure mode. A good escalation is a request for a decision, not a dump of information: the decision required, the options considered, the recommendation, the cost of waiting, and the deadline by which the answer is needed. The failure modes are escalation as drama, “we need a decision NOW” with no analysis, and escalation as avoidance, the question everyone can see that nobody owns, passed upward in the hope that someone else will carry it.

The most dangerous governance design is the one that looks right and decides nothing: a steering committee of senior people who receive the project manager’s dashboard, hear updates, ask good questions, and adjourn. The tell is in the minutes. There is no decision column, no owner column, no dates. The same item appears on three consecutive agendas. Every question is answered with “we will take that to the committee,” when the committee is the room they are already sitting in.

The committee that could not decide

Meridian’s committee is the case study, and its diagnosis is structural, not personal. Twelve members. No decision rights, because no one had been told who decides what, so every decision defaulted to the full committee at the next meeting, which was the slowest possible path for every question. No tolerances, so every variance, even a small one, had to travel. No escalation path, so questions waited for the calendar instead of the decision. And an empty seat, so the question that mattered most had no one who owned it at all.

The rebuild has five moves.

First, fill the empty seat. Nora Kariuki is named operational ownership, accountable for the adoption measures, with the grant targets written beside her name in the charter. This is not a personnel change; it is the recognition that someone already owns the operating result the grant pays for.

Second, write the decision rights matrix, the compact table that replaces the committee’s assumptions with decisions.

Third, narrow the agenda. The steering committee now sees the exception report: what is outside tolerance, what changed since the last gate, what is forecast, what decision is needed. Status updates live in the weekly integrated review, where the people who need the detail can read it. The committee’s job is the few decisions only it can make, and a meeting built around decisions takes twenty minutes or two hours, never one hour of updates plus five minutes of postponement.

Fourth, make escalation cheap and visible. Dana’s workflow-standard escalation is the model: the decision required is the clinical workflow standard for clinic one; the options are the network’s existing scheduling workflow adapted, or a streamlined go-live variant; the recommendation is the adapted workflow with a six-week clinical review; the cost of waiting is a number.

Here is the number. The workflow decision sat between the first gate and the next steering meeting, three weeks, and the missed configuration window pushes clinic one’s go-live from month twelve to month thirteen and a half. One and a half clinic-months at 250,000 units each is about 375,000 units lost to an undecided question. The arithmetic is blunt on purpose: a governance structure whose decision cadence is slower than the value at stake burns money on every adjournment, and the escalation format exists to convert “we will discuss it next month” into a number the decider can see before the month ends.

Fifth, give the challenger a real mandate. The reviewer asked the right question at signing; the redesign adds what makes it land: a reporting line to the sponsor, not through the team, a charge to find what the dashboards are not showing, and a seat at every gate. The reviewer is the reason the empty cell is now visible at signing instead of at go-live: “whose name goes in the cell” is the same question the gate asked eight weeks later, at ten times the price.

Gates are evidence, and money follows evidence

A stage gate is a decision point where the project earns the right to continue on evidence. A gate that cannot reject is a ceremony. The minimum viable gate is five questions on one page: what did we promise at the last gate, what evidence exists that we delivered it, what has changed since, what decision do we need now, and what conditions attach to continuing. The options at a gate are five: continue, continue with conditions, re-scope, pause, or stop. The stop option is not a decoration; it is the reason gates exist. Chapter 2 named stop-or-pivot conditions, and chapter 7 showed a gate that could kill a case; the gate here is the same idea in the governance machinery — the place where evidence is checked against authorization.

Rolling authorization is the funding expression of gates: do not authorize the whole project in one signature. Authorize the next tranche, and tie the tranche after that to evidence with named triggers. At Meridian, tranche one, the platform foundation, clinic one construction, and the workflow design, is authorized at signing. Tranche two is conditional, and the conditions are written: the workflow standard decided, the adoption owner with a plan and the grant targets attached, clinic one construction within tolerance. The grant window at month thirty-six makes rolling authorization natural, because the grant itself pays on evidence, access outcomes, not on plans. Adaptive funding is the same idea at delivery scale: for the platform work, budget is renewed in small increments on demonstrated evidence, not on spend rate. This is not looser governance; it is tighter, because the renewal is frequent and the evidence is specific. Money follows evidence.

The gate failure pattern is the one where the answer is known before the meeting: the gate that approves because the work is going well, without asking whether the outcome is still worth it. That is the sunk-cost gate, where continuing is assumed and the only question is pace. The best gate question is the selection question from chapter 5 wearing formal clothes: if we knew now what we know now, would we authorize this again? A gate that asks only “are we on plan” is a progress check, not a governance decision. Progress is necessary; it is not sufficient.

The question nobody asks: independent assurance

The sponsor has an information problem. The people reporting progress are the people whose careers the report affects, and the effect is real even when no one is dishonest. The dashboard is read by the people who built it; the variance is explained by the people who own it; the story is told by the people who need the story to hold. Not fraud; motivated perception. The sponsor needs at least one source of evidence that does not travel through the project team.

Assurance is that source: a reviewer, an internal auditor, an independent expert, someone whose loyalty is to the sponsor’s question rather than to the team’s story. The anti-pattern is the review board made of senior people who all read the same dashboard and all want to be supportive. The assurance seat is different in kind: its job is to find what the dashboard is not showing and to ask the question nobody wants asked, with evidence attached. Healthy challenge is a designed feature, not a personality trait. The best executive teams are not the most agreeable; they have structured ways to disagree about substance without it becoming personal. At least one seat in the governance structure should belong to someone whose incentive is productive disagreement, and the charter should say who.

Assurance scales with consequence. A two-week experiment needs a hard retrospective, not a reviewer. A public program with a grant, patient safety, and six neighborhoods needs an independent reviewer with a reporting line to the sponsor and a seat at every gate. The internal-audit tradition expresses this as three lines: management’s own controls, the risk and compliance oversight that monitors them, and independent audit that verifies both. Projects rarely need the full apparatus; they always need the question, and the question needs a reporting line that does not pass through the team being reviewed.

Assurance findings need an owner and a response date, or the assurance is theater. The reviewer’s report should end with items that someone must answer, and the next gate checks the answers. A finding with no owner is not a finding; it is a suggestion, and suggestions do not get gates.

Ready, conditionally ready, not ready

Authorization is not readiness. The charter says the project exists; the kickoff decision says whether the project can actually start. Readiness is concrete: the team assembled and available, the environments, access, data, tools, and contracts in place, the working agreements set, the decision rights understood, and the seats filled. The kickoff is a decision point in its own right, and it deserves a decision, not a date on the calendar.

Three options. Ready means start all planned work. Conditionally ready means start the work that is ready, and gate the rest behind named conditions with owners and dates. Not ready means return to the authorization: the gap between the plan and the conditions is too wide to bridge by conditions, and the honest move is to fix the charter or the plan rather than to start anyway.

The conditional start is the honest norm, because almost nothing is fully ready at authorization, and the discipline is in the conditions: each one has an owner, a date, and a consequence. At Meridian, the kickoff in the redesigned version is conditional, and the reviewer’s question at signing is the kickoff decision in miniature. “Elena, the cell is blank. Whose name goes in it?” “We will name the owner at the first gate.” “Then the start is conditional, and the condition has a date.” The conditions: Nora Kariuki named operational ownership within two weeks, with the adoption plan and the grant targets attached to gate two; the workflow standard decision scheduled with Hana and Nora within six weeks; the data migration plan approved within eight. Construction and the platform foundation start now. Workflow configuration does not start until the standard decision has an owner and a date.

The unsafe answer is not any of the three options; it is pretending the choice was made when it was not. Meridian signed the charter unconditionally and discovered the condition at the gate, which is where the price is highest. The kickoff decision exists so the conditions get written before the work starts, with dates and names, while the cost of waiting is still small.

The cadence changes; the decision does not

Governance changes with delivery approach, and the change is in cadence and form, not in whether decisions exist. In predictive delivery, gates are formal: written evidence, baselines, tolerances against the plan, change control for anything above tolerance, assurance aligned to regulatory evidence. In adaptive delivery, authorization is continuous: product ownership decides within tolerance, funding renews on demonstrated evidence, the steering layer governs by exception, and the empirical review takes the place of the formal gate. In hybrid delivery, which is Meridian’s shape, the gates sit at the seams: construction gated by physical evidence, the platform released by readiness, each clinic go-live gated by an integrated checklist across construction, platform, training, and adoption. The governance design must match the decision cadence of the work: the slowest evidence and the fastest value-at-stake both set the rhythm, and a hybrid project needs both, with the seams explicit.

A word about the assistant that will draft your charter, your decision rights matrix, and your gate agenda in minutes, because it will, and the drafts will be useful. It will not notice that the adoption cell is blank: absence is not visible in fluent prose. It will not know which of your twelve members actually decides, which constraint is a preference in disguise, or whether the escalation path leads to someone with the authority to answer. Use it for the first draft and for the contradiction check across the charter and the matrix; verify every name, tolerance, date, and owner against the people who will be accountable, and keep patient data, staff records, and anything regulated out of any tool the organization has not approved for it. At Meridian that boundary is not theoretical.

Exercises and drills

1. A quick classification. Each of these comes from a real project. Is it an authorization gap or a governance failure? (a) The charter names a sponsor who cannot release money or resolve a dispute. (b) The steering committee approves every tranche without reading the gate evidence. (c) The escalation path is “tell the project manager.” (d) The operational ownership seat is occupied by the project manager. (e) The committee’s minutes list updates, questions, and adjournments, and the same item appears on three consecutive agendas.

(a) is an authorization gap: the sponsor seat is occupied in name only, and a sponsor without authority or money cannot sponsor. (b) is a governance failure: a gate that cannot reject is a ceremony. (c) is a governance failure: there is no path above the team’s ceiling, which means no decision machinery, only a bottleneck. (d) is an authorization gap: operational ownership must survive the project, and the project manager’s seat ends at handover by definition. (e) is a governance failure: meetings without decisions. The quiet lesson of the set: the two categories are the same disease at different scales, authorization without decision, in the charter or in the meeting room.

2. A charter audit. Take the last charter, project one-pager, or initiative brief you saw, or the Meridian sketch from this chapter, and audit six lines: the outcome line (is it a changed state with a measure and an owner, or an output list?), the exclusions (are there at least two explicit outs?), the constraints (are the non-negotiables distinguished from preferences?), the assumptions (does each have an owner and a review date?), the top risks (are they the sponsor’s risks, the ones that can kill the value?), and the seats (are all four filled, with the right occupants?). Write the two weakest lines and the decision that is missing because of them.

The drill succeeds when the auditor finds the line that is a paragraph instead of a decision. The classic weaknesses: the outcome line that lists deliverables, which means the success definition is still a bill of materials; and the seats line that names a committee, a role, or a “leadership team” instead of a person, which means the accountability question was avoided in the only place it had to be answered. A charter that survives this audit usually needed ninety minutes of argument to get there; that argument is the point.

3. A decision rights matrix. For a project you know, write five rows: the decision, the single decider, the inputs the decider must receive, and the band or trigger that defines the decider’s latitude. Then check the matrix: does every decision have exactly one decider? Is each decider the person with the knowledge and the accountability, or the person with the highest rank? Is there an escalation row for “anything above these tolerances,” and does it name who receives the escalation and by when?

The drill fails if any row names two deciders, or a committee without a named chair who owns the decision, or if the band cells are empty, in which case the matrix is a wish. A defensible matrix has at least one row where the decider is not the most senior person in the room, because the decisions that live where the work happens need the knowledge that lives there too, and routing them upward is how the committee’s agenda fills with questions the committee cannot answer well.

4. A decision room: the kickoff. It is month five at Meridian, and the authorization is in hand. The evidence: construction permits are ready; the platform team is staffed and funded for tranche one; the clinical workflow standard is undecided; the operational ownership seat is blank; the grant window runs for thirty-one more months; clinic one is planned for month twelve. Decide: ready, conditionally ready, or not ready, and if conditional, write the conditions with owners and dates.

Conditionally ready is the defensible answer, and the defense is the chapter’s argument in miniature: start the work that is ready, construction and the platform foundation, and gate the rest behind conditions with owners and dates, the adoption owner named within two weeks with the grant targets attached, the workflow standard decision scheduled within six weeks, the data migration plan within eight. Ready is wrong, because the blank seat is not a minor gap; it is the seat the grant pays on, and starting it all is how the first gate becomes the moment of discovery. Not ready is defensible only if the charter itself needs fixing, which here it does not; the charter can be amended at the kickoff. The unsafe move is starting everything because the window is running. The window is exactly why the conditions have dates: the grant punishes delay, so the delay must be bounded, not ignored.

5. The mastery drill. Meridian’s steering committee has twelve members, meets monthly, spends two hours on status updates, and postpones the only decision on the agenda for the third consecutive month. The clinical adoption owner is still unnamed. The grant window runs. Redesign the governance: write the decision rights matrix, the narrowed agenda for the next meeting, one escalation with its cost of waiting, the assurance seat and its reporting line, and the conditions you would attach to the next gate.

Judge the design on three tests. First, every decision has one decider with the knowledge and the accountability, and the matrix shows it. Second, the committee’s agenda carries decisions, exceptions, and forecasts, not updates; an agenda that still starts with eleven status reports has not been redesigned, it has been renamed. Third, the empty seat is filled with a name and the grant targets, because a redesign that leaves the adoption question unowned has rebuilt the furniture and kept the hole. Defensible variations get credit: the workflow standard could be decided by Nora with Hana as the authority, or by a joint pair with a named tie-breaker, and the assurance seat could be an internal auditor rather than an external reviewer, as long as the reporting line reaches the sponsor without passing through the project manager. The unsafe choices: leaving the decision to “the committee” or to “everyone involved,” and designing the assurance seat to report through Dana. The first recreates the meetings without decisions; the second gives the review the same motivated perception it exists to correct.

6. Transfer question. In the last project you were part of, who owned adoption after go-live, who could stop the work if the value died, and where was the escalation path? What did a decision cost when it waited, and who was charged for the wait?

The durable principle: authorization is a decision with names, and governance is the machinery that keeps those decisions alive, a one-page charter, four filled seats, decision rights, tolerances, designed escalation, gates that can reject, independent assurance, and a kickoff that says what is ready and what is conditional. The most common next failure is the one the Meridian signing committed in miniature: the charter and the governance are built and then treated as furniture, while the real decisions happen informally, so the project develops two governments, the written one and the actual one, and the tell is the meeting where the minutes and the outcomes diverge. The charter named the people who decide; the people the work affects are a far larger system, the stakeholders whose interests, power, trust, and history will decide whether the authorized project survives contact with the world, and that system is the subject of the next chapter, “Map the Stakeholder System.”

Notes

• Meridian Community Health Network is a composite case created for this book; no real network, grant, or region is depicted. The grant figures (250,000 units per clinic-month, a window closing at month thirty-six) are author-created teaching numbers consistent with the earlier Meridian chapters; the 375,000-unit cost-of-waiting figure follows from the arithmetic shown in the text, one and a half clinic-months at 250,000 units.
• ISO 21502:2020, “Project management: Guidance on project management,” the general ISO guidance, addresses the initiation of a project and project governance as core practice areas; this chapter’s charter and governance treatment is the author’s method-neutral synthesis, 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 account of the sponsor as a personally accountable senior responsible owner follows the current UK Cabinet Office Government Functional Standard GovS 002: Project delivery, which requires each project to have a named accountable owner and treats governance and assurance as core practices; readers should consult the current version on GOV.UK.
• The idea that decision rights should be paired with the specific knowledge needed to exercise them well is argued in Michael C. Jensen and William H. Meckling, “Specific and General Knowledge, and Organizational Structure,” Journal of Applied Corporate Finance 8, no. 2 (1995): 4-18, a reprint of the authors’ 1992 essay in Contract Economics (Blackwell). The governance-map logic here is the author’s application, not the source’s terminology.
• The practice of governing by deviation bands, sometimes called tolerances, appears in several guidance traditions, including PRINCE2 and other framework guidance; this chapter describes the general practice of explicit delegation boundaries without adopting any specific framework’s scheme, consistent with the book’s method-neutral rule.
• The gate idea in product development traces to Robert G. Cooper, “Stage-Gate Systems: A New Tool for Managing New Products,” Business Horizons 33, no. 3 (1990): 44-54; this chapter uses “gate” in that general sense while keeping the question set and the five options as the author’s own.
• The treatment of constructive disagreement in governance draws on Kathleen M. Eisenhardt, Jean L. Kahwajy, and L. J. Bourgeois III, “How Management Teams Can Have a Good Fight,” Harvard Business Review 75, no. 4 (1997): 77-85.
• The three-lines view of assurance is a widely used description of internal control roles; the current articulation is the Institute of Internal Auditors, “The Three Lines Model: An Update of the Three Lines of Defense” (2020). Projects rarely need the full apparatus; the chapter argues they always need an independent question with a reporting line to the sponsor.