• Increase font size
  • Default font size
  • Decrease font size
Home Blog: Back From Red General Blog I Want A Shining New PMO, Too
E-mail Print PDF

I Want A Shining New PMO, Too

Last week I gave a presentation at the San Diego PMI Chapter's Tutorials conference. Flanking both sides of my ten o'clock presentation in the leadership track was Steve Romero. His two presentations were on IT governance. His energy, insight, enthusiasm, and passion (not to mention being the IT governance evangelist for CA Technologies) made him an excellent selection. And, what is so news worthy about that? Nothing. However, for someone that has little regard for adding one more layer of management to solve a problem, I was surprised that I sat through both of his presentations. He provided a three hours of information on governance—both PMOs and PPMs—crammed into two intense and valuable hours.

Still A Nonbeliever

Unfortunately, he failed to gain a convert. The problem is that I have seen too many PMOs that were (and still are) useless. As I digested what he said, believing that he really has seen PMOs work and trying to reconcile his ideas with my experience, I came to a couple of conclusions.

Image of the gap between IT and the business
Figure 1

First and foremost, people need to define what they are asking for when implementing a PMO. My first step is asking why they are considering implementing a PMO. I listen to their attempts to assign traits, "It provides governance," "It monitors projects, providing normalized metrics to compare dissimilar projects," "It makes sure projects are following the right process," and so forth. Trying to get them to realize they are talking about solutions, I reiterate my question, "What does the acronym mean?" In near three-part harmony, they respond project, program, and portfolio followed by management office. Those three P's define wildly different scope. Puzzled participants ponder the problem for a few moments then I suggest, "If we cannot agree on that 'P', then maybe it will help to know the fourth 'P.' What problem are you trying to solve?"

What is Your Problem?

Image of PMO filling the gap
Figure 2

This starts a flurry of comments. The most common being, "We need a consistent method for running projects." Unfortunately, that is not a problem; once again, it is a solution. Eventually the lights come on and someone in a resigned voice says, "Our customer does not like what we are building," or, their close cousins, of excessive cost and late delivery. Now, those are problems. As we drill into the meaning further, we inevitably land on a point that Steve makes in one of his first few slides. There is a gap... no... a chasm between the supplier and the customer. (Steve, being an IT Governance evangelist, says IT, but the problem exists in nearly every project-based discipline.) Trying to get alignment with someone that you rarely see is nearly impossible. System integrators, product developers, and service providers all agree on a solution—if you are unable to deliver what the customer wants, get closer to your customer. Hence, the disconnect with Steve, how does adding a layer of management between the customer and suppler close this gap? It doesn't; it fills the gap and the distance remains. This is where PMOs fail. They lose track of the problem they are trying to solve.

Getting Closer To The Customer

Image of removing the gap
Figure 3

My suggestion is to move closer, literally, to the customer. Move your office, collocate resources, or take them to lunch, do whatever it takes, get to know them and their business. Move the people that will build product or deliver the service as close to the customer as possible. This is one of the key attributes of Agile—the people building the product and the customer or end user are sitting together; the customer directs building a value-laden product.

Sticking with the IT world for an example, a majority internal IT departments are very isolated from the business (Figure 1), hence the gap. Instead of layering a new group to fill in the gap (Figure 2), take the resources that build the product or service and move them into the business unit (Figure 3). Here was my second conclusion: how Steve's concept of a PPM becomes viable. PPM, by most definitions, means Portfolio and Project Management. However, I prefer the term Portfolio Planning and Management. It is more meaningful. The functions are the same as Steve purports—making sure the organization (not just IT) is working on the right things. The key is that the PPM group must have enterprise authority to prioritize projects and validate value to identify which are viable and, if trouble arises, which to abandon.

No More IT Projects

Delicious Delicious
Add to Technorati Favorites

As I mention in a prior blog, to some people's dismay, there are no IT Projects. There are business initiatives with IT components. Likewise, some business initiatives are devoid of IT requirements, but still utilize critical business resources. If you are going to do real portfolio planning and management, then you need to include the entire enterprise. A managerial layer filling a gap between two groups cannot accomplish this. It must be done by the tier above those groups—a layer that, for the most part, already exists. In other words, key players are the executives, in many cases the C-Level executives. They are the only ones that can ensure a proper direction. Stating the obvious, having executive management properly aligned and active in the project execution will improve project outcomes. Am I saying that lack of executive involvement in projects is the reason project failure rates are so high? I will let you draw your own conclusion.

Tags: , , , ,

Previous Blog Next Blog


0 # Steve Romero 2011-05-23 12:30
Hi Todd,

I think we might actually be in violent agreement. I very much agree with you that many PMOs aren't very useful. As I said at the onset of my PMO presentation, I want to help PMOs elevate themselves from paper pushers and process police to participants in enterprise success. I also agree with your assertion most PMOs (and most processes) focus on the solution and loose site of the problem (if they ever had the problem in their sites at all). That is why the first two slides of my PMO presentation list problems and why I hammer the audience to figure out what problems they want the PMO to solve so they can identify the specific business objectives of their PMO. Here is a link to a post I wrote titled, "What's your problem?"

I don't agree that the idea of a PMO should be abandoned simply because so many of them fail. I believe PMOs can deliver incredible value if they are chartered and managed correctly. As you know, I discuss this at length in my presentation:

Let's close on another point on which I do agree with you, there are no "IT projects" - another favorite topic of mine

Steve Romero, IT Governance Evangelist
+2 # James Buchanan 2011-05-24 06:31
Just a few thoughts…

I have been in project management for over 15 years, and an advocate of Agile for almost 9. I could not agree more than the traditional PMO structure is of limited value, but I think the problem is both more simple, and more complicated then what you laid out here.

Fundamentally, all projects are run by people, and people tend to have drama. We are fickle, emotional, and often confused at this complicated thing called life. Most problems on teams are not process problems, but human ones. The dev lead hates the QA lead, or the Team feels disrespected because priorities change too quickly. Whatever the beef, it usually has to do with old Maslow, and those needs that we as humans seek constantly.

In most PMO’s you have people who are process thinkers. They became PM’s because they like to control, and to see structure in their world. Most problems they actually approach as process problems, not human ones. The PM’s attachment to process as a solution tends to focus, as pointed out, on creating a solution to the wrong problem, or treating the symptom instead of the disease. The disease being the dysfunctional team, and individuals that are participating in the dysfunction.

I think to find true power, and value in a PMO, you need to change the role of the PM and the type of person you hire as a PM. We are first and foremost coaches, therapists, negotiators, evangelists, and last on the list process keepers and organizers. Ultimately all that process focus was usually done under the mandate of making teams run efficiently, predictably, and in a way that exec’s can measure ROI. Hire a PM with a high EQ, and let them focus on true team dynamics first, allow trust to lead how a team is managed, and then worry about governance as an afterthought that hopefully is given little power to derail the human needs of the team.

Unfortunately these ideas are not very welcome in our left brain dominated corporate world, We live in a society that still believes in the clockwork universe, and that tends to make us thing of each other as machines, or tools to be manipulated and used. It would take VERY enlightened leadership to actually acknowledge these truths, and build a PMO organization with real power and ability to impact the problems teams face.
+1 # Rachel Goldstein 2011-05-24 09:32
Yes, someone who agrees with my PM philosophy!

I've known for a long time that any success I've found in IT project management has been attributable not to technical skills but to the oft-maligned "soft skills". Every technical implementation, EVERY technical implementation, is a political phenomenon, and a project manager needs to figure out the conflicting currents that are affecting progress, and the personalities involved.

Another successful PM tool is kind of a Maslow thing - realize that people, even the ones that may seem "difficult", are actually trying to be good, trying to feel that their contribution is meaningful. Projects involve change, and resistance to change can be better managed if the PM understands that an end user may see process change as a threat because it appears to invalidate the process that he has been using for so long.

I'm a believer in Project Management, but it definitely needs to be an integrated left brain/right brain thing. For an IT project, you have to understand the business analysis and the technical issues, and you have to have a grasp of SDLC, but in the end it's EQ that will bring it home.

Currently comment rights have been restricted to registered users only. Please try registering and logging on.

Who's Listening To Us...

Fortune/CNN Money logo
Forefront's logo
Logo Oregonian/OregonLive
Enterprising CIO's logo
Slashdot's logo
The CEO Magazine's logo

Read and Hear More...

Visualize Your Future

Change how you do business.

Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Looking to buy the internationally acclaimed Rescue the Problem Project?

Image of RPP

For a signed and personalized copy in the US visit the book's website.

Not in the US? Try one of these book stores worldwide

Amazon logo
Book or Kindle
Flag of the United States
United States

Flag of Canada

Flag of the United Kingdom Flag of Ireland
United Kingdom

Flag of Germany

Flag of France

Flag of Italy

Flag of the PRC
Flag of Japan
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Recent and Upcoming Events

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

Critical Chain
by Eliyahu Goldratt

Related Items