KULIAH 05

RISK MANAGEMENT
DR. Ir. HERMAN S. MBA
 REFERENCES 2

• Larson, E.W., Gray, C.F., 2018. Project Management: The Managerial

Process, 7th Ed., Mc. Graw Hill.
• Pinto, J.K., 2019. Project Management: Achieving Competitive
Advantage, 5th Ed., Pearson.
• Murray, D., Sanford, N., 2013. Software Engineering Project
Management.
• Villafiorita, A., 2014. Introduction to Software Project Management.
Aurbach Publisher.
• Ahmed, A., 2012. Software Project Management: A Process Driven
Approach. Aurbach Publisher.
• Microsoft Project Manual
 PROJECT
• Project risk is an uncertain event or
condition that, if it occurs, has a
positive or a negative effect on at
least one project objective. A risk may
have one or more causes and, if it
occurs, one or more impacts.
• Risks can be categorized as external
and internal. If a risk to the project
arises due to an aspect being dealt
with by the project team, then it is an
internal risk. All other risks are
external risks.
 RISK MANAGEMENT

• Risk Management is the art and science of

identifying, analyzing, and responding to risk
factors throughout the life of the project and
in the best interests of its objectives.
• Risk management is the systematic process of
planning for, identifying, analyzing, responding
to, and monitoring project risks.
PROCESS OF RISK MANAGEMENT

• Risk Identification – the process of determining the specific risk

factors that can reasonably be expected to affect our project.
• Analysis of Probability and Consequences – the potential impact of these
risk factors, determined by how likely they are to occur and the
effect they would have on the project if they did occur.
• Risk Mitigation Strategies – steps taken to minimize the potential
impact of those risk factors deemed sufficiently threatening to the
project.
• Control and Documentation – creating a knowledge base for future
projects based on lessons learned.
RISK IDENTIFICATION

• Financial Risk
• Technical Risk
• Commercial Risk
• Execution Risk
• Contractual or Legal Risk
• Others: Absenteeism, Resignation, Staff pulled away by
management, Additional staff/skills not available, Training not as
effective as desired, Initial specifications poorly or incompletely
specified, Work or change orders multiply due to various problems,
etc.
RISK IDENTIFICATION METHOD

• Brainstorming meetings – Bringing the members of the projects team,

top management and even clients together for a brainstorming
meeting can generate a good list of potential risk factors.
• Expert Opinion – The collective “wisdom” of sets of experts is then
used as the basis for decision making.
• History – In many cases the best source of information on future risk
is history.
• Multiple (or team based) Assesment – A team based approach to risk
factor identification encourages identification of more comprehensive
set of potential project risks.
Major Risk Types of Software Project
Major Causes of Software Project Risks
 Causes of Software Project Risks

• Quality Constraints: quality is one of the major concerns for software

products, as the high cost of supporting these products is well
understood, and thus, avoidance of providing product support for bad
quality products is a top policy among software vendors. Software
vendors realize that it is much cheaper to make a good quality
software product with low support costs than to produce a software
product of poor quality and end up with high support costs. Meeting
quality requirements is a big risk for all projects.
• Resource Unavailability: is one of the major risk factors, as software
professionals are in great demand the world over. Finding and
procuring a good software professional is a complete project in itself.
Retaining him within the organization is yet another challenge.
 Causes of Software Project Risks

• Disinterest: Lack of interest is a concern that needs to be mitigated by

project managers as it severely affects productivity. A good motivation
program for individuals who lack interest in the project can be organized.
• Attrition: Due to the high demand for software professionals, most
professionals have many job offers in hand at any given time. When they
find a lucrative offer, they quit an organization to join another organization,
thus leaving a project midway. Attrition has become such a big issue that
managements at big corporations have specialized programs to tackle it.
• Scope creep: is one risk that affects most software projects, and it always
impacts the project severely. Requirements keep changing and new
requirements keep piling up even after the project has completed the
testing phase and is into the implementation phase. A good change
management mechanism can tackle this menace effectively.
 Causes of Software Project Risks

• Cost constraint: Once a project is approved for commencement, a budget is

allocated and procured for the project. But due to unavoidable reasons, the budget
can be constrained. In such situations, the project cannot proceed as sources of
funds have dried up and project expenses cannot be met.
• Bad negotiation: If the project manager has good negotiation skills, then he can
procure an additional/modified budget, support, and resources, whenever the need
arises. But sometimes due to bad negotiation skills or for lack of foresight on the
part of the customer, this kind of support is not provided and the project lands in
troubled waters.
• Unrealistic estimate: is yet another risk that is very common on most projects. It is
also a fact that effort estimates for software projects are difficult to make because
of the uncertainties involved. So, it is always possible that it is understated. It is
always better to keep a buffer when an estimate is made, to take care of
uncertainties.
 Causes of Software Project Risks

• Human errors: are caused by the distractions of the brain because our brain
keeps processing all signals sent by our sensory organs continuously, and thus,
the work we are doing gets less attention, which results in errors in the work.
Due to human error, the requirements or design, or the construction may get
injected with defects. To overcome this, we must have review processes for the
work done to remove any defects.
• Poor management: is yet another human risk factor. Not all project managers are
naturally talented. Many of them learn managing things from experience. If a
project manager lacks experience in managing a project, then it is a big liability
for the project and it will show up in project results. Even if a project manager
has experience, personal traits dictate whether he can handle the project well
or not. So the project manager for a project must be chosen carefully, taking
into account his experience and personal traits.
 Risk Category

• All of the risks mentioned in the previous section can actually be broadly
grouped into categories of budget risks, resource risks, quality risks,
schedule risks, and technology risks.
• Budget Risks: If for some reason the budget goes above the permissible limit,
then the project manager must do something to control it. It is common
practice for the project steering committee to decide to cut short some
product features to contain the project within the budget. But this is not a
good practice. Instead, remedial action must be taken as soon as the project
shows the risk of cost overrun, so as to prevent the problem from actually
happening. To reduce the impact of budget risks, the budget allowance
should include reserve funds. So when such risks occur, allowances can be
taken up from the reserves to avoid the project from failing.
 Risk Category
• Time (Schedule) Risks: if the project looks to be slipping away from the targeted
date of deployment, then it will be a great business opportunity loss for the
customer. For this reason, the project should never be allowed to cross the targeted
release dates. Nevertheless, due to unforeseen circumstances, the project dates
may get affected. Sometimes, unexpected rework to be done on software
construction will lead to the slippage of the task schedule. To reduce the impact of
schedule slippages, a schedule allowance should be taken for each time-related risk
• Resource Risks: It is a reality that software professionals are in great demand, and
most projects run the real risk of team members leaving the project for more
lucrative offers. Project team members leaving in the middle of the project is one of
the biggest risks any project may face. This risk can be mitigated to some extent by
implementing a knowledge management system that will store all the knowledge
acquired by team members during the project. It will also store all the work
performed by the project team. So, when a team member leaves the project, the
knowledge acquired and the work done by him is in the knowledge management
system.
 Risk Category

• Quality Risks: Industry strength software needs a rock solid reliability so that
during operations, the support costs can be kept at a minimum. Otherwise,
supporting a poor quality software product becomes a losing proposition. So, the
quality of the software product is always a concern and a big risk. The quality of
the product may be poor due to bad software design or bad software
construction. Even if it is good, there is still a chance of defects inadvertently
creeping in due to complexity, large integration interfaces, or due to the large
number of changes in the design when the requirements are altered.
• To deal with quality risks, the best policy is to have a check for quality integrated
in the project schedule itself (quality planning). This will ensure that the quality
at the work product level is on par with the desired level, which in turn will
ensure overall product quality. Peer reviews, code reviews, and other formal
quality review processes should be strictly followed for all work products
 Risk Category

• Technology Risks: with the rapid introduction of new products into the
market, older products quickly become obsolete. So, many projects face
the prospect of having an outdated technology on which the software
product is being built. In such cases, the software product becomes
unusable even before it is implemented. Similarly, if any hardware
component that may have been integrated with the software and the
hardware becomes obsolete, the software product becomes unusable. An
appropriate selection of programming language, hardware platform, and
user access methods will make sure that the software product does not
become obsolete during the expected lifespan usage of the product.
When selecting technology tools and techniques, contact the vendors to
make sure that they will be providing support in future as well for the
tools you are buying from them.
ANALYSIS OF PROBABILITY & CONSEQUENCES

• Risk = (Probability of Event)(Consequences of Event).

• Risk Impact Matrix:
Consequences
Low High
High
Likelihood

Low
 ANALYSIS OF PROBABILITY & CONSEQUENCES

Risk Factor Consequences Likelihood Impact

Potential
A. Loss of lead High Low Moderate
designer Consequences
Low Medium High
B. Technical High Medium Serious
failure

high
C. Budget cut Medium Low Minor
D. Competitor High High Serious

Medium
Likelihood
first to market

Low
 ANALYSIS OF PROBABILITY & CONSEQUENCES

• Risks with high probability and high impact will be put on top of the list,
while risks with low impact and low probability will be put at the bottom.
• Project risks are dynamic in nature. They can occur at any stage of the
project. So the project risk matrix where the project manager has listed
risks and their impact as well as their probability needs to be revised at
regular intervals and the risks that are likely to happen at that moment in
time need to be assessed and remedial action should be taken.
Matrix of Risks: Their Impact and Probability
 Probability of Failure (Pf)
SCORE MATURITY COMPLEXITY DEPENDENCY

Low (0.1) Existing design Simple design Not limited to existing system

Minor (0.3) Minor redesign Minor increase in Schedule or performance depend on existing
complexity model
Moderate (0.5) Major change Moderate increase Moderate risk to schedule or performance
DETERMINING LIKELY RISKS

Significant (0.7) Tech. available but Significant increase Schedule or performance depend on new
complex design system or process. Significant cost or risk
Major (0.9) State of art, some Extremely complex Schedule or performance depend on new
& CONSEQUENCES

research complete system or process. Very high risk.

Consequences of Failure (Cf)

SCORE COST SCHEDULE RELIABILITY PERFORMANCE

Low (0.1) Budget estimate not Negligible/ Minimal or no reliability Minimal or no performance
exceeded no impact consequences consequences
Minor (0.3) Cost estimate exceeds Minor slip in Small reduction in Small reduction in system
budget < 5% schedule reliability performance
Moderate Cost estimate exceeds Small slip in Some reduction in Some reduction in system
(0.5) budget < 15% schedule reliability performance
Significant Cost estimate exceeds Slips excess 1 Significant degradation in Significant degradation in
(0.7) budget < 30% month reliability system performance
Major (0.9) Cost estimate exceeds Large Reliability goals cannot be Performance goals cannot
budget < 50% schedule slip achieved under current plan be achieved
CALCULATING A PROJECT RISK FACTOR

• Use the project team consensus to determine the scores for each Probability of
Failure Category: Maturity (Pm), Complexity (Pc), Dependency (Pd).
• Calculate Pf by adding the three categories and dividing by 3: Pf=(Pm+Pc+Pd)/3.
• Determine the scores for each Consequences of Failure Category: Cost (Cc),
Schedule (Cs), Reliability (Cr), Performance (Cp).
• Calculate Cf by adding the three categories and dividing by 4: Cf=(Cc+Cs+Cr+Cp)/4.
• Calculate Overall Risk Factor for the project by using the formula: RF=Pf+Cf-(Pf)(Cf)
• Rule of Thumb: Low risk Rf < 0.3
Medium risk Rf = 0.3 to 0.7
High risk Rf > 0.7
QUANTITATIVE RISK ASESSMENT

• Assume your project team has decided upon the following risk
values:
• Pm = .1, Pc = .5, Pd = .9
• Cc = .7, Cs = .5, Cr = .3, Cp = .1
• Determine the overall Project Risk using qualitative method
RISK MITIGATION STRATEGIES

• Accept Risk
• Minimize Risk
• Share Risk
• Transfer Risk
• Use of Contingency Reserves
CONTROL AND DOCUMENTATION

• Control and documentation methods help manager classify and

codify the various risks the firm faces, its responses to these risks,
and the outcome of its response strategies.
• Control document has to coherently identify the key information:
what, who, when, why, how.