Expand +



The Art of Managing Project Risk

by David Bromlow

August 11, 2009

One of the most important aspects of any large project is risk mitigation. With new technologies such as enterprise service-oriented architecture this task is becoming more complicated. Risks need to be evaluated, tracked, and actively managed. Find out the five essential elements to managing risk on your projects.

Risk mitigation is one of the most important aspects of managing large projects — and the one that commonly receives the least attention. Any situation or problem that may impact the project adversely at some future time qualifies as a risk, and you should evaluate, track, and actively manage such issues now to prevent their occurrence.

A risk mitigation process defines how to manage and mitigate risk within your projects. It’s a proactive management plan designed to eliminate or reduce risk exposure. With SAP NetWeaver projects, common risk factors, such as requirements definition and accuracy of estimates, are made more complicated by a lack of experience with new technologies, new architectural decisions to make, and the shifting of project-management practices to those more in-line with an object-oriented, Web-enabled, service-oriented architecture (SOA). A proper risk mitigation process has five essential parts.

1. Risk Identification

The starting point and the end goal for risk identification are the same: defining a list of possible risks. To achieve a more predictable result, take a more methodical and structured approach to this task than is typical. Identifying risk means involving the right people in brainstorming sessions and making use of their prior experience. These sessions should include an appropriate cross-section of participants (business and technology, management and staff) and category analysis — considering commonly known categories and their associated risk factors, such as the risk of the schedule (category) having overly aggressive deadlines or a lack of sufficient resources (risk).

  • Brainstorming: A brainstorming session can be as formal or as informal as you like. There is no one right way to come up with bright ideas. Your corporate culture, project size, team composition, and the personalities involved will largely determine how you conduct brainstorming sessions, how many people are involved and who they should be, how many sessions you have, how long they should be, and whether you should order lunch. If you can get a broad group of participants who are intelligent, experienced, and get along well with each other, you’ll have more success.

A good brainstorming team for a large project would consist of the project manager, representation from senior management (business sponsor, governance council), business analysts, business management, technology management, and front-line team members. This group should cover all the business and technology interests from several levels and perspectives, weighted toward the middle of the management/worker spectrum. It’s unwise to make the group too large or too small, overly weighted toward one end of the spectrum, or inclusive of known antagonists. An ideal brainstorming team should include between six and 12 people to keep the discussion moving.

A number of supporting tools are available to facilitate brainstorming sessions. The diagrams in “Diagrams That Help with Brainstorming” can help you capture ideas, organize them, and encourage their further development.

Diagrams That Help with Brainstorming

Brainstorming Diagram

  • Surrounds main concern with the primary risk categories

  • Branches out from the main risk categories and adds lists of contributing factors

  • Combines list structure with informal structure

  • Places primary concern in the middle of the page

Fishbone Diagram

  • Is a cause-and-effect diagram

  • Is useful for more than cause-and-effect relationships

  • Names the major risks as main branches

  • Identifies contributing factors for each risk branch until all risks are fully examined

Spider Diagram

  • Resembles the brainstorming diagram, but with less formality and structure

  • Is a good, quick, and organic way to capture ideas and encourage their free flow

  • Category analysis: Some of the categories that you should consider during brainstorming sessions are shown in “Potential Brainstorming Categories."

    Potential Brainstorming Categories
    Category Risk Example
    Objectives Unrealistic • Can this really be accomplished?
    Unfocused • Are the objectives concrete and clear?
    Unarticulated • Are the objectives concrete and clear?
    Requirements Poor definition • Are you taking enough time, being careful enough?
    Lack of reality • Are you differentiating between needs and wants?
    Budget Poor estimates • Is there due diligence? Contingency?
    Underfunding • How is the budget set, by mandate or estimate?
    Schedule Inaccurate estimates • How experienced is the team?
    Overaggressive deadlines • How desperate is the business?
    Lack of sufficient resources • Are staffing levels sufficient to the task?
    Underestimated complexity • Is there a contingency plan in place?
    Unstable organization • Are key stakeholders solidified?
    Lack of business continuity • Is there a plan for backups?
    No cultural fit • Is the company ready for this change?
    Conflicts among stakeholders • Do key stakeholders get along?
    Commercial pressures • Is funding solidified and assured?
    Technology Wrong fit • Is the technology appropriate for the requirements?
    Instability • Can new technologies provide results?
    No quality assurance • Are proper controls in place for coding, testing, and so on?
    Human resources Conflicting personalities • Can the team get along?
    Poor morale • Is the team ready to perform?
    Staff unavailability • Are the right people on-board?
    Change Scope creep • Are you committed to the project’s scope?
    Domino effect • Have you considered the consequences?
    Poor change management • Is the organization ready?
    Lack of communication with stakeholders • Is communication with stakeholders sufficient? Is it effective?
    No commitment • Do the key stakeholders support the project’s objectives?
    Insufficient planning • Is the planning sufficient and realistic?
    Lack of communication among team members • Is communication within the team appropriate and sufficient?
    No risk management • Are the risks being properly managed?

Self-protection can also contribute to unmitigated project risk. The most commonly overlooked risks are the ones everyone wants to pretend don’t exist, such as conflicting political interests, lack of business knowledge, low team morale, poor quality assurance, and suspect technical competency. No one wants to point the finger at him- or herself, so it’s natural to avoid mentioning risks that might threaten others or make them feel uncomfortable. You might upset someone who will have a strong influence on your future career prospects, or you might reveal issues that ultimately point back to yourself. Although sensitivity, confidentiality, and tact may be important in managing these kinds of project risks, the project oversight team should identify and manage them to make sure they don’t threaten the project’s success.

To finish the risk identification task, you should categorize each risk, provide a description of the risk and its potential causes, and supply a high-level rating of its relative priority on a scale of 1 to 10. This rating will be refined in the next step, risk analysis.

2. Risk Analysis

Once you have clearly defined and documented each risk, the brainstorming team should reassemble to determine the risk exposure level for each risk. You can do this by rating each risk factor on a 1 to 10 scale. The four factors detailed in the table “Risk Exposure Levels” below comprise your risk exposure:

  • Probability: How likely is the risk to occur?

  • Impact: How detrimental will the risk be if it occurs?

  • Ability to control: How much control do you have in influencing the risk’s occurrence or impact?

  • Effectiveness of control: How effective have you been in exercising your influence to control the risk’s occurrence and impact?
Risk Exposure Levels
Risk Factor
• Risk occurrence is imminent; remote chance of avoiding risk.
• Risk probability is moderate; avoidance is probable with consistent planning.
• Probability that risk will materialize is remote.
• Complete compromise of project objectives leads to project failure and complete loss of investment.
• Risk is moderately detrimental; recoverable with concerted effort.
• Risk has little measurable impact to project.
Ability to control
• Risk occurrence is completely within my ability to control.
• I have moderate ability to control risk occurrence with regular planning and mitigation activities.
• I am completely unable to control risk or influence avoidance (i.e., natural disaster, geopolitical instability).
Effectiveness of control
• I have been highly effective at controlling risk probability and impact.
• I have been moderately effective at controlling risk (definite room for improvement).
• I have been completely ineffective at controlling this risk.

For negative factors, such as probability and impact, the higher score indicates the higher probability or impact. For positive factors, such as control and effectiveness, higher scores indicate higher levels of control and effectiveness. You can use a formula to calculate the composite risk exposure score for each risk. You can use a number of formulas for this calculation to provide a relative comparison of each risk exposure. I prefer the formula in “Risk Exposure Calculation.”

In this formula, I = impact, P = probability, C = control, and E = effectiveness.

Then plot the risks within a magic quadrant along the two negative axes, impact and probability (see “Risk Magic Quadrant” below), to visualize their relative importance within risk mitigation planning.

  • Quadrant I — High impact, high probability; highest priority, requires most attention

  • Quadrant II — High impact, deserves careful monitoring

  • Quadrant III — High probability, low impact, is manageable

  • Quadrant IV — Monitor for further development

This is a sample graph. Points A-G are random.

Another tangible way to comprehend risk exposure is through cost estimates. They may take more effort to create and maintain, but cost estimates provide the most concrete picture of your project’s risk exposure. Using cost estimates, you can express risk exposure as the difference between your worst-case estimate and your best-case estimate at any time during the project. If your best-case estimate (when everything goes right and according to estimates) is $500,000, and your worst-case estimate is $1.5 million, then you could express your project risk as $1 million along with an estimated level of the probability you have of incurring that expense.

It is also useful to break down estimates for your most important risk according to the reason for the cost: risk avoidance, risk recovery, or impact minimization. Each type of estimate could steer you in a different direction to mitigate risks. In some cases, the actual cost of the impact could be less than the cost of avoidance or recovery. If the impact is manageable within the parameters of the project, don’t bother to try to mitigate the risk.

3. Mitigation Planning

Once you have prioritized your risks based on exposure, methodically define and maintain an up-to-date mitigation strategy for each risk. Some risks such as geopolitical instability, global economic conditions, and natural disaster are beyond your ability to control. But the majority of risks are well within your ability to control, even the ones you may think are not (technology or vendor selection, scope and requirements stability, managing customer expectations, managing resource performance, and controlling costs and schedule tolerances).

Risk mitigation plans need to be detailed. They should include clearly defined tasks, task assignments to individual owners, and specific completion dates. The overall project plan should contain these tasks. That way, you have visibility and accountability within the project team to mitigate these risks.

Risk mitigation plans should cover at least three areas of action:

  • Risk prevention: Keeping the risk from ever materializing

  • Impact minimization: Minimizing the impact if the risk does materialize

  • Risk contingency: Actions you will take to manage the risk if it occurs

Markus Gaulke (an advisor director and IT audit/ compliance expert for KPMG in Germany) has defined the risk reduction staircase, a useful step-down approach to risk mitigation planning, that contains five areas of concern: prevent, reduce, limit, shift, and accept (see “Risk Reduction Staircase”). The general idea is the same — there are multiple kinds of tasks that should be defined for each risk, and the execution of each task should have the cumulative effect of reducing the risk exposure for each risk.

Five areas of concern in mitigating risk

4. Mitigation Execution

Once risks have been identified and analyzed and mitigation activities have been planned, executing the plan is the easy part, but it must not be neglected. Every moderate-to-high risk that you identify should have a detailed action plan to mitigate it. Tasks should be assigned to particular individuals according to the categories listed above: risk prevention, impact minimization, and risk contingency. These tasks should appear in the project plan and be tracked there.

As project manager, you should assume ownership for each risk until others on the team or among the project sponsorship have demonstrated that they are accepting responsibility for it. You should review each risk regularly, and risk review should hold a prominent place within project-status update meetings, for both the team and the project sponsorship. A project manager’s regular weekly duties should include risk review as well as updating the project plan, reviewing and approving the hours reported as worked, and approving expense reports. It should be a regular, dedicated, weekly activity.

In the same way, you should communicate risks to senior management regularly. When you discuss the topic infrequently or in an irregular manner, it becomes more difficult to raise the subject, especially if new risks have developed since the last time they were discussed. If communication is free and regular, you can easily address new risks as a matter of due course rather than as a cause for embarrassment.

Within these regular communication cycles, it is important to set the expectation with key stakeholders that they also have a role in risk mitigation. As risks emerge that require senior management’s attention, you should escalate them early and often. Successful risk mitigation always requires a team approach. Key stakeholders should clearly understand their role in risk escalation activities, such as making the difficult decisions, dealing with the high-level issues, making the key scope and financial decisions, and moderating project politics. Set the expectation that risk mitigation is a key purpose of project steering-committee members.

5. Risk Exposure Monitoring

Although I have placed a lot of emphasis on identifying, analyzing, planning, and executing risk mitigation plans from the beginning of the project, it is important to realize that new risks can materialize at any time. For this reason, a comprehensive risk mitigation strategy must contain regular reassessment of risks. Along with monitoring the progress made on existing risk mitigation plans, you should completely reassess risks at each major milestone or project phase. Reassemble the brainstorming team for a single session to review previously identified risks and brainstorm for new risks going forward. You should analyze any new risks, put new mitigation plans in place, and assign and execute these new tasks.

Continue to monitor risks weekly and present updates at each regularly scheduled status meeting, both within the team and with project sponsorship. As the project progresses and you pass additional milestones, project risk should diminish. If this doesn’t happen, then you might have a larger systemic problem, such as inappropriate project methodology or some other foundational problem within the project team or organization. New SAP NetWeaver projects in a traditional SAP R/3 organization are especially susceptible to methodology errors, since they tend to apply traditional waterfall methodologies to a more dynamic and iterative development style.

Key to Project Success

Project risk management is a key to project success, more than ever within an SAP NetWeaver environment that provides more possibilities, more freedom, and more responsibility in the area of technical design and development. A structured, methodical approach to risk mitigation coupled with the right tools and team support can help your SAP NetWeaver project teams and your organization to achieve new heights in project success.

David Bromlow is founder and president of Quivira Corp. (, an SAP outsourcing services company based in Overland Park, Kansas. He has extensive experience in IT project management, offshore outsourcing, and technical leadership focused on high-risk, high-visibility projects based on SAP NetWeaver technologies.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!