14

ATOM for Large Projects

A key feature of the ATOM approach is scalability. ATOM is designed to be applicable to any project in any industry, offering a generic process that is suitable for all. However, some projects are undeniably more risky than others. Attempting to send a manned mission to Mars is on a different scale from moving an office from the first floor to the second, though both are projects, and both need some sort of risk management process.

The ATOM project sizing tool, discussed in Chapter 3 (with an example in Figure 3-4), allows an organization to classify its projects by size into three groups: small, medium, and large. Of course, size is relative—a project with a $1M budget may be considered enormous for one organization but tiny for another—and has many dimensions (e.g., complexity, value, duration, strategic importance), so the project sizing tool must reflect what is important to the organization. Once projects are categorized, the risk process can be tailored accordingly. The ATOM process for a typical medium-sized project is described in Part II (Chapters 4 through 12); Chapter 13 discusses how to modify it for a small project. This chapter covers how to apply ATOM to a large project, which might be expected to be riskier and therefore to require a more rigorous approach to risk management.

The process described here assumes that a large project will be treated as a whole, and not divided into subprojects. Sometimes, however, very large projects can be broken down into smaller components. In these cases, it may be beneficial to apply the ATOM process at multiple levels across the large project. A hierarchy of risk assessments could be performed, with a whole-project risk assessment at the highest level and lower-level assessments of subprojects. Multiple Risk Registers might be produced, describing risks at different levels within the large project. (This approach is also suitable for managing risk on a program or portfolio, but managing risk at this level is outside the scope of ATOM, which is designed for projects. The use of ATOM in a program context is discussed in Chapter 16.)

The remainder of this chapter describes ATOM as it should be applied to a single unitary large project.

Bigger Is Better

Many characteristics might result in categorizing a project as large. Using the example project sizing tool in Figure 3-4, a large project would have several of the following features:

•  Strategic importance: the project is critical to business success

•  Commercial/contractual complexity: groundbreaking commercial practices with unresolved issues

•  External constraints and dependencies: overall project success depends on uncontrollable external factors

•  Requirement stability: requirements are not finalized and are subject to negotiation

•  Technical complexity: groundbreaking product/project with high innovation

•  Market sector regulatory characteristics: highly regulated or novel sector

•  Project value: large project value compared with other projects in the organization

•  Project duration: long duration compared with other projects in the organization

•  Project resources: international project team or joint venture

•  Post-project liabilities: punitive exposure.

Clearly, a large project poses a significant risk challenge to any organization, and the standard ATOM risk process might not prove adequate. The process modifications described here are designed to provide a robust risk process while retaining a simple framework that does not present an unacceptable overhead burden to the project team.

The generic ATOM risk process applied to both small and medium projects is also applicable to large projects (see Figure 14-1), but for a large project each step is reinforced to ensure the necessary rigor. As for all projects, the ATOM process for large projects is iterative, starting with the Initiation step, followed by the First Risk Assessment, with regular reviews throughout the project life cycle, and ending with the Post-Project Review, as illustrated in Figure 14-2.

The rest of this chapter works through the ATOM risk process steps and presents changes to the standard approach previously described for medium projects. (For further details of the standard approach, refer to the appropriate chapters in Part II.)

Initiation

This important set-up step ensures that the risk process is properly targeted to meet the specific needs of the project. During this step, key decisions are made about the risk process, including:

•  Scope and objectives of the risk management process

•  The degree to which ATOM should be applied

•  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.

Figure 14-1: Steps in the ATOM Process

For a large project, these decisions must reflect the increased attention and effort required for risk management. Decisions must be recorded in the Risk Management Plan, which might be a more substantial document than is required for a medium project, though the content headings are the same. Figure 14-3 provides a sample contents list for a Risk Management Plan suitable for use on a large project.

Initiation for a large project is still done in a dedicated Initiation meeting, attended by key stakeholders and facilitated by the risk champion. In some cases, a skilled external facilitator might be used to support the risk champion. The Initiation meeting for medium projects, described in Chapter 4, does not require significant modification for large projects. The meeting agenda is the same (see Figure 4-5), and the attendees and duration are also similar.

One key decision for a large project is whether it justifies use of quantitative risk analysis (QRA) techniques such as Monte Carlo. These techniques reveal the predicted effect of identified risks on overall project outcome and can be applied to both cost and schedule risk. The Initiation meeting also determines the scope of required QRA, and whether it should be applied to cost, schedule, or both. ATOM recommends using these techniques on most large projects, but they are not required for all. Chapter 15 describes how to use Monte Carlo analysis techniques and includes criteria for deciding when they are applicable.

Figure 14-2: The ATOM Process for Large Projects

Figure 14-3: Sample Contents List of a Risk Management Plan for a Large Project

During the Initiation meeting, key stakeholders should consider the potential benefits of using Monte Carlo techniques on the project and should compare them with the associated costs in terms of specialized tools, the need for expert analytical skills, and the time and effort required for the analysis (especially for data generation). The ATOM process assumes that QRA techniques are appropriate for most large projects, so the emphasis of the discussion should be to question whether their use might not be justified for this particular project.

ATOM for large projects also differs from medium projects in the requirement for a more rigorous review cycle, which is considered and decided on during the Initiation meeting. Whereas an alternating series of Major and Minor Reviews is done for the typical medium project, on large projects doing the Major Review more frequently may be appropriate. Indeed, in some cases it may be decided that all risk reviews will be Major, perhaps to respond to high risk exposure, or where the pace of change on the project is fast.

Project-specific scales for probability and impact are also determined and agreed upon during the Initiation meeting. Five-point scales (VLO, LO, MED, HI, VHI) are usually considered adequate for large projects, using the same framework as recommended for medium projects (see Figure 4-8), though in some cases considering additional scale points. However, the trade-off between additional granularity and increased complexity should be considered carefully; five-by-five scales are recommended even for large projects.

Finally, consider the choice and use of a software tool to support the risk process. For medium projects, ATOM leaves open the option of using either a proprietary risk management tool or bespoke methods for recording and reporting risk data. A large project will likely generate sufficient data to justify use of a proprietary risk management tool; this tool should be fully integrated with the project management tool kit and the wider business infrastructure. The ATOM process for large projects does not depend on any particular software package, but the sheer volume of risk data handled in a large project will likely justify the investment in professional risk software that will enable the analysis and reporting process.

To complete the Initiation step for a large project, the following activities are required:

Determine key stakeholders who will provide input to this step

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, and decide whether to use QRA

•  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 the Risk Management Plan, and distribute it to key stakeholders.

Identification

Many believe that risk identification is the most important step in the risk process because unidentified risks remain unmanaged, exposing the project to unnecessary threats and leading to the loss of potential opportunities. For a large project this is particularly true, because the higher level of inherent risk presents a greater level of uncertainty. Indeed, while an organization might be able to cope with the failure of a small or medium-sized project, problems with a large project might spell disaster. For this reason, particular care must be given to the risk identification step in the ATOM process for large projects.

Identification for medium projects (see Chapter 5) forms the initial part of the First Risk Assessment. It is a structured approach, involving key stakeholders, with the aim of exposing all knowable risks. ATOM recommends three basic techniques to identify risks on medium projects, namely brainstorming, assumptions and constraints analysis, and a risk identification checklist. Each of these techniques is also useful during the Identification part of the First Risk Assessment for a large project and can be expected to reveal a significant number of risks. However, the increased complexity and importance of a large project justifies the use of additional risk identification techniques as part of this step. In particular, the following three methods are recommended for inclusion:

•  SWOT analysis

•  Structured interviews

•  Review of past projects.

The forum for risk identification on large projects is the same as for medium projects, namely a risk workshop attended by key stakeholders and facilitated by the risk champion. The typical risk workshop is expected to last for two days and covers both Identification and Assessment steps, although more time may be required for some large projects. The content of the risk workshop is the same as that described in Chapter 5 for a medium project. The risk champion might either replace the standard brainstorm session with a SWOT analysis or include it in the workshop as an extra element. The workshop is preceded by the same set of pre-workshop preparatory activities, including circulating a workshop agenda (see Figure 14-4 for an example) and other supporting material. In addition to the risk workshop, large-project risks are identified using a series of structured interviews, as well as a structured review of past projects.

The three additional risk identification techniques recommended for large projects are summarized below.

SWOT ANALYSIS

The four elements of a SWOT analysis when used for risk identification are:

•  Strength: a characteristic, resource, or capacity the organization can use effectively to achieve its objectives

•  Weakness: a limitation, fault, or defect in the organization that might keep it from achieving its objectives

•  Opportunity: an uncertain beneficial event or condition that, if it occurs, results in favorable outcomes on the project

•  Threat: an uncertain adverse event or condition that, if it occurs, results in unfavorable outcomes on the project.

SWOT analysis for project risk identification within ATOM has a different focus from use of this technique for strategic decision making. The first element of this version of SWOT analysis is a facilitated brainstorming process that identifies organizational strengths and weaknesses as they relate to the project; these are usually limited to about 10. The second element is identifying opportunities and threats that might affect achievement of the objectives, using the identified strengths and weaknesses as a starting point, as illustrated in Figure 14-5. Risk metalanguage offers a mechanism for deriving opportunities from organizational strengths, and for finding threats that arise from weaknesses, using structured risk statements such as:

•  As a result of <strength>, <opportunity> may occur, which would lead to <benefit>.

•  As a result of <weakness>, <threat> may occur, which would lead to <problem>.

Figure 14-4: Sample Agenda for a First Risk Assessment/Two-Day Risk Workshop for Large Projects

Several opportunities often arise from a single strength, and several threats might come from one weakness, so the risk champion ensures that all options are considered during the workshop.

Figure 14-5: Identifying Opportunities and Threats Using SWOT Analysis

INTERVIEWS

Short, focused risk identification interviews are conducted by the risk champion immediately after the risk workshop with either individuals or small groups of stakeholders.

•  When interviewing individuals, it is important to decide who to include. Conducting too many interviews can lead to repetition and waste time, so the aim is to interview only as many key stakeholders as are required to cover all the major areas of the project.

•  If risk interviews are conducted with groups instead of individuals, the interviewer must take additional care to manage the group dynamics, ensuring that each participant is heard and that no individual dominates. Group interviews should be kept small, say three to five people, with all participants from the same area of expertise. It is also best if they share the same level of seniority, to encourage openness and mitigate reluctance to speak honestly in front of superiors.

Structure is a valuable aid to the risk interview; ATOM uses a framework based on a work breakdown structure (WBS) or risk breakdown structure (RBS). Other factors required for a successful risk identification interview include:

•  Preparation. To make the best use of the time available for the interview, both interviewer and interviewees need to have reviewed and be familiar with the project objectives and current status, and should have spent some time prior to the interview considering possible risks.

•  Trust. The interview should be kept confidential so interviewees can express their concerns honestly and without fear of reprisal or blame. Asking open-ended questions, avoiding a judgmental or critical attitude, demonstrating respect, and acknowledging confidentiality can encourage this trust.

•  Interview skills. These include active listening and selective questioning. Active listening means paying attention, encouraging openness, and demonstrating empathy. Selective questioning means using different question types appropriately, including open, probing, hypothetical, reflective, and closed questions.

•  Recording and follow-up. Many items discussed in the interview might not be well-described risks, so the risk champion must take good notes during the interview and use them later to filter out non-risks, merge duplications, and record properly described risks. Additional clarification from the interviewee might be required after the interview to ensure that the final output fairly reflects the interviewee’s views.

REVIEW OF PAST PROJECTS

Although each project is unique, many areas of commonality exist between completed and new projects. As a result, the post-project review offers a structured mechanism for capturing lessons to be learned from previous projects and applied to new ones.

The post-project review addresses all aspects of completed projects, including the management of risk. The risk element of the post-project review should be structured using the RBS as a framework to ensure that all sources of risk are considered and to provide a comparative structure for transferring lessons between projects. The results from the post-project review are usually captured in a post-project review report and can be used to update risk identification tools such as checklists, to incorporate proactive risk response strategies into future projects, and to improve the effectiveness of the risk analysis and management process.

The risk champion, in discussion with the project manager, usually undertakes the post-project review analysis as a mechanism for risk identification, though it can also be conducted in a group that includes the risk champion, project manager, and other key stakeholders. The following steps are required:

1. Identify relevant comparable projects that have been completed and have similar characteristics to the current project.

2. Review the post-project review reports for these projects, noting generic risks and effective responses.

3. Consider the extent to which the risks and responses might apply to the current project.

It is vital for the success of the ATOM risk process that all knowable risks are identified and recorded. For large projects, this requires performing the following activities as part of the First Risk Assessment:

•  Determine workshop attendees; prepare a workshop agenda and workshop pre-brief.

•  Facilitate a risk workshop to identify all knowable risks, which are then properly described using risk metalanguage.

•  Consolidate risks to remove duplicates and non-risks.

•  Conduct post-workshop risk identification interviews and post-project review analysis.

•  Record all identified risks in the risk management tool.

Assessment

For large projects, the major change in the Assessment step is inclusion of QRA techniques, usually Monte Carlo analysis. This is described in detail in Chapter 15, which outlines how to build a risk model, perform the analysis, and interpret outputs. One key element in producing a realistic risk model is to use data from the qualitative Assessment step as a basis for determining risk model parameters. It is also valuable to use Monte Carlo analysis both before and after developing suitable responses to identified risks in order to evaluate the effect of planned responses on the risk exposure of the project.

Since qualitative assessment is a prerequisite for QRA, on large projects the qualitative part of the Assessment step must be performed first, as part of the First Risk Assessment.

The activities in the Assessment step for a large project mirror those used for medium projects (as described in Chapter 6) and are conducted during the latter part of a risk workshop.

Each identified risk is assessed against the agreed-upon scales for probability and impacts to allow risks to be prioritized, using both the red/amber/green zones of the double P-I Matrix (as in Figure 6-4), and using P-I scores (see Figures 6-5 and 6-6). Risks are also categorized using the project’s WBS and RBS to identify “hot spots” arising from common risk sources and areas of the project particularly exposed to risk. For the large project, RBS and WBS categorizations can be merged into a two-dimensional matrix (see Figure 14-6) to show particular combinations of source and area affected, allowing risk response development to be more closely targeted.

In addition to these main risk characteristics (probability, impacts, WBS category, RBS category), assessment of risks for a large project considers a number of other factors for each risk:

•  Strategic impact. Some risks may have potential impacts outside the project, perhaps affecting other projects, a higher-level program, business-as-usual activities, or even the wider organization. These non-project impacts are also considered; an example scale is presented in Figure 14-7.

•  Manageability. Some risks are easier to address than others, and this should be taken into account when prioritizing risks. For example, a high-probability/high-impact threat that can be easily managed might be prioritized below one with a medium probability/medium impact but that cannot be influenced. A scale such as the one in Figure 14-8 can be used for this assessment, with results ranging from unmanageable to controllable by normal activities.

•  Impact window. Assessing when a risk impact might occur can affect its overall prioritization, since risks that could happen soon should receive higher priority than those further off. (This is sometimes referred to as proximity.)

•  Action window. The period of time when effective action can be taken is another important factor when assessing a risk. (This is sometimes called urgency.) If addressing a risk is only possible in the next few days, that risk receives higher priority than one for which the need to act is less immediate. Impact and action windows are often presented using an overlay chart (Figure 14-9), indicating risks with high proximity and urgency. This chart also shows potential problem areas where the action window is later than the impact window—i.e., the risk is expected to occur before the project has a chance to take action. In this case, new action strategies should be sought or contingency plans developed.

Figure 14-6: Correlating RBS with WBS

Figure 14-7: Example Scale for Non-Project Impacts

Figure 14-8: Example Scale for Manageability

Chapter 6 lists a standard set of assessment outputs usually produced following the risk workshop for a medium project, as follows:

•  Initial Risk Register

•  Prioritized risk list

•  List of top threats and top opportunities

•  Categorization of risks by RBS element

•  Categorization of risks by WBS element

•  Double P-I Matrix.

These are also produced for the large project, with the addition of some other assessment outputs:

•  RBS × WBS cross-categorization analysis

•  Prioritization by other factors (strategic impact, manageability, impact and action windows)

•  Risk metrics.

A number of risk metrics can be established at this stage of the First Risk Assessment to form a baseline for later trend analysis. These include:

•  Number of active risks (separated into threats and opportunities)

•  Number of expired/occurred/closed/deleted risks (initially this will be zero)

•  Total P-I score for active threats and opportunities

•  Average P-I score for active threats and opportunities.

Figure 14-9: Impact and Action Windows Overlay Chart

After completing the qualitative assessment of all identified risks, a QRA is performed using the assessment data, following the guidance outlined in Chapter 15. This analysis demonstrates the predicted effect of identified risks on the overall project outcome (either cost or schedule or both) and informs the Response Planning step.

The Assessment step conducted as part of the First Risk Assessment for a large project requires the following activities:

•  Assess probability and impacts for each risk, plot the risk on the P-I Matrix, and calculate P-I scores.

•  Categorize risks using the RBS (causes) and WBS (effects) to determine hot spots.

•  Assess other key characteristics of identified risks, including strategic impact, manageability, proximity, and urgency.

•  Nominate risk owners.

•  Generate baseline risk metrics.

•  Develop a Monte Carlo risk model based on qualitative risk data, and perform an initial analysis to demonstrate the predicted effect of risk on overall project outcome.

•  Record all additional risk data in the risk management tool.

•  Prepare a set of outputs that will inform the continued risk management process as well as the overall project management process.

Response Planning

During the First Risk Assessment for a medium project, Response Planning occurs during a series of interviews with risk owners (as described in Chapter 7). This step is essentially identical for large projects, using the expertise and experience of risk owners to determine appropriate response strategies and effective actions, as well as nominating action owners to implement agreed-upon actions. Scenario planning may be used to develop response strategies or fallback plans and to determine what type of response is appropriate. Because Response Planning is so important for a large, risky project, it deserves the same level of detailed planning as the production of the project plan itself. In ATOM for large projects, two additional steps are recommended: the use of bowtie analysis, and an update of the QRA risk model.

BOWTIE ANALYSIS

This technique can be used as part of an interview or as a stand-alone addition, in order to improve the understanding of key or important risks (as determined by the earlier risk assessment), and specifically where a risk event has multiple causes and multiple effects. This enhanced understanding can help in the consideration of alternative response strategies. A bowtie diagram is drawn with causes of the risk event on the left-hand side, the risk event in the middle (the knot of the bowtie), and the effects, should the risk occur, on the right-hand side. Potential risk responses are entered into the diagram on either side of the risk event.

•  Where the risk being analyzed is a threat, preventive responses are placed between the causes and the risk event, aiming to either reduce the probability of the risk event occurring or avoid it completely. To the right of the risk event are recovery responses that would reduce the effect if the threat occurred. This is illustrated in Figure 14-10.

•  Figure 14-11 shows a bowtie diagram for an opportunity. Here we can record enabling responses that either enhance the probability of the opportunity occurring or make it certain. On the right-hand side are maximizing responses that, should the opportunity occur, will increase the positive effect.

When using bowtie analysis, the key risks to be reviewed should be agreed upon by the project manager, risk manager, and risk owners. The bowtie should then be drawn on either a large piece of paper or on a white board, with the risk event in the middle. Any already identified causes or effects should be written on the relevant columns. Any other causes or effects that are subsequently identified can be added later. Sticky notes should then be used to document responses that either prevent/enable the risk event or recover/maximize the effect. The sticky notes are then placed in line with the relevant cause or effect and the risk event. This visualization will show where responses are missing and need to be developed, or where multiple responses are available. A critical review of the situation should then take place and selected responses developed further into action plans with appropriate action owners.

Figure 14-10: The Bowtie Diagram for Threats

Figure 14-11: The Bowtie Diagram for Opportunities

UPDATING QRA

The Response Planning step for large projects also requires an update of the Monte Carlo analysis to take account of planned responses, as described in Chapter 15. The data in the risk model is adjusted through a series of data-gathering interviews with risk owners, indicating where values for individual model activities and other parameters have changed as a result of the actions that are to be implemented. Repeating the analysis with this revised data predicts the expected effectiveness of planned responses in improving the overall risk exposure of the project.

One key output here is the “onion ring diagram” (Figure 14-12), which overlays the S-curve for the “all risks/no responses” position with an S-curve showing the effect of all planned responses. It is also possible to build up a series of intermediate S-curves to show the cumulative effect of different responses, indicating which have the greatest influence on overall project outcome. This analysis can suggest whether currently planned responses are adequate to meet the risk challenge or whether additional response planning is required. Holding additional interviews with risk owners to develop new responses might be necessary if the Monte Carlo analysis shows insufficient expected improvement.

Figure 14-12: Overlapping S-Curves (Onion Ring)

To complete Response Planning for a large project, the following activities should be undertaken:

•  Conduct interviews with risk owners to determine appropriate response strategies and actions with nominated action owners using bowtie diagrams for key risks.

•  Confirm and refine proposed actions with action owners.

•  Update the Risk Register with response strategies and agreed-upon actions.

•  Update QRA to reflect post-response expectations.

•  Conduct additional response development interviews if required.

•  Modify the project schedule and budget to include agreed-upon actions.

Figure 14-13: Sample Contents List for a Full Risk Report

Reporting

Risk reporting is an essential element of the ATOM process because it communicates results to stakeholders in a way that enables effective decision making and management action. As might be expected, the reporting requirement for a large project is more detailed than for a medium project (see Chapter 8), though the main output is still the full risk report. However, the content of this report includes other elements arising from the additional data generated during the enhanced ATOM risk process; Figure 14-13 gives a sample contents list.

For a large project, the full risk report produced at the end of the First Risk Assessment includes the sections listed below:

•  Executive summary. This summarizes key findings, conclusions, and recommendations at a level suitable for senior management and key project stakeholders.

•  Scope and objectives of report. The purpose of the report is described, highlighting its place in the risk process.

•  Project status summary. This summarizes project status to set the context for the report.

•  Overall risk status. A summary is presented of the current level of risk exposure, highlighting main areas of risk, plus any significant individual risks, together with planned responses. Any concentrations of risk exposed during the categorization analysis are detailed, including common causes and areas of the project particularly affected.

•  Top risks, actions, and owners. This lists top threats and opportunities in priority order and discusses each in turn, detailing causes and effects, planned actions with owners, and expected changes. Significant patterns within the top risk lists are discussed.

•  Detailed qualitative risk assessment. This is the main analysis section of the report, where the risk exposure is considered in detail. The number of risks in each red/amber/green category is presented, as well as categorization by RBS and WBS, plus the RBS × WBS cross-analysis. Expected response effectiveness is discussed, based on the pre-response and post-response P-I Matrices.

•  Other analytical outputs also can be considered, and the reporting requirement will be defined in the Risk Management Plan. For example, a “risk waterfall” chart might be prepared that would indicate the predicted and actual changes in risk exposure over time. This can be done using P-I scores from the qualitative assessment step to show the expected effectiveness of planned responses. It can also be done using cost impacts to indicate when contingency might be released to profit. See Figure 14-14 for an example risk waterfall chart.

•  Quantitative risk analysis results. Findings from the Monte Carlo analysis are presented here, concentrating on the overall results rather than details of the risk model or particular outputs (these details are presented in appendices). The degree of uncertainty in project outcome is presented, and expected values from the calculation are given and discussed. The main risk drivers are identified, together with key risks, and the predicted effectiveness of planned responses is also covered. A risk waterfall chart might also be included, as described above, based on Monte Carlo simulations, perhaps taking the 50 percent or 80 percent point from a series of S-curves with or without risk responses.

•  Conclusions and recommendations. Key findings are presented at a summary level, and conclusions are drawn based on the data within the main body of the report. Based on these conclusions, a series of focused and specific recommendations are presented that respond to the level of risk currently faced by the project.

•  Appendices. Supporting information is presented in appendices. One of these should contain the complete Risk Register with full details of every identified risk. It is also common to include a complete list of all risks in priority order. Input data for the risk model may be included; detailed QRA outputs can also be presented in an appendix. The content of other appendices is optional, depending on the information needs of the recipients.

Figure 14-14: Example Risk Waterfall Chart

Reporting at the conclusion of the First Risk Assessment for a large project involves the following activities:

•  Assemble all sources of information on current risk exposure, including the Risk Register and QRA outputs.

•  Perform any additional analysis required to understand the information.

•  Draft a full risk report presenting this information in a structured way.

•  Review the draft report for completeness and correctness, and modify as required.

•  Issue the risk report to project sponsor, project manager, project team members, risk owners, and other key stakeholders.

•  Prepare and distribute extracts, subsets, and additional reports as required.

Implementation

Not everyone agrees that risk identification is the most important step in the risk process. Some would say that this is Implementation, since the best risk responses are useless if they are not put into practice. For this reason, ATOM places considerable emphasis on the Implementation step, whether the project is small, medium, or large. In fact, Implementation activities for large projects are exactly the same as those already described for medium projects (see Chapter 9) and for small projects (see Chapter 13).

So, although Implementation is extremely important, there is not much different or extra to say about it for large projects. It requires the same level of attention and effort for all projects, and involves the following activities:

•  Complete agreed-upon actions and report progress.

•  Monitor each response strategy and its associated actions.

•  Ascertain the overall status of each risk.

•  Identify additional secondary risks and raise new risks.

•  Modify the project schedule and budget to include new actions or any replanned actions.

•  Raise any issues or problems.

•  Update the Risk Register with the current status of each risk and progress on agreed-upon actions.

•  Produce information for risk reports and review meetings.

Review

As for Implementation, the Review step of the ATOM process is essential to keeping the process alive. This is especially true for large projects, which have characteristics that introduce significant risk exposure. They are likely to involve substantial innovation or technical complexity and take place over long durations, which is a recipe for a high degree of change in the level of risk exposure. As a result, the ATOM process needs an effective Review step to ensure that project stakeholders have correct and timely information to support good decision making.

For the medium project, ATOM includes a series of Major and Minor Reviews, as described in Chapters 10 and 11. The expected high degree of change on a large project means that more reliance is placed on Major Reviews, where a comprehensive reevaluation of risk exposure is undertaken. The review cycle for the project is determined and agreed upon during the Initiation step and documented in the Risk Management Plan, and large projects commonly use Major Reviews more often during the project life cycle than do medium projects. However, even on the largest project, it is unlikely that there will be sufficient resources and effort available to perform a full Major Review every time, especially when the review cycle is monthly. Consequently, large projects also make use of alternating Major/Minor Reviews.

The large-project Minor Review matches that used for medium projects exactly (see Chapter 11) and does not include revision of the QRA model. The review requires the following activities:

•  Hold a facilitated risk review meeting to review all current red risks and newly raised risks, plus amber risks if time allows.

•  Identify, describe, and assess new risks; appoint risk owners; and develop responses.

•  Update the Risk Register.

•  Revise and define risk actions and appoint action owners.

•  Update the project plan to take into account risk actions.

•  Draft and distribute a summary risk report and other information needed for project reporting.

For the Major Review, however, Monte Carlo analysis is repeated in addition to the activities performed for a medium project: updating the model parameters to reflect project progress, changes in individual risks, the effect of implemented risk response actions, the identification of new risks, and the predicted effects of remaining actions. As in the First Risk Assessment, Monte Carlo analysis is performed both before and after development of risk responses—the first time to assist in response development, the second time to model the post-response situation.

In addition, the large-project Major Review includes calculation of risk metrics to compare against the baseline that was established during the First Risk Assessment; this enables trend analysis. The activities required for a large-project Major Review are therefore:

•  Facilitate a risk workshop to review all current risks and newly raised risks.

•  Identify, describe, and assess new risks; appoint risk owners; and develop responses.

•  Update the Risk Register.

•  Revise and define risk actions, and appoint action owners.

•  Update the QRA model to determine predicted project outcomes both pre-response and post-response.

•  Update the project plan to take into account risk actions.

•  Update risk metrics to allow trend analysis.

•  Draft and distribute a full risk report and other information needed for project reporting.

•  Consider the efficiency and effectiveness of the risk management process.

Post-Project Review

The ATOM risk process emphasizes learning from experience by concluding with a Post-Project Review step at the completion of the project. Organizations perform projects for two main reasons: to create the specific project deliverables that enable achievement of benefits, and to gain experience that can be used on future similar projects. Even the smallest project can generate useful lessons for future projects. Therefore, the ATOM Post-Project Review is required for small, medium, and large projects.

Figure 14-15: Typical Agenda for a Risk Lessons-Learned Meeting

Like other parts of ATOM, the Post-Project Review step is scalable. For small projects, this activity forms part of the wider post-project review meeting, as described in Chapter 13. Medium projects might also perform ATOM Post-Project Review tasks during the post-project review meeting, or they may elect to hold a separate risk-related meeting, as described in Chapter 12. However, for large projects the scope of lessons that can be learned is likely to be greater, and consequently more effort is justified for the Post-Project Review step. As a result, Post-Project Review for large projects is always undertaken in a separate, dedicated risk lessons-learned meeting, held prior to the main post-project review meeting.

The risk lessons-learned meeting is chaired by the project manager, supported by the risk champion, and attended by all key stakeholders. A sample agenda is provided in Figure 14-15. Discussion at this meeting is structured around the project’s RBS to ensure consideration of all sources of risk, and to provide a consistent framework for transferring lessons to future projects. During the meeting, the risk champion captures lessons to be learned and later produces a risk lessons report to communicate lessons learned to key stakeholders and the wider organization.

Figure 14-16: ATOM Activities for a Large Project

The activities required to perform the Post-Project Review step for a large project are:

•  Prepare risk information for consideration at the meeting.

•  Hold risk lessons-learned meeting.

•  Capture conclusions in risk lessons report as input to the main post-project review process.

Conclusion

The scalable nature of ATOM makes it applicable to all projects, including those that are significantly risky. For these large projects, it is particularly important that all risks are managed proactively and effectively, in order to maximize the benefits delivered to clients, the organization, and other stakeholders, and to minimize the potential for disastrous adverse outcomes.

The key is to provide a risk management process that is sufficiently robust to meet the risk challenge of a major project, but that does not impose an unacceptable bureaucratic overhead on the project team. By building on the ATOM process for medium projects, ATOM for large projects only adds effort and complexity where there is a clear need to do so. The enhanced ATOM risk process for large projects described in this chapter (and summarized in Figure 14-16) provides the required benefits cost-effectively.