A number of authors[7] have sought to propose ways of managing IS project risk.
Anecdotal prescriptions have been offered but, like many such prescriptions, they smack somewhat of the “silver bullet.”[8] However, one thing these authors have in common is their suggestion that if risk is to be managed, it must first be identified.
In prior literature,[9] the management strategy proposed has been to develop checklists of risks and then to manage each risk as a distinct entity. However, complex projects may have many risks, and managing such a multiplicity of risks, some undefined or unrecognized, as unique items on a checklist is impractical.
Managers need a means of reducing long checklists to some manageable form without discarding any of the risk items. A possible solution to this problem is now discussed.
Proposed Approach: Categorizing Risk
In contrast to prior approaches, the authors propose an integrative approach that enables risks to be consolidated into categories. Each category requires a different managerial behavior together with concomitant risk mitigation strategies. Using this integrative approach, risk becomes more manageable and managers need not concern themselves with failing to identify every risk item or contingency factor.
This new model of an IS project is grounded in the data from a study of IS project risk undertaken by the authors. In this study, 41 experienced, practicing IS project managers defined, and reached consensus on, a list of 53 risk items. A detailed description of the study that developed this risk list is found elsewhere.[10]
The approach taken to developing the model in Exhibit 1 was to look for patterns in the risk items in the above-mentioned study that show some risks as being similar to each other but different from other risks. In developing mitigation strategies for managers, the patterns sought were those that indicated differing behavioral perspectives. The process of pattern recognition was through repeated inspection of the data from the above study.
Exhibit 1. A Risk Categorization and Behavior Model
The first pattern to emerge from this inspection process was that some of the risk items were totally under the control of the project manager and others were not. The resulting division is characterized as Inside and Outside risks (i.e., risks totally within the project manager’
s purview, or risks outside that purview). However, there was still considerable variation amongst the risks within each group. Further inspection resulted in the recognition of two subgroups of Inside risks which are called Task and Self, and two subgroups of Outside risks that are called Client and Environment.
The Task classification refers to those risks that were the subject to the active direction of the IS project manager (e.g., Poor team relationships). These are the risk management elements typically found in the classic project management literature. The risks in the Self category reflect the characteristics of the project
manager himself or herself, and are related to the understanding and capability of the project manager (e.g., Lack of effective project management skills).
The risks classified as Client are risks that cannot be controlled by the project manager but are risks over which the project manager may exert some influence (e.g., Failure to manage end user expectations). The Environment risks are external to the project and can be neither controlled nor influenced by the project manager (e.g., Unstable corporate environment).
Because the risks thus identified are from the project manager’
s perspective, the
different classes can be linked to the project manager views, as shown in Exhibit 1.
Each of the 53 risk items from the study was segmented into one of these four categories. It should be noted that the categories into which the risks have been put are a result of the authors’
perspectives based on their own project management
experiences. The results of this categorization are shown in Exhibit 2.
Exhibit 2. Categorized Risk Items
As may be seen from Exhibit 2, there is homogeneity within each category and difference between categories. However, there may be some borderline cases in which the reader feels that a particular risk may belong in another category. We believe this to be appropriate in that some risks may have a contextual element. For example, it may be that in one project, a risk such as Bad estimation may be classified as Self and in another, Task. Bad estimation as a result of no estimating methodology could be seen as falling in the Self category. On the other hand, where
an estimating methodology exists but is poorly executed, this risk could belong in the Task category. The purpose of the model is to develop mitigation strategies relevant to the category rather than to each individual risk in isolation. Thus the risk will be managed in accordance with the category in which it falls within a given context.
However, such contextual capabilities within the model may add to its applicability in both the general and the specific case, because any so-called borderline risk will be subsumed into a category and managed according to the strategy relevant to that category.
[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.
[6 ]For example, T.H. Kwon and R.W. Zmud, “Unifying the Fragmented Models of Information Systems Implementation,” in R.J. Boland and R.A. Hirschheim (eds.), 1987, Critical Issues in Information Systems Research, New York: John Wiley & Sons.
[7 ]Barry Boehm, 1989, Software Risk Management Tutorial, Washington, D.C: IEEE
Computer Society Press; Barry Boehm, 1991, “Software Risk Management: Principles and Practices,” IEEE Software, vol. 8 (1) pp. 32–41.
[8 ]Brooks, Note 1.
[9 ]For example, Boehm, 1989, 1990, note 7.
[10 ]Mark Keil, Paul Cule, Kalle Lyytinen, and Roy Schmidt, 1998, “A Framework for Identifying Software Project Risks,” Communications of the ACM, vol. 41 (11) pp.
76–83.
BEHAVIORS AND STRATEGIES
Given the links between the four risk classes and the project manager, it is appropriate to now explore the possibility of differing behaviors being required of the project manager in dealing with each of the four categories. The following section proposes a set of behaviors appropriate to each link. Each of these links has been named in Exhibit 1 to capture the associated behaviors.
Self Assessment
The link between project manager and the class of risks called Self suggests a behavior that can be called Assess. Because the risks in the Self category concern the project manager’
s abilities, capabilities, and knowledge regarding the
management of IS projects (e.g., Lack of project management skills), the project manager needs to continually assess her capabilities against the project needs. The project manager can then handle any recognized shortfall in capability herself.
Assessment also may need to be done by others — for example, the project manager’
s manager or outside auditors — to identify any shortfalls not recognized by the project manager herself. The Assess behavior requires of the project manager
that she periodically ask questions of herself that are aimed at surfacing the risks in the Self category. Unfortunately, it is difficult to get an accurate answer when people ask themselves such questions as “Am I managing change properly?” “Do I lack effective project management skills?” “Do I lack an effective project management methodology?” Yet these are the first three risk items in the Self category shown in Exhibit 2.
The same problem exists for each of the risk items when phrased by individuals as a question of themselves. Nonetheless, a project manager must ask these questions of herself and answer to the best of her ability. However, there are strategies that can make a project manager more effective in answering these questions. One way is to use independent auditors. This is a viable proposition where there are knowledgeable experienced project managers in-house who can execute an unbiased audit. A second form of audit is to use assessment mechanisms such as those offered by the Software Engineering Institute and its Process Maturity Model.[11] A third way of handling these questions is for the project manager to benchmark other projects and other organizations to compare and learn. These three different, but complementary, strategies may greatly enhance the project manager’
s ability to exercise the Assess
behavior.
Task Control
The risk factors classified as Task (e.g., Insufficient/inappropriate staffing) imply a Control behavior by the project manager in dealing with the risks. It is the task of the project manager to take care of these, thus calling for a task management approach. It is generally this behavioral link that is the subject of project management texts and education and should be ingrained in any experienced project manager. Thus, Assess and Control describe the behaviors required of project managers in handling inside risks. Now, the outside risks need to be addressed.
Environmental Monitoring
The risks that fall under the environment class are those about which the project manager can do little. Some risk items might even be granted the sobriquet “Act of God.” However, should an event represented by such a risk occur, the project manager needs to maximize her lead-time to react. The other type of environmental risk is rooted in the industry environment, competition, and government action.