In the ongoing quest for PMO relevance, many organizations are aligning to the PMO specifications defined by PMI in the Pulse of the Profession report unveiled in last year’s PMO Symposium. In that report, five different PMO frameworks were defined: everything from a PMO stood up to support a large program to the enterprise PMO, or EPMO.
The EPMO is something we see increasingly in large, international corporations – or in organizations that have grown rapidly by acquisition. Usually these organizations have a federated portfolio governance model. There is an organization at the middle, the EPMO, that handles centralized functions such as portfolio selection or portfolio analytics. The actual execution of the projects is then relegated to a PMO that exists within a specific line of business or national organization.
The trick is to look at the capabilities required for project delivery and then to relegate them across the various organizations. Off the cuff, I’d designate at least three categories:
- Capabilities owned and performed by the EPMO – to which I’d generally relegate large, strategic, enterprise crossing initiatives, portfolio selection criteria, and other big picture items.
- Capabilities co-owned by the EPMO and the Regional/LOB PMOs – these would be the basic processes that the PMO must follow to support the overall EPMO activities. Think of things like resource management, project lifecycle management, or those techniques for classifying work and cost such that they roll up effectively to the portfolio level to create those ever so important portfolio analytics.
- Capabilities owned by the PMO – These are the capabilities required to execute a project successfully, i.e. scope management, deliverable management, and all of the detailed requirements that make projects a success. Many of these need to be relegated to the specific group closest to the work to support their local or industry-specific needs.
Another way to group these capabilities lies in whether the portfolio being served directly impacts the client, i.e. a Type I portfolio, or if it’s a Type II Portfolio that supports the layer of the organization responsible for delivering services to the client. I might offer a framework analysis such as the following to help lump capabilities into the right level of ownership.
That’s not to say that an EPMO has no role in supporting the federated PMO structure. In general, we see success rates where the EPMO provides the role of process support, i.e. sharing best practices across the organization on how specific capabilities are performed by the various PMOs – but not necessarily being prescriptive about how those practices are carried out.
How does an EPMO share practices across various PMOs within the organization? Through knowledge sharing and training – through roundtables and lunches. More specifically, we see this done through sponsoring a shared technical platform upon which each of these processes may be enabled. This shared technical platform provides the ability to easily share practices and processes across the organization as they’re developed by each of the PMOs.