When project management software got started, resource-leveling was the ultimate end-goal. Has it disappeared?
Back in the day… I seem to start almost every article lately with that expression. It may be particularly important for this one. Back in the day, when I first entered the project management software industry in the early 1980s, talk of resource leveling algorithms was all the rage. Some very clever people, many of whom I was fortunate enough to meet, wrote some very, very clever code to do resource leveling. It all started with critical path methodology (CPM) scheduling and time limited (meaning don’t exceed the late dates but you can overload resources or resource limited (meaning don’t overload your resources but you can slip your schedule) were the two main objectives.
Sounds fine so far, but in the 1980s, planning and scheduling algorithms were new to most of us and our ideas of resource management on the mega projects that warranted project management software was limited to a handful of resource categories. I remember one system announced with pride that it could now handle up to 8 separate resource codes.
The calculations and their resulting analysis were immensely valuable.
Then something happened.
First of all project management software was being adopted at a phenomenal pace and the cost per user was dropping incredibly fast.
Project Management Software companies realized they could charge license fees for more users if each and every individual was represented as a unique resource code.
The demonstrations of what was possible were compelling. Now management could envisage a project at many levels below them reaching all the way down to individual’s daily workload and users would receive their marching orders on what to do.
While the demonstrations were awesome, realizing the results in practice was not. The tried and true resource leveling algorithms didn’t deliver meaningful results when applied to individuals.
The algorithms hadn’t broken but the original suppositions about them were no longer valid.
Let’s take a super simple example to see why.
First, we’ll make the simplest schedule possible for myself. Chris will do two tasks, each taking 40 hours and each starting together.
This is double the work I can accomplish so the project management tool dutifully shows that I am 100 percent overloaded. We all know what will happen in real life with this problem. I’ll do one of the tasks this week and one next week. So, if I resource level, that’s exactly what it shows.
So far, so good. But what if we add a second resource and give them some tasks and what if there is a relationship between these tasks? It’s still a very simple schedule but now John and I are working in parallel.
Looks great until I resource level.
Now if I look at John’s schedule, he will work for a week, then he will not be able to work for a week and then will finish his work in week 3. This is a 5 task project with two resources. It doesn’t take much imagination to see where the algorithm becomes a problem for managing those resources.
Resource leveling only optimizes for one resource at a time. It isn’t that the algorithm isn’t clever. It is. But maximizing for multiple resources simultaneously is a three-body-problem.
It’s unsolvable.
So how did users and project management software companies and the industry adapt?
Several approaches were adopted
- Forget about that. It’s not important
For some project managers, they moved on from looking at the impossible resource capacity planning analysis and instead just managed resources based on budgets or priorities, leaving the ugly problem of resource management as something to be handled further downstream. In some cases, the organizations reorganized their companies project-by-project and didn’t worry about capacity in terms of human resources. - Forget about CPM. Everything is Agile now
Agile has made big inroads into the project management industry since the year 2000 and is particularly popular in IT and development projects. But Agile doesn’t spend any time thinking about the big-picture of the organization. Numerous attempts have been made to get Agile to an over-reaching perspective in movements such as SAFE (Scaleable Agile Framework) but the adoption has been minimal. - Make everyone into a team and shift from resource leveling to resource allocating
All Project Management is Team Management said a big software vendor who was, not coincidentally selling team management tools. It’s true of course but it’s true at the team level; from the tactical perspective. Making the corporate or organizational budget is still a thing at the Strategic/Executive Level and at that level we need to resource level.
So, is that it? Do we simply not care about resource leveling or optimizing use of our resources.
But we do.
Perhaps not at the team level where small Agile teams have now been taught that resource leveling is nonsense and resource allocation is the only thing that counts. But everywhere else, there is a great interest the analysis of what can be accomplished at the macro level with the resources available.
Certainly executives at the Strategic level are painfully interested in what they can produce with the resources they have, what projects they can commit to in the future and what resources they should be thinking of adopting or abandoning given the their plans.
That’s a resource leveling exercise.
But executives have little or no interest in the named resources that will accomplish that work. They care only about the macro view at a portfolio type of level.
So what are our options?
First, forget for the moment about scheduling a person to a task far in the future and putting that into your analysis. You can’t honestly say that you even know the names of the people who will be working on your projects next year or the year after.
Just level manpower This isn’t as crazy as it might sound at first. Instead of a list of dozens or hundreds or even thousands of individual resources to assign to tasks. Just assign one at the project or sub-project level. Call it manpower or effort or people.
Some people when I suggest that immediately say “oh, but what about the skills? You’re not taking into account skills!” That’s true. But if you can’t optimize at this level, it’s nonsense to think you can optimize for multiple skills. So try it.
Plus, in most projects, the mix of skills is often relatively constant. There are so many developers, so many designers, so many QA experts, so many documentation personnel and so on. Creating a number of work-days per a project that is generally accurate is very do-able.
Now we can take that generic resource and apply it to our project either at the one-line per project level or perhaps at a sub-project level.
The resource levelling algorithm suddenly works.
“But, what about that critical path methodology calculation?” You ask.
If you do this exercise at the portfolio level, there is rarely any logical link between the projects. They are more likely to be scheduled based on portfolio priority. Then you can transmit from the executive portfolio view down to the operational project manager level the start/end dates of the project and the expected manpower. The project manager then translates that into detailed tasks with skill assignments and turns that over to scrum masters who will do the individual allocation for each sprint.
For people who don’t like anything about what I’ve just described but are determined to get some value out of their resource leveling algorithm, here is an alternate plan.
Remember, our goal is to manage the most constrained resources. So, why not just resource manage the most constrained resources? This is a viable technique when there is a small, manageable number of highly skilled workers who are essential to projects being successful. In the industry I work in, the software business, lately that often means people with extensive AI experience. Your AI projects simply can’t move forward without them so, make a multi-project schedule which allocates only those key resources for each project then have all your other resources fill in as needed, essentially managing the resource capacity of a handful or people with everyone else being resource allocated, not resource leveled.
This type of technique will certainly work for this type of skilled worker but I’ve seen the same soft of methodology used to great success when the critical resource wasn’t even a person.
Many years ago, we consulted with an aluminum company. They wanted to improve their overall throughput of the plant. For their manufacturing process, the smelter was the critical resource. They decided to resource level just the smelter with all other elements of the process such as delivery of raw materials, pre-smelting soaking or preparation processes following whatever the smelter schedule dictated. Sure enough, all the less constrained resources were easy to adjust and easy to line up with the smelter. The result was a huge improvement in production.
So, resource leveling hasn’t’ evaporated.
It’s still alive and well.
Where it is not deployed is, in the end, where it was not effective. Trying to resolve level everyone’s daily schedule is not an algorithm-based exercise. People’s day-to-day schedule is a commitment-based exercise.
The key to making resource leveling work is distinguishing the level of the organization where this analysis is useful.
For determining what projects can be completed in this year what whether we have the capacity to take on more work, the perspective lies with the strategic level.
