Services Capacity Management – Part 3 - Operations

The last step to an effective Capacity Management plan is ensuring that the Model can scale and grow with the organization as business expands and increases.

The benefit of scalable model is that it can be updated to reflect the current (and future state of the business).   The challenge, however, is that data is allowed to grow stale, it can quickly go out of date.

Fortunately, the model we have proposed can typically be maintained with <20 minutes of maintenance per week and periodic (quarterly) revisions to clean out old data.    Results will vary based on the degree of volatility of the business, but this is achievable.

Ownership:

To maximize efficiency in Operations, it’s typically to identify Services resource that has the  broadest view of the organizations.  In general, it’s inefficient to have individual team members updating components of the model.  Even the best organized team (with the best intentions) will struggle to maintain operations objectives when trading off against customer deliverables and it will be difficult to track which updates have been made when (and which are still outstanding).

For teams with up to 20-25 members, this is typically the most Senior Leader on the team (Director or VP).   This individual tends to have not only the best insight into staffing updates and overall company strategy, they will typically have the best insight into both the status of current projects (including problem areas), the Sales Pipeline AND the best application of resources.   Additionally, smaller teams can typically maintain a level of 1:1 communication between Project Owners and the senior leader.

For teams with 25-50+ members, it’s typically ideal to establish and Operations owner (full or part time) that maintains the model.   This adds some internal communication complexity as Project Owners need to communicate changing deliver dates and staffing needs to the Operations owner while communicating other project issues to the Senior Leader.

Once a team reaches 50+ members, it’s preferable to consider a more formal Capacity Planning SaaS tool as the complexity of managing

Weekly Updates:

Weekly fall into a few basic categories as outlined below:

• Team Staffing – As with the model, any notable changes in staffing should be updated weekly.  New headcount should be projected, new hires should be named (with estimated output) and attrition or leaves should be captured to ensure the future capacity is well understood.

• Active Project Timeline – For Active projects, the main updates are changes to the “go live” date of the project.   Delays here will extend the implementation team’s commitment while early delivery will free up resources sooner.
  Each week the owner should scan the active projects and update the Go-Live Date and then adjust the “Implementation” vs. “Support” category. 

• Sales Pipeline – Signed Deals – Once Deals are signed, they should move from “Sales” to “Active” status which automatically projects 100% staffing needs.  Any last minute tweaks to Kick-Off and Go-Live data can also be adjusted here.    As housekeeping, it’s often cleaner to “cut and paste” the signed project to be the last “Active” project in the file.

• Sales Pipeline – Probability/Date Changes – As Sales can be a highly volatile process, it’s critical that shifting stages (Contracting moving back to Scoping) or dates (May to July) be captured and updates.  Remember that a delayed kick-off date TYPICALLY means a delayed launch date and use the opportunity to remind Sales of these updates.  In some cases, deals are “Lost” (or not pursued) and should be updates to reflect 0% probability.

• “Refresh” the Look-Up Sheet – Note that the above changes should be made directly to the Projects tab in the master sheet.  However, depending on the number of changes, this may “break” the Sales Projections sheet.    I typically follow these steps:  1)  I add lines toward the bottom of the table to account for new Sales Deals.    I then copy the 2nd line in the table and paste it (with all of the corresponding look-ups) to repopulate the table.   This will repopulate the graph with fresh data with minimal rework.

Quarterly Updates:

Quarterly updates typically involve new learnings that will adjust the model.  Typical examples include the following:

• Updates to Project Staffing – With more experiences the teams may find that certain products become easier (or harder) to implement.  This can be adjusted by modifying the Product Complexity tab . . . which will reflect immediately in all Active and Sales projects.

• New Products – In some cases, a new Product will be launched by the company.  In these cases, an estimate of effort, duration, etc. should be added to the Product Complexity tab.

• Extend into the Future – Typically I work in blocks of 12 months, but as you approach the end of this block, the model will provide less visibility to the future.  In these cases, I extend 6 or even 12 months so that there is “room” to build out future deals.

Annual Updates:

Although there is often value in retaining history (especially for Team Members but also Active Projects .  .  . ), Sales deals can grow stale quickly the Model may become weighed down with too many lost deals.  For this reason, I typically recommend an “Annual” maintenance.

• Archive a Version – I live to save a local copy (or duplicate a Google Sheet) to ensure I have a snapshot of history.   Be sure to name it to clearly communicate it’s no longer in use (i.e. “ARCHIVED” or “DEPRECATED” in the title and even on the first tab.

• Sales Deal Clean-Up – I use the annual clean-up to delete out all “lost/not pursued” deals.    As this can involve removing 25-50 lines from the Projects tab, it’s good to do some validation of results before “publishing” the new version

And that’s it!   Effectively implemented and maintained, this approach and Model  can be expanded to include Revenue Forecasting (which we’ll discuss in a future session.