Sullivan managed this project correctly, given the traditional approach of limiting project management to the elements she could control. These are the task-centered items that project managers learn to manage in project management classes and literature. However, once it becomes clear that the expectation of Sullivan is that she must be responsible for the outcome of the project, the scope of what it means to be an IS project manager becomes larger and much more complex. Sullivan’
s
management lexicon had limited her to identifying only one category of risk and thus exhibiting a single behavior. As discussed, exhibiting the other three behaviors might have enabled her to achieve the desired outcome.
The fault is not entirely Sullivan’
s, however. Some of the blame must go to Bennett.
Bennett abdicated his responsibility in that he never checked that the system being developed by Sullivan would meet his company’
s changing needs. He never took it
upon himself to keep Sullivan abreast of the changing environment and changing needs. Similarly, Sullivan’
s boss “was clearly trying to hold her accountable for more
than the creation and implementation of the system — he was putting her on the hook for the results of the system, too.” In so doing, he was raising Sullivan’
s
awareness of the risks in the Self category. This raising of awareness should have been done at the beginning of the project and should have been regularly assessed throughout the duration of the project. It is too late now to tell Sullivan that she failed to assess, and manage, these risks. Thus, the behavior of her executives contributed to Sullivan’
s project failure.
[12 ]Reimus, note 4.
CATEGORIZED RISK AND PREEMPTIVE STRATEGIES
Brooks[13] tells us that projects fail one day at a time. This would suggest that failure is dynamic and its opportunities for occurrence are both ever- present and cumulative. Sullivan’
s project did not fail on the day management first expressed
dissatisfaction, it had been steadily failing for some time. Other well-known software failures, such as the California State DMV project,[14] support this. The DMV project failure did not happen on the day before the state auditors arrived on the scene. As the audit report showed, this project had been on a failure track for some time. If we look at most IS project failures we find the seeds of failure sown earlier in the project and they mature in the soil of ignorance. This ignorance comes from inability to identify, and then manage, all IS project risks.
The IS Project Management Perspective
The IS project manager’
s strategic behavior starts even before the project is initiated.
Instead of having to execute individual risk strategies every day, the project manager now has four behaviors he or she must continually exhibit. The control behavior should already be ingrained in any practicing project manager. However, the other three, assess, relate, monitor, may not be so familiar to many IS project managers. For the IS project manager, this model provides a new way of viewing the responsibilities he or she has. For example, in the case under discussion, had Sullivan had this behavioral model and acted accordingly she probably would not have been surprised by the expected scope of her responsibilities. She would have developed self-awareness. Furthermore, having established the requisite relationships, it is unlikely that Sullivan would have been unaware that the system she was delivering no longer met the needs of the business. This model gives IS
project managers new insights into risk and mitigation behaviors that may help them avoid the apparent fate of Sullivan and her project.
The Senior Management Perspective
Use of this model by project managers in isolation will not be enough, as is clear from the discussion of Sullivan. The responsibility for the successful outcome of an IS
project cannot lie with the IS project manager alone. The model also lays open the need for active participation and proactive responsiveness from the group of stakeholders called Clients. The need for the IS project manager to undertake relationship building and management has been asserted. However, the whole concept of relationships and their management requires the active participation of multiple parties. Success cannot be achieved unless those with whom the project manager must establish the relationship are willing to actively participate in that relationship. There may be a temptation for the executive to turn over responsibility to the IS project manager with an attitude of “leave it to the nerds.” Succumbing to this temptation results in the executive’
s abdicating, not delegating, responsibility.
The executive who stimulates the relationship with the IS community will probably be less prone to being victim of the Client set of risks than a counterpart who cuts off the Relate behavior.
The model, strategies, and behaviors can also be used in audit mode, as in the Sullivan case. They can be used, at any point in a given project, to evaluate which risk classes have the highest potential for project exposure, thus enabling management to focus on the behaviors necessary to minimize occurrence. Just as
the project manager must continually assess and manage the risks in the Self category, there must also be those charged with the responsibility for external assessment, counseling, and training to ensure that these Self risks are being appropriately managed.
[13 ]Fred P. Brooks, Jr. 1995, The Mythical Man-Month: Essays on Software Engineering, Reading, MA: Addison-Wesley.
[14 ]California, note 3.
STRATEGIES OR TACTICS
Some strategies for preempting IS project risks have been presented; they are strategies, however, and, as such, they must be tailored to the project context, the circumstances surrounding the individuals, and the environment of the project.
Because an IS project is dynamic, this context can change rapidly. One such case could be where the incumbent project manager, who has a real grasp of the strategies and behaviors, is replaced by a new project manager exhibiting some of the shortfalls discussed under Self. This would require an immediate focus on the Assess behavior by both the IS project manager and the responsible company management.
The temptation to convert these generalized strategic behaviors into some set of tactics to be executed by all project managers should be resisted. For example, there may be a temptation to identify approaches such as Object-Oriented (OO) Development as a strategy. The use of OO is more of a tactic than a strategy. In the risk items in Exhibit 2, use of OO is a tactic within Lack of effective development methodology. On the negative side, it could be viewed as a tactic that results in increasing risk due to Trying new development method.
Each IS project is unique and dynamic. Each has its own changing context of environment, people, and relationships. The tactics developed for each project, therefore, are unique to that project context and relevant to some specific point in time. Even though we have developed the model from the project manager’
s
perspective, the development of these project specific tactics must be a shared responsibility. What is consistent between projects is the need for IS managers to acquire and exhibit each of the strategic behaviors along with the active participation and guidance of senior management.
The model developed herein is based on categorizing IS project risks as seen from the IS project manager’
s perspective. As a result, different behaviors and mitigation strategies by the IS project manager are suggested, one set for each of the four resulting categories. The model also shows the need for executives, investing managers, and managers who will use the system to share in the management of the IS project risks. Although this chapter is useful to different stakeholders, executives, user management, and IS project managers, it may be many times more useful when shared among these stakeholders. The implications of IS project failure are far too great to abdicate responsibility to the technologists.
NOTES
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.
5. J.G. March and Z. Shapira, 1987, “Managerial Perspectives on Risk and Risk Taking,” Management Science, vol. 33 (11). See also Z. Shapira, 1995, Risk Taking: A Managerial Perspective, New York: Russell Sage Foundation.