You are on page 1of 34

workbook solutions for IT management

The Risk
Management Planner

Identifying, Assessing and Controlling


Risks in Technology Projects

from RIGHT TRACK ASSOCIATES


The Risk Management Planner
written by
E.G. Edman
Right Track Associates, Inc.

The Risk Management Planner is a tool for project planning and management. If you have any
questions or comments about the information contained herein, please submit a feedback form at
our web site, www.ittoolkit.com.

Copyright © 2002 Right Track Associates, Inc. All rights reserved. This publication is protected
by the copyright laws of the United States of America. No copying in any form is permitted. It
may not be reproduced, distributed, stored in a retrieval system, or transmitted in any form or by
any means, in part or in whole, without the express written permission of Right Track Associates,
Inc.

Right Track Associates, Inc. disclaims all warranties, express or implied, including but not limited to any warranties of the
accuracy or completeness of the content of this guide, of its fitness for a particular purpose, of merchantability, or against
infringement of third party rights. Right Track Associates, Inc. is not responsible or liable with respect to the use or
reliance on this document or any information contained in this document under any contract, negligence, strict liability, or
other legal or equitable theory (i) for any amounts in excess of the amount received by Right Track Associates, Inc. upon
the sale of this guide, or (ii) for any indirect, incidental, or consequential damages, including but not limited to loss of
profits or income.
The Risk Management Planner IT Management Workbooks from Ttoolkit.com

INTRODUCTION
?
Risk management plays an important role in the project management process. The goal
of effective risk management is fairly straightforward ….. to anticipate and analyze any
issues, circumstances and events that can threaten project success, and to respond to
those threats in such a way that they are either accepted, reduced or eliminated. As
such, risk management is an essential part of the project management process.

The Risk Management Planner is a practical tool for risk management planning and
execution. This workbook takes a comprehensive look at the many strategic and
procedural issues involved in risk management. Using the information, and the tools
provided, you will learn how to develop workable risk management practices for your
project environment. To that end, this workbook is structured as follows:

Chapter One: Risk Management Strategies (jump to Chapter One)

This chapter discusses the strategic issues and elements of the risk management
process, showing you how to….

• Evaluate project characteristics as part of risk management planning.

• Identify and categorize specific types of risks to facilitate the assessment


process.

• Assign risk probabilities to determine the most likely risks.

• Assess risk impact to determine ramifications and consequences.

• Plan effective risk response and control strategies.

Chapter Two: Risk Management Mechanics (jump to Chapter Two)

This chapter discusses the mechanical elements of the risk management process,
showing you how to implement tangible policies and procedures for managing risks.
This section provides you with the nuts and bolts of risk management covering:

• Origination

• Roles and Responsibilities

• Review and Analysis

• Response Management

• Oversight

• Closure

Page #1 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Chapter Three: Risk Management Tools (jump to Chapter Three)

This chapter provides the worksheets, checklists and templates you need to plan risk
management procedures, and to implement your own chosen risk management
strategies and practices.

• Appendix A: The Risk Management Procedures Worksheet

To be used for planning risk management procedures for all projects, specific
types of projects, or any one individual project.

• Appendix B: The Risk Identification Worksheet

To be used for naming and evaluating project risks according to category,


impact, probability, priority and target value.

• Appendix C: The Risk Assessment and Response Template

To be used for assessing risk details and planning response strategies.

• Appendix D: The Risk Status Worksheet

To be used for tracking risk status and response plan progress.

• Appendix E: The Risk Identification Reference Checklist

To be used as a reference guide for risk identification, providing a checklist of


common project risks sorted by category.

The goal of The Risk Management Planner is to provide the tools and information
necessary to plan and implement effective risk management practices, suitably designed
to meet varying needs and circumstances.

As you use this workbook, you will find links created throughout for quick navigation
through the pages and tools as needed. The “Bookmarks” tab can also be used as a
source of quick navigation.

To begin, jump to Chapter One: Risk Management Strategies.

Page #2 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

CHAPTER ONE: RISK MANAGEMENT STRATEGIES

By their very nature, all projects involve risk. Projects are initiated to handle unique
circumstances --- to produce products, services or strategies that cannot otherwise be
produced as part of normal business operations. By definition, there is risk in every
unique project initiative. But, this risk potential goes well beyond the project outcome
itself. Actual project completion can be constrained by any number of operational
factors, including time, money and available resources. These constraints create a
breeding ground for problems and failures, and as such, they must be treated
accordingly …. as project risks.

As a project manager, it is your job to anticipate and control project risks before negative
consequences are realized. This is the essence of risk management: to identify risks,
assess potential impact, and to devise appropriate strategies for response and control.

Risk Management and the Project Cycle

The risk management process should be an ongoing effort, maintained throughout the
project management cycle. In order to deliver expected project results, you must be fully
aware of any potential risks that stand in the way of successful project completion. And,
this need exists and evolves throughout the life of a project.

Risk Management at the Start of a Project:

As you begin to plan and structure any project, risks should be identified and assessed
along with all the other major project elements. At the start of a project, the goal of the
risk management process is to identify likely risks, assess their impact and prepare any
appropriate responses. These goals must be incorporated into any documented project
plans, and all related tasks and activities.

Appendix B: Risk Identification Worksheet

Risk Management Midstream:

Once a project is underway, the risk management process remains in full swing, but it
also takes on an additional dimension. As projects are executed, underlying
circumstances and conditions may change, and project plans must be modified
accordingly. Any such project changes can give rise to new risks, and the risk
identification and assessment process must always be in play in order to deal with this
new risk potential.

In addition, as the project proceeds, any risks identified at the start of the project must be
continually monitored. This oversight takes shape through a series of questions
designed to uncover any changes in risk status…

• Have any predicted risks come to fruition?


• If so, was the impact as predicted?

Page #3 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

• Has the planned risk response been effective?


• How have any new project circumstances changed initial risk forecasts in
terms of probability and impact?
• Are any changes required in the risk control plan as a result of these
changes?

Appendix C: Risk Assessment and Response Template

Risk Management at Project Closure:

Once a project is completed and closed, the overall effectiveness of the risk
management process should be reviewed and assessed. To that end, risk process
evaluation should be included as part of any post-project review or audit. This risk
process evaluation should examine the efficiency of the overall risk management
process, and the quality of the results….

• Were all risks properly identified, assessed and controlled?


• Were any truly predictable events overlooked?
• If so, how can the risk management process be improved in the future?

Appendix D: Risk Status Worksheet

What are project risks?

Project risks can be most simply defined as any event, circumstance or situation with the
potential to prevent, disrupt or diminish the successful completion of a chosen project
initiative. And the key word here is potential – i.e. the likelihood that a negative event
can and will occur.

Once a negative event takes place, or if it is a certainty from the start, it is a problem, not
a risk. Risk events are potential problems, and risk management is designed to help you
deal with that unfortunate, but inevitable degree of uncertainty.

Risk is all about potential and probability – what can happen, how likely is it to happen,
and what are the consequences if it does…..?

Any realistic risk assessment process begins with identification …. what can happen?
Since all project risks share certain common characteristics, any structured approach to
risk management should be designed to use those similarities to your advantage.

To save time and facilitate planning, risks can be initially viewed through a series of
standard categories that can be readily defined and organized. The risk assessment

Page #4 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

process provided in this workbook is based on the concept that project risks can be
organized into five common categories.

RISK CATEGORIES:

THE FIVE CATEGORIES OF PROJECT RISK

• Management Risks
• Technical Risks
• Resource Risks
• Organizational Risks
• External Risks

Providing a structured view of project risks to facilitate identification and analysis….

• Management Risks:

Risks that relate to the scope, structure and strategy of a given project. These
risks go to the heart of the project process itself, as they pertain to overall
project organization, definition and management. Potential management risks
can include ill-advised project selections, a lack of management support, a lack
of structured project management processes, insufficient requirements, or a
cursory definition of goals, scope and deliverables.

• Technology Risks:

Relate to the design and implementation of the technical elements of a project.


These risks usually involve the project outcome itself, or the manner in which the
outcome is developed and/or implemented. Technical risks can include early
adoption of new technology, an inappropriate reliance on older technology,
version conflicts, platform incompatibilities, or software and hardware bugs.

• Resource Risks:

Relate to finances, product availability, project staffing, training and resource


allocation. No project can be completed successfully without the right mix of
resources, and the appropriate allocation of those resources. In project terms,
resources include money, staff, and any products and tools necessary to
manage and complete a project. As such, resource risks can pose serious
threats to successful, timely project completion. Resource risks can include
product delivery delays, insufficient funding, a lack of skilled resources, the loss
of specific, key resources, or a lack of sufficiently skilled service providers.

Page #5 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

• Organizational Risks:

Relate to internal company and organizational issues that can impede project
execution and completion. Projects are completed by people, and it would be
unwise and unrealistic to ignore the risks posed by internal politics, interpersonal
relationships and related power struggles. Organizational risks can include
power struggles and ownership conflicts, ineffective team dynamics, and project
team personality conflicts.

• External Risks:

Risks that go beyond the direct control of the project team, caused by external,
environmental, or industry factors. These risks can include changes to industry
regulations, changes in economic conditions, the release of new technologies,
or company mergers. Any risks of this nature can impact internal decisions and
strategies that may render any project inappropriate or ineffective. While these
risks can be difficult to predict, timing and industry circumstances can be used
as a measure of likelihood and impact. If circumstances are right, it is always
wise to keep an open mind to the impact of mergers, reorganizations or
recessions as you make project plans and recommendations.

Appendix E: Risk Identification Reference Checklist

While these categories certainly are not all inclusive, they do establish a consistent basis
for risk identification and evaluation …... creating a specific point at which to start. Using
these five categories as a foundation, we will now move on to our examination of the risk
management process.

THE RISK MANAGEMENT PROCESS:

Within this workbook, we lay out a practical process for risk management, based upon
the concepts and definitions expressed in the section above. In order to achieve desired
results, this process addresses two key structural elements …strategy and mechanics.
In the next chapter, we will examine the mechanics of the risk management process (
i.e. the means by which the risk management process is executed). In this chapter, we
will look at strategy….

Risk Management Strategies:

Risk management strategies establish the basis and criteria upon which risks are
identified and assessed. Once realized, risks can threaten the success of any project,
both in terms of process and outcome. To effectively manage risk, realistic guidelines for
identification and evaluation must be established and consistently enforced. And above
all, these guidelines must be designed with sufficient flexibility to meet varying project
circumstances, conditions and capabilities.

Page #6 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

To that end, risk management strategies can be viewed as a series of five structural
components:

RISK MANAGEMENT STRATEGIES…..

• Evaluating project characteristics


• Naming specific risks
• Assigning probabilities
• Assessing impact targets and values
• Planning response and control activities

Risk Management Strategy - Part One: Evaluating Project Characteristics

Risk management strategies begin with an assessment of individual project


characteristics. Obviously, as project circumstances vary, so will the need for risk
management. To be truly effective, risk management processes must be appropriate to
the needs and circumstances of the project at hand. Along these lines, it seems logical
and likely that larger, more complex projects will require more stringent risk management
procedures than smaller, simpler projects.

If you applied a rigid risk management process to each and every project, regardless of
individual needs and circumstances, you may be wasting valuable time and resources
on an inappropriate and ineffective effort.

Know your project …..

When you take the time to consider individual project characteristics, you will be in a
better position to tailor your overall risk management process to suit the needs of the
project at hand. This will likely lead to better results and improved productivity.

As you look to apply risk management processes to any given project, you will need to
consider the following questions…..

• Is risk management necessary for this particular project?

• What benefits can be realized from risk management for this particular project?

• If risk management is necessary, should all policies and procedures be followed,


or should procedures be resized to suit the needs of the project, available time,
and available resources?

• Should more attention be paid to specific areas of risk than to others?

See the “Questions to Consider” Summary

Page #7 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

To answer these questions, you can look to six defining project characteristics, specified
below. Table 1: Project Evaluation Criteria for Risk Assessment, lays out these six
elements:

TABLE 1:
Project Evaluation Criteria for Risk Assessment

; Visibility What is project visibility?

The extent to which the project is visible to company


management, thus creating a smaller margin of error. Risk
management takes on a more urgent tone in a highly visible
project.

; Value What is project value?

The ultimate value of the project to the organization in terms


of business or technical objectives. Highly valuable projects
will most likely require a greater attention to risk detail.

; Experience What is project experience?

The level of experience that the project team has had with
this particular type of project. Under the certain conditions,
an inexperienced project team may be a risk in and of itself.

; Size and What is project size and complexity?


Complexity
The overall size and complexity of a project in terms of
duration, number of tasks, and degree of difficulty and
complexity. The time, expense and complexity of large
projects can present increased opportunities for risks.

; Project What are project circumstances?


Circumstances
The generic organizational and political conditions under
which the project is taking place …. i.e. stressful or
supportive, reactive or proactive, positive or negative? A
stressful, negative work environment can render a project
more susceptible to the influence of risks.

; Risk Threshold What is risk threshold?

The degree to which risks can be withstood within a given


project …. i.e. will a certain level of risk cause the project to
be cancelled, or will you forge ahead no matter what? A
project manager must evaluate the extent to which risks can
be absorbed, and the extent to which risks can reasonably be
managed.

Page #8 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

As you examine individual projects from these perspectives, the need for flexible risk
management practices should become even more apparent. For example, contrast
these two projects…..

Project A: Project B:

; High Visibility ; Low Visibility


; High Value ; Moderate Value
; Inexperienced Project Team ; Experienced Project Team
; Long and Complex ; Short and Simple
; Stressful Conditions ; Positive Environment
; Low Risk Threshold ; Moderate Risk Threshold

While the differences between these projects may lie on the extremes, the illustration is
intended to make a simple point …. one process may not fit all. A highly visible,
complex project, portrayed as “Project A”, will likely require a higher level of risk
management than its smaller, less complex counterpart, as portrayed by “Project B”.

Risk management processes should be applied in appropriate proportion to the needs of


the project, as follows:

Step One: Carefully consider your standard risk management processes to


determine how they can be best applied to the project at hand.

Step Two: Carefully consider the benefits to be realized from any risk
management efforts, weighed against the value of the project, your available
resources, and other projects pending. In most project environments, difficult
choices have to be made, and you may find that time is better spent on other
matters, rather than on extensive, perhaps unwarranted, risk management.

Step Three: Modify risk management activities to suit the project at hand with a
focus on specific types of risks and corresponding activities.

Step Four: Document your project evaluation findings and related risk
management decisions to ensure a proper audit trail, and to use as future
reference for similar projects.

Risk Management Strategy – Part Two: Naming the Risks

After examining critical project characteristics, likely risks must be identified and
categorized.

Depending upon the nature, complexity and duration of your project, risks will vary by
type, impact and degree. As previously discussed, to facilitate identification and
assessment, the risk management process provided herein relies on the use of “risk

Page #9 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

categories”. These categories provided a structured view of potential risks, organized


according to type, source and underlying cause .....

• Management Risks (project definition, structure and process)


• Technology Risks (project outcome or design processes)
• Resource Risks (people, money and equipment)
• Organizational Risks (internal organizational and operational conditions)
• External Risks (circumstances outside the direct control of the project team or
its customers)

With the use of these structured categories, individual risks can be more readily
identified and specifically named. In all, risk identification can be a time consuming and
challenging process, relying heavily on common sense, communication, observation,
and past experience.

Common sense identification of project risks begins with a simple question ….. what can
go wrong? Based on specific project circumstances, logic and deductive reasoning can
be applied to expose the most apparent types of risks. Consider these examples….

• If you are planning a project that relies heavily on the timely delivery of specific,
limited availability products, any delay in delivery would present a risk.

• If you are planning a project that relies heavily on one individual with a specific
set of unique skills, that reliance would present a risk.

• If you are planning a project that relies heavily on new, relatively untested
technologies, that technology would present a risk.

Going beyond logic and common sense, communication and observation can also be a
valuable source of risk information. In all likelihood, as you plan your project, team
members, stakeholders, and customers will raise a multitude of issues and concerns,
either through words or deeds. Under the right set of circumstances, these concerns
and behavior patterns can easily translate into any number of project risks. For
example, communication, observation and insight can reveal:

• Internal power struggles for project ownership and authority that can inhibit
effective cooperation and supporting activities.
• A resistance to change on the part of end-users that can interfere with effective
requirements definition, or critical training activities.
• A lack of appropriate and effective management support that can threaten
funding, or preclude effective, timely conflict resolution.

Aside from common sense and behavioral insights, the most useful source of risk
information may very well be past project experience. To begin with, past projects are a
barometer of likely project risks …. if it happened once before under similar
circumstances, it may very well happen again. In addition, past project experience may
be the best statistical basis upon which “unique” risks can be identified. For example,
until you have attempted a technology migration project, or an office relocation project,

Page #10 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

you may never be able to fully appreciate the unique series of risks presented. Only
experience can uncover the truly unique risks…. those born out of certain projects, in
certain environments, and under certain conditions.

There is no simple formula for risk identification, but with the use of common sense,
logic, insight, and past experience, you will uncover the vast majority of risks you are
likely to encounter.

Appendix E: Risk Identification Reference Checklist

Risk Management Strategy – Part Three: Assigning Probabilities

Once project characteristics have been identified, and risks have been named,
probability must be addressed. It makes little sense to expend valuable time and
precious resources in an effort to assess and control improbable risks. Risk
management efforts should be realistic and well placed.

As such, risk management should apply to risk events that are more than just
possibilities …. to warrant further time and attention, risks must be probabilities ….
i.e.….they must be realistic and likely to happen. With this perspective, you can focus
attention on appropriate risk priorities, allocating valuable time and resources to risk
events and circumstances that can threaten project success in a realistic and tangible
way.

Absent a crystal ball, risk probability assessment is largely a product of common sense
and experience.

• What problems have you experienced in the past in similar projects?

• Could any of those problems have been predicted …. i.e. did they appear as
risks before they became problems?

• Could any of those problems be repeated in this project?

• Based on prior project circumstances, compared to current project conditions,


how likely is it that similar risks will occur?

See the “Questions to Consider” Summary

Page #11 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

The answers to these questions will help you to assess risk probability. If, as you
complete this analysis, you find that past project experience is indeed prologue, you can
use that knowledge and experience to apply a sliding scale of risk probability, ranging
from low to high…..

Low ………………….. Medium ……………………….. High


Highly unlikely …………..50 – 50 Chance ……………....Highly Likely

Used in conjunction with project characteristics and named risks, you can use probability
as a means of pinpointing risks for further analysis and action. But, risk probability offers
only a partial picture for analysis. At this point, you may be able to exclude risks that are
highly unlikely, but in order to fully assess risks and plan further actions, you must be
able to evaluate risk impact …. i.e. if this risk were to occur, what would be the likely
consequences? This brings us to the next step in the risk management process,
evaluating impact targets and values.

Risk Management Strategy – Part Four: Assessing Impact Targets and Values

The assessment of impact targets and values is all about consequences …. how and to
what degree will a given risk affect any given project? Again, consequences are tough
to predict, but prior experience can once again be a valuable indicator….

As you examine individual risks in the light of past projects, you will need to address the
following key questions…..

• Can this risk affect the quality and usefulness of planned project deliverables?

• Can this risk increase project costs and expenses?

• Can this risk delay or otherwise interfere with timely project completion?

• Can this risk impede the project planning and management process?

• Can this risk affect the stability of the overall project work environment?

See the “Questions to Consider” Summary

As these questions show, risks can impact a given project in any number of ways. For
planning purposes, risk impact can be most simply measured in terms of risk targets.
Within this workbook, we have identified five distinct risk target categories as follows:

Page #12 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Risk Target Categories:

; Quality: to threaten the quality of the project result

; Costs: to threaten project budgets and funding availability

; Schedules: to threaten timely project completion

; Management Processes: to threaten the effectiveness of the project process

; Project Environment: to threaten the stability of your project environment, its team
and overall working conditions

Once you can identify likely targets for any given risk, you will need to determine the
extent of the impact. At this point, one defining question must be addressed: if this risk
occurs, will the consequences be serious enough to warrant further action? To answer
this question, you must be able to quantify the impact. To that end, risk impact can be
graded along a scale similar to that used to grade risk probability:

Low ………………….. Moderate …………………….. High


Not serious …………..Moderately serious ……………....Very Serious

In practical application, these ratings are largely subjective, applied on the basis of
experience, common sense and the specifics of the project at hand. As you look at risk
impact, a few practical guidelines can be applied to help you determine whether the
“low”, “medium” or “high” label is warranted. Consider the illustrations offered below:

Considering an impact on quality:


Can this risk cause a degradation in the quality of project outcome serious enough so
that the result will be different than what is needed and expected?

‰ Yes = a moderately serious to very serious impact


‰ No = a low impact

Considering an impact to cost:


Can this risk cause an increase in project costs to the degree that additional funds may
not be approved, or the project cannot be completed?

‰ Yes = a moderately serious to very serious impact


‰ No = a low impact

Page #13 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Considering an impact to schedules:


Can this risk cause a schedule delay that cannot be absorbed, and as such, will threaten
the successful completion of the project as currently planned?

‰ Yes = a moderately serious to very serious impact


‰ No = a low impact

Considering an impact on management processes:


If this risk occurs, will standard management processes be abandoned or modified to the
extent where consistency, quality, or other projects are threatened?

‰ Yes = a moderately serious to very serious impact


‰ No = a low impact

Considering an impact on the project environment:


Can this risk cause problems in the project environment, creating stress, burnout and
other internal conflicts such that overall project success is threatened?

‰ Yes = a moderately serious to very serious impact


‰ No = a low impact

Putting It All Together….

To complete the assessment picture, the analysis of risk probability, impact and target
values should be combined into one comprehensive perspective … forming a risk
threshold.

Risk threshold is the level of risk that can be withstood within any given project, used as
a measure of “priority” for risk control and response planning. As you can see from the
discussion to this point, risk management is a complicated process, filled with many
variables and nuances. And, above all, it all takes time. Depending on the particular
project, you may or may not have the time to devote to full-scale risk management. As a
result, you may need to focus specific risk management activities on those risks of the
highest probability and greatest impact. With the use of risk thresholds, you can set
useful guidelines to ensure that the most critical risks receive the most effort and
attention.

Determining Risk Priorities and Thresholds….

Table 3: Risk Management Thresholds, provides a matrix for assessing risk priorities.
This matrix is based on the premise that risk priorities are best determined through a
careful balancing of impact and probability, with impact getting first consideration. Under
this process, risks with a “moderate” impact, and “high” probability (Code: MH) are
assigned a higher priority score than risks designated as “SL” (serious impact, low
probability).

Page #14 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Considering the time constraints under which most projects are undertaken, limited time
may be available for risk management and related activities. While you may want to
prepare for all risks, realities prevail, and choices have to be made as to how time and
resources are best spent. In this instance, it may be wise to focus on risks with a more
moderate impact, but a higher probability of occurrence, rather than risks with more
serious impact potential, but a much lower probability of occurrence.

TABLE 3: Related Worksheet Tools:


RISK PRIORITY MATRIX The Risk Identification Worksheet
The Risk Assessment & Response
Template
Impact Probability Code Priority Score
Serious High SH 1
Serious Medium SM 2
Moderate High MH 3
Moderate Medium MM 4
Serious Low SL 5
Moderate Low ML 6
Low High LH 7
Low Medium LM 9
Low Low LL 10

As you look to apply these strategies, always keep an eye on flexibility and individual
circumstances. Priorities can and do change within any project, and it is important to
modify policies and procedures as needed to best suit individual circumstances and
requirements. As such, it is important establish risk thresholds that are well suited to the
needs of the project at hand.

Risk Management Strategy – Part Five: Response and Control Planning

Once risks have been fully identified and analyzed, response strategies must be
selected and planned.

Once again it is important to note that there is no one best approach to risk response
and control, and that individual response strategies will vary based on project
requirements and the nature of the risks identified. But, specific response strategies can
still be boiled down to three primary possibilities….

1. You can decide to move on with the project without taking any further actions to
control or respond to one or more risks. This is known as risk acceptance.

2. You can take action to eliminate one or more risks in entirety. This is known as risk
avoidance.

3. You can take action to minimize the probability and impact of potential risks. This is
known as risk mitigation.

Page #15 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

The following chart, Table Four: Risk Response Matrix illustrates the theoretical
distinctions between these three risk response alternatives:

TABLE 4: Related Planning Worksheets:


RISK RESPONSE MATRIX Risk Assessment & Response Template
Acceptance Avoidance Mitigation
Results of the risk Results of the risk Results of the risk
The Basis identification and identification and identification and
assessment process. assessment process assessment process

To proceed with the To avoid risk through To minimize risk potential


The Strategy project without any substantial project and impact through
further action to control changes, or in the carefully crafted
risks. absence of other management procedures
alternatives, project and strategies.
cancellation.
As a strategy, risk In risk avoidance, the Risk mitigation is based on
The acceptance is not goal is to eliminate the the premise that project
Reasoning meant to imply “risk risk in entirety, largely benefits outweigh the costs
ignorance”. The because risks are too of risk mitigation. The
decision to accept risks great, and the costs of project is the imperative,
is based on the premise risk mitigation would and you must go ahead –
that further risk action exceed expected project despite the obstacles.
will either be non- benefits. To avoid risks, Therefore, the goal of
productive, too time- you may need to cancel effective mitigation is to
consuming or too costly. the project or enact minimize risk probability
In essence, when you substantial planning and impact, and to be
decide to accept project changes so that prepared with alternative
risk, you have decided associated risks are actions should risk potential
to “take the chance”. eliminated. be realized.

Once again, there are no hard and fast rules as to when and how to apply these basic
risk control strategies. However, there are certain practical realities to consider….

Under most circumstances, the decision to accept risks is probably too extreme, except
for the simplest projects, where risk control offers little or no benefit. Most of us cannot
afford to just accept risks without some further planning and analysis ….. just in case.

Avoidance can also be an extreme measure, particularly when project cancellation is the
chosen solution. Under the right set of circumstances, projects may very well be
management directives, and despite any obvious technical or logistical risks, “the show
must go on”. Under these circumstances, project cancellation is probably not an option.
However, it is important to remember that cancellation (or postponement) is not the
same as failure (or risk aversion), and sometimes project risks are just too great to
warrant continuation. This is probably the most compelling argument for risk
assessment … if a project is to be cancelled or postponed due to excessive risk, you
must be in a position to make that case, and justify your recommendations. Only an
effective, realistic risk assessment can provide you with sufficient information to make
that case.

Page #16 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

In all likelihood, the most common risk control action is mitigation. In essence, mitigation
is a combination of acceptance and avoidance. There are two levels of risk mitigation -
proactive mitigation, to prevent risks, and responsive mitigation, to respond when and if
risk events occur. Depending on individual risks and project circumstances, these levels
of mitigation can be deployed in any number of ways…. you may decide to alter project
plans and schedules, or to take other specific actions to minimize the chance that a risk
will occur. In addition, you can also develop contingency plans that will be enacted only
if the risk actually occurs .... "i.e. if this happens, I will do that, but until then, I will stick
with the original plan".

Risk Response – Practical Applications

The selection and application of specific response and control strategies will vary
according to project circumstances, time, and available resources. When faced with the
selection and development of risk response and control strategies, several key questions
must be addressed….

• What is your goal?


• Which response offers the best chance of meeting that goal?
• Which response is possible – i.e. what actions are realistic in terms of time,
resources, skills and costs?
• Who must be involved in developing, selecting and approving risk response
decisions?

And, once preliminary response decisions are made, additional questions must be
addressed if mitigation is the chosen alternative….

For proactive mitigation…..

• Is proactive mitigation possible and worthwhile?


• If so, what steps can be taken to prevent the risk from occurring?
• Who is responsible for activating and implementing the prevention plan?
• How will the prevention plan be integrated into ongoing project activities in terms
of planning, execution, oversight and communication?
• What are the costs associated with the prevention plan?
• What resources will be required to execute the prevention plan?
• How will project schedules and deliverables be affected?

For responsive mitigation…..

• Is responsive mitigation possible and worthwhile?


• If so, what event criteria will be used to trigger the response?
• Who is responsible for activating and implementing the response plan?
• How will the response plan be integrated into ongoing project activities in terms
of planning, execution, oversight and communication?
• What are the costs associated with the response plan?
• What resources will be required to execute the response plan?

Page #17 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

• How will project schedules and deliverables be affected?


• Is a response test plan required to ensure that the planned response is
effective?

See the “Questions to Consider” Summary

And, from a practical perspective, each chosen response strategy carries with it a
different set of implementation steps…..

Acceptance:

Step 1: Document the results of the risk assessment process.

Step 2: Recommend acceptance of risks.

Step 3: Continue with projects as planned unless and until circumstances change
to warrant reconsideration of risk acceptance.

Avoidance:

Step 1: Document the results of the risk assessment process.

Step 2: Recommend risk avoidance and pursue one of the following options….

• Cancel or postpone the project if needed.


• Outsource the project as a means of avoiding internal risks.
• Enact substantive project changes to one or all the following - project
requirements, scope, deliverables, budgets and resources so that one or more
risks are fully eliminated or avoided.

Mitigation:

Step 1: Document the results of the risk assessment process.

Step 2: Identify risk prevention and impact reduction alternatives which can include:

• modifications to project deliverables to minimize risk potential


• modifications to project schedules
• reallocations of resource assignments, roles and responsibilities
• additional training for project staff
• the acquisition of critical products and services earlier than needed

Page #18 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Step 3: Develop risk contingency plans:

Risk control activities that will be enacted only if the risk occurs….

• modify deliverables in response to risk occurrence


• modify project plans, tasks and schedules to respond to risk occurrence
• add additional resources to project teams
• purchase additional equipment
• reallocate resources and/or equipment from other projects
• authorize overtime and additional work hours to compensate for risk
occurrences
• postpone or cancel other projects so that resources can focus on the project
at hand
• authorize additional expenditures in order to deal with risk occurrences

At the end of the day, your chosen risk control strategies will come down to needs and
capabilities …. how important is the project, and how far can you go in your efforts to
control risks? As you go through this important analytical process, you will need to
consider the following types of questions……

• What are the costs associated with each risk control activity? You will need to
identify all costs associated with risk avoidance and mitigation, which can
include equipment, overtime or additional resources. You will need to know
whether these risk control measures are affordable, within budget, and above
all, do they make sense in consideration of other business objectives?

• Do you have sufficient resources and skills to respond to risks? You will need to
identify resource requirements for risk avoidance and mitigation activities in
terms of staff, skills and available time. Risk control requirements can change
the nature and direction of any project, taking it outside the skill boundaries of
your internal staff. You may have the expertise to create risk mitigation plans,
but do you have the skills and the time necessary to execute those plans?

• What impact will risk contingency plans, once invoked, have upon your staff, and
your ability to complete other work? As previously discussed, risk control plans
and activities can change a project, and those changes can be substantial. As
you develop your risk control strategies, you will need to consider corresponding
project changes, and the impact those changes can have upon your overall
workload of projects and ongoing operational activities. In a multi-project
environment, any change in one project can cascade down to other projects,
even if they are seemingly unrelated. For that reason, when planning project
risk control strategies, you must consider both the project, and your overall work
environment.

Keeping these issues and strategies in mind, we are now ready to put theory into action,
with a review of risk management mechanics….. the procedures by which risk
management strategies are implemented.

Page #19 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

CHAPTER TWO: RISK MANAGEMENT MECHANICS

Having examined the strategic elements of the risk management process, we can now
turn to the mechanics …. the actual implementation of risk management strategies
through tangible procedures and steps….

Step by Step to Risk Management….

In order to ensure that risks are properly and consistently evaluated, risk management
strategies should be backed up by sound, structured steps for execution and
implementation.

To that end, this workbook lays out the essential procedures and steps involved in risk
management mechanics. We begin by examining the primary elements involved,
structured into a five-category workflow…..

RISK MANAGEMENT PROCEDURAL FLOW:

1. Origination
2. Assignment
3. Execution
4. Oversight
5. Closure

Risk Management Mechanics – Part One: Origination

Risk origination procedures establish the mechanics by which risks are initially identified
and raised for further analysis and consideration. As previously discussed, risk
management takes place throughout the entire life of a project …. from start to finish.
Therefore, risks can be identified and raised at any time. In order to ensure that proper
attention is paid to each and every risk possibility, procedures should be established to
allow for ready identification at any point in a project.

To that end, risk origination procedures should provide structured formats and methods
by which risks are raised and communicated. Such methods and formats can range
from the simple to the technically complex, and may involve the use of paper forms or
electronic databases. But, whether paper or electronic, the methods and formats by
which risks are first raised should provide for the entry certain basic information….

; Preliminary risk data – what is the nature of the risk and potential impact on the
project?
; The name of the individual raising the risk
; The date the risk was raised
; A target response date – when must this risk be analyzed and addressed?

Page #20 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

This risk origination process should also include a mechanism for risk receipt and
acknowledgement. Once the risk origination form is submitted or the database entry is
made, its existence should be acknowledged in some formal manner. Once again,
specifics will vary based methods and tools used, but, acknowledgement procedures
should include some sort of tangible “receipt”, confirming that a risk was raised. This
“receipt” can be a written communication, the assignment of an id number, or an entry
into a risk assessment queue.

Methods and formats for initial risk identification will vary based on the project at hand,
the size and structure of your project team, and internal technical capabilities. However,
whether you submit risks on paper, or whether you use database systems to record risks
as they are raised, origination procedures should ensure that once risks are raised, they
can be heard, and that timely, appropriate action can be taken.

Risk Management Mechanics Part Two: Assignment

Risk assignment procedures establish the mechanics by which risks are assigned to
appropriate staff members for further analysis and action. Risk assignment procedures
should address the following:

• Risk review assignments …. i.e. how are risk assignments to be made within
your organization and for any given project? Depending on specific needs and
organizational circumstances, risks may be assigned to individuals, to the
project team as a whole, or to a specific team of individuals created to handle
risk reviews (i.e. a Risk Review Team). Whatever structure is chosen, that
decision should be made at the start of the project.

• Roles and responsibilities within risk review process. No matter how risks
are assigned, intended roles and responsibilities should be clearly defined. This
establishes clear expectations for the project team, and lays a proper foundation
for effective risk review. While the actual allocation of roles and responsibilities
may vary, there are certain defining elements that should be part of any
specification of roles and responsibilities:

; Risk Originator: the individual or team who first identifies a risk, and enters
said risk into the established origination process.

; Risk Analyst: the individual or team responsible for analyzing risks


according to established risk management criteria and strategies.
Responsibilities of the risk analyst(s) can include risk categorization,
probability and impact value assessments, and the recommendation of
response and control strategies.

; Risk Manager: the individual or team responsible for overall risk


management and oversight. Responsibilities of the risk manager can
include response strategy approval, and the related oversight of risk
management activities, including the success of control strategies and

Page #21 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

changes in the status of risk probabilities.

; The Project Team: once project risks are identified, analyzed and
controlling strategies are determined, those strategies must be incorporated
into the existing project plan, and executed as part of the overall project. In
all likelihood, the project team will be responsible for carrying out those
changes.

These various roles and responsibilities can be assigned in any number of ways. In a
small project environment, one individual may wear many hats. In a large project
environment, there may be separate teams and individuals assigned specifically to deal
with project risks. In fact, risk management may be handled by groups or individuals
outside of the project structure itself … as can occur in a project audit situation. No
matter how your project team is structured and sized, risk management roles and
responsibilities should address ….

; Who can originate risks?


; Who will be responsible for risk review and analysis?
; Who will be responsible for developing and selecting risk response and control
strategies?
; Who will be responsible for approving risk assessments and related response and
control strategies?
; Who will execute risk response and control plans?
; Who will monitor risk status and the progress of any risk management activities?
; Who will approve risk closure?
; Who will be responsible for reviewing the success of the risk management process?

See the “Questions to Consider” Summary

Risk Management Mechanics Part Three: Execution

Risk management execution procedures determine the actual steps involved in the risk
review process, establishing the sequence of events and flow of information as risks are
identified and evaluated. For planning purposes, these execution steps can be broken
down into seven elements, as follows:

1. The risk is raised and initially identified.


2. The risk is assigned and prioritized for further action.
3. The risk is reviewed according to established criteria (category, probability, impact
and target values).
4. Risk response strategies are devised (acceptance, avoidance or mitigation)
5. Risk response strategies are approved.
6. Risk response strategies are implemented as needed.
7. Risk management activities as listed above are documented.

These steps form the heart of the risk review process in terms of tangible execution.

Page #22 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Risk Management Mechanics Part Four: Oversight

As previously noted, the risk management process is an ongoing effort that lives
throughout the entire project cycle. This is not mean to imply that every element of the
risk management process will be executed in all circumstances. If risks fail to
materialize, you may never have to take any further action for control and mitigation.
However, that does not mean that you can avoid risk oversight. Effective risk
management oversight has two unique dimensions – status measurement and progress
measurement.

Status measurement:

Whether or not risks ever materialize, risks still have to measured and monitored for any
apparent change in status. In the initial risk assessment process taking place at the start
of a project, potential risks are identified and evaluated. At that point in time, it may
appear that certain risks are unlikely, or that their impact will be insignificant. However,
as the project ensues, circumstances may change, and risks once thought to be unlikely
and insignificant, can suddenly become very likely, and quite dangerous. For this
reason, potential risks must be continually monitored as a project progresses. You can
never tell when risk conditions will change or when new risks will arise, and to prevent
unpleasant surprises, periodic risk reviews should be undertaken as often as practical
and whenever needed. At the very least, monthly risk review sessions should be built
into your overall project management process.

Progress Measurement:

Risk oversight procedures must also be designed to monitor the timing and completion
of all scheduled risk identification, evaluation and control activities. There are two
primary elements to risk progress measurement, detailed as follows:

1. Management of the risk review schedule, which can include organization and
prioritization of the risk review queue. Progress must be readily measured to ensure
that risks are reviewed on a timely basis, and to maintain a realistic risk review
schedule suited to project circumstances, overall project status, and external
resource demands.

2. Management of individual risk activities, to include the status of all tasks and
decisions necessary to manage individual risk events….

• Have risk review assignments been completed as needed?


• Have response and recovery action plans been completed as needed?
• Have risk response plans been properly communicated so that the project team
can act upon them?
• Are mitigation activities working?

And, above all, the risk management oversight process must provide the authority, ability
and the obligation to act if risk management results are not as expected, and as needed
to ensure successful project completion.

Page #23 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Risk Management Mechanics Part Five: Closure

The final element of risk management process is closure …. the point at which risks are
sufficiently resolved so that no further action is warranted. This is not meant to imply
that closure only arrives through resolution or elimination. Risk management closure
procedures can be applied at several points in the project cycle ….

Risk closure is appropriate when …..

• A risk is raised and no further analysis is warranted.

• A risk is realized, and response actions are completed so that the risk no longer
exists.

• The time or circumstances under which a risk can occur expires.

• The project is cancelled or completed.

Risk closure procedures involve several basic steps:

1. Risk status is assessed to determine if a risk is “open” (meaning that further analysis
or action may be required) or “closed” (no further action or analysis is required).

2. Risk status is documented. This documentation should address all elements and
results of the risk management process as pertaining to the risks at hand. This
should include the completion of all forms, and documented evidence of the ways
and means by which specific risks were evaluated, as well as the results of the risk
response and control activities.

3. Lessons learned are analyzed and recorded. Every project should conclude with a
post project review, to include a comprehensive Lessons Learned Analysis. Any
effective Lessons Learned Analysis should include an examination of the risk
process itself, as well as an evaluation of risk management processes as a
contributing factor to overall project success or failure….

Lessons Learned and the Risk Management Process

• Were all risks properly identified, assessed and controlled?


• Were any truly predictable events missed?
• How can risk management processes be improved in the future?

Page #24 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Lessons Learned in Light of the Overall Project

• Overall, was the project a success?


• If the project was a success, did risk management play any part in that success?
• If the project was not a success, could improved risk management have made a
difference?

SUMMARY:

As this workbook has shown, project risk management is a combination of strategies,


tactics, policies and procedures. The ultimate goal of risk management is to create
realistic processes for resolving project risks, so that time is well spent, and project
results are appropriately protected. Above all, risk management strategies and practices
must be well suited to the projects encountered, and to individual organizational needs
and capabilities. To create your own plan for project risk management, you will likely
face several key steps and decisions. These steps and decisions have all been
specified and examined in the previous pages, and for quick reference, are quickly
summarized as follows:

⇒ Part 1: Steps
⇒ Part 2: Questions to Consider
⇒ Part 3: Risk Review Process Flowchart

PART 1 - THE STEPS:

Step One: To develop and determine the criteria you will use to evaluate risk:

‰ Project Characteristics
‰ Risk Categories and Types
‰ Risk Probabilities
‰ Risk Targets and Impact
‰ Response and Control Strategies

Step Two: To develop and determine the approaches taken to control risk:

‰ Acceptance
‰ Avoidance
‰ Mitigation

Step Three: To develop and determine the means by which assessment and response
strategies are applied within the real world project environment.

‰ Origination
‰ Assignment
‰ Execution
‰ Oversight
‰ Closure

Page #25 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

PART TWO: QUESTIONS TO CONSIDER:

The following section summarizes the key “questions to consider” as you go through the
risk management planning and evaluation process:

Project Evaluation Questions:

• Is risk management necessary for this particular project?

• What benefits can be realized from risk management for this particular project?

• If risk management is necessary, should all policies and procedures be followed,


or should procedures be resized to suit the needs of the project, available time,
and available resources?

• Should more attention be paid to specific areas of risk than to others?

Risk Probability Questions:

• What problems have you experienced in the past in similar projects?

• Could any of those problems have been predicted …. i.e. did they appear as
risks before they became problems?

• Could any of those problems be repeated in this project?

• Based on prior project circumstances, compared to current project conditions,


how likely is it that similar risks will occur?

Risk Impact Questions:

• Can this risk affect the quality and usefulness of planned project deliverables?

• Can this risk increase project costs and expenses?

• Can this risk delay or otherwise interfere with timely project completion?

• Can this risk impede the project planning and management process?

• Can this risk affect the stability of the overall project work environment?

Risk Response Planning Questions:

• What is your goal?

Page #26 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

• Which response offers the best chance of meeting that goal?

• Which response is possible – i.e. what actions are realistic in terms of time,
resources, skills and costs?

• Who must be involved in developing, selecting and approving risk response


decisions?

For proactive mitigation…..

• Is proactive mitigation possible and worthwhile?

• If so, what steps can be taken to prevent the risk from occurring?

• Who is responsible for activating and implementing the prevention plan?

• How will the prevention plan be integrated into ongoing project activities in terms
of planning, execution, oversight and communication?

• What are the costs associated with the prevention plan?

• What resources will be required to execute the prevention plan?

• How will project schedules and deliverables be affected?

For responsive mitigation…..

• Is responsive mitigation possible and worthwhile?

• If so, what event criteria will be used to trigger the response?

• Who is responsible for activating and implementing the response plan?

• How will the response plan be integrated into ongoing project activities in terms
of planning, execution, oversight and communication?

• What are the costs associated with the response plan?

• What resources will be required to execute the response plan?

• How will project schedules and deliverables be affected?

• Is a response test plan required to ensure that the planned response is


effective?

Roles & Responsibilities Questions:

• Who can originate risks?

Page #27 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

• Who will be responsible for risk review and analysis?

• Who will be responsible for developing and selecting risk response and control
strategies?

• Who will be responsible for approving risk assessments and related response
and control strategies?

• Who will execute risk response and control plans?

• Who will monitor risk status and the progress of any risk management activities?

• Who will approve risk closure?

• Who will be responsible for reviewing the success of the risk management
process?

Risk Oversight Questions:

• Have risk review assignments been completed as needed?

• Have response and recovery action plans been completed as needed?

• Have risk response plans been properly communicated so that the project team
can act upon them?

• Are mitigation activities working?

Lessons Learned Questions:

Risk Management Lessons Learned:

• Were all risks properly identified, assessed and controlled?

• Were any truly predictable events missed?

• How can risk management processes be improved in the future?

Lessons Learned in Light of the Overall Project

• Overall, was the project a success?

• If the project was a success, did risk management play any part in that success?

• If the project was not a success, could improved risk management have made a
difference?

Page #28 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

PART 3: RISK REVIEW FLOWCHART

ORIGINATION:
Notes: This Risks are raised and
overall process initially identified
will be ongoing
until all risks are
resolved or the
project is closed
or cancelled.
ASSIGNMENT:
The risk is assigned
as needed for further
analysis.

EXECUTION:
Risk is reviewed and
analyzed.
risks are
reviewed for
additional facts
and further
action until
closure is Is further action required?
possible….
YES NO CLOSURE
Risk is closed
and fully
documented.

EXECUTION:
Risk response created

EXECUTION:
Risk response implemented

OVERSIGHT:
Risk response monitored

Risk Closed?

NO YES

Page #29 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

CHAPTER THREE: TOOLS FOR RISK MANAGEMENT

Relying on the concepts, strategies and steps provided in the previous chapters, this
section provides specific tools to be used as you plan and implement your risk
management program.

This attached series of five interactive worksheets, checklists and templates are
designed to help you plan risk management procedures, and implement related
strategies and tasks.

Appendix A: The Risk Management Procedures Worksheet

Purpose: To be used for planning risk management procedures for all projects,
specific types of projects, or any one individual project.

Timing: This worksheet can be used at the start of a project, or at any point
when risk management procedures require revision or further development.

Preparation: To complete this worksheet, you will need to consider your


technical alternatives and formats for risk communication, staff roles and
responsibilities, the sequence of events in risk process execution, and required
steps and criteria for risk management oversight and closure.

Appendix B: The Risk Identification Worksheet

Purpose: To be used for naming and evaluating project risks according to


category, impact, probability, priority and target value.

Timing: This worksheet can be used at the start of a project, or at any point
when risks are best viewed from a global “project” perspective.

Preparation: To complete this worksheet, you will need to consider the types of
risks you may encounter, and be prepared to analyze and assess those risks
according to impact, probability, priority and target value. This worksheet is
divided into five sections according to the five established categories of project
risks.

Appendix C: The Risk Assessment and Response Template

Purpose: To be used for assessing risk details and planning response


strategies.

Timing: This template can be used at any point when risks are best viewed
individually and in detail in terms of identification, analysis and response.

Page #30 Copyright 2002 Right Track Associates, Inc.


The Risk Management Planner IT Management Workbooks from Ttoolkit.com

Preparation: To complete this worksheet, you will need to consider the types of
risks you may encounter in a given project, and be prepared to analyze and
assess those risks according to impact, probability, priority and target value. In
addition, you should also be prepared to complete a risk impact statement, and
to identify, justify and specify your recommended risk response strategy.

Appendix D: The Risk Status Worksheet

Purpose: To be used for tracking risk status and response plan progress.

Timing: This worksheet can be used at any point in a project when risk progress
and status must be tracked and evaluated.

Preparation: To complete this worksheet, you will need to consider the status of
all major phases and tasks in the risk review and response process, including
specification of all tasks required to implement risk response plans. You should
be prepared with task specifics including task-numbering schemes, start dates,
descriptions, target completion dates and current status.

Appendix E: The Risk Identification Reference Checklist

Purpose: To be used as a reference guide for risk identification, providing a


checklist of common project risks sorted by category.

Timing: This checklist can be used at the start of a project, or at any point when
project circumstances indicate that further risk identification is warranted.

Preparation: To complete this checklist, you will need sufficient information


about your project to select appropriate and likely risks. This checklist provides a
list of common risks organized according to the following categories:

⇒ Management Risks
⇒ Technology Risks
⇒ Resource Risks
⇒ Organizational Risks
⇒ External Risks

As you consider these categories and the specific risks provided, you should also
be prepared to enter any additional, unique risks for future analysis and
consideration.

Happy planning…..

Page #31 Copyright 2002 Right Track Associates, Inc.


THANK YOU FOR YOUR PURCHASE FROM ITTOOLKIT.COM

IT Management Workbooks are published and produced by Right Track Associates,


Inc., information technology consultants, and producers of ITtoolkit.com. Having had
many years of practical IT experience, with small companies, and large corporations, we
know what it is like to be on the front lines of IT services and support. No matter how
your IT shop is sized and structured, IT "people" face certain professional realities....

THE IT REALITY.....

¾ No matter how many staff members you have, it is never enough....


¾ No matter how large your operating budget is, it is never enough....
¾ No matter how many projects you complete, or problems you solve, there are always
more projects and problems waiting in the wings....
¾ For every end-user who is happy with you, someone else is probably annoyed.....
¾ Just when you think you have a handle on all the latest technology changes,
something new comes along....
¾ It is difficult to keep up with the latest trends and skills when you are faced with a
never-ending stream of projects, problems and end-user requests....
¾ It is hard to keep IT staff motivated, engaged and "appreciated"....

STAY AHEAD OF THE CURVE:

In short, IT work is stressful and challenging. Time is always of the essence, but time is
also always in short supply. Under these circumstances, productivity is essential - to
make the most of the resources and time that you do have. And, we have learned that the
right set of practices, policies and practices can make the difference between total
frustration and the chance to succeed.

Our series of IT Management Workbooks have been written and produced with this in
mind ... to give you practical ideas, ready-to-apply processes, and useful tools.... so you
can stay ahead of the productivity curve.

We invite you to examine our series of electronic workbooks, available for easy online
purchase as single titles, or as multiple titles bundled into specially priced collections -
giving you more tools and information at special savings.

¾ Planning Guides
¾ Process Templates
¾ Interactive Worksheets
¾ Workbook Product Bundles ….. Save 20 – 30%

You might also like