A Focus on Resource Management is Value Deferred

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:

  1. 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.
  2. 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:

  1. 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.
  2. 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.
  3. 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.

Advertisements
A Focus on Resource Management is Value Deferred

3 thoughts on “A Focus on Resource Management is Value Deferred

  1. Doug Welsby says:

    Andrew – another great post, thank you. I like the “attack the issues from a different angle” thinking. With your alternative approach, and I’m thinking about prioritization of projects, won’t we just end up with a different problem to deal with? We’ll have a prioritized list of projects, but won’t have the resource capacity information at hand to determine where the cut-off is. The business will have agreed to a prioritization approach, but the PMO will still need to determine resource capacity in order to assess their ability to deliver.

    Showing value immediately is always critical as we implement solutions such as this, so the prioritization approach is indeed faster and cleaner. I just think we need to consider both sides – the prioritizations of the business, and the capacity of the PMO – before we get any truly valuable results.

    Thoughts? And thanks again for your insightful postings.

    1. Good question. I’d say this represents an evolution in my thinking. I agree that, intellectually, if I, the PMO, collect the resource data and present it to my customers, that should force them to engage in constrained optimization. That’s the underlying premise of tackling resource management first.

      That being said, in the last year or two, I’ve been exposed to a number of failed attempts to do that very thing. It’s almost always blamed on user adoption when it fails, i.e. the PMO couldn’t get everyone to “buy in” to capturing detailed resource forecasts. Hence this post.

      As for resource management in a prioritized environment….that’s easier. Publish the list of projects, in order of priority. Ensure everyone knows what the priority is. Pretty soon, resources will resist being pulled off a high priority project to work on a low priority project. That then leads to a prioritized work backlog – which then changes the thinking. Instead of committing to all of the projects in an annual plan, we’re committing to the highest priority projects now, and rebalancing periodically in the future.

      Capacity is still a large part of it, but capacity was never the hard part of resource management. It’s always been the ongoing forecasting and reforecasting exercise for all of the projects in execution that’s been the hurdle.

      To simplify even further….allocate capacity to programs as part of the program budgeting process. Then let the program manager handle allocating that downward within the program. That structure would only work if the prioritization was allowed to determine program funding though.

      I’m sure this will turn into another blog post pretty soon now I look at it…..

  2. baileyaaronr says:

    Great post. At my current client–a mid size health provider–we had to tackle the problem of selecting a portfolio where resource constraints were the deciding factor. Last year we made the selection by having the twelve mid-level managers do a one-time rough estimate of the availability of the resources who reported to them. We also focused on getting good estimates of the effort for the project pipeline, as Andrew suggests here. That approach was much easier to achieve than a full resource management solution, and it was successful enough that we are now implementing a full resource management solution with time sheets and actual time reporting from everyone on the team (rather than just estimates from managers). Getting buy-in and adoption on actual resource availability data has been much easier since we have proved our ability to use estimated resource information to select a portfolio.

    If I was asked to implement resource management again, I would break it into two phases–portfolio selection using resource estimates first and then portfolio selection using resource actuals. As Andrew points out, it’s much better to be sure you can make decisions with resource actuals before you go out and collect them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s