The Oops of Systems Development or Project Escalation And Failure

1
The Oops of Systems Development-or-Project
Escalation And Failure

• ISM 6121

2
Runaway Project Definition

• Over budget
• Behind schedule
• Less functionality / features

3
Project Escalation

• Escalation of commitment to a failing course of
  action
• Continuing to provide resources
• Despite signs that project is failing or
• Cannot succeed

4
Whats the management issue?

• Companies are investing millions of dollars in IT
  projects
• BUT many projects are not as successful as we
  would like
• 75 of large systems are considered operating
  failures
• Project escalation occurs in 30-40 of all
  projects and cost overruns average 130-150
• Average loss on an abandoned project 4.2
  million
• Costs the industry billions of dollars a year

5
Project Escalations/Failures

• CONFIRM
• Fox-Meyer Drug ERP
• California DMV Database Merging
• Greyhounds Trips System
• Hershey Foods
• Denver International Airport
• Taurus Project

6
Frequency

• 81 of auditors suggested that at least one of
  the last 5 projects was example of escalation

7
Duration

• Averages 21 months
• Min 1 month
• Max 255 months (21 yrs)
• 75

8
Causes of Project Escalation

• Treating Project as investment in RD
• Denial of Negative Information
• Emotional Attachment to Project
• Rivalry between sub-units
• Empire Building
• Company culture promotes escalation
• Loose Control Structures

9
Project Reasons For Escalation

• Underestimation of Time to Completion (83)
• Senior Management did not monitor project closely
  enough (78)
• Underestimation of Necessary Resources (77)
• Size or Scope Underestimated (75)
• Inadequate Project Control Mechanisms (72)
• System Specs Keep Changing (71)
• Inadequate Planning (71)

10
Psychological, Social Organizational Factors

• Primary decision-maker (PDM) repeatedly expressed
  support (85)
• Abandonment would make PDM look bad (76)
• Senior mgt. provided continued funding (75)
• PDM expressed a weve come to far to quit now
  attitude (70)
• Completion seen as important to organizations
  ability to compete (64)
• Failure would have negative impact on PDM (57)
• PDM distorted or concealed negative information
  (55)
• Loose/Informal process for justifying projects
  (54)

11
People Mistakes

• Undermined motivation
• Weak personnel
• Uncontrolled problem employees
• Heroics
• Adding people to a late project
• Noisy, crowded offices
• Friction between developers and customers

• Unrealistic expectations
• Lack of effective project sponsorship
• Lack of stakeholder buy-in
• Lack of user input
• Politics placed over substance
• Wishful thinking

12
Process Mistakes

• Overly optimistic schedules
• Insufficient risk management
• Contractor failure
• Insufficient planning
• Abandonment of planning under pressure
• Wasted time during the fuzzy front end
• Shortchanged upstream activities

• Shortchanged quality assurance
• Insufficient mgt controls
• Premature or overly frequent convergence
• Omitting necessary tasks from estimates
• Planning to catch up later
• Code-like-hell programming

13
Technology

• Silver-bullet syndrome
• Overestimated savings from new tools or methods
• Switching tools in the middle of a project
• Lack of automated source-code control

14
Contributing Factors

• Mum Effect
• Reluctance to tell bad news
• It would have been political suicideIve been
  the whistle blower once in my life and wound up
  standing on the unemployment line
• (IS Auditor)
• Deaf Effect
• Reluctance to hear bad news
• I wrote a lot of reportsThey took me out to
  lunch and said, We really appreciate what you've
  done, but we wont be needing you anymore
• (Internal IS Auditor)

15
Project Deescalation

• Keil and Robey (1999)

16
Deescalation Definition

• Reversal of escalating commitments to failing
  courses of action
• Project Termination
• Project Redirection

17
Questions Concerning Deescalation

• What factors are associated with Transition for
  Escalation to Deescalation?
• Who is involved?
• What actions are taken?

18
Deescalation Factors

• Change in top management
• External shocks to the organization
• Change in project champion
• Organization tolerance for failure (-)
• Presence of Publicly Stated Resource Limits ()
• Consideration of Alternative uses of Funds
• Awareness of Problems Facing Project ()
• Visibility of Project Costs
• Clarity of Criteria for Success or Failure ()
• Evaluation of Decision Makers Process vs.
  Outcome ()
• Regular Project Evaluations ()
• Separation of Responsibility ()
• Approval of Projects
• Evaluation of Projects

19
Who De-Escalates Projects

• Top Management (37)
• Internal IS Auditor (17)
• External IS Auditor (14)
• Users (11)
• IS Project Staff (11)
• IS Management (9)

20
De-escalation Actions

• Project Management
• Redefine the Project
• Improve Project Management
• Change in Project Leadership
• Subdivide the Project
• Resolve Specific Problems

21
De-escalation Actions

• Resource Management
• Adding or Removing Resources
• Layoff / Hiring
• Training

22
A Model of De-Escalation
1. Recognize the Problem
2. Reexamine Present Course of Action
Reduction of Commitment
3. Search for Alternative Courses of Action
4. Implement an Exit Strategy
23
Process Model of De-escalation
Deaf Effect
Escalation
Deescalation
Mum Effect
24
Recommendations

• Monitor IT projects closely
• Initiate External Project Reviews
• Dont underestimate seriousness of problems
• Set limits above which support will be withdrawn
• Manage whistle blowing
• Separate Auditors from Project Authority
  Structure
• Nurture Team Culturenot Policeman culture
• Separate Project Approval from Project evaluation
• Change Project Leadership/Staffing

25
What we Know about Keeping Mum

• Smith, Keil, Depledge (2001)

26
Suceptability of IS Projects

• Lack of Understanding
• Complexity of IS
• Estimation of Coding Done
• Dynamic Projects
• Scope Changes

27
Whistleblowing

• Problem Awareness
• Does Problem Deserve Action?
• Am I Responsible for taking Action?
• What Reporting Alternative Should I use?
• Internal
• External

28
Proposed Model (IS)

-
Personal responsibility to report
Status Ought to be reported
Reluctance to Report

-

Perceived Wrongdoing
Perceived Risk of Negative Consequences

Perceived Project Risk
Perceived Impact
-

Perceived Risk Propensity
29
Implications of Model

• Willingness to Transmit Bad News
• Perceived Impact of Bad News and
• Level of Wrongdoing
• Question What is Wrongdoing?
• Over budget
• Behind schedule
• Less functionality / features

30
Conclusion

• We need to be careful how our definitions of
• Runaway Projects
• Wrongdoing
• Success
• Failure