GPM First
Chapter 7 of Gower Handbook of Programme Management (978-0-5660-8603-8) by Geoff Reiss, Malcolm Anthony, John Chapman, Geoff Leigh, Adrian Pyne and Paul Rayner

Management of risks and issues



7.1 Introduction

The management of uncertainty is a fundamental activity within any programme. These uncertainties take two main forms – risks and issues:

  • Risk is some event or set of circumstances that may occur in the future and which, if it does occur, will prevent the programme from achieving its objectives.

  • An issue is something that may prevent the programme from achieving its objectives unless some action is taken that is outside the normal cycle of management. Frequently issues are caused by a current lack of knowledge and understanding and therefore the required action is to investigate the matter.


Risks and issues are connected in that some issues, on investigation, may be identified as risks. However, not every issue will be so identified. As the diagram in Figure 7.1 shows, some may be identified as potential changes whilst yet others may turn out to be of no significance and may be ignored.

As can be seen in Figure 7.1, issues may be identified at the programme level, or may be escalated from component projects that make up the programme. One of the responsibilities of the programme management team will be to ensure a common understanding of the circumstances in which such issues should be escalated.

All issues should be recorded and assessed and some may need further investigation before an appropriate action can be agreed. However, not every issue will warrant action: even in the largest programme time and resource is limited and attention must be focused on the most important issues and risks. Accordingly many will be assessed as being not significant.

Some issues may require changes to be initiated. These may not result in formal requests for change, as discussed in Chapter 12 ‘Management of scope and change’, but may merely require adjustment to planned actions that do not compromise any of the agreed parameters of the programme. After all, adjusting to circumstances is a key function of management.

Figure 7.1 Basic issue and risk management process


Usually only a portion of the issues will actually, upon investigation, turn out to be risks.


7.2 Issue Management

Most people seek to overcome the day-to-day uncertainties of their jobs without involving their superiors. However, there will always be circumstances that are outside their knowledge or ability to cope. For example, they may discover that there is a misunderstanding about requirements: what the customer appears to be expecting is different from what the supplier is planning to deliver. Resolving such a situation may be outside their authority, ability, or they may not have the time to handle it. Accordingly, it is an issue that must be resolved and a formal process will be needed to ensure that it is not lost or forgotten.


7.2.1 Escalation Of Project Level Issues

Within a programme, issues may be identified by those working within component projects (that is at the ‘project level’) or by members of the programme management team (that is at the ‘programme level’). Wherever possible, project-level issues should be resolved within the projects. However, some issues will need to escalated for management at the programme level. These include:

  • issues that are so big or complex that the project has insufficient resource or capability to resolve it;

  • issues that result from the relationship between component projects and thus need ‘programme level’ adjudication;

  • issues that will affect all projects and would thus benefit from a programme-wide solution;

  • issues that relate to the programme as a whole, such as the management of programme objectives; and

  • issues that relate to the delivery of benefits after project deliverables have been delivered.


It is the responsibility of the programme management team to provide guidance on when issues should be escalated from projects to programme level.


7.2.2 Issue Capture

Various techniques can be used to capture issues. A common approach is to use the regular progress reporting meetings. These meetings include those at which project managers meet with programme management staff, and those where programme management staff meet with key stakeholders.

Some programmes also provide facilities for the programme team to report issues; for example, by means of an Internet-based issue recording system. This latter approach has the advantage of ensuring that all can record problems, but the ability to easily record a problem as an issue may encourage some to pass the work to someone else rather than to resolve it themselves. As a result, this approach requires a greater degree of administration and management control since more issues are likely to be captured and all will need to be assessed and allocated to someone for investigation and/or action. An approach to resolving this problem of potential overload is to require every such issue to be endorsed by a project manager, team leader or phase manager. The manager should consider and then either approve, modify and approve or reject the issue. Acceptance will cause the issue to be added to the issues register.


7.2.3 Issues Register

Whatever method is used, all genuine issues should be recorded on an issues register (see Figure 7.2). Typically, this will record:

  • Unique identifier or reference number.

  • A description of the issue.

  • The person raising the issue (and/or their manager).

  • An owner: an individual or role that takes responsibility for managing and monitoring the issue.

  • The work that may be affected: This will normally be a single task but might refer to a phase of a project, a project, a number of projects, delivery of one or more benefits or a complete programme.

  • The estimation of the impact of non-resolution of the issue expressed in a common way.

  • Timing, which may include:

    • – date of raising the issue

    • – expected date for resolution, such as the date by when investigation must be completed.


  • Response task: a task given to an individual or team to manage an issue. A wide variety of actions may be taken to deal with issues and if these are significant they may have to be treated as project or programme tasks in their own right, thus requiring a change to programme or project plans.

  • Status: this may indicate:

    • – ‘Live’ – a current issue, being investigated or managed.

    • – ‘Closed’ – an issue that has been dealt with. It may now be regarded as a change or a risk; alternatively, it may have been revealed, upon investigation, that it was not, in fact, a problem. If now regarded as a risk, it will be recorded on the risk register and allocated a reference number.

    • – ‘Dead’ – issues that no longer pose a threat.



Figure 7.2 Example of an issues register


In this way, the programme issues register will contain all programme-level issues and show the status of each. It will allow the programme management team to consider the status of issues and any planned actions and ensure that all are addressed in a timely manner. This is important since there is often an urgency to ensure that issues are attended to in a timely manner to prevent delays or overspend. It may also be possible to generate statistical data on issues and their states to allow senior management to understand the trends and quantities of issues without being involved in specific cases.


7.3 Risk Management

Because programmes are initiated to create a better future, they must always cope with uncertainty. Nobody knows what the future will bring, but the more astute can usually detect trends and pitfalls, often based upon the experience gained from previous programmes and projects. However, these trends and potential pitfalls are not certainties, merely possibilities. If they were certainties, appropriate actions to cope with them would have been built into programme and project plans. But such actions involve costs and, because risks are only possibilities, it would be wasteful to plan and pay to cope with every one. Accordingly, a considered process is required where the cost incurred is proportionate to the risk.

Furthermore, our worst fears about the future are rarely justified. Whilst some risks actually do occur, many do not. Therefore, an objective of the risk management process is to ensure that appropriate resources are available to cope with the risks that do occur, but a minimum is wasted on coping with those that do not.

Risk management can thus be defined as:

The task of identifying risks associated with a particular course of actions designed to deliver a particular outcome. Once identified, those risks are managed to limit the potential of adverse results and achieve the desired outcomes.1 [8]



7.3.1 Objective of Risk Management

The purpose of risk management is to prevent future events from disrupting the achievement of the programme’s anticipated benefits. Since the potential incidents that could occur in the future are virtually unlimited, including war, pestilence and famine, the resources that could be committed to risk management are also potentially unlimited. In practice, the resources are limited by the scale of the benefits that the programme is expected to deliver and thus they must be used where their impact is greatest.

For this reason, it is usual to measure risk and thus permit risk management activities to be focused where they make the greatest contribution to ensuring the certainty of project success.

Some risks are so all embracing that standard procedures and mechanisms will already be in place. For example, the risk that staff will stop work if they are not paid is so great that all organizations put in place payroll systems to ensure regular payment of wages and salaries. Similarly, the risk that quality will be sacrificed in order to save time and money is so great that all programmes will implement comprehensive quality assurance procedures, such as those described in Chapter 8, ‘Programme quality management’. Risk management handles specific risks that these generic processes fail to cover adequately.


7.3.2 Measurement of Risk

Two factors combine to allow the measurement of the size of each risk:

  • Probability: the estimated likelihood of a particular outcome actually happening;

  • Impact: the evaluated effect or result of a particular outcome actually happening.


The term exposure refers to the combination of these two estimated factors. The task of risk management is the management of this exposure to an acceptable level, by taking action on either probability, impact or both; it therefore requires identification of the elements to be considered, not all of which may be controllable. It is not necessary or possible to eliminate all risks but it is necessary to recognize and manage risk at all levels.

Within a project, the objective of risk management is primarily aimed at the risks of failure to deliver the expected deliverables in a timely, cost-effective way. Within a programme, by contrast, the objective is to ensure that the required benefits are delivered in a timely and cost-effective way. Therefore the impact of a risk should be expressed in terms of its effect on the programme’s objectives. For example, the impact of a delay on a programme that has an objective of making a measurable reduction on an organization’s running costs, would be to delay the date at which running costs are reduced. In many programmes, understanding the impact of a risk will involve understanding the complex chains of benefit on which the programme is based, as described in Chapter 5, ‘Benefits management’.


7.3.3 Qualitative Assessment of Risk

The degree of precision with which exposure needs to be measured will vary from programme to programme and from organization to organization. It may even vary from risk to risk. For example, risks to the trajectory of an inter-planetary space probe may need to be measured extremely accurately since only a fraction of error may cause the vehicle to completely miss its target. By contrast, estimates of the exposure of a business change programme on a particular group of stakeholders cannot be measured precisely and spurious precision in estimating impact could actually be counter-productive.

In practice, most organizations use a fairly rough and ready ‘qualitative’ approach to estimating exposure, typically based on grading likelihood and impact on the basis of ‘high’, ‘medium’ or ‘low’. Even this crude approach will result in nine possible gradings of exposure, as demonstrated by Figure 7.3.

Figure 7.3 Example of a summary risk management profile


Because management time is limited, only the more serious risks (that is, those with the greatest exposure) can be actively managed. The others will merely be recorded and kept under observation to ensure that greater knowledge or changing circumstances does not alter the assessment of impact or likelihood. Thus, for any programme, and potentially for any particular category of risk, you can draw up a risk management profile, which identifies the level of exposure that will trigger active risk management.

In the example in Figure 7.3, only risks where the impact or likelihood are rated as ‘high’ and the impact of the other aspect of exposure is ‘medium’ or ‘high’ will be so managed. Thus Risk A (‘high’ impact, ‘high’ likelihood) and Risk B (‘high’ impact, ‘medium’ likelihood ) will be managed, whereas: Risk C (‘high’ likelihood but ‘low’ impact) and Risk D (‘medium’ likelihood and ‘medium’ impact) will be merely kept under observation.


7.3.4 Quantitative Assessment of Risk

In some programmes, differing levels of tolerance will apply to differing types of risk, depending upon the criticality of the objective that they impact. For example, where completion dates are critical, it may be appropriate to use Monte Carlo analysis to determine exposure.

This refers to a technique that applies probability to complement traditional critical path analysis in order to estimate likely project durations, so named because it uses randomness in the same way as the casinos at Monte Carlo. From this, the likely delivery dates for various programme benefits may be calculated.

Within a traditional critical path model, planned activities are connected by dependencies that demonstrate how each task depends on the others. Each activity is given an estimated duration and these dependencies are used to provide an analysis of the plan giving a single overall estimated duration of a project and calculation of float. Some activities will be on the critical path and determine the overall project direction. Others will lie off the critical path and may be extended in time without affecting the project completion date.

To permit Monte Carlo analysis, a range of possible durations is added to each task and thus to the likely completion date. For example, it may be estimated that in ideal circumstances a task will take 3 weeks, in normal circumstances 5 weeks and 8 weeks in a worst case. It is also possible to include an estimate of a likelihood for each duration. For example, when servicing an aeroplane, removing an inspection hatch may have a 25 per cent chance of being followed by no work, a 50 per cent chance of being followed by a simple servicing operation, and a 25 per cent chance of being followed by a major replacement.

Once such a model has been built, it may be analysed many times using random selections of activity durations and logical links. The result is a graph relating overall project duration to likelihood and in some situations is very relevant and a vast improvement on a single crude estimate. An example of such a graph is shown in Figure 7.4.

Figure 7.4 Example of a Monte Carlo probability profile


This technique is expensive and time consuming and usually requires specialist computer software, but may be appropriate where unusual challenges are to be faced. It is widely used in the heavy engineering and construction industries, where time overrun will result in serious financial losses to the contractor.2 [9]


7.4 A Risk Management Framework


7.4.1 Risk Management Strategy

Some programmes are, by their nature high risk, for example, new product launches in competitive markets. Furthermore, some organizations are very risk averse; they commit to programmes only where risks are small and very manageable. It is important to understand for each programme what level of risk is to be expected and accepted, often referred to as the ‘risk appetite’. This would normally be defined in a risk management strategy, which would define how risks are to be managed throughout the programme. Typically, it would identify:

  • the overall approach to managing risk

  • the techniques for measuring and assessing

  • roles and responsibilities

  • guidance on escalating risks from project level to programme level

  • arrangements for review

  • special techniques to be used, including those for handling contingency.


Any such strategy will need to identify the cyclic nature of risk management. As the programme progresses, new risks will be discovered while old risks will cease to be significant. Because of this, risks should be subject to regular review and revision throughout the life of the programme. However, it is vital to have a good grasp of likely risks at the start, since coping with them may consume a significant amount of time and effort and may thus be a major consideration in the initial business case on which the whole decision to proceed with the programme was based.

The risk management strategy will thus need to be built around a lifecycle along the lines shown in Figure 7.5.

The risk management strategy will provide a framework within which risks will be identified, analysed, controlled, monitored and reviewed. The following sections describe the components of this framework in further detail.

Figure 7.5 Risk management life cycle



7.4.2 Identify And Record Risks

There will be areas of risk that are common to many programmes and the identification of common areas of risk will help each programme and project team to locate appropriate risks. It is difficult to consider the right number of risks. While it is tempting to protect oneself from criticism by listing every possible risk no matter how unlikely and minor the impact, this will tend to cloud effective decision making. On the other hand, it is easy to miss important risks and therefore commit to a programme in ignorance of them. To find a balance is a matter for experience and will vary from organization to organization.

An analysis of past programmes will provide expertise to help the risk management of new programmes. This is an especially valuable way in which to use learning lessons from historic work to help in new challenges. An example of such an analysis, summarizing the experience of the IT Department of a multi-national financial organization, can be found in Case Study 7.1.


This checklist summarizes the experience gained from previous programms and will help to identify likely risk areas in new programmes.

  • Customer: The customer (that is, the business or the user) may not have the technical or commercial expertise to perform adequately their obligations with respect to the project in the manner that you expect. For example, they may be understaffed and thus find it difficult to release people from their normal work for programme activities or there may be no suitable person to act as user representative.

  • Other group companies/divisions: Other parts of the firm may be involved and they may not have your understanding of what is required or your commitment to achieving success.

  • Development partners and collaborators and other third-parties: External suppliers of software, hardware and other services may not fully understand their obligations and may not be as careful or as competent as you would wish.

  • Estimating development effort: The estimates of the work required may not be accurate.

  • Technology: Some of the proposed work may involve technology that is new or untried or new to the organization. There is thus a risk that problems are underestimated and/or that the technology may under-perform or fail totally.

  • Business critical issues: It is one thing for implementation of a new, improved method of working to be delayed. It is another thing if the new system damages the company through failing to correctly perform some business critical function.

  • Effect of other programmes or projects: Other programmes and projects may impact on this by using up resources and management time or because they provide an essential component to this one.

  • Scope of Supply: The definition of what is required must be sufficiently complete, consistent, stable and understood by all parties to ensure that estimates are based on what is actually wanted and to minimize subsequent ‘scope creep’.

  • Hidden and unspecified programme objectives: There may be unstated requirements assumed by the sponsor that have not been explicitly excluded from the programme – exposing the programme to the risk of argument upon completion.

  • System performance: The performance requirements may be unclear, or there may be no clear-cut way of measuring whether or not they have been achieved.

  • Timescales: The timescales insisted upon by the customer may be impractical or may become so if the customer delays giving their acceptance of the proposal.

  • Acceptance: If the acceptance requirements and procedures are not well defined, the customer may be able to delay acceptance or insist on late changes.

  • Price versus cost: Pressures to keep the cost within pre-defined budgets may have led to an underestimate of costs and contingencies.

  • Staffing: It may not be possible to assign the required number of suitable staff, or key staff may be deficient in specific experience.

  • Compliance, evaluation and certification: the need for legal and statutory compliance may impose uncertainties delays and costs, for example:

    • – establishing what is actually required

    • – evaluating whether the requirements are met

    • – obtaining formal assessment and certification that they have been met.


  • Customer liaison and progress monitoring: Arrangements for progress review, for sign-off of documents and for handling requests for change need to be clear, agreed and allowed for in time-plan and estimates.


Another common approach is to conduct a brainstorming session. The people involved must be knowledgeable individuals who bring different viewpoints, for example, business manager, commercial manager, QA consultant, project managers, design authority from a similar project and members of the programme team. Where it is not possible to get such a wide range of people together into a single meeting, it may be appropriate to conduct structured interviews.

Once initial risks are identified, they should be recorded in the programme risk register. Similar documents should also exist within each project for recording risks identified at project level.

A typical risk register will record:

  • a unique identifier or reference number;

  • a description of the risk;

  • the benefits or programme objectives that it appears to impact;

  • the source – where the risk came from, for example, escalated from a component project;

  • the ownership, that is, the person responsible for investigating and assessing and evaluating the risk.


Subsequently, when the risk has been evaluated, further information will be added:

  • impact, likelihood and exposure, plus any date dependency;

  • agreed responses, including containment mitigation and contingency arrangements;

  • person responsible for implementing responses;

  • current status of risk; the status may be:

    • – Open – being investigated

    • – Active – subject to active risk management, with agreed responses to be implemented

    • – Non-active – not currently deemed sufficiently important to warrant active management

    • – Closed – this risk is deemed no longer likely to affect the programme.



Several software packages are available to record risks. However, many find that a simple database is adequate. Such a database will allow risks to be listed according to responsibility, objective affected, and so on, and these listings can be used to monitor responses at regular progress meetings.

Examples of entries in a risk register can be found in Case Study 7.2. In this example, detailed information on each risk is recorded on an assessment sheet and then summarized in the risk register summary.



Sample Risk Register – Summary Sheet

Project title:

New wages software

Issue date

30 April


New Wages system




Risk description

Risk containment plan

Date raised

Date of impact

Risk contingency plan

Likelihood %

Impact (high/med/low)


Delay in special keyboard supply

Proactive subcontractor plans, early delivery, customer involvement. Penalty clause in supply order



Monthly progress reviews with contractor – consider another supplier




Overrun software development

Include extra 30% effort in plans for software 1100md

1 March

4 June

Monitor the modelling component very closely – expect effort overrun




Delay in user acceptance

Advise user group of test philosophy. Include extra review time in plan, and slack of one month prior to ship. No extra effort

2 April

16 June

Allow 2 weeks contingency on Acceptance Test Schedule




Once completed, the initial risk register will usually be submitted to the appropriate authority (for example the programme board) for endorsement. It will also be subject to review and updating on a regular and planned basis, as described in Section 7.4.10 ‘Update risk register’.


7.4.3 Evaluate Risks

Risks to projects tend to be relatively easy to understand. By contrast, risks to the success of a programme tend to be complex. For example, evaluating a risk within a programme aiming to automate patient records within a hospital may require a thorough assessment of how the risk will impact on each stage of the various benefit chains as described in Chapter 5 ‘Benefits management’. The sample benefit model shown as Figure 5.4 summarizes the various possible factors that might have a bearing on potential patient litigation that would be impacted by the patient record system.

Many risks can only impact a programme during certain time periods or phases. A classic example of this is provided by the famous ‘Year 2000’ problem, where many computer programmes were feared not to be able to cope with the change of date from the 20th century (for example, 30–12–99) to the 21st century (for example, 01–01–00). The majority of such risks would occur, if they occurred at all, during the first few days of the year 2000 and, if they had not materialized during that period, they could be ignored. Thus a risk which would have been classed as ‘Active’ during the final days of 1999, would have been flagged as ‘Closed’ once the year-end transition had been completed.


7.4.4 Measure and Evaluate

Once the risk has been evaluated, its exposure can be calculated, in the manner discussed above in Section 7.3.2 ‘Measurement of risk’.

Those that have a high exposure and will need specific responses to be implemented or allowed for will be marked as ‘Active’ in the risk register. Those of lower priority will be marked as ‘Non active’.


7.4.5 Agree Responses to Risk

The ultimate purpose of identifying and assessing risks is to initiate appropriate responses. These responses fall into two broad categories:

  • actions that should be undertaken to prevent, contain or mitigate the impact or occurrence of the risk;

  • actions for which a contingency should be allowed, which will only be used should the risk actually occur.


Agreed actions should all be summarized within the risk register.


7.4.6 Containment

Containment activities are undertaken whether or not the risk event actually occurs. For example, in an e-commerce programme, there may be a concern that an initial rush to use the new capability may be such as to swamp the computers and cause the service to collapse. An appropriate mitigation action might be to hire and install on a temporary basis additional computer servers to cope with any such a rush. The problem with such an approach is that the costs are incurred whether or not the rush occurs. An alternative approach might be to prevent the risk by requiring users to pre-register and limiting those who do to the capacity of the system.

The containment plan is a plan for containing risk to acceptable levels. It may seek to eliminate the risk entirely. Alternatively, it may not eliminate the risk but manage it in an agreed and understood way.

Containment activities are implemented during the life of the project or programme and must be put in place before the risk might occur.

Sometimes, it may make sense to adjust plans so that the risks occur earlier. For example, where there is uncertainty about whether or not it will be necessary to modify software from a supplier, scheduling for early delivery will allow time to make the modifications without disrupting other project activities. Of course, this may increase planned costs (if only in cash flow charges) but the reduced potential impact may allow the programme to reduce the contingency required to cover possible disruption to the other activities.

One approach to coping with risk is to transfer its impact to another party. A frequent request from public sector organizations is for external contractors to ‘share the risk’. Thus, for example, those tendering to supply a new Internet-based service may be required to base their remuneration on the number of citizens that actually use the service.

Another approach is to pass as much of the risk as possible to suppliers or customers. Through clear terms and conditions, it is possible to pay another party to bear part of the risk. Currently this approach is very much in favour with UK public bodies, who seek to put as much as much of the risk associated with building new public facilities such as schools and hospitals onto the external contractor through Private Finance Initiatives and similar contractual arrangements. However, nothing comes free and the cost to the public purse of operating in this way is higher than with traditional procurements. Furthermore, it is rarely possible to remove risk completely this way, as involving a contractor carries risk in itself.

It is important to remember that risk containment tasks may give rise to secondary risks. For example, the hiring of extra computer equipment may create a risk of incompatibility with existing equipment. Where such secondary risks are not covered within the containment plan and any related contingency plan, they should be raised as new risks and processed accordingly.

A single containment plan may apply to a number of risks and there is often a ‘many to many’ relationship between risk reduction tasks and risks. There may be a containment plan for risks on a specific project or programme or more general containment plans for all programmes in an organization.


7.4.7 Contingency

In contrast to containment, contingent activities only take place if the event occurs. In the e-commerce programme described above, an initial rush might also overwhelm the staff that pick, pack and despatch products. However, it may be possible to cope with a temporary rush by hiring in temporary staff from a recruitment agency. Since these can normally be brought in at short notice, there is no need to commit to such action ‘up front’. Instead, the extra staff need only be hired should the rush actually occur. Such staff will be expensive and budgets must contain a contingency fund to pay for them. However, if an overwhelming rush does not occur, the money will not need to be spent and may be reabsorbed as profit or allocated to some other purpose.

Because only some of the identified risks will actually occur, it is rarely necessary for the contingency fund to be large enough to handle all risks. Instead, it is normal to discount the contingency by the likelihood of occurrence. Thus, if coping with a risk would cost £100 000, but there is only a low probability of it occurring (say less than 20 per cent), contingency fund of only £20 000 would be allowed.

The important point to remember is that the contingency that you include in your programme plan is only an allowance to cover possible future risks; it is unlikely that it will be adequate to cover fully the impact of all of the risks should they occur. The best that can be expected is that if every component project within the programme includes adequate allowances, then the aggregate effect over a long time and over all the projects within the programme will effectively be neutral – that is, some component projects will have bad luck and use up relatively large amounts of contingency, but most will not and the total amount of contingency used will thus be equal to or less than the total amount allowed.

The rules for using contingency, and the authority for deciding on its use, will usually be defined within the risk management strategy. Typically, projects may only be able to call on the contingency fund with the approval of the programme manager, while the programme can only use the fund with the authority of the programme board.

Containment and contingency arrangements can be expensive. In some major IT-based initiatives, 20 per cent to 30 per cent of the cost may be consumed in such arrangements. In politically sensitive programmes, which depend upon the continuing goodwill of the government, contingencies can be even higher. Accordingly, it is vital for initial business cases to include them.

Note that, although the examples given above all relate to money, contingency can also refer to time and effort.

If there are many small risks (low likelihood/low impact) and a few big risks (high likelihood/high impact), it may be sensible to manage the small risks in a single containment plan and a single contingency plan. This will enable the programme’s management to concentrate on preparing the plans for the big risks.


7.4.8 Implement Responses

All prevention, containment or mitigation activities must be adequately completed to have effect. Accordingly, they will need to be included in programme and project plans and their completion monitored in the same way as other programme and project activities.


7.4.9 Review

Throughout the life of the programme, risk exposures will change as circumstances change and existing plans for managing them may become irrelevant or inefficient. New risks may emerge, old risks may disappear and risks may change in terms of likelihood and impact. If properly managed, some of the changes may be advantageous.

Typical sources of change are:

  • Timescales: The timing may have changed, in particular the start and end dates.

  • Requirements: The customer requirements may have changed.

  • Terms and conditions and service level agreements: The detailed terms and conditions or service level agreements for doing the work agreed during programme initiation may have changed the risk.

  • Suppliers: Suppliers may have ‘upgraded’ their offerings or may now offer alternatives with better performance and/or price.

  • Non-customer agreements: Agreements with contractors, and so on, may no longer reflect the final contract, in particular quotations may no longer be valid.

  • Staffing: Staff available to the programme management team may have changed or be more expensive.

  • Knowledge: Research may have provided a better understand of technical risks.


Because of such changes, it is necessary to review the risk registers at regular intervals and revise them appropriately. The stages in your review of risks are:

  1. Review and update the risk register: What changes are needed to the risk assessments and their associated containment plans and contingency plans?

  2. Update the programme and project plans: What changes are needed to the project plan to reflect changes to the containment and contingency plans?


Risk management is not necessarily either sequential or compartmented. Different aspects may proceed in parallel and there is constant iteration amongst the various activities. New options for handling risk are always being created. The programme manager should try to anticipate changes so that they can influence their impact, rather than just responding to the changes when they occur.

It is therefore essential to have a short review of risk at many stages of the programme management process. At this occasion, the team should consider what new risks have emerged, asking what risks need no longer cause concern and what existing risks need to be modified to reflect the latest position. Changes to the risk register should reflect these changes and may be audited to maintain records throughout the programme lifecycle.


7.4.10 Update Risk Register

The risk register should be kept up to date throughout the life of the programme. This will provide a consistent set of up-to-date assessments of the various risks and the plans to handle them. This then provides one of the major sources of information against which to monitor the programme and against which to prepare revised plans from time to time.

In major programmes, maintaining the risk register and associated assessments and liaison can be a full-time task, allocated to a risk manager. Such a person may also have control of risk contingency funds. However, identifying risks and drawing them to the attention of the project or programme management teams is the responsibility of all who work within the programme.

After each major review of the risk register, it is usual to present a report to the programme board so that it can reappraise the likely success of the programme.


7.5 Conclusion

Cardinal rules for risk management:

  • Do no harm. No risk should be greater than the benefit. Don’t replace one risk by another greater one.

  • Try to make small improvements at each stage. Risk management cannot predict whether or not events will occur. The goal is to improve, constantly and in measured steps, the probability of success or the opportunity for success, whenever feasible.

  • Never focus on future intentions, always on current capability. Don’t fool yourself into thinking that, because there are intentions to do something, things will work out that way. Risk management is based upon what feasibly can be accomplished not what is hoped to be accomplished.

  • Without management commitment there can be no effective risk management. If senior management such as the programme board neither actively supports nor foresees the need for risk management, then there is little point in pretending to do it.



[1] PRINCE2 is a widely used methodology, sponsored by the UK Government’s Office of Government Commerce (OGC). PRINCE® is a registered trade mark of OGC.

[2] The programme office typically has a major responsibility with respect to such ‘programme-level’ functions – see Section 3.4.6 ‘Programme support’.

[3] These statistics are based upon information within the databaes of the Programme Management Maturity Model, described in Chapter 15.

[4] Key points are typically, end of Start-up stage, approve the brief; end of Define stage, approve the programme definition and permission to start first tranche; end of each tranche, permission to close that tranche and start next tranche; Closure stage, permission to close programme, see Chapter 2 ‘The programme management process’ for more details.

[5] Gateway Reviews are independent checks of major public-sector programmes organized by the UK’s OGC. Such reviews must be conducted at key stages to ensure that the programme still makes good business sense, before it proceeds to the next stage. The ‘Level 4’ Review veritifies that a programme is ready to ‘go live’ and that the Business Case still stands up. The subsequent ‘Level 5’ Review takes place after ‘go live’, to confirm that all necessary arrangements are in place to maximize the benefits achieved from the programme.

[6] ‘Getting Better Value From IT Investments’, organized by ProgM and PROMS-G, 10 April 2003, Inmarsat Conference Centre, London, UK. PROMS-G is the Project Management Special Interest Group of the British Computer Society (BCS) and ProgM is the joint Programme Management Special Interest Group of the BCS and the Association for Project Management

[7] This table is created by copying information from the Gantt chart, which has been prepared in the Microsoft Project program, into a Microsoft Excel® spreadsheet. A pivot table is way of quickly sorting large amounts of data. Its rows and columns can be rotated to show different summaries of the data, and it can display the details of areas of interest.

[8] A definition provided by the UK’s Office of Government Commerce (OGC) in its Successful Delivery Toolkit (2005).

[9] For further guidance on this technique see Vase, 1999.

[10] Change control should not be confused with organizational change management, which is the responsibility of the change manager and is discussed in Section 5.7.1 ‘The change manager’.

[11] In the UK, building societies provide savings bank and housing mortgage services to the general public. Originally they were mutually owned by their depositors and lenders, but over recent years many have converted themselves into joint stock companies or been taken over by major banks. In the USA, similar services are provided by ‘savings and loans’ organizations.

[12] Numbers in square brackets [ ] are references to documents that are identified in the List of References in Section 1.7.

[13] Of course, while a particular programme may be unique to the business unit experiencing it, the programme may have similarities with programmes undertaken elsewhere or earlier programmes undertaken within the same organization. Thus there may be pools of experienced staff who have already faced and resolved similar issues and challenges elsewhere. This is one reason why organizations engage external consultants with prior experience to play leading roles within their programmes.

[14] The web site lists 47 different interpretations of the acronym FM, including ‘Foreign Minister’, ‘Fault Management’ and ‘Filosofian Maisteri’ (the Finnish equivalent of a master’s degree).

[15] In many corporate cultures such delay would be in the interests of the programme or project, since any indication of difficulty results in a flurry of demands by senior management for meetings, information and progress reports which consume so much time and effort that the eventual delay is even greater than might otherwise have been the case.

[16] For a list of books by Maslow see For a summary of his hierarchy of needs theory and other theories of motivation see Kakabadse et al. 1987.

[17] Nowadays, creating such a portal is relatively easy. For example, ProjectPlace will allow a readymade portal to be rented. Details of ProjectPlace can be found at

[18] A number of such tools are readily available, including Survey Shack, which can be accessed via the Internet at

[19] See Chapter 2 of this handbook for a description of the various stages in the programme lifecycle.

[20] Change control should not be confused with organizational change management, which is the responsibility of the organizational change manager and is discussed in Section 5.7.1 ‘The organizational change manager’.

[21] COE Information Pack v3.1 (© Crown copyright OGC April 2004,

‘Perhaps the most significant aspect of a COE that differentiates it from a programme or project support office is the relationship it has with the department’s Management Board. A COE should provide the Management Board with strategic oversight of the department’s portfolio of programmes and projects. This “helicopter view” will bring visibility to the interrelationships and interdependencies across the portfolio and support the Management Board in its judgements and decision-making on strategic priorities and commitments.’

[22] SMART – Specific, Measurable, Actionable, Realistic, Timely.

[23] The Sarbanes–Oxley Act (2002) compelled all United States registered companies to make an annual public attestation to the completeness and effectiveness of their regimes of financial control. Basel II (International Convergence of Capital Measurement and Capital Standards: A Revised Framework) defines new regulations to be adopted by the world’s largest economies, for the calculation of capital to be held by banks and similar financial institutions. International Accounting Standards provide common approaches to corporate accounting throughout the world. All three legislative and regulatory changes are far reaching and highly complex.

[24] ‘2002 Programme Management Survey’, summary and details available from



OGC (2005) Successful Delivery Toolkit, available from


Vase, D. (1999) Quantitative Risk Analysis: Guide to Monte Carlo Simulation Modelling. Chichester: Wiley.

Submit your own content for publication

Submit content