Six signs your project will fail

Project 'failure' is political. It's about power. People with power get to define budgets and deadlines, to approve specifications, to assign teams. Thus they define the boundary between success and failure. Go outside the boundary, and your project fails.

The problem with politics is that it fuzzes our vision. We tend to see what we want to see rather than what's really going on. That means we miss the early signs of failure.

And that, of course, increases the risk of catastrophic failure. If you spot the early warning signs, you have time to fix things before they become critical, before problems propagate. Miss those signs, and you sail blithely across the boundary of failure, never to return.

So it'd be nice to have some clear indicators that my project is heading into trouble. I can't give you a magic formula, but here are some of the signs that make me nervous:

1. "Failure is not an option"

When someone says 'failure is not an option', most people hear 'don't talk about potential failure modes'. That cuts us off from information about risk. It means we don't hear about problems that people are having.  

It almost guarantees that small failures are going to grow and accumulate before we hear about them.

Failure stays beneath the surface until it's so large it can no longer be hidden. When it emerges, it's too large to mitigate.

2. "Don't bring me problems; bring me solutions"

This is very similar. If I've got a problem and I don't know how to solve it, what am I supposed to do with it?  Hide it and hope it'll go away? That's what this phrase says.  When I hear it, I start looking for hidden problems.

(Sometimes, people do escalate problems too quickly. This often happens because they're scared of being blamed if they pick the 'wrong' solution. In that case, this phrase is a sign of a blaming culture.  And again, the organisation's projects almost certainly have hidden problems.)

3. "I'll do my best"

When a developer says this, typically after losing a negotiation about the time needed to do something, it generally means: "I don't think I can do this, but I can't admit that.  I can at least make sure no-one blames me for not trying hard enough".

Most people try to do their best most of the time. If they need to say they'll do it, there's probably something wrong.

4. "I haven't got time to think"

It's amazing how often I hear this. Often from people who regard themselves as 'knowledge workers'. How do you create knowledge without thinking?

Our projects rarely fail for lack of physical effort – it's lack of clear thinking that kills them. Yet our organisations load us with so much work that people spend all their time running around doing stuff, with no time to step back and think about what they're doing.

If you're not taking some quiet time to think things through occasionally, your project is at serious risk of failing.

5. "We'll sort out the quality later"

Are you cutting corners? Building quick-and-dirty features, with a promise that you'll come back and tidy them up later? Avoiding discussions with stakeholders because they'll open up too many issues?

Sometimes this buys you a little time in the short term. Often it doesn't even do that – quality problems often hit you a lot sooner than you expect.  

Then you have all the costs of dealing with operational failures, handling disgruntled stakeholders, etc, as well as the costs of reworking the original deliverables.

6. Too many projects

This is a problem at just about every organisation I know. Rather than say no, managers commit to a portfolio of projects that far exceeds the capacity of their teams.

This kills projects in several ways. People waste time context switching between projects. Work products 'decay' over time (requirements get out of date, technology platforms are superseded, bugs are a lot harder to find long after the code was written. etc), so we waste time on rework. Coordination overheads explode.

And the biggest failure: when we spread our resources too thinly, we ensure that our most important projects will be starved of resources.

Stop pretending

None of these is an absolute guarantee of failure. Sometimes, for example, it's OK to say 'failure is not an option' – a startup's bet-the-company project may well need to commit everything to the one small chance of success.  

But in this case we're engaging with known risks, not pretending that risk doesn't exist.

It's the pretence that kills projects. All of the above signs suggest that someone is avoiding reality. They don't want to know that risk exists, that some problems are hard to solve, that there's a limit to the team's capacity, that simple models don't always apply in messy situations.

Projects begin to fail when we lose touch with reality. The above signs suggest this is happening on your project. If you notice them, start looking for failure.