Why project fails?

Statements mostly hear, when project about

to fail

1. Cut the deployment timing. Think in this way, Time is money

2. Make it Simple, take off or hide complex parts

3. Money: Since now market is down, cut money

4. What's we lose when we are "Optimists"

 Defining “Failure”

 The inability of the project to deliver the

intended benefits to the identified
stakeholders
 However – Failure is relative – there are
many levels of failure from complete
failure to mild failure, and each should be
seen in context
 Levels of Failure

 Complete Failure
 Cancelled before completion
 Failure after implementation so serious that have to roll-back to previous
version or manual alternative
 Organisation is significantly worse off than before, and may be at risk of
bankruptcy
 Serious Failure
 Continues into operation, but does not achieve full benefits
 May be less effective and efficient than existing system
 More costs than benefits and significant loss of brand value
 Medium Failure
 Some benefits received, but not all
 Many tolerances overrun
 Major fixes required to recover
 Mild Failure
 Largely meets benefits but some of the tolerances exceeded (time, cost,
quality, benefits, risks, knowledge transfer, …)
 Projects and Complexity

 A project is a complex arrangement of time,

costs, resources, scope, benefits, risks, issues,
quality and structures
 Failure is very easy : any one part or link can
cause failure – there are millions of way to fail
 Success is very difficult : there is only ONE
way to succeed – the correct balance of the
project elements
 5 key features to fail a project

Failed Project

Scope
Quality

Money Risk

Time

Resource
projects fails when they meet the

following criteria for success

Criteria1 Criteria2 Criteria3

The system It is on It is
works as or under delivered
required budget on time
 Projects Fail:

PM Expectations Estimation Requirements

Inadequately Failure to
Failure to set Poor effort
trained adequately
and manage estimation
and/or identify,
expectations
inexperience document
d project and track
managers requirements
Primary causes for the failure of any
projects

Poor planning
Unclear
goals and
objectives
Failure to
communicate
Objectives changing
Lack of executive
support
Unrealistic time
 4 Points of failed Projects

Failed Badly

Lack of User Unrealistic Scope Creep Poor Testing

Involvement Time Scales
 Why projects fail?

The goal of the project is not

defined properly

Lack of change management

(changes to project are not
controlled)
The ‘moving goalposts’ syndrome.
 Why projects fail? Cont…

Poor or non-existent planning

A solid plan is one of the key steps of
the effective project management.

The project is not resourced as

planned (resources were not
available at the time, or were not
booked in advance)
 Why projects fail? Cont…

Lack of coordination of activities

The project is not led properly

The project reporting is

inadequate or does not exist
 Why projects fail? Cont…

Quality criteria is not defined or

measured

Lack of ownership - It is not

clear who is responsible for the
project outcome

The progress is not monitored

and controlled properly.
 10 things you should know

To prevent projects from failure

1 - You need to define the project
clearly
2 - You need to plan the project
(not to be mixed with project schedule) A
good plan should include scheduling as well
as many other points
3 - You need to provide a way of
including contingency plan
4 - You need a communication plan
 10 things you should know

8 - You need to manage risks and

issues
A good project manager revisits risks and
issue management throughout the project
lifecycle

9 - You need to monitor quality

10 - You need to be prepared that no
matter how well a project is
planned something may go wrong
at some point
 10 things you should know

5 - You need a quality plan

Getting a clear and reliable definition of what
constitutes fit-for-purpose on your project is crucial
for its success.

6 – You need to make it clear project

managers are responsible for projects
7 - You need the manage the project
plan
 Project Management Laws

 Murphy’s Law – Anything that can go wrong,

will go wrong.
 Finagle’s Law of Dynamic Negatives or
Finagle’s Corollary to Murphy’s Law -
Anything that can go wrong, will – at the
worst possible moment.
 Hofstadter’s Law – It always takes longer
than you expect, even when you take into
account Hofstadter’s law.
 Parkinson’s Law – Work expands so as to
full the time available for its completion.
 Project Management Laws

Norman R. Augustine law

 A bad idea executed to perfection is still

a bad Idea
 A good idea executed poorly is of no use to
anyone

Validating the Project’s Strategic Alignment

– For every project you choose to do

– You give up an infinite number of projects
 Conclusion

 Projects mainly fail due to management

problems
 Project manager is responsible for the
outcome of the project
 Success metrics: On time, on budget and as
defined

BUT the project manager must also focus on

the expected results and benefits
Field Examples
 Example 1 : MacDonalds

 2001 : Intranet to connect 30,000

outlets with real-time information
 $170 million written off
 Early termination when estimated costs
of completion reached $1 billion
 Decided that money could be better used
 PROBLEM : scope too broad – no possible
way to construct it
 MODE OF FAILURE: Business Case failure
 TO THEIR CREDIT : Decided to stop
before spending any more!
 Example 2 : US IRS

 GOAL : Upgrade the fraud-detection

system
 Switched off old system
 PROBLEM: System did not work – could
not be deployed – and old system
already switched off
 COSTS : Estimated losses of $318 million
in lost revenue/undetected fraud
 MODE OF FAILURE: Many – classified as
“maintenance upgrade” instead of new
system
 Example 3 : IRS infrastructure

 8 year project to revise infrastructure

 Personnel retiring and lack of expertise
 Failure to deploy meant rebooting the old
system for 2007 tax season
 Costs to Date : $8 billion
 MODE OF FAILURE: Many – too large a
project – too long a timeframe – solutions
out of date before deployed – loss of skills
 Example 3 : UK NHS

 Rewrite of complete national health

system
 More than 12 vendors – no compatibility
in systems – squabbling among vendors
 Users inadequately consulted
 Contractors get no money until system
delivered
 One large contractor has pulled out at
loss of $450 million
 Costs to date = $10 billion overrun
 Major vendor (iSoft) under threat of
bankruptcy
 Analysis of Failures

 Need a formal method for analysis of

failures so that we do not have to learn
same lessons over and over again
 Need a means of reporting failure and
disclosure so that maximum benefits
are gained for the future
 Need to ensure that organisations
accountable for their work and cannot
simply hide details in order to protect
reputations
 HOWEVER : Analysis of Failure is itself
Complex
 Analysis of Failure/2

 Historical Research = What Happened?

 Many histories – many viewpoints
 Can we get to the truth or are all interpretations naturally
biased
 Is there such a thing as an independent analysis?
 Analysis can only be successful if there is a well-documented
project
 Example 3 / cont. …

 MODES OF FAILURE : many

 Government contracting policy – try to reduce risk by
spreading work among vendors
 Government tender policies – splitting specifications from
implementation over different organisations
 Job too large – biting off too much
 Analysis of Failures

 Need a formal method for analysis of

failures so that we do not have to learn
same lessons over and over again
 Need a means of reporting failure and
disclosure so that maximum benefits
are gained for the future
 Need to ensure that organisations
accountable for their work and cannot
simply hide details in order to protect
reputations
 HOWEVER : Analysis of Failure is itself
Complex
 Analysis of Failure/2

 Historical Research = What Happened?

 Many histories – many viewpoints
 Can we get to the truth or are all interpretations naturally
biased
 Is there such a thing as an independent analysis?
 Analysis can only be successful if there is a well-documented
project
 Risks that can induce Failure

 Organisation
 Failure to constitute a Project Board properly
 Lack of involvement from corporate management
 Lack of involvement from customer
 Lack of involvement from user
 Wrong people selected to assist
 Responsibilities not explicit
 Some key responsibilities not allocated
 Risks that can induce Failure/2

 Communication
 Lack of reporting structure
 Lack of sufficient information from decision-making
 Lack of usage of the information as reported – get the
information but not acted on
 People who receive reports do not know what they are
supposed to do with them – think that someone else is
acting on them
 Recommendations/2

 Need a Project Management Method that be

used throughout the organisations
 Common Language for Projects
• E.g. what is an issue, what is a risk, what does “quality”
imply, what is a “tolerance”
 Simple method that is easy to apply
 Method that can be used for early detection of failure modes
 Recommendations

 Recommend that all projects be divided into

smaller units – easier to manage – impact of
failure is reduced
 = DIVIDE AND CONQUER
 High-level Programme Management takes
the long-term view – identifies evolving
technologies and decides on appropriate
solution structures
 Other Risks that can induce
Failure
 Specification + Scope Management
 Business Case Management + Realised
Benefits
 Quality Control
 Change Control + Issue Management
 Risk Analysis + Risk Management
 Configuration Control
 User Involvement
 Incompetence of Personnel
 Unsuitable Technology
 Never Forget

 Murphy’s Law
 O’Leary’s Corollary to Murphy’s Law
 Fetridge’s Law of Frustration