Program risk management strategy

An event that has already occurred is an issue , not a risk. A risk has the potential to occur; it has not actually occurred. These three risk types can be defined as:. The unknowable risks are just that, impossible to predict. The model for the risk management process is shown in Exhibit 1. Although obviously technically correct, this model includes both qualitative and quantitative risk analysis and lacks any type of feedback loop, a vital part of any risk management process. A modified model of the risk management process is shown in Exhibit 2.

This model relies upon a qualitative risk assessment, an approach more likely to be used in the business world than a highly mathematical quantitative analysis. In addition, it adds the necessary feedback loop indicating that risk management is an iterative process.

The program manager and a small cadre of key project members can best perform this planning activity. In the planning process, the key program evaluation criteria need to be agreed to and established. They can be categorized into various impact areas: business performance, product capability, schedule, etc. Once the key parameters are established, the impact of each should be developed. For instance, if a key parameter is weight, then the sensitivity of weight to the product should be established.

Establishing the high, medium, and low impact values for each parameter provides a common viewpoint for all team members to use as they consider a risk. Similarly, the overall risk sensitivity of the project should be established. The risk planning results can be documented in a simple matrix similar to that shown in Exhibit 3 below. The agreed relative importance of various likelihood and consequence combinations is captured in this example by the Roman numerals shown in each circle.

In this case, risk events with a medium likelihood but a high consequence are considered to be more important than a high likelihood but medium consequence event.

How those trade-offs are made are unique to each project, company and industry. Risk identification is the next step in the process and it forms the basis for all the future activities. This is the step where the hard work of drawing out concerns, frustrations and risks must occur.

It is an activity worth spending considerable time to complete. Program managers may feel as if they are under attack or be simply overwhelmed with the magnitude of the risks being identified. The appropriate timing for an initial risk identification session can be somewhat tricky to determine but it should be held early, soon after the basic program requirements, milestone dates, etc.

Done properly, the risk identification session should identify areas that require additional effort, money, time, etc. Risk identification sessions should be held as a separate meetings with a cross-functional group of varying experience levels. By mixing up the functions and the experience level, the widest array of ideas will be identified.

This is a first step but all need to understand the resulting consequence. The consequence on the product may be a. The risk response plan will differ greatly depending upon the consequence. Running the risk identification meeting as a brainstorming session is an effective technique.

Allow one risk item per turn to keep all team members engaged, preventing one person from dominating the discussion. In all cases, it is vital to have an on-going risk identification process. This on-going process should include holding risk identification sessions at various points throughout the project, especially as a new project phase is begun. Providing a Risk ID form to all the team members is also helpful for gathering input between risk meetings.

The risk assessment step, i. As part of the risk ID meeting, allow the identifier of the risk event also characterize their risk by placing it on a 3' X 4' version of the Risk Priority Matrix ref: Exhibitr 4. A program manager must be careful, however, to not unwittingly eliminate a risk as being redundant when in fact there is a nuance that is key.

Risk response planning includes 2 major activities: identifying the risk response strategy ies to be applied and creating the plan to implement the strategy ies. The possible response strategies include:. Still, EPMOs face challenges to operationalize strategic plans. Studies consistently find that two-thirds to three-quarters of large organizations struggle to implement their strategies. An adaptive program management approach is necessary to translate strategic vision across the enterprise to deliver outcomes that often impact or change organizational processes.

Program management is an effective way to realize benefits quicker and at higher value while creating scale and bridging organizational silos. Program managers can create outcome-driven program plans and roadmaps connecting dependencies cross-functionally to manage them holistically while ensuring the organization prioritizes the execution of strategy. Leveraging program management practices is an effective way to execute cross-functionally and realize strategy.

Programs allow the organization to translate strategy into actionable goals to measure performance and mitigate the risk of failure. Metrics should be measurable, attainable, and aligned with the overall goals of the program. What you decide to measure will drive not just the program but will help define projects and their intended value. If they have, then the strategy has changed, and the organization needs to react accordingly. That is why it is so important for programs to be a translation of strategy and not some side-list aligned to it.

Some examples of program metrics include:. These are just a few of the key metrics to think about when setting up program management to ensure maximum benefits realization. Keep in mind other Key Performance Indicators KPIs are important for specific projects, and the program as a whole, and make sure they are defined and communicated from the start. Program management aids in strategic execution and results in more time spent on the enterprise, establishing metrics, measuring performance against strategic goals, communicating, managing priorities, and managing business change across departments.

Linda Roach champions solutions marketing at Planview, partnering with customers to articulate their business challenges and to quantify the value of implementing change. Linda works with industry analysts to understand trends and help guide Planview teams and customers to stay ahead of the curve.

She has led benchmark studies and analysis for organizations to compare against peers in project and portfolio management, resource management and capacity planning, collaborative work management, and product portfolio management.

Previously, Linda held positions at Pervasive Software, VTEL, and Kodak where she led go-to-market initiatives for new products and product line expansion. Program management enables strategic execution and results in more time on establishing metrics and measuring performance against strategic goals. Program management ensures people and teams are focused and collaborating across departments who are working together to achieve a shared strategic vision. Visualize dependencies across the business with program management.

A few things to consider when thinking about program management: Drive a strategic plan while balancing against day-to-day realities: Programs create change. They leverage a set of projects to deliver that change incrementally and measure the value they create back to the strategic goals.

This allows programs to manage the change they create while evolving as new information is learned. Operationalizing strategic execution moves across the organization and bridge silos: Dealing with multiple departments, multiple products, or moving targets is challenging.

The organization knows the priorities if there is a roadmap. A strategic roadmap with the work required across the organization highlights dependencies while having a roadmap to resolve conflicting priorities.

This leads to the benefits of having multiple perspectives in risk management, which will eventually lead to meaningful risk management for all parties. In other notes, information from the literature e. All the programs in our study have a formal and standard risk management process.

The informants indicated clearly that their risk management process is comprehensive, proactive and forward looking. Since these programs were based on contracts with the Department of Defense DoD , their risk management processes were aligned with DoD policy.

We found that the typical steps in the risk management process includes risk identification, risk assessment, risk handling, risk surveillance, and risk closure. Risk Identification: We found that typically, risks are identified at all levels IPT and program levels and throughout the entire program life cycle. This initial assessment led to areas where the team focused on improving the performance position to meet technical requirements, cost targets, and schedule goals, while balancing all three elements.

In the MH-6 case, the risk identification process also includes the review of the WBS against the internal risk taxonomy matrix. This matrix, in fact, serves as a checklist for risk categories, which include requirements, design, integration and test, management processes, program constraints, production, and logistics including obsolescence.

Risk Assessment: To identify risk priority, risks were assessed by using both qualitative and quantitative approaches. While all of the programs we studied reported using a qualitative risk assessment, the MH program used both qualitative and quantitative risk assessment methods. For the qualitative risk assessment, we found that risks were classified by likelihood and impact levels. The likelihood represents the probability of risk occurrence. For the impact level, the adverse trends in performance-measuring parameters from the impact or risks are measured and predicted.

In the programs we studied, those parameters were defined with respect to the technical, cost, and schedule dimensions. In terms of assessment scales, while some of the programs e. However, in any case, we found that the explicit operational definitions for both likelihood and impact were used to facilitate a consistent evaluation standard. After the assessment, risks were added to a matrix.

This risk matrix helps facilitate the risk prioritization and the group review and discussion of the risk and corresponding step-by-step mitigation schemes. In addition to the qualitative risk assessment, the MH program also employed the quantitative risk assessment. In particular, the risk likelihood was evaluated in terms of percent and the impact level was identified in terms of dollars cost or days schedule. Factored cost or schedule exposure is defined as the product of the likelihood and impact in dollars or days.

The MH program manager also pointed out that each risk analysis included the determination of a root cause. For example, if a root cause is traceable to timing and information deficiencies, scheduling and management reserve or parallel development actions are evident potential abatement approaches.

Risk Handling: After the program risks were evaluated and prioritized, the action plans were developed for responding to the moderate and high risks. Avoidance, mitigation, and the use of contingency acceptance were the common action plans. Low risks were maintained on a watch list, reviewed regularly quarterly, in the case of MH for changes, and closed when no longer applicable.

The program manager of THAAD reported that it was the responsibility of the IPTs to develop risk-handling options to mitigate the risks and monitor the effectiveness of the selected handling options. On a particular risk item, once the board agrees that the risk level changes from moderate or high to low, that risk item is placed on the watch list and monitored for changes.

The board also monitors whether any risk items need possible additional funding from the management reserve, whether any risks warrant elevation to the PRMB, and whether there are any newly identified risks. At the program level, the PRMB meets regularly monthly in the case of E-2C to review and discuss new potential risks and to manage existing risk mitigation efforts.

In terms of risk closure, closure criteria were developed to evaluate risk items. According to the criteria, if risks especially the ones on the watch list are assessed as no longer a factor, they are closed and removed from the watch list.

This process, in fact, was used mainly for managing risks at the IPT level. At the program level, risk management practice is more or less providing oversight.

As discussed earlier, the appropriate use of risk management boards helps facilitate coordination. The use of a risk database discussed in the next section also significantly helps. Our analysis shows that a risk management database was used in the programs we studied. We found that the database can be as simple as risk matrix spreadsheets or an online data repository system. In the database, risks are described, catalogued, updated, tracked, and so forth.

In general, besides the use of the database to ensure a the integrated risk management, b the risk verification by risk management boards, c the risk scoring, system d the establishment of metrics and closure criteria for mitigation tracking, additional purposes of the database were 1 to be the central location for obtaining risk assessment data for the program, 2 to provide for the team to respond quickly to emerging risks, 3 to facilitate shared monitoring of risks affecting multiple subsystems IPTs , and 4 to be the tool used to communicate risk areas and status to the chief engineers and program leadership council.

In the F program, its risk management database integrates key elements of the risk management process, metrics, team-partner roll-up, real-time updating, multiple site accessibility, template integration, and scalable databases. With a high complexity level and a long duration of the program, we agree that it is practical to use a risk database as part of program risk management.

The database provides an opportunity to coordinate risk management across the program among different IPTs and the program boards. In addition, with the online database, program risks can be documented and maintained irrespective of geographical location. This finding, in fact, supports the study of Patterson and Neailey The findings from this study suggest several implications for program risk management, especially for government-contracted programs.

Practitioners may use such information for benchmarking and further improving program risk management in their organization. Researchers may use our findings as a basis for future study. To be effective in program risk management, the findings show that risk and opportunity management should be a part of the organization's policy, procedure, and culture.

In particular, it should be a part of program performance management. Even though every member of the program is encouraged to be an active participant in risk management, in terms of governance, a program should implement a tiered risk management board—team subproject level and program level. The team level board has a responsibility for managing risks in their area. The members of the board may come from different parties, such as customer, contractor, subcontractors, suppliers, or others.

Because a program consists of multiple teams, having system engineers to help coordinating risk management may be practical. At the program level, the board should oversee program risk management. While the team-level boards are responsible for managing risks in their areas, the program board should emphasize also managing risks with respect to system integration.

The members of the program board should also come from different parties and the board should be co-chaired by the program managers from the customer and the contractor. The findings also suggest that effective risk management practice needs a formal and standard risk management process. The process should include risk identification, risk assessment qualification and quantification , risk handling response planning , risk surveillance monitoring and control , and risk closure.

This process should be used to manage both risks and opportunities. For risk identification, risks should be identified at all levels. The implementation of the team-level board encourages the identification of risks at the lowest possible level.

As already mentioned, the program-level board, in addition to providing oversight, should focus on the identification of risk associated with system integration, interdependencies, and interactions. After the identification, risks should be assessed, at least in a qualitative way, to identify their priority.

Then an appropriate response plan should be developed. If risks are assessed quantitatively to identify their impact in dollars or days, and the investment on the response plans is recorded, the return on risk investment can be calculated after the impact of the residual risks are assessed. For risk surveillance, as already mentioned, the tiered risk management board should be implemented.

While the program board provides oversight, risks with respect to each team are monitored by the team. However, some risks may warrant elevation to the program board. The risks that are identified by the program board may not be managed by the board per se. The board may assign those risks to the respective program teams. Since the programs we studied involve high levels of system complexity, it is practical to implement an online database system in order to facilitate integrated and real-time risk management.

We summarize what we have learned in this research into a conceptual model for program risk management, shown in Figure 1. The objective of this study was to investigate program risk management. Based on the reports submitted for the Aviation Week Program Excellence Award, we conducted content analysis to explore risk management of 12 major defense programs from five organizations.

The majority of these programs 11 programs were based on government contracts. We found that with support from organizational policy, procedure, and culture, risk and opportunity management have been practiced rigorously in these programs. The members of the program have positive attitudes toward risk and opportunity management. In addition, formal and standard risk management process and methodologies, including a risk database, have been used. Because little research has been done on program risk management, these findings contribute to a program risk management process, derived from real-life contexts.

Researchers may use these findings as a basis for future study. For practitioners, our findings may be considered a best practice for other programs to benchmark against further improvement.

With the sample only from the contracted programs from aerospace and defense industries, to apply this finding to the programs in different settings, practitioners may have to adapt it to their programs.

With its preliminary nature, this study has some limitations. We recognize that the content analysis was done based on the self-reported document. The information in the document may not represent what was done in reality. However, with our research design, analyzing the emerging patterns from multiple cases, our findings were cross-validated. Nonetheless, further research, such as case studies, should be conducted to further investigate the risk management practices of these programs.

Baccarini, D. The risk ranking of projects: A methodology. International Journal of Project Management, 19 3 , Baron, M. Designing risk-management strategies for critical engineering system.

Bauer, M. Qualitative researching with text image, and sound: A practical handbook. London: Sage Publications. Chapman, C. Estimation and evaluation of uncertainty: A minimalist first pass approach. International Journal of Project Management, 18 6 , Cooper, D. Project risk management guidelines. West Sussex, U. Datta, S. Developing a risk management matrix for effective project planning — An empirical study.

Project Management Journal, 32 2 , Dillon, R. Optimal use of budget reserves to maximize technical and management failure risks during complex project development. Elkington, P. Managing project risks: A case study from the utilities sector. International Journal of Project Management, 20 1 , Flyvbjerg, B.

From Nobel Prize to project management: Getting risk right.