Ten REAL Reasons Why IT Projects Fail

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.

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 synch. 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 iteself 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!)

If you enjoyed this post, make sure you subscribe to my RSS feed!

What Do You Think...? Add to the discussion and post a comment!

Take a look at these other articles you may find interesting:

• Using Chaos to Organize large scale programs and projects
• Do You Consider Business Readiness as an Afterthought?
• Why Business Sponsorship and a Center of Excellence is Key to BPM Success
• Ten Web-Based Project Management Tools
• Projects Are About People, Not Technology (According To Elizabeth Harrin)