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 Airport’s Computerized Baggage Handling System • California’s Department of Motor Vehicle Database Redevelopment Project • Greyhound’s TRIPS system • AMRIS’s 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 company’s 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 isn’t • “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 couldn’t 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 don’t’ think they ever got to the point where they really were able to say “This isn’t 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 isn’t going to work and walking away from it.” (Sales Manager) • I’m 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-unit’s throat • “The spin on that is that the field just didn’t get it, the field just didn’t understand, the filed just didn’t support it. The field knew what they wanted and they weren’t 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, we’re 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 didn’t 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 organization’s 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 • Project’s 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 we’re killing projects left and right unless they start producing fairly quickly.” (Manager in Development Organization)

19. Project’s Primary Champion Dies • “He was a very powerful person. Well, now that he’s not around, and he’s not there to protect it, and he’s 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 isn’t 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, I’m 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 suicide…I’ve 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 you’ve done, but we won’t 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 around…Yet 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/consultants

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