Services Capacity Management - Part 2 - The Model
Now that we’ve outlined the core components of the Capacity Model, the next step is to build out the components.
(Note: A working Excel Template can be found here).
Step 0 - Basic Best Practices
Here are a few of the basic concepts that will be leveraged throughout this model:
Time Scale = Months – I’ve found that “months” are the best way to block time, especially for service/implementation projects that span 3-9+ months on average. While “weeks” can provide more granularity, the value they provide is typically not worth the overhead they require.
FTEs measured in 10% Increments – Although most team members can multi-task, we all have our limits. Depending on the product line, most Team Members can’t actively manage much more than 3-4 simultaneous implementations (a bit more for Support/Post Launch). For this reason, I think of a team member as an FTE with “1.0” units of capacity and assume a truly busy Team Member is staffed at 1.0. There is some fuzziness here when it comes to target utilization, etc. . . . but this simple approach works well.
Step 1 – Team Structure and Staffing
The first step is putting together an accurate estimate of how MUCH capacity you have across your team. Although there can be a LOT complexity here, I’ve found it’s typically easiest to start with the following assumptions:
Team Members have 1.0 Units of capacity if they are fully employed and working
New hires typically take 2-3 months to come up to speed and have 0 capacity in 1st month, 0.5 in months 2-3 and eventually reach 1.0
For “small” vacations (=<1 week), we maintain 1.0; Longer leaves of absence (or if a Team Member is supporting another team), can reduce capacity to 0.5 or 0.0 for the appropriate month
The following table provides a basic structure with each Team Member’s capacity mapped out through the year 2023:
Notes:
Bill is on leave in May-June, so his availability is reduced to 0 for this period
David is a new hire starting in January, so his capacity is reduced while he gets
Step 2 – Product Complexity and Staffing Needs
The next steps is to estimate the approximately complexity of Products from a Services staffing perspective.
I typically separate Product Lifecycles into the following phases:
Implementation – The Services team is actively scoping, configuring and launching the product
Support – The Product is “launched” but has ongoing support
Depending on your company’s structure (i.e. a defined Customer Success team), the Support may be short-term OR “perpetual”.
The following table provides a simple overview of a Product Staffing needs by Project Phase:
Step 3 – Sales Probabilities by Sales Phase
As effective Capacity Planning needs to incorporate both EXISTING and FUTURE projects, it is critical to have Sales Pipeline incorporated into the model. In most cases, the model can incorporate Sales that have reached the Scoping or Contracting phase, the variability of Sales makes it important to “scale” staffing needs by Sales Stage as to avoid over-estimating staffing.
I’ve found the best practice to be based on the “phase” that a Sales Opportunity has reached. Sales Team members are typically overly optimistic and will frequently say a deal is “90% likely” even in very early stages.
To address this, I track the Sales Phase/Stage and use a consistent % likelihood of the deal closing. While actual %’s will vary based on an internal Sales processes and execution, the following table can provide a good starting point:
Step 4 – Project and Opportunities Master
Okay, here’s where it gets exciting! The next step is to list all Projects that will require some level of support from your team. This work typically includes active Implementation, previously launched customers and NEW Sales Opportunities.
Here are some of the basic concepts I utilize:
Client – You need a list of Clients that are utilizing the software and services.
Status – Active vs. Sales – This helps differentiate from signed, ACTUAL customers and projected projects
Sales Phase and Probability – Per Step 3 above, this information can be tracked in CRM and automatically calculated in the model
Kick-Off and Launch Dates – Another key set of data is when the Project will start and launch as this drives the bulk of the workload (i.e. Implementation) and defines when the customer transitions to “Support” mode)
The final pieces of the model is to actually “build” a simple calendar and specify the type of work being done for each month. This CAN be automated based on changing Kick-Off and Launch Dates but when working with <25 total active projects, I find it’s easier (and provides more flexibility) to update it manually.
Combining all of this can produce a table like the following:
Step 5 – Capacity Model
Finally, once all Project and Opportunities are defined, you can build a 2nd table with the identical structure of Step 4, auto-populate the meta data and use the Product Capacity table to determine the actual staffing needs for each Client based on Project Phase.
By using SUMIFS and scaling work by Sales Probability, you can get an accurate estimate fo the projected staffing needs.
And with some simple graphing, you can now see your staffing needs for both “Active” projects and “Sales” projects:
For our next entry, we’ll discuss best practices in managing the Capacity Model from an Operations perspective.
