Some highlights, at least from this attendee’s perspective.

Interesting Research:
Two researchers, Brian Hobbs and Jim Pennypacker, presented some interesting survey data on PMO’s in general.  The highlights, from my point of view:

Best Practices:
Here’s a question I get asked with almost every PMO engagement – what are best practices for a PMO? Hobbs’ research indicates some interesting facts that back up my own anecdotal perceptions.  First, there is no real agreement on what a PMO is, let alone what would be best practice.  Let’s start with the meaning of the term.  Is it a Project Management Office, a Program Management Office, or something entirely different? In my own practice, I’ve seen Project Support Office, Project Guidance Office, Project Center of Excellence and several others. Pennypacker uncovered some truly interesting names, including “Office of the Multi-Year Plan” and “Innovation and Planning”.

The mandates of these PMO’scover that gamut from managing single projects and programs to the Strategic Project Office (per Pennypacker), which can engage in  Project Governance, Portfolio Management, and Resource Optimization.

One area of agreement was that there is a sub-set of services, yet to be defined, that are generally offered by PMO’s, depending on their mandate, and that it may be possible to create best practices around these services.

Industry segments and company size:Of real note, Hobbs’ research showed no correlation between the type and mandate of PMOs by vertical industry or company size. If there is a common thread, it is that PMOs are formed to solve specific problems, and their mandate stems from this.  They are usually born from a specific pain point, such as poor project execution, resource overload, or poor portfolio visibility.

Where do Project Managers report?The research, and my own anecdotal evidence, both suggest there is no best practice around this. In Hobbs’ research, 50% of the PMOs surveyed have project managers reporting to them.

What correlates with success?Hobbs’ research suggests some correlation between perceived legitimacy of the PMO and a few key factors:

% of projects within the PMO’s mandate
% of project managers reporting to the PMO
Decision-making authority
Resources not matrixed
Supportive organizational culture
Project Management maturity
Number of important functions

So much for the interesting research.

Marketing the PMO:

Hugh Woodward presented some compelling information, based on research, on how to market a PMO.

First and foremost, he suggested using business terms instead of project management terms for measuring and promoting success. So, instead of touting how many projects are on-time and on-budget, talk about how a project is improving profitability, increasing market share, or otherwise improving business conditions in terms commonly used by your executives.

Hugh also notes the importance of linking projects to strategic objectives and value. This is a theme that was, of course, repeated throughout the conference.

Finally, be willing to change or kill projects as business conditions change. This is not a sign of failed project management, but rather shows the PMO’s flexibility and understanding of business. Projects do not exist for their own sake, and if there reason for existence changes, change or eliminate the project. Hugh gave an example of a project that was originally scheduled for 18 months, but ended up improving productivity so well, the life of the project was extended to 5 years to add scope and take the new techniques enterprise-wide. While this project may look years late, it was actually a huge success when measured in business terms – increased productivity!

Case Studies:

If there were common themes  to this Symposium, it was found in the case studies and the information gleaned from all the networking with other attendees and presenters. The basic ideas were:

Successful PMOs focus on business results, not common project metrics

The Strategic PMO is becoming more common, and is often located outside of IT at an enterprise level. Even PMOs that started in IT are graduating to the Enterprise level. The common term here is now EPMO – Enterprise Project Management Office

Enterprises often have multiple PMOs, facilitated by  the new EPMO

If there are causes for PMO death, it is typically that the PMO forgets its business purpose and becomes a bureaucracy. There is a related symptom I like to call “The Methodology Police”. Both of these symptoms alienate project managers and stakeholders alike.

Who should staff a PMO?

This question came up repeatedly, and consistently received the same answer, including by yours truly during the panel discussion. If we’re talking about a Strategic PMO (not a program specific PMO), the PMO head and key staff should be business leaders first, and project managers second. They are the link between corporate strategy and execution through projects, and need a solid understanding of the underlying business. The project management expertise needs to be there, but the business knowledge is critical to success.

So, here are my most commonly observed PMO mistakes. Feel free to add your own or comment on these!

1. PLAYING COP. If there is a common refrain to failed PMOs, this is it. The PMO becomes the “Methodology Police” and enforce an often ill-fitted SDLC rigorously. This leads to complaints from project managers at best, and open revolt and ignoring the methodology at worst. Rather than becoming an aid and guide to project managers, and creating consistency in PM practices, this PMO has become the PM’s worst enemy, loses visibility into the project portfolio, and leaves a bad taste in everyone’s mouth.
2. IMPLEMENTING AN SDLC. OK – this might sound heretical, but hear me out. I have seen many PMOs implement an SDLC, literally a “Software Development Life Cycle”. This is great for the software development team, but drives the infrastructure and process improvement folks nuts! The point here is, one size does not fit all. A better structure is an overall project management framework, with just the basic phases and gates and a few key controlling artifacts (business case, project schedule, status report, etc.). This is sometimes known as a PDLC (Project Development Life Cycle), and many different SDLCs can fit under the framework, tailored to the need of the project type.
3. NOT IMPLEMENTING A METHODOLOLY. What, am I contradicting myself? Not really. If the PMO does not implement some kind of overarching framework, it cannot create an apples-to-apples view of the projects in the portfolio. Further, federal regulations, especially Sarbanes-Oxley, require methodologies that meet their requirements.
4. NOT MATCHING DEMAND TO SUPPLY. I’ve sat in on many a Steering Committee meeting, and the focus is almost always on prioritization. That’s great, and a good prioritization process results in a good understanding of project demand. But when it comes to deciding how many of the top projects can actually be done, discussion usually turns to pure guess work! – “How overloaded is you department, Tom?”. “If we take on the top 10, can we handle the load?” Without a metrics-based understanding of resource capacity, it is impossible to match that wonderfully organized demand with the actual supply of human resources.
5. NOT LOGGING TIME. This is actually the source of number 4. Without tracking actual time worked on actual projects AND other work, it is impossible to know any department’s true capacity. Planning, even at the most detailed level, is merely guesswork if it does not involve the feedback loop of actual time.
6. GATHERING UNECCESARY INFORMATION. PMOs are great at gathering all sorts of statistics, from very detailed SDLCs (see number 1 above!). If that information is not used in the decision-making process, why gather it? It just creates an extra burden on the project team without generating any useful result. Example: gathering time data at the detail task level, including sub-day tasks like “Enter time”, “Check email”, “Respond to email”, “Attend staff meeting”. These may be useful reminders as tasks, but for planning purposes all we really need to know is how much time each resource is spending performing “Admin” tasks.
   
   That’s my list for today. I’m sure you have others to add to the list – please do! And if you want to hear more on any one of these topics, please let me know. I’ll try to address it in a future Blog.