14

C hecklists

Technique Description

Checklists are classic tools of risk identification, drawing on the expe-

rience of other project managers and past projects to ensure a level
of consistency in early risk analysis. They consist of simple lists of
questions or statements based on lessons learned from earlier projects,
which allow the project manager to build early risk lists that reflect
risks faced on previous projects.

When Applicable

This technique is recommended for all projects in organizations where

checklists have been developed. Some external organizations, such
as the Software Engineering Institute (SEI), have developed generic
risk identification checklists for all projects in a given field (such as
SEI’s taxonomy-based risk identification checklist). The technique is
normally applied early in a project, though checklists can also be used
at midterm and final project evaluations. PMI® recommends applying
checklists each time a project-closing procedure is conducted and also
emphasizes that the lowest level of the risk breakdown structure (see
Chapter 15) may be applied as a risk checklist.

Inputs and Outputs

The inputs to build the checklists are the past experience of project
teams and clear documentation of their experiences. After the check-
lists have been created, however, the inputs to applying checklists are
nothing more than the checklists themselves. The project manager

15 9
16 0 Risk M a n ag em en t

and the project team should take the checklist and openly, honestly
discuss the concerns that the tool addresses.
Depending on the construction of the tool, the checklist may do
little more than generate red flags to warn of categories of concern or
specific risks. If the tool is software driven and more complex, then
it may also provide a list of recommended basic actions to guide the
project manager and the team toward best-practice experience in han-
dling any of the risks or risk areas identified in the tool.

Major Steps in Applying the Technique

Operating under the assumption that a checklist has already been

created, the process associated with checklists is among the simplest
of all the risk tools:
Review the risk checklist. Ensure that the project team is working
with a checklist that is appropriate to the environment, the
culture, and the project in question. Since some risk check-
lists are designed to address issues within a given organiza-
tion or within a given project type, it is important to work
with a tool that is appropriate to the project at hand.
Answer the questions or check the appropriate boxes on the checklist.
Checklists normally come with guidance to direct the user on
the appropriate application. Such applications consist of sim-
ple question-and-answer sessions or rating schemes to assess
the likelihood of encountering some common risks.
Review and communicate the guidance provided. Even though
checklists normally include some direction about how to com-
plete them, they also include guidance on how to apply the
findings. In some cases, these findings may represent nothing
more than a list of commonly identified risks (or risk areas) for
the project. However, some of the more advanced checklists
will also embed suggestions on the standard internal practice
and procedure for resolving or managing the risks identified.
Guidance of any nature should be communicated to the team.
Organizations looking to build their internal risk practice can fre-
quently develop that practice by generating checklists. Checklists are
 C hec k lis t s 161

often among the first steps that a project office takes to build a broader
understanding of the depth of risks within the organization and the
support that they can provide in ameliorating some of those risks.

Use of Results

Since checklists are first applied early in the project, outputs can be
used to provide a general understanding of the nature of risks and the
concerns in the project in a nonthreatening manner. Data from risk
checklists tend to cause less anxiety because the questions asked (or
statements made) are applied equitably to all projects and the outputs
are normally familiar to the organization. Outputs at the end of the
project should be used in any reevaluation of the checklists for addi-
tions or deletions. Checklist analysis should not be considered a pana-
cea for risk identification. Efforts should be made to identify risks not
directly called out in a checklist.

Resource Requirements

Checklist reviews normally require only two participants. At least

two people should review a series of checklist responses to ensure that
personal biases do not influence the outputs. The only other resources
required are the checklist(s) and a tool for storing the outputs of the
process.

Reliability

The reliability of the process pivots on the quality of the checklist.

A sound checklist built to reflect the organization’s culture, nature,
and project history will build an excellent set of initial project risks.
A checklist that a single individual crafts after a single project without
considering the organizational culture will have limited reliability.
The best checklists are those that capture experience from a variety of
projects and project teams. Answered candidly, checklists of that cali-
ber can generate extremely positive and reliable (although not inher-
ently comprehensive) results.