The perils of PMO proliferation

Some organizations struggle to improve their PM or project portfolio management capabilities without having a PMO.  However, I’ve also encountered organizations that have established PMOs in multiple functional areas and at differing levels of authority – this situation is equally challenging.

Some of the risks of PMO proliferation are:

- Significant “hard” costs with limited perceived tangible benefits.

- A lack of process or tool consistency across PMOs results confuses PMs, resource managers, team members and other stakeholders and this in turn reduces the “bang for the buck” achieved from the overall organization project portfolio.

- “Jurisdictional” disputes between PMOs can impact credibility, cause communication issues and also reduce overall value received from a portfolio approach.

Large organizations may not be able to get away from having multiple PMOs, but a few ground rules can ensure that these risks are mitigated.

1. Ensure clear authority & mandate boundaries between the PMOs.  For example, if there is an enterprise PMO and a departmental PMO, project portfolio management processes at the enterprise level should be controlled by the enterprise PMO where as project management practices within a department can be controlled by the departmental PMO.

2. Ensure consistent project metrics across all PMOs.  The degree of discipline within each PMO’s methodology can vary, but the metrics that are reported for project status across different PMOs need to be consistent otherwise it is impossible to get an accurate understanding of overall portfolio health.  Beyond the nature of the metrics, the frequency of gathering or calculating of the metrics also needs to be aligned so that executives know that project data is up-to-date across the board.

3. Ensure resource management data and practices are standardized across all PMOs.  A critical foundation to project portfolio management is that organizations have to have a consistent, accurate, near real-time understanding of resource capacity and allocation.  If one PMO is tracking resource data at the individual resource level while another does it at the skill level, it becomes very difficult to look at supply vs. demand at the organization level.  Similar to the previous item, I recommend standardizing on a handful of resource metrics that are tracked in a consistent fashion across all PMOs.  However, as resources can work on projects that span the oversight of multiple PMOs, it is important that resource request, allocation, evaluation and release practices are also standardized across these PMOs to avoid confusion and improve integration.

4. Use common tools across all PMOs.  While the degree of project management discipline might change on a PMO-to-PMO basis, and some of the services provided by the PMO might vary (e.g. one PMO staffs the PMs for its projects while another only provides project oversight) the tools that are used to automate the PM processes should be the same.  If not, significant cost and resource effort will be required for integration, establishing an organization-wide resource pool becomes very difficult, and it is much harder to negotiate for enterprise license or subscription agreements with tool vendors.

Your organization may be experiencing the phenomenon of PMOs spawning like Mogwai dropped into a swimming pool, but this should not imply that the efforts of these disparate PMOs cannot be aligned towards (what should be) a common goal – facilitating the creation of business value.

A dripping faucet or a firehose – which most resembles YOUR project communication strategy?

Communications is the corner stone of successful project management.  Nowhere in the PMBOK or other sacred scripture of project management do we get guidance on how much or how little communication is required.  The unfortunate outcome is that some project managers operate like CIA agents (“This project update is on a need to know basis, and you DON’T need to know”) while others seem to have forgotten that they two ears, two eyes and only one mouth and can’t seem to stop communicating!

Communication is a knowledge area where one size can never fit all – some stakeholders require frequent real-time tweets to be pushed to them, while others prefer periodic higher level status updates that they can peruse at their leisure.

Planning appropriate communications is as important to projects as are scope, schedule & cost planning.  If you don’t develop and get approval from key stakeholders on communication plans as a standard practice when planning your projects, you always risk missing the mark with project information updates.

When handed a project, a core responsibility of the PM is to understand the communication needs and wants of their stakeholders, and then institute procedures to provide their stakeholders with the right information at the right time.  Using manual information gathering and reporting methods, this can be done, but will often reduce the project manager to purely being a project administrator (to say nothing of the likelihood of poor quality, obsolete or conflicting reports).  Once you know a stakeholder’s desired level of detail, communication method (push vs. pull), and frequency of updates (near real-time vs. periodic) you can hopefully leverage technology to reduce this administrative effort.

Whether it is RSS subscriptions, project-focused Twitter channels, dashboards, user-flagged posts or regularly scheduled report runs, so long as the processes are in place to gather project information in a timely, quality fashion  you can hit the right information balance without starving or drowning your stakeholders.

Is your project information System of Record the grapevine?

I’ve written a few posts about the challenge of achieving compliance with consistent project management practices.

One concept I have not written about is the Project Information System of Record (I’ll let you get a Bart Simpson-level kick out of the obvious four letter acronym!).  For those of you that are not from an IT background or have not heard this term before, Wikipedia manages to sum it up quite well as being the authoritative data source for a given piece of information.

When project management procedures are properly institutionalized and these procedures are supported or automated by appropriate systems (read Vaughan Merlyn’s post on the topic of appropriate tools) the Project Management Information System becomes the Project Information System of Record.

Executives treat project information gathered through the grapevine or in elevator conversations as hearsay, and they go to the PM Information System to understand what’s really going on.  That message percolates through the ranks of stakeholders, sponsors and project teams such that the staff responsible for entering and updating project data in the PM Information System know that they need to keep the information A) Current and B) Accurate.

On the other hand, when executives ignore the PM Information System and readily accept project information through other means, they are sending the clear message that the PM Information System is a pale substitute for the grapevine.

The mantra for PM Information Systems should be “If executives swear by it, compliance should follow”.