§ Process management packages. In another three to six months after the project management package is introduced, project managers will be ready to further hone their project management skills. With a few projects under their belts using the time accounting and project management tools, they will be able to more fully integrate the new process management tools into their project planning process. If, however, process management tools are introduced too soon, project managers might not have enough real project experience to appreciate the benefits of the somewhat complicated process management tools.
CONCLUSION
Successful projects are critical to the success of not only project managers, but to the whole IS department — and even to the company. Selecting appropriate project management methodologies and life cycles, and supporting them with the proper software tools, can help immeasurably with project success.
Chapter 4: Strategies for Heading Off IS
Project Failure
Paul Cule
Roy Schmidt
Kalle Lyytinen
Mark Keil
OVERVIEW
Information systems software projects must be considered as risky undertakings.
The very nature of software contributes to this riskiness in that it consists of intellectual concepts without physical substance. For example, Brooks[1] describes software, the output of the project, as “pure thoughtstuff, infinitely malleable” and
“invisible and unvisualizable.” The effects of these risky characteristics are manifest in the frequent reports of IS projects that are late and over budget. Furthermore, many systems do not meet the needs of the business when they are delivered and have a low user satisfaction rating. This set of truisms seems to surround information systems projects. A Standish Group study found that over 50 percent of IS projects were late or over budget.[2] This was estimated to amount to $59 billion in cost overruns and another $81 billion in canceled software projects. The ultimate extension of the late and over-budget condition occurs when projects become victims of escalation — the condition of continuing, even increasing, expenditure on a project that to the onlooker is clearly a failure.[3] Why does this happen and what, if anything, can managers do about it?
This chapter develops a behavioral model and concomitant strategies that include strategies for executives and user managers that are as fundamental to IS project success as are the strategies for IS project managers. In addition, a particular case[4]
is discussed that has already been published and discussed elsewhere to illustrate how these strategies can be used to identify where, and why, an IS project is going off track and how these strategies might be used to avoid IS project failure.
[1 ]Fred P. Brooks, Jr., 1987, “No Silver Bullet: Essence and Accidents of Software Engineering,” IEEE Computer vol. 20 (4) pp. 10–19.
[2 ]J. Johnson, 1995, “Chaos: The Dollar Drain of IT Project Failures,” Application Development Trends vol. 2 (1), p. 47.
[3 ]For example, Mark Keil, 1995, “Pulling the Plug: Software Project Management and the Problem of Project Escalation,” MIS Quarterly vol. 19 (4), pp. 421–447. From another perspective: M. Lynn Markus & Mark Keil, 1994, “If We Build It, They Will Come: Designing Information Systems That People Will Use,” Sloan Management Review, vol. 35(4): pp. 11–25. Also, State of California, Bureau of State Audits.
California State Auditor, 1994, The Department of Motor Vehicles and the Office of Information Technology Did Not Minimize the State’
s Financial Risk In the Database
Redevelopment Project.
[4 ]Byron Reimus, 1997, “The IT System That Couldn’
t Deliver,” Harvard Business
Review, vol. 75(3) pp. 22–26. This case is discussed by various luminaries in the ensuing pages of the same issue of the HBR.
RISKS AND RESPONSIBILITIES
IS project failure is not a new problem. It has existed since information systems moved beyond simple automation. Historically, the responsibility for IS project failure has been laid squarely on the shoulders of the IS project manager. The project is defined and the IS project manager is charged with the responsibility of delivering a system that meets the requirements, is on time, and is on budget. This chapter shows how reality may be somewhat more complex. Developing strategies for IS project managers alone is insufficient and requires moving beyond the typical IS-centric view of the traditional literature.
Traditionally, in books and articles, IS project managers have been advised to follow a structured approach to managing risk: identify individual risks, assess their impact, and develop coping strategies for each risk. However, as is shown later in this chapter, this approach rapidly becomes completely unwieldy as the number of risks to be managed increases. Therefore, the authors break with this tradition by showing that risks can be classified into four major types according to their sources, and then managed by dealing with the sources rather than with the individual risks. This approach yields strategies that are manageable as opposed to the unwieldiness of trying to contain each risk individually.
What Is Meant by Risk
Before proceeding any further in this exploration it is necessary to discuss what is meant by risk in the context of this chapter. In the management domain, risk is defined as negative outcome and the size of the risk is the loss incurred if the outcome should occur. Positive outcomes are not seen as risk. Thus, in management terms, there are upside potential and downside risk. Furthermore, managers differentiate between risk-taking and gambling. Gambling is seen as accepting the odds — passive management — whereas risk-taking is seen as managing the odds to achieve a favorable outcome.[5] This chapter uses this management definition of risk, and all of the following discussions are framed by this definition.
That a risk may have a low probability of occurrence does not negate the need to manage it at some level. If an event occurs that causes the derailment of a project, that event is a risk prior to its occurrence. Such an event is frequently unforeseen —
an unrecognized risk. Had it been foreseen, it would have been treated as a risk to be managed. An unforeseen risk is like an invisible “sword of Damocles” waiting to fall upon the unwary, hence the literature’
s emphasis on the identification of risk.
Identifying the risk and then managing it does not make this sword go away, it merely postpones its falling, preferably forever. From this perspective, the purpose of managing a given risk is to defer indefinitely the occurrence of the undesired outcome. Thus, management of a risk is continuous.
For example, obtaining top management commitment to a project, a condition regarded as essential by many, even beyond IS project literature, may not be sufficient. The risk always exists that the project manager will lose that top management support for one reason or another. To manage this risk requires that
the project manager work actively to maintain the support. The risk outcome is defined as occurring if the project manager loses that support. Once the project manager has reestablished top management support, the potential of losing it becomes a risk once again. This is but one risk of many to be managed.
In getting to the roots of IS project risk, new dimensions of risks are disclosed beyond those usually considered to be the responsibility of the project manager.
These new dimensions also impinge upon the responsibilities of the investing executive. Although some project risks are under the control of the IS project manager, others are only partially, or not at all, under his or her control. If the investment is to be adequately protected and the expected outcomes achieved, management of these shared risks must be a joint responsibility of the investing manager, user management, and the IS management. Thus, even though the proposals in this chapter are derived from a study of IS project managers, the implications are as important to non-IS managers as they are to the IS community.
Prior Approaches: Individual Risk
In the literature on IS project failure and the management of risks, there are two approaches to achieving IS project success. Both these approaches seek to establish discrete risk elements to be separately managed. One of the approaches recommends managing IS project risks through the identification and control of individual risk items, the risk management approach. A second approach is based on contingency theory: project success is contingent upon the presence of some set of factors. The second approach is predominant in the IS implementation literature.[6]
Several distinctions can be drawn between these two approaches. First, it can be argued that the contingency factors are framed as positive elements that affect the success of a project, whereas risk factors are framed as negative elements that cause failure. These two streams can be further differentiated in that the stream dealing with contingency factors represents a static view of projects, with the implicit assumption that once a factor is present (e.g., top management support) it remains present. In contrast, the risk management perspective represents a more dynamic view, suggesting that risk factors (e.g., the possibility of a lack of top management support) represent a constant threat and must be managed actively for the entire duration of the project and thus lends itself to the discussion of management processes and strategies more than do event-based contingency factors. The remaining discussion is built upon the ideas of managing risk.