14 Establish the Initiative

Destiny is not a matter of chance; it is a matter of choice. It is not something to be waited for; but, rather something to be achieved.

—William Jennings Bryan

It takes initiative to respond to project requirements for risk management. I chose the word initiative because it has a circular definition that leads to risk. Initiative means to take the first step, as in a venture. Venture is synonymous with risk, because of the uncertainty in any new endeavor. An initiative is defined by the energy and enthusiasm that is associated with a new beginning. It is also defined by inventiveness and ingenuity, due to the creativity and resourcefulness required to build a new product.

The purpose of establishing a risk management initiative is to provide the context for performing risk management that is integrated within the project. Establishing an initiative involves reviewing requirements from the customer and organization and planning for risk management activities. The project manager, responsible for allocating resources for the risk management initiative, can delegate the task of coordinating training for project participants to encourage their involvement in risk management activities.

In this chapter, I provide a checklist to help you respond to project requirements for risk management.

This chapter answers the following questions:

Why is risk management a derived requirement for all projects?

How much does a risk management initiative cost?

What is the recommended approach for risk management training?

14.1 Review Risk Management Requirements

In order to establish a risk management initiative, you should review where your project’s risk management requirements come from because these requirements are the drivers for establishing this initiative. Project requirements are a combination of contractual, organizational, and derived requirements. Contractual requirements for risk management are often contained in a statement of work (SOW), which typically specifies planning risk management activities and implementing risk management on a project. Organizational standards for risk management start with a policy that sets expectations for project behavior. Some requirements are not explicitly stated but are derived from goals and objectives. Derived requirements for risk management can originate from the marketplace, competitive bids, the use of new technology, or system complexity. Risk management is a derived requirement from the need to nail the cost, schedule, or technical system performance. Another reason that risk management is a derived requirement for all software projects is the volatility of the software industry. Software has never been more complex or costly than in today’s environment.

14.1.1 Review Contractual Requirements

A project SOW is likely to contain contractual requirements for risk management. The vocabulary that describes risk management in the SOW, however, is often different from the organizational standard terminology. Contractors as software producers and customers as software consumers often use different words to describe similar concepts. A lookup table like the one shown in Table 14.1 can be generated and used to translate customer requirements. It is best to use consistent terminology and avoid overloading words whenever possible.

Table 14.1 Risk Management Terminology Translation

You may want to adapt the Glossary from this book to create your set of terms. Working on one particular proposal team, I generated a list of about 20 words to describe the contractor’s risk management approach in the customer’s terms. Risk was addressed consistently in the technical proposal by asking the proposal team members to use the words on the list. Note the consistent use of customer language in the following specification from a SOW [USCG94], which outlines the project management plan and the risk management program required by the contract:

Project management plan. Planning activities shall include risk management practices and mechanisms for controlling resources and schedule.

Project management review: At each project management review, the contractor shall report progress and work status to the customer and shall address risk management areas and activities.

Risk management plan: The contractor shall indicate plans for engineering specialties, such as risk management.

Risk management metrics: The contractor shall describe the methods to be employed for software engineering planning and control, including the use of software management metrics for risk management.

Risk management status: The contractor shall conduct a general session to report progress and work status on all active task orders to the customer and shall address risk management areas and activities.

Risk management program. The contractor shall plan and implement a risk management program that includes a continuing analysis of the risks associated with the cost, schedule, and technical parameters and describes the reduction of those risks to an acceptable level through effective management. The contractor shall address risk analysis, risk reduction, and risk management.

Risk analysis: This analysis shall include identification and assessment of risk; the likelihood of occurrence, evaluation of the impact of risk on cost, schedule, and technical performance; and the identification of alternatives to avoid or minimize risk.

Risk reduction: This activity shall involve the selection of risk reduction alternatives, definition of courses of action to implement risk reduction alternatives, commitment of staff, and financial resources to support risk reduction actions.

Risk management: This activity shall establish a procedure to monitor progress of risk management activities, and report results of the risk management program to the customer.

Risk management progress: The contractor shall document risk management activities and report progress to the customer in the monthly progress reports.

14.1.2 Review Organizational Standards

Organizational standard operating procedure should contain requirements for risk management. A draft company policy statement for risk management is defined in Chapter 9. Following is an example of a standard operating procedure for risk management that could serve as an organizational standard (note the consistent use of contractor language in this procedure):

The purpose of risk management is to assess and control risks. Risk management involves identifying potential problems throughout the project. Identified risks are analyzed to determine their probability and consequence. Risk resolution plans are developed to resolve risk. Risks and risk resolution plans are then tracked to closure. Communication of risks and risk resolution plans to affected groups is emphasized.

Risk management involves performing the tasks necessary to identify, analyze, plan, track, and resolve risks using a defined risk management process. The risk management process may be part of the project’s defined management or engineering process.

Goal 1: A risk management initiative is planned and implemented throughout the project (at all operational levels).

Goal 2: Risks to the project are assessed and controlled according to a documented risk management process throughout the life cycle.

Goal 3: Risk management activities are documented, reviewed, and reported.

The project follows a written organizational policy for planning and implementing a risk management initiative. The policy specifies that:

1. The risk management plan is peer reviewed in order to promote commitment and understanding.

2. Risk management activities involve the project team, customer, end user, and suppliers as appropriate.

3. Risk management activities are reported and tracked.

4. A risk assessment is performed early in the project life cycle using a defined process.

5. Risk identification activities focus on the identification of risks, not placement of blame.

6. The results of risk identification activities are not used by management to evaluate the performance of individuals.

7. Each project routinely assesses and controls risk as part of project management tasks.

14.2 Plan Risk Management Activities

Once risk management requirements are understood, you can plan for risk management activities. Specific project requirements help to define the tasks to plan and implement risk management. The scope of the activities is based on the project attributes of size, budget, and complexity and is adjusted to fit project constraints. The project planning process [Paulk93] can be used to plan the risk management activities on the project. A sample project planning process is shown as an IDEF0 diagram [AirForce81] in Figure 14.1. The process elements Budget, Schedule, Staff, and Plan are the major tasks that transform requirements into cost estimates, a project schedule, an organization chart, and project plans. The risk management plan is an integral part of project plans [Thayer88]. (The details of the risk management plan are examined in Chapter 15.)

14.3 Budget Risk Management Activities

Phil Crosby [Crosby80] said that “quality is free,” but risk is not free. Risk is a potential loss, and the only way to turn that around is risk management. Risk management is an investment in future payoff. We manage risk to gain¹ a return on investment. The old adage, “It takes money to make money,” reminds us that life accumulates. For example, we expect each dollar that we invest to double in a certain amount of time. This payoff cannot be exactly known because of future uncertainty, such as inflation. But we do know that if we never invest the money, we will never have the opportunity for future payoff.

¹ It is not a good strategy to manage risk to the break-even point. Due to the uncertainty associated with risk, we should expect a return with a margin for error.

Budgeting for risk management activities is the initial investment required for future payoff. Later, mitigation costs are incurred when there is reason to believe that risk leverage exists. You should add a line item for each risk management activity on the project master schedule. Be sure to cost the baseline risk assessment using the assessment method that your project budget will support. How much does a risk management initiative cost? The answer to this question is the sum total of the budgeted line items.

14.4 Schedule Risk Management Activities

Schedule risk management activities—developing the risk management plan, training the people, baselining the risk, and verifying risk management practices—on the project master schedule. You may want to allocate more time on the schedule for a high-risk area to ensure a delivery date. If your budget is inflexible, schedule a lower level of effort over an extended period to provide the time needed to address a high-risk area. Consider schedule dependencies for high-risk areas, to schedule the correct order of activity. Activities that are not completely in your control, such as those with external interfaces, often take longer. You can specifically schedule technical interchange meetings to address risk and incorporate risk issues within project reviews and other meeting agendas.

Figure 14.1 Project planning process diagram. The planning process is used to transform risk management requirements into a documented risk management plan. The plan may be contained within the project management plan, the system engineer ing master plan, or the software development plan.

14.5 Staff Risk Management Activities

Ultimately, the project manager is responsible for software risk, but the majority of the responsibility to manage risk must be delegated. People inherit responsibility for risk management by their assigned role on the project. For example, oversight for risk management verification can be delegated to quality assurance specialists. One way to coordinate risk management activities is to create a special assignment to the role of risk manager. This role is often filled by a senior technical person but is not required to be a full-time position. Staff risk management activities by involving the appropriate mix of people. Encourage participation from the customer, senior management, and the project team.

14.6 Coordinate Risk Management Training

Assigning responsibility for managing risk without the ability to execute the task is setting up people for failure. Coordinate risk management training for project staff to develop their ability to manage risk. With training, they will be prepared to perform risk management activities. Training should be specific to the project procedures that are used to implement the risk management plan. (Training for risk management is described in Chapter 11.)

Just-enough is a recommended approach for training material that builds on current knowledge. With just enough training, the people will not feel overwhelmed by the amount of information or feel they must become an expert over-night. They should understand there is a developmental path and know where they are on the path.

Just-in-time is another important concept. Train the project team so they can apply the concepts immediately. Lectures must be accompanied by exercises that provide practice in applying new methods. There should also be time for answering questions that arise when people practice new methods.

14.7 Summary

In this chapter, I provided a checklist to help you respond to project requirements for risk management. The checklist includes the following activities:

1. Review risk management requirements.

2. Plan risk management activities.

3. Budget risk management activities.

4. Schedule risk management activities.

5. Staff risk management activities.

6. Coordinate risk management training.

Risk management is a derived requirement for all projects because of the increasing rate of change in the software industry. The environment for software development is more complex and costly than ever before.

Risk is not free. It is a potential loss, and the only way to turn that around is risk management. Risk management is an investment in future payoff. This payoff cannot be exactly known, because we must consider future uncertainty, such as inflation. Budgeting for risk management activities is the initial investment required for future payoff. Later, mitigation costs are incurred when there is reason to believe that risk leverage exists. You should add a line item for each risk management activity on the project master schedule. A risk management initiative cost is the sum total of the budgeted line items.

The recommended approach for risk management training is to build on the team’s current knowledge and have them apply the concepts immediately.

14.8 Questions for Discussion

1. List three risks in establishing a risk management initiative. Assess the probability and consequence of each risk.

2. Compare and contrast contractual and organizational requirements for risk management.

3. Explain why risk management is a derived requirement on most software development projects.

4. What would you do if your organizational standard terminology for risk management was different from your customer’s vocabulary?

5. List three resources that you need to manage risk.

6. How could you add risk assessment as a line item cost to baseline software risk?

7. How could you add time for risk management to project meeting agendas?

8. How could you encourage participation from the customer, senior management, and the project team for managing software risk?

9. In what way is training for risk management specific to a project?

10. Do you agree that destiny is a matter of choice? Discuss why you do or do not agree.

14.9 References

[AirForce81] Integrated Computer Aided Manufacturing Architecture, Part II, Vol. IV: Function Modeling Manual (IDEF0). AFWAL-TR-81-4023. Wright-Patterson Air Force Base, OH: Air Force Systems Command, June 1981.

[Crosby80] Crosby, Phil. Quality Is Free. New York: McGraw-Hill, 1980.

[Paulk93] Paulk M, et al. Capability Maturity Model for Software. Version 1.1. Technical report CMU/SEI-93-TR-24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993.

[Thayer88] Thayer R. Software Engineering Project Management. New York: IEEE Computer Society Press, 1988.

[USCG94] United States Coast Guard. Vessel Traffic Services (VTS2000) Statement of Work. Washington, DC, 1994.