Project Risk Register

The output of the risk identification process is a list of identified risk events/ conditions and other information needed to provide the context in which the risks can be managed. They are recorded in the project risk register and progressively refined during project risk management processes. The register is often displayed in a table or spreadsheet format.


Risk events occur to the detriment or enhancement of the project and therefore need to be fully described. Common headings in the register are as follows:

• An identification number for each risk.

• A rank for each risk event/condition to indicate its level of severity.

• The name of each risk.

• A description of each risk event/condition.

• The category under which each risk falls.

The root cause of each risk - the real or underlying reason why a probleni/opportunity occurs.

Triggers for each risk or indicators of risk.

Potential responses to each risk.

The risk owner or person who will take responsibility for each risk.

The probability and impact of each risk occurring.

The status of each risk, ranging from newly identified to having been resolved.

Example of a Project Risk Register

Earlier, the example was provided in which the risk of an increase in the cost of airfares was determined as moderate. Using this information and hypothetically allocating the risk an identification number and ranking, the entry in the project risk register could be as shown in Table 8.3.

Table 8.3 Sample entry in the project risk register



Identification number







An increase in the cost of airfares



Root cause

International oil prices are on the increase


Airline increases the cost of its tickets

Response strategy

Mitigate the risk by reducing the number of staff travelling


Student Recruitment Office


1 on a scale of 5


2 on a scale of 5


No notification of cost increase has as yet been received

The structure of the risk register has shortcomings (Ward 1999). If individual risk descriptions are not adequate it will create ambiguity and misunderstanding in the minds of the project team. Interdependencies between risks are not clearly indicated and the tabular form does not provide detail on the interaction between response strategies. Its tabular form and simplicity, however, assist management in gaining an overall feel for project risks.

Implementation of Project Risk Responses

The central theme of this book is to respond to the existence of project risks in a way that adds value. Chapter 2 identified different risk response strategies to protect the value of the organisation and/or create value. While the selection of appropriate responses is important, this is not in itself sufficient without giving attention to implementing these strategies during project risk management. The completion of both processes is critical to project success.

Risk responses decisions are usually made at a high level because of their significance to the project portfolio, while their implementation is at the lower project level. Being outside the decision-maker's direct control has created the concern within management that response strategies are actually implemented. Hopkinson (2011:165) quoted the experiences of a corporate risk manager: 'In the past, my company has been very good at risk identification, risk assessment and risk filing.' Monitoring and control activities should ensure that project risk responses are actioned.


The main document for monitoring performance in implementing project risk responses is the risk management plan. It provides processes that should be followed as well as documentation and reporting requirements. The second important reference is the project risk register since it shows the progress that has been made for each of the identified risk events/conditions. Not only does it define project risk characteristics but also reports their current implementation status (see Table 8.3).

Performance reports communicate to management how project risk responses are developing according to the risk management plan. The reports compare actual achievements to the risk management plan in respect of project risk activities and deliverables at predefined project milestones. Reporting is the responsibility of the project manager (or nominee) and highlights compliance or deviation from the plan. Deviations can be caused by a change to the project itself, project activities uncovering new or changed risk events/condihons, or inadequately defined risk responses.

Variance and trend analysis provide deeper insights by assessing performance in different areas of project activities. For example, project costing should collect and report on the cost of implementing risk responses. Variations, both good and bad, from the original estimation will have to be carefully considered. When the variation is significant it raises a difficult question: should the risk management plan be adjusted to include additional risk activities? This will affect the project's costs and possibly its viability. Alternatively, the temptation may arise to ignore the new situation and avoid making changes in project risk responses.

To lessen the impact of changes, a project risk reserve could be established. Reserves are funds set aside by management for future risk events, and generally refer to the 'known unknowns' of risk. As outlined in Chapter 7, project risk is easier to identify, manage and monitor where information is complete ('known knowns') than when uncertainty is high (the 'known unknowns') or extreme ('unknown unknowns'). It is not possible to predict these risks in detail except to provide a 'reserve' to cater for risk exposure that may occur in future. Reserve analysis compares the remaining reserves (cost and schedule) with the impact of new risk responses. Professional judgement is needed to assess the adequacy of the reserve at any one time because it is dependent on the amount of yet undiscovered risks in the project.


Projects are not static and are periodically evaluated for new risks. Any new risk should be assessed and a change request submitted for approval. The requested change needs to be analysed, its consequences documented and approved, and recorded in the risk register, risk response plan and risk management plan. The risk response is funded from the risk response reserve or, if this is absent or inadequate, through a 'workaround'. This attempts to overcome risks that have emerged by thinking of a response as an alternative to previously determined responses.

Example of Project Risk Response Implementation

In the earlier example of university staff travelling overseas to recruit students there is the risk of missing the flight because of potential traffic jams. The project team has two risk response strategies to choose from. First, if it is critical not to miss the flight, it should avoid the risk of traffic jams. It can check on traffic conditions just prior to departure and choose a route free from traffic congestion. If it wants to reduce the risk, it could arrive at the airport area the night before but may still be caught in a traffic jam when travelling to the airport. The risk is not voided but mitigated. Should the team be confronted by an unexpected traffic jam for which they had not planned a response, the contingency plan would be activated. In it, alternate ways of getting to the airport would have been identified. For example, if there is a high urgency to get to the airport, a helicopter service could be used. To cover costs, funds in the reserve are used. Alternatively, the team has to 'work around' the problem by selecting an alternate route to the airport by trial and error. This is, however, a risky response strategy.

< Prev   CONTENTS   Next >