This technique highlights and isolates risk disparities in planning. It evaluates project plans for contradictions and voids. Traditional, formal plans used to guide a project include the following:
Project Quality
Communication Contracting w Testing
Training
Other documents are also essential to the success of the project and to such evaluations:
w Work breakdown structure (WBS) w Project specifications
Statement of work (SOW) Contracts
w Other baseline documents
Although plans outline project implementation steps, other documents represent critical communication with stakeholders about what is to be done. Flaws, inconsistencies, contradictions, and voids in these documents inevitably lead to project problems and introduce significant risk. Figure 12 illustrates the linkage between three key documents.
/\
$38,
s
*#P
% h % o %* %,a,".,
"rpS o w )
I
Are specifications*
specificationsproperly included in all SOWS?
E l
Figure 1 2. Plan Evaluation Technique
Technique Description
The plan evaluation technique simply suggests a thorough, recurring internal review of all plans for correctness, completeness, and currency, with a cross-check for consistency.
Using the WBS for Risk Identification
Proper development of a WBS represents a major step in risk control because it constitutes much of the project definition. Its quality-indeed its very existence-provides the planning framework that sets the standard for the future of the project. As a WBS is completed, a careful examination is appropriate:
w Are all elements of the WBS necessary and sufficient?
Is there a WBS dictionary, and does it adequately explain the content of each element?
w Does the WBS represent what is to be done rather than who is to do it?
w Are all elements of the WBS present?
H Is the contracting strategy reflected in the project WBS?
w Is any work to be done not reflected in the WBS?
The WBS offers a framework for organizing and displaying risk factors.
The technique of downward allocation and upward summarization through the WBS can be used to highlight discrepancies in most of the project's performance parameters, such as efficiency, reliability, cost, and capability.
The WBS provides a sensible structure for treating technical risk. A systematic review for risk identification and preliminary rating of each WBS element will yield much information for the risk analyst.
100 Chapter 9
The relationship between the WBS and the specifications is so impor- tant that mapping the relationships is a valuable exercise for the risk analyst. Mapping will highlight inconsistencies between the work to be done and the performance to be achieved.
The project WBS eventually becomes the aggregate of all contract information, including subcontractors' plans. The risk analyst should review the WBS with the question "Who is doing what?" as a test of reasonableness of the contracting strategy. Finally, the WBS represents the framework for cost and schedule performance (although it is not a representation of the schedule itself). A survey of both cost and schedule reporting in the context of the WBS identifies possible blind spots in cost and schedule information. As part of this survey, the analyst can gain valuable insights by comparing the numbering schemes for the WBS, scheduling system, and cost-reporting system. Ease of translation among and ease of summarization within each of these numbering systems can indicate how well traceability among the WBS, schedules, and cost data can be maintained. Incompatibility introduces management risk into the project.
To extract additional risk from the WBS, any variety of techniques may be used, with each one posing the question, "What are the risks for this WBS element!" Expert interviews, brainstorms, and the Crawford Slip Method can all generate that information.
1 Using Specifications for Risk Identification
Some of the previous discussion deals with the important relationship between the WBS and the specifications and the need for compatibility.
When that compatibility exists, the performance to be achieved can be related to the work to be done. Because the specifications represent the source of all technical performance requirements, they are the single most important source of information for the risk analyst attempting to identify, organize, and display items of technical risk. Each performance parameter of a given WBS element represents a possible focus for an expert interview on technical risk.
I
As with the WBS, a survey of the specifications is appropriate for risk identification:Do the specifications overlay the WBS so that performance require- ments are specified for WBS elements?
Are all performance parameters identified even though they may not be specified (that is, given a discrete value)?
Plan Evaluation 101
w Can the risk of achieving the specified value for the performance parameter be sensibly discussed?
Is there a technical performance measurement scheme for each performance parameter?
Using Statements of Work for Risk Identification
The SOW is the single most important communication between the project organization and the customer. If the WBS and the specifications are complete and well developed, SOWS are fairly straightforward. The risk analyst is searching primarily for gaps in coverage and should consider the following:
Does the SOW cover whole parts of the WBS that can clearly be evaluated against the specifications?
w Does the SOW represent work that matches the project organization in terms of politics, contractual capabilities, and legal capabilities?
m Is all work contractually covered?
w Are the SOW requirements properly related to the specification?
Developing a Technical Risk Dictionary
A dictionary in project management can expand understanding and pro- vide documentation and background on a specific project area. Thus far, this chapter has addressed the need to gather all project information with common descriptions into a common database. A technical risk dictionary, as conceptualized in Figure 13, offers the risk analyst a single place to gather this information for facilitating the risk identification and definition processes.
Until recently, creating a technical risk dictionary has been a formidable editorial task. Advances in project management software, coupled with advances in documentation management, allow for integrated data within a single database, and in some cases, a single file. In most popular project management software packages, there are sufficient available text and numbers fields so that the bulk or whole of the risk dictionary can be maintained in the same file as the project plan itself. If the text and numbers fields are to be used this way, then the same text field used for one element in one project (for example, Textl3=Performance Risk) should be used for the same purposes in all projects within the organization to facilitate knowledge transfer.
Such information maintenance practices afford project managers a
"home" where their risk information can readily be shared with the team,
102 Chapter 9
Project Specifications
0 b d Q
Technical content
Performance
Task
3.6.2.1 SAMPLE
I
Figure 13. Technical Risk Dictionary
and where risk identification and management can be integrated into day-to-day operations.
Using Other Plans for Risk Identification
"Risk Identification" in Chapter 3 discusses the use of a top-level risk matrix to highlight and isolate risks. The matrix relies heavily o n goal definition and strategy development. The presumption is that the strategies expressed in the project plans are directed at meeting the project goals.
Comparing the two can identify risks. The same thinking can be applied to lower-level risk matrices associated with any other plans (communication, quality, testing, and so on) that are developed.
When Applicable
The plan evaluation technique is directed specifically at risk identification and is best used for technical risk. Its utility for cost and schedule risk is considerably lower. However, this technique could highlight missing information concerning deliverables that would affect cost and schedule risks. It is most applicable to the implementation phase of a project. As a risk identification technique, it requires the existence of the plans to be evaluated. As a strategy tool (to identify what risks can be avoided), it can be used during the project planning process.
Plan Evaluation 103
Inputs and Outputs
Plan evaluation operates on the collective body of documentation broadly referred to as project plans and includes primarily those documents listed earlier. Outputs typically include-
w Top-level risk matrix w Lower-level risk matrices w Technical risk dictionary
w Updated versions of project plans