Software Project Escalation

1
Software Project Escalation
2
Many IT Failures Involve Projects that Take on a
Life of Their Own

• As Keider (1974) has observed
• Some projects never seem to terminate.rather,
  they become like Moses, condemned to wander till
  the end of their days without seeing the promised
  land.
• How can we explain what is happening in these
  so-called runaway projects?
• Is there something more going on here than poor
  planning and control?
• Are there behavioral or psychological factors
  that might explain this phenomenon?

3
Escalating Commitment Factors

• Concept of Escalating Commitment
• Several different types of factors may contribute
  to escalation (Staw and Ross, 1987)
• Project factors
• Psychological factors
• Social factors
• Organizational factors

4
Examples of Software Project Escalation

• Denver International Airports Computerized
  Baggage Handling System
• Californias Department of Motor Vehicle Database
  Redevelopment Project
• Greyhounds TRIPS system
• AMRISs CONFIRM Project
• London Stock Exchange Taurus project
• CompuSys CONFIG project

5
CompuSys CONFIG Project

• In 1980, CompuSys began to develop an expert
  system designed help its sales reps configure
  computer hardware
• Despite substantial user involvement, the system
  failed to gain acceptance among the sales reps
  for two primary reasons
• Developers had a poor understanding of the sales
  process and built CONFIG as a standalone system
  instead of tightly integrating it with the
  companys price quotation system
• Sales reps had not incentive to use the system
• Finally, in 1993 after millions of dollars and
  more than a decade of effort the project was
  terminated.

6
Causes of Escalation

• Treating a project as an investment in research
  and development
• Denial of negative information
• Emotional attachment to the project
• Rivalry between organizational sub-units
• Empire building
• Company culture that promotes escalation
• Loose management controls

7
Treating a project as an investment in research
and development when it really isnt

• I think it was a combination of optimism which
  you could call undue or not---a sense that this
  was a new technology that we were applying to
  this problem and that experimenting with it could
  yield the results that we wanted even if we
  couldnt see them in front of us. (CONGIF
  Program Manager)

8
Denial of Negative Information

• The stuff that she was hearing from me she would
  get defensive about denied it I think.. (CONFIG
  Implementation Manager)
• I dont think they ever got to the point where
  they really were able to say This isnt
  working (CONFIG Application Support Specialist)

9
Emotional Attachment to the Project

• The emotional baggage of hanging on to it.not
  being able to say well this isnt going to work
  and walking away from it. (Sales Manager)
• Im trying to be very objective and pull myself
  away from being so attached to (CONFIG).
  (CONFIG Development Manager)

10
Rivalry between organizational sub-units (e.g.,
sales and manufacturing) causing one sub-unit to
force something down another sub-units throat

• The spin on that is that the field just didnt
  get it, the field just didnt understand, the
  filed just didnt support it. The field knew
  what they wanted and they werent getting it.
  (CONFIG Implementation Manager)

11
Empire Building

• We were in a period of relative growth so that
  building empires was the thing to do because that
  was indicator of how powerful you were. He was
  definitely building an empire. It was like
  Hey, were going to have our own building.
  (CONFIG Implementation Manager)

12
Company culture that promotes escalation

• Part of the culture at that point was it was
  okay to let things linger before someone actually
  went out and killed them. That was not unusual.
  (Manager in Development Organization)

13
Loose Management Controls

• Proforma justifications I think were much more
  readily accepted (CONFIG Program Manager)
• You didnt have to go to any board, or group, or
  management committee. (Sales Executive)
• Sometimes it seemed to me that decisions about
  this kind of thing were made almost in an
  off-handed way. (CONFIG Program Manager)

14
Project Management Factors Commonly Associated
with Escalation

• Underestimation of time to complete the project
  (83)
• Senior management did not monitor project closely
  enough (78)
• Underestimation of necessary resources (77)
• Size or scope of project underestimated (75)
• Inadequate project control mechanisms (72)
• System specifications kept changing (71)
• Inadequate planning (71)

15
Psychological, Social, and Organizational Factors
Associated with Escalation

• Abandonment would make the primary decision-maker
  look bad (76)
• Senior management provided continued funding or
  protection (75)
• Primary decision-maker expressed a we have come
  too far to quit now attitude (70)
• Primary decision-maker initiated project or was
  extensively involved with it (70)
• Completion seen as important to organizations
  ability to compete (64)
• Failure would have a negative impact on primary
  decision-maker (57)
• Primary decision-maker distorted or concealed
  negative information (55)
• Loose/informal process for justifying projects
  (54)

16
The Importance of Understanding De-Escalation

• Escalation (and the factors that contribute to
  it) has been widely studied
• But.can we ever hope to avoid the problem of
  escalation?
• The more significant question may be how to deal
  with escalation when it does occur

17
De-escalation Turning Around Troubled Projects

• What happened in the case of CONFIG?
• External shock hits the organization
• Projects primary champion dies.

18
External Shock hits the organization

• I firmly believe if we had not run into
  financial problems.that product would be alive
  and well. (Sales Manager)
• At this point in our history were killing
  projects left and right unless they start
  producing fairly quickly. (Manager in
  Development Organization)

19
Projects Primary Champion Dies

• He was a very powerful person. Well, now that
  hes not around, and hes not there to protect
  it, and hes not there to influence the funding,
  and you know he could always find a way to pull
  the money that he needed. (CONFIG
  Implementation Manager)

20
Turning Troubled Projects Around Is There
Anything Managers Can Do?

• All of this seems rather extreme.
• Do we have to wait until the business environment
  becomes so unfavorable that cash flow dries up
  and the project is cancelled?
• Do we have to wait until somebody dies to cancel
  a project that isnt performing?

21
Factors Associated with De-Escalation

• Less organizational tolerance for failure
• More publicly stated limits
• Greater awareness of problems facing the project
• Greater clarity of criteria for success and
  failure
• More emphasis o project outcomes than management
  processes
• More regular evaluation of projects
• Greater separation of responsibility for
  approving and evaluating projects

22
The Mum Effect (I.e., reluctance to transmit bad
news)

• .so me as a little staff auditor, Im going to
  go to the executive vice president of the company
  and tell him this is a worthless project and he
  should pull the plug on it? (IS Auditor)
• It would have been political suicideIve been
  the whistle blower once in my life and wound up
  standing on the unemployment line. IS Auditor)

23
The Deaf Effect (i.e., reluctance to hear bad
news)

• We were trying to convey the seriousness of the
  situation (Internal IS auditor)
• We tried to recommend in many reports that
  they should stop this system and kill it. But,
  senior management let it keep going.. (Internal
  IS auditor)
• I wrote a lot of reports.They took me out to
  lunch and said, we really appreciate what youve
  done, but we wont be needing you anymore
  (Internal IS auditor)

24
A Model of De-Escalation

• Phase 1 Recognizing the Problem
• Phase 2 Re-examining the Present Course of
  Action
• Phase 3 Searching for an Alternative Course of
  Action
• Phase 4 Implementing an Exit Strategy

25
Conclusions

• Escalation is a significant problem in IT
  projects
• Escalation and de-escalation manifest different
  portraits
• There are no particular actions that always turn
  projects aroundYet many actions can lead to
  successful de-escalation
• In the majority of cases, de-escalation appears
  to be triggered by actors such as senior mangers,
  internal auditors, or external auditors/consultant
  s

26
Recommendations

• Monitor projects closely and do not underestimate
  the seriousness of problems
• Clearly define the criteria for project success
• Set limits beyond which the project will cease to
  receive support
• Manage whistle blowing
• Separate responsibility for project approval from
  responsibility for project evaluation
• Reduce project complexity/scope
• Initiate external review of the project
• Change project leadership or staffing