Why do IT Projects fail? Project Managers reel out a million reasons and excuses. But in my years of working in projects, whatever the size or budget, there are 10 reasons why failed projects end up that way. (Maybe you know more? If you do, please share them!)

1. Too Many Parallel Activities into One Completion Date

Project deadlines are not like train stations. Activities of a project are rarely, if ever, allocated their own line in which they have no dependencies on others. The more parallel activities on a project, the greater the inter-dependencies and it is these that cause confusion and delay. Parallel activities often are part of a critical path and each activity must complete on time, on budget and without overstepping the dependencies identified during the planning phase. But this never happens. Task interdependence is always under-estimated! My preference is to structure a project into a long series of intermediate deliverables where each activity can bank its history and reduce interdependence. If too many interdependencies exist, then re-cut the plan to reduce them.

2. Planning for Perfection

This is the fools gold of Project Management – the perfect plan. Plans work if nothing changes, including the delivery of the plan itself. Plans are an approximation and forecast of the future . But business and people are naturally chaotic – there are always factors that complicate things. Projects fail when Project Managers assume that nothing will change other than what their plan will change. But a plan doesn’t account for everything that will change, so it is inherently flawed. My advice, have a solid plan for no more than a month, a strong plan for up to 3 months and have statements of intent for the remainder, as that’s the best they will be. Wrap these up into whatever words the stakeholders are happy with, but don’t waste too much time gazing into a crystal ball.

3. Too long

Linked to above point. Projects are often way too long! Human nature is curious; according to boffins, humans will only really start working hard on a project until 50% of the time allocated to it has elapsed . Sounds implausible, but think about projects you’ve worked on and you’ll know this to have some truths. Also linked to point 1, long projects should be broken down into phases, where the results of a phase can be banked and, if you’re savvy, deliver business value as they stand. This is the art of turning a plan into a strategy.

4. Too Many Managers – Not Enough Delivery

Too many Chiefs, not enough Indians is perhaps an outdated phrase nowadays, but it fits here. Why is it that organizations feel that adding more management helps delivery? Delivery people help delivery. OK, not enough managers is a problem too. But too many managers is also bad, if not worse, because this creates too much cost overhead as well as a line structure that dis-empowers people from delivering.

5. Scope Rigidity

Too many projects are constrained by initial commitments of scope. Project sponsors can easily add in scope, but it is a much more difficult conversation about taking items out. This causes unnecessary chaos as more is attempted with the same resource. Projects require flexibility on scope . So I am advocating the tolerance of scope-creep . This is the boon of many Project Managers. Get over it, I say. Projects, especially programs of projects, must stay flexible to cope with the changing business environment. The reality is that the business environment changes over time and the priority of deliverables changes as the business does. New items come in, existing items go out. A ‘killer’ of PMs is when items don’t go out. The project sponsors should be as flexible to take things out as they do putting them in, or scope creeps without the capability to deliver. One other thing – when items are put on hold, they are really being removed forever . At the point when they come back in, the requirement has always changed, so it is a new item.

6. Technology Rigidity

Especially rife in large organizations, projects can be hamstrung when ‘standard’ technologies are applied to solutions where they don’t fit properly. So much time is wasted in trying to get it to fit, just because an IT Architect says it must. Sometimes, a project exists to revolutionize a business, not just evolve it. So new technologies should be a consideration of the revolution.

7. Ineffective Testing

Project delivery teams often claim that not enough testing is done. I think this is rubbish. The reality of projects is that further down the delivery chain an activity it is, the more it comes under pressure when previous activities slip. This is how it is. Not enough testing is a lazy statement . Ineffective testing isn’t. When testing is suddenly presented with a shorter life-cycle, then the test team has to change its priorities, and some testing needs to be consigned to posterity. So testing needs to be applied to the highest-impact, highest risk areas. When the awakening occurs, the test team should already know what the highest-impact tests are, and start there. What doesn’t get tested are the lowest-priority items, and these should be either accepted as a risk, or a case for the remaining testing built. So effective testing is risk-based testing , and I’ve seen this work in every instance, no matter how much time is left.

8. Lack of Practice

An amazing phenomena that is all to common is when projects believe that they can bring in new technologies or methods to bear without any mistakes. Competence requires practice , so why do Project Managers sometimes think that no practice will still result in a perfect outcome? Projects fail because too much has rested upon a perfect delivery, which rarely happens. So part of a change in technology or method should be a pilot or proof of concept that doesn’t impact the critical path. I am absolutely advocating new technologies or methods, but I challenge anyone who thinks that high-impact changes will slot in without any drama. Don’t let the drama impact your project. Bed it in before it hits your critical path.

9. The Wrong People

Project Managers tend to be really good at bringing in resources because they have the right technical skills and experience. Just because someone knows C#, then they must be right for you if you need C# skills, right? Wrong. If personalities, soft competencies and perfect resumes were not a factor, then life would be this simple. But it isn’t unfortunately. Most projects fail when the Wrong People are working on it . It is much easier to recruit a Wrong Person than it is to get rid of them. A lot of damage can be done by the Wrong Person, even if they know about the subject matter like the back of their hand. To avoid Wrong People, more time must be spent on looking for the fitness of a candidate based on their personality, approach to working and their ability to build rapport and strong working relationships. This is why it is common for people to bring in folks they have worked with before onto projects, because they know how they behave.

Above all else, individuals on a project, and the team, must have passion . A lack of passion means that Project Managers don’t get 100%. A lack of passion can result in latency in decisions and delivery. How many times have you asked for a meeting to discuss something to be told you can have a slot in 3 weeks time for half an hour? This is because the person you want to see doesn’t have passion for what you’re trying to achieve. An organization succeeds or dies on people working together, in sync. And the strength of an organization is as strong as its weakest link . A lack of passion is often the weakest link. Passion creates focus, drive and flexibility. Passion can overcome most problems. I’d rather work with a passionate novice than a lackadaisical expert. Passionate people learn quickly and don’t get hung up on mistakes. They don’t hide behind professional boundaries or corporate suits. Screening candidates for passion isn’t easy, but not impossible. When someone’s character radiates passion, you know it.

10. Ownership

A major contributor of project failure is when the owner or customer stops caring about it. Perhaps their priorities change? Perhaps they have new leadership? Perhaps they never cared in the first place. Whatever the reason, projects fail when the people who the project are delivering to lose interest. This may manifest itself as continually changing requirements, and could also be signalled by lack of engagement or drive. Project Managers must continually test their customer to check their interest and yes, passion for the outcome. One trick is to deliberate supply wrong information in a project update, such as an expense, and see if there is a reaction (which of course can be corrected!) It’s a bit sneaky, but it works.

Share This

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

About the author

Simon
Simon is a creative and passionate business leader dedicated to having fun in the pursuit of innovation and personal development

Related Posts

Why Projects Fail

Projects fail when the reason why the project is being done isn't clear, or is a good one. Projects fail because when we hope that what it will deliver will be good. Fingers-crossed, yes? We need to know what a project...

Canned Project? 3 Big Reasons Why Your Project Has Been Cancelled

If the project you were busy working on has just been shelved then you might be feeling puzzled, frustrated or even angry. Sometimes, it doesn't seem logical or even fair. It's likely that your project has suffered the consequences...

Projects Are About People, Not Technology (According To Elizabeth Harrin)

In a recent post on her blog, Elizabeth Harrin shares with us some research from Forrester which (in her words) reminds us that projects are about people, not technology. Elizabeth Harrin is a blogger (a girl's guide to project...

6 Comments for Ten REAL Reasons Why IT Projects Fail

Joe Lau

Wow Simon I think you hav hit the nail on the head on this nice post. I can think of many times when these problems have occurred on projects and feel bad about it

VA:F [1.9.13_1145]

please wait...

Rating: 0.0/5 (0 votes cast)

Chris Mahan

Can’t disagree with anything there.

I would only add that having an inexperienced project manager can lead to a project failure.

Oh, and project with no project manager also have good chances to fail.

VA:F [1.9.13_1145]

please wait...

Rating: 0.0/5 (0 votes cast)

simonstapleton

@Chris – can’t disagree with you either. Have you ever experienced a rookie project manager yourself, and what was the result?

VN:F [1.9.13_1145]

please wait...

Rating: 0.0/5 (0 votes cast)

Chris Mahan

@simonstapleton: The rookie one didn’t religiously follow the steps, but instead wavered in the customer wind like a loose helium balloon in the strom. The work breakdown structure was non-existent.

But there is worse: the Proud yet Incompetent one. This one produced a prodigious amount of documents that contradicted each other.

In both of those cases I ended up using my own system. See this post that describes it: http://stackoverflow.com/questions/122547/how-well-does-bugzilla-work-for-managing-scrum-projects#122726

VA:F [1.9.13_1145]

please wait...

Rating: 0.0/5 (0 votes cast)

micronuts

Just additional to your point, I believe that also most of the time, the person who take up the ownership have to be right attitude. Yes, you can be cool and passion to be learnt, but you need to remember too when you been apppoint or hire for specify role, you are mostly ready to know what it need to be carried on to be done and of course keep learning from time to time with right attitude
I will not want to pay a staff to just for learning and not deliver hahahaa

VA:F [1.9.13_1145]

please wait...

Rating: 0.0/5 (0 votes cast)

simonstapleton

@micronuts – that’s a great point. I think to avoid bringing in the ‘wrong people’ – and therefore having the ‘right’ people is assessing their skills and behaviors, and this includes the owners too. Whole projects can fail if the competency of the owners are not up to standard. It’s connected to the point I made recently about Business Readiness. Projects can deliver, but if the business owner isn’t ready to receive (because of ill preparation or competency issues) then the whole house of cards collapses!

VN:F [1.9.13_1145]

please wait...

Rating: 0.0/5 (0 votes cast)

Wanna say something?

Name (required)

Email (required)

URL

Message (required)

  Cancel Reply

CAPTCHA Code *

Notify me of followup comments via e-mail

« How To Use Your Connections to Increase Your Productivity and Overall Success

Grab This Unconditional and No-Strings Offer Of Support Through These Hard Times »