A team can be busy all week and still finish almost nothing important.
That sounds harsh, but it happens constantly.
The project board is active.
Standups happen.
Tickets move.
Updates are posted.
People are clearly working.
And yet the same strategic initiative appears again next week with a slightly different status.
“Almost done.”
“Waiting on one thing.”
“Needs final review.”
“Nearly ready.”
The problem is often not effort.
The problem is that nobody clearly defined what done means.
Activity Is Not Completion
Software teams are especially vulnerable to confusing motion with progress because we have so many visible signals of activity.
Commits.
Pull requests.
Tickets.
Meetings.
Slack threads.
Deployments.
Issue comments.
All of that is useful.
But none of it guarantees that the business outcome is finished.
A project can generate enormous activity while staying permanently open.
For example:
Goal: Improve customer onboarding
That sounds reasonable.
But when is it actually complete?
- New flow designed?
- Backend updated?
- Frontend released?
- Team trained?
- Existing customers migrated?
- Old process retired?
- Reporting updated?
If nobody agrees on the answer, the initiative can stay “in progress” forever.
“Almost Done” Usually Means Something Is Still Undefined
When a project sits at 80% for several weeks, I would look for four things.
- An unresolved decision
Sometimes the team is not blocked by implementation.
They are blocked by a decision.
Which approach are we choosing?
What scope are we accepting?
What are we explicitly excluding?
Who has final authority?
Until someone answers those questions, work can continue around the edges without actually closing.
- An unmanaged dependency
A project may depend on:
another team
a vendor
data migration
security review
content
legal approval
leadership sign-off
Dependencies are normal.
The real problem is when everyone knows the dependency exists, but nobody owns getting it resolved.
Tracking a blocker is not the same as removing it.
- Scope that keeps moving
This one kills more projects than teams admit.
You get close to release.
Then:
“Since we’re already changing this, can we add one more thing?”
Then another.
Then another.
Each request may be reasonable.
Together, they destroy completion.
At some point, the team has to say:
This version is done.
The next improvement becomes new work.
Without that boundary, “done” becomes impossible.
- Shared ownership
Several people may own pieces of the project.
That does not mean anyone owns the outcome.
For example:
Engineering -> implementation
Product -> requirements
Ops -> rollout
Leadership -> approval
All of those responsibilities can be clear while the project itself still has no single owner.
Someone needs to own the finish line.
Definition of Done Is Not Just an Agile Concept
Developers already understand this idea in software delivery.
A ticket is not complete just because code exists.
Depending on the team, “done” may mean:
code complete
tests passing
review approved
deployed
documentation updated
monitoring confirmed
The same idea should apply to business initiatives.
Instead of:
Implement new CRM
define something like:
Done means:
- pipeline stages configured
- required integrations active
- existing deals migrated
- sales team trained
- reporting validated
- old workflow retired
Now the project has a real terminal state.
That changes the conversation completely.
Instead of asking:
“How far along are we?”
you can ask:
“Which completion condition is still false?”
That is a much better debugging question.
Think of Projects Like State Machines
A lot of unfinished work is really bad state design.
Teams often operate with something like:
Not Started
In Progress
Done
That is too vague for complex work.
A more useful model might be:
Defined
↓
Owned
↓
Dependencies Cleared
↓
Execution Complete
↓
Validated
↓
Closed
Each state should have a clear exit condition.
If the project cannot move forward, you should be able to identify exactly why.
For example:
state = "Dependencies Cleared"
blocked_by = [
"Finance approval",
"Production data migration"
]
That is more actionable than:
status = "80% complete"
Percent-complete numbers often create false precision.
The final 10% may contain the hardest part of the project.
The Last 20% Is Usually Where Coordination Matters Most
The first part of a project is often straightforward.
Design.
Build.
Implement.
Prepare.
The final stretch is where messy organizational work appears.
Someone needs to make a decision.
Another team has to finish something.
An edge case needs resolution.
Users need migration.
An old system needs retirement.
Someone needs to say no to additional scope.
That is why projects often move quickly at first and then slow down near the end.
The remaining work is less about production and more about closure.
Technical teams feel this all the time.
A feature can be “code complete” while still being nowhere near operationally complete.
Code merged != Outcome finished
That distinction matters.
One Person Should Own the Outcome
This does not mean one person does everything.
It means one person is accountable for getting the project to a closed state.
That owner should always be able to answer:
What does done mean?
What is left?
What is blocked?
Who owns each blocker?
What decision is waiting?
What is outside the current scope?
When should we close?
If nobody can answer those questions, ownership is probably too distributed.
This is especially common in cross-functional initiatives.
Everyone owns their contribution.
Nobody owns the result.
A Fractional Integrator Is Really a Closure Role
This is where an Integrator can be useful.
Not because the company needs more project-management ceremony.
The useful part is creating a reliable path from priority to completion.
Something like:
Priority
↓
Owner
↓
Definition of Done
↓
Dependencies
↓
Decisions
↓
Execution
↓
Validation
↓
Closed
The Integrator keeps asking the questions that stop work from sitting indefinitely in the middle.
What is blocking this?
Who owns that?
What decision are we waiting for?
Is this request required for this version?
Can we close this now?
That is less about adding management and more about reducing open loops.
Measure Carryover, Not Just Velocity
One useful operating signal is how often important initiatives carry over from one week to the next.
Some carryover is normal.
Persistent carryover is not.
If the same initiative appears every week, ask why.
Did scope change?
Is a dependency unresolved?
Is ownership unclear?
Is a decision missing?
Was "done" never defined?
That tells you more than another status percentage.
A project stuck at 90% for four weeks is not necessarily 90% complete.
It may simply be poorly specified.
Practical Checklist
Before starting an important initiative, define:
the business outcome
one accountable owner
the exact definition of done
known dependencies
decision owners
what is explicitly out of scope
the closure condition
During execution, ask:
What is still false in the definition of done?
What is blocked?
Who owns removing the blocker?
Has scope expanded?
Is the team executing, or waiting on a decision?
Can this version be closed now?
And when the criteria are met, close it.
Do not keep a finished project alive because someone has another idea.
Create the next piece of work separately.
The Real Problem Is Too Many Open Loops
Growing companies usually do not need more activity.
They already have plenty.
What they need is a stronger ability to convert activity into finished outcomes.
That requires a clear finish line.
One owner.
Explicit dependencies.
Resolved decisions.
And the discipline to say:
This is done.
I wrote a longer version of this idea here: Your Team Is Working on It. So Why Is Nothing Ever Actually Done?
