One of the things that has concerned me most over the past 40 years of working in project management environments is why more projects do not conduct Detail Resource Planning. I say “Detail” because almost all projects can produce a budget, a staffing plan, some even have what they call a Resource Plan. But the issue is how these are derived. In most cases, we found that the project started with a lump sum budget and then apportioned this out, with little or no regard to the detail effort. We call this top-down planning methodology and it has a history of NOT working so well.
Detail Resource Planning is a bottoms-up planning process.
It starts by loading all detail tasks with their planned or anticipated resource requirements in a project database or file; then going though all the fundamental processes of what we call Schedule Reconciliation. The result of this is a working schedule of all the tasks of the project that in total meet all project objectives, and which have accounted for every constraint on the project save one – resources. But it is only after a viable schedule of tasks has been derived that Detail Resource Planning should be conducted, because we need to derive our Resource Plan to a schedule that meets the project’s delivery objectives. There is no use planning resources to a schedule that does NOT meet the schedule requirements.
This is also the point where the focus is squarely on the project management software tool and this is where the problems begin.
For instance, there are two basic methods here and the tool needs to support both. The first is called “resource-limited resource planning.” That is where a defined level of resource availability is held constant and the project’s schedule is adjusted (delayed or pulled-in) to accommodate this constraint. You can see that there are many examples of a need for this capability – like scheduling a critical facility or tool, or even a very limited individual labor resource.
But remember, we just spent enormous effort in reconciling the schedule – and don’t now need to delay the schedule – as this will put our schedule objectives in jeopardy. So what we need in the general case is the other resource methodology – “time-limited resource planning.” This is where the project’s schedule is held constant and the process needs to compute the resources necessary to meet this schedule. In this methodology, our software tool needs to accomplish a very important process, something we call “Resource Aggregation.” This is actually a relatively simple process, but many of the available tools don’t seem to get it and the problem is prolific enough that you need to test any and all of them to make sure they work correctly. Very simply, what the software tool needs to produce is an accumulation, or summation or aggregation of the resource requirements of each resource type per day, per week and per month that it would take to meet the schedule.
So why don’t more projects do this as the basis for their resource and staffing plans?
Our conclusion after many, many years is that way too many people have found that there are multiple reasons for this – many stemming from an issue with their tool. As one example, their tool might focus on the first methodology (resource-limited resource planning) and not so much the second (time-limited resource planning). But since this is the general resource problem – they conclude that their tool is not much help with their resource problem. They might also conclude that their tool simply doesn’t seem to work properly. The resultant data doesn’t seem to make sense. What a pity! This is such critical information to help any and all projects meet their schedules.
And if we can get past the tool issues, there is an even greater perceived problem. The result of any Aggregation is that a time-phased resource requirement is a radically dynamic variable, especially on a per day or per week basis. It might reflect five resources one week, ten the next, twelve the next, four the next, etc. Resource availability simply cannot practically vary often enough to meet a radically dynamic variable – resource availability can vary, but must do so infrequently. So once we get past issues with the tool, then we are confronted with how to match a radically dynamic variable (resource time-phased requirement) with a relatively static variable (resource availability).
This is a problem that we here at PMT have taken on with intensity – because we believe that it is very likely the key to managing a project’s schedule success. Well after many, many years we have finally succeeded – we have found answers. In fact, we have actually come up with several methods to resolve this problem, and each is documented in one of our project management courses. If you would like to learn more about detail resource planning – contact us today.