Do you need a PMO or an RMO?

Since Binocs was first launched, I have primarily been focused on how to help organizations improve their resource utilization, especially for knowledge workers in environments such as engineering, R&D, Quality, and regulatory operations.

Across all of our implementations over the last 8 years, we have set up a range of different processes for managing: capacity, demand, resource allocation, resource planning, training, working standards, and much more. With each new implementation, we establish a “catalyst” role to make all these processes work in an efficient and sustainable fashion.

Although we have never formally named this catalyst role, a spark of inspiration made me think of the term “Resource Management Office” or RMO. It’s a logical extension of PMO (Project Management Office), a well-established function among large, project-driven organizations. But how do the two differ?

In many of our implementations, we have successfully used our zero-code interfacing approach to seamlessly connect Binocs with an organization’s existing PMO tools, however this raises an important question: why wasn’t their PMO function already closing the resource management gap? Is it because PMOs tend to be very project portfolio centric?

This can certainly lead to a number of shortcomings, as we have already described in a previous post, but I feel that it must be due to something deeper. The more I thought about it, the more questions it raised: aren’t PMOs missing something critical that would add greater value to operations at knowledge worker organizations? Are they missing and extra… leg?

Should companies instead be establishing a PaRMO, a Project and Resource Management Office? We all know that there’s no such thing as an original idea, someone else must have already walked this path, so I Googled “Resource Management Office” and, surprisingly, there were only a handful of hits that made sense.

Here’s how NASA positions their RMO:

The Office provides monitoring, analysis, and reporting across the full breadth of the Directorate’s financial and workforce resources. The Office trains and manages the co-located Resource Analysts who work within the various Offices and Divisions to implement effective and efficient use of resources. It also provides proposal support to NASA research.

Although this definition has quite some room for interpretation, it’s pretty much the same role that we setup during our Binocs resource management projects! Indeed, for operations where 70% of the effort is dedicated to routine work and only 30% is project-related, we strongly recommend setting up an RMO function, not a PMO. That has long been our philosophy and continues to be a guiding principle when scoping new implementations—and we know it works.

When, on the other hand, the majority of a team’s time is dedicated to project work, does it still make sense to draw an RMO on the org chart if there is already a PMO?

Possibly not, although I would argue that we do need to consider tweaking the conventional approach to PMOs a bit, to better cope with the needs of resource managers. PMOs typically define resource allocation as one of their key areas of responsibility but, truthfully, I have yet to see any that manage this aspect effectively. But, before we dive into it, I should briefly outline the different types of PMOs that exist across the scope of commercial functions.

Here is how the Project Management Institute defines different PMO frameworks:

1. Organizational Unit PMO/Business Unit PMO/Divisional PMO/Departmental PMO
   “Provides project-related services to support a business unit or division within an organization including, but not limited to, portfolio management, governance, operational project support and human resources utilization.”
2. Project Support/Services/Controls Office or PMO
   “Provides enabling processes to continuously support management of project, program or portfolio work throughout the organization. Uses the governance, processes, practices, and tools established by the organization and provides administrative support for delivery of the project, program or portfolio work within its domain.”
3. Project-Specific PMO/Project Office/Program Office
   “Provides project-related services as a temporary entity established to support a specific project or program. May include supporting data management, coordination of governance and reporting, and administrative activities to support the project or program team.”
4. Enterprise/Organization-wide/Strategic/Corporate/Portfolio/Global PMO
   “The highest-level PMO in organizations having one, this PMO is often responsible for alignment of project and program work to corporate strategy, establishing and ensuring appropriate enterprise governance, and performing portfolio management functions to ensure strategy alignment and benefits realization.”
5. Center of Excellence/Center of Competency
   “Supports project work by equipping the organization with methodologies, standards and tools to enable project managers to better deliver projects. Increases the capability of the organization through good practices and a central point of contact for project managers.”

[Source]

At Binocs, our resource management implementations deal mainly with matrices of projects where, as outlined in the diagram below, services and resources are requested from multiple functional teams. Given this context, I would argue that it is rather difficult (and, in most cases, a waste of energy) to try and integrate an RMO into frameworks 3, 4, and 5, which are much more focused on projects and strategies, rather than the day-to-day allocation of individual resources.

By contrast, frameworks 1 (Organizational Unit PMO) and 2 (Project Support PMO) are absolutely a suitable target for an RMO / PMO assessment, and this is where Binocs really shines.

Project organizations that operate in a matrix need to close the RMO gap to claim a true resource assignment function.

PMO functions tend to team up with project managers and, together, they view senior managers and project/program sponsors as the primary stakeholders. However, what I think this 2nd little leg under the P highlights is that resource managers must also be recognized as major stakeholders. Functional teams are the delivery engines of the project portfolio and, in many cases, they simply aren’t granted the visibility they need to keep those engines running efficiently. The PMO needs to facilitate and organize this visibility, and that means accommodating the full span of work requests, not focusing solely on the priority projects in the portfolio.

With that in mind, it should be immediately clear from the above diagram that there are a lot of PMO responsibilities that simply cannot be fulfilled without a robust and effective resource planning platform. This, in turn, requires a change in the organizational mindset: gone are the days where each functional team can rely on building and maintaining their own homegrown and highly complex Excel planning sheets. At best, these offer limited transparency and connectivity between functions; more commonly, they actively undermine any progress towards achieving end-to-end project and resource management goals.

Instead, organizations who want to attain a greater level of maturity in project (and portfolio) management need the support of a resource management platform that fully engages the resource managers, the project managers, and the PMO.

So, should we name it PaRMO after all?

Looking to enhance your PMO with a world-class resource management solution? Let’s talk Binocs!