what a waste of money! orange paper

www.acando.co.uk

Acando White Paper“ What a waste of money!”

IT project failure and how to avoid itInsight

Project Failure - what a waste of money! v3.indd 1 08/10/2012 12:34

Acando - White Paper

This white paper examines the reasons why IT projects fail. The results of several studies are presented and the trends for failure rates examined. A number of reasons for project failure are considered and recommendations are made as to how project failure may be avoided.It’s almost an unwritten rule that IT projects fail - or at least a signi� cant number of them do! IT projects do not need to fail,but it seems to have become an acceptable norm. The reasons why they fail have not changed much over the past 15 yearsand neither have the rates of failure. Although there have been many attempts to propose simple guidelines, which, it hasbeen argued, can change IT project success rates signi� cantly, projects continue to fail.

In the following sections we will consider what is meant by project failure and then look at the results of studies that provide � gures for IT project failure rates. We will examine the reasons why they fail and consider ways to avoid project failure.

What is project failure?The � rst di� culty is de� ning what is meant by project failure. It is here that the authors of the various studies have di� ering views. Is a project failure a project that is over budget? Well – it might be, but if the project still delivered a positive ROI, can we really call it a failure? Is a project failure a project that does not deliver all the requirements? Possibly, but if the project still delivered positive business bene� ts is it really a failure? Even a cancelled project is not necessarily a failure. There are many reasons why projects can be legitimately cancelled – a changing regulatory landscape, or changing business conditions, could mean that the problems the project wanted to solve have ‘gone away’. Unfortunately, the studies do not make unambiguous distinctions in their

classi� cations that would allow us to identify a true failure. We just have to assume that a project cancelled is a failure and that a project over budget is a failure. We know that this assumption is not valid for all cases, but in our examination of the studies we are looking for trends rather than trying to de� ne absolute project failure rates. If we assume that cancelled projects are categorised by their owners as failures today for the same reasons as they were 20 years ago, then our trend analysis is valid. While that’s a hard assumption to validate, it’s equally hard to invalidate, so for now let us accept it.

On to the studies...Many studies have been carried out to examine IT project failure rates. One would expect that these would show a trend of reducing failure rate over time, given the improving body of knowledge about why projects fail (see Figure 1, below). Unfortunately the statistics do not support this assumption. The Standish Group reported on IT project failure rates back in 1995(1). Their research indicated that 31.1% of projects would be cancelled before they were completed. Additionally, 52.7% of projects would be more than 180% over their original budget. Their research was US based and covered 365 respondents representing 8,380 projects. This represented $81bn of failed projects in a year across the US. The Standish Group repeated their survey in 1998(2) with a 28% cancellation rate and again in 2009, surveying 400 respondents. This time cancellation rates were 24%.

A 2004 study from the Chartered Institute for IT(3) calculated a project failure cost of €142bn across the European Union. From a study of 214 projects, 23.8% were cancelled before completion. Additionally, 69% of projects were over their budget and of these, 53% were more than 70% over budget.

If you’re involved in project management or delivery you willagree that these � gures are worrying. There are many others.Julia King, writing in Computer World in 2003(4), reported IT project failure rates of 30%, which matches a similar survey by Lewis from InfoWorld, also in 2003(5). An Oxford University 2003(6) study had a 10% failure rate and in the 2004 Rand study(7) a 46% budget overrun rate was reported. A Tata Consultancy 2007(8) survey had a 49% budget overrun rate. In 2008 an IEEE study(9) had a 9% failure rate, whilst in the same year a Dynamic Markets(10) study showed a 25% failure rate. A survey of Government projects in 2007 by the European Services Strategy Unit(11) had a 30% failure rate, with




www.acando.co.uk

57% going over budget, whilst in 2008, the North American Computer Audit(12) had a failure rate of 40%. Finally, according to the World Technology and Services Alliance in 2009(13) the failure rate was 43%, costing $6,180bn across the world!

The number of studies we have considered is low and it’s not statistically valid to hypothesise an exact failure rate – there just isn’t enough data. But the trend from the data we do have is clear. Project failure rates have remained pretty consistent over the last 15 years.

So why do IT projects fail?So what is all the research pointing to? The trends show that the failure and overspend rates are not changing over time. This is despite the billions spent on project management, many institutes developing improved techniques and all the research into how to run projects well. After all the lessons learned from innumerable failed projects, project failure rates are the same today as they were 15 years ago.

Too many surveys into project failure reasons do not look at the root cause of failures. Let us consider a sample list to highlight the point. Below are the top 10 reasons, according to the Standish Group 1995 Report, as to why projects fail:

1. Lack of user input2. Incomplete requirements and speci� cations3. Changing requirements and speci� cations4. Lack of executive support5. Technological incompetence6. Lack of resources7. Unrealistic expectations8. Unclear objectives9. Unrealistic time frames10. New technology

Project failure and overspend rates 1994-2009 (Figure 1)

Perc

enta

ge

Year

80%

70%

60%

50%

40%

30%

20%

10%

0%1994 1996 1998 2000 2002 2004 2006 2008 2010

Key:

Failure Rate

Overspend

Linear (Failure Rate)

Linear (Overspend)

52.7%

31.1%

28%

10%

23.8%

30%

46%

69%

57%

49%

30%

40%

43%

9%

24%

25%



This list is not dissimilar to lists provided by countless other studies and you may even recognise some of the reasons why your own projects failed in this list. Few, if any, of these reasons are actual root cause reasons. Let us examine a few, starting with ‘lack of user input’; why is this a valid reason? Is it really because no one asked the users to be involved? Why? Is it because the types of user were not clearly de� ned and therefore, the actual users could not be identi� ed? How did this happen? Surely the Project Manager should have ensured that the user types were de� ned and the users identi� ed? Let us consider another reason – ‘lack of resources’. Why is this a valid reason? Could the lack of resources be due to the fact that requests for resource were not submitted in time? Why? Was it because the resource requirements were not identi� ed until the day before they were needed? How could this have occurred? Why didn’t the Project Manager realise that the resources would be required at that point in the project and submit the request for them in a timely manner? You can begin to see that there are additional, underlying reasons which are the real root causes of the reasons commonly presented in lists of project failure reasons.

So, is project failure the fault of the Project Manager? Or is this just a convenience to make the Project Manager a scapegoat? Think back to a failing project you have had, where you changed the Project Manager and the project improved dramatically. Was this just good fortune, or does a di� erent Project Manager actually have a crucial e� ect on the project outcome?

I believe there are two reasons why projects fail. The � rst of these is most de� nitely the choice of Project Manager. When the underlying causes are examined, most failure reasons (other than events such as a change in the economic factors) that can be obtained from many studies are actually the responsibility of the Project Manager. Yes, your project lacked resources and that’s why it failed. But it’s the Project Manager’s responsibility to identify the resource requirements, plan for those, submit the resource requests and escalate the situation when it becomes more critical. If your project failed due to changing requirements and speci� cations, it was the Project Manager’s responsibility to de� ne and enforce the change request process. Requirements should be agreed, signed o� and baselined. Change requests should only be submitted under a strict Change Control regime and any requests for changes to baselined requirements must be referred to the Change Control Review Board, or similar group of senior management sta� . Similar steps should be taken to manage changes to speci� cations which have already been accepted and signed o� .

The second reason that projects fail is ‘lack of executive sponsorship’. Let us return to the resource requirements ‘failure reason’ again. It is the Project Manager’s responsibility to identify the resource requirements, plan for these and submit the resource requests. If the resourcing problem remains unresolved, the project will start to head towards failure as the timescale begins to slip out. The Project Manager needs to escalate the problem to the Executive Sponsor. It is then the Sponsor’s responsibility to move whatever obstacle was in the way – free up budgets, speak to HR and get them mobilised and advise the Project Manager to contact various agencies, etc. Together, an e� ective Project Manager and an e� ective Executive Sponsor will drag a project through to success no matter how much it kicks and screams.

Both of these reasons can be seen in play every single day. There are countless examples of projects that were going south - of projects that were failing and when the Project Manager is replaced, suddenly the project turns around and is delivered successfully. Most organisations have experienced examples of this. But why is this? The users were the same, the technology was the same, the resources were the same and the requirements were the same. So if users, technology, requirements and resources are common reasons for failure, how is it that by changing the Project Manager, and keeping all these four constant, the project suddenly becomes a success? The root causes of a project failure are the Project Manager and/or the Executive Sponsor. And a good Project Manager would know if the Executive Sponsor wasn’t committed to the project and would escalate that too!

How can project failure be avoided?If a project fails due to a poor Project Manager, the key to a successful project has to be to put in place a top quality ProjectManager. It really is that simple. A good Project Manager will: involve users; make sure requirements are clear,unambiguous, complete and well-de� ned; plan the project, set realistic expectations around delivery and set frequent projectmilestones; ensure sta� are competent (and change them if they are not); motivate the project team; and work with theExecutive Sponsor to deliver a truly successful project.




www.acando.co.uk

The body of knowledge on project management has increased. The discipline of project management has improved. The certi� cation of Project Managers has become widespread. But project failure rates have remained constant. In any population of Project Managers their skills pro� le will follow a normal distribution curve. In a normal distribution curve, around 30% of the population will be at the ‘lower end’ of the curve (see Figure 2, below). This correlates well with the levels of project failure rates we have seen in the studies. Those Project Managers who are in the higher performing population are there because of the sorts of people they are, how they work, their ability to motivate, foster sponsorship, to make the hard decisions and enthuse the people working for them. And that is the same for any professional population. So the reason project failure rates have not decreased is because a successful project still depends so much on the human elements and the human population has not changed. It probably never will. Those who do not want their projects to fail need to look very closely at the Project Manager.

So what makes a good Project Manager?With the Project Manager being so instrumental to the project’s success or failure, it’s important to consider the qualities thatmake up a good Project Manager and to use these as guiding principles in our recruitment and appointment.

Let’s start with the obvious one – professional project management quali� cations. There must be a good correlation between project success rates, good project managers and formal project management quali� cations, right? Now that would be aninteresting study for someone to take up. But anything other than a cursory glance at the quali� cations suggest that this mayin fact not be the case. Let’s use PRINCE2 as an example. This is not in any way to pour scorn on PRINCE2, but merely to serveas an example – and an example from which many other quali� cations also su� er.

Poor Average Good

Num

ber o

f Pro

ject

Man

ager

s

(Fre

quen

cy)

(PM Skill distribution)

30% 50%

Figure 2 Norm

al Distribution

of Project Manager Skills



To become a certi� ed PRINCE2 practitioner requires 2 days of formal learning in a classroom, an exam, another day of formal learning and a second exam. It doesn’t require any formal experience of Project Management, or any proof of your ability to apply the PRINCE2 principles to a project either. To force home the example, I elected to send one of our sales people on the PRINCE2 course. 5 days in the classroom, a 4 week wait for the results and another certi� ed PRINCE2 practitioner. And all of that with no previous Project Management experience or knowledge. Does this person now have professional project management quali� cations? Yes. Should they be trusted to manage a project? Absolutely not.

As a quick footnote, this does not mean formal project management quali� cations are a bad thing. They are an exceptionally important part of our profession and raising the standards in our profession. But they are not in any way, when taken in isolation, a good indicator of a good Project Manager.

So, what’s missing? There are two factors that quali� cations alone do not take in to account. First, there is no check that the practitioner can apply the principles taught in the quali� cations. Second, are the human interactions in the project a hindrance to the application of the principles?

With respect to the � rst factor, a good Project Manager should be able amply to demonstrate their application of project management principles in the work they have delivered. It’s one thing being taught how to do something. It’s another thingentirely to put that knowledge into practice and actually do it. So let’s check that our Project Managers actually put it into practice. The old adage “I don’t apply all the principles, I pick and choose the appropriate ones that are relevant to my project” is full of danger. Beware! This normally means “I don’t understand all the principles and why they’re important so I only use the ones I understand”. The unfortunate truth is that those responsible for assigning the Project Managers to a project often don’t understand the in-depth principles of our profession either. So they are not well placed to ask the challenging questions, to see why requirements led design principles were not used in this project, to check if there was a real decision to exclude them with careful analysis and due consideration, or if the Project Manager simply doesn’t understand the area itself. A good Project Manager applies the principles carefully to each project and where they don’t, they are able to show a considered, full and reasoned argument as to why not.

In addressing the second factor we move on to the most di� cult and arguably the most important area. Are the human interactions in the project a hindrance to the application of the principles? What does this mean? It’s one thing knowing the project management principles. It’s another thing actually using them on a project. And it’s an entirely separate thing again to work with the people, their personalities, personal agendas, strengths and foibles and still get the principles intelligently and systematically applied to the project. This often overlooked but absolutely necessary part of a Project Manager’s skill set includes their man management skills, their communication style, their passion, their stamina, their ability to steer a course to success in spite of human obstacles, their stakeholder management, their in� uencing, negotiating, cajoling and coercing, their planning, cunning, foresight and analysis, their attention to detail and their ability to grasp the big picture, all rolled in to one. One hell of a speci� cation for an individual job role, but the most important determinant of a Project Manager’s ability to make your project a success. Unfortunately there is no single blueprint of skills that will guarantee success. The exact blend of skills required will depend on your organisation and the people involved in your project as much as anything else. And today more people are embodying this philosophy. For example, the APM’s Competency Framework looks at which of these competencies a Project Manager needs and suggests a framework for measuring and developing these skills.

To summarise, project failure rates are not reducing and have been consistent for the last 15 years. The skill of the ProjectManager is a key determinant in the success of the project. The skills we should look for in our Project Managers to maximiseour success are professional quali� cations, structured thorough application of those principles taught in the quali� cations andthe 101 personal competencies required to e� ectively manage the human interactions to ensure the successful applicationsof those principles. Sprinkle with stamina, passion and a drive to succeed and your project has a pretty good chance of beingOK. And the � nal word – now go and take a long hard look at whether this is what you actually do!




www.acando.co.uk

References1. Chaos, The Standish Group, (1995)2. Chaos, The Standish Group, (1998)3. A Study in Project Failure, Dr John McManus and Dr

Trevor Wood-Harper, The Chartered Institute for IT, (June 2008)

4. Survey Shows Common IT Woes, Julia King, Computer World, (June 23, 2003)

5. The 70 Percent Failure, Bob Lewis, InfoWorld, (2003)6. The State of IT Project Management in the UK, Sauer

C and Cuthebertson C, Templeton College, Oxford University, (November 2003)

7. Cost Overruns on Space Systems, The Rand Corporation, (2004)

8. New IT Failure Stats, Tata Consultancy published in ZDNet, (December 12, 2007)

9. A replicated Survey of IT Project Failure Rates, Khaled El Emam and A. Gunes Koru, published in The Journal of IEEE Software Volume 25, (5 September 2008)

10. The IT Complexity Crisis: Danger and Opportunity, Roger Sessions, ObjectWatch, (November 8, 2009)

11. Dynamic Markets Limited, (August 2007)12. Cost Overruns, Delays and Terminations, European

Services Strategy Unit Research Project No. 3 (2007)13. North American Computer Audit, Control & Security

Association (2008)

For more insight, comments and opinion visit our website www.acando.co.uk

About the AuthorPhil Jacklin is the Managing Director of Acando UK, a global consultancy providing project management services. He has managed consultancy � rms for over 15 years, all providing project management services to blue chip clients across the globe. In this capacity Phil has provided governance across numerous projects, employed and recruited hundreds of project managers and advised many of his clients on how to improve their project management capabilities.


www.acando.co.uk

United Kingdom Head O� ce

Oak HouseGround Floor, Sutton Quays Business ParkClifton RoadSutton WeaverWA7 3EH

Tel: +44 (0) 1928 796800Email: [email protected]

Delivering perfect projects around the world...

Manchester / London / Helsinki / Stockholm / Gothenburg / Malmö / Linköping / Ludvika / Falun / Västerås / Hamburg / Frankfurt / Düsseldorf / München / Stuttgart / Zurich / Trondheim / Oslo / Vantaa / Wilmington / Singapore

The only project management company to be accredited by the APM.
