The PMO Lifecycle - Building, Running and Shutting Down

By William Dow

The PMO Lifecycle: Building, Running, and Shutting Down will provide PMO Managers, Portfolio, Program and Project Managers with the knowledge and skills to Build, Run and Shutdown a PMO. No other text on the market will take you through the steps of the PMO lifecycle.
This book covers the step by step process of building, implementing, running and shutting down a PMO.

This book covers:
• Building industry-leading PMO
• Building an Agile PMO
• Running the day-to-day operations of the PMO
• Shutting down PMOs in an organized and structured manner.
• Dashboard and Reporting using the latest tools.
Note: This book is a major update to "The Tactical Guide for Building a PMO" so if you liked that book, you are going to love this version. With new tools, new charts and graphs, and new step-by-step instructions, this book is going to help you be successful.

• Language: English
• Publisher: Dow Publishing LLC
• Release date: Sep 6, 2018
• ISBN: 9780985869540

William Dow

Bill Dow, PMP is a recognized expert in Project Management by the Project Management Institute (PMI) for specifically developing and managing Project Management Offices (PMOs.)  His extensive experience with Project Management and PMOs have enabled him to co-author several comprehensive books available through Amazon.com. Bill has taught at the college level for more than 15 years in Washington State, British Columbia and Ontario, Canada, and has worked at Microsoft for more than 14 years.  He has spoken at multiple Project Management Institute (PMI) conferences, breakfasts and events nationally.  Projectmanagement.com and projecttimes.com host numerous articles by Bill currently.

Book preview

The PMO Lifecycle: Building, Running and Shutting Down

The PMO Lifecycle: Building, Running and Shutting Down

William D Dow, PMP

Dow Publishing LLC

Contents

About the Author

Books by William Dow

Credits

The PMO Lifecycle Online Class

Foreword

Introduction

Who This Book is For

How is This Book Structured

I. PMO Fundamentals

1. Why PMOs Fail

40 Reasons PMOs Fail" by Harry Hall

Using Root Cause Analysis to Identify Systemic Failures in an IT-Based PMO Serving Non-IT Businesses

Why PMOs Fail by Yolandi Nortje"

Summary

Answers to Review Questions

2. A Brief History of Project Management and PMOs

Early Humans

Ancient Projects

Modern History

Summary

Answers to Review Questions

3. Executive Support

The PMO Cycle

Assessing the Value of Your PMO

Summary

Answers to Chapter Review Questions

II. Building a PMO

4. Chapter 4 - How to Build a PMO

Creating a Project Schedule

PMO Staples

Choosing a Process Methodology

Differences in Process Methodologies

Understanding Industry Methodologies

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

5. PMO Models

Industry PMO Models

Selecting the PMO Model

Establishing PMO Service Offerings

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

6. The Lean-Agile PMO

Lean and Agile

Updating the PMO Charter

Updating the PMO Service Catalog

Lean-Agile PMO Responsibilities

Providing Information to Stakeholders

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

7. PMO Maturity Models

The Balanced PMO

The Iron Triangle

Business-Success Metrics

Project Trade-Off Decisions

PMO Maturity Metrics

The Kerzner PMM Model

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

8. PMO Staffing Models

PMO Manager Expectations and Qualifications

Typical PMO Roles

PMO Staff Qualifications

Permanent Employees Versus Third-Party Vendors or Contractors

Managing Employees and Third-Party Vendors or Contractors

PMO Career Growth

PMO New-Hire Onboarding Guide

Going It Alone: Running a PMO of One

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

9. PMO Training and Education

PMO Training Opportunities

Recommended Skills Training

Mentoring and Buddy-System Programs

Creating a PMO Mentoring Program

Building a PMO Buddy System

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

10. Portfolio-Management Methodology

Roles and Responsibilities of a Portfolio Manager

The Portfolio-Management Lifecycle

Portfolio-Initiating Process

Portfolio-Planning Process

Step 1: Create (From Idea to Project)

Portfolio-Executing and Portfolio-Controlling Processes

Portfolio-Closing Process

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

11. Program-Management Methodology

What is Program Management?

Performance Domains

Program Governance Process

The Program-Management Lifecycle

Program Delivery - Executing and Controlling Processes

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

12. Project-Management Methodology

What Is Project Management?

What Is a Project Manager?

The Project-Management Lifecycle

Project-Initiating Process

Project-Planning Process

Project-Executing and Project-Controlling Processes

Project-Closing Process

Project-Management Knowledge Areas

Tools, Templates, Processes, and Procedures

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

13. PMO Tools and Processes

Standard PMO Tools

Portfolio-Management Tools

Program- and Project-Management Tools

PMO Processes

PMO Roundtable and Best-Practices Sharing Sessions

Summary

PMO Build Decisions

Company Profile Information Questions

Answers to Review Questions

14. Implementing the PMO

Obtaining Buy-In from Key People

Key Inputs for Implementing a PMO

The PMO Implementation Process

Sustaining Your PMO

Summary

Answers to Review Questions

III. Running a PMO

15. Getting Your PMO Up and Running

Generating Executive Reports

PMO Reporting

Conducting Day-to-Day Operations

Managing PMO Resources

Summary

Answers to Review Questions

16. PMO Day-to-Day Operations

Day-to-Day Operations: Core Processes

Process 1: Set Color Definitions

Process 2: Set Up a CR Process

Process 3: Develop Portfolio, Program, and Project Playbooks

Process 4: Define the PMO Priority List

Process 5: Define the PMO Weekly Checklist

Process 6: Set Up Program and Project Transition Plans

Process 7: Develop PMO Templates

Process 8: Execute PMO Reports

Process 9: Review and Select PMO Tools

Process 10: Continue to Support PMO Value Discussions

Summary

Answers to Review Questions

17. PMO Metrics and Performance Management

Metrics Versus KPIs

Creating PMO Metrics

Examples of PMO Metrics

Best Practices Around Creating PMO Metrics

PMO Performance Tracking

PMO Auditing

Summary

Answers to Review Questions

18. PMO Reporting

Past, Current, and Future Reports

Building Your PMO’s Reporting Function

Assessing Existing PMO Reports

The PMO Reporting Analyst Role

Summary

Answers to Review Questions

19. PMO Capabilities Assessment

Capabilities-Assessment Process

Dealing with Vendors and Contractors

PMO Capabilities Checklist and Evaluation Criteria

Opportunities for Improving PMO Skills

Results of the PMO Capabilities-Assessment Process

Summary

Answers to Review Questions

20. Managing Change in the PMO

Change and Change Agents

Change Models

Organizational Change Management

Summary

Answers to Review Questions

IV. Shutting Down a PMO

21. Chapter 21 - Shutting Down the PMO

Why PMOs Shut Down

The Eight-Step Shutdown Process

Step 1: Create a Project Schedule

Step 2: Review Resources

Step 3: Shut Down Mentoring Programs and Buddy Systems

Step 4: Review All Financial/Billing and Establish the Closeout Process

Step 5: Review Software and Maintenance Contracts

Step 6: Shut Down Specific Organizational Environment Factors

Step 7: Review, Back Up, and Archive the PMO Site and Materials

Step 8: Report Completion of PMO Shutdown

Summary

Answers to Review Questions

22. In Conclusion

V. PMO Fundamentals

VI. Building a PMO

VII. Running a PMO

VIII. Shutting Down a PMO

Chapter Review Questions and Answers

Copyright @ 2017 William Dow, PMP

Dow Publishing LLC

1210 N 42nd Place

Renton, WA 98056

All rights reserved.

No part of this book may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without permission from the author.

ISBN 978-0-9858695-4-0

Printed in the United States of America

All trademarks are the property of their respective owners.

PMI:

Always provide an attribution statement when using PMI marks.

Registered Marks. Registered marks are marks that are registered with the U.S. Patent and Trademark Office. If the PMI List of Marks indicates that the mark is registered, the attribution statement should include the word registered, as follows:

PMI, PMP,PgMP,ACP, PfMP, PMI-PBA are registered of Project Management Institute, Inc.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Sixth Edition, Project Management Institute, Inc., 2013.  Copyright and all rights reserved.  Material from this publication has been reproduced with the permission of PMI.

PMBOK is a registered mark of Project Management Institute, Inc.

The Standard for Program Management – Fourth Edition Copyright and all rights reserved.  Material from this publication has been reproduced with the permission of PMI.

Vellum flower icon Created with Vellum

When I thought about dedicating this book, I wanted to focus on one person this time: my wife, Kathleen Dow. It has been a rough year with some medical issues for us, and so I want to take this time and say Kath, without you, I would not be who I am today. You are my rock, my support mechanism, my life. You are everything to me. I want to thank you for being you, and I could not have done it without you!

I also want to thank my mother and my brothers and sister and of course my son William Dow. Billy, I am so proud of you and you mean everything to me.

About the Author

William Dow, PMP, is a recognized expert in project management by the Project Management Institute (PMI) for developing and managing project management offices (PMOs.) His extensive experience with project management and PMOs has enabled him to co-author several comprehensive books (available from Amazon.com).

Bill has taught at the college level for more than 15 years in Washington State, as well as in British Columbia and Ontario, Canada. He has worked at Microsoft for more than 10 years. He has spoken at multiple PMI conferences, breakfasts, and events nationally. ProjectManagement.com (http://www.projectmanagement.com) and PMtimes (http://www.projecttimes.com) host numerous articles by Bill.

As a PMP and subject matter expert, Bill is available to author white papers, articles, and blog posts on specific topics relating to trends in project management. He is also poised to deliver training, however basic or complex, in project-management methods.

Facebook icon Twitter icon Instagram icon

Books by William Dow

The PMO Lifecycle: Building, Running, and Shutting Down (2017)

Project Management Communication Tools, co-authored with Bruce Taylor (2015)

The Tactical Guide for Building a PMO (2012)

Project Management Communications Bible, co-authored with Bruce Taylor (2008)

Courses by William Dow, PMP

The PMO Lifecycle: Building, Running and Shutting Down Online Course

Top Communication Tools Mini Course

How to Build, Run and Shutdown a PMO - Mini Course

Details found here: https://www.dowpublishingllc.com/

LinkedIn: https://www.linkedin.com/in/billdow

Website: http://www.dowpublishingllc.com and http://www.billdowpmp.com

Credits

Foreword: James Brown

Cover design: Elysia Chu

Editor: Kate Shoup

Chapter 2 PMO history: Bruce Taylor

Chapter 6, The Lean-Agile PMO: Jonathan Ward

Contributor, project-management business intelligence: Michael Hopmere

Contributor, Chapter 7, PMO Maturity Models (including The Balanced PMO): Al Callan, PMP

Chapter 10, Portfolio-Management Methodology: Yorai Linenberg

Contributor, Chapter 11, Program-Management Methodology: Mark Bestauros

Chapter 20, PMO change agents/models: Diana Lilla, M.A., PMP

The PMO Lifecycle Online Class

If you are still struggling and want some additional help, check out the online course. Click on the image below to go right to the course.

The PMO Lifecycle Online Class

Foreword

I remember the first time I met Bill Dow. We were both attending a PMI Congress. He asked if he could share my table at breakfast. We quickly struck up a conversation about PMOs—the challenges many face when starting a PMO, and how to ensure delivery of the PMO’s value and benefits once it’s up and running.

As the director of a PMO that won the 2009 PMO of the Year Award and someone who has built or managed PMOs for more than 20 years, I was attending PMI Congress as a speaker and as a guest of several vendors I had used over the years. As Bill described his current assignment, I was keenly interested in how his PMO handled project management compared to my current and previous experiences. It was very apparent during our brief discussion that many people in the profession run into similar issues surrounding PMOs.

Upon my return home from the PMI event, I immediately began reading Bill’s first book, The Project Management Communication Bible. It echoed the discussions we had. I could see that he truly understood that a major failure of many project managers is communication. I can no longer keep count of the times I have been asked to study an organization to determine the root cause of a PMO failure only to find it tied in some way to communication.

Over time, Bill and I kept in touch. He graciously provided me a copy of his next book, The Tactical Guide for Building a PMO, targeted at those attempting to build or improve a PMO. It was filled with common-sense information that is unfortunately not so common. To be more accurate, it identified a path and a series of processes that increase the PMO’s chances of success. (Most folks do not want to take the time to perform these processes—and then wonder why their PMO is not effective.) Bill’s views on the importance of focusing on the problem your PMO is trying to solve rather than process creation for the sake of having processes is very good advice.

When Bill asked me to write the foreword for his new book, PMO Lifecycle: Building, Running, and Shutting Down, I was very humbled and quickly accepted. This text not only covers building and managing a PMO, but also shutting one down. Not many in the project-management profession actually understand how important it is to close a PMO correctly. In fact, I wager very few PMOs include processes related to shutting down in their design. Most people think a PMO lives (and should live) forever, which is just not true.

Overall, reading a book written by someone who actually has the appropriate knowledge and experience provides a much better base upon which to build your own PMO. Bill has both knowledge and experience.

―James Brown

Introduction

The company has chosen you as the new PMO manager. You are excited and ready to go, but you have no idea how to start. As a long-time project manager, you have worked in many PMOs. However, this is the first time you will be running one yourself. Frankly, you are a little scared!

You are not the first person to face this challenge, and you will not be the last. What is important is how you approach it. The good news is that this seemingly impossible task can in fact be very simple—if you approach it in a very organized and structured manner. Think about it this way: You work in project management, right? Well, why not tackle building and implementing a PMO the same way you would tackle a project?

For help setting up your PMO, there are numerous books on the market, written by some great project-management thought leaders. I strongly encourage you to check them out. For example, Mark Price Perry’s book, Business Driven PMO Setup: Practical Insights, Techniques, and Case Examples for Ensuring Success, is an excellent PMO book. It provides some great information and strategies around setting up and establishing PMOs from a very strategic level. The Strategic Project Office, Second Edition, by Ken Crawford, is another excellent book about building PMOs from a strategic point of view. It covers some of the high-level concepts that PMO managers will need to consider when starting their own PMOs.

Both these books are great. This book, however, takes a different angle. It’s tactical, offering step-by-step instructions for creating, building and running a PMO. It leaves the strategic side of building PMOs to the two books I just mentioned (and other books like them).

Back in 2012, I attended a conference with several PMO managers who were all looking for a tactical book about setting up and managing PMOs, to no avail. To meet that need, I wrote and published my first PMO book, The Tactical Guide for Building a PMO. It was (and still is) a big hit in the industry. However, while that book covered building and implementing a PMO, it didn’t cover shutting one down. That’s where this book comes in. It’s a more complete version of that earlier title. By covering the full lifecycle of a PMO, this book helps PMO managers run their PMOs from the cradle to the grave.

The information in this book will get you through most scenarios at most companies. However, if it does not, you can contact me (my contact information appears on the About the Author page), or you can communicate with many other industry experts who run large-scale PMOs. In addition, online project-management resources, such as the project-management page on LinkedIn and ProjectManagement.com have lots of white papers and other information that can help you solve business problems. Take advantage of these resources, and do not be afraid to ask questions.

In the grand scheme of things, PMOs are still relatively new. There are many people like you who are just now getting a handle on this area and doing the best job they can. Industry leaders who share their materials and lessons learned help everyone to be successful, and that’s the aim of this book.

Before we get started on the PMO lifecycle, I just want to say one more thing: good luck. It is going to be a long journey. At times, it will be frustrating, but overall, you will find it valuable, rewarding, and frankly, one of the best jobs in the world. You are going to do just fine, and I’ll be here the whole way.

Who This Book is For

Who This Book Is For

Let me guess. You work in one of the following roles:

PMO manager

Portfolio manager

Program manager

Project manager

Project coordinator

Project report analyst

Well, I have good news. This book caters not just to PMO managers, but to many different roles relating to project management. If you work in any one of these roles and you want to learn how to do it better, then this book is for you.

This book is also for you if you are curious about PMOs or if you are new to the project-management industry. Yes, the main focus of this book is building, implementing, running, and shutting down a PMO, but it delves into so many more areas. This book is intended for PMO managers, but it would be wrong to assume they are the only ones who would get value from it.

How to Use This Book

Building a PMO is a difficult task. Even if you have many years of experience in project management, building a PMO is not something you can just wake up one morning and do. That’s where this book comes in. This book is tactical. There are no concepts or theories or high-level strategies—just step-by-step details on building, running, and shutting down a PMO.

Here are some friendly and helpful tips on how to use this book:

Answer the chapter review questions: Each chapter has a series of review questions and answers. Use these to do a self-check to make sure you understand the content. See if you can answer them immediately. If not, go back and reread the chapter. Being able to recall this information will help you as you build, run, and shut down your PMO.

Be flexible regarding roles: Do not assume that you will perform just one role in the PMO. The PMO manager can be a portfolio manager, program manager, and project manager all at once. Read this book with an open mind and some flexibility regarding the various roles you can play as PMO manager. The best PMO managers are the ones who are the most flexible.

Don’t feel like you have to implement everything: Not all PMOs need the same level of rigor. Besides, most companies won’t accept the introduction of that many processes. That being said, you should at least consider the various tips and suggestions. Then, determine which ones work for you and which ones don’t.

Implement your PMO using the crawl, walk, run theory: Don’t hit the ground running. Give your PMO time to develop. Think of it like a baby. First, the baby crawls. Then it walks. And later, it runs. The same applies to your PMO.

Think about how resources, procedures, and infrastructure play a part in each aspect of your PMO: Throughout the book, I’ll highlight the ways in which these three considerations factor into the various parts of your PMO.

Use any templates provided: Some chapters include templates, which are provided as job aids to help you through the PMO lifecycle process. Use them. Other chapters mention templates, but don’t provide them. In that case, it’s up to you to find them yourself. There are hundreds of templates online. Or, it may be that your company already has applicable templates. Remember: As PMO manager, you decide what templates your organization will use. Note templates for the book are available at https://www.dowpublishingllc.com/store

Document every PMO build decision: It is a best practice to document your build decisions in a build-decision chart. You do this immediately after you read a chapter that steps you through the decision process for a certain area of your PMO. (Otherwise, you might forget what you decided.) Later, when it’s time to implement your PMO, you can refer to your build-decision chart and act on the decisions you’ve documented there. Figure 1.1 is a build-decision chart that you can use to document your build decisions. Keeping this chart current will be extremely helpful when you enter the implementation phase of the PMO.

Figure 1.1: Build-decision chart

PMO Decision Chart

Document Company profile information: Another best practice to incorporate when building your PMO is completing the company profile information questions. The company profile questions help you make decisions when building your PMO. For example, if you have no PMO budget, and you looking to purchase PMO software, well that will be problem. In figure 1.2, you see an example of these questions, starting with some initial details of the company, and then ten questions to get your started. You should add or delete questions where applicable. This is a simple but powerful tool to help you document the profile and characteristics of your company, and make decisions as you progress through building your PMO. Continue to refer to the PMO Build chart and these company profile information questions and answers throughout the PMO build process.

Figure 1.2: Company profile information questions

Company Profile Information Questions

How is This Book Structured

How This Book Is Structured

This book is broken into four main parts:

Part I, PMO Fundamentals: The first part of this book provides a history of and insight into the structure of PMOs. The goal of this part of the book is to provide key information to PMO managers and to ensure everyone reading the book understands the basic fundamentals of PMOs.

Part II, Building a PMO: The second part of this book teaches the core components of building a new PMO or enhancing an existing one. (For the purposes of this book, the basic activities in each scenario are essentially the same.) Two key topics covered during this part are the PMO build schedule and PMO build decisions. In addition, this part discusses the implementation of the PMO. Note that this does not mean implement everything covered in the build chapters. Rather, it means implement all the decisions you made during the build phase.

Part III, Running a PMO: The third part of this book focuses on running a PMO on a day-to-day basis. It covers critical areas such as establishing metrics, reporting, implementing processes, day-to-day operations, assessments, and more. Like the rest of the book, this part is very tactical.

Part IV, Shutting Down a PMO: This part covers the ins and outs of shutting down a PMO. Sadly, at some point in your career, you will likely have to perform this duty. Fortunately, it involves a pretty clear set of processes, which are laid out in this part. If you are in the position of having to shut down your PMO, you can go directly to this part.

That is all there is to it: four parts, each building on the one before to guide you through building, running and shutting down a PMO.

Note that throughout the book, you will encounter a few different types of learning aids:

Tips and Notes: You’ll see lots of these nuggets of information scattered throughout this book. They’re short, but they’re valuable. I urge you to take the time to read them.

Bill’s Thoughts: These relay first-hand personal accounts of what I’ve gone through when building, running, and shutting down my PMOs.

Let’s get started.

Part I

PMO Fundamentals

1

Why PMOs Fail

Review Questions

In the 40 Reasons PMOs Fail survey, what is the biggest issue between PMOs and stakeholders?

In the Using Root Cause Analysis to Identify Systemic Failures in an IT-Based PMO Serving Non-IT Businesses survey, what technique is used to break down the root-cause issues?

How long does a PMO manager typically have to convey a PMO’s value?

How long do PMOs typically run before there is a change in direction or they are shut down?

In this first chapter, let’s examine what contributes to successful PMOs by examining common reasons PMOs fail. Here, you’ll find contributions on this topic from three experts in PMOs: Harry Hall, Steven Selikoff, and Yolandi Nortje. Hopefully, by heading into this new adventure with some knowledge and background, you will avoid the mistakes that others have made while in your same position.

Let’s dive into these survey’s now.

40 Reasons PMOs Fail" by Harry Hall

I’ve been managing projects and programs for more than 15 years. I’ve seen a little bit of everything. I’ve also had the joy and the pain of implementing two project management offices (PMOs), one in an information technology department and one enterprise PMO.

Through the years, I’ve noted many reasons that PMOs fail or struggle. It’s rarely just one thing; it’s usually a combination of things. Here is a list of causal factors. I hope the list helps you find success.

No project sponsor or project charter for the implementation of the PMO

Failure to define the P in PMO (project management office or program management office)

Failure to place the PMO at the right level of the organization (e.g., enterprise PMO, IT PMO) based on the real problems of the organization

Inability of the PMO to deal with institutional politics

Passive-aggressive behavior of stakeholders

Communicating to all the stakeholders in the same manner with the same level of detail

Staffing of the PMO with technical project managers that lack leadership, strategic, and business management skills

The PMO requires that ALL project managers adopt templates, forms, and strict methods

The organization only wants window dressing rather than real change

Showy Batman heroics of the PMO rather than day-to-day servant leadership

Changes in executive leadership (out goes the individual who supported the PMO, and in comes a person who does not favor PMOs)

The lack of project management maturity of its business leaders

The lack of in-depth project management experience in the PMO

The lack of collaboration between the PMO and its stakeholders

The lack of rewards and recognition when good things happen

The lack of project management training

The lack of business analysis skills in the PMO

The lack of periodic assessments of the PMO

The clashing of beliefs in traditional and Agile lifecycles

Functional managers want complete control of the organizational projects that impact them

Jealousy

Power struggles

The tendency of the organization to regress to bad behavior

Embarking on large, complex programs immediately after or during the implementation of the PMO

The unwillingness of senior management to make the investment of time to improve the project culture over the long haul

The PMO lacks an understanding of the organization’s problems

Poor definition of the PMO success criteria

The PMO doesn’t understand the organization’s culture

The PMO doesn’t understand the stakeholder’s needs and expectations

Not implementing the right type of PMO/degree of control (e.g., supportive/low control, controlling/moderate control, directive/high control)

Thinking that PMOs can only bring value for mammoth programs

The PMO is bureaucratic

Failure to highlight early successes

The PMO loses wind after the initial gains

The PMO is seen as the process police/box checkers

Too many meetings with too little to show

The PMO lacks an understanding of the organization’s strategic plan and fails to align itself with the strategy

Thinking that what worked at one company will work at another company

Individuals craving the desire for former positions or status before the implementation of the PMO

Expecting huge results in a short period of time

Printed with permission from Harry Hall’s website:

http://projectriskcoach.com/2015/08/08/40-reasons-pmos-fail

Analysis

Think long and hard about some of these points. It is amazing how common these problems are from company to company and industry to industry. As PMO manager, be prepared to face some of these same issues in your company. Knowledge is half the battle. Knowing what can happen helps you be prepared in case it does happen.

Let’s talk about a few of the key points in Hall’s list.

11. Changes in Executive Leadership

As PMO managers start building their brand-new PMO (or enhancing an existing one), they nearly always have the executive support they need. Then, for whatever reason, a change in leadership occurs. Suddenly, the PMO no longer has executive support. And of course, with limited or no executive support, your PMO will struggle. PMO managers and PMO failure surveys frequently cite executive support as one of the main factors in the success of any PMO—and lack of support as one of the main factors in a PMO’s failure. Chapter 3, Executive Support, discusses the importance of executive support to the success of a PMO.

25. The Unwillingness of Senior Management to Make the Investment of Time to Improve the Project Culture Over the Long Haul

Fixing some aspects of project management—such as compiling regular status reports, acting on lessons learned, and tracking the budget—may not take much time. But for other areas, there are no quick fixes. Changing methodologies, improving leadership, and fostering trust and respect take time.

32. The PMO Is Bureaucratic

When building your PMO, avoid being too academic or bureaucratic. Yes, academics were the foundation of PMOs back in the 1960s, but today, PMO managers must convert academia into tactical practice as quickly as possible. A big, bloated PMO that is all theory is doomed to failure. Similarly, a PMO that enforces best practices and processes without considering what works best for program and project managers in practice will not succeed. To be successful, PMO managers must balance academia and bureaucracy with the tactical side of things.

40. Expecting Huge Results in a Short Period of Time

Generally, PMOs aren’t about getting quick results. Indeed, if that’s the primary focus of your PMO, it will probably be meet an early demise. However, your window to make a positive impression with a new PMO is brief. For this reason, even as you remind management that your PMO is a long-term program, you must continually market and sell your PMO—including reporting any short-term results you achieve. If done correctly, this can dramatically increase your odds of success over the long haul!

Let’s have a look at another survey on PMO failures.

Using Root Cause Analysis to Identify Systemic Failures in an IT-Based PMO Serving Non-IT Businesses

by Steven Selikoff

There is a troubling high rate of business projects, led by a PMO situated within the IT division, that fail to successfully deliver on the needs of their internal business clients.

Since I am extremely analytical, and I love root cause analysis, I thought it would be a fun to apply the Six Sigma Five Whys root cause analysis technique to this problem. I’ve been privileged to be a consultant to many Fortune 100 companies, so this case study uses examples I have personally experienced. However, every IT-based PMO is unique, so run this exercise within your own PMO and have all your members contribute to the analysis.

The Five Whys is one of the simplest tools to identify the root cause(s) of a problem without using statistical analysis, and is a tool every project manager, program manager, and product manager should be familiar with. The technique is easy. Once you have your problem statement, simply ask Why? again and again, digging deeper or forking each time. Asking five times is just a guideline. You may need to ask two times, three times, six times, or even more. Like brainstorming, the Five Whys is most effective when performed by a group. The goal is to dig deep enough to get past symptoms of the problem and get to a point where no more Whys can be asked.

Problem Statement: Business projects led by the IT-based PMO have not met the required needs of the business.

Step 1: Since we are looking at numerous failures to deliver across many projects, and therefore large amounts of data, begin by clumping the errors into affinity groups. An affinity group is a cluster of events/issues/problems that are associated by commonalities.

Figure 1.3: Why your PMO may be failing

Why PMOs may be failing

---

Affinity Group 1: The PM did not fully understand the needs of the business and the potential negative impact of the project solution.

Why? The PM did not have the in-depth knowledge or the experience within the business to make design decisions. What may seem inconsequential to the PM was actually very important to the business.

Why? The PM’s skill strengths are within IT disciplines such as networking or systems, rather than the business’s skills.

Why? There is a cultural bias within IT that the IT PM can learn and understand the business, easier than someone from the business can learn technology.

Potential Solutions:

Assign a business representative as an SME for the business.

Hire IT PMs who have business backgrounds and experience.

Train a business representative the skills needed to be a non-technical IT PM.

Train the IT PM in general business principles, process management, and organizational change management.

Train the IT PM about the specific business. For example, have them attend sales calls and use the CRM they would be modifying. Have them shadow the line workers or use the tools/systems as a member of the business team would.

Affinity Group 2: The BRD was flawed.

Why? The PM did not ask the right questions or pose the questions in the right way.

Why? The PM was not effective at interviewing.

Why? The business did not effectively communicate information to the IT PM.

Why? The business feels marginalized, un-empowered, or not engaged.

Potential Solutions:

Additional PM training in interviewing techniques and open-ended questions.

Document and validate all assumptions.

Leverage the use case scenarios to confirm the accuracy of BRD.

Ensure use case scenarios tie to business goals.

Build organizational connections and trust relationships between business organizations.

Affinity Group 3: The execution was flawed

Why? Problems were not identified until it was too late to change them.

Why? Problems were not recognized until the Test portion of the development or project.

Why? The technology aspect of the solution works, but does not effectively solve the business problem.

Why? There is a cultural bias toward IT when making tradeoff decisions between competing priorities.

Potential Solutions:

Use an iterative methodology instead of traditional waterfall methodology when a high risk of foundational changes is present.

Consult a business representative when making tradeoff decisions.

Obviously, this is an abbreviated root cause analysis, but all the issues here come from real-life examples, and many of the solutions have proved to be very successful. If your IT-based PMO is failing your internal business clients, try this exercise yourself. To get the best results, include all the members of your PMO, and include the businesses you serve as well.

Reprinted with permissions from Steven Selikoff

Analysis

This survey is IT based, but looking at the different affinity groups, I think it can be scaled across other industries quite easily. Steven lays out three major areas that PMO managers must be tracking and watching closely.

Let’s review these areas now.

Affinity Group 1: The PM Did Not Fully Understand the Needs of the Business and the Potential Negative Impact of the Project Solution

When you think about the art and science of project management, the art part consists of business knowledge, business acumen, communications, and leadership. Sadly, not enough project managers take the time to explore this part of the project they are managing. In their haste to check boxes, they miss the opportunity to dive in and really understand what the project is trying to achieve.

Steven is spot on when he suggests you assign business representatives to act as SMEs. Project managers can then partner with those SMEs to understand both the business and the goals of the project. Working with an SME is one of the quickest ways for project managers to ramp up on the business without derailing the project. Steven’s fifth solution—training the IT PM on the specific business—is also great advice.

Affinity Group 2: The BRD Was Flawed

There are tons of reasons BRDs may be flawed—and these reasons often have nothing to do with the project manager. When business analysts with little or no business knowledge throw together the BRD, that BRD will almost always be flawed. To identify these flaws, the PM must ask the right questions.

I love Steven’s potential solutions—particularly the ones that involve employing use-case scenarios. With use cases built into standard operating procedures, the project manager and project team can work hand in hand with the business to ensure the BRD captures exactly what it should, thereby reducing the chances the BRD is flawed. The employment of use cases, as well as the implementation of formal signoff and approvals, can easily be achieved, and should be made standard practice in PMOs.

Affinity Group 3: The Execution Was Flawed

This is probably the most logical reason PMOs and projects fail. Indeed, if you do even minimal research on this topic, you’ll find survey after survey on project failures. Although Steven’s suggested solutions are good ones, the sad fact is there is no easy answer here.

That being said, I have one additional suggestion, above and beyond the ones Steven provides: tracking lessons learned on all projects. PMO managers should mandate the tracking of this information and make course corrections based on findings as a standard part of project execution within the PMO. In this way, the PMO manager can reduce the chances of failure and improve project success rates. But again, there is no silver bullet here. As projects become more complex—spanning such areas as IT, construction, marketing, research, and more—ensuring flawless execution becomes that much more difficult.

Let’s look at our final survey on why PMOs fail.

Why PMOs Fail by Yolandi Nortje"

The outlook for the project management office (PMO) may be considered, by some, as bleak, says Yolandi Nortje, an executive at Intuate Group. According to the Association for Project Management, 50% of PMOs close within three years, with Gartner quoting just over the same percentage for the correlated PMO implementation failure rate since 2008.

An IBM change-management survey of 1,500 executives found that only 40% of projects meet schedule, budget, and quality goals, while Standish Group's CHAOS report cited a mere third of all projects being successfully completed on time and on budget. With 68% of stakeholders perceiving their PMOs to be bureaucratic, according to the 2013 Gartner PPM Summit, it is easy to see why we have used the word bleak.

One of the prevailing issues