13

ATOM for Small Projects

Everyone involved with projects agrees that they are risky endeavors subject to a wide range of sources of uncertainty. If all projects are risky, it follows that all projects need risk management, at least to some degree. However, it is also abundantly clear that not all projects are the same, either in scope or in risk exposure. The risk level is vastly different for a project to move an office and for a project to launch a space shuttle. So, although all projects need to address risk management somehow, the level of treatment can and should vary.

Although risk management can be undertaken at a variety of levels, the standard risk process still applies to every project, because there is always a need to clarify scope and objectives (Initiation), find the risks that could affect the project (Identification), prioritize those risks for further attention (Assessment), decide how to deal with them (Response Planning), take appropriate action (Implementation), communicate results (Reporting), keep it up to date (Reviews), as well as identify lessons to be learned at the end of the project (Post-Project Review). Therefore, the standard ATOM risk process as described in earlier chapters can be applied to every project. However, the fact that different projects face different risk challenges is reflected in the scalable nature of the ATOM process.

Chapter 3 discussed how projects could be divided into three notional groups using a project sizing tool. Within the typical organization, most projects fall into the medium-sized category; the standard ATOM risk process detailed in Part II (Chapters 4 through 12) provides an approach for these types of projects. Because ATOM is scalable, it can also be applied to small and large projects, following the same process framework but with varying levels of detail. This chapter describes how to modify the standard ATOM risk process to make it suitable for small projects; Chapter 14 addresses process modifications for large projects.

Less Is More

Small projects lack some of the characteristics that result in higher risk exposure, though, like all projects, they involve uncertainty. Their lower level of risk, however, allows the ATOM risk process to be simplified while retaining the essential elements for effective management of risk.

The challenge is to reduce process complexity without making the resulting process inadequate to the task—to simplify without becoming simplistic.

ATOM for small projects follows the same generic risk process (see Figure 13-1), but each step is reduced to minimize the time and effort required without cutting important tasks. This chapter works through the steps in the ATOM risk process and presents changes to the standard approach previously described for medium projects. (For further details of the standard approach, refer to the appropriate chapter in Part II.)

Figure 13-1: Steps in the ATOM Process

As for medium projects, the ATOM process for small 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 step, as illustrated in Figure 13-2.

Initiation

The purpose of the Initiation step is to define the scope and objectives of the risk process as they will be applied to this project, and to allocate roles and responsibilities for risk management. Decisions made during the Initiation step are documented in a Risk Management Plan, so all project stakeholders know how risk will be managed for their project.

The Initiation step for the small project is reduced in several ways from the requirements for a medium project (see Chapter 4). The main difference is in the method used to produce the information contained in the Risk Management Plan. For medium projects an Initiation meeting is held, attended by key stakeholders and facilitated by the risk champion. This meeting is not required for a small project, and the project manager produces the Risk Management Plan in liaison with key stakeholders. Nor is there a need for a formal stakeholder analysis during the Initiation step for a small project, because the project manager is likely to be aware of the stakeholders and their needs and is able to document these in the Risk Management Plan without conducting a stakeholder analysis.

Figure 13-2: The ATOM Process for Small Projects

The Risk Management Plan itself is also simpler than the version required for a medium project, and is usually produced from a template following the sample contents list in Figure 13-3. The contents for a small project Risk Management Plan mirror those for medium projects, but with less detail. One particular area where detail is reduced is in the definition of roles and responsibilities; a RACI chart (Figure 4-6) is not required.

Figure 13-3: Sample Contents List for a Risk Management Plan for a Small Project

Another key difference is in the allocation of staff to risk roles. A small project rarely has a full-time risk champion. This role can either be provided as part-time support from a central resource pool such as a project office, or, more typically, the responsibilities of the risk champion are undertaken directly by the project manager. However, even the small project needs to nominate risk owners and action owners who are responsible for managing individual risks, because the project manager cannot be expected to manage all identified risks.

The Risk Management Plan defines the assessment framework to be used during the risk process, which can be simplified for the small project. The framework for a medium project usually has five-point scales (VLO, LO, MED, HI, VHI) for both probability and impacts (see Figure 4-8) to provide the necessary granularity to discriminate between risks. For a small project, the project manager should consider using a simpler risk assessment framework, perhaps with three-point scales (LO, MED, HI) or four-point scales (VLO, LO, MED, HI). Figures 13-4 and 13-5 give examples of such scales; the project manager should agree with the project sponsor on the assessment framework to be used and document this decision in the Risk Management Plan.

Figure 13-4: Three-Point Project-Specific Probability-Impact Scales

Figure 13-5: Four-Point Project-Specific Probability-Impact Scales

The Risk Management Plan also describes the tools to be used to support the risk process; the small project typically uses simple spreadsheets or databases rather than a proprietary risk tool. The exception is when the organization uses a standard risk toolset for all projects or an enterprise-wide risk system containing data for every project undertaken by the business, in which case even small projects are required to use the standard tools or hold their risk data on the standard system.

The tasks required to perform the Initiation step for a small project are summarized as follows:

•  Project manager confirms project objectives and risk assessment framework with project sponsor

•  Project manager drafts Risk Management Plan for approval by project sponsor

•  Project manager issues Risk Management Plan to project team and key stakeholders.

Identification

The Identification step aims to expose and document all knowable risks to project objectives. In reality, this is a never-ending task; it is therefore important to place boundaries on the effort spent on this step. However, it is also essential to not skip this step or pay too little attention to risk identification, since risks that are not identified cannot be managed, and the project will experience unexpected problems as well as miss potential benefits.

For the Identification element of the First Risk Assessment on a small project, two reductions are made from the Identification step as implemented on the medium project (see Chapter 5). These are:

1. Perform risk identification (as well as assessment and response development) in an existing project team meeting rather than holding a specific risk identification workshop.

2. Limit the risk identification techniques used.

The project manager leads the project team in the risk process and sets aside time for this in regular project team meetings. The project team should expect to spend more time on the risk process during the First Risk Assessment than later in the project; typically, two to three hours should be allocated to this activity (to include risk identification, assessment, and response development). It is recommended to include the risk element of the project team meeting as the first agenda item, when people are fresh for the task. The project manager leads the risk identification process, unless a part-time risk champion is available to lead this part of the project meeting. Figure 13-6 outlines the risk identification steps included in this part of the meeting.

Figure 13-6: Risk Steps during Project Team Meeting for Small Projects

Two risk identification techniques are used for the small project that provide results quickly and with minimum effort but without compromising the data quality or shortcutting the process. It is important to have sufficient time for risk identification; otherwise, key risks are likely to be missed and go unmanaged. The two techniques are:

1. Analysis of assumptions and constraints

2. Risk identification checklist.

These techniques are detailed in Chapter 5 and summarized below.

•  Analysis of assumptions and constraints. The project assumptions and constraints should already be documented in the project business case, project charter, or other statement of work. If not, the project manager arranges a short meeting with the project sponsor before the project team meeting in order to identify and document them and to ensure that hidden or implicit/tacit assumptions and constraints—as well as the explicit or more evident ones—are exposed as much as possible. The list of assumptions and constraints from this meeting or from the existing project documentation is then discussed at the project team meeting. Team members review each assumption and constraint in turn, asking two questions:

•  Could this assumption or constraint be false?

•  If it is false, how will project objectives be affected?

If an assumption or constraint could be false and would matter to the project, team members should raise a risk.

•  Risk identification checklist. If the organization has a standard risk checklist, it is considered during the team meeting. Each item on the checklist is reviewed, and meeting participants ask whether the risk could be relevant to the project and raise a risk when the answer is “yes” or “don’t know.” If there is no existing risk checklist, the project manager may lead a short open discussion with the project team to identify any risks not raised during the assumptions and constraints analysis.

Following use of these two structured risk identification techniques, the project manager invites team members to raise any risks not yet mentioned, perhaps by leading a short brainstorming session. This need not take long since the two main techniques should have exposed most of the risks, but it allows each team member to have his or her say.

The project manager encourages the team to identify both threats and opportunities, and ensures that all risks raised during the meeting are properly described and distinguished from causes and effects using risk metalanguage. Risks raised during the team meeting are recorded by the project manager or meeting scribe and entered into the risk management tool immediately after the meeting. The project manager then reviews each risk to ensure that the risk description is accurate and clear and that there are no duplications, making amendments as required.

Identification during the First Risk Assessment for the small project requires the following tasks:

•  Project manager clarifies project assumptions and constraints and generates a list if necessary.

•  Risks are identified during project team meeting, using assumptions and constraints analysis, then the risk identification checklist is considered, followed by a short discussion or brainstorming.

•  All identified risks are recorded and entered into risk management tool after project team meeting.

Assessment

After the list of risks is generated, these risks are prioritized for further attention and action, which is the purpose of the Assessment part of the First Risk Assessment. Assessment is described for the medium project in Chapter 6. For small projects, risk assessment is performed in the same project team meeting immediately following risk identification. A simple prioritization is achieved by assessing the two key dimensions for each risk: the probability of occurrence and the impacts on project objectives.

The project manager presents the risk assessment framework agreed on with the project sponsor and documented in the Risk Management Plan to be used when assessing identified risks. For each risk in turn, the project manager leads a discussion among project team members, covering the following topics:

•  The project manager first asks for opinions and estimates of how likely it is that the risk will occur, seeking consensus on one of the values in the assessment framework.

•  Next, the team considers how each risk might affect project objectives, using the assessment framework, again seeking consensus among team members.

•  Each risk is plotted onto a double P-I Matrix during the meeting, reflecting the assessments of probability and impact.

•  Next, each risk is assigned a risk owner, who selects an appropriate strategy and develops an initial set of actions to address the risk. Typically, project team members present at the meeting are allocated as risk owners, though others might be nominated if necessary. If people outside the meeting are assigned as risk owners, the project manager informs them and obtains their consent immediately after the meeting.

Agreed-upon estimates of probability and impacts, as well as agreed-upon risk owners, are recorded for each risk and entered into the risk management tool immediately after the meeting. These steps also appear in Figure 13-6.

After the discussion in the meeting to assess whether each risk is complete, the project manager produces a prioritized list of threats and opportunities, based on the assessed probability and impacts and the position of the risk on the P-I Matrix. Figures 13-7 and 13-8 give prioritization schemes for a double three-by-three P-I Matrix and a double four-by-four version, respectively. It may be prudent to arrange a short break in the team meeting while this is done.

The Assessment step for small projects differs from that used for medium projects because it does not progress to categorizing risks by source (using the risk breakdown structure) or by area of the project affected (using the work breakdown structure). This level of detail is usually not required for effective management of risks on small projects.

Undertaking Assessment for small projects involves the following:

•  Assess risks during the project team meeting, using the definitions of probability and impacts detailed in the Risk Management Plan.

•  Nominate a risk owner for each risk.

•  Produce a prioritized list of threats and opportunities, based on assessments of probability and impact.

•  Record assessments of probability and impacts, as well as agreed-upon risk owners, for all identified risks, and enter into risk management tool after project team meeting.

Response Planning

This part of the First Risk Assessment step in the ATOM risk process is also undertaken during a project team meeting for a small project, but without the interviews employed for medium projects (see Chapter 7). The required steps are included in Figure 13-6. There is also no requirement to formally consider secondary risks when developing risk responses on a small project, though these should be recorded and included in the risk process if they arise during the discussion of risk responses.

The Assessment step results in choosing a risk owner for each identified risk, usually one of the project team members present in the team meeting. During the Response Planning part of the project team meeting, the project manager leads a short, focused discussion with each nominated risk owner, dealing first with threats and then with opportunities, and taking them in priority order. For each risk, this discussion has two steps:

Figure 13-7: Double Three-by-Three Probability-Impact Matrix

Figure 13-8: Double Four-by-Four Probability-Impact Matrix

•  The risk owner is first asked to select an appropriate strategy for each risk, in agreement with the project manager. Threat strategies include avoid, transfer, reduce, or accept; opportunity strategies include exploit, share, enhance, or accept.

•  Having selected a strategy, the risk owner develops an initial set of actions, with at least one action per risk, and suggests action owners. Actions should be properly defined, with completion criteria, time-lines, and budgets, providing sufficient information so that the action can be unambiguously understood by the action owner and monitored by the project manager.

The Response Planning step is done during the team meeting so that other team members can contribute to the discussion with risk owners and add ideas for appropriate ways to tackle an identified risk. Team members are also likely to be nominated as action owners, so their agreement to perform actions can be obtained during the meeting.

Agreed-upon responses and actions for each risk, as well as agreed-upon risk owners, are recorded during the meeting; this data is also entered into the risk management tool immediately after the meeting.

If the risk owner of a particular risk is not present at the project team meeting, the project manager arranges a meeting with that risk owner as soon as possible to develop responses and actions. The project manager then ensures that this data is entered into the risk management tool.

The project manager also ensures that all agreed-upon actions are incorporated into the project plan immediately after the meeting, so that they can be monitored alongside other project tasks as part of the normal project management effort.

The following tasks are required when performing Response Planning during the First Risk Assessment for a small project:

•  Responses are developed in the project team meeting.

•  Risk owners for each risk select an appropriate strategy, determine actions with agreed-upon action owners, and enter data into risk management tool after project team meeting.

•  Project manager includes agreed-upon actions in the project plan.

Reporting

The reporting requirement for a small project is considerably reduced from that of a medium project (as detailed in Chapter 8). The nature, content, frequency, and distribution of risk reports is defined in the Risk Management Plan, and the project manager is responsible for producing these. For the small project, the main reporting output is the Risk Register, usually generated directly from the risk management tool. A simplified Risk Register format might be appropriate; see Figure 13-9. It is also common to produce a short risk report highlighting the current risk status of the project. A typical contents list for such a report is presented in Figure 13-10. An acceptable alternative to a stand-alone risk report is to include a risk section in the regular project progress report, which should include the same content.

Figure 13-9: Sample Simplified Risk Register Format

Figure 13-10: Sample Contents List for a Small-Project Risk Report

Completion of the Reporting step at the end of the First Risk Assessment for a small project involves these tasks:

•  Project manager compiles data from the earlier steps in the risk process.

•  Project manager produces a Risk Register and draft risk report (or risk section in regular project progress report) for approval by project sponsor.

•  Project manager issues and distributes the Risk Register and report.

Implementation

The Response Planning step of the ATOM process results in nomination of a risk owner for each identified risk, who selects an appropriate strategy and develops suitable actions, each of which has an action owner. The final step in the First Risk Assessment is to implement agreed-upon actions, which is as important for small projects as it is for medium projects. Consequently, there is no difference in how the Implementation step is performed for small projects compared with medium projects (see Chapter 9).

During this step, action owners perform agreed-upon actions and report on their progress to the risk owner. This progress is then entered into the project plan as part of the normal project monitoring process, so that the plan includes the current status of all actions.

It is also important during the Implementation step for all project team members to remain alert to the possibility of new risks. Whenever a new risk is identified, the project manager should be notified immediately. The project manager then enters it, noting the status as draft, into the risk management tool for review during the risk section of the next project team meeting.

Though it appears simple, the Implementation step is in some ways the most important of all in the ATOM risk process, because failure to implement agreed-upon actions means that risks remain unmanaged, some threats will turn into problems that should have been avoided or minimized, and some opportunities that could have been captured will be missed. It is therefore crucial to pay proper attention to this step, even for the small project.

The Implementation step for the small project involves the following tasks:

•  Action owners perform agreed-upon actions and report to risk owners.

•  Risk owners update the project plan with the status of all actions.

•  All project team members raise new risks as they become visible.

•  Project manager enters newly raised risks, with draft status, into the risk management tool.

Review

As with any project, risk exposure changes throughout the life of a small project. It is therefore important to keep the assessment of risk current, which requires undertaking risk-related actions in addition to the First Risk Assessment. The ATOM risk process includes reviews to keep the assessment of risk up to date; the medium project uses a series of Major and Minor Reviews (see Chapters 10 and 11). The Major Review essentially repeats all the steps of the First Risk Assessment, using a dedicated workshop, whereas the Minor Review is performed at a lower level of detail.

The small project is unlikely to require the full rigor of a Major Review, so the ATOM risk process includes only Minor Reviews for small projects. These are incorporated into regular project team meetings and do not require a separate risk review meeting.

During the risk portion of the project team meeting, all active red risks are reviewed in priority order, dealing first with threats, then opportunities, in a discussion led by the project manager. For each risk, the risk owner reports on progress with agreed-upon actions and allocates a status value to the risk (active, expired, occurred, closed, or deleted). If a risk remains active, the risk owner assesses its current probability and impacts, and, in discussion with the project team, determines whether new actions and action owners are required.

After all red risks have been discussed, the project manager leads a review of draft risks raised since the last meeting. These are either discarded, in which case they are marked in the risk management tool with a status of rejected, or they are accepted, in which case their status is set to active. For new active risks, the team agrees on probability and impacts, and chooses a risk owner who selects a response strategy and agrees on actions with action owners.

If time remains in this section of the project team meeting, the project manager might discuss amber risks, but this is optional. The team should also be allowed to discuss other active risks by exception; report changes in status; or suggest changes in response strategy, action, or action owners.

All changes in risk data agreed upon during the meeting must be recorded and entered into the risk management tool. An updated Risk Register is produced after the meeting and made available to project team members and other key stakeholders; however, a risk report is not usually required.

The Review step of the ATOM process for a small project involves the following tasks:

•  Active risks and newly raised draft risks are reviewed in the project team meeting.

•  All red risks, and others by exception, are reviewed.

•  Draft risks are reviewed and are either rejected or accepted.

•  Project manager enters updated risk data into the risk management tool.

•  Project manager reissues the Risk Register.

Following a review, if the project manager wishes to communicate the latest project risk status to stakeholders, a risk section is incorporated into the regular project status report; the current Risk Register can also be distributed.

Post-Project Review

Even small projects can generate valuable lessons for future projects, so a post-project review should form part of the normal project life cycle, though this is often not the case. For medium projects, ATOM recommends including a risk element in the post-project review meeting, if one is held, or holding a separate risk-related meeting (as described in Chapter 12). The same process is also recommended for small projects, with the following tasks:

•  Project manager prepares risk data for the meeting, including the final issue of the Risk Register.

•  Post-project review meeting (or a separate risk meeting) is held.

•  “Lessons to be learned” are captured, including generic risks, effective responses, and process improvements.

Conclusion

The ATOM risk process is designed to apply to all projects, including those with characteristics that suggest they are less risky. Even on these small projects, however, it is important to identify threats and opportunities, and to ensure that they are managed proactively and effectively.

There is no excuse for managers or teams of small projects to say that they have insufficient time or inadequate resources for risk management, because the simplified process described here maximizes the results while minimizing the overhead. Existing project team meetings are used instead of special risk workshops or risk interviews, and the reporting requirement is kept to a minimum. The reduced ATOM risk process for small projects described in this chapter and summarized in Figure 13-11 provides all the benefits of the more detailed process required for the medium project, but in a way that is affordable and appropriate.

Figure 13-11: ATOM Activities for a Small Project