SimonStapleton.com

Ten REAL Reasons Why IT Projects Fail

Estimated reading time: 6 mins

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.

Share this...
Share on Facebook0Share on Google+0Tweet about this on TwitterShare on LinkedIn0Pin on Pinterest0Share on Reddit0Share on StumbleUpon0Digg thisEmail this to someone
 
This post is part 10 of 11 in the series Careers in IT

About the author /


Simon is a creative and passionate business leader dedicated to having fun in the pursuit of high performance and personal development. He is co-founder of Applied Change, a Business Change consultancy based in the UK. Simon is also an Ambassador for Gloucestershire business. Simon is an Associate Member of the Chartered Institute of Professional Development.

Related Articles

6 Comments

  1. 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

     
  2. 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.

     
  3. simonstapleton

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

     
  4. 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

     
  5. 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

     
  6. 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!

     

Post your comments

Your email address will not be published. Required fields are marked *

Affiliate Promotion

simonstapleton.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com. Amazon, the Amazon logo, AmazonSupply, and the AmazonSupply logo are trademarks of Amazon.com, Inc. or its affiliates.

Polls

When answering Employee surveys, do you always answer completely honestly?

View Results

Loading ... Loading ...
SimonStapleton.com located at Watledge , Stroud, UK . Reviewed by 18,205 readers rated: 1 / 10
My latest book: ACE Your Performance Appraisal$4.99 on
How Am I Doing?

Did this discussion solve your problem?

Then please rate this post or leave a comment.