|
|
9.5. Risk identification techniques
Richard E. (Dick)
Èñòî÷íèê: Richard E. (Dick) Fairley Managing and leading software projects // a John Wiley & Sons, inc., publication. 2009.
As indicated in the various standards and guidelines for risk management, project
risk factors must be identifi ed as they develop. Risk factors should be identifi ed,
analyzed, prioritized, and mitigation plans developed, to the extent possible, during
initial project planning, but risk factors must also be identifi ed, analyzed, prioritized,
and mitigated on a continuous, ongoing basis. Some potential problems will not
materialize; for example, the hardware you need is delivered on schedule, so the
risk of late delivery does not become a problem. Other unforeseen risk factors will
arise as the project evolves; for example, your software architect tells you she may
be moving to another city for personal reasons, but she is not certain she will and
she is not sure when she will move, if she does.
Some risk factors thought to be settled may re-emerge. For example, a former
risk of failure to achieve consensus on the layout of the user interface that was
previously achieved may now re - emerge because some new users who have recently
joined the users ’ organization are saying they want major changes. This re-institutes
the risk of late product delivery based on lack of consensus among the users.
Some techniques for identifying risk factors are listed in Table 9.4. In general,
any technique you use to identify potential problems for your project can be used
for risk identifi cation.
9.5.1 Checklists
Checklists are often used to identify risk factors. They can be used by individuals,
in group meetings, or as aids to those participating in a Delphi process (see Chapter
6). The risk taxonomy developed at SEI is one of the best-known checklists for
risk identifi cation [Carr93] . The taxonomy is a three-level hierarchy of commonly
occurring risk factors for software projects. Table 9.5 a lists the top two levels of
the hierarchy. Table 9.5 b lists some of the second-level and third-level elements in
the hierarchy. The report that contains the full taxonomy and other aspects of
risk identifi cation and risk management can be accessed at the URL cited in
[Carr93].
Table 9.4 Some techniques for identifying risk factors
|
1. Checklists
2. Brainstorming
3. Expert judgment
4. SWOT analysis
5. Assumptions analysis
6. Constraints analysis
7. Lessons – learned fi les
8. Cost modeling
9. Schedule analysis
10. Requirements triage
11. Assets inventory
12. Trade-off analysis |
|
Table 9.5a Top levels of the SEI risk taxonomy [Carr93]
| Top-Level Elements | Second-Level Elements |
| A. Product engineering (technical aspects of the work) |
A.1. Requirements
A.2. Design
A.3. Code and unit test
A.4. Integration and test
A.5. Engineering specialties |
| B. Development environment (methods, procedures, and
tools to be used)
|
B.1. Development process
B.2. Development system
B.3. Management process
B.4. Management methods
B.5. Work environment
|
| C. Program constraints (contractual, organizational, and
operational factors that are outside the control of local
management) |
C.1. Resources
C.2. Contract
C.3. Program interfaces
|
Table 9.5.B Some second- and third- level elements of the SEI risk taxonomy
[Carr93]
| Second-Level Elements | Third-Level Elements |
| A.1. Requirements |
A.1a. Stability
A.1b. Completeness
A.1c. Clarity
A.1d. Validity
A.1e. Feasibility
A.1f. Precedent
A.1g. Scale |
| B.1. Development process |
B.1a. Formality
B.1b. Suitability
B.1c. Process control
B.1d. Familiarity
B.1e. Product control |
| B.3. Management process |
B.3a. Planning
B.3b. Project organization
B.3c. Management experience
B.3d. Program interfaces |
|
B.5. Work environment |
B.5a. Quality attitude
B.5b. Cooperation
B.5c. Communication
B.5d. Morale |
|
C.1. Resources |
C.1a. Schedule
C.1b. Staff
C.1c. Budget
C.1d. Facilities |
|
|