Risk Management

Introduction

Risk management is something that is more frequently associated with bridge building, mechanical engineering, or actuarial science than digital library projects. Yet, one of the critical aspects of good digital library project planning and management is risk management.

One way of defining “risk” is that risk is a problem that has not happened - yet. While this may be a bit simplistic, it does get to the core of the issue a project manager faces: “What are the problems I might encounter while performing this project and how do I avoid them?”

Given the critical nature of this question, one might think that risk management would be high on every project manager's agenda. Unfortunately, risk management is often not given the attention it warrants. This does not necessarily mean that the project manager does not consider the issues related to risk, but rather that often project managers only perform a superficial examination of the issues related to risk and then add a “margin for risk.”

Enterprise Risk Management is a process, affected by an entities board of directors, management and other personnel, applied in strategy setting and across the enterprise, designed to identify potential events that may affect the entity, and manage risk to be within its risk appetite, to provide reasonable assurance regarding the achievement of entity objectives.

Risk factors

Understanding the process of risk management entails understanding the underlying factors that contribute to project risks. The project management literature is strewn with investigations into project risk factors and repeatedly investigators find many of the same risk factors, regardless of the nature of the project.

As Keil et al. (76-83) have noted, the most common risk factors are remarkably consistent across projects:

lack of top management commitment to the project;

failure to gain user commitment;

misunderstanding the requirements;

lack of adequate user involvement; and

failure to manage end user expectations.

One point that is especially interesting here is the use of “commitment” rather than “support.” Keil et al. point out that this distinction is critical. It is easy to support a project by throwing money or empty words behind it; it is an entirely different thing to actively work on the behalf of a project and to continue to do so for the long haul. Project managers need this latter type of support (Larsson et al, 5-11).

To this litany of risks, Jones (1994) adds that projects involving information technology are also particularly subject to the following additional risk factors:

creeping user requirements;

excessive schedule pressure; that is doing too much in too little time;

low quality work as a result of undue pressure;

cost overruns; and

inadequate configuration control.

Many, but not all, of these factors are caused or exacerbated by inadequate evaluation of the various categories of risk that are inherent in every project.

Risk assessment

It is one thing to identify and outline a long list of (potential) problems, but it is a significantly different matter to try to address them. This is where risk assessment comes into play.

The first step in risk assessment is risk identification. In risk identification, the team looks at all of the ...