How do you make a project fail?
Studies from companies like IBM have shown that up 60% of projects in organisations fail. A staggering number, in fact it’s a wonder anything gets done at all.
However, if we analyse the reasons why these projects fail, we can see there are some common mistakes that if we were to deliberately sabotage a project then this is how you do it.
1. Never have a reason why
Don’t think about why you are doing a project just be grateful you’ve thought of something to do. Every bright idea should be actioned upon regardless of whether it helps the organisation or not.
This will stop all those people screaming at us for not doing anything. After all, why look at how desirable a change is? Can’t remember the last time somebody finished something, and we looked at it and said “Why did we do that?”
It must work, we put so much effort into it and it cost us a small fortune to pay for it so make it work. Don’t start moaning about the fact that you’ve lost sales or productivity has plummeted by 50%, you paid for this so you had better use it.
No one wants to hear about your problems either whether you have actual issues or ones you just might think will happen. Everything is doable, nothing is impossible, technology answers all our questions.
Strategy is for losers, action is for heroes, never think of why you want a change, the return you get on investment or whether the change itself is achievable.
2. Ignore the past
What can history teach you anyway?
That’s done, its in the past so forget it.
Every project you have is unique so it’s a waste of time using your past experiences to guide you round the pitfalls on this one. I’m not just talking about personal experience either, don’t waste time listening to what happened on other projects in your organisation.
Never research outside the organisation. What could possibly have happened on similar projects elsewhere that can help you on this one?
While you are doing your current project don’t waste your time recording what has gone well or not so well. It’s not like you would want to continue doing the good things or correcting the errors you’ve made.
We are all perfect all the time.
3. Keep the team in the dark
People love surprises.
Just look at the joy on somebody’s face when you give them a present they were not expecting.
So why tell people about anything? It’s much better to keep them in the dark and surprise them.
Project teams should be handled in the same way to keep up morale and enthusiasm. For starters don’t tell anybody what you are expecting them to do on the project. Everybody naturally knows this anyway. Besides, somebody will eventually do something if you leave the task hanging around long enough. It’s not as if nobody ends up doing it.
Much the same attitude goes to communicating other project information as well. It’s all top secret until release so why bother identifying anyone who needs to know anything. This saves so much time compiling all those progress reports if we don’t have to send them to anybody. It’s not like we would listen to them anyway as we are carrying on regardless (see sin 1).
4. Once started, always finish
No project should ever review itself and nobody should ever question it’s existence once started.
Just crack on and deliver it, why would you ever question that decision? Nothing ever changes that could cause you to question what you are doing so you wouldn’t want to have key decision points defined in the project where you would do some kind project review and go/no go decision.
This would only cause more administration as you would have to do smaller, more accurate plans for what is happening between these decisions. You would have to update information to show the continuing viability of the project and whether it can still be achieved.
Look, you took this decision over 3 years ago and obviously nothing is ever going to change in your organisation or outside that could possibly effect the project so stop wasting time reviewing it and get it done.
And also that project plan you put together doesn’t need adjusting because there would not have been any resource adjustments over the last 3 years or any impacts on the timeframe, scope or quality requirements.
5. Micromanage wherever possible
Nobody likes being left on their own to work, everybody loves to have someone watching over their shoulder the whole time directing their each and every move. Beside which you are keeping everyone in the dark anyway (sin 3) so no ones going to know what to do, so no point leaving them on their own.
People don’t want to be responsible for their own decisions as they are fearful of making the wrong one.
Much better to keep running backward and
forward to somebody in management to make every decision for them, after all that’s what management is for.
Management will have to drop everything on the operational side of the business to cope with all the requests coming from the project. That should be ok as the business operation has been in place for decades so can look after itself.
Nothing ever goes wrong there.
Don’t just sit there planning, get on with it!
Action, action, action!
Everybody knows that action creates work that creates output.
Never mind what the output should look like, what it can do or who will benefit from its use. Just do something to create some.
Seriously, why would you want to think about the finished article? Just go and build it.
There is no value at all in having even the slightest clue about the components, features or quality standards that need to be delivered or adhered to.
It’s not as if this would help identify the skills needed to create the output or quality check it, or even if we had these skills in our organisation to start with. Quality is waste of time anyway as we all know, we are all perfect all the time so everything we build is perfect so no need to quality check it.
7. Keep doing it this way
Never take an individual project context into consideration and adapt working methods to it.
The business case template is 200 pages long so it shouldn’t matter whether you’re building a new shopping centre, IT system or garden shed. The business case is 200 pages long.
This will make sure that the high levels of administration needed to stick rigidly to our project framework is maintained consistently across all projects regardless of size or type.
Only by causing this amount of work can we maintain the high staffing levels required to move the paperwork around instead of deploying these people into more productive tasks.
Moment of reflection
Thank you for making it this far and reading this list. It’s by no means meant as an exhaustive list and as you have been reading it you may have some other examples of project failure come to mind.
I have written it in the hope that you will keep them in mind when managing your current or future projects. Its been compiled from many lists put together by learners on project management courses over the years. The exercise is to compile a list of 10 reasons for project failure and I cannot tell you how many times that list has stretched to 11,12….15 and more!
At the very top I quoted a figure of 60% failure rate on projects which would indicate quite a poor conversation rate. All is not lost though as the alternative figure to this is that projects being governed by a robust methodology have an 80% success rate.