4
Start at the Beginning (Initiation)
Everyone recognizes that risks must be managed and that managing risks requires development and implementation of appropriate responses . Determining the appropriate type of response is not possible without first assessing and/or analyzing the characteristics and significance of a risk—of course, this assumes that risks have actually been identified. This logical chain of reasoning forms the basis for the core steps in the ATOM risk management process (see Figure 3-1), namely Identification, Assessment, Response Planning, Reporting, Review, and Implementation.
It seems obvious that the first task in a risk management process is to identify the risks, and until recently the first step in most risk management processes was Identification. However, Chapter 1 points out that risk can only be defined in relation to objectives, which means that one cannot identify any risks until objectives are defined and agreed upon. In reality, in many cases project objectives are either not clear, not agreed upon, or not documented. Projects are still launched prematurely, with the intention to “tidy up loose ends later.” This lack of definition makes it impossible to identify risks properly, leading to confusion and conflict, disagreement and disillusionment, and ultimately ineffective risk management. This shortfall must be rectified before the risk process can start. It is also necessary to decide which objectives are to be included within the scope of the risk process, because the boundary can be drawn in various places. For example, a project team might decide to perform only a technical risk assessment, or to focus instead on schedule risk exposure, budget uncertainties, or organizational reputation.
Something else is required before risk identification can commence. Simply defining the project objectives and then getting on with the risk management process is not enough. Organizations and projects must recognize that there cannot be a “one size fits all” approach to risk management. While ATOM offers a standardized risk management process, the depth at which it is implemented can vary. It is possible to do risk management very simply, perhaps only involving the project manager stepping through the process informally and quickly, using the minimum of tools and techniques. On the other hand, the risk management process can be performed in some detail, involving all project stakeholders, using a variety of approaches and tools, including sophisticated analysis and simulation. Significant amounts of time, effort, and money can be spent on understanding, assessing, and managing the risks. In fact, there is a spectrum of possible implementation levels at which risk management can be undertaken, and one must decide the appropriate level for a particular project. In ATOM this is determined by using a project sizing tool.
It is important to involve key stakeholders in decisions about scope and objectives, and the appropriate process level. However, it is not always clear who these stakeholders are, or who can make such decisions on behalf of the project. Stakeholder analysis answers these questions, and often forms part of the pre-project definition and planning phase—but not always. If key stakeholders have not already been identified, it is important to undertake a stakeholder analysis to determine who should be involved in setting the parameters of the risk process.
To address these potential problems, most current risk management processes include a step prior to risk identification; in ATOM this is called Initiation. The purpose of this step is to:
• Clarify which stakeholders should set the parameters of the risk process
• Decide on the appropriate level of risk process for this project
• Define the scope and objectives of the risk process.
The Initiation step requires the following inputs:
• List of key stakeholders, if available
• Defined project objectives, usually documented in the business case, project charter, and scope statement, or bid documentation
• Project sizing tool (if project sizing has not already been done).
In ATOM, Initiation requires the following activities:
• Stakeholder analysis (if it has not already been done for this project)
• Project sizing, to confirm the appropriate level of risk process
• An Initiation meeting to decide the parameters of the risk process.
The Initiation step produces the following outputs:
• List of key stakeholders and their relationship to the project (unless this was previously available)
• Agreed-upon level of risk process appropriate to the project size
• Risk Management Plan, which records decisions on the scope, objectives, and parameters of the risk process.
Figure 4-1: Flowchart for the Initiation Step
These inputs, activities, and outputs are illustrated in Figure 4-1 and described in detail in the following sections.
Inputs
Key stakeholders are responsible for making important decisions about how the project should be managed, including the risk process. It is therefore essential to identify these people and understand their relationship to the project. Stakeholder analysis is commonly performed before the project is formally sanctioned, and is documented in the business case or project charter. When this analysis is completed prior to the Initiation step, information on key stakeholders can be used directly to determine their input to the risk process. Otherwise a stakeholder analysis must be undertaken during Initiation.
Similarly, project objectives should be clearly recorded in the business case or project charter; for external projects they may form part of the bid documentation, such as an invitation to tender (ITT) or request for proposal (RFP). If project objectives are already unambiguously defined, they can form an input to Initiation; otherwise they must be clarified as part of this step.
Activities
STAKEHOLDER ANALYSIS
The first activity of the ATOM Initiation step is determining the key stakeholders, because these people will provide essential input on future decisions. If a prior stakeholder analysis is available, the results should be used directly; otherwise such an analysis must be undertaken here. A recommended method for stakeholder analysis is based on assessing three dimensions for each stakeholder (as illustrated in Figures 4-2 and 4-3):
• Their attitude toward the project, either supportive or resistant
• Their power to influence the project for better or worse
• Their level of interest in the project and its success or failure.
Figure 4-2: Stakeholder Analysis Template
Assessment of these three dimensions can be recorded using a stakeholder analysis template similar to that shown in Figure 4-2. Figure 4-3 shows how this assessment maps stakeholders in one of eight positions: Savior, Friend, Sleeping Giant, Acquaintance, Saboteur, Irritant, Time Bomb, or Tripwire. These positions are described in detail in Figure 4-4.
Having completed a stakeholder analysis, the project sponsor and project manager identify the key stakeholders and, therefore, who should contribute to decisions about the risk process. All Saviors are definitely invited to attend the Initiation meeting, and it is worth inviting Sleeping Giants in order to engage their interest. The project sponsor and project manager might seek the views of Saboteurs and Time Bombs (outside the meeting) if they feel able to contain any possible negative input and convert these stakeholders into supporters. Although Friends and Acquaintances support the project, their contribution is limited by their low power or low interest levels, so they need not be included. Irritants and Tripwires are also excluded.
The project manager decides how the role of risk champion will be fulfilled for the project. The risk champion is responsible for facilitating the risk process (see Figure 4-7).
Figure 4-3: Stakeholder Mapping Cube (from Murray-Webster and Simon 2006)
PROJECT SIZING
The assumption is that the organization has prepared a project sizing tool for use in all projects, as discussed in Chapter 3 (see Figure 3-4). This tool lists criteria that determine the importance of the project to the organization and that give an indication of the level of risk. Projects can then be scored on a consistent basis and ranked relative to one another. Projects that are strategically important or particularly risky require a more robust risk process than smaller projects, where a simpler process can be employed.
When a project sizing tool exists, the project sponsor and project manager together complete it for the project to determine whether the project rates as small, medium, or large. This information is used during the Initiation meeting to inform decisions about how detailed the risk process should be.
If the organization does not have a project sizing tool, the project may wish to develop one that can be used more widely within the business. Alternatively, key stakeholders’ views can be sought to determine whether this project should be treated as small, medium, or large. Whichever method is used, project sizing should be done prior to the Initiation meeting and then confirmed as part of the meeting.
Figure 4-4: Descriptions of Different Stakeholders
INITIATION MEETING
Key decisions about the risk process for a particular project are made at the Initiation meeting, which is attended by key stakeholders and facilitated by the risk champion. For a medium-sized project, this meeting might be expected to last a day. Before the meeting, the risk champion briefs the attendees on its content and format as well as their expected contribution. A typical agenda for the Initiation meeting is given in Figure 4-5.
Figure 4-5: Typical Agenda for an Initiation Meeting
The Initiation meeting is required only for medium and large projects; small projects are handled differently (see Chapter 13). The project size, either medium or large, should have been determined prior to the meeting. Assuming this has been done, the Initiation meeting starts with a brief discussion among key stakeholders, facilitated by the risk champion, to confirm the project size. If size has not been predetermined, a discussion is held to determine the project size using the project sizing tool.
Having sized the project, it is then possible to define the appropriate level of risk management process to be used. This definition should address the following process characteristics:
• Scope and objectives of the risk management process
• The degree to which ATOM should be applied
• Schedule of planned ATOM activities
• Tools and techniques to be used
• Roles and responsibilities for risk management
• Reporting and review requirements
• Definitions of probability and impact scales for qualitative assessment.
Key stakeholders consider these aspects at the Initiation meeting. Everyone involved with the project must be clear about each of them before they try to manage risk on the project. Therefore, decisions about each item must be documented and made available to all project stakeholders. This is done in a process description document called the Risk Management Plan, which details how risk management will be performed on a particular project. (Some organizations may use other names for this document, such as the Risk Strategy Statement or Risk Policy Document.) The content of a typical Risk Management Plan for a medium-sized project is described in the Outputs section of this chapter, with a template in Appendix A-1.
Clarification of Project Objectives Of course, project objectives should be defined and documented before the project starts, and should be included in the business case or project charter, or in the ITT/RFP for external projects. These documents should record project objectives, link them to the business case and strategic goals of the organization, and prioritize them to indicate which take precedence if trade-offs are required. If this prior definition of objectives has already been completed, the Risk Management Plan can simply refer to the document that contains the statement of objectives. If, however, the project does not already have clearly stated objectives, they must be defined at the start of the Initiation meeting because the risk process cannot continue without them.
Project objectives usually cover the scope, time, cost, and quality requirements of the project. There is, however, a range of other possible objectives that might be set for a particular project. These objectives might include technical performance, reputation, safety, regulatory compliance, maintainability, operability, and reliability.
To define, clarify, or confirm project objectives, the following questions are considered during the meeting:
• Scope. What is included and excluded in the project scope? What are the project deliverables?
• Time. Is there a date by which this project must be completed? Are there any intermediate milestones during the project? Are any interim deliverables required before project completion?
• Cost. What budget has been set for this project? How much contingency and/or management reserve is set aside? Are there targets for cash flow, margin, profitability, return on investment (ROI), etc.?
• Quality. Are there specific quality requirements for this project? What are the acceptance criteria?
• Other objectives. Are these clearly defined, agreed upon, and documented?
The answers to these questions are documented in the Risk Management Plan, which forms the output from this Initiation step.
Scope and Objectives of the Risk Management Process Clearly defined project objectives, either from a preexisting document or following a definition exercise during the Initiation meeting, make it possible to consider the scope of the risk management process. The key stakeholders discuss and agree on which of the project objectives are to be included in the risk process, and they define the boundary of what is included and excluded. It is also important to consider risk process scope in organizational terms. For example, will the risk process address risks only within the main project, or will it also include supplier risks, subcontract risks, program risks, corporate risks, etc.?
Deciding which objectives are in scope is essential to risk identification, because risks are defined in terms of the objectives that would be affected should the risk occur. For example, it might be decided to undertake a purely technical risk assessment, identifying and managing only those uncertainties that could affect technical performance objectives. Or the risk process might be expected to include all project objectives, including scope, time, cost, quality, etc. Alternatively, it might be decided to use the risk process to address risks to both this project and the program or portfolio to which it belongs.
Finally, in this part of the Initiation meeting, clear objectives are set for the risk process itself, against which the performance of the risk process can be measured.
Application of the ATOM Risk Management Process Like most risk methods, ATOM can be tailored to meet the specific requirements of a particular project, and such tailoring is discussed and agreed on by key stakeholders during the meeting. Decisions are documented in the Risk Management Plan.
Tools and Techniques to Be Used The organization might apply a standard set of risk tools and techniques during the risk process, and it might decide during the Initiation meeting simply to use the standard approach. Alternatively, there may be a case for changing the tools and techniques, and this is discussed, agreed upon, and documented in the Risk Management Plan.
Roles and Responsibilities for Risk Management The contributions of the key participants in the risk process are defined and agreed upon during the meeting. This can be done simply by discussion, listing the various tasks and agreeing on who will do what. A more structured analysis might be more useful, for example, using a responsibility assignment matrix (RAM) in the format of a RACI chart, which allocates one or more stakeholders to each of four responsibilities:
• Responsible for performing the activity
• Accountable for the task (and may also approve the output)
• Consulted about the task (or contributes to it)
• Informed about the task.
An example RACI chart is given in Figure 4-6. The list of agreed-upon roles and responsibilities is documented in the Risk Management Plan, together with the RACI chart if one is produced. Figure 4-7 lists the key roles associated with the ATOM process: project sponsor, project manager, risk champion, Risk Owner, Action Owner, project team members, and other stakeholders.
Reporting and Review Requirements The information needs of key stakeholders are considered in order to define what outputs are required from the risk process. This information is captured in the Risk Management Plan, and also forms part of the project communication plan, if one exists. For a medium-sized project, the First Risk Assessment concludes when the risk champion issues a full risk report, which is distributed to the project sponsor, project manager, and key project team members (including all Risk Owners). This report includes the current Risk Register as well as an analysis of the current risk exposure of the project. The executive summary from this report can be extracted for other key stakeholders.
The review and update cycle is also agreed upon and documented, determining how often the risk assessment for this project will be repeated. The use of Major and Minor Reviews is agreed upon, as discussed in Chapter 3, and decisions are made regarding when Major Reviews will be performed and how often Minor Reviews are required. For the medium-sized project, a First Risk Assessment is performed prior to project start, if possible; otherwise, it is done immediately afterward. The Major Review is repeated at key points in the project, for example, on major changes to scope or requirements and at key phase changes or stage gates. Regular Minor Reviews are undertaken periodically between Major Reviews, timed to match the normal project reporting cycle— typically monthly.
Figure 4-6: Example RACI Chart
Figure 4-7: Roles and Responsibilities within ATOM
Definitions of Scales for Probability and Impacts (P-I Scales) The key stakeholders discuss and agree on the meanings of the labels used during the Assessment step when estimating the probability and impacts of an individual risk.
For a medium-sized project, use of five-point scales is recommended for both probability and impact; i.e., very high (VHI), high (HI), medium (MED), low (LO), and very low (VLO). The use of five-point P-I scales should be confirmed, and may be simplified to four points, or three points if a simpler risk process can be justified for this project. Figure 4-8 shows an example set of probability and impact scales.
Figure 4-8: Example Probability-Impact Scales
After the number of scale points is determined, the meanings of each must be agreed upon. Probability terms are defined in terms of percentage ranges. Impact terms are defined against each of the project objectives that are in scope for the risk process, translating each term into ranges of effects on time, cost, quality, etc. Many organizations use a common scale for probability definitions across all projects, but impact scales must be project specific. Figure 4-9 illustrates the process of determining project specific impact scales. The highest level of impact on each scale (VHI) is defined as the level of impact that cannot be ignored—for example, a showstopper or catastrophic impact for a threat, or a golden “must-have” opportunity. The lowest impact scale (VLO) is defined as a degree of impact that does not need active management and is considered acceptable for this project. Intermediate scale points are set between these two limits. The three points in between are established by selecting a nonlinear scaling, usually based on a doubling of value at each point.
Figure 4-9: Examples of How to Set Impact Scales
The same set of P-I scales is often used for both threats and opportunities, treating impacts as negative for threats (e.g., delays, additional cost, performance shortfall) and as positive for opportunities (e.g., saving time or cost, enhancing performance). It may, however, be decided to use different P-I scales for threats and opportunities if the sensitivities of the project are significantly different for each type of risk; for example, a catastrophic delay might be three months, but a time saving of just one month might be regarded as exceptional.
During the Assessment step, the probability and impacts of each risk are evaluated using these scales, then risks are positioned on a Probability-Impact Matrix to determine their relative importance, as described in Chapter 6. ATOM uses a default double P-I Matrix with the thresholds shown in Figure 4-10.
Figure 4-10: Double Probability-Impact Matrix
Risk Thresholds It is important to confirm the risk thresholds to which the organization generally works, or those that are appropriate to this project. The default scheme used in ATOM has three zones: “red” top-priority risks require urgent attention, “amber” risks are medium priority and require active monitoring, and “green” risks are low priority. The position of the boundaries between these three zones on the matrix is confirmed during the Initiation meeting. Most projects will use the default scheme; changes to that scheme should be justified, agreed upon, and documented.
Potential Sources of Risk to this Project The organization may have defined typical sources of risk on its projects, either as a list of risk categories or as a hierarchical risk breakdown structure (RBS). Where a generic category list or RBS exists, it should be reviewed during the Initiation meeting, and key stakeholders should confirm that it includes all possible sources of risk to the project, making modifications where necessary. A sample risk breakdown structure is shown in Figure 4-11.
Outputs
If a stakeholder analysis is performed as part of the Initiation step, the results are captured in a report written by the project sponsor or project manager and distributed to key stakeholders, as appropriate.
The main output from the Initiation step is the Risk Management Plan, which documents the decisions reached during the Initiation meeting. The Risk Management Plan is drafted by the risk champion and approved by the project manager.
A sample contents list for a typical Risk Management Plan for a medium-sized project is shown in Figure 4-12, and the contents and purpose of each paragraph are expanded below. (See also the template in Appendix A-1.)
• Introduction. Describe the purpose of the Risk Management Plan, with essential document reference information, including author, issue date, etc.
• Project description and objectives. Summarize the project, including its purpose, scope, objectives, and other relevant background information. Refer to existing project documentation wherever possible to avoid unnecessary duplication. Explicitly list all project objectives (e.g., scope, time, cost, quality) and comment on their relative priority in case of conflict.
• Aims, scope, and objectives of risk process. Describe the purpose of risk management for this project. Clearly state the scope of the risk process, defining what is in or out of scope. It may also be useful to include a glossary of risk terms or refer to a standard document.
• Application of the ATOM risk management process. Outline how ATOM will be used for this project, either summarizing each process step or by referring to a standard process description document. Any adjustments or tailoring of the ATOM process should be noted. State the schedule for planned risk activities during the project.
• Risk tools and techniques. List the tools and techniques to be used for each step in the risk management process, either describing them briefly or referring to another process description document.
Figure 4-11: Sample Risk Breakdown Structure
Figure 4-12: Sample Contents List for a Risk Management Plan
• Organization, roles, and responsibilities. State who is responsible for the various elements of the risk management process for this project and describe their contribution, possibly using a responsibility assignment matrix. Where possible, use the names of individuals rather than job titles to encourage ownership.
• Risk reviews and reporting. State how often risks will be reviewed on this project, and whether risk reviews will be undertaken as part of other project meetings or in a separate forum. Describe the deliverables from the risk management process, including types of reports, their purpose, and distribution.
• Project-specific definitions of probability and impacts. Define the terms to be used for qualitative assessment of risks on this particular project. Confirm thresholds on the P-I Matrix to be used when prioritizing risks.
• Project-specific sources of risk. List the types of risk that the risk management process is expected to address for this project. This may be structured as a simple list of risk categories, or in a hierarchical RBS, either using a generic RBS or a project-specific version.
A Risk Management Plan template is presented in Appendix A-1, indicating typical content for a medium-sized project. This template can be easily modified to apply to any particular project by replacing the text contained in <angle brackets>.
Once project objectives and process characteristics are defined in the Risk Management Plan, the project manager issues the plan to all key stakeholders so that everyone understands how risk management will be undertaken on their project. The Risk Management Plan becomes a formal configuration item, subject to configuration management. It is reviewed at key points during the project to determine whether the process is still appropriate and effective. It may be necessary to revise some of the decisions made at the start of the project, so that the risk management process remains capable of addressing the degree of emergent risk faced by the project. If the risk process is modified during the project, then the Risk Management Plan is revised and reissued.
Summary
The Initiation step, by defining the parameters and boundaries of how risk management will be undertaken for this particular project, provides all the necessary information for the next step in the risk process. Completing this step requires the following activities:
Determine key stakeholders who will provide input to this step Size the project to determine the appropriate level of risk process Hold an Initiation meeting with key stakeholders in order to:
• Confirm project size
• Clarify project objectives
• Set the scope and objectives for the risk process
• Confirm the tools and techniques to be used
• Allocate roles and responsibilities for risk management tasks
• Agree on reporting and review requirements
• Define scales for probability and impacts
• Identify potential sources of risk to the project
Document the decisions from the Initiation meeting in a Risk Management Plan, and distribute it to key stakeholders.
Completing the Initiation step makes it possible to move on to risk identification, as detailed in the next chapter.