They sound reasonable in the moment. They show up in steering committees and weekly reviews. Each one signals that the value delivery loop is about to break — six months before the failure shows up.
Most program failures aren’t technical.
The technical risks get tracked. They get named in steering committee. They get owners and mitigations. When a program ships clean and then quietly dies in the post-delivery phase, the cause is almost never something on the technical risk register. The cause is a handful of sentences that surfaced in meetings six to nine months earlier, sounded reasonable at the time, and were not treated as the diagnostic signals they actually were.
This post names the four sentences. Each one signals that a specific step of the value delivery loop — strategy, commitment, execution, measurement, narrative — is about to break. Each one is recoverable if caught at the moment it’s spoken. None of them are recoverable after the program ships.
The framework underneath is the value delivery loop: the discipline of treating delivery as a five-step loop rather than a three-step linear handoff. Most teams run a tight three-step loop and stop. The sentences below are the markers that show where they stopped.
Sentence 1: “Let’s circle back on measurement after launch.”
This sentence kills the measurement step of the loop.
It surfaces in pre-launch readouts when the program is in flight, the team is stretched, and the baseline document hasn’t been signed off yet. The sentence sounds like a scheduling decision. It’s actually a value capture decision. A baseline that gets pushed past launch will never get signed off, because by post-launch the team has moved to the next initiative and no one will defend a baseline they didn’t establish in real time.
The downstream consequence: in Q3 review, the program’s value can’t be defended because there’s no signed baseline. Every challenger gets to argue the improvement would have happened anyway. The value disappears not because it wasn’t real but because it wasn’t measurable.
The artifact that defuses this sentence is a signed-off baseline document at intake. Three to five paragraphs. Sponsor signature. Dated. The document is the contract between the program and the outcome. Without it, the outcome doesn’t exist in committee.
The moment to require this artifact is at program initiation, not pre-launch. Once you’re at pre-launch and the baseline isn’t done, the sentence will surface and the loop will break. The discipline has to be earlier.
Sentence 2: “We’ll find an owner for run-rate later.”
This sentence kills the post-launch measurement phase.
It surfaces in steering committee about six weeks before launch, when team capacity is being negotiated and the run-rate capture phase looks like operational overhead. The sentence sounds like a delegation decision. It’s actually an outcome decision. Run-rate capture without an owner doesn’t happen. The team ships, the team disperses, the run-rate flattens to zero by week six because nobody is responsible for it not flattening.
Eighteen months later, the program is described as “a project we did” — past tense, no run-rate attached. The sponsor cannot defend the program because there’s no current data to defend.
The artifact that defuses this sentence is a measurement cadence document, established before launch, with named owners through quarter four. The cadence specifies which numbers are reviewed, by whom, at what frequency, with what escalation path when the numbers move.
The owner doesn’t have to be the original BRM. It does have to be someone whose performance is partially measured against the cadence. If no one’s performance touches the cadence, the cadence is theater. It will lapse within two quarters.
Sentence 3: “The sponsor knows what we’re delivering.”
This sentence kills the narrative step of the loop.
It surfaces in pre-launch communication planning when someone asks whether a written narrative needs to be prepared. The sentence sounds like a confidence statement. It’s actually a misread of how executive memory works.
The sponsor knows the program in the moment. The sponsor does not know what to tell their peers about the program in twelve months when the question comes up. The sponsor does not know the language to use, the numbers to cite, the framing that would survive a skeptical peer’s challenge. The sponsor has been told all of this, repeatedly, but they have not been given the artifact that lets them repeat it accurately in a room you’re not in.
Six months after launch, the sponsor will be asked about the program by an executive who wasn’t in the room. They’ll improvise. The improvisation will be partially wrong, not because the sponsor is careless, but because no one ever wrote down the sentences that should have been repeated.
The artifact that defuses this sentence is a one-page narrative document, written by the BRM, updated quarterly. Three numbers, three commitments, three risks. The same artifact that anchors the trust balance sheet anchors the value delivery loop’s narrative step. One artifact, two frameworks.
The narrative is not for the sponsor. It’s for the people the sponsor talks to. Write it that way.
Sentence 4: “We can write the narrative after we see the results.”
This sentence kills the entire post-delivery phase.
It surfaces in pre-launch readouts when narrative work feels like premature optimization. The sentence sounds like a sequencing decision: let’s get the results first, then write about them. It’s actually an admission that the narrative will never be written.
The reason: by the time the results are in, the team is already shipping the next initiative. The sponsor has moved on. The original BRM is partially staffed against new work. The narrative would have to be written by someone who wasn’t present for the program, working from artifacts that don’t exist, in time stolen from the next quarter’s commitments. It doesn’t happen.
The narrative has to exist as a draft before launch. Then it gets revised against actual results in week six. Then quarterly thereafter. Drafting it before launch is the only way to make sure it exists at all.
The artifact that defuses this sentence is a narrative draft, written before launch, with placeholders for the actual numbers. The draft has the structure, the framing, the three sentences the sponsor will eventually repeat. Post-launch work is to swap in real numbers, not to invent the document from scratch.
Why these four sentences matter more than technical risk
A program with clean technical execution and a broken value delivery loop is a program that quietly fails. A program with technical issues and a tight delivery loop usually survives. The issues get surfaced, mitigated, and absorbed into the narrative. The framework that handles technical risk is mature. The framework that handles narrative, measurement, and ownership risk is less so, which is why the four sentences slip past steering committees that would catch any technical equivalent.
Each sentence is a diagnostic. When it surfaces, the failure mode it represents is already in motion. The fix is not to talk the sentence out of the meeting. The fix is to require the artifact that the sentence is trying to defer.
Four artifacts, all required before launch. None of them takes more than two hours to build the first version. All of them outlive the program by years.
Catch the sentences. Require the artifacts. Ship the outcome, not just the work.
The full loop, the artifact templates for each of the four sentences, and the steering-committee discipline that catches them at intake are in Deliver Real Value.