I get this question on a regular basis, “Why can’t I just start with Resource Capacity Planning? That’s all I want from our EPM anyway.”
In many lectures when I talk about what is Enterprise Project Management, I show a collection of possible definitions. Perhaps EPM is just system compliance, where everyone uses the same system. Perhaps it’s document management, perhaps it’s timesheeting. All of these answers are potentially accurate for any one organization but there is one answer that is by far the most popular. When I ask what is it you’d like out of your enterprise project management system, they respond “Resource Capacity Management”.
So why isn’t this the first thing that people deploy?
The short answer is that resource capacity planning might have to be the last aspect of your project management system to deploy because it counts on almost everything else. Now, I’m going to take that back in a few paragraphs but let’s take a look at the challenge of the most common expectation for an EPM system.
What do we need for real resource capacity planning?
A schedule of work
We’re going to need to know when things are expected to happen and we’re going to need to know about everything that might have a demand on our resources. After all, what value would a resource capacity plan be if only a fraction of the projects were represented? This can be the first major hurdle for any organization as it requires a centralized collection of all work.
All the resource availability
Of course we’ll need to have all the availability of any workers. That should be easy, right? Well in some organizations it may be, but in many it is not. The availability of contractors for example, may be hard to pin down. It may be hard to identify how much of an executive we can allocate to work, vs their administrative responsibilities. For the long term, are we able to be certain about hiring and firing of people who are, as yet unnamed who will be needed for projects?
The resource requirements
Didn’t we cover that in the schedule? No. Resource loads are, of course, project work but many projects don’t have an accurate accounting of what resource requirements will be for each task. And, the further into the future we look, the less certain we are. Not only that, but resource requirements has to include all requirements, not just project requirements. So, maintenance, overhead and administrative tasks need to be included. Sometimes these are difficult to estimate
Project priorities
We’ll need to know how to sort the projects as we allocate resources or everything will be allocated as though it is just as important as everything else. This seems obvious until you try to do it. Project prioritization can be one of the most contentious elements of resource capacity planning.
A flow of change
As projects, staff and risks change, the three elements above will change. That means that whatever system is created, it will need to be updated constantly. So, updated schedules, updated global resource availability and updated resource requirements have to be brought up to date every week or every month or as often as you’ll make project decisions.
Ok, so that sounds insurmountable, doesn’t it? For many organizations it has been. One of the reasons this is so daunting however has everything to do with the very software vendors who offer solutions to this problem. Many years ago, it became apparent to EPM software vendors that their license revenue would be maximized if enterprise project management meant “top-to-bottom” integration. Demonstration data was created that showed the project from the very highest perspective at the portfolio level all the way down to an individual’s week of tasks. “Look,” they said, “we update this person’s task and it instantly shows up on the portfolio as a change.” That was a compelling sales pitch and given it wasn’t just one vendor saying so, the industry magnified this view and many organizations bought into it.
Individuals were shown on a regular basis in such presentations and organizations dutifully bought licenses for each individual. Resource levelling algorithms promptly broke down. We’ve talked about this too here in these pages. When we apply such algorithms to roles or groups of resources they can be quite effective. When we apply them to individuals they do not. Some software tools instructed their salespeople to downplay the relevance of resource leveling calculations as “dated”.
But does this top to bottom notion make sense? We’ve already discussed in these very pages that when you move from the analytical domain of the project schedule to the commitment based domain of a to-do list that you’re going to end up in trouble. Collapsing those two paradigms is almost never successful. Perhaps those aren’t the only two paradigms that we collapse when we talk about resource capacity planning.
Many years ago I was speaking to someone who was a very senior engineer in an aerospace company. He told me that their project management office regularly sent him lists of “what to do” which he consistently ignored. “If they’re so smart,” he explained to me, “they should get down here themselves and do the work.” He was adamant that the PMO and all their fancy software couldn’t possibly know how to best allocate his team and get work done in the most effective manner.
So, is there a way to have resource capacity planning for the entire enterprise? As is often the case, it depends on how we define it. If we are saying that the vision of top-to-bottom-all-integrated-to-the-individual-schedule is the goal, then you’ll need to create that much more complex corporate process of getting everyone on board. However, there are other definitions that may be much easier and faster to deploy.
For a very long time I have thought that both a bottom-up and top-down analysis could live in harmony at one time. Think about this:
- Project Teams are asked to help define the complexity of projects in resource-group level terms. They give these estimates to management.
- Management, whether that is the PMO or a Strategic Portfolio Board or an Executive Level committee knows in rough terms how many people there are. They can also look at projects in terms of resource groups or even just total man power. Then they hand down to the project teams, project priority lists and guidance on when projects are to be expected.
- The Project Teams take this guidance and then refine the project in terms of resource role, skills or even individuals and execute the project.
- Tracking of projects is done timesheets and the results are sent in the individual level to the projects and in much more summary terms back to the portfolio with just summary costs and milestone accomplishment and projection dates.
Wait. Won’t that create a break between the portfolio / resource capacity planning analysis and the project tasks? Yes it will.
Wait. Won’t that mean that the management level people won’t be able to just drill down to the individual schedule? Yes it will.
But both of those things are not so bad. The break between global resource capacity decisions and day-to-day tasks is a break between strategic thinking and tactical thinking and that’s almost always appropriate. The notion that upper management would ever be more effective by being able to drill all the way from their strategic plan to an individual’s schedule was always a fantasy anyway. The upside of all of this is that senior management has a much easier to deploy resource capacity tool that is unaffected by how compliant each and every individual in the organization is and the project teams including the individuals can continue to be managed in a much more nimble and effective manner.
This is just one way of dividing different kinds of thinking to make an effective view for each audience and there will be many more. The key, I think, as you work towards what is the right plan for yourself is to keep distinguishing the domain of thinking that each part of the audience sees. Keeping those domains distinct will almost always lead to better decision making.
