The Task That Belonged to Everyone
- 4 days ago
- 9 min read
A small scope item was accepted, assigned to “the team,” and carried politely through the project until everyone discovered that nobody owned it.
By D.B. Trench
Scope Creep Month on PMTales
Week 3: Ownership Drift
This is Week 3 of a four-week field series on how small asks, soft agreements, and helpful little sentences quietly rewrite the plan.
Week 1 covered early drift. Week 2 covered hidden impact. This week is about ownership drift — the moment a task becomes “the team’s” problem and begins vanishing in plain sight.
The new requirement arrived carrying pastries.
This was the first warning sign.
Not because pastries are dangerous. Pastries are innocent. Pastries have never personally damaged a project plan.
But pastries do tend to appear in meetings where someone needs the team to feel cooperative before asking for something that should have been raised six weeks ago.
The sponsor opened the box, smiled at the project team, and said, “Before we get started, there’s one small thing we should add.”
The project manager looked at the pastries.
Then at the sponsor.
Then at the agenda, which had not consented to this.
The small thing was a new onboarding checklist for managers.
Nothing fancy.
Just a one-page guide explaining how to use the new intake process once the system went live.
Simple.
Helpful.
Honestly, probably necessary.
That was the problem.
Bad ideas are easier to defend against. They arrive making noise and leaving fingerprints.
Useful ideas arrive wearing sensible shoes and saying things like, “This will help adoption.”
And this one would help adoption.
Managers were going to need something clear. The intake process had changed. The system screens had changed. The approval path had changed. People who had been ignoring the project for three months were absolutely going to wake up after launch and ask why nobody had told them what to do.
So the project manager did not say no.
She asked, “Who owns the checklist?”
There it was.
The question that could have saved everyone.
A clean question.
A fair question.
A question with excellent posture.
The sponsor waved one hand gently, as if ownership were a minor atmospheric condition.
“The team can handle it.”
Three heads nodded.
One business analyst wrote something down.
The change lead said, “We can probably pull from the training material.”
The operations lead said, “We should make sure the steps are accurate.”
The product owner said, “It should align with the release notes.”
The project manager wrote in the action log:
Create manager onboarding checklist — Owner: Team — Due before launch.
That was the second warning sign.
Not the checklist.
The owner.
Team.
Team is not an owner.
Team is where ownership goes when nobody wants to make eye contact with accountability.
The Checklist Enters the Mist
For a week, nothing happened.
This is normal for tasks assigned to everyone.
They do not fail immediately. That would be too helpful.
They hover.
They appear in meeting notes.
They receive encouraging phrases.
They are “on the radar.”
They are “being discussed.”
They are “in progress” in the spiritual sense.
At the next project checkpoint, the project manager asked, “Where are we with the manager checklist?”
The business analyst said, “I thought Change was drafting the first version.”
The change lead said, “I was waiting for Ops to confirm the actual steps.”
The operations lead said, “We need Product to confirm what’s in the release.”
The product owner said, “I thought the BA was pulling that together.”
The checklist sat in the middle of the table, invisible and thriving.
Nobody had refused the work.
Nobody had accepted the work.
The task had achieved its purest corporate form: widely supported, completely unowned.
The project manager closed her laptop halfway.
This is a move experienced PMs know.
Not dramatic.
Not angry.
Just enough motion to signal that the meeting has reached the part where optimism will be asked for identification.
“Okay,” she said. “Let’s stop passing the checklist around like a cursed envelope. Who is drafting it?”
Silence moved professionally through the group.
The sponsor checked the pastry box.
Empty.
Naturally.
Everyone Had a Reason
The business analyst could not own it because the checklist was user-facing, and user-facing language belonged with Change.
Change could not own it because the steps had to be operationally accurate, and accuracy belonged with Ops.
Ops could not own it because the process was system-enabled, and system behavior belonged with Product.
Product could not own it because the checklist was not technically part of the product backlog.
The sponsor could not own it because sponsors do not own checklists. Sponsors request them, bless them, and then ask whether they are ready.
Everyone was correct.
This made the situation worse.
A project does not need everyone to be wrong in order to get stuck.
Sometimes it gets stuck because everyone has a defensible reason to stand six inches away from the work.
That is how ownership drift happens.
Not through laziness.
Not through sabotage.
Through reasonable boundaries that do not meet in the middle.
The task falls between them.
Then the project manager is expected to retrieve it from the floor with a smile.
The Task Grows While Looking Innocent
The checklist was supposed to be one page.
That was the original phrase.
One page.
A phrase that makes people feel safe because they can picture it.
Unfortunately, the first draft was not one page.
It was three.
The change lead had added context because managers needed to understand why the intake process changed.
Ops had added exceptions because managers were going to ask about urgent requests.
Product had added screenshots because the system labels were not obvious.
The BA had added a decision tree because people kept confusing intake with approval.
The sponsor had added a note about strategic alignment because apparently the checklist needed to believe in something.
The project manager stared at the document.
It had become a small manual.
Still useful.
Still reasonable.
Still not in the plan.
That is the special danger of helpful work. It does not look like damage while it is happening.
It looks like quality.
It looks like stakeholder care.
It looks like the team being responsive.
Until someone asks who is reviewing it, who is translating it into training language, who is validating the screenshots, who is approving the final version, and whether it needs to be posted somewhere before launch.
Then the one-page checklist turns around and reveals a backpack full of dependencies.
The Deadline Makes a Noise
Launch was still twelve business days away.
This created false confidence.
Twelve business days sounds like time.
It is not always time.
Sometimes it is just a calendar wearing a mask.
The training deck was already locked.
The release notes were being finalized.
The support mailbox scripts were waiting for approval.
The communications email had been drafted, reviewed, revised, re-reviewed, and placed gently in the ceremonial folder labeled FINAL_v6_ACTUAL_FINAL.
The checklist touched all of them.
Of course it did.
New work rarely travels alone.
It brings cousins.
The project manager opened the RAID log and created an issue:
Manager onboarding checklist lacks clear owner, review path, approval route, and delivery plan. Potential impact to launch readiness and stakeholder adoption.
This sentence was not popular.
Good issue statements rarely are.
They remove fog from places where people were enjoying the fog.
The sponsor replied, “Is this really an issue? I thought we all agreed it was needed.”
The project manager took a breath.
Not the deep cinematic kind.
The practical kind.
The kind you take before saying something calm that might ruin someone’s preferred version of events.
“We agreed it was useful,” she said. “We did not agree who owns it, what it displaces, or what has to change to include it before launch.”
There it was.
The line between agreement and commitment.
Most project chaos lives there.
The Ownership Meeting
The project manager called a short meeting with a rude title:
Manager Checklist Ownership Decision
No “sync.”
No “touchpoint.”
No “alignment conversation.”
Ownership Decision.
A title with shoes on.
The agenda had five lines:
Confirm whether the checklist is required for launch.
Confirm the accountable owner.
Confirm required contributors.
Confirm review and approval path.
Confirm what moves if this is added now.
This is where the task began to lose its magical properties.
Work behaves differently when named.
The sponsor confirmed the checklist was required for launch.
Fine.
Then it needed an owner.
The change lead became accountable for drafting and final delivery.
Ops became the process validator.
Product became the screenshot and system-behavior validator.
The BA became the definition checker.
The sponsor became the approver.
The project manager became the person who wrote all of this down because civilization is fragile.
Then came the tradeoff.
The checklist could be completed before launch, but the final training deck update would move by three days, and the support scripts would need one additional review cycle.
The launch date could hold only if the sponsor accepted the reduced buffer.
There was a pause.
The sponsor did not love the word reduced.
Sponsors rarely do when it stands near buffer.
But the work was now visible.
It had a name.
It had an owner.
It had contributors.
It had a cost.
The sponsor approved the tradeoff.
Nobody clapped.
Nobody should clap for this.
This is not victory music.
This is project hygiene.
Necessary. Unromantic. Best done before something smells expensive.
The Checklist Gets Delivered
The checklist was finished two days before launch.
It was two pages, not one.
This was accepted as a reasonable compromise because reality had been allowed into the room under supervision.
Managers got the guide.
The support team got updated scripts.
The training deck matched the final process.
The release notes did not contradict the checklist.
No one from operations sent an email after launch beginning with, “Just to clarify…”
This was considered a win.
A quiet one.
The kind project managers usually get.
Not the kind where someone thanks you for preventing a problem they never saw.
The sponsor later said, “Glad the team pulled that together.”
The project manager smiled the professional smile of a person who had personally wrestled the word team into a table with names beside it.
What Actually Happened
The checklist did not almost fail because people were careless.
It almost failed because everyone agreed with the idea before anyone owned the work.
That is a different problem.
A more common one.
A more dangerous one.
Unclear ownership lets scope creep hide in goodwill.
People say yes to the value.
They nod at the need.
They assume someone will handle it.
Then the work drifts from person to person, picking up assumptions, edits, dependencies, and quiet delays.
By the time the project notices, the task is no longer small.
It is late.
And late work has a way of becoming urgent work, and urgent work has a way of becoming everyone’s problem, which is how we got here in the first place.
The PM Move
The project manager did not save the checklist by being difficult.
She saved it by refusing to let “the team” remain the owner.
That is the move.
Not dramatic.
Not heroic.
Not particularly fun at parties.
But useful.
When someone says, “The team will handle it,” ask:
“Who is accountable for the first draft, who contributes, who approves, and what moves if we add it now?”
That question will not make you universally beloved.
Few useful questions do.
But it will keep work from entering the project as a cloud and leaving as a delay.
And that is the job.
Not to stop every helpful idea.
Not to protect the plan like it is a museum artifact.
But to make sure every new commitment has an owner, a cost, and a place to land.
Because the task that belongs to everyone eventually belongs to nobody.
And nobody has terrible follow-through.
Field Notes from D.B. Trench
“The team” is not an owner.
It is a hiding place with a distribution list.
A task becomes real when it has:
one accountable owner
named contributors
a review path
an approval point
a visible tradeoff
If those five things are missing, the work has not been assigned.
It has been released into the hallway.
And the hallway is undefeated.
Free Field Tool
Scope Creep Early Warning Sheet
A 2-page PMTales field sheet for spotting hidden change before it becomes “already agreed.”
Use it when a “small” request has been accepted, but nobody can clearly say who owns it, what it touches, or what moves.
Inside: 10 early warning signals, a quick “discussion or decision?” test, a mini drift tracker, tradeoff prompts, and calm scripts for naming change early without making the room defensive.
Free PDF · 10 warning signals · Drift tracker · Tradeoff prompts · Calm scripts
Need Stronger Scope Guardrails?
Scope Defense Bundle
The Scope Defense Bundle turns “small asks” into clear decisions, visible tradeoffs, and written follow-up before the project quietly absorbs the work.
It includes the Start Here Guide, Weekly Scope Review Sheet, Change Impact Snapshot, Boundary Scripts Pack, Escalation Brief Template, Scope Drift Tracker, Tradeoff Log, and Complete Print Workbook.
Fillable PDFs · Printable PDFs · Excel trackers · Complete workbook
Story Route
Want the longer field tale?
The Scope Creep book follows the disaster pattern of small asks, soft agreements, harmless language, and the quiet rewrite of the work.
Coming Field Reports
Scope Creep Month continues with tradeoffs, boundaries, and the deadline that did not move.
After this series, PMTales moves into meeting fog, stakeholder pressure, status theatre, delivery confidence, and the rest of the project chaos ecosystem.
Comments