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.[—]

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





• Mot Managing Change Properly

• Lack of Effective Project Management Skills

• Lack of Effective Project Management Methology

• Improper Definition of Roles and Responsibilities

• Mlsunderstandig the Requirements

• Poor or Non-Existent Control

• Pool Risk Management

• Choosing the Wrong Development Strategy

• Lack of" People Skills' In Project Leadership

• Project Not Based on Sound Business Case

• No Planning or Inadequate Planning

• Bad Estimation

• Lack of Effective Development Process/Methodology

* Trying New Development Method/Technology During Important Project

* Lack of Required Knowledge/Skllls In the Project Personnel

• Poor Team Relationships

* Insufficient Staffing

• Excessive Use of Outside Consultants

• Lack of Available Skilled Personnel » f ntrod uct io n of N ew Te ch no logy

* Stability of Technica Architecture

* Multi-Vendor Projects Complicate Dependencies





* Lack of Top Management Commitment to the Project

* Failure to Gain User Commitment Conflict Between User Departments

« Failure to Get Project Plan Approval From All Parties

* Failure to Manage End User Expectations

* Lack of Adequate User Involvement Lack of Cooperation from Users

* Failure to Identify All Stakeholdets

* Growing Sophistication of Users Leads to Higher Expectations

* Managing Multiple Relationships with Stakeholders

- Lack of Appropriate Expe rience of the User Represe ntatives

* Unclear/Misunderstood Scope/Objetlves

* Number of Organizational Units Involved

* Lack of Frozen Requirements

* New and/or Unfamiliar Subject Matter for Both Users and Developers

* Under Funding of Development

* Under Funding of Maintenance

* "All or Nothing"

* Artificial Deadlines

• A Climate of Change in the Business and Organizational Enviroment that Creates Instability In the Project

• Mismatch Between Company Culture and Required Business Process Changes Needed for New System

• Project that Are Intended to Fail

• Unstable Corporate Enviroment

• Change in Ownership or Senior Management

• "preemption" of Project by Higher Priority Project

• Staffing Volatility

» External Dependencies Not Met

• Lackot ControlOverConsultants,Vendors,andSub-Contractors

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.

[—]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.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment