Project Failure Modes:Lessons from the Field

Roger LaytonMD, NIRO Project Management (Pty) Ltd

MD, Roger Layton Associates (Pty) Ltd

Basic Premises Failure Avoidance

it is possible to avoid failure completely or to minimise the impact at the earliest time but this requires comprehensive understanding of all

possible types and modes of failure as well as best practice approaches to deal with

issues and threats to success Learning from Other’s Mistakes

What can we learn from large-scale failures that can help to avoid future failures

Can we all learn from the lessons of a few disasters? Improving our Understanding of Failure

We need to focus more on the understanding of failure than on success

We will encounter the potential for failure every day

What is Project Failure? Analysis of Google search on “Project

Failure” identifies almost exclusively IT Project Failure!

Many good case studies reported – but virtually NO companies (customers) or suppliers prepared to comment on their own failures

Need to distinguish levels and modes of failure…

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

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

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, …)

If it ain’t broke, don’t fix it! How often are organisations forced into the

conservative position of not starting new projects because of a fear of failure (CYA)

At the same time they deny themselves the opportunities and benefits that may emerge from new projects and products.

Without new IT and business projects, organisations will over time become more ineffective, more inefficient and eventually will become extinct.

If it ain’t broke yet, then break it!

How often are organisations placed into a worse position by having tried to develop and install a new system and failed.

We rely on IT systems more and more in our world.

When large systems fail to be delivered, or fail after deployed, they can impact on the lives of thousands or millions of people.

Managing Change

All programmes and projects are a reaction to the need for change – driven by business strategy and policy

Programmes deliver the changes and the benefits by producing new products, processes and services

Projects will create these products

ChangeStrategy

Conservative Evolutionary

If it ain’t broke, don’t fix it

If it ain’t broke yet,

then break it

Do nothing…Risk of stagnation and extinction

Lose competitive advantageLose efficiency and effectiveness

OR

Sit back and watch competitors fail!

Risk of high costs, not meeting deadlines and not receiving any

benefits

Being in a worse position than before with nothing to show

Bad publicity and brand damageLegal actions

We are in trouble if we do, and in trouble if we don’t

Do ALL large IT projects have to endure the high risk of failure?

Examples from the Field Source : Information Week, 13/16 Oct 2006,

Paul McDougall “in most cases overly complex IT

makeovers are doomed to fail because their success depends upon too many unpredictable variables falling nicely into place”

“Some elements of success include :- Meticulous business case analysis Sound strategies for change management Workable back-up plans if the big one happens”

Selection of Field Examples

Only using documented examples as have appeared in press

No local examples cited Specific elements of failure extracted

to serve as lessons learned

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 4 : Neilsen Media Research

Viewer stats in TV industry Complete rewrite of the system Wanted to get finished within one

year 8 years on still no new system Costs and time overrun MODE OF FAILURE : Unrealistic

schedules – always overdue and rushing – quality second to time, costs get lost

Example 5 : 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

Example 5 / contd

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

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

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

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