Tooling for Resource Planning

Navigating resource management challenges

Just like with project planning, most tools on the market cover resourcing in the same way: non-swarming and projectized. For some industries, this practice is fine and makes sense with how they approach resourcing. However, as discussed in this chapter, tech companies tend to use capacity planning that may shift due to priorities over the life of the project.

The lack of swarming capabilities means that a task timeline won’t automatically reduce when you add additional resources, it will actually reduce the time each resource works on the task and keep the duration the same. Some tools allow you to change this behavior, but it isn’t consistent. This means any time you need to swarm—or even want to know what the impact of swarming would be—you need to do it manually, either through changing durations or forcing the hours spent to reduce the calendar time.

In prioritization meetings, we often receive inquiries from management about available dates to meet with resources $x$, $y$, or $z$. Rather than just dictating the number of required people, we assist in balancing the number of resources with the priority, considering the best possible ROI. During these instances, we frequently export the data to Excel in a Gantt chart style and manually adjust tasks to visualize the outcomes.

The other issue is that the resourcing provided and the optimized resourcing for a project rarely match. This leads to issues where tasks with no written predecessors will all start at the same time, regardless of the number of people assigned. Some tools, such as MS Project, will warn you that a resource is overbooked but requires step-by-step approval to shift timelines. This is still far better than other tools that completely ignore, or hide under a budget subsystem, the fact that resources are overbooked. Not all tools excel in handling these issues, and a single tool capable of addressing all of them effectively has remained elusive. This often necessitates manual intervention in at least one of these situations. To mitigate this, a common approach involves imposing a start date constraint or creating a placeholder task based on resource availability.

When planning has to be quick

When planning a project, ensure that you do not forget about overhead. Either ahead of a project, or through multiple projects with multiple teams, build up tables of standard items per team, such as vacation trends, on-call rotations, team outings, improvement weeks, and training.

If the tables are still taking longer than you have, then a quick chat with SDMs on their understanding of their teams’ overhead can suffice early on in a project. Usually, a 10-minute conversation with an SDM to talk through the overhead list from this chapter and fill in values is enough time for a rough number. Because it is an estimate in and of itself, don’t forget to add a buffer until you have enough data to make the numbers more concise.

Regarding vacations, these often vary from person to person, but some patterns may exist within your team, especially depending on the type of services they run. Local holidays often play into when people will take time off, such as Christmas, and people often pad a simple 3-day weekend to create a longer vacation. Watch for these patterns and ensure that they are considered when planning.

Now that we know a little bit more about resourcing in a technology landscape, let’s apply this to the project plan for the Mercury program in the table below: