Anda di halaman 1dari 11

Risk Management for IT Projects ANZ-4360 defines risk as “the chance of

something happening that will have an impact

Introduction on objectives.”
There are a variety of standards associated PMBOK defines project risk as “an uncertain
with risk management including PMI’s event or condition that, if it occurs, has a
Project Management Body of Knowledge positive or negative effect on at least one
(PMBOK), Australia-New Zealand ANZ- project objective, such as time, cost, scope or
4360, International Standards Organization quality.”
(ISO) ISO 31000 Risk Management -- By any definition, risk is something rather
Guidelines on Principles and Implementation nebulous that, if it happens, will be
of Risk Management, ISO/IEC 16085 undesirable. Because of the nebulous nature
Systems and software engineering – Life of risk many people find it difficult to
cycle processes – Risk Management, National effectively manage the risk. This white paper
Institute of Standards and Technology (NIST) presents a number of techniques that will help
800-30 Risk Management Guide for Project Managers and Risk Managers make
Information Technology Systems, Factor project risks less nebulous so that they can be
Analysis of Information Risk (FAIR), effectively managed.
Institute of Electrical and Electronics
Engineers (IEEE) 1540, and many others. Risk Management Challenges
PMBOK, ANZ-4360, and ISO/IEC 16085
focus primarily on project risk management When discussing risk management with
whereas NIST 800-30, ISO 31000, and FAIR Project Managers I encounter four recurring
have a much broader scope and focus challenges that I consider significant
primarily on organizational or Enterprise risk impediments to effective project risk
management. Fundamentally, all of these management; improperly defined risks, risks
standards have five basic components in not properly quantified, ineffective mitigating
common; risk management planning, risk strategies, and lack of documentation about
identification, risk analysis, risk treatment, the effectiveness of the mitigating strategy.
and risk monitoring. The most common risk management
The focus of this whitepaper is specifically challenge is that risks are not properly
project risk management and the primary identified. Project Managers and team
references are the PMBOK, ANZ-4360, and members will frequently identify conditions,
ISO/IEC 16085. This white paper will focus symptoms, events, and / or opinions that are
on common challenges associated with indications that a risk exists but, they do not
project risk management, present a practical decompose the risk to the point that the actual
approach to risk management based on risk is identified. In looking at risk logs, I
PMBOK, ANZ-4360, and ISO/IEC 16085. A will see literally dozens of risks that are
brief discussion about how an enterprise can symptoms or indications that a risk is present
derive maximum value from project risk but the actual risk never makes it to the log.
management is also included. If the risk is not properly identified it
becomes nearly impossible to mitigate.
IT Project Risk Defined Project teams spend countless hours
mitigating various symptoms while the actual
Webster’s defines risk as “exposure to the risk goes unscathed. Project risks should be
chance of injury or loss; a hazard or identified in terms of schedule, budget,
dangerous chance”. quality, or mission accomplishment.

©2009 Joseph W. Mayo. All rights reserved 1

Risk Management for IT Projects

The second risk management challenge is that ISO/IEC 16085 include the same nine
risks are not properly quantified. I see risks components although they may be ordered
logs that list the impact as “major”, and grouped differently.
“significant”, “substantial”, etc. In order to
effectively mitigate a risk its impact to the
project must be objectively quantified. For
example, three-week schedule delay, $50,000
budget overrun, 500 hours of rework, etc.
Figure 1 - Risk Management Process
The third risk management challenge is
preparing an effective treatment plan. I often Some may argue that the sequence is less
see risk logs containing dozens or hundreds of important that the actual process. However, I
risks with each risk containing a single have found that the following sequence is the
mitigating action. A risk with a single most effective as it maximizes the risk
mitigating action is one indication that the management effort by focusing on high
project risk has not been properly identified. impact risks and reduces the amount of effort
Further analysis often reveals that the same wasted on low impact risks.
mitigating action is assigned to a variety of
risks; another indication that the true risk has Establish the Context
not yet been properly identified. More often Organizations frequently broaden the scope of
than not, a risk will require multiple actions to project risk management to include areas
be effectively mitigated. Mitigating strategies outside of the project team’s direct control.
also provide significant value at the Requiring project teams to manage risks well
Enterprise level which will be discussed in outside of their project boundary not only
more detail later in this whitepaper. causes confusion and wasted effort but also
Finally, the fourth risk management challenge indicates the need for a Program or Project
is a lack of documentation regarding the Management Office (PMO). PMO’s are
effectiveness of the mitigating strategy. Not much more capable and effective than a
documenting the effectiveness of the project team in mitigating risks across an
mitigating strategy may not necessarily organization. The context of project risk
impact the current project but, it will certainly management should be confined to the
affect later projects. The effectiveness of project’s budget, schedule, quality, and
mitigating strategies should be documented mission accomplishment.
and push up into the PMO, Enterprise, etc.
Identify Risks
Risk Management Process One of the greatest challenges to effective
An effective project risk management process project risk management is the proper
consists of nine components; six discrete identification of risks. Project risks
process steps and three activities. The six frequently have a variety of symptoms,
process steps are; establish the context, conditions, events, etc. that indicate the
identify risks, quantify risk impact, prioritize presence of a risk. Project teams will often
risks, treat risks, and monitor risk strategy. times identify these risk indicators as the risk
There are three activities that transcend the while, the real risk goes undocumented and
entire risk management process; oversight to slips by under the radar. The real danger of
ensure compliance, develop risk models, and identifying risk indicators instead of the true
feedback loop. The PMBOK, ANZ-4360, and risk is that the true risk goes undocumented
and undocumented risks cannot be managed.

©2009 Joseph W. Mayo. All rights reserved 2

Risk Management for IT Projects

Improper identification of risks can lead to I contend that risks must be defined in terms
extremely large risk logs filled with a of schedule impact, budget impact, quality
combination of risks, risk indicators, issues, impact, or ability to accomplish the mission.
etc. Risk logs of this nature quickly become If schedule impact can be effectively
unmanageable because of their size. A single managed then it doesn’t matter what
risk may have dozens of symptoms or condition or event impacts the schedule (i.e.
conditions each of which requires significant hurricane, network outage, personnel
effort to document, develop treatment plans turnover, etc.). There are five basic questions
for, and report the status. While the project that can be asked to help identify project
team is spending countless hours attempting risks:
to manage risk indicators, the real risk is 1. Is there a schedule impact?
incurred which not only causes schedule 2. Is there a budget impact?
delays, budget overruns, poor quality, etc., but 3. Is there an impact to quality?
also leads the project team to lose confidence 4. Is there an impact to our ability to
in their ability to effectively manage risk. In accomplish the mission?
addition to risk indicators, risk logs frequently 5. Can impact be objectively quantified?
contain issues which further compound the If the answers to questions 1, 2, 3, or 4 and 5
problem and lead to even more confusion. A
are “yes” then there is a very good chance that
risk log containing dozens or hundreds of
the risk has been properly identified.
entries can quickly become daunting and very
intimidating to the project team that questions Quantify Risk Impact
their ability to effectively manage risks.
In order to effectively manage a risk, its
A hurricane is one example of an event that is impact to the project must be objectively
often identified as a project risk. A hurricane quantified. For example, three-week schedule
will significantly impact a project team delay, $50,000 budget overrun, 500 hours of
working in a hurricane prone area but, even rework, etc. “Significant delays”, “reduced
though the effects of the hurricane can be quality”, “Substantial cost overrun”, etc. are
minimized, the hurricane itself cannot be extremely problematic when defining risk
managed by the project team. The key point primarily because “substantial cost overrun”
here is to recognize the difference between to one person could mean hundreds of dollars
conditions or events that cannot be managed whereas “substantial cost overrun” to
(e.g. asteroid hitting the earth, hurricanes, someone else could mean tens of thousands of
etc.) by a project team and risks that can be dollars. Quantifiable impact is also crucial
managed. One question to ask is; how much when monitoring risks since it makes little
time and effort should the project team spend sense to spend $100K to manage a risk that
attempting to manage these types of has an impact of $50K.
conditions or events? Another event that I
frequently see logged as a risk in the Public Project teams often struggle with quantifying
Sector is “regulatory change”. Once again, risk impact. Quantifying risk impact is
“regulatory change” is an event that cannot be further compounded by the fact that many
managed by the project team; however, the “risks” are not truly project risks and cannot
schedule and budget risks associated with be managed by the project team; the hurricane
unexpected requirements changes (associated scenario previously mentioned is one
with regulatory changes) can be managed and example.
will be addressed in the next section. It is possible that a risk can affect multiple
aspects of the project; a schedule delay for

©2009 Joseph W. Mayo. All rights reserved 3

Risk Management for IT Projects

example could also impact the budget. In budget impact. If budget is the driver, then a
order to effectively manage the risk it is part of the treatment plan could be to redeploy
important to understand the driver(s) behind existing resources which would result in a
the project. If time to market is more schedule delay but would keep the budget on
important then the risk should be defined and track. If schedule is the driver then a part of
managed as a schedule risk whereas if budget the treatment plan could be to add additional
is more important then the risk should be resources to the project which would result in
defined and managed as a budget risk. The cost overrun but keep the original schedule.
project sponsor will most likely have to make The schedule impact can be explicitly defined
the decision as to whether time to market or simply by multiplying the number of
budget is most important. additional resources required by the duration
(e.g. 3 resources redeployed * 4 weeks = 12
It is possible to manage both a schedule and a
week schedule impact). The budget impact
budget risk (e.g. project team works unpaid
can be explicitly defined by multiplying the
overtime) but often at the risk of quality. The
cost of additional resources times the duration
schedule, budget, quality triangle is outside
(e.g. 3 additional resource (@ $5,000 / week
the scope of this whitepaper however, there
cost) * 4 weeks = $75,000 budget impact).
are countless articles and books available (see
links in the Further Reading section below). In this particular scenario, the best approach
could be to issue a change order and remove
Consider the following scenario based on the
some existing scope in order to accommodate
“regulatory change” event noted in the
the new regulatory mandated changes. There
previous section:
are other actions that could be implemented
• There is a pending regulatory change that
but these serve to illustrate the point.
will require unplanned modifications to
the project Prioritize Risks
• If the regulatory change goes into effect
then additional scope will need to be After risks have been properly identified and
added to the project. quantified, the next step is to prioritize the
risks. Some may argue that developing a risk
Once it has been determined that a risk exists treatment plan should be the next step in the
(by asking the five key questions), the next sequence but I contend that it is more
step is to determine the potential impact. In effective to prioritize risks first so that risk
this case, there will definitely be an impact to management effort can be focused on the high
the schedule since increased scope will impact risks. It makes little sense to spend
require either additional resources or time and effort to develop risk treatment plans
redeploying existing resources; in either case, for low impact risks that will result in
the schedule must be modified. In order to schedule impacts of hours or days while the
determine schedule impact the scope must be project is on the verge of incurring a risk that
analyzed to some degree and the effort to will result in schedule delays of weeks or
implement the required changes must be months. Prioritizing risks will yield the most
estimated. Let us assume that the scope will value to the project team by focusing the
require approximately 500 hours of effort to effort on the high impact risks. Risks should
implement. “500 hours” is a quantifiable be prioritized based on impact to the project
metric that can be used to prioritize and followed by probability of occurrence. There
manage the risk. Based on the project are countless risk prioritization schemes
driver(s), the 500 hour estimate can be ranging from very simple high/low schemes
expressed in terms of schedule impact or to extremely complex schemes such as Monte

©2009 Joseph W. Mayo. All rights reserved 4

Risk Management for IT Projects

Carlo simulation. I prefer a simple 3-tier Treat Risks

scheme of low,
The first step in the risk treatment process is
medium, and high to select one of the four industry accepted risk
which is often treatment strategies; Avoid, Transfer,
referred to as the Mitigate, and Accept.
9-box model
(depicted in Avoidance is a risk strategy where the project
Figure 2). The 9- plan is modified to completely eliminate the
box model calls risk. For example: A risk has been identified
Figure 2 - 9-Box Model
for prioritizing with a new software feature that is scheduled
risks with high impact / high probability to be to be part of the next software release. The
managed first, followed by risks with high risk is estimated to impact the schedule by
impact / medium probability and so on. In more than two months. To avoid the risk, the
keeping with the objective quantification of software feature associated with the risk can
risks, parameters must be established for high, be de-scope and removed from the next
medium, and low. The impact parameters release.
require a quantified value for each context; Transfer is a risk strategy where the risk is
Table 1 illustrates one example: transferred to another party. The most
Context Impact Parameter common example of risk transfer is buying
insurance. Subcontracting is another example
Schedule High > 6 Weeks
of risk transfer.
Medium 2 – 5 Weeks
Mitigate is a risk strategy where a risk
Low < 2 Weeks
treatment plan is prepared. A risk treatment
Budget High > $100,000 plan is based on a mitigation strategy or series
Medium $50,000 - $99,999 of actions that will reduce the impact of the
Low < $50,000
risk to some degree. Risk treatment is one
area where I prefer to utilize ISO/IEC 16085
Quality High > 1,000 Hrs Rework
or ANZ-4360. Both ISO/IEC 16085 and
Medium 500 – 999 Hrs Rework ANZ-4360 have very comprehensive sections
Low < 500 Hrs Rework related to risk treatment. ANZ-4360 contains
Mission High Failure chance >65%
excellent detailed information about creating
treatment plans along with a variety of
Medium Failure chance 35%-65%
scenarios to help illustrate the process. The
Low Failure chance < 35% ANZ-4360 approach to risk treatment plans is
Table 1 - Quantifiable Impact Parameters very comprehensive and includes:
• Proposed actions
The parameters for probability can be the • Resource requirements
same for all contexts (e.g. schedule, budget,
• Responsibilities
quality, mission accomplishment). I suggest
• Timing
starting with a baseline of >80% for high,
50% - 79% for medium and <50% for low. • Performance measures
Over time these parameters can be adjusted • Reporting and monitoring requirements
based on actual performance in a particular ANZ-4360 includes two components that are
environment. notably absent in both the PMBOK and
ISO/IEC 16085; “timing” and “performance
measures”. The “timing” and “performance

©2009 Joseph W. Mayo. All rights reserved 5

Risk Management for IT Projects

measures” can be combined to establish a actions and trigger points are in stark contrast
trigger point for initiating different actions of to soft trigger points and subjective criteria
the risk treatment plan. Having said that, I (e.g. “engage the alternate supplier when you
prefer the ISO/IEC 16085 treatment plans are sure that the supplier will be late”)
overall because it is very comprehensive and Acceptance is the final risk management
addresses a number of areas that are not strategy. There are two categories of risk
covered in either the PMBOK or ANZ-4360 acceptance; passive acceptance and active
(e.g. resource allocation, control measures, acceptance. Passive acceptance essentially
environment requirements, treatment change means that the project is simply going to
procedures). These missing components are accept the risk and deal with the risks as they
extremely important and contribute to the arise (aka issues). Active acceptance involves
development of risk models which are establishing a contingency reserve of time,
covered later in this white paper. ANZ-4360
money, and resources to deal with risks as
utilizes the concept of “triggers” which, when they arise. Acceptance is a reasonable risk
combined with the ISO/IEC 16085 treatment management strategy in cases where the cost
plan, provides an extremely comprehensive of mitigating a risk is more than the impact of
and highly effective risk treatment plan. the risk. Passive acceptance relegates the
To help illustrate the use of triggers, consider project or organization to incur nearly all
the following scenario: potential risks. Active acceptance is a
common strategy when dealing with many
• A key deliverable on the critical path
unknowns (e.g. space travel), leading edge
has been subcontracted to an
development, etc.
organization that has a reputation for
late delivery. Important Note: Passive acceptance is the
• Based on the Treatment Plan in Figure default risk management strategy for any
3, a trigger point has been established project or organization that does not have a
and two actions have been defined that formal and effective risk management
are tied to the trigger point (1 – Identify process.
alternate supplier(s) and 2 – Engage
alternate supplier(s)). Monitor Risk Treatment
There are two categories of risk monitoring;
tactical and strategic.
Tactical monitoring occurs day to day and is
typically conducted by the project team.
Tactical monitoring should be conducted on a
daily basis and must take performance
measures, trigger points, and actual
Figure 3 - Risk Treatment Plan performance into account. The purpose of the
The key point here is that specific decision(s) tactical day to day monitoring is to evaluate
or trigger points are explicitly defined along whether the risk treatment plan is effectively
with specific actions that must be undertaken mitigating the risk(s). The tactical monitoring
at that point. Explicitly defining actions and should evaluate actual progress against the
the “trigger” to initiate the action reduces the performance measures in the treatment plan
likelihood that actions will slip and it also and trigger points should be monitored on a
makes the treatment plan repeatable. Explicit daily basis. It would not be prudent to spend

©2009 Joseph W. Mayo. All rights reserved 6

Risk Management for IT Projects

$100K mitigating a risk that will result in management process can be provided by a
$50K loss so, it is very important to measure combination of Quality Assurance reviews
the cost and effort associated with risk and Management reviews. Oversight of the
treatments and not blindly execute the risk strategic risk management process requires
treatment plan. fairly rigorous process compliance and is
most effective if an organization supports
Strategic monitoring is conducted as part of
formal Quality Management procedures.
management reviews, during internal or
Without adequate oversight, the effectiveness
external audits, and at the end of projects.
of organizational risk management can
Strategic monitoring is forward looking and
focuses on long-term process improvement. quickly deteriorate due in large part to the
challenging nature of project risk
An important aspect of strategic monitoring is
post-project risk analysis. Risk analysis
evaluates the results of risk treatment plans Feedback Loop
and their associated performance measures
looking for patterns and anomalies which An active feedback loop is one area where an
become inputs to risk models. organization can derive a tremendous amount
of value from project risk management. An
Risk Models active feedback loop is characterized by
processes that “push” information throughout
One of the most important outcomes of the
the organization as risk models and lessons
risk analysis process is the development of
learned are develop or modified. Actively
risk models. A risk model is a risk strategy or
disseminating information allows project
risk treatment plan that has been proven to be
teams to leverage enhanced risk models,
effective for a recurring risk. A risk model
lessons learned, etc. on a near real-time basis.
will contain proven mitigating strategies,
Wiki or other collaboration software are
resources, proposed actions, triggers,
excellent tools for providing active feedback
performance measures, and reporting
to project teams, especially distributed teams.
information. Additionally, the risk model will
include risk strategies and/or treatments that Conclusion
were applied but were found to be ineffective.
Risk models can be developed based on a Unfortunately, there is no single, definitive
variety of factors (e.g. methodology, project source for risk management processes, tools,
size, team size, technology stack). The real techniques, etc. However, highly effective
value of the risk model is that effective and comprehensive risk management process
actions and strategies are validated and can be constructed using components of the
ineffective actions are documented so that PMBOK, ANZ-4360, and ISO/IEC 16085.
subsequent project teams can focus on proven The PMBOK contains a good overview of
treatment plans. project risk management and includes what
should be considered the basic foundation for
Oversight to ensure process compliance the strategic aspects of organizational risk
management (e.g. risk models, risk
The project risk management process is not
management oversight, quantitative risk
complex but, executing the process can be
analysis). ISO/IEC 16085 has a very
very difficult. In order for project risk
comprehensive risk management plan, an
management to be effective, the process must
excellent approach to risk treatment, and also
be enforced at both the tactical and strategic
includes more detailed governance topics (e.g.
level. Effective oversight of the tactical risk
risk management policies, risk management

©2009 Joseph W. Mayo. All rights reserved 7

Risk Management for IT Projects

roles and responsibilities, risk thresholds). from the University of Phoenix. Career
Even though ANZ-4360 has been superseded highlights include:
by ISO/IEC 16085 it does contains more Program Manager for #7 of InfoWorld’s Top
detailed processes along with a number of 100 IT Projects of 2006. Developed PMO
tools and techniques that can be used to governance, the collaboration workspace, and
augment ISO/IEC 16085. Additionally, Executive level dashboards to divest a large
ANZ-4360 utilizes the concept of triggers International conglomerate. The PMO was
which simplifies the decision making process responsible for cloning 112 Corporate
in times of crisis and yields repeatable risk Applications for four separate operating
treatment plans. companies, and renegotiating 1,300 telecom,
Finally, keep in mind that risk management is IT service and license contracts without
not a complex process. The key to effective impacting the day to day operations of any
risk management is to follow a defined, one of the operating companies.
disciplined approach and focus on objective
measures for identifying, quantifying, and Program Manager for the Air Force Supply
prioritizing risks. Modernization. Utilized the Rational Unified
Process (RUP) and the Evolutionary Process
Keys to effective project risk management
for Integrating COTS (EPIC) to deliver new
Implement a defined process capability that dramatically improved the
Properly identify project risks efficiency of the Air Force supply chain
Quantify risk impact using objective measures resulting in a ROI calculated at 6:1 in the first
12 months alone.
Prioritize risks based on probability and impact

Develop a mitigating strategy Mr. Mayo can be contacted via e-mail at
Monitor mitigating strategies

Develop reusable risk models Further Reading

Provide oversight to ensure compliance Project Triangle
Implement an active feedback loop
Table 2 - Risk Management at a Glance Respect the Iron Triangle
Bio htm
Mr. Mayo is a PMI certified Project Discussion of Risk Management
Management Professional (PMP) and PMI
certified Risk Management Professional %20planning/SP%20pages/Risk_paper.htm
(RMP). Mr. Mayo’s career has spanned more
than 27 years and includes 13 years of hands- Development of Risk Management Defense
on software development and 16 years of Extensions to the PMI Project Management
Project and Program Management. Mr. Mayo Body of Knowledge
has spent 17 of the past 27 years as a
consultant for a number of companies 003/ConrowSP3.pdf
including CSC and Keane. Mr. Mayo has
conducted more than 60 IT project
assessments with emphasis on PMBOK
compliant project and risk management
processes. Mr. Mayo holds a BS/IT degree

©2009 Joseph W. Mayo. All rights reserved 8

Risk Management for IT Projects

ANZ-4360 Risk Management Guidelines
PMBOK Guide, Fourth Edition
ISO/IEC 16085 Systems and software
engineering – Life cycle processes – Risk

©2009 Joseph W. Mayo. All rights reserved 9

Risk Management for IT Projects

Appendix A – Risk Treatment Plan

The following treatment plan example is based on ANZ-4360:
Resources Performance Reporting and
Risk Requirements Proposed Action Timing measures Monitoring

performance Prior to project
based contract start
with supplier(s)

Establish weekly Prior to project

milestones start

Conduct weekly Weekly Progress

Weekly - ongoing
progress reviews Report

Identify alternate 30 days prior to

Contract Project Schedule
Schedule delay supplier(s) the trigger point
Specialist (CS)
> 2 weeks due
to late delivery Establish a trigger
Project point for engaging Prior to project
by supplier Project Schedule
Manager (PM) alternate start
• Earned value is <
90% at the
trigger point
In accordance with
Engage alternate
OR Earned value Communication
• Earned value is <
75% at weekly
progress review

©2009 Joseph W. Mayo. All rights reserved 10

Risk Management for IT Projects

Appendix B – Risk Treatment Plan Outline

The following outline is based on ISO/IEC 16085

1. Overview
1.1. Date of Issue and Status
1.2. Issuing Authority
1.3. Updates
2. Scope
3. Reference Documents
4. Glossary
5. Planned Risk Treatment Activities and Tasks
6. Treatment Schedule
7. Treatment Resources and their Allocation
8. Responsibilities and Authority
9. Treatment Control Measures
10. Treatment Cost
11. Interfaces Among Parties Involved
12. Environment / Infrastructure
13. Risk Treatment Plan Change Procedures and History

©2009 Joseph W. Mayo. All rights reserved 11