Purpose

Risk models are designed to provide a consistent up-front assessment of the relative levels of risk and opportunity associated with a given project. They are also used to highlight any specific risk areas endemic within the organization. The models provide an at-a-glance risk assessment without the detailed qualitative and quantitative analyses typical of later stages in the project.

Application

Risk models consist of a series of questions or objective assessments related to the risk posture of the organization. The questions may be simple binary assessments (e.g., “Have the project requirements been developed and traced into the WBS?”) or weighted evaluations (e.g., “What percentage of the requirements have been developed and traced into the WBS?”). In either case, the organization-critical risks are presented in a consistent format so the answers from one project may be compared with the answers from another. This relative evaluation can serve a variety of functions. It can be used to identify areas of risk specific to the project. It can provide a sense of the relative need for management attention from one project to the other. It can be used to establish contingency budgets, because those projects with higher risk may merit higher cost or schedule contingencies.

Content

Some risk models may simply include a massive list of questions, where the greater number of “high-risk” responses indicates a higher level of overall project risk. One of the most exhaustive such lists was generated by the Software Engineering Institute in their Taxonomy-Based Risk Identification incorporating almost 200
questions relevant to the potential risks associated with any project.
Other models will include more organizationally specific content, focusing on the nature of risks (and sometimes opportunities) within the organization. In those types of models, the risks are often weighted according to their relative levels of importance as in the following example:

Risk Area: REGULATORY COMPLIANCE (Weight: 8) High (3)—Project is subject to multijurisdictional reviews/regulations. Medium (2)—Project is subject to regulations from a single jurisdiction. Low (1)—No regulatory influence.

Risk Area: DATA SECURITY (Weight: 4) High (3)—Data will be made available via the Internet. Medium (2)—Data will be made available via networked terminals. Low (1)—Data will be available only within the “closed” system.

Projects are assessed by reviewing their condition and multiplying that score by the weight of the issue under consideration. A project facing multijurisdictional reviews, for example, would merit a risk score of 24 on that issue. A project facing multijurisdictional reviews and presenting information over the Internet would have a total score of 36 (Regulatory Compliance Score: 24 + Data Security Score: 12).

The content is determined by management teams as being the areas that pose the greatest potential threat to the organization or to the project in terms of long-term success. The objective assessment criteria should be established by teams who know and understand the nature of the organization’s risks. The criteria should be established by those who understand the signs early in the project that are harbingers of those risks.

Approaches

This approach affords organizations the ability to focus on risk areas specific to their culture and to balance the lesser (but still noteworthy) risks against those that inherently pose a greater threat. Some such risk surveys will include only threat-oriented questions, while others will compare or contrast information related to opportunity as well.

In any case, the model scoring can be used to establish percentages of budget contingency or schedule contingency appropriate to the project, given its risk relative to other projects in the organization. A project scoring high in a risk model may merit a significantly higher contingency reserve than a project with relatively low risk.

Considerations

As with any metric model, it is possible to skew the outcome by modifying the assumptions associated with the project. Thus, some model developers require that any analysis conducted is accompanied by an assumptions document that captures the environmental considerations taken into account in completing the model.

In some organizations, there have been problems with project managers who have modified the questions, the answers, the weighting scales or other components of the models. To be deployed effectively, risk models should be applied consistently from project to project. Good models will incorporate a warning as to which elements of the model are not subject to modification.