2013fall2gm600.files.wordpress.com€¦ · Web viewIn order to monitor the project for technical performance risks, the process will be to: 1) forecast the values to be achieved

Risk and Opportunity Management Plan (ROMP) Template

Page i

<DocName> Template

Template Revision History

Revision Date Revision Revision Description

NOTE: Delete this and all above pages prior to using template.

Page ii

Risk and Opportunity Management Plan (ROMP)

<Project Name>Risk and Opportunity Management Plan (ROMP)

<Document ID>(may be multiple lines long and include such things as Contract Number per contract

requirements)(If no contract requirements exist for the Document ID, use the organization-defined

documentation nomenclature, as follows:<type of document>-<brief description>-<project acronymn>

<Identify document in accordance with the document numbering work instruction>

Page ii


Signatures[Include Signature Table based on the nature of the individual Template. All plans and all technical documents typically require signature pages.][Add additional signatures lines:● add row● copy signature line from elsewhere in the table (maintains styles)● update names and titles.Signature lines can be deleted using Table | Delete | Rows.]

Prepared By:First1 M1. Last1, Project Risk Manager Date

Approved By: First4 M4. Last4, Project Manager Date

Page


Revision History

Revision Date Revision Revision Description

Page


Table of Contents1 PURPOSE.......................................................................................................12 SCOPE............................................................................................................13 STRATEGY.....................................................................................................1

3.1 Roles and Responsibilities..........................................................................23.1.1 Project Manager (PM)..............................................................................23.1.2 Risk Manager (RM)..................................................................................23.1.3 Individual Contributors.............................................................................23.1.4 Risk Owner...............................................................................................33.1.5 Risk Review Board...................................................................................3

4 Schedule & Deliverables.................................................................................35 APPROACH TO RISK MANAGEMENT..........................................................4

5.1 Risk Categories...........................................................................................45.1.1 Technical Risks........................................................................................45.1.2 Cost Risk..................................................................................................55.1.3 Schedule Risk..........................................................................................55.1.4 Programmatic Risk...................................................................................55.1.5 Risk Ratings.............................................................................................6

5.2 Risk Classification.......................................................................................85.3 Process........................................................................................................95.4 Process Structure........................................................................................9

5.4.1 Identification.............................................................................................95.4.2 Assessment............................................................................................115.4.3 Mitigation................................................................................................115.4.4 Reporting................................................................................................12

6 ROM MEASURES.........................................................................................137 DEFINITIONS OF TERMS............................................................................14APPENDIX A. RISK ASSESSMENT Tables (Sample)...................................................17APPENDIX B. OPPORTUNITY ASSESSMENT TABLES (Sample)..............................19APPENDIX C. Sample Risk Report from Risk Radar.....................................................20

Page


1 PURPOSEThe purpose of this Risk and Opportunity Management Plan (ROMP) is to define the roles and responsibilities, processes, and procedures that <Project Name> will use to manage project R&Os in accordance with the above policy and plan and any customer-specific requirements.

2 SCOPEThis plan covers the management of R&Os for the <project name> project. In the project domain, R&Os are assessed in terms of their probability of occurrence and impact to the business and potential effect on Schedule, Cost, and Performance. The focus of this ROMP is risks and opportunities. Therefore, issues, concerns, and problems are not risks or opportunities and are outside the scope of this document.

3 STRATEGYRisk and Opportunity Management (ROM) is a key driver for project success in <Project Name>. ROM will be applied throughout the project and implemented in an effective way such that the risk reduction measures and contingency options must be cost effective. The objective is to ensure that the risk is maintained at an acceptable level after mitigation processes are carried through the entire project lifecycle. <Project Name> Risks and Opportunities are assessed in terms of their potential impact on Project execution against established technical performance, schedule and cost requirements. <Project Name> risk metrics and selected risks/opportunities will be reviewed by the Project-level Risk Review Board (RRB) on at least a monthly basis as part of on-going management activities depending on the risk level impact and time to realization.<Project Name> will manage risks and opportunities on two levels: Project level, and Partner level according to the <Project Name> Risk and Opportunity Management guidance. Project is the top level team comprised of organization, project and customer participants. Partner level organizations include suppliers of material and services subcontracted to the organization or customer in support of the project. Partner level organizations may also come from other business units within the organization who provide key support roles to the <Project Name> Project.The ROMP is intended to cover risk and opportunity management for all functions/projects/sites at the Project and Partner levels. A Partner organization (e.g. Key Supplier) may create its own ROMP, tailored from and aligned to this plan. Though full disclosure to the <Project Name> PM or RM of all risks and opportunities is strongly recommended to identify cross-cutting risks or opportunities that may affect multiple organizations, each organization may choose to keep certain risks and opportunities as Hold-Close (excluding red (high) level Project risks).To ensure the management of <Project Name> risks and opportunities supports the successful achievement of the Integrated Business Plan (IBP): ● Periodic update of the IBP includes goals for each organization and is flowed down to the

respective function/project in quantifiable terms. For <Project Name>, these goals are identified as “Business Success Criteria” as defined in the subject worksheet in the <Project Name> Contract Status Review Data Pack.

● Each organization aligns its objectives to these goals which in turn drive execution.

Page


When evaluating the appropriateness of a risk handling plan, the following considerations should be made:● The estimated cost of mitigations vs. the potential cost savings ● Contingency plans in case the risk materialize● Secondary risks<include additional risk strategies that are appropriate for the project>3.1 Roles and Responsibilities

3.1.1 Project Manager (PM)● Assign a project Risk and Opportunity Manager (Risk Manager).● Chair the R&O Review Board (RRB).● Identify R&O Review Board members● Create an environment for communication which fosters willingness among Individual

Contributors to bring possible risks/opportunities forward. ● Ensure a formal R&O review meeting is conducted on a monthly basis.● Approve proposed handling plans for identified project R&Os.● Support approved mitigation/exploitation plans by providing resource and oversight.● Report key project risks during project milestone reviews including Contract Reviews, Phase

Reviews, and Design Reviews. Ensure the ROMP state is appropriate for the life cycle phase and Risk Register reflects the project’s risk position.

● Report key project R&Os to the next level of management on a monthly basis.

3.1.2 Risk Manager (RM)● Collect candidate R&Os from stakeholders including Individual Contributors● Manage project R&Os in accordance to this Plan.● Establish and conduct monthly R&O reviews with the RRB● Maintain R&O review minutes.● Maintain this Plan as a living document.● Manage mitigation plan execution and record status.● Status risk mitigation plans progress during Project Status Reviews and report

new/closed R&Os.● Train all project personnel on Risk and Opportunity Management.● Maintain the project’s risk and opportunity database.● Generate and provide all customer risk and opportunity management deliverables. ● Plan for risk identification brainstorming sessions facilitated by Project Manager the (PM)

at least on a monthly (or more frequent, if desired) basis. ● Collect and provide R&O metrics as requested by customers, PM, or the organization.

3.1.3 Individual Contributors ● Identify risk items and report them to the PM or RM in a timely manner.● Actively participate in R&O brainstorming sessions when requested.● Execute assigned mitigation actions.

Page


3.1.4 Risk Owner● Ensure timely development of the Risk Mitigation Plan.● Manage/Execute the mitigation plan for their particular risk.● Ensure the mitigation plan is integrated with the detailed schedules and earned-value

work package.● If the Risk Owner has not been identified when the risk is reviewed at the Risk Review

Board (RRB), the Board will assign an owner.

3.1.5 Risk Review Board● Meet at least monthly to status all new candidate R&Os brought forward to the Board.● Approve project-level R&Os and mitigation/exploitation plans.● Assign a Risk Owner if one is not identified when the risk is brought forward as a

candidate.● Submit to management a request to allocate funds for risk mitigation or opportunity

realization.

4 Schedule & Deliverables The following section lists the deliverables expected from the execution of this plan. Changes to this schedule will be managed by the ROM Manager as an addendum to this plan.

Owner Deliverable Due Date

PM Designate Risk Manager for project

RM Create project ROMP

PM Approve ROMP for project or obtain approval from the Risk Management Authority (RMA) for tailored ROMP

PM, RM, Team Leads

Communicate ROMP to own organization

PM, RM, Team Leads

Conduct monthly risk review meetings from approval date of this plan onward

Project Team Manage risks and opportunities according to ROMP from approval date of this plan onward

PM Report key R&Os via R&O worksheet during Contract, Design and Phase Reviews.

from approval date of this plan onward

PM Report key R&Os to Program Director/VP on a monthly basis

from approval date of this plan onward

<role> <other milestones> <date>

Page


Note: For simplicity and flow, the term “risk” will represent both positive risk (opportunity) and negative risk (risk) from this point on. It is important to note, however, that it is our objective identify and manage both risks and opportunities, as applicable.

5 APPROACH TO RISK MANAGEMENTThe overall goal of risk management is to successfully manage the project within technical, cost, and schedule goals by reducing all project risks to low or to an acceptable level.

The following sections comprises of a set of risk management nomenclature and standards to ensure a consistent approach to risk management for this project.

5.1 Risk SourcesRisks can originate throughout the project lifecycle and possible sources of risks can come from many areas as seen in the figure below.

Figure 1 – Risk Sources

5.2 Risk Categories The risk management effort will categorize risks associated with project design, development, manufacture, and testing, such as: 1) technical; 2) cost related; 3) schedule related; and/or 4) programmatic. These categories, and the subcategories under technical risk, are provided as a guideline to allow identified risk elements to be placed in an appropriate functional risk area.

5.2.1 Technical Risks Technical risk is defined as those elements of the project that have specific performance criteria and will ultimately affect the performance of the system, including the ability to produce, test,

Page


field, and support the system. Sources of technical risk can be further classified as described in the following functional categories.

5.2.1.1 Technology Risk Technology risk can be defined as the risk associated with evolving a new design to provide a greater level of performance than previously demonstrated. Some sources of technology risk include:● A major, or greater than anticipated, state-of-the-art advance is required to meet

performance requirements.● Numerous, several areas require state-of-the art techniques and development to meet

performance requirements.● Lack of state-of-the-art advances.

5.2.1.2 Design and Engineering Risk. Design and engineering risk is associated with evolving a new design to provide the same or a lesser level of performance subject to some new constraints. Sources of risk might be:● Operating environment; the environment the system is required to perform in.● Physical properties; the dynamics, stress, or vibration physical property requirements.● Modeling; used in developing mathematical and physical predictions, testing and

retesting.● Environmental issues; how the system affects the environment.● Integration/interface; new and unique design adaptability, compatibility, interface,

standard, and interoperability requirements.● Survivability requirements for nuclear hardening, chemical survivability, etc.● Software; unique software test requirements, a new computer language, or one unfamiliar to

those responsible for planning and writing software.● Reliability; failure to properly forecast system reliability or the required reliability.● Maintainability; the desired maintainability performance with a design that is compatible

with proven maintainability procedures.

5.2.1.3 Manufacturing RiskManufacturing risk is the risk that a contractor will not be able to manufacture hardware that meets requirements within cost, schedule, and performance parameters. Some sources of manufacturing risk are; design stability, scarce resources, vendor base, capability, advance buy authorization for long lead items, and production readiness.

5.2.1.4 Support Risk Supportability risk can be defined as the risk associated with fielding and maintaining systems which are being developed and deployed, including; decisions on reliability, supportability, and readiness requirements versus the definition of the design. Infrastructure to support the system and operation and maintenance training programs, or lack thereof, are also possible sources of support risk.

5.2.2 Cost Risk Cost risk is the risk to a project of overrunning its budgeted costs. One or more of technical risks, schedule risks, and programmatic risks often play a key role in cost risk. Some of the

Page


sources of cost risk are funding levels versus project requirements, the methods used in the estimating process, or having an adequately defined project to estimate.

5.2.3 Schedule Risk Schedule risk is the risk to a project in not meeting its baseline schedule. As with cost risk, schedule risk does not always stand-alone and is often the result of other project risk areas.

5.2.4 Programmatic Risk Programmatic risks include staffing levels, facilities and equipment requirements, contractual funding and definition, and other factors that support performance to the project scope of work. Programmatic risk issues can be raised in the process of evaluating project performance to cost and schedule, through examination of the scope of work, by selection of alternative designs in trade studies, and in meetings with the customer and (project) staff.

5.2.5 Risk Ratings The objective of defining risk ratings is to provide a common framework, which can be used in assigning risk ratings to the identified risk elements. The following definitions are provided as a baseline for (project). These definitions may change as the project matures.

5.2.5.1 Low

Risk Type DescriptionTechnical - Technology No new technology necessary to meet

requirements

Technical - Design and Engineering

Analysis, simulation or testing has demonstrated a high probability of successfully meeting requirements.

Technical - Manufacturing Has little or no potential to cause a disruption of schedule, increase in cost, or degradation of system/project performance.

Technical - Support No major supportability issues exist.

Cost Cost variance is 9% or less over Budgeted Cost of Work Scheduled (BCWS) and is recoverable.

Schedule Schedule variance is 9% or less and no deliverables are affected.

Programmatic Project issues are manageable.

5.2.5.2 Moderate

Risk Type DescriptionTechnical - Technology A minor advance of current technology is

necessary to meet requirements.

Page


Risk Type DescriptionTechnical - Design and Engineering

Some subsystems; components have been developed, and analysis, simulation and testing have judged that requirements should be met.

Technical - Manufacturing Can potentially cause some disruption of schedule, increase in cost, or degradation of system/project performance.

Technical - Support Potential problems during fielding or operating.

Cost Cost variances are 10% or more over BCWS, may be recoverable or may require alternate funding options.

Schedule Schedule variances are 10% or more and may affect a contractual milestone or deliverable.

Programmatic Extraordinary effort required to recover.

5.2.5.3 High

Risk Type DescriptionTechnical - Technology The technology to meet requirements does

not exist, has not been developed, or has not been demonstrated.

Technical - Design and Engineering

Based on analysis, simulation and testing, there is a marginal likelihood that requirements can be met.

Technical - Manufacturing Likely to cause significant disruption of schedule, increase in cost, or degradation of system/project performance.

Technical - Support Likely to cause significant fielding or operating disruptions or degrade performance objectives of the system.

Cost Cost variances are 10% or more over BCWS and are not recoverable.

Schedule Schedule variances are 10% or more and will impact one or more major deliverables.

Programmatic Program resources are not available or issues are not correctable.

Page


5.3 Risk Reporting ThresholdsThe reporting of risks must take into account the appropriate thresholds set by the different management perspective. These thresholds are typically set by the next level of management for periodic reporting and/or escalation.At a minimum:

The threshold for reporting risks to the next level of management is typically any risk with mitigation and fallback costs outside the signature authority or budget level of the responsible manager.

The threshold for reporting risks in the Contract Status Review is any risk having an impact to the EAC.

The threshold for immediately reporting a risk to the VP Finance is any risk having a >50% probability of $0.5mil or greater impact to the current year Integrated Business Plan (IBP).

<add additional thresholds as applicable>

5.4 Risk ClassificationIf identified as a risk or opportunity, the submitter should assign an initial classification based on the following guidelines:● Open: There are no constraints on sharing this risk among <Project Name> Project

participants● Hold-Close: This risk is sensitive to a <Project Name> participant organization and

needs to be kept within the organization or as bounded by direction of the Risk Owner or appropriate management authority

● Competition-sensitive: The risk involves potential legal / proprietary information that must be controlled in regards to limited dissemination among competing entities

● Classified: The risk involves U.S. Government security regulations or laws. No classified risks will be maintained in written form in any open <Project Name> risk register, report, metric or other standard document, or any electronic tool that does not meet security requirements. For reference purposes, however, the risk submitter or owner shall contact the <Project Name> RM to obtain an assigned risk identification number and title so that all need-to-know inquiries will be referred to the proper POC.

As is the case for all documents generated by any individual in the Project, it is the responsibility of the document issuer and approver to mark the document in accordance with organization, Project or U.S. regulatory requirements.5.5 ProcessContinuous risk identification is planned through internal project sources and mechanisms (e.g., design and functional organizations), and from external sources (e.g., customer technical and management personnel, subcontractors, co-contractors, consultants, and suppliers). Risk management oversight will be accomplished by the Project Manager, and the project management team.

Page


5.6 Process StructureThe process structure is summarized in Figure 2.

Figure 2 – Risk Process Components

What How Description

Identify Recognize … risks and opportunities in relation to the achievement of objectives

AssessAnalyse … qualitatively, based on impact and probability, to set priorities

Evaluate … quantitatively, based on impact and probability, to determine consequences

Respond Decide …with a handling plan based on understanding of risk and available options

Manage

Implement … via control strategies and plans to invest in pre-emptive actions + recovery measures

Review and Report … Information on exposures and Mitigation status / trends, related to specific and collective Assessments.

5.6.1 IdentifyTo identify risks that could compromise and opportunities that could benefit the successful achievement of objectives.Identification involves the recognition of potential threats or beneficial conditions and their origins. They are captured as cause / effect statements, taking account of a wide range of sources/functions associated with the company’s activities.

This section defines risk identification and monitoring process for each project risk category.

Page


5.6.1.1 Technical Risk Identification In order to monitor the project for technical performance risks, the process will be to: 1) forecast the values to be achieved through the planned technical program effort of essential performance parameters; 2) identify the differences between the achieved values and those allocated to the product element by the systems engineering process; and 3) determine the impact of any differences on system effectiveness. Technical requirements may be tracked on any element of the project including, as a minimum, hardware and software design/development. Items that do not meet planned performance parameters and profiles will be identified as a risk and will be placed into the Risk Database.All safety-related hazards and risks will be tracked through the project System Safety Program. During this process, certain risks may be designated as candidates for risk management. Risk management candidate hazards with risk levels of medium and high will be forwarded for inclusion in the Risk Database.

5.6.1.2 Cost Risk IdentificationEvery month the Planning and Control team coordinates cost and schedule status performance reporting with input from Cost Account Managers (CAMs), to quantify progress to the project baseline/budget.An essential element of trade analyses (studies) when considering design alternatives is weighing the cost impact. These cost impact elements provide another means for identifying cost risk to the project.

5.6.1.3 Schedule Risk Identification A project Integrated Master Schedule (IMS) has been developed (currently in Microsoft Project software) and will be statused throughout the effort. The IMS utilizes key project and internal milestones to measure project progress on a routine basis. A Project Planning Specialist is responsible for maintaining the IMS, monitoring and reporting schedule impacts, and developing status reports.

5.6.1.4 Programmatic Risk Identification Project risks include items such as staffing levels, facilities and equipment requirements, contractual funding and definition, and other factors that support performance to the project’s scope of work. Project risk issues can be raised in the process of evaluating project performance to cost and schedule, through examination of the scope of work, by selection of alternative designs in trade studies, and in meetings with the customer and project staff.

5.6.2 AssessIs intended to gather information on the risks and opportunities and assess them against consistent criteria in order to understand and prioritize them for action.It is essential that the likely cost impact of assessed Project Risk is estimated and reflected in the cost to complete for the contract / budget concerned.

5.6.3 RespondIs intended to plan and take action for the reduction, removal, avoidance and containment of risks through Mitigation and Fallback Action Plans and to plan and implement actions for the realization of opportunities.

Page


Information from the risk assessment activities are used to prioritized and select risk handling options.

Among the four key options (transfer, accept, mitigate, avoid), the mitigate option requires a cost-effective mitigation plan.

Such a plan must be durable and must be capable of evolving with events, drawing on best practice from both inside and outside the business. Clear accountabilities, key performance indicators and time-scales for delivery of actions must be agreed and visible from the outset.

Mitigation Plan Risk mitigation planning and actions are essential to good risk management. Plans are developed by the owner, with support from the Risk Manager, and documented in the appropriate planning template. Key elements of the mitigation plan include a description, the scoring summary, contingency plans and detailed mitigation steps planned. It is expected that all mitigation steps are tied to activities in the existing work breakdown structure to ensure adequate resources are in-place to execute the plan.

5.6.4 Manage (Review, Report)To regularly review the status of risks and opportunities, analyze and monitor their impact and benefit on the overall project, approve actions, report status to project stakeholders and monitor the effectiveness of the overall process.

5.6.4.1 ReviewAs stated above, the Project shall conduct monthly project risk review as part of the risk review board meetings.In addition, the PM will attend the director monthly risk reviews to report Project key risks meeting the director’s thresholds.For Phase Reviews and Design Reviews, the ROMP and risk registers will be key review artifacts supporting the Risk Assessment and any new risk identified by the assessors shall be incorporated into the risk register before the final risk assessment can be passed.

5.6.4.2 ReportThe reporting of risks must take into account the appropriate thresholds set by the different management perspective. These thresholds are typically set by the next level of management for periodic reporting. Where risks of a highly significant nature are identified these need to be immediately notified through the line manager, where appropriate up to the relevant Director of Programs or Function, who will be responsible for deciding whether to invoke action or other notification outside of the normal reporting routines. The following model explains best practices of reporting requirements dependent on the risk and opportunity assessment.

Page


Figure 3 – Risk Reporting Model

Note: Any risk having a >50% probability of >=$.5mil impact to the current year IBP must be immediately escalated to the VP of Finance.5.6.4.2.1 Formal Reporting PeriodsProject R&O’s related to Estimate-at-Completion (EAC) will be included in the Contract Review data pack and reviewed at all bid, phase, contract and design reviews. The Project Manager is expected to mange R&Os as part of day to day activities with monthly formal R&O reviews. Key Project R&Os will also be reported to the Program Director on a monthly basis.

5.6.4.2.2 R&O Report FormatThe project will maintain an R&O database using an Excel spreadsheet or database. In addition, the project is often required to follow the report format prescribed by management or the customer.

5.6.4.2.3 R&O DatabaseThis section identifies responsibilities, database field requirements. Note that the term risk register and risk database is used interchangeably to indicate the source risk repository. Analysis of identified risk elements for project impact is the responsibility of the project management team, consisting of the Project Manager, the Project Manager, the Planning Specialist, and the Core Team. Identified risks will be analyzed, classified, prioritized, and continuously tracked through a risk management database maintained in Excel or Access (or other tools). Table 1 presents the data elements to be captured in the risk register or risk management database.

Page


Table 1 - Risk Database Fields and Descriptions(The project’s Risk Database field names might differ as long as they match in contents with these fields, and a “mapping” is provided.)

Field Name DescriptionRisk ID Unique risk identification number

ID Date Date risk was identified

Risk Description Concise description of the identified risk to include the risk condition, cause and effect by using either of the following formats:If ... <risk/opportunity condition> due to... <cause> then… <impact / consequence>.-or-There is a risk/opportunity that… <uncertain event> caused by… <cause> will result in…<project impact >.

Risk Probability Probability of occurrence of the risk in terms of High, Medium or Low. This value will be based on professional judgment and experience, in other words, most of the time it is an educated guess. These values will likely change over time as the risk is actively managed. Note that a risk cannot have a probability of 0% because that would mean the impact of the risk could never materialize, which would by definition mean it is not a risk.

Reputation Impact Impact of the risk in terms of the reputation of the organization. Refer to the risk register Scoring worksheet for the current guideline.

Estimated Financial Impact

This attribute comprises of three components: 1) the impact of the risk in terms of Cash, Profit or both 2) the estimated dollar amount and 3) the impact period.In the project domain, this impact is typically measured in terms of the project’s cost targets.Also consider potential financial impact on the IBP and over which years.When deriving the impact take in to consideration any mitigation actions already completed & any contingency already accounted for.

Financial Impact Rating

This is a High, Low, Medium value based on the scoring criteria defined for this project. This could be defined within the ROMP or in the risk register scoring worksheet.

Risk Score The risk score is an automatic calculation based on the previously discussed probability and impact. Do nothing with this field.

Risk Categorization The risk categorization is an automatic calculation based on the previously discussed inputs. Do nothing with this field.

Handling Plan Indicate the current handling plan. Options include Mitigate, Accept, Transfer, Avoid

Mitigation Actions This is to contain what plans of action are being undertaken to reduce or eliminate the chance of the risk occurring. In considering the cost-effectiveness of mitigation plans, make sure estimated costs of mitigation is documented somewhere for future review against the cost impact of the risk itself.

Target Date Enter here the target completion date for each mitigation action.

Status of Mitigation Here is where the status of the mitigation actions are entered such that:

Page


Field Name DescriptionRed - date for completion or cost targets unlikely to be met.Amber - date for completion or costs targets may not be achieved.Green - mitigation action plans on schedule and to budget.

Risk Owner This person is responsible for overall management of each specific risk.

Current Status Describe current status of mitigation actions including tasks completed vs outstanding and any change in probability or impact

Basis of Estimate Describe basis of estimate for the risk impact amount. Even with expert judgment, identify the cost components used to show how estimate was derived, including assumptions.

Fallback Plan Describe the recovery actions to be taken should part or all of this risk materializes. Include trigger event/date as appropriate.

Estimated Mitigation/Fallback Costs

Estimated costs associated with mitigation actions and fallback plans.These costs are used in cost/benefit analysis to ensure handling plan is cost-effective and also used in budget/baseline planning

Funded? Indicate if and how will the action plan be funded

Closure Rationale Reason supporting closure decision.

6 ROM MEASURESTo measure the effectiveness of the ROM practices, the following metrics have been established:1. Percentage of mitigation plans successfully executed

7 DEFINITIONS OF TERMSAnalysisThe (qualitative) component of the process in which Identified material is considered against consistent criteria to determine its importance, possible effects, and appropriate management strategies.AssessThe term used to refer to the Analysis and Evaluation process components which respectively comprise qualitative and quantitative assessments.ContingencyFunds identified for possible expenditure if risk materializes.Definition ScaleDefinitions of impact and probability ranges produced by the Project or organization, against which each Risk/Opportunity is analyzed.EvaluationThe (quantitative) component of the process in which effects are evaluated to generate action priorities and models of their collective time, cost, performance and business consequences on meeting objectives or satisfying requirements.

Page


ExposureA judgment of the overall financial implications if identified risks materialize.Exposure ValueA judgment of the (post-mitigation) contingency required for an individual risk. Contingency PlanSometimes referred to as “fallback plan”, is an alternative strategy for the achievement of an objective that requires funding to be released from Contingency. Contingency plans are required in case a risk is unresponsive to pre-emptive mitigation, or if a risk occurs.IdentificationThe component of the risk and opportunity management process in which all areas of concern / promise are captured and recorded.ImpactThe measurement of a risk effect, expressed quantitatively.Impact ValueA judgment of the financial cost (or benefit) to the business or project should a given risk (or opportunity) materialize. It may be the cost of recovering from or absorbing a Risk/Opportunity effect. (Also referred to as Recovery Cost, with reference to risk.) MitigationThe component of the process which involves the devising and implementation of effective plans and actions to reduce risk, to ensure business or project commitments are met. It requires that decisions are made to invest in preemptively reducing, transferring or protecting against risks, and to deal with any risk occurrences. Action plans are formulated and followed as required, recognizing that secondary risks may thus be generated. ExploitationThe component of the process which involves the devising and implementation of effective plans and actions to promote opportunity, to ensure business or project commitments are met and opportunities are realized.Mitigation (Exploitation) PlanAn action plan designed to preemptively influence Risk and/or Opportunity outcomes.OpportunityAn event or series of events with a probability of occurrence which, on occurring, would offer benefit to business or project objectives.Probability of OccurrenceA judgment of the chance that an Identified risk or opportunity will materialize. (Probability may be measured and presented in bands (e.g. High, Medium, Low) or as a percentage (20%, 60% etc.) or as a decimal (0.2, 0.6 etc.).)Program/ProjectThe term program/project may be used interchangeably to identify a project or group of projects.Recovery CostA judgment of the financial cost to the business or project should a given risk materialize. It may be the cost of recovering from or absorbing the risk. (Also referred to as Impact Value.)ReportingThe component of the process that links Identification, Analysis, Evaluation and Mitigation, in which current and historical data is collated on all risk and opportunity attributes and

Page


implications, their status and the resultant Exposure position. A range of report styles is produced to inform stakeholders and to support review activities.RiskAn event or a series of events with a probability of occurrence which, on occurring, would damage a business or project objective.Risk & Opportunity ManagementRisk and Opportunity Management is the means by which the consequences of uncertainty associated with a business or project are dealt with. It is a continuous and structured activity throughout the Lifecycle, recognizing and reacting to conditions that could be detrimental or beneficial to the achievement of the project’s or business’ success.Risk & Opportunity Management PlanA document defining the philosophy, strategy and method of managing risks and opportunities.Risk & Opportunity Register (ROM Register)A detailed record of all risks and opportunities Identified, Analyzed and Evaluated, their status, including a current view of the effect of committed Mitigation (Exploitation) and Contingency Actions.Also referred to as the ROM Database or Risk Register, the ROM Register may be in any database or spreadsheet format as long as it contains the required data fields per the Risk and Opportunity Register template (reference Risk and Opportunity Register form).

Risk / Opportunity OwnerThe individual or organization that will experience the pain or gain associated with a risk or opportunity occurrence, and is thereby the sponsor of Mitigation (Exploitation) or Contingency Actions.Secondary RiskA Risk associated with a Contingency Plan.StakeholderAny individual or organization who stands to gain or lose (either directly or indirectly) as a consequence of the business’s or a project's performance, and thereby has an interest in risk and opportunity outcomes.

Page


APPENDIX A. RISK ASSESSMENT Tables (Sample)

Probability of Occurrence Assessment Table

LOW MINOR MODERATE SIGNIFICANT HIGH

Probability of Occurrence

Very unlikely to occur

Will be rarely observed when the system is in use

Less than 15% probability of occurrence

Unlikely to occur Will be observed

occasionally when the system is in use

15%-40% probability of occurrence

As likely as unlikely to occur

Will be observed roughly half the time the system is in use


Likely to occur Will be observed

on most occasions the system is in use


Very likely to occur

Will be observed almost every time the system is used

Greater than 85% probability of occurrence

Impact of Occurrence Assessment Table


Performance Any other effect

Operator inconvenience or annoyance

Adversely affects the accomplishment of an operational or mission essential capability—but a workaround is known

Adversely affects the accomplishment of an operational or mission essential capability—no workaround known

Prevents the accomplishment of an operation or mission essential capability

Performance impact which violates system (contract) specifications should be assessed at least “Significant”

Schedule Virtually no impact on subsystem schedule

No impact to subsystem critical path

Impacts the subsystem non-critical path by 0-3 months and/or impacts the subsystem critical path by 0-1 mos.

1-2 month impact to subsystem critical path and/or 0-1 mos. impact to system critical path

Greater than 1 month impact to system critical path

Page 17



Cost Virtually no cost impact to the cost account

Impact handled within cost account

Impact exceeds cost account but can be handled within project budgets

Requires allocation of management reserve to cover impact

Exceeds management reserve available

Page 18


APPENDIX B. OPPORTUNITY ASSESSMENT TABLES (Sample)

Probability of Occurrence Assessment Table

Numerical Probability Essence Probability

80%-95% There is a high probability (greater than four out of five) that the opportunity can be realized.

High

60%-80% There is better than 50-50, but less than high, probability the opportunity can be realized.

Significant

40%-60% There is roughly a 50-50 probability the opportunity can be realized.

Moderate

20%-40% There is less than 50-50, but better than low, probably the opportunity can be realized.

Minor

5%-20% There is a low probability (less than one out of five) that the opportunity can be realized.

Low

Impact of Realization Assessment Table

Impact Range IMPACT> $50K High

$10M-$25K Significant$5K-$10K Moderate$2K-$5K Minor

< $2K Low

Page 19

Documents

2013fall2gm600.files.wordpress.com€¦ · Web viewIn order to monitor the project for technical performance risks, the process will be to: 1) forecast the values to be achieved