Five Signs Your PMO is not Meeting Your Organization’s Needs

Cool article I found and thought I would share with complete attribution.

Five Signs Your PMO is not Meeting Your Organization’s Needs

Published by Brad Egeland | June 21, 2009

I’m assuming that most of you are like I am…you’ve been part of organizations that had good PMO’s, bad PMO’s and no PMO’s. What set the good ones apart from others or at least seemed to make a difference? Or if yours was bad – what made it so? Why, in your mind, was your organization not served well by the presence of or creation of a Project Management Office? And if you do not have a PMO, do you think your organization would be well served by one? Why….what is lacking that you think a PMO would fill?

That’s a handful of questions and I’d like to hear feedback from anyone willing to offer information and answers – either anonymously or not.

Let’s assuming you’re in the category of individuals who think your organization is not being served well by your existing Project Management Office. I’d like to hear your thoughts and reasons, but first I’m going to take a stab and what I believe are five reasons that the PMO sometimes does not meet the org’s needs.

• Executive Management is not Included in the PMO Process
• Training Plans are Non-Existent
• Common Templates and Processes do not Exist
• Poor Upward Project Reporting
• Major Projects Circumvent the Process

Let’s look at each of these in a little more depth…

Executive Management not Included in the PMO Process

This one means exactly what it says. If your Project Management Office acts independently and either doesn’t report detailed project status up to executive management or if executive management doesn’t care what your PMO is doing, then your PMO isn’t relevant to your organization and it isn’t serving it effectively. That may be the PMO’s fault and it may not be. It’s sad if you have a PMO that your CEO does not find important enough to follow, view project status or have any interaction with. Either your PMO Director is not promoting your PMO well, proper and meaningful reporting is not in place to make it relevant, or your CEO is clueless.

Training Plans are Non-Existent

Most project managers could use additional or refresher training. Technology changes, better processes evolve, and – in the case of IT shops – application development processes can change. To stay current, to stay cutting edge – there needs to be training plans in place for the members of the PMO. Otherwise, even if your PMO is important to your organization now, it may become irrelevant in the future as more and more PMO members become disgruntled with lack of growth opportunities and move on to other positions and companies.

Common Templates and Processes do not Exist

If your PMO is flying by the seat of it’s pants, then it’s not functional and it’s not likely to last. It must have repeatedly process to be relevant and for the company to have confidence in it’s effectiveness. Otherwise, no one will no for sure why one project was successful and another was not. With no consistency your organization will not know what to tweak or fix in order to make things right or better next time. Lessons learned will mean nothing if there is no consistent process and no consistent, meaningful templates in place.

Poor Upward Project Reporting

This one takes us back to the first point…the involvement of executive management. Exec management may not care or get involved and that’s bad…but if there’s no meaningful mechanism by which to report project portfolio status (dashboards, etc.) to executive management, then it’s very difficult to show or prove PMO relevance to them. You can show them how the PMO is making a difference if you can’t show them what that difference is.

Major Projects Circumvent the Process

This one may be the biggest tell tale sign that your PMO is not serving the organization well. If smaller and less meaningful projects are being run through the PMO and managed by project managers…then that’s great. But if they major projects go elsewhere within the organization and are managed by individuals that are not part of the PMO, then it’s obvious that executive management lacks the confidence in the PMO that is necessary to make it an integral part of the company’s success.

Delusional Project Management

The Diagnostic and Statistical Manual of Mental Disorders defines Delusion as follows:

"A false belief or incorrect inference about external reality that is firmly sustained despite what almost everybody else believes and despite what constitutes incontrovertible and obvious proof or evidence to the contrary. The belief is not one ordinarily accepted by other members of the person's culture or subculture."

I have seen a number of examples of Delusions in Project Management. One example from a while ago was a client decided while they could not do Project X which had medium complexity and would take 12 months, but could do Project Z that included Project X but do it all in 6 months.


Clearly individuals who are not clinically delusional can gather together into a team and collectively be delusional. I am sure there are many examples of such behavior.


What I am wondering is are there good methodologies for doing organizational psychotherapy to help such organizations and teams perform better?

Building Collaborative Teams

"We found that the greater the proportion of experts a team had, the more likely it was to disintegrate into non-productive conflict or stalemate." This is a statement made by Lynda Gratton and Tamara J. Erikson in the Harvard Business Review article “Eight Ways to Build Collaborative Teams” from November 2007.

A lot of the projects I am involved with require a large number of experts on very large teams. Some of the projects I am involved have non-productive conflict and stalemate at certain times. However that may be due to selection bias: my expertise lies in large complex projects that are in trouble.

So I would like other readers and contributors to this Blog views on two things:

1. Anecdotal evidence that supports or not the primary thesis: lots of experts leads to non-productive conflict and stalemate.
2. Some specific ways they have mitigated or proactively prevented such conflict from arising.

Who makes a good Project Manager?

Project Manager has become a valuable title and as with all such things lots of people want that title whether they are qualified or not. Credentials are definitely one way to tell if a person is qualified to be a Project Manager. There are now degree programs at major universities and there is the Project Management Institute certification (PMP) that can help identify the committed professionals.

However you as I have known great Project Managers who don't have any of these credentials and we have perhaps run across a number of persons with the credentials who are ineffective project managers.

So what makes a project manager good?

One point of view is provided here: http://www.ithealthcareblog.com/archives/12#comments by Susan McClafferty.

What do you think?

Smart Tips to keep your project on track

Baseline magazine has an interesting article on effective project management called "8 Ways To Save Your Next Project" by Elizabeth Bennett. The article is worth a complete read and can be found here: http://www.baselinemag.com/article2/0,1540,2235679,00.asp

The summary is Project Management is an exercise in active and proactive management. What do you think?

Is there such a thing as too much staffing?

Many of us learn early in our lives all things, even good things, must be taken in moderation. Staffing for projects is one such good thing. I am sure we have all experienced projects that are run with too little resources. We know the normal symptoms of a project that is resource starved -- delays, quality and morale issues and perhaps failure.

However what would happen with a project that has too many resources? Would Brooks's law, which says that adding manpower to a software project that is behind schedule will delay it further, apply? Lets further complicate the issue by asking what would happen if the project begins with too many people to begin with, i.e. people are not being added late.

There are two common explanations for Brooks's law (http://wen.wikipedia.org/wiki/Brooks%27s_law) :

1. New staff take time and resources to ramp-up and are therefore not immediately productive and distract the experienced resources.

2. Communication overhead increases as we add more people. The number of different communication channels go up a square of the number of people.

However when the project is new problem #1 (ramp up time) is not a large contributor. However problem #2 -- communication overhead is a killer.

There is a 3rd problem that arises in the most extreme cases over-staffing; when the number of resources available exceeds the amount of work that can be performed at that time. When this happens in a manufacturing process we have idle machines. Machines are not aware of being idle and do not react to their idleness. People tend to be very aware of being idle. Idle machines might be ignored or eventually redeployed, Idle people usually become unemployed. So people start manufacturing work to stop being idle.

Work manufacturing can happen in two broad categories: scope creep and process creep. Scope creep usually refers to uncontrolled changes to a project's scope, but I am using it to mean changes that are not necessary to deliver the business case for this project.

Process creep is like scope creep except the changes are not made in deliverables of the project but the steps used to create the deliverables and manage the project. Of the two process creep is the more insidious because it is much harder to detect and control.

Good project gone bad

So you have a project plan, you have contingency plans, you have a methodology, you have a PMO and your project still goes to hell in a hand basket. What do you do?

There are simple options that are not really the purview of Project Management but need to be acknowledged first. Option 1 is ignore it. There are a lot of variants of "ignore it" which include "assign blame", "I am a victim" and "this is the way all projects of this kind go" etc.

The other simple option is to disengage. Disengagement can occur in a number of different ways which can range from people leaving the team to people withdrawing ideas and effort short of leaving the team.

If you are the PM or responsible leader for this project and cannot personally follow a simple option, it will still be important to remember that others have simple options.

If you are responsible for a turn-around strategy for a project:

Step 1: Recognize the situation requires a turn-around
Step 2: Assess the current state
Step 3: Define the goal state and how the current state deviates from goal state.
Step 4: Define a turn-around plan. Check if the project is still worth saving.
Step 5: Get buy-in
Step 6: Start the new project.