"On large projects, a healthy respect for significant risks is the difference between success and failure; and on the large projects, the financial consequences-as well as the legal, social, and political consequences-can be devastating." --Edward Yourdon

Practice Description

Risk management is the discipline of identifying problems that could occur in a program, and systematically identifying the impact on overall program success if that potential problem were to become a reality. It also includes identifying strategies for either mitigating or avoiding the potential problem, and identifying a set of objective criteria for determining if the potential problem either has or is beginning to become a reality. Based on experience from past projects, as well as factors relevant to the current one, risk management is the process of identifying what might/could go wrong, determining the significance of the situation, steering activities to avoid it problem if possible, but being prepared to react to it, if necessary.

The discipline of risk management is vital to the success of any software effort and is done by all program managers at some level. To not perform risk management is essentially to walk blindly into a project, reacting to situations as they occur. Risk management is the process of exploiting experience to avoid problems that have plagued previous projects. In a very real sense, risk management is "the forward application of hindsight."

The disciple of formal risk management takes the natural planning process out of the minds of program planners and puts it into a structure where it can be systematically, consistently, effectively applied. In doing so, it forces program management personnel to lift their sights from their daily tasks and focus on the future. Motorola exploited this perspective by establishing something called a "preview." It was closely related to a normal program review, but its focus was macroscopic, rather than microscopic like a review. As described by Ann Miller in Engineering Quality Software Defect Detection and Prevention, "a preview gives us a chance to look ahead, identify major areas of risk in the next phase, design for and build in reusability, and assess the activities of the upcoming phase."

Intimately interwoven with risk management is the concept of corporate acceptance. A formal risk management process requires corporate acceptance of risk identification as a major factor for achieving success in complex system development. Corporate acceptance must be at the senior executive levels of both supplier/developer and government.

Practice Essentials

• The cultures of all stakeholders must support the risk process.

 
• A senior person from the buyer program office and from each supplier/developer should be given responsibility for risk management. By applying high-level attention to this problem, the visibility of risks and their impact is placed at a level capable of responding quickly to events.

 
• Risk status should be reported at least monthly to the customer and developer program managers and discussed between them.

 
• A detailed, written risk management process should be documented, which includes the essential details on how risk management will be performed on the project. This process should be objectively monitored to make sure it is being implemented.

 
• Risks should be identified for the full life cycle. Include the risks in cost, schedule, technical, staffing, external dependencies, supportability, sustainability, and programmatics. Because it is easiest to focus on near-term problems, it takes discipline to examine long-term problems.

 
• For each risk, estimate the chance it will become a problem and the impact if it does.

 
• Risks should be identified in source selection, at program inception, and then at regular intervals throughout the life cycle. However, defining risks is not enough. To be effective, mitigation strategies must be developed for key risks.

 
• Trade studies are a powerful tool for risk reduction. They identify potential alternatives to high-risk strategies. Trade studies should be accomplished at the systems level. It is imperative, however, that software engineers be included on study teams.

 
• Define early tasks to resolve whether high technical risks will materialize. For example, a task to simulate network throughput under maximum loads could be used to resolve the risk of inadequate network capacity.

 
• Risk management is a continuous process. Risks change as a program evolves. Risk management must constantly keep a focus on the most significant risks.

 
• Risk management requires open communication. Without open communication, risk management is merely an exercise in bureaucracy.

 
• Some risks will become problems. This is to be expected. If not, then there is likely a failure in your risk identification process. 

• Risks should be reported at the level where management action can be taken to mitigate or avoid the risk.

 
• Risk management should commence prior to contract award and be considered for inclusion as a factor in the award process.

 
• The supplier/developer should propose, establish, and implement a project Risk Management Plan that, at a minimum, defines how the next six points will be implemented. The plan and infrastructure (tools, organizational assignments, and management procedures) should be agreed to between the acquirer and the supplier/developer and placed under configuration management (CM).

 
• Supplier/developer and acquirer senior management should establish reporting mechanisms and employee incentives in which all members of the project staff are encouraged to identify risks and potential problems and are rewarded when risks and potential problems are identified early. The acquirer should address risk management explicitly in its contract award fee plan when risk is a major or significant consideration, and the supplier/developer should provide for the direct distribution of all non-trivial risk data to all employees in furtherance of establishing and maintaining a risk management culture.

 
• Risk identification should be accomplished in facilitated meetings attended by project personnel most familiar with the area for which risks are being identified. A person familiar with problems from similar projects in this area in the past should participate in these meetings when possible. Risk identification should include risks throughout the life cycle in at least these areas: cost, schedule, technical, staffing, external dependencies, supportability, maintainability, and programmatic. Risk identification should be updated at least monthly. Identified risks will be characterized in terms of their likelihood of occurrence and the impact of their occurrence. Risk mitigation activities should be included in the project's task activity network.

 
• Both the supplier/developer and the acquirer should designate a senior member of the technical staff as a risk officer to report directly to his/her respective program manager and charter this role with independent identification and management of risks across the program and grant the authority needed to carry out this responsibility.

 
• Each medium-impact and high-impact risk will be described by a complete Risk Control Profile, which should include four basic items: definition of risk index, which is impact likelihood; transition scenario, which includes initiating key pivotal events and likely risk occurrence; potential mitigation strategies; and key action triggers tied to metrics that initiate various mitigation activities.

 
• Periodically updated estimates of the cost and schedule at completion will include probable costs and schedule impact due to risk items that have not yet been resolved.

 
• The supplier/developer and acquirer risk officers will update the risk data and the integrated supplier/developer database on the schedule defined in the Risk Management Plan. All risks intended for mitigation and any others that are on the critical path and their status against the mitigation strategy will be summarized and reported, and an agreement will be reached on planned action and mitigation. Newly identified risks should go through the same processes as the originally identified risks.·
  
  
• Learn from the mistakes of others – today’s problem is tomorrow’s risk. 
  
  
• One common Risk area is subcontractor management.  To minimize risks in the area the following should be accomplished: Work should be subcontracted is defined and planned according to a defined procedure which indicates that products and activities are selected based on a balance of technical and non-technical characteristics, the work to be performed shall come from the SOW, system requirements, and software requirements. When a sub is involved, they should follow the same oversight, and management principles as the prime, though the scope may be scaled.  A subcontract SOW is prepared/reviewed/agreed upon revised when needed, and that a plan to select the contractor is prepared concurrently with the subcontract SOW.  Further, the software subcontractor should be selected based upon an evaluation of the subcontractor's ability to do the work.  Selection should follow a documented procedure covers the evaluation of proposals submitted, prior performance on similar work, location of the sub relative to the prime, software engineering and management capabilities, staff available, prior experience, and available resources (facilities, hardware, software, training).  The agreement between the prime and the sub should be the basis for managing the contract (SOW, terms and conditions, requirements for the products to be produced, dependencies between the sub and the prime, products to be delivered, conditions under which revisions to products will be submitted, acceptance procedures and criteria, and procedures to be used for monitoring the sub).  The sub should produce an SDP for prime review and approval.  The plan should cover the appropriate items from the prime's SDP. 
  
  
• Another common risk area is inadequate planning.  Planning is a critical step in the project process because it outlines and organizes the activities needed for success.  One common risk is inadequate planning.  To minimize this risk, the planning process should coordinate dependent activities.  It should also address support of the software team in other support activities and delineate budgets/resources.  The plan should be reviewed and approved by all program participants at a senior level.  The SDP which results should cover all activities needed to achieve project success.  Items to be included are: project purpose, scope, goals, and objectives, project life cycle, project procedures, methods and standards, software products to be developed (including interim), size estimates of products, estimates of project cost and effort, estimates for use of critical assets, milestones and schedules, identification and assessment of software risks and the risk process to be followed, and plans for necessary tools, facilities and training.  Planning for support activities (e.g. SQA) should be as rigorous as other activities.  For SQA, there should be a plan that covers the responsibilities and authority of SQA which should identify the SQA resources, identify the funding for SQA, identify SQA's role in establishing an SDP, standards and procedures, identify evaluations to be accomplished, identify audits to be performed, identify the process and standards to be followed in reviews/audits, identify the procedures to be used for recording and tracking problems, identify the records SWA must keep, and identify the frequency/method of providing feedback to software engineering groups.
  
  
• A significant risk in projects is miscommunication. A documented plan (SDP, etc) is an excellent communication tool.  The plan provides baseline schedule, contractual commitments, assignment of responsibilities, coordinates activities between groups, should be available to all team members, reflects intergroup commitments and dependencies, is kept current, and is reviewed by all team members and approved by the PM.  The project should have a mechanism for identifying, negotiating, and tracking dependencies between organizations.  Each dependency should be identified, each should be negotiated, need dates and delivery formats should be resolved, agreements should be documented and approved by all parties.  When groups cannot resolve an issue, there should be a documented process for resolving (e.g. elevate to managers)  Project planning includes developing and documenting, in the SDP,  project software processes tailored from the organization's standard. The process accounts for all life cycle phases, and contractual waivers. Process plans are reviewed by Quality and management and approved by senior management. Changes to the software process are managed and controlled with reviews and management approvals.
  
  
• Another Risk area is lack of focus.  This comes from lack of attentive leadership at the working level.  It is critical that Management put someone in charge.  A software project manager with the necessary background and skill should be identified and assigned responsibility for building an effective team, developing a software development plan and process that is consistent with the systems development process and successfully delivering the project.  Management should provide the PM with the assets needed to succeed as well as clear, objective measures of success.  The PM should also have the authority necessary to commit the organization.

 
• Identify risks in meetings attended by project staff most familiar with the topic of the meeting and facilitated by a person who understands the metrics of problems from past projects. Yesterday's problems are today's risks.

 
• Schedule risk-resolution tasks with sufficient slack to implement a workaround.

 
• Maintain an automated risk database easily accessible to all people working on the project.

 
• Implement contracts that ensure an equitable and sensible allocation of risk between buyer and developer.

 
• Establish contingency funding and schedule slack for risks that materialize into problems, based on the sum of the products of individual risk item probability and cost/schedule impact if the risk materializes. Include expected cost and schedule impact of unresolved risks in periodic updates of estimates of cost and schedule at completion. 

• Cultural resistance to admitting there is risk, often with good reason, is the greatest obstacle to risk management. Customers or senior executives usually react very negatively to an admission of risk.

 
• Many programs "game" a risk management program to meet buyer expectations. The typical approach is to list trivial items as the identified risks but make no mention of the real high-risk items.

 
• Many programs do not involve staff who really understand the program in risk identification.

 
• Many programs do not conduct systems engineering trade studies to reduce high-risk technical requirements.

 
• Rarely are supportability and maintainability risks identified.

 
• Often external dependency risks are not identified.

 
• Seldom are risks from using unproven new technology identified. 

Chapter 6 contains a series of detailed questions that can be applied to any program to determine the health of its risk management approach. These questions should be applied on a regular basis. However, there are some quick indicators that can be used to see if the risk management process requires more in-depth examination. Specific "quicklook" questions are:

• Is there a risk officer assigned? 
• Is there a risk management plan? 
• Has a list of risks been created? 
• When was the list created? 
• How long has it been since it was changed? 
• Have any of the risks materialized? 

• Is there a risk officer assigned?
• Is there a risk management plan?
• Has a list of risks been created?
• When was the list created?
  • How long has it been since it was changed?
• Have any of the risks materialized?

An inappropriate answer to any of these questions could indicate a more serious problem and merits further investigation.

top

---