See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/273760220

PROJECT RISK MANAGEMENT

Conference Paper · November 2013

CITATIONS READS
0 8,297

1 author:

Ronald Kibuuka Ssempebwa

Karlsruhe Institute of Technology
6 PUBLICATIONS   1 CITATION   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Presidential Initiative On banana Industrial Development- Uganda View project

MAIZE VALUE CHAIN View project

All content following this page was uploaded by Ronald Kibuuka Ssempebwa on 19 March 2015.

The user has requested enhancement of the downloaded file.

 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
INTRODUCTION: Risk is defined as an event that has a probability of occurring, and
could have either a positive or negative impact to a project should that risk occur. A risk may
have one or more causes and, if it occurs, one or more impacts. For example, a cause may be
requiring an environmental permit to do work, or having limited personnel assigned to design the
project. The risk event is that the permitting agency may take longer than planned to issue a
permit, or the assigned personnel available and assigned may not be adequate for the activity. If
either of these uncertain events occurs, there may be an impact on the project cost, schedule or
performance.

Risk in itself is not bad; risk is essential to progress, and failure is often a key part of
learning. But we must learn to balance the possible negative consequences of risk against the
potential benefits of its associated opportunity. (Van Scoy, 1992)

A risk is a potential future harm that may arise from some present action; such as, a
schedule slip or a cost overrun. The loss is often considered in terms of direct financial loss, but
also can be a loss in terms of credibility, future business, and loss of property or life. (Wikipedia,
2004)

As part of introducing risk management, two other important items need to be addressed;
first are the mitigation steps that can be taken to lessen the probability of the event occurring,
second is the contingency plan, or a series of activities that should take place either prior to, or
when the event occurs. Mitigation actions frequently have a cost. Sometimes the cost of
mitigating the risk can exceed the cost of assuming the risk and incurring the consequences. It is
important to evaluate the probability and impact of each risk against the mitigation strategy cost
before deciding to implement a contingency plan. Contingency plans implemented prior to the
risk occurring are pre-emptive actions intended to reduce the impact or remove the risk in its
entirety. Contingency plans implemented after a risk occurs can usually only lessen the impact.

Risk management is a broad factor affecting quite a number of business sectors however
it’s also a factor which must be addressed by every human being on earth regarding their way of
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
living otherwise if ignored human life is left in harm’s way and susceptible to death, diseases and
poverty.

THESIS: Dealing with risks and opportunities professionally is becoming one of the key
success factors in business. Most companies have realized the requirements turbulent markets
present and have started to adapt to this turbulence. But risks and opportunities are greater in
turbulent markets, so they call for active strategic risk management.

As competition becomes fiercer (even "hyper-competitive"), and market cycles more

volatile, markets are becoming more and more turbulent. To the individual business, this
turbulence manifests itself through shorter innovation and product life cycles. At the same time,
the range of products is increasing, planning horizons are getting shorter and establishing
strategy becomes increasingly uncertain. To management, turbulent markets mean their
companies' opportunities and risks are changing increasingly frequently, and hence must be
quickly used or avoided. Dealing with risks and opportunities professionally is becoming one of
the key success factors in business.

BODY: Risk management is an ongoing process that continues through the life of a
project. It includes processes for risk management planning, identification, analysis, monitoring
and control. Many of these processes are updated throughout the project lifecycle as new risks
can be identified at any time. It’s the objective of risk management to decrease the probability
and impact of events adverse to the project. On the other hand, any event that could have a
positive impact should be exploited.

The identification of risk normally starts before the project is initiated, and the number of
risks increase as the project matures through the lifecycle. When a risk is identified, it’s first
assessed to ascertain the probability of occurring, the degree of impact to the schedule, scope,
cost, and quality, and then prioritized.

Strategic risk management is a holistic approach to responsible business. It aims to create

an optimum balance between security interests and value creation goals required to add value to
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
business long term. We adopt quantitative risk management methods from the financial sector
and qualitative methods from industry and create a strategic risk management system. This
approach helps managers recognize their businesses' critical success and risk factors and use
them.

Strategic risk management is therefore about identifying risks and opportunities of a

business and taking action to counteract them, implement them and monitor their performance.
There are two conditions that must be met before a risk management system can be introduced.
First, risks must be comparable, so life-threatening events can be aggregated together. This is the
only way of ensuring that a risk management system is not just a collection of individual
potential risks and packages of action, but a way of recognizing potential existential threats
throughout the business. Second, problem areas must be prioritized so that scarce business
resources can be used efficiently. A risk management system therefore consists of a risk
management process and a risk management organization.

Risk management is a series of steps whose objectives are to identify, address, and
eliminate risk items before they become either threats to successful operation or a major source
of expensive rework. (Boehm, 1989)

The industry is fraught with failed and delayed projects, most of which far exceed their
original budget. The Standish Group reported that only 28 percent of software projects are
completed on time and on budget. Over 23 percent of software projects are cancelled before they
ever get completed, and 49 percent of projects cost 145 percent of their original estimates.
(Standish, 1995)

In hindsight, many of these companies indicated that their problems could have been
avoided or strongly reduced if there had been an explicit early warning of the high-risk elements
of the project. Many projects fail either because simple problems were reported too late or
because the wrong problem was addressed. (Bruegge and Dutoit, 2000)

Problems happen. Teams can choose to be reactive or proactive about these problems.
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
Reactive teams fly into action to correct the problem rapidly in a crisis-driven, firefighting mode,
without proper planning and more serious problems often occur late in the schedule. At this
point, resolving any serious problems can require extensive modification, leading to big delays
Proactive teams begin thinking about risks even before technical work is initiated. Their
objective is to be able to avoid risk whenever possible, to solve problems before they manifest
themselves and to respond to problems that do happen in a controlled and effective manner.

The risk management process can be broken down into two interrelated phases, risk
assessment and risk control. These phases are further broken down. Risk assessment involves
risk identification, risk analysis, and risk prioritization. Risk control involves risk planning, risk
mitigation, and risk monitoring.(Boehm, 1989) It is essential that risk management be done
iteratively, throughout the project, as a part of the team’s project management routine.

In the risk identification step, the team systematically enumerates as many project risks as
possible to make them explicit before they become problems. There are several ways to look at
the kinds of project risks. It is helpful to understand the different types of risk so that a team can
explore the possibilities of each of them.

Generic risks are potential threats to every project. Some examples of generic risks are
changing requirements, losing key personnel, or bankruptcy of the company or of the customer.
It is advisable for a development organization to keep a checklist of these types of risks. Teams
can then assess the extent to which these risks are a factor for their project based upon the known
set of programmers, managers, and customers. (Laurie Williams 2004)

Product-specific risks can be distinguished from generic risks because they can only be
identified by those with a clear understanding of the technology, the people, and the environment
of the specific product. An example of a product-specific risk is the availability of a complex
network necessary for testing.
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
Generic and product-specific risks can be further divided into project, product, and
business risks. Project risks are those that affect the project schedule or the resources (personnel
or budgets) dedicated to the project. Product risks are those that affect the quality or performance
of the product being developed. Finally, business risks are those that threaten the viability of the
product, such as building an excellent product no one wants or building a product that no longer
fits into the overall business strategy of the company.

There are some specific factors to consider when examining project, product, and
business risks. Some examples of these factors are listed here, although this list is meant to
stimulate your thinking rather than to be an all-inclusive list. (Laurie Williams 2004 )
1. People risks are associated with the availability, skill level, and retention of the people on
the development team.
2. Size risks are associated with the magnitude of the product and the product team. Larger
products are generally more complex with more interactions. Larger teams are harder to
coordinate.
3. Process risks are related to whether the team uses a defined, appropriate product
development process and to whether the team members actually follow the process.
4. Technology risks are derived from the software or hardware technologies that are being
used as part of the system being developed. Using new or emerging or complex
technology increases the overall risk.
5. Tools risks, similar to technology risks, relate to the use, availability, and reliability of
support products used by the development team, such as design software, and other
Computer-Aided Software Engineering (CASE) tools.
6. Organizational and managerial risks are derived from the environment where the product
is being developed. Some examples are the financial stability of the company and threats
of company reorganization and the potential of the resultant loss of support by
management due to a change in focus or a change in people.
7. Customer risks are derived from changes to the customer requirements, customers’ lack
of understanding of the impact of these changes, the process of managing these
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
requirements changes, and the ability of the customer to communicate effectively with
the team and to accurately convey the attributes of the desired product.
8. Estimation risks are derived from inaccuracies in estimating the resources and the time
required to build the product properly.
9. Sales and support risks involve the chances that the team builds a product that the sales
force does not understand how to sell or that is difficult to correct, adapt, or enhance.
10. Spontaneous and sporadic risk identification is usually not sufficient. There are various
risk elicitation techniques the team can use to systematically and proactively surface risks

After risks have been identified and enumerated, the next step is risk analysis. Through risk
analysis, we transform the risks that were identified into decision-making information. In turn,
each risk is considered and a judgment made about the probability and the seriousness of the
risk. For each risk, the team must do the following (Laurie Williams 2004):
1. Assess the probability of a loss occurring. Some risks are very likely to occur. Others are
very unlikely.
2. Establish and utilize a scale that reflects the perceived likelihood of a risk. Depending
upon the degree of detail desired and/or possible, the scale can be numeric, based on a
percentage scale, such as “10 percent likely to lose a key team
3. The team should establish a set numerical probability for each qualitative value (e.g. very
improbable= 10 percent, improbable = 25 percent).
4. Assess the impact of the loss if the loss were to occur. Delineate the consequences of the
risk, and estimate the impact of the risk on the project and the product. Similar to the
probability discussion above, the team can choose to assign numerical monetary values to
the magnitude of loss, such as $10,000 for a two-week delay in schedule. Alternately,
categories may be used and assigned values, such as 1=negligible, 2=marginal, 3=critical,
or 4=catastrophic.

Determining the probability and the magnitude of the risk can be difficult and can seem
to be arbitrarily chosen. One means of determining the risk probability is for each team member
to estimate each of these values individually. Then, the input of individual team members is
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
collected in a round robin fashion and reported to the group. Sometimes the collection and
reporting is done anonymously. Team members debate the logic behind the submitted estimates.
The individuals then re-estimate and iterate on the estimate until assessment of risk probability
and impact begins to converge. This means of converging on the probability and estimate is
called the Delphi Technique (Gupta and Clarke, 1996).

After the risks have been organized into a risk table, the team prioritizes the risks by
ranking them. It is too costly and perhaps even unnecessary to take action on every identified
risk. Some of them have a very low impact or a very low probability of occurring – or both.
Through the prioritization process, the team determines which risks it will take action on.

The team sorts the list so that the high probability, high impact risks percolate to the top
of the table and the low-probability, low impact risks drop to the bottom. If the team used
categorical values for probability (e.g. very improbable, improbable, probable, or frequent)
and/or impact (e.g. negligible, marginal, critical, or catastrophic), group consensus techniques
may need to be used to produce the risk ranking. If numerical values were given for probability
(percentage) and impact (monetary), the risk exposure can be calculated. Risk exposure is
calculated as follows (Boehm, 1989):
1. Risk Exposure (RE) = P x C
2. Where P = probability of occurrence for a risk and C is the impact of the loss to the
product should the risk occur. For example, if the probability of a risk is 10 percent and
the impact of the risk is $10,000, the risk exposure = (0.1)($10,000) = $1,000. If RE is
calculated for each risk, the prioritization is based upon a numerical ranking of the risk
exposures.

After the risks are prioritized, the team, led by the project manager, defines a cut off line
so that only the risks above the line are given further attention. The activities of this “further
attention” are to plan, mitigate, monitor, and communicate – as is discussed in the following
sections. The lower ranked risks stay on the table for the time being with no action other than
monitoring.
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
Risk management plans should be developed for each of the “above the line” prioritized
risks so that proactive action can take place. The following are some examples of the kinds of
risk planning actions that can take place:
1. Information buying; the perceived risk can be reduced by obtaining more information
through investigation. For example, in a project in which the use of a new technology has
created risk, the team can invest some money to learn about the technology.

2. Contingency plans; A contingency plan is a plan that describes what to do if certain risks
materialize. By planning ahead with such a plan, you are prepared and have a strategy in
place do deal with the issue. Contingency planning is the act of preparing a plan, or a
series of activities, should an adverse risk occur. Having a contingency plan in place
forces the project team to think in advance as to a course of action if a risk event takes
place. Associated with a contingency plan, are the start and stop triggers. A start trigger is
an event that would activate the contingency plan, while a stop trigger is the criteria to
resume normal operations. Both should be identified in the Risk Register and can be
embedded.

3. Risk reduction; For example, if the team is concerned that the use of a new programming
language may cause a schedule delay, the budget might contain a line item entitled
“potential schedule” to cover a potential schedule slip. Because the budget already covers
the potential slip, the financial risk to the organization is reduced. Alternately, the team
can plan to employ inspections to reduce the risk of quality problems.

4. Risk acceptance; Sometimes the organization consciously chooses to live with the
consequences of the risk (Hall, 1998) and the results of the potential loss. In this case, no
action is planned.

5. Related to risk planning, through risk mitigation, the team develops strategies to reduce
the possibility or the loss impact of a risk. Risk mitigation produces a situation in which
the risk items are eliminated or otherwise resolved. (Hall, 1998)
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
6. Risk protection; the organization can buy insurance to cover any financial loss should the
risk become a reality. Alternately, a team can employ fault-tolerance strategies, such as
parallel processors, to provide reliability insurance.

7. Risk planning and risk mitigation actions often come with an associated cost. The team
must do a cost/benefit analysis to decide whether the benefits accrued by the risk
management steps outweigh the costs associated with implementing them. This
calculation can involve the calculation of risk leverage (Pfleeger, 1998).

For each identified risk, a response must be identified. It is the responsibility of the
project team to select a risk response for each risk. The project team will need the best possible
assessment of the risk and description of the response options in order to select the right response
for each risk. The probability of the risk event occurring and the impacts will be the basis for
determining the degree to which the actions to mitigate the risk should be taken. One way of
evaluating mitigation strategies is to multiply the risk cost times the probability of occurrence.
Mitigation strategies that cost less than risk probability calculation should be given serious
consideration.

After risks are identified, analyzed, and prioritized, and actions are established, it is
essential that the team regularly monitor the progress of the product and the resolution of the risk
items, taking corrective action when necessary. This monitoring can be done as part of the team
project management activities or via explicit risk management activities. Often teams regularly
monitor their “Top 10 risks.”

For every risk impact categories the impact assessment should include consideration of
the following areas of impact also:
a. Cost – This impact is usually estimated as a dollar amount that has a direct impact
to the project. However, cost is sometimes estimated and reported as simply
additional resources, equipment, etc. This is true whenever these additional
resources will not result in a direct financial impact to the project due to the fact
the resources are loaned or volunteer, the equipment is currently idle and there is
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
no cost of use, or there are other types of donations that won’t impact the project
budget. Regardless of whether there is a direct cost, the additional resources
should be documented in the risk statement as part of the mitigation cost.

b. Scope – Whenever there is the potential that the final product will not be
completed as originally envisioned there is a scope impact. Scope impact could be
measured as a reduction of the number of studies completed, or not providing a
deliverable such as an IND.

c. Schedule – It is very important to estimate the schedule impact of a risk event as

this often results is the basis for elevating the other impact categories. Schedule
delays frequently result in cost increases and may result in a reduction of scope or
quality. Schedule delays may or may not impact the critical path of the project
and an associated push out of the final end date.

d. Performance/Quality – Performance/Quality is frequently overlooked as an

impact category and too often a reduction in quality is the preferred choice for
mitigation of a risk. “Short cuts” and “low cost replacements” are ways of
reducing cost impacts. If not documented appropriately and approved by the
project sponsor, mitigation strategies that rely upon a reduction in quality can
result in significant disappointment by the stakeholders.

Risks need to be revisited at regular intervals for the team to reevaluate each risk to
determine when new circumstances caused its probability and/or impact to change. At each
interval, some risks may be added to the list and others taken away. Risks need to be
reprioritized to see which are moved “above the line” and need to have action plans and which
move “below the line” and no longer need action plans. A key to successful risk management is
that proactive actions are owned by individuals and are monitored. (Larman, 2004)

As time passes and more is learned about the project, the information gained over time
may alter the risk profile considerably. Additionally, time may make it possible to refine the risk
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
into a set of more detailed risks. These refined risks may be easier to mitigate, monitor, and
manage.

On-going and effective communication between management, the development team,

marketing, and customer representatives about project risks is essential for effective risk
management. This communication enables the sharing of all information and is the cornerstone
of effective risk management.

The three stakeholders involved in risk management include, the developer who must
systematically and continually enumerate all the possible risks related to technical capability and
making the schedule, the manager who must lead the team to follow the risk management
process to proactively manage the project risks, the manager must also allocate resources for
proactive risks management and the who customer must participate in the continual identification
of risks.

None of the above stakeholders is empowered to manage business risks, i.e. what we
called organizational and managerial risks, and sales and support risks in the "Risk
Identification" section above. This kind of risk must be managed by upper management and
marketing department of the firm.

The responsibility for managing risk is shared amongst all the above mentioned
stakeholders of the project. However, decision authority for selecting whether to proceed with
mitigation strategies and implement contingency actions, especially those that have an associated
cost or resource requirement rest with the Project Manager who is responsible for informing the
funding agency to determine the requirement for a contract modification.

Sometimes the need for risk management can seem far off for students. After all, you
don’t do anything close to buying insurance to reduce the risk for your class projects, however,
consider that success (your grade) in the class as being at risk. In the beginning computer science
classes, your assignments were probably small but these assignments crisp, “you worked alone”
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
so your chances of being successful as you advance in your academic career become minimal.
The course projects will likely become quite a bit longer, you will be working with at least one
other person, and the requirements will be more ambiguous and even changeable. All of a
sudden, things aren’t nearly as under control. What can you do to improve your odds of getting a
good grade? Employing risk management can help. (Laurie Williams 2004)

In Conclusion; in itself, the process of performing a risk assessment can give your
project a greater chance of success. Assessments lead to the expression of outcomes as ranges,
the development of risk mitigation plans, and the ability to set contingency. Risk Analysis
provides a comprehensive means of determining confidence levels for project success, together
with quick and easy techniques for determining contingency and risk.

Project contingency can make or break a project. Having too much contingency is
uncompetitive; having too little contingency increases the chance of failure. Risk assessment or
allowing for uncertainty within estimates helps set contingency levels, with a preferred level of
risk, and gives the confidence level of outcome targets.

Contingency is often set at the task level, and it is common to add some contingency to
every estimate. The amount of contingency added may even be a fixed amount, for example
10%. However, it is much better to set contingency at the project level. In other words, use the
ranges on the task estimates to understand what contingency should be set for the project as a
whole. Setting contingency at the project level reflects the reality that some tasks may be delayed
whereas others may be completed on time or be finished early. The amount of management
reserve can be set by the same principle; allowing drawdown against risks that were identified at
the start of the project.

To effectively handle risks, the project manager will need to begin with risk management
planning. A large, complex project will likely have more risks than a smaller project. In any
situation, however, risks must be identified and planned for. The performing organization will
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
often have risk management policies that dictate how the risk planning sessions are to be
performed, and what level of risks call for additional planning.

Some stakeholders and organizations will be more tolerant to accept risks than others. A
person’s willingness to accept risk is called the utility function. A perfect example of the utility
function is the stock market. Some people will only invest in solid, reliable stocks but with little
return on their investment. Other people will invest in startups, low-dollar stocks, and other high
risk companies but will receive a higher yield if their investments pay off. The same is true with
projects: some risks are worth taking while others are not. Risk planning and the utility function
help the project manager determine which risks are acceptable.

Risks must be actively monitored and new risks must be responded to as they are
discovered. Risk monitoring and control is the process of monitoring identified risks for signs
that they may be occurring, controlling identified risks with the agreed responses, and looking
for new risks that may creep into the project. Risk monitoring and control also is concerned with
the documentation of the success or failure of risk response plans, and keeping records of metrics
that signal risks are occurring, fading, or disappearing from the project.

REFERENCES

1. Hall, E. M. (1998). Managing Risk: Methods for Systems Development,

Addison Wesley

2. Boehm, B. and R. Turner (June 2003). "Using Risk to Balance Agile and Plan-Driven
Methods." 36(6): 57-66.

3. Standish (1995). "The Chaos Report."

4. Larman, C. (2004). Agile and Iterative Development: A Manager's Guide.

Boston, Addison Wesley.
 PROJECT RISK MANAGEMENT
BY Eng Ssempebwa Kibuuka Ronald
ATLANTA INTERNATIONAL UNIVERSITY
5. Gupta, U. G. and R. E. Clarke (1996). "Theory and Applications of the Delphi
Technique: A bibliography (1975-1994)." Technological Forecasting and Social Change
185-211.

6. Bruegge, B. and A. H. Dutoit (2000). Conquering Complex and Changing Systems.

Upper Saddle River, NJ, Prentice Hall.

7. Pfleeger, S. L. (1998). Theory and Practice. Upper Saddle River, NJ, Prentice Hall.

8. Standish (1995). "The Chaos Report."

9. Van Scoy, R. L., "Development Risk: Opportunity, Institute, Pittsburgh, PA CMU/SEI-

92-TR-030.

10. Wikipedia (2004). Wikipedia, the Free Encyclopedia. http://www.wikipedia.org.

View publication stats