Risk Management in Projects and Project Control – Unit III

Risk Concepts
Risk in a project depends on the uniqueness of the project and the experience of the project team.
When activities are routine or have been performed many times before, managers can anticipate the
range of potential outcomes and manipulate the system design and project plan to achieve the desired
outcomes. However, when the work is unique or the team is inexperienced, making it difficult to
anticipate the problems, the potential outcomes are less certain. Even routine projects have risks,
because outcomes may be influenced by the factors that are new and emerging, or beyond anyone’s
control.
The notion of risk involves two concepts:
1. The likelihood that some problematic event will occur.
2. The impact of the event if it does occur.
Hence, risk is a joint function of the two:
Risk = f (likelihood, impact)
A project may be considered risky whenever at least one – either the likelihood or the impact – is large.
For example, a project will be considered risky when the potential impact is human fatality or massive
financial loss even when the likelihood is small.
Although the risk cannot be eliminated altogether, it can be reduced and plans readied in case
things go wrong; this is the purpose of risk management. The process and elements of risk
management are shown in the following figure.
Risk Identification
You can only manage things you are aware of. Thus, risk management begins with identifying the risks and
predicting their consequences. Risks in projects is generally referred to as the risk of failure, which implies
that a project might fall short of schedule, budget, or technical performance goals by a significant margin.
The Sources or Causes of high risk must be studied and well understood before the project can be approved
and funds committed.
Different types of Risks and their Causes
Any factor that can influence the outcome of a project is a risk cause or risk hazard. Risk in projects can be
classified as internal risks and external risks.
Internal risks
Internal risks originate inside the project, and project managers and stake holders usually have some
measure of control over them. Three main categories of the internal risks are as follows:
Market risk is the risk of not fulfilling the market needs or the requirements of particular customers. Sources
of market risk include:
• Failure to adequately define market or customer needs and requirements.
• Failure to identify changing needs and requirements.
• Failure to identify newly introduced products by competitors.
Market risk stems from the developer misreading the market environment, it can be reduced by
working closely with the customer; thoroughly defining needs and requirements early in the
project; closely monitoring trends and developments among markets, and competitors; and
updating requirements as needed throughout the project.
Assumption risk is risk associated with the numerous implicit or explicit assumptions made in
feasibility studies and project plans during project conception and definition. The risk of meeting
cost, time, and performance requirements depends on the accuracy of many assumptions.
Technical risk is the risk of encountering technical problems with the end-item or project activities
(sometimes these risks are listed in special categories – schedule risks being those that would cause
delays, cost risks those that would lead to overruns, and so on). Technical risk is high in projects that
involve new and untried technical applications, but is low in projects that involve familiar activities
done in customary ways.
One approach to expressing technical risk is to rate the project end-item or primary
process as being high, medium, or low according to the following features.
• Maturity: how experienced or knowledgeable the project team is in the project technology. An
end-item or process that takes advantage of existing experience and knowledge is less risky than
one that is innovative, somewhat untried, or cutting edge.
• Complexity: how many steps, elements, or components are in the product or process, and how
tightly interrelated they are. An end item or process with numerous, interrelated steps or
components is riskier than one with few steps and simple interrelationships.
• Quality: how producible, reliable, and testable the end-item or process is. In general, an end-item
or process that has been produced and is reliable and/ or testable is less risky than one that has
yet to be produced or has unknown reliability or testability.
• Concurrency or Dependency: the extent to which multiple activities in the project overlap or are
dependent. Sequential activities with no overlap are less risky than activities with much overlap.
External Risks
These originate from outside the project, and project managers often have limited or no control
over them. External risk causes include:
• Market conditions
• Customer needs and behaviour
• Competitor’s actions
• Supplier relations and business failures
• Government regulations
• Physical environment, i.e. whether conditions
• Interest rates and exchange rates
• Labour availability (strikes and walkouts)
• Decisions by senior management or the customer regarding project priorities, staffing, or budgets
• Material or labour resources (shortages)
• Subcontractor failure
Any of these can affect the success of a project.

Identification Techniques
The Project risks and their sources are identified in many ways. The principle methods are explained
as follows.
Project Analogy
The project analogy method involves scrutinizing records, post-completion summary reports, and
project team member’s recollection from earlier analogous projects to identify risks in new,
upcoming projects. The better the documentation (the more complete, accurate, and well-
catalogued) of past projects and the better people’s memories, the more useful these are as means
for identifying risks.
Checklist
Documentation from prior projects is also used to create checklists – lists of risks and their causes in
projects. A checklist is originally created from the experiences from past projects, and is updated as
new experience is gained from recent projects. Risk checklists can pertain to the project as a whole,
or to specific phases, work packages, or tasks within the project.
The more experience a company or managers gain with projects, the more they learn about
the risks, and the more comprehensive they can make the checklists. As experience grows with
completed projects, the checklist are expanded and updated. When a checklist cannot guarantee
that all significant risk sources or causes in a project will be identified, it does help ensure that the
important known one’s won’t be overlooked.
A disadvantage of risk checklist is that people might only consider the risks listed and not
consider any not in the list.
Work Breakdown Structure (WBS)
Risks can be identified through analysis of the WBS. Every package is scrutinized for potential
technical hurdles or problems with management, customers, suppliers, equipment, or resource
availability. Processes or end-items within each work package are assessed for internal risks in
terms of, for example, complexity, maturity, quality, and concurrency. The work package is also
assessed for external risks – for example, relying on a subcontractor to manage the work package.
Process Flowchart
Project risks can also be identified from process flowcharts. A flow chart illustrates the steps,
procedures and flows between tasks and activities in a process. Examination of a flowchart can
pinpoint potential trouble spots and areas of risks.
Project Networks and Convergence Points
The risks can also be identified through scrutiny of the precedence relationships and concurrent or
sequential scheduling of activities in project networks. For example, risk sometimes increases at
merge points in the project network. At these points, work performed by different teams comes
together and must be integrated; sometimes only do then errors become evident, such as
subsystems produced by two teams not matching up or functioning correctly. The result is that the
project may get delayed.
Cause-and-Effect Diagram and Brainstorming
Risks can be identified from the collective experiences of project team members who participate in
a brainstorming session to share opinions about possible risk sources in the project, and record
them on a cause-and-effect diagram. This can be worked out in two ways: 1. Given an identified,
potential outcome (effect), to identify the potential causes (sources); 2. Given a risk source (cause),
to identify the outcomes that might ensue (effects).
Delphi Technique
The term “Delphi” refers to a group survey technique for combining the opinions of several people
to develop a single judgement. This technique comprises a series of structured questions and
feedback reports. Each respondent is given series of questions (e.g., what are the five most
significant risks in this project?). For which he writes his opinions and reasons. The responses of
everyone surveyed are summarized in one report that is given to everyone. Seeing others opinions,
respondents have the opportunity to modify their own opinions. Because the written responses
are anonymous, no one feels pressurized to conform to their opinions. If people change their
opinions, they must explain the reason why; if they don’t, they must also explain why. The process
continues until the group reaches a collective opinion. Studies have proven this technique to be an
effective way of reaching consensus.
Risk Symptoms and Triggers
As the sources and outcomes of each risk are identified, so are its symptoms, which are visible
indicators or warning signs that the risk is materializing; these serve as a trigger to initiate
counteractions or contingencies to mitigate or combat the risk. For example, for the risk “failure to
meet technical requirements”, a symptom might be “failure of component X during test”; should
that symptom be observed, it would trigger the action “move to design plan B”.
Risk Assessment
Risks are ubiquitous, but it is only the notable or significant ones that require attention. If a risk and
its consequences are significant, ways must be found to avoid or reduce the risk to an acceptable
level. What is considered “acceptable” depends on the risk tolerance of project stakeholders.
Similarly, what is considered significant depends on the risk likelihood, the risk impact, and the risk
consequence.
Risk Likelihood
Risk likelihood is the probability that a risk factor will actually materialize. It can be expressed as a
numerical value between 1.0 (certain to happen) and 0 (impossible), or as a qualitative rating such
as high, medium, or low. The following table shows an example of qualitative ratings and the
equivalent percent values for each. When, for example, someone says the likelihood of this or that
risk is low, the probability of its happening, according to the table, is 20 percent or less.
The association between qualitative ratings and particular numerical values is subjective, and
depends on the experience of the project team and the risk tolerance of stakeholders. For
example, the above table might be for a project with high economic stakes, and therefore a
numerical likelihood greater than 50 percent equates to “high risk”.
When the project has multiple, independent risk sources (as is common), they can be combined
into a single composite likelihood factor, or CLF, which can be computed as a weighted (W) average.
CLF = W1*Likelihood of risk source 1 + W2*Likelihood of risk source 2 + W3*Likelihood of risk
source 3 + -------
Where W1, W2, W3, and so on each have values 0 through 1.0 and together total 1.0.
For example, if there are five risk sources with their likelihood of happening as 0.1, 0.3, 0.5, 0.3, and
0.5 and all of them are rated equally at 0.2, then
CLF = (0.2)0.1 + (0.2)0.3 + (0.2)0.5 + (0.2)0.3+ (0.2)0.5 = 0.34
However, when the risk sources are not independent, then the individual likelihoods cannot be
summed up. In such a situation the sources would be subjectively combined into one source and a
single likelihood value based on judgement is assigned.
Risk Impact
What would happen if a risk source or hazard materialized? The result would be a risk impact. A
poorly marked highway intersection is a risk hazard; it poses the risk impact of a collision and injury
or death. Risk impacts in projects can be specified in terms of time, cost, performance, publicity,
and so on. For example, the impact of insufficient resources might be failure to meet schedule or
user requirements.
Similar to risk likelihood, risk impact can be expressed as a qualitative rating (such as high, medium,
or low) or as a numerical measure between 0 and 1.0 (where 0 is not serious and 1.0 is
catastrophic), based upon a manager’s or expert’s judgement about the impact.
Just as the likelihoods for multiple risks in a project can be combined, so can the impacts from
multiple risk sources. Accordingly, the composite impact factor (CIF) can be computed using
weighted average. However, if the risk impacts are not independent, they should be treated jointly.
Risk Consequence
Earlier, the notion of risk was defined as being a function of risk likelihood and risk impact; the
combined consideration of both is referred to as the risk consequence or risk exposure, which can
be expressed as follows
Risk consequence = Impact × Likelihood
Example: Suppose the likelihood associated with a risk is 0.40. Also, should this risk materialize, it
would set the project back 4 months and increase the cost by an estimated 3,00,000/-. The
expected risk consequences for time and cost are thus:
Risk consequence time (RT) = 4 months × 0.40 = 1.6 months = 6.4 weeks
Risk consequence cost (RC) = 3,00,000 × 0.40 = 1,20,000/-

Risk Response Planning

Risk response planning addresses the mater of how to deal with risk. The following are the ways of
dealing with a risk.
Transfer the Risk
Risk can be transferred between customers, contractors, and other parties using contractual
incentives, warranties, or penalties.
Insurance
The customer or contractor purchases insurance to protect against a wide range of risks, including
those associated with
• Property damage or personal injury suffered as a consequence of the project.
• Damage to materials while in transit or in storage.
• Breakdown or damage of the equipment.
• Theft of equipment or materials.
• Sickness or injury of workers, managers, and staff.
• Fluctuations in exchange rates.
Subcontract work
Risks arise from uncertainty about how to approach a problem or situation. One way to avoid such risk
is to hire contractors that specialize in handling those problems or situations. For example, to
minimize the financial risk associated with the capital cost of tooling and equipment for production of
a large, complex system, a manufacturer might subcontract the production of the system’s major
components to suppliers familiarize with those components. This relieves the manufacturer of the
financial risk associated with the tooling and equipment to produce these components. But, as
mentioned, transfer of one kind of risk often means inheriting another kind. For example,
subcontractor work for the components means that the manufacturer must rely on outsiders, which
increases the risks associated with quality control and scheduling. However, such risks often can
reduce through careful management of the subcontractors.
Risk Responsibility
The individual or group responsible for each particular risk in a project should be specified. Risks
may be transferred, but they can never be completely “offloaded”. A warranty or guarantee
specifies the time or place at which the risk is transferred from one party to another. For instance,
when an item is procured and shipped from abroad, the risk of damage usually remains with the
seller as long as the item is on the ship; as soon as it is hoisted over the rail of the ship the risk is
transferred to the buyer. Generally a party willing to accept responsibility for high risk in a project
will usually demand a high level of authority over the project.
Avoid risk
Risk can avoided by such measures as increasing supervision, eliminating risky activities, minimizing
system complexity, altering end-item quality requirements, changing contractors, etc. But attempts
to avoid risk can entail the addition of innumerable management controls and monitoring systems,
which tend to increase system complexity and, perversely, introduce new sources of risk. Risk
avoidance attempts can also diminish payoff opportunities. Many risk factors can be avoided, but
not all, especially in complex or leading edge projects. Projects for research and new product
development are inherently risky, but offer potential for huge benefits later on. Because the size of
the risk is often proportional to the potential payoff, rather than avoiding risk it is better to try to
reduce risk to an acceptable level.
Reduce Risk
Among the ways to reduce the technical risk (its likelihood, impact, or both) are the following.
• Employ the best technical team
• Use mature, computer-aided system engineering tools
• Provide the technical team with incentives for success
• Hire outside specialists for critical review and assessment of work
• Perform extensive tests and evaluations
• Minimize system complexity
• Use design margins.
The latter two points deserve further explanation. In general, system risk and uncertainty increase
with system complexity: the more elements in a system and the more they are interconnected, the
more likely it is that an element or interconnection will go wrong. Thus, minimizing complexity
through reorganizing and modifying elements in product design and project tasks reduces the
project risk. For example, by decoupling activities and subsystems – i.e., making them independent
of one another – a failure of one activity or subsystem will not spread to others.
Incorporating design margins into design goals is another way to reduce risk associated with
meeting technical requirements. A design margin is a quantified value that serves as a safety buffer
held in reserve and allocated by management. In general, a design margin is incorporated into a
requirement by setting the target design value to be stiffer or more rigorous than the design
requirement. By striving to meet a target vales that is stiffer than the requirement, the risk of not
meeting the requirement is reduced.
Accept Risk (Do Nothing)
Not all the risks are severe. If the cost of avoiding, reducing, or transferring the risk is estimated to
exceed the benefits, then “do nothing” might be the best alternative. This accept risk strategy
would be chosen for risks falling in the low consequence category.
Risk Tracking and Control (or) Risk Monitoring
Identified risks are documented, added to a list called a risk log or risk register, and rank ordered with
greatest risk consequence first. For risks with the most serious consequences, mitigation plans are
prepared and strategies adopted (transfer, reduce, avoid, or contingency); for those of little or no
consequence, nothing is done (accept).
The project should be continuously tracked for symptoms of previously identified risks as well as
newly emerging risks (not previously identified). Should a symptom reach the trigger point, a decision
is made as to the course of action, which might be to institute a prepared plan or to organize a
meeting to pick a solution. Sometimes the response is to do nothing.
All risks deemed critical or important are tracked throughout the project or the phases to which they
apply; to guarantee this, someone is assigned responsibility to track and monitor the symptoms of
every important risk.
Altogether, the risk log (risk register), mitigation strategies, monitoring methods, people responsible,
contingency plans, and schedule and budget reserves constitute the project risk management
plan. The plan is continuously updated to account the changes in risk status. The project manager
(and sometimes other managers and the customer) is alerted about emerging problems and people
readily notify the project manager whenever they detect a known risk materializing or new one
emerging.
Tools to manage a risk
• Risk register: A risk register is a chart that contains all the risks associated with a project, as well as
their priority levels, mitigation plans, and other important details. A risk register might also be called
a risk matrix. You can find project management software that can help you compile risk registers, or
else create your own in a spreadsheet.
• Risk management plan: A risk management plan is generally a living document that contains all
information related to risk in your project. This can contain an executive summary, your risk,
mitigation plans, risk owners, and any other information pertaining to risk. Project managers may
update the document as the project progresses and needs fluctuate.
Benefits of project risk management
• Evaluating Problem Areas: - A detailed project risk management plan will give you a clear picture of
your project and the potential problematic areas in it. That way, you will be able to direct your (&
your Stakeholders) attention towards the weak links of the project, perform periodic status checks,
peer reviews and audits to keep up the project performance.
• Fewer Surprises: - Who doesn't like surprises, correct? But in a Project, none of us would like a
surprise!. So, risk management plans give you an early warning of potential risks or issues. This
enables the team to gear up and take the necessary steps to mitigate problems before they escalate
to severe issues and cause any irreversible harm.
• Better Decision Making: - With information on risks in advance, the upper management is able to
make better and efficient decisions. They will be having real-time information on risk through a
dashboard which will be continuously providing them with the latest data.
• Enhanced Communication: - Effective risk management enhances the flow of communication.
With the risks detected beforehand, it opens up the discussion point between the team involved.
All the teams to bring their minds together and to talk about the problem areas and handle the
causes of it rather than blaming each other after the harm has been done.
• Accurate Budget Estimations: - With project risk management mapped into your schedule and
cost planning, you will be able to predict the potential problems. This will help you in setting
aside a buffer budget (also called as contingency) for each of the domain like cost, time, resource
etc. resulting in less wastage and better quality.
• Elevated Project Success Rate: - With an effective risk management plan incorporated in your
project management, it boosts up the mindset of the entire team as they know the risks are being
actively managed and there is very less probability of failure.
• Focused Approach: - Knowing the fact that the risks are being actively tracked and managed, the
teams can focus more on their assigned tasks. Not only this, risk management highlights the
problem areas of a project so that the teams can swiftly deal with them ensuring the project
success.
• Better Escalation Management: - A systematic risk management plan will give you a proper idea
of when a risk needs to be escalated to the senior level for advice and action. This will help in
alerting the right people at the right time to analyze and fix the risk.
Challenges of project risk management
• Identifying risk: The act of determining risks can be a challenge. There is no way for one person
to be aware of all the financial and time limit risks. Hence this task is incredibly time consuming
and require compliance from other individuals.
• A lack of buy-in: From co-workers to upper management and others may not understand the
importance of developing a risk management plan. Project managers have to get the team and
top management buy-in (acceptance of and willingness to actively support and participate) for
most components of a project. If others don’t see the value in doing this, then project managers
might not be allowed the time to do it, and co-workers might not adhere to guidance from it.
• Cannot precisely predict the future: Regardless of how much planning a project manager does,
there is no way to predict the issues that will occur correctly. Managers can only include
information concerning past events that deterred a project. If a company has never had anyone
develop a risk management plan, then managers have to piece together the past to the best of
their ability. Regarding the future, the best anyone can do is guess, and sometimes this is not
always good enough.
Aligning risk management with business strategy: Project managers have the sometimes daunting
task of making sure that risk management plans have to align with company goals and strategy. The
contingency (Contingency reserves are used to manage identified risks (known unknowns) and are
calculated/estimated and linked to specific risks) of a risk management plan may scale back on the
budget or alter the schedule which may not line up with the policies of upper management. This
means project managers will have to work alongside senior management to iron out synergies and
take care of any differences which may not always be the easiest of processes.
Principles of risk management
The following are general principles for managing risks.
 Create a risk management plan that specifies ways to identify major project risks. The plan
should specify the person(s) responsible for managing risks, as well as methods for allocating
time and funds from the risk reserve.
 Create a risk profile for each risk that includes risk likelihood, cost and schedule impact, and
contingencies to be invoked. It should also specify the earliest visible symptoms (trigger events)
that would indicate when the risk is materializing. In general high-risk areas should have lots of
eyes watching closely.
 Appoint a risk officer to a project; a person whose principal responsibility is the project’s risk
management. The risk officer should not be the same person as the project manager; he should not
be a can-do person, but instead, to some extent, a devil’s advocate identifying and tracking all the
reasons why something might not work – even when everyone else believes it will.
 Include in the budget and schedule a calculated risk reserve – a buffer of money, time, and other
resources to deal with risks should they materialize. The reserve is used at the project manager’s
discretion to cover risks not specified in the risk profile. The project manager keeps the amounts held
in the reserves strictly confidential (else the project will tend to consume whatever amount is
available).
 Establish communication channels (perhaps anonymous) with the project team to ensure that bad
news gets to the project manager quickly. Ensure that risks are continually monitored, current risk
status is assessed and communicated, and the risk management plan is updated.
 Specify procedures to ensure accurate and comprehensive documentation of proposals, detailed
project plans, change requests, progress reports, and the post completion summary report. In
general, the better the documentation of past projects, the more information is available for
planning future, similar projects and identifying possible risks.
 Document the profile and management plan for every identified risk. It provides places to
summarize everything known about the risk. Such a document should be retained in a binder or
library, to be updated as necessary and until the risk is believed to no longer exist and is “closed out”.