What is the purpose of a Project Management Office? Before you answer, consider the analogy of the purpose of your local newspaper. Why do you think it exists? To inform its subscribers of goings-on? To chronicle the occurrences that influence the community?
No. The purpose of a newspaper is to sell advertising space. Not what the J-schools would ever admit, but undeniably true. Before I re-ask the question in the first sentence, let me invite GTIM Nation to reevaluate the purpose of the PMO along similar lines, because I want to submit that it’s not what most of us have been led to believe. What follows is a short list of the things that the PMO should never attempt, much less internalize as a key goal.
- The PMO is not there to dazzle the other parts of the organization with their advanced expertise in the way their projects ought to be managed. This is true for two main reasons: (a) the people actually performing the technical scope of the project tend to focus on just that, and will see non-technical people from outside their particular project team as interlopers at best, interference agents at worst, and (b) our friends the accountants have a 500-year head start on creating the narrative that Generally Accepted Accounting Principals (GAAP) are the way of tracking cost performance on any business endeavor. This means that any group that attempts to advance a different notion of the optimal business approach will be seen as interlopers at best, interference agents at worst.
- The PMO is not an agent of organizational change. Yes, I know this is a radical assertion, but consider: the project team that is being forced to accept what the PMO has decided is advanced PM techniques against their wishes will abandon them the nanosecond they are allowed to do so. The project team that has elected to employ the services of the PMO will continue as long as the PMO offers a desired service at an acceptable price point.
- The PMO is not a vehicle for upper management to harangue the project teams into performing better. I’ve witnessed this mal-formed strategy time and again. Recall from last week’s blog, the step where the organization’s executives, stung by a prominent project overrun or delay, has agreed to invest in the creation of the PMO. When this strategy is being employed, the PMO is typically started with a generous overhead budget. As the new PMO begins to churn out official procedures and policies, mandating what the project teams must do in addition to what they’re used to, some level of resentment becomes imbedded in the organization. When the project teams begin to opt out of the reporting requirements, executive frustration sets it, but not with the non-performers themselves. It’s always with the PMO. The PMO was supposed to change the poor performers into good or great ones, right? What then follows is a reduction of the overhead budget for the PMO, with a requirement that its members charge more of their time directly to the projects they “support” – the very same projects that have been incurring resentment-by-proxy against their agitating superiors, with predictable results.
- The PMO also isn’t there to kibitz about what could go wrong, phrased in Gaussian-curve jargon (GTIM Nation didn’t think I’d get all the way through this list without an anti-risk management snark, did you?).
In short, the PMO can’t directly change behavior, can’t educate the uninterested, and will fail as a proxy for frustrated upper management. Again, what is the PMO there to do?
Simple, but utterly at odds with conventional wisdom: the PMO exists to put into the hands of the decision-makers what they need to make informed decisions. Assuming this simple mission is the correct one (and it is) brings with it some specific strategies, again well outside conventional approaches. These include:
- Wherever possible, don’t change anything about the way the project teams currently conduct their business. It sounds impossible, but it’s not. For example, need a basic Earned Value Management System, but you’re unable to pin down the project team’s principals in order to get a Performance Measurement Baseline in-place? Here’s a quick solution: the Estimate at Completion (EAC) can be accurately (+/- 10%) calculated by dividing the project’s percent complete into its cumulative actuals. That’s right: TWO data points, one of which is already available via the General Ledger. Compare that to the project’s budget (also available through the General Ledger), and you have a usable Variance at Completion, which I would argue is the single most important piece of information that an EVMS can generate. (Extra credit PM hack: the same formula works for duration.)
- When you absolutely, inescapably need to change some part of the business process, make it as falling-off-a-log easy and simple to do. This will become essential when…
- In those instances where even a demonstrably simple change is blocked, respond immediately to the ones who are not participating. Make it clear to whatever organizational element that gave the PMO its initial authority how easy and simple it would be to comply with your suggested change.
- Every single person who cooperates with your implementation is golden, even if they are providing schlock data. Better data can be taught, cooperation cannot.
Counter-intuitive? Sure. However, as available strategies for implementing your PMO go, this one has one distinct advantage: it’s aligned with the true purpose of the Project Management Office.
And that advantage is really all you need.