“What a waste of money” IT Project Failure and how to avoid it 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 significant 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 years, and neither have the rates of failure. Although there have been many attempts to propose simple guidelines, which, it has been argued, can change IT project success rates significantly, 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 figures for IT project failure rates. We will examine the reasons why they fail, and consider ways to avoid project failure.

1. Acando White Paper
“What a waste of money!”
IT project failure and how to avoid it
Insight
www.acando.co.uk
Project Failure - what a waste of money! v3.indd 1
08/10/2012 12:34

2. Acando White Paper
“What a waste of money!”
IT project failure and how to avoid it
Insight
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
significant 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 years
and neither have the rates of failure. Although there have been
many attempts to propose simple guidelines, which, it has
been argued, can change IT project success rates significantly,
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 figures
for IT project failure rates. We will examine the reasons why they
fail and consider ways to avoid project failure.
classifications 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 define
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%.
What is project failure?
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.
The first difficulty is defining what is meant by project failure. It is
here that the authors of the various studies have differing 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 benefits 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
If you’re involved in project management or delivery you will
agree that these figures 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
Acando - White Paper
Project Failure - what a waste of money! v3.indd 2
08/10/2012 12:34

3. 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!
Project failure and overspend rates 1994-2009 (Figure 1)
80%
70%
69%
Percentage
60%
50%
57%
52.7%
49%
46%
40%
30%
30%
30%
28%
Overspend
25%
23.8%
Linear (Failure Rate)
24%
Linear (Overspend)
10%
10%
Key:
Failure Rate
40%
31.1%
20%
0%
1994
43%
9%
1996
1998
2000
2002
2004
2006
2008
2010
Year
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 input
2. Incomplete requirements and specifications
3. Changing requirements and specifications
4. Lack of executive support
5. Technological incompetence
6. Lack of resources
7. Unrealistic expectations
8. Unclear objectives
9. Unrealistic time frames
10. New technology
www.acando.co.uk
Project Failure - what a waste of money! v3.indd 3
08/10/2012 12:34

4. Acando White Paper
“What a waste of money!”
IT project failure and how to avoid it
Insight
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 defined and therefore, the actual users could not
be identified? How did this happen? Surely the Project Manager
should have ensured that the user types were defined and the
users identified? 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 identified 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 different Project Manager actually have a crucial
effect on the project outcome?
I believe there are two reasons why projects fail. The first of
these is most definitely 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 specifications, it was the Project Manager’s responsibility to
define and enforce the change request process. Requirements
should be agreed, signed off 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 staff. Similar steps should be taken to manage
changes to specifications which have already been accepted
and signed off.
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 effective Project
Manager and an effective 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 Project
Manager. It really is that simple. A good Project Manager will:
involve users; make sure requirements are clear,
unambiguous, complete and well-defined; plan the project, set
realistic expectations around delivery and set frequent project
milestones; ensure staff are competent (and change them if they
are not); motivate the project team; and work with the
Executive Sponsor to deliver a truly successful project.
Acando - White Paper
Project Failure - what a waste of money! v3.indd 4
08/10/2012 12:34

5. 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 that
make 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 qualifications. There must be a good correlation
between project success rates, good project managers and formal
project management qualifications, right? Now that would be an
interesting study for someone to take up. But anything other than
a cursory glance at the qualifications suggest that this may
in 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 serve
as an example – and an example from which many other
qualifications also suffer.
(Frequency)
Figure 2 Normal Distribution
of Project Manager Skills
Number of Project Managers
The body of knowledge on project management has increased.
The discipline of project management has improved.
The certification of Project Managers has become widespread.
But project failure rates have remained constant. In any population
of Project Managers their skills profile 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.
30%
Poor
50%
Average
(PM Skill distribution)
Good
www.acando.co.uk
Project Failure - what a waste of money! v3.indd 5
08/10/2012 12:34

6. Acando White Paper
“What a waste of money!”
IT project failure and how to avoid it
Insight
To become a certified 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 certified PRINCE2 practitioner. And all of that
with no previous Project Management experience or knowledge.
Does this person now have professional project management
qualifications? Yes. Should they be trusted to manage a project?
Absolutely not.
As a quick footnote, this does not mean formal project
management qualifications 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 qualifications
alone do not take in to account. First, there is no check that the
practitioner can apply the principles taught in the qualifications.
Second, are the human interactions in the project a hindrance to
the application of the principles?
With respect to the first 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 thing
entirely 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 difficult
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 influencing, 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 specification 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 Project
Manager is a key determinant in the success of the project. The
skills we should look for in our Project Managers to maximise
our success are professional qualifications, structured thorough
application of those principles taught in the qualifications and
the 101 personal competencies required to effectively manage the
human interactions to ensure the successful applications
of those principles. Sprinkle with stamina, passion and a drive to
succeed and your project has a pretty good chance of being
OK. And the final word – now go and take a long hard look at
whether this is what you actually do!
Acando - White Paper
Project Failure - what a waste of money! v3.indd 6
08/10/2012 12:34

7. References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
Chaos, The Standish Group, (1995)
Chaos, The Standish Group, (1998)
A Study in Project Failure, Dr John McManus and Dr
Trevor Wood-Harper, The Chartered Institute for IT,
(June 2008)
Survey Shows Common IT Woes, Julia King, Computer
World, (June 23, 2003)
The 70 Percent Failure, Bob Lewis, InfoWorld, (2003)
The State of IT Project Management in the UK, Sauer
C and Cuthebertson C, Templeton College, Oxford
University, (November 2003)
Cost Overruns on Space Systems, The Rand
Corporation, (2004)
New IT Failure Stats, Tata Consultancy published in
ZDNet, (December 12, 2007)
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)
The IT Complexity Crisis: Danger and Opportunity,
Roger Sessions, ObjectWatch, (November 8, 2009)
Dynamic Markets Limited, (August 2007)
Cost Overruns, Delays and Terminations, European
Services Strategy Unit Research Project No. 3 (2007)
North American Computer Audit, Control & Security
Association (2008)
About the Author
Phil Jacklin is the Managing Director of Acando UK, a global consultancy providing project management services. He has managed
consultancy firms 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.
For more insight, comments
and opinion visit our website
www.acando.co.uk
www.acando.co.uk
Project Failure - what a waste of money! v3.indd 7
08/10/2012 12:35

8. www.acando.co.uk
United Kingdom Head Office
Oak House
Ground Floor, Sutton Quays Business Park
Clifton Road
Sutton Weaver
WA7 3EH
Tel: +44 (0) 1928 796800
Email: projectsuccess@acando.com
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.
Project Failure - what a waste of money! v3.indd 8
08/10/2012 12:35