Ten REAL Reasons Why IT Projects Fail

Why do IT Projects fail? 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 – One End 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, 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 (ain’t this called agile?) 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 (once again, ain’t this called agile?).

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 postponed 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. 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. Testing needs to be applied to the highest-impact, highest risk areas. When testing begins, 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 by the Project Sponsor (see 10), or a case for the remaining testing to continue. So effective testing is always risk-based testing, whether the start to testing has been delayed, or not.

8. Lack of Practice

An amazing phenomena that is all too common is when projects believe that they can deploy new technologies or methods without any mistakes. Competence requires practice, so why do some Project Managers think that no practice will still result in a perfect outcome? Projects fail because too much has rested upon a perfect delivery, which never happens. Oart 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. But rarely is this enough to consider a recruit as a good choice. 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 their project.

Above all else, individuals on a project, and the team, must be self-motivated. A lack of self-motivation means that Project Managers don’t get 100%, and are forced to continually kick the ass of their project team. A lack of self-motivation can result in latency in decisions and delivery, as people leave for home with critical actions outstanding. A project succeeds or dies on people working together, in sync. Self-motivation creates focus, drive and flexibility. Self-motivation can overcome most problems. I’d rather work with a self-motivated novice than a lackadaisical expert. Self-motivated people learn quickly and don’t get hung up on mistakes. They don’t hide behind professional boundaries or corporate suits. Screening candidates for self-motivation isn’t easy, but not impossible: you’ve got to ask the right questions in an interview.

10. Ownership

A major contributor of project failure is when the owner or customer (known as the Sponsor) 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.

Have you suffered a failed IT Project?

Share your story below by leaving a comment or starting a discussion in my Community Forum.