Program and Project Management Process
1
Management Approach............................................................................................................ 3
1.1
2
3
4
5
Introduction ...................................................................................................................... 3
Time, Cost, and Scope Management ....................................................................................... 4
2.1
EVM ................................................................................................................................. 7
2.2
Variance Analysis ............................................................................................................ 6
Quality Management ............................................................................................................... 7
3.1
Quality Management Plan ................................................................................................ 7
3.2
Quality Assurance ............................................................................................................ 7
3.3
Quality Control ................................................................................................................. 7
HR Management ...................................................................................................................... 7
4.1
HR Plan ............................................................................................................................ 7
4.2
Acquire Project Team....................................................................................................... 7
4.3
Training Plan .................................................................................................................... 7
4.4
Project Team Performance Management ......................................................................... 7
Communications Management ................................................................................................ 7
5.1
Communications Plan ...................................................................................................... 7
5.1.1
Status Reporting ........................................................................................................ 7
5.1.2
Performance Reporting ............................................................................................. 7
5.1.3
Escalation Process ..................................................................................................... 7
5.2
Stakeholder Management ................................................................................................. 7
6
Procurement Management ...................................................................................................... 7
7
Risk Management ................................................................................................................... 8
7.1.1
Establish the Context ................................................................................................ 8
7.1.2
Identify Risks ............................................................................................................ 8
7.1.3
Quantify Risk Impact ................................................................................................ 9
© 2010 J.W. Mayo Consulting, LLC
Page 1 of 12
Program and Project Management Process
7.1.4
Prioritize Risks .......................................................................................................... 9
7.1.5
Treat Risks .............................................................................................................. 10
7.1.6
Monitor Risk Treatment .......................................................................................... 11
7.1.7
Risk Models ............................................................................................................ 11
7.1.8
Oversight to ensure process compliance ................................................................. 11
7.1.9
Feedback Loop ........................................................................................................ 11
© 2010 J.W. Mayo Consulting, LLC
Page 2 of 12
Program and Project Management Process
1
Management Approach
1.1 Introduction
The Program and Project Management Process (PPMP) is a comprehensive project and program
management body of knowledge based on four decades of organizational and industry lessons
learned.
The PPMP is constantly evolving as we identify more efficient approaches to PM challenges,
issues, risks, etc., and integrate organizational lessons learned into our project management
approach. JWMC strives to combine our own unique organizational lessons learned with best
practices and industry lessons learned embodied by the various standards bodies (e.g. CMMI,
INCOSE, ISO, IEEE, ITIL, PMBOK, ANSI etc.). The value of the PPMP is that global
standards, lessons learned and best practices are distilled down to specific actions, deliverables,
logs, checklists, etc. that can be effectively utilized by Project Managers and their associated
team members.
The PPMP is a single integrated approach as opposed to a series of discrete activities. The focal
point for the PPMP is the project schedule which is the primary product from the Time
Management Knowledge Area of the PMBOK. JWMC uses the project schedule to drive
virtually every aspect of the project / program. For example:
•
•
•
•
•
Mitigating strategies for risks are reflected in the schedule
Scope changes are not acted upon until they are added to the project schedule
Deliverable acceptance is reflected as major milestones
Deliverable status, risks and issues form the basis for status reporting
The plan itself is combined with weekly variance analysis to provide the basis for
identifying lessons learned and best practices on a real-time, ongoing basis
The PMBOK is the foundation of PPMP which addresses all nine PMBOK Knowledge Areas
(see Figure 1 below). One of the key elements of PPMP is the fact that the process starts long
before contract award, during the proposal stage of a project. Fifteen of the 42 PMBOK process
areas are completed during the JWMC proposal stage:
•
•
•
•
•
•
•
Develop Project Management Plan
(PMP)
Collect Requirements
Define Scope
Create WBS
Define Activities
Sequence Activities
Estimate Resources
© 2010 J.W. Mayo Consulting, LLC
•
•
•
•
•
•
•
•
Estimate Effort
Estimate Duration
Develop Schedule
Estimate Cost
Determine Budget
Quality Planning
Plan Risk Management
Identify Risk
Page 3 of 12
Program and Project Management Process
Figure 1 - Integrated Management Approach
Immediately after contract award JWMC will collaborate with the Government to confirm the
pre-award work that was completed to confirm that it is still aligned with the Government’s
goals, objectives, and requirements.
2
Time, Cost, and Scope Management
JWMC utilizes a three tier hierarchy of work products
to develop our project schedule which becomes the
Progress versus activity is the driver
baseline for time, cost, and scope. The hierarchy of
behind JWMC’s approach to
work products consists of a product based work
managing time, cost and scope.
breakdown structure (WBS), a WBS Dictionary,
Process Definitions, and project schedule. The
hierarchical approach maximizes reuse and promotes project management efficiency while
maintaining the appropriate level of detail for any experience level from entry level team
members to highly experienced Subject Matter Experts (SME). A single WBS element will map
to a single WBS Dictionary entry which consists of the following data elements:
•
•
•
•
WBS ID
Control Code
WBS Name
Description
•
•
•
•
Deliverables
Work Package(s)
Basis of Estimate (BOE)
Activity List
•
•
•
Input(s)
Dependencies
Resource Requirements
Each element in the Activity List has a corresponding process definition that details the required
inputs, processes, and outputs for each activity. The basic premise is that experienced team
members will find sufficient detail in the project schedule to complete their work assignments;
moderately experienced team members can map their work assignments from the project
schedule to the WBS Dictionary if they need additional detail; and junior team members can map
their work assignments from the project schedule to the WBS Dictionary, to the process
definition for each individual activity.
A product oriented schedule focuses team member effort on completing deliverables and work
products and not simply completing a series of steps that may or may not result in a tangible
deliverable or work product.
© 2010 J.W. Mayo Consulting, LLC
Page 4 of 12
Program and Project Management Process
In addition to deliverables and work products the project schedule will also contain major
milestones, mandatory dependencies, discretionary dependencies, and external dependencies.
Based on customer requirements JWMC will tailor our schedule management process to include
additional elements as needed. The Project Manager uses the baselined project schedule as the
basis for assigning work. Works is
assigned and progress is monitored
on a weekly basis. Variance
analysis is one of the main
techniques used for monitoring
progress and is described in detail in
Section 2.1 below.
As previously mentioned, the
project schedule is the focal point
for the PPMP and all JWMC
projects. The project schedule will
represent 100% of the defined scope
of the project. JWMC recognizes
Figure 2 - Schedule Management Process
that deliverables scheduled to be
developed later in the lifecycle will have dependencies on early lifecycle stages and therefore
may require additional definition after the completion and approval of early deliverables. For
example, specific code modules cannot be fully defined until the detailed design is complete.
The project schedule is baselined at the inception of the project and is only modified based on
approved change requests. The initial baseline may be at a high level to reflect the relationship
and dependencies of all requirements.
Detailed work packages are developed using a phased approach or a calendar-based windowing
approach. The phased approach allows the team to define each phase in detail at least 30 days
before the end of the current phase. The calendar-based windowing approach allows the team to
detail a 90-day window of activity; after the completion of a 30-day window, the subsequent
calendar month is planned in
detail, thereby providing a
sliding 90-day window of task
and resource assignments. This
approach provides an up-to-date
management tool that supports
client expectations and acts as a
mechanism to immediately
incorporate lessons learned and
Figure 3 - Rolling Window
team member input in our
processes. JWMC can tailor the rolling window process to accommodate both longer and shorter
windows based on customer requirements.
These detailed plans do not affect or change our baselined project plan. Any changes to the
deliverables or commitments reflected in our initial project plan will be executed using our
change management process.
© 2010 J.W. Mayo Consulting, LLC
Page 5 of 12
Program and Project Management Process
2.1 Variance Analysis
Actual effort and estimate-to-complete data are collected from individual team member time and
status reports. The project schedule is updated weekly, with metrics applied against project tasks
and an updated estimate to complete (ETC) the task. Variance analysis is conducted each week
after the project schedule is updated with actuals. Variance analysis includes analysis of EV (e.g.
CPI, SPI), schedule variance, effort variance, and any variance that exists between actual
accomplishments and the basis of estimate (BOE). The weekly variance analysis enables both
JWMC and the customer to review planned versus actual data and to assess the impact of any
variances on time, cost, and scope on a near real-time basis.
The variance analysis process is
complementary to EVM in that it provides an
opportunity to detect undesirable trends long
before they are reflected in earned value
reporting. JWMC conducts variance analysis
on all aspects of the project plan including (but
not limited to) resource availability,
dependencies, skill level variance, schedule
variance, effort variance, and most importantly
the original basis of estimate. By mapping any
variance back to the original basis of estimate
we are able to identify undesirable trends and
implement corrective action long before the
project is impacted.
Figure 4 - Variance Analysis
Consider the following scenario:

The original basis of estimate (BOE) was that a total of 575 test cases would be executed

The BOE also indicated that the combined test team would be able to execute 15 test
cases per day

Based on the total test cases, labor categories, team size, and an execute rate of 15 test
cases per day, 38.3 days were allocated to testing in the project plan

During the first week of testing the test team was only able to execute 10 test cases per
day
During the variance analysis process, the project manager conducts root-cause analysis on
the variance of 5 test cases per day to determine where the problem lies. In this scenario
there are several possibilities; incorrect skill levels, test team availability, complexity of test
cases, learning curve, etc. Based on the root cause, the project manager and test team would
implement corrective action which includes a checkpoint to reassess their progress.
© 2010 J.W. Mayo Consulting, LLC
Page 6 of 12
Program and Project Management Process
In the worst case, JWMC’s variance analysis process will indicate whether there is a problem
within two weeks and in many cases we are able to identify problems and implement corrective
action within one week.
The variance analysis process is typically conducted mid-week so that there is time to implement
corrective action before the weekly reporting cycle. Based on the criticality of the project, this
process can be tailored to include daily variance analysis on critical path activities.
2.2 EVM
<< Insert EVMS information here >>
3
Quality Management
3.1 Quality Management Plan
3.2 Quality Assurance
3.3 Quality Control
4
HR Management
4.1 HR Plan
4.2 Acquire Project Team
4.3 Training Plan
4.4 Project Team Performance Management
5
Communications Management
5.1 Communications Plan
5.1.1 Status Reporting
5.1.2 Performance Reporting
5.1.3 Escalation Process
5.2 Stakeholder Management
6
Procurement Management
© 2010 J.W. Mayo Consulting, LLC
Page 7 of 12
Program and Project Management Process
7
Risk Management
JWMC’s risk management process is fully aligned with three accepted industry standards
governing risk management; the PMBOK, Australia-New Zealand ANZ-4360 Risk Management
Standard, and International Standards Organization (ISO) 16085 Systems and software
engineering – Life cycle processes – Risk Management.
An
effective
project
risk
management process consists of
nine components; six discrete
process steps and three activities.
The six process steps are;
establish the context, identify
risks, quantify risk impact,
prioritize risks, treat risks, and
monitor risk strategy. There are
three activities that transcend the
entire risk management process;
oversight to ensure compliance,
develop risk models, and feedback
loop.
Figure 5 - Risk Management Process
Risks are documented in the risk register and risks that meet certain priority and/or impact
thresholds will have separate risk treatment plans developed. The quantification, prioritization,
and treatment processes are described in the following sections.
7.1.1 Establish the Context
JWMC’s risk management approach confines the context of project risk management to the
project’s budget, schedule, quality, and mission accomplishment.
7.1.2 Identify Risks
Project risks frequently have a variety of symptoms, conditions, events, etc. that indicate the
presence of a risk. Project teams will often times identify these risk indicators as the risk while,
the real risk goes undocumented and unmanaged. JWMC’s risk management approach
emphasizes the need to decompose risk related items to the point that the real risk can be
identified and the impact objectively quantified. The key element of effective risk identification
is to quantify the impact of the risk in terms of the context (e.g. time, cost, quality, mission
accomplishment). There are five basic questions that can be asked to confirm that the risk has
been identified versus a symptom, condition, etc.:
1.
2.
3.
4.
5.
Is there a schedule impact?
Is there a budget impact?
Is there an impact to quality?
Is there an impact to our ability to accomplish the mission?
Can impact be objectively quantified?
© 2010 J.W. Mayo Consulting, LLC
Page 8 of 12
Program and Project Management Process
If the answers to questions 1, 2, 3, or 4 and 5 are “yes” then we have a high degree of confidence
that the risk has been properly identified. Once the risk is identified it is added to the risk
register.
7.1.3 Quantify Risk Impact
In order to effectively manage a risk, its impact to the project must be objectively quantified. For
example, three-week schedule delay, $50,000 budget overrun, 500 hours of rework, etc.
“Significant delays”, “reduced quality”, “Substantial cost overrun”, etc. are extremely
problematic when defining risk primarily because “substantial cost overrun” to one person could
mean hundreds of dollars whereas “substantial cost overrun” to someone else could mean tens of
thousands of dollars. Quantifiable impact is also crucial when monitoring risks since it makes
little sense to spend $100K to manage a risk that has an impact of $50K.
It is possible that a risk can affect multiple aspects of the project; a schedule delay for example
could also impact the budget. In order to effectively manage the risk it is important to
understand the driver(s) behind the project. If time to market is more important then, the risk
should be defined and managed as a schedule risk whereas if budget is more important then, the
risk should be defined and managed as a budget risk. In cases where a single risk impacts
multiple aspects of the project, JWMC will collaborate with the project sponsor to determine the
primary driver so that the most effective risk management plan can be developed.
After the risk impact has been objectively quantified the risk register is updated to reflect risk
impact.
7.1.4 Prioritize Risks
After risks have been properly identified and quantified, the next step is to prioritize the risks.
Prioritizing risks before developing treatment plans is a
more efficient use of the project team’s time because it
makes little sense to spend time and effort to develop risk
treatment plans for low impact risks that will result in
schedule impacts of hours or days while there are open
risks that will result in schedule delays of weeks or
months. Prioritizing risks will yield the most value to the
project team by focusing the risk management effort on
the high impact risks.
Figure 6 - Prioritization Matrix
Risks are prioritized based on impact to the project
followed by probability of occurrence. JWMC uses a simple 3-tier scheme of low, medium, and
high which is often referred to as the 9-box model (depicted in Figure 7). The 9-box model calls
for prioritizing risks with high impact / high probability to be managed first, followed by risks
with high impact / medium probability and so on. In keeping with the objective quantification of
risks, parameters must be established for high, medium, and low. The impact parameters require
a quantified value for each context; Figure 7 illustrates one example.
The parameters for probability can be the same for all contexts (e.g. schedule, budget, quality,
mission accomplishment). For this project we will start with a baseline of >80% for high, 50% © 2010 J.W. Mayo Consulting, LLC
Page 9 of 12
Program and Project Management Process
79% for medium and <50% for low and modify
these parameters over time based on actual
performance and lessons learned. JWMC will
collaborate with the Government within 15 days of
contract award to confirm the initial impact and
probability parameters.
Context
Impact
Parameter
Schedule
High
> 6 Weeks
Medium
2 – 5 Weeks
Low
< 2 Weeks
High
> $100,000
Medium
$50,000 - $99,999
Low
< $50,000
High
> 1,000 Hrs Rework
Medium
500 – 999 Hrs Rework
Low
< 500 Hrs Rework
High
Failure chance >65%
Medium
Failure chance 35%-65%
Low
Failure chance < 35%
Budget
7.1.5 Treat Risks
Quality
It is important to recognize that not all risks can be
mitigated therefore, the first step in the JWMC risk
treatment process is to select one of the four industry
accepted risk treatment strategies; Avoid, Transfer,
Mitigate, and Accept.
Mission
Avoidance is a risk strategy where the project plan is
modified to completely eliminate the risk.
A
Figure 7 - Impact Parameters
common risk avoidance technique is to reduce the
project scope to avoid potentially risky aspects of the project.
Transfer is a risk strategy where the risk is transferred to another party. Subcontracting is one of
the most common examples of risk transfer.
Mitigate is a risk strategy where a risk treatment plan is prepared. A risk treatment plan is based
on a mitigation strategy or series of actions that will reduce the impact of the risk to some
degree. JWMC’s risk treatment approach combines components from ISO/IEC 16085 and ANZ4360 to produce comprehensive and actionable risk treatment plans that include:



Proposed actions
Resource requirements
Responsibilities



Timing
Performance measures
Reporting and monitoring requirements
By combining “timing” and “performance measures” we establish trigger points for initiating
different actions of the risk treatment plan. Trigger points establish a specific point, based on
objective criteria, where and when action must be taken along with the specific actions that must
be taken. Explicitly defining actions and the “trigger” to initiate the action reduces the likelihood
that actions will slip and it also makes the treatment plan repeatable and measureable.
Acceptance is the final risk management strategy. There are two categories of risk acceptance;
passive acceptance and active acceptance. Passive acceptance essentially means that the project
is simply going to accept the risk and deal with the risks as they arise (aka issues). Active
acceptance involves establishing a contingency reserve of time, money, and resources to deal
with risks as they arise. Acceptance is a reasonable risk management strategy in cases where the
cost of mitigating a risk is more than the impact of the risk. Passive acceptance relegates the
project or organization to incur nearly all potential risks. Active acceptance is a common
strategy when dealing with many unknowns (e.g. space travel), leading edge development, etc.
© 2010 J.W. Mayo Consulting, LLC
Page 10 of 12
Program and Project Management Process
7.1.6 Monitor Risk Treatment
There are two categories of risk monitoring; tactical and strategic.
Tactical monitoring is conducted on a daily basis by the project team and takes performance
measures, trigger points, and actual performance into account. The purpose of the tactical day to
day monitoring is to evaluate whether the risk treatment plan is effectively mitigating the risk(s).
The tactical monitoring evaluates actual progress against the performance measures in the
treatment plan and trigger points to determine whether additional risk management actions must
be undertaken. Tactical monitoring also monitors the risk management time, effort and budget
expended to date to determine whether risk management actions should continue or be
terminated.
Strategic monitoring is conducted as part of management reviews, during internal or external
audits, and at the end of projects. Strategic monitoring is forward looking and focuses on longterm process improvement. An important aspect of strategic monitoring is post-project risk
analysis. Risk analysis evaluates the results of risk treatment plans and their associated
performance measures looking for patterns and anomalies which become inputs to risk models.
7.1.7 Risk Models
One of the most important outcomes of the risk analysis process is the development of risk
models. A risk model is a risk strategy or risk treatment plan that has been proven to be effective
for a recurring risk. A risk model will contain proven mitigating strategies, resources, proposed
actions, triggers, performance measures, and reporting information. Additionally, the risk model
will include risk strategies and/or treatments that were applied but were found to be ineffective.
Risk models can be developed based on a variety of factors (e.g. methodology, project size, team
size, technology stack). The real value of the risk model is that effective actions and strategies
are validated and ineffective actions are documented so that subsequent project teams can focus
on proven treatment plans. Risk models are developed in collaboration with JWMC’s Corporate
QA and PMO functions.
7.1.8 Oversight to ensure process compliance
In order for project risk management to be effective, the process must be enforced at both the
tactical and strategic level. Effective oversight of the tactical risk management is provided by a
combination of Quality Assurance reviews and Management reviews. Oversight of the strategic
risk management process is enforced through our Corporate CMMI processes.
7.1.9 Feedback Loop
An active feedback loop is one area where an organization can derive a tremendous amount of
value from project risk management. An active feedback loop is characterized by processes that
“push” information throughout the organization as risk models and lessons learned are develop
or modified. Actively disseminating information allows project teams to leverage enhanced risk
models, lessons learned, etc. on a near real-time basis. Wiki or other collaboration software are
excellent tools for providing active feedback to project teams, especially distributed teams.
© 2010 J.W. Mayo Consulting, LLC
Page 11 of 12
Program and Project Management Process
© 2010 J.W. Mayo Consulting, LLC
Page 12 of 12