{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.


That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.


Sorry about this, there is a problem with our search at the moment.
Please try again later.

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.

Graham Oakes

Published 16 September, 2013 by Graham Oakes

Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is contributor to Econsultancy.

43 more posts from this author

Comments (3)


Jim Roberts

Have heard all of these at one time but you missed my favourite phrase 'Just do it', which often means do not plan just get the job done and we will work out a structure later. The idea is to get things done quickly, but nearly always results in a longer timescale or a repeat of work.

about 3 years ago


Bernie Stewart

One of my favourites is from my husbands workplace, "There's never enought time to do it properly but always enough time to do it again!" So true if you don't get the planning right and be realistic about what you expect to achieve.

about 3 years ago

Guy Redmond

Guy Redmond, Digital Marketing Engineer at Nestle

The problem with "projects" is they are often a one off and we don't know what good looks like, so we are not aware of the potential risks.
We need to learn to accept "failure" and learn from it, but also, be flexible in the approach.

I used to hear "Work Harder and Longer" and “We’ll sort out the quality later”

"Studies on project failure are easy to find and make depressing reading. Gartner studies suggest that 75% of all US IT projects are considered to be failures by those responsible for initiating them. But what do they mean by failure?"

almost 3 years ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.