Sunday, 22 May 2011 00:00

I Want A Shining New PMO, Too

Rate this item
(0 votes)

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

Old IT PMO Image (missing)

Figure 1. Classical IT-Business Relationship

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.

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 (missing)

Figure 2. A PMO filling the gap


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

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.

Removing the gap Image (missing)

Figure 3. Removing the gap


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.

Want to read more?

Executive project sponsorship plagues nearly every project. Our researched-based white paper Challenges In Executive Project Sponsorship uncovers a variety of issues (some specific to healthcare, that are quite unexpected.

No More IT Projects

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.

Read 14511 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References