A PMO’s job is fundamentally to operate as an investment advisor to the business. A PMO should recommend to the business how to best structure projects and the project portfolio to reduce risk and enhance value. All too often however, while the PMO may be able to perform this function for projects that belong to other groups, it tends to have a blind spot when it comes to the PMO’s own improvement initiatives. (see Chris Argyris’ Overcoming Organizational Defences for more on why this may be the case.)
Nowhere is this more evident than in the resource management discussion. The PMO is usually in a perfect place within the organization to provide resource analytics. The PMO has visibility into all projects in execution. The PMO has some control over each of the PMs managing these projects. The PMO typically owns some form of a PM Information System (PMIS) that has functionality designed to capture all of this data and regurgitate it in the form of colorful, clickable reports.
Hence, once the PMO realizes that one of the fundamental issues impacting project execution is resource contention, it begins a review of enterprise project management systems designed to support data collection and presentation. This endeavor is typically phrased in the context of mapping resource demand (the project pipeline) and resource capacity (the resource pool). Somewhere in this discussion, the consultant (me) will invariably ask, “Why? What’s the goal of collecting all of this data?”
The answer is almost always along the lines of, “We need to show the impact of adding new projects on our resource pool. We need to provide the metrics to justify asking for additional head count to address the sheer number of projects in the pipeline.”
Let’s take a look at the implications of this statement. The PMO is basically saying that the organization is allowing too many projects into the pipeline – or that we don’t have the resources to support this level of project execution, which is essentially the same thing.
The roadmap then for a “traditional” resource management deployment of an EPM system is to implement all sorts of metrics to capture the current resource load, to capture where resources are spending their time, and create all sorts of reporting functionality. Fast forward 6-12 months down the road and assuming we didn’t fail in the all important user adoption, we have beautiful reports; we have resources all captured in a fantastic online database. What do we do with the information?
We take it back to the business and present them with prioritization decisions. This is the point where we might realize that the business is not willing to change how projects are selected – that the business is not willing to converge on a single prioritization scheme. Remember, the entire resource management endeavor was predicated on the idea that eventually we would get to that point where all of the data could shape behavior.
There’s a lot of risk inherent in this approach:
- The risk that user adoption will not happen and resource data will be flawed. This is pretty much guaranteed in the majority of implementations of a certain size.
- The risk that once we collect the data, the business will not be interested in coming together to find new ways to select projects.
Wouldn’t it have made sense to have overcome this hurdle first – then go through the effort of collecting all of the resource data? Wouldn’t it have made sense to assess organizational willingness to even touch this issue – then focus on what the PMO could actually do to generate value?
An Alternate Approach
If we start the improvement process with project selection and attaching estimates to new projects, we mitigate these risks:
- By focusing only on the projects in the approval pipeline, we greatly reduce the number of moving parts associated with resource management in the enterprise. We reduce the complexity and enhance the opportunity to drive user adoption within the constituency that counts.
- We cut to the chase. We identify that the organization is willing to address the fundamental problem – not the availability of resources, but the inability to prioritize the projects. We put the prioritization mechanism in place, then build the reports and data structures to support it. This is important because it lends credibility to the resource management effort. We’re not simply collecting data to collect data, a common gripe. We’re collecting data to support a clear strategy.
- We begin generating value immediately – and don’t invest in 12 months of effort with an uncertain delayed return.
At the end of the day, resource management roadmaps always end up at the feet of the business and the prioritization process. Why take on all of the risk and investment before realizing we’ll fail there? Instead start with the single point of failure, address that, and then move on to the complicated stuff. Fundamentally, that reduces the risk that the organization will invest heavily in a resource management process – only to kick it to the curb when it comes to the actual behavioral change that matters.