Most improvement projects do not fail because the idea was bad.
They fail because nobody was ever truly in charge.
There is a pattern that repeats itself across organisations of every size and industry. A problem is identified. Energy builds. A project kicks off. And then, somewhere between the first meeting and the third, things start to blur. Who is making the decisions? Who owns this now? Why are we getting conflicting feedback from two different stakeholders? Why has this been in review for six weeks?
The answer, almost always, is the same: ownership was never defined.
Why ownership matters more than anything else
When a project has unclear ownership, everything downstream suffers. Conflicting business logic creeps in, because two people are each making decisions as if they are in charge. Timelines slip, because nobody has the authority to call a hard stop on scope. Feedback contradicts itself, because everyone feels entitled to redirect the work.
The project does not fail dramatically. It just slows down. Then slows down more. Then quietly stops.
This is not a people problem. It is a structural one. And it is entirely preventable.
The format that stops projects from dying
Over time I have landed on a consistent structure that every initiative needs before a single line of work is produced. Not because bureaucracy is good, but because ambiguity is expensive. The few hours it takes to answer these questions saves weeks of rework later.
1. Clear ownership from initiation
Before anything else, you need to know: who requested this and on whose behalf? Who is leading the project? Who is leading the build or implementation? And, critically, who is the single decision maker when there is disagreement?
This last question is the one most teams skip. They define the team but not the tiebreaker. That is the gap where projects go to die.
Every initiative needs a named requester, a named project lead, a named implementation lead, and a named decision maker. These can overlap. But they must be explicit.
2. Clear goals and business logic
Why does this project exist? What is the current process, and what specifically is broken about it? What does the improved state look like, not in vague terms, but in concrete ones?
This is where a lot of improvement projects get soft. They start with a feeling: "this is inefficient," "stakeholders are unhappy," "we can do better." And they never translate it into a specific, falsifiable goal. If you cannot describe the current state and the target state in two paragraphs, the project is not ready to start.
Business logic must be documented before development begins. Not because it will never change, but because it gives every future decision a reference point. When someone proposes a change mid-project, you can ask: does this serve the original goal? If nobody can remember what the original goal was, the project has already lost the thread.
3. Clear feedback guidance, structure, and deadlines
Feedback is where most well-intentioned projects go sideways.
Not because people give bad feedback. Because nobody defined what good feedback looks like, or when it is due, or who owns making sure it actually happens.
Before feedback is requested, you need to answer four questions: what specific information are we asking for? In what format should it be given? By what date is it required? And who is responsible for chasing it down and consolidating it?
Open-ended, undated, unstructured feedback loops are where projects lose months. Someone gives feedback in a Slack message. Someone else gives contradicting feedback in a meeting. A third person gives no feedback at all and later objects to the outcome. None of this is malicious. All of it is avoidable.
The person who owns the feedback process is accountable for making sure the right input arrives in the right form by the right deadline. That person needs to be named.
4. Clear success metrics, MVP, and post-development ownership
The final gap, and the one that causes the most pain after launch, is failing to define what done looks like.
What does success look like, and how will we measure it? What is the minimum viable version of this project, the thing we must ship before we can call it complete? And once it ships, who owns it?
That last question matters more than most people realise. Projects that ship without a named owner tend to degrade quietly. Nobody maintains them. Nobody iterates on them. Nobody is accountable when they break. The work that went into building them slowly becomes irrelevant.
Post-development ownership is not an afterthought. It is part of the project brief.
What happens when you skip the framework
The failure modes are predictable.
Skip ownership clarity and you get conflicting decisions and political deadlock. Skip business logic and you get a project that ships but solves the wrong problem. Skip feedback structure and you get scope creep, missed deadlines, and stakeholders who feel unheard. Skip success metrics and post-launch ownership and you get a project that ships once and is never touched again.
Each gap on its own is survivable. All four together, which is more common than you would think, and the project is almost certainly going to stall or stop entirely.
The uncomfortable ask
Adopting this structure requires something that organisations resist: naming people. Not teams. Not roles. People.
It is uncomfortable to say "this person is the decision maker" because it implies that other people's opinions carry less weight. That discomfort is real. It is also exactly the clarity that allows work to move.
Consensus is not the same as ownership. You can involve many people in the process and still have a single person who is accountable for the outcome. The best-run projects do exactly that.
The point
If you are running improvement initiatives and they keep stalling, look first at ownership. Not at the idea, not at the team, not at the timeline.
Unclear ownership is not a symptom. It is the cause.
Define who owns what before the work begins. Everything else gets easier from there.
Written by
Martin Dimoski
Senior R&D Executive & AI Systems Builder