Back to the Future
-
Upload
cssa -
Category
Technology
-
view
1.037 -
download
2
description
Transcript of Back to the Future
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