Risk: Managing Project Uncertainties
Systems Analysis and Design: Paper 3
Carl Dolezal
University of Houston Clear Lake
carl.dolezal@utmb.edu
Abstract:
How a project team addresses project risk is a critical factor to the success or failure of a project. By
adequately identifying risk and effective risk management strategies, organizations can improve
their project success rates. An effective risk management strategy should be a critical component of
any project plan.
Introduction:
Deborah Weiss, Meta Group program director of enterprise planning and architecture strategies,
believes that up to 72 percent of all IT projects are late, over budget, lack functionality or are never
delivered as planned [1]. During a time when technology has become a principle tool for allowing
businesses to take advantage of opportunities, project success rates can be a principle factor in an
organization’s success or failure. Risk management is a methodology used to address project risk
factors and help improve project success rates.
What is Risk and Risk Management?
Project managers continually have to balance multiple resources, obstacles, and challenges over the
life of a project. Risk is an important project issue that should be addressed. Risk has three
components: the event that could occur, the probability that the event will occur, and the impact
that the event would have on the project should that event occur [2 ]. Risk management involves
identifying project risks and developing appropriate response strategies to address them. Risk
management is an ongoing process that continues throughout the SDLC.
Types of Risk:
There are two basic types of risk: business risk, and pure risk [2]. Business risks have a positive
characteristic of a potential gain for an organization. They also have a potential for loss. Business
risks can typically be managed. In contrast, pure risks (sometimes referred to as ‘insurable risks’)
cannot be managed. Pure risks are risks that should not be attempted by an organization or project
team. An example of a pure risk is a natural disaster. Another more common example of a projectrelated pure risk occurs when an organization chooses to approve a project based on a majority of
the requirements being within scope of the organization’s expertise and experience, while one or
more requirements are uncontrollable or outside the scope of the organization’s expertise.
Project managers that have a strong ability to identify risk events and their potential impacts on a
project have the ability to help influence a more favorable project outcome. A risk management
model should be developed to help control the types of risk an organization is willing to accept.
Risk Tolerance:
There are three common classifications for risk: risk averter, risk neutral, and risk seeker [6]. Risk
averters prefer projects where the outcomes are more certain. Risk seekers thrive in environments
of high-uncertainty and high stakes. Those who are risk neutral accommodate risk when there is an
1
equivalent potential payoff for the risk they assume. The risk tolerance of the project manager
should match the risk tolerance of the project and organizational culture.
Risk Management Models:
A risk management model is a group of formalized guidelines and procedures for addressing risk.
The model should start with the project selection phase. During this phase, the priority of the
project should be identified and weighted against other organization priorities to determine the
amount of resources needed and what levels of competition and demand are for those resources. If
a higher-priority project requires all of an organization’s resources, a lower priority project
requiring the same resources will not be successful.
The desired schedule is another risk factor to consider when selecting a project. Timelines that
appear reasonable at first may actually be unreasonable when compared against other projects,
available resources, a work schedules. Care must be taken when developing and reviewing a
project’s schedule to ensure that all potential influences on the schedule are included.
Perhaps the most important tool for identifying risk is a project’s work breakdown structure
(WBS). The WBS includes important information about the project’s tasks. Each of those tasks is
instrumental in identifying the specific type of resources needed by the project. It will become
quickly apparent whether or not the organization has the skills and resources available to perform
the WBS tasks. If resources are not available, the organization will have to consider alternatives
such as outsourcing, staffing-up at acquire skills, or not approving the project.
The WBS will also help to identify when multiple tasks
must be completed before another specific process can
start. In Figure 1, tasks K, G, and A must all be completed
before task H can begin. A delay in any one of these single
tasks will prolong the project (especially if the tasks are
on the project’s critical path). Projects requiring multiple
path convergences like this will have higher risks
associated with them.
WBS Task K
WBS Task G
WBS Task A
WBS Task H
Figure 1
A risk management model should be used to develop a risk management plan for the project.
Risk Management Plans:
The risk management plan is the beginning of the risk management process. A risk management
plan is used to communicate the processes used to manage the risks of the project for which it was
developed. The risk management plan includes two parts: risk management planning and risk
response planning [3]. The risk management plan defines and communicates how project risks are
identified, how they are managed by the project team, and how they are tracked. By successfully
planning for risk, an organization can improve its performance, profits, efficiency, and better meet
goals [4]. The risk management plan includes the methodology used to manage risk, monitors and
controls, roles and responsibilities, funding, how to measure risk, level of responsibility, a
communication plan, and risk tracking and documentation processes.
Risk Management Methodology:
This section of the risk management plan describes the tools and techniques used to
identify risks and how the project team will respond to project risk.
2
Monitors and Controls:
This section includes how risk will be monitored throughout the duration of the project’s
life. Project team members will have responsibilities for monitoring risk and reporting
(communicating) any changes in the status of risk.
Roles and Responsibilities:
This section of the risk management plan clearly lists and defines each of the project team
member’s roles and responsibilities for the project. Each of the team members should know
when and how to report problem events during a project and understand the reporting
process that needs to be followed. This will allow project leadership to understand and
address risk issues as they arise.
Risk Analysis and Measurement Methodology:
This section of the risk management plan describes how risk is analyzed and measured. It
should include a methodology for scoring and evaluating risk that is clearly understood by
the project team and stakeholders. There are many mathematical formulas and methods for
measuring risk. The ones selected by the organization or project team should be clearly
defined in this section of the plan.
Levels of Risk Response Responsibility:
All risks are not created equal. Each risk has a varying level of impact on the project. Each
member of the project team should have a certain amount of authority to address risk, but
should pass events on to the next higher authority if the specific risk reaches a
predetermined level (threshold).
Funding:
Funding is an important part of the risk management plan. A lack of funding or project
overruns can easily cause a project to fail. Plans should be in place to provide contingency
funding for a project and define when and how those funds will be used.
Risk Communication Plan (Reporting):
This section of the risk management plan defines how and who will receive and review
reports of project risk as they occur. The entire project team and stakeholders should have
appropriate tracking and documentation related to risks as they occur and the risk
communication plan defines how this process takes place.
Risk Tracking and Documentation:
The risk tracking and documentation section of the risk management plan defines how risk
is tracked, archived, and reviewed. Risk tracking and documentation should also be useful
for identifying best risk management practices for related projects.
Identifying and Measuring Risk:
Identifying risk is a challenging but important process. The failure to identify risk is a main
contributing factor to the failure rate of projects. The project team should be gathered in a meeting
to help identify risk as part of a group process. This helps take all of the team-member’s
experiences into account when identifying project risk factors. Combining techniques like
brainstorming and cause-and-effect diagrams (also known as fishbone diagrams) can help to
identify and organize project risk. Researching past project documentation can also help identify
risks as well as how they were managed.
3
Qualifying Risk
A risk must be qualified to determine how to manage it. A probability should be assigned to risks
based on the likelihood of occurrence. Once the risks have been identified and assigned a
probability, they should be ranked and prioritized with other project risks. By prioritizing risks, the
project manager can focus their limited resources on the risks that will most likely occur. The
expected value analysis technique is used to identify the most likely result of an outcome based on
risks and the probability they will occur.
Developing and Implementing Risk Response Strategies:
Project managers should be proactive in their approach toward responding to project risk. The
entire project team should understand how risk will be addressed when it is encountered in a
project. The basic steps a risk response strategy should include are risk identification, risk analysis,
a response plan, and a monitoring process [3]. Triggers should also be included so that when risk
events do occur, the appropriate risk response strategy is implemented.
Once the project team has identified and analyzed risks, it is time to develop the risk response.
Ideally, a risk response should be developed for each known risk. Once a risk is realized, the
response should be implemented. Response options include avoiding risk, transferring risk,
mitigating risk, and accepting risk [3].




Avoiding risk involves plans to move the project around a risk factor. For example, if
a project involves the install and configuration of a server and the organization lacks
these resources, those services could be purchased from a server hosting company
to avoid any potential risk related to server install and configuration. Hewlett
Packard encourages the re-use of previously developed software because it helps to
avoid risk when compared to developing new software [5].
Risk transfer involves the movement of risk from one entity to another. A common
way of doing this is through purchasing insurance. The insurance company is at risk
should an adverse event occur.
Mitigation of risk involves reducing risk to a more acceptable and manageable level.
Analysis and adjustment of the scope of a project to reduce functionality to a core
level of requirements is a way to reduce the amount of potential risk that the project
might have if all the ‘bells and whistles’ have to be implemented.
The acceptance of risk means that the project must accept that a particular event
may occur and should develop an alternative plan to implement should that risk
occur.
Implementing Risk Response Strategies:
Once a risk has occurred, the risk response strategy should be implemented. Triggers are activated
so that the team knows what has happened and what steps to take (in accordance with the plan).
Monitoring and communication is critical so that project leadership and project team members are
aware of triggers, when events occur, and what steps to take.
Tracking Risk Response:
Once implemented, a risk response should be tracked to ensure that the strategy is working as
planned. If the response plan is not working as planned, an alternative approach must be planned
and implemented. The project manager must develop a methodology to assess the effectiveness of
the risk response strategies so that the strategy can be continually assessed.
4
Documenting and Archiving Risk:
Risks strategies should be appropriately documented an archived so that best practices can be
identified. Lessons learned meetings should take place following project completion so that future
projects can benefit from the most effective strategies developed. Strategies can also be developed
to help avoid unanticipated risks that occurred during previous projects. Unfortunately,
documentation and post-project review meetings are important steps that are often skipped. A
well-disciplined organization will ensure that these meetings are part of the project closing process
so that the organization continually learns and improves with each project.
Conclusion:
Risk is an element that must be addressed for any project. Failure to plan for risk by developing a
risk management and response strategy places the project at a higher risk for failure. The project
manager and project team have responsibility for planning for risk to help ensure that the project at
hand will succeed. Each project with a unique work breakdown structure will require a unique risk
management plan and risk response strategy. It is as important to include a documentation and
archiving process as part of the project close out process so that the organization learns and
develops best risk management processes. By appropriately recognizing and addressing risk
factors, projects will have an improved chance of success.
5
REFERENCES
1. McBride, Siobhan. IT World, “Poor project management leads to high failure rate”,
http://www.itworld.com/, October 15, 2004.
2. Taylor, James. “Managing Information Technology Projects: Applying Project Management
Strategies to Software, Hardware, and Integration Initiatives,” AMACOM, 2004.
3. Tomczyk, Catherine A. “Defining Your Risk Management Plan, Project Manager's Spotlight
on Planning,” Sybex, 2005.
4. Heldman, Kim. “What Is Risk Management? Project Manager's Spotlight on Risk
Management,” Sybex, 2005.
5. Smith, Preston G. and Guy M. Merritt. “Risk Management Approaches and Strategies,
Proactive Risk Management,” Productivity Press, 2002.
6. Kerzner, Harold. “Risk Management, Project Management: A systems Approach to Planning,
Scheduling, and Controlling,” John Wiley and Sons, 2003.
6