The Deliverable That Wouldn’t Die (Vol. 1, Issue 9)
- D.B Trench
- Dec 29, 2025
- 3 min read
Excerpt:
This week’s dispatch tells the story of a deliverable that survived reviews, rewrites, re-scoping, and three separate approvals—yet somehow refused to stay “done.”
A short tale about shifting expectations and the strange immortality of unfinished work.
Full Issue:
Some deliverables in Deliveria simply refuse to die.
You can revise them, approve them, publish them, archive them, ritualistically bless them, and even send them to governance…
…and they still crawl back onto your desk like:
“Hi. Just one more update.”
Today’s dispatch is about The Deliverable That Wouldn’t Die—the undead creature that haunts every PM at some point in their career.
A Tale from the Trench
The deliverable in question was a design document. Clean, structured, beautifully formatted— borderline majestic by project standards.
The team reviewed it. The architect approved it. The sponsor signed it. Governance nodded gracefully.
It was done. Done in the official sense. Done in the spiritual sense. Done—capital “D,” period, end of story.
Until one morning, a stakeholder sent an email:
“Quick question about Page 14…”
Never trust Page 14.
Page 14 is where deliverables go to become immortal.
The question led to an edit. The edit led to a revision. The revision led to another review. And suddenly “done” wasn’t done anymore.
Two weeks later, the deliverable had been:
approved three times
reviewed by people who shouldn’t have been involved
modified in ways no one requested
and updated to reflect decisions that weren’t made yet
It was now less a document and more a living organism—mysterious, evolving, hungry.
Why Some Deliverables Never Die
The immortality of certain deliverables is never about the document itself.
It’s about the unresolved conversations underneath.
The document becomes:
a placeholder for clarity that hasn’t been achieved
an artifact people keep editing instead of deciding
a negotiation tool
a political shield
a comfort mechanism
a proxy for alignment
a target for everyone’s anxiety about “getting it right”
Deliverables don’t resurrect themselves. Uncertainty resurrects them.
Survival Lesson #9: Declare the Type of “Done”
The word “done” has at least four meanings in a project environment.
If you don’t clarify which one you mean, the deliverable will haunt you forever.
Done (Draft): We completed a version. It will definitely change.
Done (Reviewed): People looked at it. They’re nervous but silent.
Done (Approved): People signed it. They may still regret it.
Done (Frozen): It cannot change without formal rework or escalation.
If you don’t state which “done” you’re delivering, someone else will quietly downgrade it.
A PMTales Insight
Here’s what I’ve learned:
A deliverable only dies when the conversation it represents is complete.
If people still feel:
uncertain
exposed
confused
pressured
unheard
or politically vulnerable
…the deliverable will resurrect itself.
Not because the document needs to change, but because someone’s emotional state hasn’t.
How to Put a Deliverable to Rest (Mostly)
Try this line in your next review meeting:
“Let’s align on whether we’re changing the document or changing the decision.”
Half the time, people don’t want to update the document. They want to revisit the decision the document records.
Naming that distinction breaks the undead cycle.
Or at least slows it down.
From the PMTales Armory
If your deliverable keeps coming back from the grave:
Creature Card - Perfect for naming the subtle shifts that reanimate old work.
Field Note of the Week
A deliverable’s life cycle is not linear. It loops. It spirals. It revisits you in the night.
But once you learn to separate the document from the alignment it represents, you stop fighting the paperand start guiding the people.
That’s when you finally break the curse.
(Or at least reduce it to annual hauntings.)
Until Next Week
May your deliverables stay dead, your approvals hold, and Page 14 remain quiet.
See you in the trench,
D.B. Trench
Comments