PMO Handbook - How to Plan, Build, and Run a PMO

ByAnthony Natoli, PMP
November 2016
The PMO Handbook
How to plan,build,and run a
Project Management Office
Proprietary and Confidential

Table of Contents
1
 Summary 2
 How to Plan a PMO
 Purpose of PMO 4
 Types of PMOs 5
 PMO Framework 8
 Current StateAssessment 9
 Future State Definition 11
 Gap Analysis 12
 PMO Charter 14
 How to Build a PMO
 Gating process 16
 Demand management function 18
 Resource management function 19
 Project management function 26
 Performance management function 28
 Release management function 33
 Portfolio management function 37
 How to Run a PMO
 Operating cadence for the functions of a PMO 40
 PMO Playbook 41
 Metrics to monitor 42
 Training and development of staff 43
 Continuous improvement program 44
 References 45

Summary
2
• The purpose of this presentation is to provide a prescriptive guide on how to plan, build, and run a
PMO from scratch or from an existing PMO that requires a reboot
• The planning of a PMO is done using a gap analysis method to assess current state, define future
state, and determine how to close gaps between them. The final deliverable from this phase is a
PMO Charter which describes the why, what, where, who, how of the PMO and a roadmap to close
the gaps.
• The building of a PMO is centered around the Gating Process and which PMO functions are needed
to support it. The primary tool here is the PMO Framework which defines all the critical functions
or service offerings performed by a PMO and how they integrate with eachother. The end result of
this phase is a PMO built to meet the specific needs of the organization.
• The running of a PMO is the effective operation of the PMO Framework as it relates to the Gating
Process. The cadence of daily, weekly, monthly, and quarterly activities must be established for each
critical PMO function. In addition, the operating cadence must be flexible enough to handle
exceptions or ad hoc situations. The goal of this phase is the creation of a PMO Playbook.
• This “PMO primer” is intended mainly for IT organizations and specifically those that follow both
Waterfall and Agile methodologies for software development. It describes a model for a traditional
PMO. It does not address IT organizations that strictly follow Agile methodologies only. In those
cases, other models may be better suited such as the Agile PMO1 or SAFe2 (Scaled Agile Framework
for the Enterprise).

3
How to Plan a PMO

How to Plan a PMO – Purpose of a PMO
4
• The PMO purpose is to plan and coordinate a portfolio of programs and projects that
are aligned to business strategy and deliver them in the most efficient manner
possible
• Stated simply, the PMO purpose is to deliver those programs and projects needed to
execute the business strategy
• In planning a PMO, the following structured process is recommended as it provides a
simple but effective methodology of where to start and what to focus on
Assess
current state
Define
future state
Perform
gap analysis
Develop
PMO
charter

How to Plan a PMO – Types of PMOs
5
 Before embarking on the planning effort, it is important to understand that not all PMOs are
created equal. There are multiple types of PMOs and they can be viewed along multiple
dimensions.
1. Degree of control or to what extent the PMO can control the outcome of projects and programs
2. Degree of scope or to what extent the PMO will impact the strategic goals of the organization
 PMOs by degree of Control3
 Supportive PMO – provides templates, best practices, and training to PMs. Low degree of control
over projects. Project managers are not necessarily assigned by the PMO and are more likely to report to
functional areas outside the PMO. Functional managers tend to have control over the budget and manage
project activities. Project managers are viewed as more of a project coordinator.
 Controlling PMO – provides supportive functions AND requires compliance to standards, methods,
and tools for project management. Both project and functional managers manage project activities and
budget together. PMO has authority to take corrective action if there are problems in the application of
the standards, methods, and tools.
 Directive PMO – provides supportive and controlling functions AND directly manages projects.
Highest degree of control over projects. Project managers report to the PMO and have sole control over
the project activities and budget.

6
• PMOs by degree of Scope4
• Program PMO – Responsible for planning and execution of projects for a major program.
Generally the program is of high complexity with multiple dependencies. These PMOs tend to
dissolve or are absorbed into a larger PMO (ie. Departmental or Enterprise) after the primary
goals of the program have been achieved.
• Departmental PMO – Responsible for planning and execution of projects and programs within
a specific business unit or division within the organization. These PMOs are ongoing in nature.
• Enterprise PMO – Responsible for planning and execution of all significant projects and
programs for the entire organization. This may include both IT and Business projects. These
PMOs are ongoing in nature and have highest degree of scope and impact on the organization.

7
• Matrix of PMO Types
• The two dimensions can be seen below as a matrix
• For strong matrixed organizations (centralized), most PMOs tend towards Directive for control and Enterprise for scope
(C3, S3)
• For weak matrixed organizations (decentralized) where functional areas are strong, most PMOs tend towards Supportive
for control and can range from Program to Enterprise for scope (C1, S1 thru S3)
• PMOs often start as controlling (O2) and will either digress to being supportive or progress to being directive in terms of
control.
• It is highly unlikely to encounter a PMO that is Supportive for control and Enterprise for scope.
DegreeofScope
LowHigh
Degree of Control
Low High
Enterprise
O1, S3 O2, S3 O3, S3
Departmental
O1, S2 O2, S2 O3, S2
Program
O1, S1 O2, S1 O3, S1
Supportive Controlling Directive

How to Plan a PMO – The PMO Framework (What does a PMO do?)
8
• The basic framework for the PMO
consists of 6 primary functions.
Each function is part of an overall
workflow that repeats itself
according to a certain cadence.
• This workflow will run continuously
with some functions being done
daily or weekly (ie. Program &
Project Mgmt) while others are
done biweekly or monthly (ie.
Demand Mgmt).
• A deeper dive into the activities of
each function will be provided in the
“How to Build a PMO” section of
this presentation.
1. Demand Mgmt
Align, prioritize, and
estimate demand for
projects
2. Resource Mgmt
Match demand with
supply and schedule
projects
4. Project Mgmt
Manage execution of
projects
5. Perf & Financial
Mgmt
Report on status and
cost of projects
6. Release Mgmt
Deploy projects per
master schedule
7. Portfolio Mgmt
Measure planned vs
actual benefits

How to Plan a PMO – Current State Assessment
9
• The current state of the organization’s PMO capabilities should be assessed relative to
the PMO Framework
• Most organizations will find its PMO capabilities in one of the following levels of
maturity5 shown below from lowest to highest
1. Adhoc or Reactive - Some PMO functions are performed on a single-project basis, a project office. No unified
practices across the organization. Practices are nonstandard and nonsystematic, and teams are functionally isolated.
Organization has little understanding for the number or scope of active projects
2. Managed or Emerging Discipline - A PMO exists, carrying out partial support functions, with no governance or
guidance roles. The processes are in place for initiating, planning, managing, and closing individual projects.The
organization identifies and reports upon active and prospective projects.
3. Defined or Initial Integration - The PMO represents a central project management governance and control function.
Project management processes are implemented in the framework of an overall program management; integrated,
cross functional program teams are institutionalized.
4. Measured or Effective Organization – The PMO monitors and reports on the project management practices
maturity all over the organization. Portfolio management is instituted across the organization. Systematic tracking
and integration of projects and programs is performed for the portfolio across the organization.
5. Optimized or Effective Innovation – The PMO takes initiatives in enhancing and improving the organizational
project management maturity over the three dimensions of project, program, and portfolio management.
Represented by a program-centered organization in which a mechanism has been established for continuous process
improvement.
Assess
current
state
Define
future
state
Gap
analysis
Develop
PMO
charter

How to Plan a PMO – Current State Assessment
10
• Current state assessment involves the evaluation of each functional area relative to the
level of maturity model
• Ex.
• To arrive at this type of evaluation, compare the current state against the best practice
(Optimized Level 5) in each of these functional areas
• There is no definitive standard of best practices in each functional area. However,
industry organizations such as PMI and Gartner have published numerous papers on
this topic. See the glossary for references to PMO best practices.
Assess
current
state
Define
future
state
Gap
analysis
Develop
PMO
charter

How to Plan a PMO – Future State Definition
11
• Defining the future state requires clear understanding of the organization’s strategy
and how the PMO can enable it
• Steps to be undertaken at this stage include,
1. Understand organization’s strategic objectives – What are the goals in terms of customers, markets, products, services,
innovation?
2. Understand the organization’s size, complexity, and culture – Geographical footprint, hierarchical vs matrix vs
functional, innovation vs risk averse culture
3. Assess key stakeholder needs – main issues and concerns, operations vs projects
 Based on the strategic goals and needs of the organization, the desired future state is
targeted as a maturity level for each functional area and type of PMO
• Ex.
Assess
current
state
Define
future
state
Gap
analysis
Develop
PMO
charter
Level of Maturity Type of PMO

How to Plan a PMO – Gap Analysis
12
• The gap analysis is the difference between the current state assessment and future state
definition or the amount of change required to achieve the desired future state.
Assess
current
state
Define
future
state
Gap
analysis
Develop
PMO
charter
1. Demand Mgmt
Align, prioritize, and
estimate demand for
projects
2. Resource Mgmt
Match demand with supply
and schedule projects
4. Project Mgmt
Manage execution of
projects
5. Perf & Financial
Mgmt
Report on status and cost
of projects
6. Release Mgmt
Deploy projects per master
schedule
7. Portfolio Mgmt
Measure planned vs actual
benefits
• For any viable PMO there are some
functions that are core to its operation
and purpose more so than others.
• These are Demand Mgmt, Resource
Mgmt, and Program & Project Mgmt.
• The ability to decide on which projects to
approve (Demand), schedule and balance
the demand against available supply
(Resource), and execute and deliver to
plan (Program & Project) are foundational
capabilities of any PMO.
• Any gap analysis should first address
these core functions

How to Plan a PMO – Gap Analysis
13
• Gaps are prioritized based on organizational need but any gaps in core functions
(demand, resource, project management) are prioritized first.
• Not all gaps can be closed in the short term and therefore a plan for implementing them
in phases is needed (aka Roadmap)
• Ex.
Assess
current
state
Define
future
state
Gap
analysis
Develop
PMO
charter

How to Plan a PMO – PMO Charter
14
• The end result from the planning phase is a PMO Charter. It should contain the
following elements,
• PMO Mission – What is the PMO’s primary objectives and strategy to achieve it?
• Customers and Stakeholders – Who are the primary customers and stakeholders?
• Service Offerings – What are the main functions performed?
• Organizational Structure – How is it organized and what are the roles/responsibilities?
• KPIs - What metrics will it be measure by and what are the targets or success criteria?
• Budget - What does it cost to implement and run it?
• Tools - What PPM (project portfolio management) tools are required?
• Roadmap - What is the implementation plan or what, how, and when are gaps closed?
• The PMO Charter must clearly describe what the PMO is and what it isn’t
• The PMO Charter should be reviewed with PMO sponsor (ie. CIO) and key
stakeholders (ie. CFO, COO, Line of Business VPs) to obtain their feedback and
ultimately their approval/sign off
• Socialize the PMO Charter with other key stakeholders who will be affected by the
PMO’s service offerings
Assess
current
state
Define
future
state
Gap
analysis
Develop
PMO
charter

15
How to Build a PMO

How to Build a PMO – Gating Process
16
• The first step in building a PMO is to establish a view of how any project goes from
“cradle to grave”
• This holistic view of the project lifecycle is typically called the Gating Process
Create constraint
analysis with,
• Prelim
schedule
based on est
of costs and
resource
availability
• Impact of
project cost
on total
annual budget
Submit for
decision to begin
detailed
requirements
analysis work
Track and
measure benefits
at regular
intervals.
Compare to biz
case and
determine cause
of variances.
Recommend
corrective
actions to
minimize
variances and
determine
budget impact
for future similar
projects.
Conduct benefits
review
Create detailed
requirements
and design of
technical
solution. Redo
estimate of all
remaining work.
If total project
cost is higher,
Submit for
decision to
increase project
budget and
continue to
implementation.
Implement
project per
approved
requirements
and technical
design.
Summarize
metrics for
review by
Release mgmt
team.
Submit all
metrics for
decision to move
project changes
to Production
Approve,
Reject,
or Hold?
Approve,
Reject,
or Hold?
Approve,
Reject,
or Hold?
Approve,
Reject,
or Hold?
Release
to
Production?
Create project
request and
provide high
level information
on,
• Scope
• Benefits
• Costs
• Risks
• Alignment to
Strategy
Submit for
decision to
proceed for
further
investment
Create high level
solution and
develop biz case
with,
• High level est
of costs
• ROI calc
• Timeline for
completion
• Priority score
Submit for
decision to
proceed for
constraint
analysis/portfolio
impact
Gate 1
Create
Gate 2
Select
Gate 3
Plan
Gate 5
Deliver
Gate 4
Initiate
Measure

How to Build a PMO – Gating Process
17
• As stated previously, the PMO Framework provides the overall outline of PMO
functions but these functions must support the Gating Process
• The alignment between the Gating Process and the PMO Framework is shown below
• Each gate or phase is supported by one or more of the PMO functions
Gate 1
Create
Gate 2
Select
Gate 3
Plan
Gate 5
Deliver
Gate 4
Initiate
Measure
Demand
Mgmt
Resource
Mgmt
Project Mgmt
Performance
Mgmt
Release Mgmt
Portfolio
Mgmt
Demand
Mgmt
Portfolio
Mgmt
Demand
Mgmt
Resource
Mgmt
Project Mgmt Project Mgmt
Portfolio
Mgmt
Performance
Mgmt
Performance
Mgmt
Release Mgmt
PMO Framework Gating Process supported by PMO Framework
Resource
Mgmt
Resource
Mgmt

How to Build a PMO – Demand Management
• The demand management function provides an intake process to create and select
projects (Gate 1 & 2) that can then be planned and delivered
• Gate 1 (Create) activities include,
1. Submission of project request via a request form (see example).
Request should provide information on,
• Scope and proposed business and technical solution
• Benefits
• Costs (if available)
• Alignment to strategy
• Riskiness
• Impact to other areas of the organization if undertaken
2. Decision by Governance committee to move to Gate 2 for
further refinement of the request with a detailed business case
• Gate 2 (Select) activities include,
1. Refinement of the business and technical solution
2. Creation of detailed business case with a minimum of,
• Business purpose and alignment to strategy
• Scope
• Assumptions
• Risks
• Detailed cost estimate with resource requirements*
• NPV and Payback Period analysis
• High level timeline for completion
3. Prioritization of the project request relative to all other requests
and inflight projects
4. Decision by Governance committee move forward to Gate 3 to
perform a constraint analysis and determine preliminary
schedule and impact on annual budget
• Ex. Sample Project Request Form
Demand
Mgmt

How to Build a PMO – Resource Management
19
• After demand management, the resource management function or the “Plan” phase
(Gate 3) follows to ensure that approved demand can be added to the portfolio
without exceeding supply. This is often described as the “constraint analysis”. There
are two main activities to this process and they can be done in parallel,
1. Scheduling of the request based on availability of supply to determine planned Go Live
2. Assessing impact of the total project cost on the annual planned budget
 Scheduling)
Step 1) Schedule in order of priority
If there are multiple project requests coming thru demand management (Gates 1 & 2), ensure each is assigned a priority
score and force ranked. Schedule the project requests in order of priority with the highest priority project being
scheduled first.
Ex. List of Project Requests with prioritization scores
Resource
Mgmt

20
 Scheduling)
Step 2) Identify key dependencies between projects
Scheduling in order of priority may ignore how projects are related to each other. Scheduling may have to be adjusted to
account for business and technical dependencies between newly approved projects or between new and existing projects.
See the example below.
An extreme version of this situation occurs when a higher priority project is dependent on receiving a deliverable
provided by a lesser priority project. In this case, the lesser priority project would be scheduled first.
Ex. Dependencies between projects
Projects Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Project 1
Project 2
Project 3
Project 4
Project 5
Project 6
Project 7
Project 8
Project 9
Project 10
Legend
Milestone to
provide task/
deliverable
Milestone to
receive task/
deliverable
Resource
Mgmt

21
 Scheduling)
Step 3) Schedule based on availability of critical path resources
Once priority order and dependencies have been accounted for, the project request is scheduled in the “float” or the first
availability of resources (see below)
Ex. Demand vs Supply view of all resources
By scheduling in this manner, balance between demand and supply is maintained. In the example above, it appears
resources become available in mid March to start work. However, it is the type of resources required that will
determine when the project can actually start. A detailed view of the cost estimate from the business case reveals what is
the “critical path” resource type. The critical path resource type is defined as the resource type that will govern the
overall timeline of the project. Generally it is the resource type with most work effort required during the course of the
project.
Resource
Mgmt
Float

22
 Scheduling)
Step 3) Schedule based on availability of critical path resources (continued)
This critical path resources is determined from the cost estimate and resource requirement shown in the business case.
Ex. Resource requirement plan from business case
 From the resource requirement plan, duration is 16 weeks for the full software development lifecycle
 Impacted application areas are Intershop, JDE, Qlikview, Biztalk
 Intershop development is critical path activity due to amount of effort and duration
 The critical path resources are Intershop design, build, test, and deploy to the size and duration (488 hrs and 12
weeks)
Resource
Mgmt

23
 Scheduling)
To identify when the critical path resources become available, a surplus/deficit or availability report can be reviewed. In
the example below, first availability of Intershop resources that meets the resource plan (1 FTE for 2 wks of SDD, 2
FTEs for 4 wks of Build) is in the week of June 7th. The project is then scheduled based on this availability.
Ex. Surplus Deficit Report
Resource
Mgmt

24
 Scheduling)
Using the first availability for critical path resources, the project start and end dates are determined as shown below,
 Design to startWk of 6/7 and last for 2 weeks
 Development to startWk of 6/21 and last for 4 weeks
 Testing to startWk of 7/19 and last for 4 weeks
 Deployment to occurWk of 8/16
Project is scheduled into the project portfolio and “locked”. Meaning if the schedule is accepted by the project sponsor,
available resources can be named and committed to this schedule.
Ex. Demand vs Supply view of all resources with new project request scheduled
Resource
Mgmt
project
request
scheduled

25
 Scheduling)
Step 4) Determine if schedule is acceptable to project sponsor
Scheduling based on first availability of critical path resources is called Option 1 for scheduling purposes since it generally
ensures a balance between incoming demand and existing supply. If the project sponsor does not accept this schedule there are
other options that can be entertained.
 Option 2) Schedule based on unconstrained resource availability. In this option, the project sponsor will
secure additional funding to allow for hiring of new resources. These additional resources are added to the supply and the
project is scheduled assuming a certain hiring and training period (6-8 weeks) is required first.
 Option 3) Schedule based on swapping resources with another inflight project. In this option, the project
sponsor will gain approval to put on hold an inflight project that is currently using the same type of resources needed for
the new project request. The resources are reallocated to the new project until its completion at which time they resume
working on the project that was put on hold. In this scenario, it is usually determined the new project request to be of
higher priority or greater opportunity for the organization than the one put on hold.
 Budget Impact Assessment)
The impact of the project cost on the annual approved budget must be assessed prior to starting work. If no additional funding
has been secured (ie. Option 2), then the project request must fit within the annual budget envelop. This is done by
determining if the project cost exceeds the total remaining budget.
 Total Remaining =Total Annual –Actual cost of finished – Estimated cost at completion
Budget Budget projects of inflight projects
 If Project Cost >Total Remaining Budget, additional funding should be secured prior to start of work
Resource
Mgmt

How to Build a PMO – Project Management
26
• With project request now approved, prioritized, scheduled, and budgeted, “Initiate”
and “Deliver” phases (Gates 4 & 5) can begin
• As stated previously, the heart of the PMO’s value is its ability to efficiently deliver on
programs and projects aligned to the business strategy
• Program and project management is the core competency for any PMO. The
establishment and compliance of a standardized process to deliver projects is the best
way of demonstrating this core competency.
• There two lifecycles that must be clearly defined and standardized across all projects
1. Project management lifecycle (PMLC)
 Defines all activities performed to ensure the consistent application of project management techniques and
processes. These activities are performed by the project manager.
2. Software development lifecycle (SDLC)
 Defines all activities performed to define, design, build, test, and deploy software applications. These activities
are performed by the project team.
• Each lifecycle has its own distinct set of activities with PMLC activities used to
orchestrate and support the smooth execution of SDLC activities.
• These activities should be documented in a PMLC and SDLC handbook or standard
operating procedure.
Project
Mgmt

How to Build a PMO – Project Management
27
• The PMLC should be able to support any SDLC methodology whether its Waterfall or
Agile or some hybrid of the two.
• Ex. Alignment of PMLC and SDLC activities
Project
Mgmt
Execution & Control
Initiation &
Planning Closing
Project
Management
Lifecycle
Business
Requirements
Definition
Waterfall
Software
Development
Lifecycle
Design Build Test
Deploy and Post
ValidationTesting
Sprint Planning
Sprint Review
Deploy PSP
Sprint
Retrospective
Agile
Software
Development
Lifecycle
Sprint Backlog
(User Stories)
Potentially
Shippable
Product
(PSP)
Sprint
Daily
Scrum

How to Build a PMO – Performance Management
28
• During the same “Initiate” and “Deliver” phases, that PMO function of Performance
Management are critical.
• The ability to provide easy to understand visibility and transparency as to the status
and performance of all work (programs and projects) is key to building the PMO’s
credibility. This is done thru Key Performance Indicators or KPIs.
• Performance management consists of activities in a four step process
1. Defining KPIs
2. Developing KPI measurement methodology
3. Reporting KPIs
4. Identifying KPIs requiring corrective actions
 Steps 1 and 2 are done as one time events, while Steps 2 and 3 are recurring
1. Defining KPIs
KPIs should be defined in the key areas6 of,
 Execution – Are projects getting done on time, on schedule, on scope, and of acceptable quality?
 Operational Efficiency – Are projects going from idea to delivery efficiently?
 Strategic Alignment –Are projects in alignment with the strategic goals of the organization?
 Business Value Delivered – What real and perceived business outcomes have been achieved?
These KPIs should be easy to understand, easy to measure, and tied to the outcomes desired from the PMO
function.
Perf
Mgmt

29
1. Defining KPIs (continued)
 Execution KPIs
 Schedule variance (Forecasted Go Live vs Baseline Go Live)
 Cost variance (Forecasted Total Cost at Completion vs Baseline Total Cost)
 Scope variance (Forecasted Effort or Hrs at Completion vs Baseline Effort or Hrs)
 Quality variance (no. of high defects found during UAT vs total defects found during UAT)
 Overall health status (no. of projects in trouble status vs total projects currently in portfolio)
 Operational Efficiency KPIs
 Resource utilization (no. of hrs charged to project work/total hrs available for work)
 Time to market (Actual project duration vs Planned project duration)
 Service availability (Actual start date vs Desired start date)
 Throughput (No. of projects approved per year vs No. of projects completed per year)
 Forecast accuracy
 Strategic Alignment KPIs
 Classification of projects by type (No. and $ of spend for Run, Grow, Transform projects)
 Alignment to strategic objectives (% of projects aligned to at least one strategic objective)
 Business Value Delivered KPIs
 ROI
 Customer satisfaction (survey results of key stakeholders on the project’s deliverables and outcome)
 Project success rate
 Average implementation cost
Perf
Mgmt

30
2. Developing KPI measurement methodology
 The measurement of most KPI should consist of the following elements.
a) The actual value of the KPI at a point in time
b) The target value of the KPI
c) The variance between the actual and target value expressed as a,
o Difference (Actual KPI value – Target KPI value)
o Percentage ((Actual KPI value – Target KPI value)/Target KPI value)
o Ratio (Actual KPI value/Target KPI value)
 The target value should always be considered the latest baseline value
 Baseline is the latest agreed upon value for the target. Baseline values for a project will change throughout its
lifecycle due to changes in scope, schedule, or budget
 For Waterfall projects, a new baseline for Execution KPIs like scope, schedule, and budget should be set after
detailed requirements and technical design and prior to Gate 4 (Initiate) approval
 Once the project is underway and in “Deliver” phase, any significant changes should be documented as a “scope
change request” and submitted for approval. Once approval all relevant KPIs should be rebaselined.
 Example – Rebaselining Target KPI for Schedule Variance
 Scope added by project sponsor during build phase of project
 Impact to budget and schedule is additional $50K and Go Live date delayed by 10 working days
 Requested change documented as Scope Change Request and approved by Project Sponsor
 Target Go Live date prior to scope change was Oct 7
 New Target Go Live date due to scope change is Oct 21
 Actual Go Live per current schedule is projected to be Oct 28
 KPI for Schedule Variance = Oct 28 – Oct 21 = - 5 working days
Perf
Mgmt

31
3. Reporting KPIs
 The key area of each KPI will have different frequencies of reporting. Also the timeframe for a corrective action
to actually improve a KPI should dictate the frequency of reporting.
 Execution
 Should be reported weekly since they are tactical in nature and provide visibility into week to week health of projects
and programs. Since the health of these KPIs can change significantly from week to week they need to be reported on a
weekly basis. Impact of any corrective actions taken to improve these KPIs can be seen the following week.
 Operational Efficiency
 Should be reported monthly since they provide visibility into how efficiently the overall PMO function is performing.
These KPIs should not change from week to week but monthly reporting will indicate trends in efficiency. Impact of
any corrective action taken to improve these KPIs will require two weeks to a month to take effect.
 Strategic Alignment
 Should be reported monthly or quarterly to ensure inflight and pending approved projects are aligned to business
objectives for the year. Impact of any corrective actions taken to improve these KPIs will require at least a month to
take effect.
 Business Value Delivered
 Should be reported quarterly and semi-annually. The reporting of these KPIs will be driven by the need to see how
well the PMO and the overall organization is performing in managing a “portfolio” of projects. Impact of any
corrective actions taken to improve these KPIs will require months to take effect.
 Each KPI should be reported via a “PMO Dashboard”. The dashboard is typically constructed to show KPIs in
the categories listed above and at each level of scope managed by the PMO allowing the audience to zoom in or
out
 Portfolio level – Strategic Alignment, Business Value Delivered KPIs
 Program level – Execution, Operational Efficiency KPIs
 Project level – Execution KPIs
Perf
Mgmt

32
4. Identifying KPIs requiring corrective actions
 The identification of corrective actions is based on how large the variance between actual and target KPIs.
 Typically, variances are set for RAG (Red, Amber, Green) health status with Red requiring immediate
corrective action, Amber requiring corrective action but not at the level of urgency of Red status, and Green
requiring no corrective action.
 The type of corrective action to be taken depends on the KPI in question and the changes to key activities and
processes that drive the KPI
 Ex. Typical dashboard for Execution KPIs showing which projects require corrective action
Perf
Mgmt

How to Build a PMO – Release Management
33
• Prior to projects being ready for deployment, a proactive release management model
should be used
• The opposite is to allow projects to deploy ad hoc or “when ready”. This reactive
model typically results in massive inefficiencies and production issues, some of which
include,
1. Poor resource utilization -Testing resources used to regression test the same code base multiple times resulting in
high QA costs.
2. Environment delays - Multiple projects waiting in the queue for test environments to become available resulting in
schedule delays.
3. Higher no. of deployments to production – Ad hoc releases staggered to satisfy different release dates, resulting in
high number of deployments and infrastructure resources being used multiple times.
4. Production downtime -Ad hoc releases overwriting changes previously released to production. Individual teams may
not be aware of previous changes made in production and can inadvertently “wipe them out” with new changes and
bring down the system.
• A proactive release management model is one in which deployments to production are
done on a once per month basis only. All the demand, resource, project, and
performance management done up to now will be for naught if projects are delayed
prior to deployment or cause production issues.
Release
Mgmt

34
• A proactive release management model has two important characteristics
1. All project deployments are planned in advance and done once per month only. Typically at mid month.
2. Projects can start anytime, but if any projects are scheduled to deploy during the same month, all system changes due
to these projects must be tested together. Meaning their test and deployment schedules must be synched.
• Ex. “CRs for T+2” and “Project for T+2” start at different times but end up combining activities for system
integration testing, regression testing, user acceptance testing, and deployment. This practice is made possible by
code merge after build phase is complete and testing is done on the combined code base. This practice eliminates the
need to test and deploy separately.
Release
Mgmt

35
• A proactive release management model should bring the following benefits over a
reactive one
1. Reduced Costs - QA and Infrastructure resources used once per month for deployments
2. Faster Speed to Market and Higher Predictability - Multiple projects can be bundled into a single release and releases
will be every 30 days which is shorter than the current aging of projects
3. Less Delays - Environment constraints are reduced as all changes are “merged” together
4. Improved Quality -A regular release cycle require all changes to merge at the same time (code freeze) from various
teams resulting in higher quality of delivery as the probability of “wiping out” changes in production environment
• Release management consists of the following activities
1. Reviewing the end dates for all inflight projects
2. For those projects with end dates within the same month, bundling the regression testing phase for these projects so
they all test together
3. Scheduling the deployment for these bundled projects during the same regular release window (typically mid
month)
4. Assessing the risk of the no. of projects being bundled and magnitude of changes being introduced into Production
environment. If risk is too large, rescheduling some projects to deploy in the next available regular release window
(following month).
5. Informing all impacted stakeholders of release schedule.
6. Repeating steps 1-5 to create a “Master Release Schedule” showing which projects deploy to Production
environment each month. This Master Release Schedule should include both all inflight and proposed projects that
are recently approved.
Release
Mgmt

36
• Ex. Master release schedule for projects deploying in January thru March timeframe.
For each monthly release, approximately mid month is chosen as the regular release
date.
Release
Mgmt

How to Build a PMO – Portfolio Management
37
• The last but the most important function of PMOs is portfolio management
• Portfolio management supports both the “Measure” and “Create” phases of the gating
process
• While project management is concerned about “doing the things right”, portfolio
management is concerned with “doing the right things” and seeing the big picture
• Portfolio management activities would include,
1. Reviewing all proposed and inflight projects to ensure alignment with strategic objectives
2. Measuring post deployment benefits of projects to ensure ROI is as stated in the original business case
3. Comparing current and future mix of projects by type of work, line of business, and spend against planned mix
4. Taking corrective actions at the portfolio level to ensure the entire portfolio is optimized (including accelerating,
stopping, delaying, cancelling projects to ensure the portfolio is meeting its risk vs reward tradeoff)
• These activities can be undertaken in no particular order but should be performed on a monthly,
quarterly, or as needed basis
• Often portfolio management activities are triggered by reviewing data on a “portfolio
dashboard”. As stated in the Performance Management section, a dashboard would have KPIs
displayed for each of the activities described above.
Portfolio
Mgmt

How to Build a PMO – Portfolio Management
38
• Ex. Corrective action to optimize the portfolio
1. Project D, Program A, and Program D are “at risk” or “in trouble” status
2. Program D is the largest effort in terms of cost and of highest risk
3. Recommended corrective actions to undertake
 Expend minimum effort to bring Project D to “on target” status since it is of low value and risk
 Bring Program A back to “on target” status due to its high value nature
 Cancel or Stop Program D since the effort is large and value is not as high as other programs. In addition, this Program has
the potential to significantly lower the value of the Portfolio if not successful.
Portfolio
Mgmt
Risk
Value
Low High
LowHigh
Proj A
Proj B Program
D
Program
A
Proj D
Program
C
Risk
Value
Low High
LowHigh
Proj A
Proj B Program
D
Program
A
Proj D
Program
C
Size of Circle = Cost, Color = Project Health, on target at risk in trouble
X

39
How to Run a PMO

How to Run a PMO – Operating cadence for various PMO functions
40
• The operating cadence is the “heartbeat” of the PMO and ensures each function is
performed at the right time and in the right order
1. Demand Mgmt
Perform weekly or as
needed
2. Resource Mgmt
Perform weekly
4. Program & Project
Mgmt
Perform daily and
weekly
5. Perf & Financial
Mgmt
Perform weekly
6. Release Mgmt
Perform monthly
7. Portfolio Mgmt
Perform monthly or
quarterly or as needed

How to Run a PMO – PMO Playbook
41
• This cadence is reinforced by a PMO Playbook which lists all PMO activities, what is
their frequency, when they are performed, and who is responsible
• Ex.

How to Run a PMO – Metrics to closely monitor
42
• While each KPI is important to understanding the PMO’s ability to deliver on projects
and programs, there are certain metrics that should be watched closely as they provide
immediate indicators of whether,
• Projects are on schedule
• Projects are on budget
• Right projects are being worked on
• Projects completed are providing the promised return on investment
• All available resources are being fully utilized on projects
• Portfolio of projects is healthy
• The corresponding metrics which will provide these answers tend to be,
• Schedule variance (project and portfolio level)
• Cost variance (project and portfolio level)
• Percentage of projects directly aligned to at least one strategic objective
• ROI (project and portfolio level)
• Resource Utilization
• Percentage of projects on target (green), at risk (amber), in trouble (red status)

How to Run a PMO – Training and development of staff
43
• Training and development of staff is crucial to maintaining a highly performing PMO
and improving its maturity over time
• Prior to implementing a training and development program, the organizational
structure of the PMO should be established with all roles and responsibilities defined
• The org structure in turn should define a career path of coming into, progressing thru,
and leaving the PMO for other parts of the organization
• Training and development should be focused on what knowledge, skills, and
competencies are required to perform and progress thru each position in the org
structure
• However, as a baseline, all PMO team members should be provided training material
and instruction on the following subject areas
• PMO Framework – A standardized training manual for each functional area and how they integrate
• Project Management – A standardized PMLC and SDLC training manual that addresses Waterfall, Agile, and Hybrid
approaches to software development (ie. Project Management Handbook)
• PMO Tools – Standardized training manual for any project management related software tool being utilized
• PMO Reporting – Standardized training on how to develop all required reports at the Portfolio, Program, and
Project level
• Communication – Standardized training on how and when to communicate with internal and external project team
members, stakeholders, and senior management

How to Run a PMO – Continuous improvement program
44
• Coming Soon

References
45
1. “Tradition vs Lean and Agile PMO Organisations” by Barry O’Reilly, Jan 7, 2013
2. “Scaled Agile Framework (SAFe) Distilled: A Practical Guide to Scaling Agile in the
Enterprise” by Dean Leffingwell and Richard Knaster, 1st Edition
3. “Which PMO Structure is Right for Your Organization?” by Resit Gulec, Dec 2,
2014
4. “The PMO Maturity Cube, a Project Management Office Maturity Model” by
Americo Pinto, Marcelo F. DeMatheus Cota, Ginger Levin
5. “IT Score for Program and Portfolio Management” by Lars Mieritz and Donna
Fitzgerald, Gartner Group, Aug 25, 2014
6. “As an Executive, How Can I Tell if My PMO is Effective” by Paul R. Williams,
Think for a Change, LLC, Jun 9, 2015

PMO Handbook - How to Plan, Build, and Run a PMO

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a PMO Handbook - How to Plan, Build, and Run a PMO

Similar a PMO Handbook - How to Plan, Build, and Run a PMO (20)

Último

Último (20)

PMO Handbook - How to Plan, Build, and Run a PMO