Projects fall apart over the definition of success

Projects rarely fail due to technical issues. In twenty-five years I can think of very few examples.

When projects unravel, it is normally time that gets blamed first. “We didn’t have enough time.” It is the most socially acceptable explanation available: “it was impossible” - it implicates nobody in the room and everybody can safely agree with it.

But it is rarely the real story. The real story is usually that nobody took ownership of where the project was heading - nobody took responsibility and took the time to understand what success looked like.

What did the client actually want? What is the client trying to achieve? What is the underlying purpose for the project? Know these things and I find you can pivot any project out of any issues. But if it is not captured, then how can you know how to successfully tap the tiller and keep the boat on course?

A successful project is more than the sum total of a hundred actions. Over the years I have seen too many projects where people have pushed decisions down the line. A key piece of scope is never defined, or remains poorly understood until it lands in a ticket for an engineer. I have been on the receiving end of these tickets - months of preceding client meetings have failed to define the approach or problem, and the engineer is left holding a vague set of hopes and dreams loosely disguised as Acceptance Criteria.

The excuses are often honest, and frequently correct. The client didn’t communicate a clear vision. Nobody was quite sure what to do here. But that is exactly where trust starts to erode, because when a team doesn’t understand what it is building, it also doesn’t know when to stop.

If the team don’t know what the project priorities or goals are, then they don’t know which are the right compromises and end up escalating (or worse, guessing) on every micro-decision.

AI exacerbates rather than solves this problem. When building was slow, an unclear definition of success could reveal itself gradually and there was time to course correct. As building speed increases, it means you simply arrive at the wrong destination sooner.

Without a shared definition of success, you are relying on luck. You are hoping it lands rather than knowing it will, and hope is not a delivery methodology.

Without a shared definition of success, you are relying on luck.

Here is the test I use: ask the project team, separately, to tell you in one sentence what success looks like, without looking anything up. If you get different answers, you have found your risk, and you have found it while there is still time to do something about it.