There is a myth in planning circles that more detail is better and more accurate. In resource planning this looks like huge spreadsheets with people’s names assigned to specific projects across the months or weeks for at least a year. If we can plan out that much detail that far, it must be accurate, right? Well, not so fast. There are three main problems with this approach:
- It takes a long time to create and modify those spreadsheets.
If you want to see what happens if you complete projects A, B, and D instead of C, E, and F you’ll probably end up burning the midnight oil to get there. And better hope you don’t mess up any formulas in that spreadsheet while you’re at it. And if there is more than one person accessing that spreadsheet, try not to step on each other’s toes (or rows). If you are managing resources for a large group, this quickly becomes unwieldy and leads to the dreaded paralysis by analysis syndrome. - These large spreadsheets make it very difficult to see the forest for the trees.
Sure, there are summary tabs in the spreadsheet, but you can’t play with those summaries. You have to go back to the detail they are rolled up from to see how the forest might change if you modify some of those trees. Let’s say the “forest” view shows you departmental summaries across projects. That’s still going to leave you with quite a few rows in the summary tab to get to the bottom-line that shows if that department or group is over-capacity. And if they are, it’s back to the detail sheets to figure out how to change it. - You’re trying to solve the wrong problem!
The “forest” level is primarily concerned with approving the right projects that fit the available capacity. This is not a user-by-user problem, it is a larger-scale, capacity problem. If you have a 500 person IT department, for instance, you really want to see some breakout of those 500 people into logical groupings and then select the projects that fit those groupings.
The guest speaker for our upcoming Agile Enterprise customer webcast on November 10th, Dr. Klaus Leopold, released a book in 2018 called “Rethinking Agile: Why Agile Teams Have Nothing To Do With Business Agility” that has a great take on this, in a slightly different context. He described and laid out various types of planning and execution into three “Flight Levels.” These Flight Levels can apply to resource planning as well. I’ll let you read the book to get the full understanding, but here’s how I apply them to Resource Planning.
Strategy. Coordination. Operation.
“Flight Level 3” is the Strategic level and analogous with an airplane cruising at 30,000 feet. If you are flying a plane at that altitude you don’t expect to see individuals on the ground. Mostly you see broad landscapes with cities, highways, and farms. You don’t need to see the individuals on the ground in order to figure out where to fly the plane, you really just need that broader landscape. In resource planning terms, this may equate to departments or large teams. More detail than the whole 500 person IT group as a whole, but certainly less than each of the 500 people. The key here is the problem we are solving – making sure we don’t overload the system’s capacity. That’s it! Not who will do the work, not what roles are involved – let’s just make sure we don’t overload the system.
“Flight Level 2” is Coordination at a more moderate altitude like 15,000 feet to stick with the airplane analogy. At this level we expect to see more detail, but still not the individuals on the ground. For resource planning, this might be roles such as Project Manager, Business Analyst, Engineer. Note that I do not include these role-based types at Flight Level 3. Here we are solving for critical resource availability. If we’ve done Flight Level 3 planning and the overall system isn’t overloaded, then we will already find far less contention for resources. Though, there may still be overloads for critical resources such as Project Managers or specific types of Engineers. I think of this level as finding the right types of people for the right projects.
“Flight Level 1” is Operational, a very low altitude of 5,000 feet and below where individual objects are clearly visible and distinguishable. Now we are looking at who will do the work. This is the purview of project managers who assign the work or product owners who prioritize stories for individuals to pull.
Resource Capacity Planning – Don’t Overload the System
With the flight levels outlined let’s dive a little deeper into Flight Level 3 – Resource Capacity Planning. Remember, the objective here is simply to not overload the system with work and narrow down the strategic decisions based on what will fit in the capacity pipe.
The first step you’ll need to take is figure out what your capacity pipes really are. If you made the 500-person, IT department one pipe you could select projects that fit inside its 20,000 hours a week capacity. And you might select way too many web projects and leave the network engineers twiddling their thumbs.
If you are an Agile shop, this will be much easier. You already use Teams. If you are large, there may be Engineering departments made up of multiple Teams and you can choose to use either the Teams capacity or the Department capacity. And, this could be expressed in story points, person-month, days, or sprints. The nice thing about Agile teams is that they are already balanced. A typical team may be one scrum-master, one tester, and four engineers. If that ratio doesn’t work, then the team make-up can be adjusted so that stories flow smoothly and you can aim initiatives or projects at a Team and know how much will fit their pipe.
Agile teams work great for software only projects, but PMOs manage a broad range of work, which often needs infrastructure resources, subject matter experts (SMEs), and project management. Now how do we divide up that 500-person IT department? One way is to develop virtual capacity teams. Individual resources are usually specialized in most large IT departments. Thus, infrastructure projects will have PMs that only manage infrastructure, specialized business analysts, and of course network engineers and admins. Maintaining third-party software applications will also find specialized project management and engineering resources. That 500-person shop can probably be broken down into a dozen or so minimally overlapping virtual capacity teams.
Of course, today you probably run both waterfall and Agile projects, so a hybrid of the above is quite likely.
Now that we have abstracted a true 30,000-foot planning view for capacity, we can select the work. Instead of selecting the top 20 projects out of 100 proposed, we can select the top 10 web projects, top five infrastructure projects, and so on. And, you can squeeze in a couple of small Web projects from the remaining capacity. Most likely, those top 20 projects become 30 when aligned with their capacity pipes. Of course, if you need to change the plan, it’s as easy as changing the makeup for the projects in each of a dozen capacity teams – not changing projects assigned to every one of those 500 people.
In the end this all boils down to solving the right problem at the right planning level. Overall, resource capacity issues are a “Flight Level 3” problem. Not only is it not in the details, too much detail will get in the way of the business agility and the sound decision making we all strive for. You will spend more time updating the details than making sure the projects are running smoothly!
