Everybody Did Their Job. So Why Did the Project Fail?
A project can fail even when every department completed its tasks. The deeper issue may be unclear ownership, missing authority and a system designed around activity rather than outcomes.

A team can be full of intelligent, hardworking people and still fail to deliver. The failure can sit in the gaps between their responsibilities.
Take this illustrative product-launch scenario. The designer finishes the screens. The developer delivers the application. Marketing prepares the campaign. Operations checks its own requirements. Each department has a completed task list, and the progress report is reassuring.
Then the launch date arrives. Nothing goes live.
Marketing is waiting for approval. The developer says the product was ready last week. Operations assumed somebody else was coordinating the handover. The manager wants to know who failed.
Everybody may be telling the truth. Each department completed what it understood to be its assignment, while the result depended on work that nobody clearly owned.
A task is not an outcome
A task describes an activity. An outcome describes the change or result that activity is meant to produce.
“Send the launch email” is a task. “Eligible customers can activate and use the product on launch day” is an outcome. Sending the message contributes to that result, but it also depends on working access, clear instructions, approval and support being ready.
A person can finish a task and still leave a critical dependency unresolved. If nobody is responsible for joining the pieces, the final result becomes vulnerable to gaps between departments.
That is what makes “Everybody did their job” an incomplete explanation. The assignments may have been defined too narrowly to produce the result.
How accountability disappears
The first warning sign is ambiguous ownership. Several people are involved, but nobody can answer a simple question: who is responsible for ensuring that this result happens?
The second is responsibility without authority. Someone is told to deliver an outcome but cannot approve the required changes, access essential information or resolve conflicts between teams.
The third is weak escalation. People encounter obstacles, but there is no agreed point at which a delay becomes a leadership decision. For example, a missing approval may sit for days because nobody knows who should decide or when to escalate it. The deadline then exposes a problem that was visible much earlier.
A fourth problem is measuring what is easy to count instead of what matters. Meetings held, messages sent and reports completed can create the appearance of movement. They do not prove that the underlying objective has been achieved.
In such an environment, defending individual activity becomes rational. People learn to preserve the evidence that they completed their part, even when the project is drifting away from its purpose.
Why more supervision is not always the answer
When an initiative fails, some managers respond by adding meetings, approval stages and reporting requirements.
Occasionally, stronger supervision is necessary. But if the real problem is unclear authority or a missing owner, additional reporting may simply document confusion more frequently.
The system must allow people to coordinate, resolve obstacles and make the decisions that delivery requires.
Three leadership decisions can make a considerable difference.
Give each critical outcome a clear owner. For a launch like this, name a person responsible for bringing the parts together and raising unresolved decisions. The owner needs support from contributors and leaders; the role should never become a convenient place to put all the blame.
Match responsibility with decision-making authority. If someone must deliver, specify what they can approve, what requires escalation and how quickly decisions should be made.
Build the handovers into the plan. Specify what the next person needs before they can proceed. “Development complete” is vague. “Operations has tested account creation and confirmed that support can resolve a failed login” gives the next team something concrete to accept or reject.
The leader's uncomfortable question
An organisation that regularly misses deadlines does not always have a motivation problem. It may have a design problem.
That does not absolve individuals who neglect their responsibilities. Accountability should still identify poor execution and address it. But good leadership distinguishes a person who failed to do agreed work from a system that never made the expected work clear.
A useful review asks who defined success, who owned the result and whether the team had the authority to act. It also asks when the first warning appeared and what prevented someone from responding.
When responsibility is distributed without clear accountability, failure can become everybody's experience and nobody's responsibility.
The remedy is not necessarily another motivational speech. Sometimes it is a more honest look at how the work was designed.
For more on how I approach decisions and examine problems, explore How I Think.


