Docstoc

Risk Management Plan Appriss

Document Sample
Risk Management Plan Appriss Powered By Docstoc
					                   Risk Management Plan


Project Name:       California Statewide VINE
Department:         Professional Services
Project Manager:    Stephen Adams
Date:               November 19, 2007
                                            Risk Management Plan




INTRODUCTION .................................................................................................. 1

PURPOSE AND SCOPE ..................................................................................... 1

RISK MANAGEMENT PLANNING ...................................................................... 2

RISK IDENTIFICATION ....................................................................................... 2

RISK IDENTIFICATION ....................................................................................... 3

RISK ANALYSIS.................................................................................................. 4

RISK PLANNING ................................................................................................. 4

RISK MONITORING AND CONTROL ................................................................. 5

RISK MANAGEMENT ASSIGNMENTS .............................................................. 5

RISK CLASSIFICATION...................................................................................... 6

REFERENCED DOCUMENTS ............................................................................ 8

DOCUMENT REVISION HISTORY...................................................................... 9
                                   Risk Management Plan

INTRODUCTION
The Appriss approach to risk management starts with a plan that defines the scope and process
for the identification, assessment, and management of risks which could impact the
implementation of the project. The objective of the Risk Management Plan is to define the
strategy to manage project-related risks such that there is acceptable minimal impact on cost and
schedule, as well as operational performance.

PURPOSE AND SCOPE

The purpose of the Risk Management Plan is to establish an approach to monitoring, evaluating,
and managing risks throughout the life of the project. A risk is an uncertain event or condition
that, if it occurs, has a negative or positive effect on the project’s objectives.

The risk management process will identify potential risk sources; assess individual risks and
impacts on performance, cost, and schedule; evaluate alternative approaches to mitigate high and
moderate risks; and develop action plans to handle individual risks.

The product of risk management planning will be the Risk Register. The Risk Register will
document the various risks with their classification, mitigation and handling strategies, impact on
cost and schedule, and action items.

The risk management process includes these five elements.

       1)    Risk Management Planning – Deciding how to approach and conduct the risk
             management activities for the project.

       2)    Risk Identification – An initial and continuous effort to identify, quantify and
             document risks as they are identified.

       3)    Risk Analysis – Evaluate identified risks to determine probability of occurrence,
             impact, and timeframe.

       4)    Risk Planning / Mitigation – Establish an action plan for risk and assign
             responsibility.

       5)    Risk Monitoring and Control – Capture, compile, and report risk.




09/28/2012                                      1                                       Version 1.0
                                                                Risk Management Plan


RISK MANAGEMENT PLANNING
Risk management planning is the process of determining how to approach and conduct risk
activities for the project. Planning is critical to establish the importance of risk management,
allocating proper resources and time to risk management and establish the basis for evaluating
risk.

The diagram illustrates the functional relationships of the five risk management process
elements:




                  Individual Activities                                         Weekly and Monthly


                                                                                                     Plan:
                                          Analyze:
                                                                         Analyze:                   Assign
  Identify Risk                           Classify
                                                                         Prioritize              responsibility,
                                          Evaluate
                                                                                                 Approve plans




                                          Risk
                                         Class,
      Risk                            Probability,                     Prioritized list           Assignments
   Statement                            impact,                           of task                approved plans
                                      timeframe




                                                       Individual Activities                     Weekly and Monthly


                                                Plan:
                                          Define Mitigation
                                             approach.                           Track:                         Control
                                            Determine
                                           Mitigation plan
                                                                                                                              LEGEND
                                                                                                                                  Decision
                                                                                                     Decision

                                                                                                      - Close Risk                 Activity
                                           Risk mitigation                                            - Take Planned Action
                                                                            Status Reports
                                                plan                                                  - Continue Tracking
                                                                                                      - Replan                     Output




09/28/2012                                                                                2                                     Version 1.0
                                   Risk Management Plan

RISK IDENTIFICATION

A baseline set of risks will be created and entered into the project Risk Register. These baseline
risks will be identified through the normal course of the project planning process. Risk
statements will be written for each identified risk. Risk statements will be clear concise and
contain only one risk condition and one or more consequences of that condition.

All project stakeholders are responsible for identifying new risks. New risks identified during
project related meetings shall be captured and added to the Risk Register within two working
days of the meeting. It will be the responsibility of the Appriss Project Manager to make sure this
is accomplished.

Appriss brings ten years of experience to the project in implementing similar systems. This
experience has provided Appriss with a unique insight to common operation and system risks.
Some of the common risks are documented in the table below. This table is not intended to be an
exhaustive list.

Risk Area                                           Potential Risk
Project Scope and Complexity                            Scope is not understood
                                                        Requirements not documented properly
                                                        Requirements not agreed upon by
                                                           customer
                                                        Complexity not understood in terms of:
                                                               o Technology
                                                               o Adapters needed
                                                               o Number of users
                                                               o Business process
Technology                                              Technology not proven
                                                        Unreliable performance record of
                                                           vendors
                                                        Inexperience with the technologies to
                                                           be used
                                                        Vendor infrastructure is not sound
Staffing                                                Inadequate resources committed to the
                                                           project
                                                        Project team does not contain members
                                                           that have experience with similar
                                                           projects
                                                        Resources pulled from project before
                                                           completion
Culture                                                 Users not willing to make business
                                                           process changes
                                                        Customer does not make a strong
                                                           commitment to project
                                                        Organization changes within agency,

09/28/2012                                      3                                       Version 1.0
                                    Risk Management Plan

                                                            removes key personnel
Project Management                                         Executive oversight committee is not
                                                            actively engaged in project
                                                           Project issues are not addressed
                                                           Change is not controlled and project
                                                            scope      grows     beyond      original
                                                            boundaries


RISK ANALYSIS
Appriss will use a qualitative approach to Risk Analysis. This methodology uses a risk level
matrix based on probability and impact. This allows for an independent assessment of probability
and consequence of risk.

Each risk shall be evaluated to determine impact, probability of occurrence, and timeframe. Each
risk shall be examined to determine its relationship to other risks identified. Initially, the
identifier of the risk shall provide an estimate of these attributes. The Project Manager shall be
responsible for further analyses and prioritization of the risks. The criteria for analyzing risks are
established later in the Risk Classification section of this plan.

RISK PLANNING

Risk handling is the identification of a course of action or inaction selected for the purpose of
effectively managing a given risk. All identified risks shall be handled. Specific handling
methods should be selected after the probable impact on the project has been determined.

The Appriss Project Manager will determine what action should be taken for each risk as it
brought to his attention through weekly team meetings and database reports. The Appriss Project
Manager shall determine whether to keep the risk, delegate responsibility, or transfer the risk
responsibility up the project organization chain. The Project Manager, if necessary, may transfer
a risk(s) to external organizations if that organization is best suited to handle the risk.

Risk planning requires a decision to perform further research, accept the risk (document
acceptance rationale in the Risk Register and close the risk), watch the risk attributes and status
(define tracking requirements, document in the Risk Register, and assign a "watch" action), or
mitigate the risk (create a Mitigation Plan, assign action items, and monitor the activities and
risk).

Mitigation activities shall be documented on the Risk Register or by creating a separate
Mitigation Plan. A Mitigation Plan shall be written for any effort that requires re-allocation of
project resources. The Project Manager shall determine when to use a Mitigation Plan.




09/28/2012                                        4                                       Version 1.0
                                    Risk Management Plan

RISK MONITORING AND CONTROL
Risk information and metrics defined during planning shall be captured, tracked and analyzed for
trends. The person assigned responsibility for the risk shall provide routine trend and status
reports on research and/or mitigation activities to the Appriss Project Manager during the weekly
project meetings. Watched risks shall be reported on during the monthly project meetings. The
Risk Register shall be used to report summary status, and a Stoplight Status Report shall be used
by the Appriss Project Manager to report progress to senior management at the monthly reviews.

Decisions shall be made by the Project Manager during the weekly and monthly meetings to
close risks, continue to research, mitigate or watch risks, re-plan or re-focus actions or activities,
or invoke contingency plans. This is also the time when the Project Manager authorizes and
allocates resources toward risks.

RISK MANAGEMENT ASSIGNMENTS
The following table describes the responsibilities of the project stakeholders:

        Who                                        Responsibilities
 Individual                    Identify new risks
 Members                       Estimate probability of risk, impact, and time frame
                               Classify risk
                               Recommend action
                               Assist in prioritizing risk
 Appriss Project               Collect all risk information from individuals
 Manager                       Ensure accuracy of probability, impact and time frame
                               Build the Risk Register
                               Collect and report risk measures and metrics
                               Report risk to senior management
                               Prioritize Risk
 Executive                     Authorize expenditures of resources for mitigation
 Oversight                     Authorize additional cost or time to mitigate risk.
 Committee




09/28/2012                                        5                                       Version 1.0
                                  Risk Management Plan
The following table describes the criteria for communicating and documenting risk

          Who                                    Responsibilities
 Individual Members           Any risk that impacts performance
 to Project Manager           Any risk that impacts >10 percent of budget
                              Any risk that exceeds schedule milestones
                              Any risk that needs to be transferred to another team
 Project Manager to           Mitigation activity status
 Executive Oversight          Any risk that impacts mission success
 Committee                    Any risk that causes the project budget to be exceeded by
                               more that 10 percent
                              Any risk that may negatively impact Appriss or their
                               customers
                              Risk status


RISK CLASSIFICATION

Risk shall be analyzed qualitatively using impact, likelihood and timeframe classifications
defined in this section. Impact is based on project success, resources, cost, and schedule.
Likelihood is used to provide an order of magnitude based on quantitative data and qualitative
experience.

Impact Classification

High
 Schedule Slip – Slip of delivery beyond two month of milestone schedules.
 Cost Overrun - > 10 percent increase in budget allocation.
 Technical – Loss of critical function or major objective.
 Political – Bad press for TOHS, DIR, TDEx, or other entities

Significant
 Schedule Slip - > 1 month <2 month delivery from milestone schedules
 Cost Overrun - > 5 percent but < 10 percent increase to budget
 Technical -Major function objective not fully met.
 Political - Senior Management has concerns about project success or development progress

Low
 Schedule Slip - > 2 weeks <1 month delivery from milestone schedules
 Cost Overrun - < 5 percent increase to budget
 Technical –Some wanted or desired functions are not met.

Negligible
 Schedule Slip - < 2 weeks delivery from milestone schedules


09/28/2012                                     6                                    Version 1.0
                                  Risk Management Plan

   Cost Overrun – minor impact
   Technical –Small impact to technical performance

Likelihood Classification

High (>70% chance of occurrence)
 Occurrence is very likely and may not be controlled by following existing processes,
   procedures and plans.

Significant (40% - 70% chance of occurrence)
 Occurrence is likely and may not be entirely controlled by following existing processes,
   procedures and plans.

Low (20% - 39% chance of occurrence)
 Occurrence is unlikely and may not be entirely controlled by following existing processes,
  procedures and plans.

Negligible (<20% chance of occurrence)
 Occurrence is very unlikely and is generally controlled by following existing processes,
   procedures and plans.

Timeframe Classification

Near - Action or mitigation needs to take place within the next 4 months

Mid - Action or mitigation needs to take place between 2 months and 4 months

Far - Action or mitigation needs to take place beyond 4 months

Once risk items are entered they will be assigned an exposure grade red, yellow, or green based
on the following combinations of impact/likelihood:




09/28/2012                                     7                                    Version 1.0
                                   Risk Management Plan



       High                                                                       RED



       Significant                          YELLOW


       Low

                                      GREEN
       Negligible


                      Negligible           Low                Significant         High
                                    Risk Classification Chart

Green - Items classified as green are acceptable without further mitigation and will be routinely
tracked.

Yellow - Items classified as yellow may require mitigation. For these items, alternative
dispositions will be identified and trade-offs conducted to determine the mitigation required.

Red - Items classified as red are considered primary risk drivers. For these items, mitigation
options will be developed. Red risks will be assessed for impact to budget reserves and will be
tracked to closure.

Timeframe is used in conjunction with the Risk Classification Chart to determine priorities,
establish when risks need to have actions taken, and how long risks may need to be watched or
tracked before they no longer are a concern or can be closed.

Each project review meeting will result in an update to the project Risk Register that will be sent
to all project personnel.

REFERENCED DOCUMENTS
   1. Risk Register
   2. Mitigation Plan
   3. Stoplight Status Report




09/28/2012                                      8                                        Version 1.0
                                Risk Management Plan


                             Document Revision History

   Version    Date                    Changes              Updated By
     1.0     4/30/07   Original document                 C. Higginbotham




09/28/2012                                 9                        Version 1.0

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:13
posted:9/29/2012
language:Latin
pages:11