Roadmap Capacity Planning
I know my last post was about roadmapping and there’s a whole lot more to Community Operations than just working on the roadmap. However… I’ve seen a lot of chatter in the community spaces about roadmapping lately, particularly for capacity and team planning, and given roadmapping has been pretty top of mind for me lately, I figured it’s timely for me to write this post. Don’t worry — there will be plenty of other posts on other parts of CommOps. 🙂
As a note, this is not an introductory post on how to create a roadmap. I’ll eventually write one of those too, but this is more advanced and is for people who are looking to create a detailed roadmap for the purpose of team bandwidth capacity planning.
The first step is to have your basic roadmap created. At the minimum, the roadmap should have:
- Line items — what are the individual programs and initiatives that are taking place
- Timing — when does each line item begin and end
- Owner — who on the team is primarily responsible for each line item
We aren’t looking for billable hours here…
The first thing I thought about when creating the capacity planning was to estimate actual time, in terms of minutes per day or hours per week/month, that each team member had on their plate at any moment in time. We created an extensive capacity plan in Team Gantt that I talked about in my last post about my roadmapping adventures. It looked something like this and was complicated and nearly impossible to read:
This was based off of hours (very detailed hours) added for each line item in the roadmap, that looked something like this:
Sure, the red is a good indicator that the team member has too much on their plate. But it was too granular.
After all, we aren’t lawyers or consultants who are keeping track of their billable hours.
Is there really a need to document decimals of time? Let me tell you. The answer is “No”.
What’s the purpose of capacity planning for your community team?
I took a step back to think about why we went through this exercise. What was the intent of tracking time? What actions or decisions would come as a result of having this information?
Firstly, what we are not looking to do:
❌ We are not looking to micro manage people’s workloads.
❌ We are not looking to make sure team members are at an exact number of hours of work per day.
❌ We are not looking to add unnecessary administrative work by tracking and logging time.
What we are looking to do:
✅ Ensure each team member has a manageable workload to prevent burnout.
✅ Have visibility to workload distribution across the team.
✅ Plan for timing of future initiatives and programs based on team bandwidth availability.
✅ Add efficiencies with the intent of saving team member’s time.
✅ We could also be creating a business case for additional headcount.
So let’s create our roadmap capacity planning to reflect this.
Introducing the Effort Rating
In the roadmap, I introduced an Effort Rating column that are numbers 1–10. This number is an approximation of time and effort.
The Effort Rating simply shows, on a 1–10 scale, the approximate hours per week that a team member would spend on the initiative. Below is an example table showing the Effort Ratings, approximate time, and examples of activities that would be each rating.
Getting into the weeds a bit more, there are a few additional notes to consider if you actually go through this exercise:
- Oftentimes line items in a roadmap will have more than one person working on it. For example, if you are doing an engagement campaign, you may have a Community Manager as the project lead, but the Community Operations person is helping with the setup and the logistics of the campaign. If this is the case, you’d have two line items in the roadmap, one for each person, and the Effort Rating would be different for each person. As you can see in the image below, both Geri and Melanie are working on this engagement campaign, but Geri who is leading the initiative, has a higher effort rating than Melanie, who is providing support for the initiative.
- Effort spent on initiatives often changes from the beginning to the end. For example, you might spend more time at the beginning of a project while you’re scoping and planning it out, a moderate amount of time throughout the project, and then a small spike again at the end as you wrap things up. The Effort Rating is not something that should be set in stone! Feel free to update it. We should be visiting and updating the roadmap regularly anyway, so if your effort changes, the rating should be updated to reflect it. (As a side note to this, once a line item is completed, you may want to change the Effort Rating to an overall or average effort that you spent over the duration of the project. This way, if you want to look back at the year, you have a good overall assessment rather than just the Effort Rating it was at the end of the project.)
Adding it all up
The Cumulative Effort Score is the sum of all Effort Ratings for each team member. I have this displayed in a different table, and it takes all lines where the Status is “In Progress” or “Ongoing” and adds up the Effort Ratings.
The Cumulative Effort Score should be an indicator of the team member’s bandwidth and workload. This, too, is not an exact science, but rather a general indicator of how much each team member is working on. Loosely speaking, the Effort Rating is equivalent to hours per week, so it should absolutely not exceed 40 (assuming a 40-hour work week). However, this does not include time that is spent on meetings (e.g. 1:1’s, team meetings, All Hands, trainings, etc.), so ideally, the Cumulative Effort Score stays a healthy level below 40.
At the very minimum, each team member will have their regularly occurring run-the-business items (typically those Effort Ratings of 1). From what I’ve seen from my team, it could add up anywhere between 3–7. On top of that, the Cumulative Effort Score should show approximately how many hours of work per week each person has on their various initiatives. With my team, I’ve seen average scores of 23–30.
To take things one step further, you could create this table but provide the Cumulative Effort Score by Quarter as well. This shows an approximation of effort over time, which can help with future project planning and seeing when team members might have a busy quarter.
The road less traveled
I can’t stress enough that the roadmap is an incredibly powerful planning exercise. I refer to our roadmap very frequently and our team uses it as a source of truth for what’s going on, and we’re constantly updating and providing notes in there for team-wide visibility to latest updates on ongoing initiatives.
However, not every roadmap needs to be the same. Use the version that is the most helpful for your team. You may not need to go this granular with capacity planning, or maybe capacity planning on your team looks differently than this. Or, you might just want to stick with initiatives and when they’re taking place. Cater the roadmap to what suits you, your team, and your community the most.
Interested in making or improving your roadmap?
If you’re interested in creating a roadmap, holding a roadmap planning session, have an existing roadmap that needs some love, or are trying to figure out what kind of roadmap would work best for you, feel free to email me at thecommopsgal@gmail.com. I’d love to chat!
And, of course, here is a bonus picture of Yoshi for those of you dedicated folks who read until the very end. 🙂
