Unit 3 Project Management Process Areas

1
Unit 3Project Management Process Areas
2
Project Management PAs

• Project management process areas cover the
  activities related to planning, monitoring and
  controlling the project.
• They are
• Project Planning PP
• Project Monitoring and Control PMC
• Supplier Agreement Management SAM
• Integrated Project Management for IPPD IPM/IPPD
• Risk Management RSKM
• Integrated Teaming IT
• Integrated Supplier Management ISM
• Quantitative Project Management QPM

3
Project Planning PP

• Purpose Establish and maintain plans that define
  project activities.
• SG1 Establish Estimates
• Estimates of project planning parameters are
  established and maintained
• SG2 Develop a Project Plan
• A project plan is established and maintained as
  the basis for managing the project.
• SG3 Obtain commitment to the Plan
• Commitments to the project plan are established
  and maintained.

4
SG1 Establish EstimatesEstimates of project
planning parameters are established and maintained
Requirements Definition

• SP 1.1-1 Estimate the scope of the project
• Establish a top level work breakdown structure
  (WBS) to estimate the scope of the project
• The WBS divides the overall project into a set of
  interconnected components. This provides a scheme
  for organising the logical units of work to be
  managed (Work Packages) to be used as the basis
  for assigning effort, schedule and
  responsibility. The WBS should allow risks to be
  identified and mitigated. Work products or their
  components that will be acquired externally can
  be identified as are those that can be reused.

5
SG1 Establish EstimatesEstimates of project
planning parameters are established and maintained

• SP1.2-1 Establish Estimates of Work Product and
  Task Attributes
• Establish and maintain estimates of the
  attributes of the work products and tasks.
• Size and complexity are the main parameters for
  estimating effort, cost and schedule. These might
  include LOC or Function Points in software or
  expected cyclomatic complexity. Also factors such
  as the organisations familiarity with the
  requirements (relates to complexity) and
  understanding of the technology base are issues.
  In fact determining a high level technical
  approach for the project is an important
  sub-practice here because this is essential for
  appreciating complexity.
• An example of a work product might be a software
  module and attributes of a software module might
  be LOC and complexity.
• An example of a task might be maintenance and
  attributes of the maintenance task might be
  programmer familiarity with the problem space.

6
SG1 Establish EstimatesEstimates of project
planning parameters are established and maintained
Technical Solution PA

• SP1.3-1 Define Project Life-Cycle
• Define the project life-cycle phases upon which
  to scope the planning effort
• Any project needs planned periods of evaluation
  and decision making. These are now defined so
  that logical decision points are identified where
  significant commitments of resources can be made
  and project course corrections determined.
• For a software project this might be selection
  and refinement of a software development model to
  address sequencing of software project
  activities. (This is not the same as determining
  the high level technical approach mentioned in
  SP1.2-1)
• An example of a Life Cycle for software might be
  Spiral model version of SSADM

7
SG1 Establish EstimatesEstimates of project
planning parameters are established and maintained

• SP1.4-1 Determine estimates of effort and cost
• Estimate the project effort and cost for the work
  products and tasks based on estimation rationale
• Estimates of effort and cost should be based on
  analysis of historical data. For example, taking
  the software module mentioned earlier, we might
  have LOC and Cyclomatic complexity as our
  established work product estimates we must now
  use our historical data to estimate the effort
  required by us to create this module.
• Of course it is not always the case that we have
  accurate historical data this will increase
  risk.
• For example, we may have to maintain this module
  of software but our programmers have little
  familiarity with the problem space (no history)
  therefore making effort and cost predictions for
  this task difficult.

8
SG2 Develop a Project PlanA project plan is
established and maintained as the basis for
managing the project

• SP2.1-1 Establish the Budget and Schedule
• Establish and maintain the projects budget and
  schedule
• The budget and schedule are based on the
  determined estimates.
• Subpractices include identifying milestones,
  schedule assumptions (for example, the
  maintenance task defined earlier may have a four
  week schedule but there may be a low confidence
  in this due to the lack of historical data),
  constraints (for example we might be constrained
  in our maintenance task with limited options for
  actually performing this work), task dependencies
  (optimal ordering is important through he use of
  Critical Path Analysis or Program Evaluation and
  Review Technique), budget and schedule with
  corrective action criteria.

9
SG2 Develop a Project PlanA project plan is
established and maintained as the basis for
managing the project
Risk Management PA

• SP2.2-1 Identify Project Risks
• Identify and analyse project risks.
• Identifying risks involves the identification of
  potential issues, hazard, threats etc that could
  negatively affect work efforts and plans. The use
  of Risk Taxonomies, Checklists, Brainstorming,
  Quality Factor Analysis are all ways of
  identifying and analysing risks. The results
  should be agreed upon by relevant stakeholders
  before being carefully documented.

10
SG2 Develop a Project PlanA project plan is
established and maintained as the basis for
managing the project

• SP2.3-1 Plan for Data Management
• Plan for the management of project data
• The data to support a project in all its areas
  (administration, technical, financial, quality,
  safety etc) may take any form (reports, manuals.
  specifications, files etc) and may exist in any
  medium.
• Once the project data to be collected and
  distributed has been determined, mechanism to
  archive and access data might be established and
  indeed procedures for the privacy and security of
  such data.

11
SG2 Develop a Project PlanA project plan is
established and maintained as the basis for
managing the project

• SP2.4-1 Plan for Project Resources
• Plan for necessary resources to perform the
  project
• Defining project resources and determining
  quantities needed builds on the initial
  estimates.
• The determination and acquisition of assets in a
  timely manner is crucial for project success.

12
SG2 Develop a Project PlanA project plan is
established and maintained as the basis for
managing the project

• SP2.5-1 Plan for Needed Knowledge and Skills
• Plan for knowledge and skills needed to perform
  the project.
• Assess the knowledge and skills available to the
  project after understanding the knowledge and
  skills needed by the project. Decide on the
  mechanisms to be used to plug the gaps (new hire,
  training etc).
• These mechanisms must be incorporated into the
  project plan so that they can be scheduled and
  resourced.

13
SG2 Develop a Project PlanA project plan is
established and maintained as the basis for
managing the project

• SP2.6-1 Plan Stakeholder Involvement
• Plan the involvement of identified stakeholders.
• Stakeholders are identified by examining the type
  of functions and people who need to be
  represented in the project. A rationale for
  involvement and their respective roles and degree
  and type of interaction might be planned

14
SG2 Develop a Project PlanA project plan is
established and maintained as the basis for
managing the project
PMC

• SP2.7-1 Establish the Project Plan
• Establish and maintain the overall project plan
  content
• A documented plan that addresses all necessary
  planning items is necessary to achieve the mutual
  understanding, commitment and performance of
  stakeholders and organisations which must support
  the plan.

15
SG3 Obtain Commitment to the PlanCommitments to
the project plan are established and maintained

• SP3.1-1 Review Plans that Affect the Project
• Review all plans that affect the project to
  understand project commitments
• As there is a plan the process generic practice,
  it is reasonable that other Pas will have their
  own plans containing similar information to that
  in the overall project plan. The additional
  detailed guidance contained in these should be
  checked for compatibility with the overall plan.

16
SG3 Obtain Commitment to the PlanCommitments to
the project plan are established and maintained

• SP3.2-1 Reconcile Work and Resource Levels
• Reconcile the project plan to reflect available
  and estimated resources.
• It is important to reconcile differences in
  estimated and actual resources by lowering
  requirements, negotiating further resources,
  changing the schedule etc. If not reconciled this
  could be a serious obstacle to obtaining
  commitment.

17
SG3 Obtain Commitment to the PlanCommitments to
the project plan are established and maintained

• SP3.3-1 Obtain Plan Commitment
• Obtain commitment from relevant stakeholders
  responsible for performing and supporting plan
  execution.
• Commitments should be negotiated with
  stakeholders and commitments both full and
  provisional (sometimes necessary before full
  commitment can be given) should be documented and
  signed.
• Internal and external commitments might be
  reviewed with senior management
• Well defined interface specifications should form
  the basis of commitments.

18
PP Generic Goals
19
GG2 Institutionalise a Managed ProcessThe
process is institutionalised as a managed process

• GP2.1 Establish an Organisational Policy
• Establish and maintain an organisational policy
  for planning and performing the project planning
  process.
• This policy sets expectations in the organisation
  for any project plan devised within the
  organisation
• GP2.2 Plan the Process
• Establish and maintain the plan for performing
  the project planning process
• This plan relates to the planning for all the
  specific practices within the PPPA. i.e. In a
  sense you are required to plan the plan in
  contrast to the project plan which relates to the
  project effort itself. (The SPs need to be
  scheduled and staffed).

20
GG2 Institutionalise a Managed ProcessThe
process is institutionalised as a managed process

• GP2.3 Provide Resources
• Provide adequate resources for performing the
  project planning process, developing the work
  products, and providing the services of the
  process.
• Special expertise may be required such as that
  provided by experiences estimators. Project
  planning and scheduling tools may be required.
• GP2.4 Assign Responsibility
• Assign responsibility and authority for
  performing the process, developing the work
  products and providing the services of the
  project planning process
• People need to be made responsible for example
  the creation and writing of the overall project
  plan and for other work products such as a
  stakeholder/function matrix (which might be used
  in SP2.6-1)

21
GG2 Institutionalise a Managed ProcessThe
process is institutionalised as a managed process
GP 2.5 Train People Train the people performing
or supporting the project management process as
needed. GP 2.6 Manage Configurations Place
designated work products of the project planning
process under appropriate levels of configuration
management. Examples of PP related work products
include the WBS, the Stakeholder involvement plan
and the Project Plan itself. GP 2.7 Identify and
Involve Relevant Stakeholders Identify and
involve the relevant stakeholders of the project
planning process as planned This GP is different
from SP 2.6-1. This GP relates to the
identification and involvement of all those
groups and functions which pertain to Project
Planning. SP-2.6-1 relates to stakeholders
pertaining to the overall project itself. A
programming group may be a stakeholder in the
overall project but may not be a stakeholder in
relation to the project plan process
22
GG2 Institutionalise a Managed ProcessThe
process is institutionalised as a managed process
GP 2.8 Monitor and Control the Process Monitor
and control the project planning process against
the plan for performing the process and take
appropriate corrective action. GP 2.9
Objectively Evaluate Adherence Objectively
evaluate adherence of the project planning
process against its process description,
standards and procedures and address
noncompliance Examples of activities reviewed
include establishing estimates and obtaining
commitment to plans. Work products of the process
such as WBS and the Stakeholder Involvement Plan
may also be evaluated for compliance to
standards. GP 2.10 Review Status with Higher
Level Management Review the activities, status
and results of the project planning process with
higher level management and resolve issues.
23
GP3 Institutionalise a Defined ProcessThe
process is institutionalised as a defined process

• GP3.1 Establish a Defined Process
• Establish and maintain the description of a
  defined project planning process.
• The point at which a managed process becomes
  defined is where it is an integral process, well
  understood and used by people across the
  organisation as appropriate. If a common PP
  process were used and understood across the many
  projects undertaken then it might well be
  institutionalised,
• GP3.2 Collect Improvement Information
• Collect work products, measures, measurement
  results and improvement information derived from
  planning and performing the project planning
  process to support the future use and improvement
  of the organisations processes and process
  assets.
• As PP is now a defined process we need to capture
  information from the use of this process which
  may have an impact on other processes. Good
  practice in a sense which must be shared with
  other process assets. Further, measures that
  could be collected in relation to PP may have a
  direct impact on improving PP

24
GG 4 Institutionalise a Quantitatively Managed
ProcessThe process is institutionalised as a
quantitatively managed process

• GP 4.1 Establish Quantitative Objectives for the
  Process
• Establish and maintain quantitative objectives
  for the project planning process that address
  quality and process performance based on customer
  needs and business objectives.
• We may have collected improvement information and
  act on it to improve the process assets and PP
  but here we need to specify quantitative
  objectives for PP, For example, the gap between
  estimated resources for a project and the actual
  resources consumed may be a measure that we take
  as for GP3.2. An organisation may have been
  alarmed at this and indeed taken action to
  address the problem by using different estimation
  techniques. However, in GP4.1 the organisation
  might well have defined a statistical objective
  such that there should be no more than a 10
  difference between the estimate and actual
  figures. In GP3.2 the company knew there was an
  issue that had to addressed but this is different
  from knowing quantitatively what is reasonable to
  target.

25
GG 4 Institutionalise a Quantitatively Managed
ProcessThe process is institutionalised as a
quantitatively managed process

• GP 4.2 Stabilize Subprocess Performance
• Stabilize the performance of one or more
  subprocesses to determine the ability of the
  project planning process to achieve the
  established quantitative quality and process
  performance objectives.
• An organisation must be confident that the target
  quantitative objectives are reasonable and
  realistic given the existing PP. GP 4.2 is really
  about stabilizing subprocesses so that tests can
  be made of the process. For example, using the
  gap between estimated and actual resources used.
  An agreed approach for this calculation may be
  introduced and stabilized to test if it
  continually produces a gap of 10 or less on most
  occasions.

26
Understanding GG4

• Apply the principles of statistical process
  control
• address special causes of process variation

Identify the problem in the process
Control Chart With Special Causes
27
GG 5 Institutionalize an Optimizing Process

• GP 5.1 Ensure Continuous Process Improvement
• Ensure continuous process improvement of the
  project planning process in fulfilling the
  relevant business objectives of the organisation
• There are now quantitative objectives for the PP
  process. Effort must be made to seek out
  continually, ways of improving on these process
  objectives. Taking the 10 gap measure it may be
  that the organisation maintains an improvement
  goal of reducing this gap every year for the next
  five years,
• GP 5.2 Correct Root Causes of Problems
• Identify and correct the root causes of defects
  and other problems in the project planning
  process
• The organisation is not content with the odd
  problem in the process as depicted in the
  previous slide. The company seeks to remedy the
  root cause of such unusual problems

28
Understanding GG5

• Identify and eliminate chronic causes of poor
  performance

Control Chart With Common Causes
Original zone of
quality control
Chronic waste
New zone of
quality control
Continuously improve the software process
29
Project Monitoring and Control PMC

• Purpose To provide an understanding of the
  projects progress so that appropriate corrective
  actions can be taken when the projects
  performance deviates significantly from the plan
• SG1 Monitor Project against Plan
• Actual performance and progress of the project
  are monitored against the project plan
• SG2 Manage Corrective Action to Closure
• Corrective actions are managed to closure when
  the projects performance or results deviate
  significantly from the plan.

30
SG1Monitor Project against PlanActual
performance and progress of the project are
monitored against the project plan
PP

• SP 1.1-1 Monitor Project Planning
  ParametersMonitor the actual values of the
  project planning parameters against the project
  plan
• Periodically measure the actual completion of
  activities and milestones against the schedule in
  the project plan. Measure also the effort and
  cost expended and resources used. Monitor the
  attributes of the work products and tasks (for
  example LOC/complexity). Monitor training,
  assessing the knowledge and skills acquired.
• In all cases seek to compare actual with planned!
  Document significant deviations in the project
  planning parameters

31
SG1Monitor Project against PlanActual
performance and progress of the project are
monitored against the project plan

• SP 1.2-1 Monitor Commitments
• Monitor commitments against those identified in
  the project plan.
• Periodically review both internal and external
  commitments identifying those which are at risk
  of not being satisfied.
• SP 1.3-1 Monitor Project Risks
• Monitor risks against those identified in the
  project
• Communicate risk status to stakeholders
• SP 1.4-1 Monitor Data Management
• Monitor the management of project data against
  the project plan
• For example check regularly that privacy and
  security standards are not being breeched

RSKM
32
SG1Monitor Project against PlanActual
performance and progress of the project are
monitored against the project plan

• SP 1.5-1 Monitor Stakeholder Involvement
• Monitor stakeholder involvement against the
  project plan
• The planned interactions must be occurring.
• SP 1.6-1 Conduct Progress Reviews
• Periodically review the projects progress,
  performance and issues.
• Communicate status of assigned activities and
  work products to stakeholders. Review the results
  of collected measures (SP1.1-1).
• Negotiate and track any change requests to the
  project plan.
• SP1.7-1 Conduct Milestone Reviews
• Review the accomplishments and results of the
  project at selected project milestones
• These are typically formal reviews planned during
  project planning and involve discussing all
  project issues up to the milestone

33
SG2 Manage Corrective Action to
ClosureCorrective actions are managed to closure
when the projects performance or results deviate
significantly from the plan.

• SP 2.1-1 Analyse Issues
• Collect and analyse the issues and determine the
  corrective actions necessary to address the
  issue.
• Issues are collected from the reviews and
  execution of other processes. These might
  include, commitments that have faultered, risks
  that have increased, security issues, stakeholder
  representation issues etc. Corrective action on
  all issues needs to be determined. (Corrective
  action criteria should be part of the project
  plan).
• SP 2.2-1 Take corrective action
• Take corrective action on identified issues.
• Obtain agreement on the actions to be taken with
  stakeholders and negotiate any changes to
  commitments
• SP 2.3-1 Manage Corrective Action
• Manage corrective action to closure
• Monitor and then analyse results of corrective
  actions. Correct any deviations from expected
  results.

34
Supplier Agreement Management SAM

• Purpose To manage the acquisition of products
  from suppliers for which there exists a formal
  agreement
• SG1 Establish Supplier Agreement
• Agreements with the suppliers are established and
  maintained
• SG2 Satisfy Supplier Agreements
• Agreements with the suppliers are satisfied by
  both the project and the supplier

35
SG1 Establish Supplier AgreementAgreements with
the suppliers are established and maintained

• SP 1.1-1 Determine Acquisition Type
• Determine the type of acquisition for each
  product or product component to be acquired
• Many different types of acquisition can be used
  to acquire products (contractual agreements,
  through in-house vendors, purchasing COTS
  products etc).
• SP 1.2-1 Select Suppliers
• Select suppliers based on an evaluation of their
  ability to meet the specified requirements and
  established criteria.
• The subpractices are to document criteria for
  evaluation of supplier, identify and issue
  requirements, evaluate supplier proposals,
  evaluate the risks for each supplier, evaluate
  capability (Interestingly, many organisations
  specify that a supplier of bespoke systems must
  be CMMI assessed and be at a particular level of
  capability in software development before they
  can be a suppler of software) then select the
  supplier

Decision Analysis and Resolution
36
SG1 Establish Supplier AgreementAgreements with
the suppliers are established and maintained

• SP 1.3-1 Establish Supplier Agreements
• Establish and maintain formal agreements with the
  supplier
• What the project will provide the supplier should
  be documented and understood by both parties. The
  agreement should include a statement of work, a
  specification, terms and conditions, a list of
  deliverables, a schedule, a budget and a defined
  acceptance process.

Requirements Development
37
SG2 Satisfy Supplier AgreementsAgreements with
the suppliers are satisfied by both the project
and the supplier

• SP 2.1-1 Review COTS Products
• Review candidate COTS products to ensure they
  satisfy the specified requirements that are
  covered under the supplier agreement
• Similar to SP1.2-1 but in this case it is COTS
  products that are desired and so some
  subpractices might differ slightly (for example
  those concerning support for the product.
• SP 2.2-1 Execute the Supplier Agreement
• Perform activities with the supplier as specified
  in the supplier agreement.
• Monitor supplier progress and performance.
  Conduct technical and managerial reviews with the
  supplier
• SP 2.3-1 Accept the Acquired Product
• Ensure that the supplier agreement is satisfied
  before accepting the acquired product.
• Verify that the products satisfy their
  requirements and that all non-technical
  commitments have been met. Discuss and create
  action plan for products which fail test.
• SP 2.4-1 Transition Products
• Transition the acquired products from the
  supplier to the project
• Ensure that the products are received, stored,
  used and maintained according to the terms and
  conditions specified in the supplier agreement
  and that all concerned with the products receive
  the appropriate training as necessary, in a
  timely manner

PMC
Verification
Product Integration
38
Basic Project Management Process Areas
Component Requirements Acceptance Reviews
Engineering and Support Process Areas
SAM
What to Build
What to do
Corrective actions
Reviews
Commitments
Plans
PP
What to monitor
PMC
Need for replanning
39
Risk Management RSKM

• Purpose To identify potential problems before
  they occur, so that risk-handling activities may
  be planned and invoked as needed across the life
  of the product or project to mitigate adverse
  impacts on achieving objectives
• SG1 Prepare for Risk Management
• Preparation for risk management is conducted
• SG2 Identify and Analyse Risks
• Risks are identified and analysed to determine
  their relative importance
• SG3 Mitigate Risks
• Risks are handled and mitigated, where
  appropriate, to reduce adverse impacts on
  achieving objectives

40
SG1 Prepare for Risk ManagementPreparation for
risk management is conducted

• SP 1.1-1 Determine Risk Sources and Categories
• Risk sources (areas where risks originate), both
  internal and external to the project are
  identified. Possible sources include uncertain
  requirements, inadequate staffing, cost or
  funding issues, inadequate subcontractor
  capability etc. Categorisation is used as a means
  of collecting and organising risks and management
  attention can be drawn to categories of risk
  which represent the most significant threats to
  the project.
• SP1.2-1 Define Risk Parameters
• Define the parameters used to control the risk
  management effort
• Parameters might include risk consequence and
  threshold to trigger management activities. For
  example, a code complexity metric might exceed
  the expected complexity by 20 or more thereby
  triggering senior programming management
  attention.

41
SG1 Prepare for Risk ManagementPreparation for
risk management is conducted

• SP1.3-1 Establish a Risk Management Strategy
• Establish and Maintain the strategy to be used
  for risk management
• The risk management strategy is often documented
  in an organisational plan and will address items
  such as the scope of the risk management effort,
  methods and tools to be used for risk
  identification, monitoring, communication and
  mitigation. Risk measures may be defined to
  monitor the status of risks (for example, the 20
  threshold on the complexity of software mentioned
  earlier might be identified in the strategy).
  Mitigation strategies might include prototyping,
  simulation, alternative designs, use of design
  patterns etc.

42
SG2 Identify and Analyse RisksRisks are
identified and analysed to determine their
relative importance

• SP 2.1-1 Identify Risks
• Identify and document risks.
• Risks must be identified and described in an
  understandable way in order that they can be
  analysed and managed. The context, conditions and
  consequence of each identified risk should be
  noted. The categories and parameters developed in
  the risk management strategy along with the
  identified sources of risk are the precursor to
  effective risk identification. The list of risks
  should be reviewed periodically as conditions may
  change. Methods for identifying risks include,
  interviewing experts, examining lessons learned
  from other projects, using a tried and tested
  risk taxonomy.

43
SG2 Identify and Analyse RisksRisks are
identified and analysed to determine their
relative importance

• SP2.2-1 Evaluate, Categorise and Prioritise Risks
• Evaluate and categorise each identified risk
  using the defined risk categories and parameters
  and determine its relative priority.
• Collectively, the activities of risk evaluation,
  categorisation and prioritisation are sometimes
  called risk assessment or risk analysis.
• Each risk should be evaluated and assigned values
  according to the defined risk parameters which
  may include thresholds and consequences which can
  be aggregated to assess risk exposure. For
  example, a particular risk source might be
  uncertain requirements (the categorisation
  mechanism employed might be the stages of the
  life-cycle so this source lies in the RCA stage).
  A threshold for this category of risk might be
  created on the basis of prior experience of
  creating systems incorporating the requirement.
  When a particular uncertain requirement is
  identified by a requirements review panel it
  might be noted that this is a high risk because
  it exceeds its threshold on the basis that it is
  a requirement for which the organisation has no
  previous experience. The consequences of this
  risk are classified as critical because it
  impacts on cost, schedule and performance in a
  very significant way. Hence it is assigned a very
  high priority and flagged to senior management.

44
SG3 Mitigate RisksRisks are handled and
mitigated, where appropriate, to reduce adverse
impacts on achieving objectives

• SP 3.1-1 Develop Risk Mitigation Plans
• Develop a risk mitigation plan for the most
  important risks to the project as defined in the
  risk management strategy.
• Alternative courses of action need to be planned
  for each critical risk. The plan needs to
  consider the methods used to avoid, reduce and
  control the probability of occurrence of the
  risk. When risks exceed the established threshold
  it is the mitigation plans that are deployed. For
  risks which cannot be mitigated a contingency
  plan might be created. Both risk and contingency
  plans are generated only for risks with the most
  severe consequences. Others are simply monitored
  and mitigated on the fly.
• For reduce the likelihood of uncertain
  requirements presenting a problem, prototyping
  and simulation might be used. If a particular
  uncertain requirement exceeds its threshold there
  may be several course of action depending on the
  when the issue was discovered. One such action
  might be to assign a small team of senior
  analysts to carry out further investigation in
  order to improve the overall understanding of the
  requirement for the project. Another alternative
  might be to renegotiate the requirement with the
  customer.
• The mitigation plan should also consider the
  cost/benefit ratios for alternative solutions and
  identify groups responsible foe addressing each
  risk.

45
SG3 Mitigate RisksRisks are handled and
mitigated, where appropriate, to reduce adverse
impacts on achieving objectives

• SP 3.2-1 Implement Risk Mitigation Plans
• Monitor the status of each risk periodically and
  implement the risk mitigation plan as appropriate
• Proactively monitor risks and the status and
  results of risk handling actions. When a risk is
  identified it should be checked against its
  threshold and if necessary the mitigation plan
  should be implemented. After implementation of
  the plan the risk should be monitored to closure.
  A schedule for performance of each risk handling
  activity is needed and sufficient resources
  committed for successful completion of the
  activity.

PMC