Resource Planning 101: Part B

Service Coordinator superheroes make the tech's job 10% more efficient, which amounts to $31,200 per tech per year in potential savings.  How impactful would that be for you at your MSP?  Just multiply # of techs * $31,200 and subtract the superhero's compensation and benefits. 

Resource planning goes a long way to drive chaos out of the Service Delivery operation, starting with a short review of the first steps in the Triage process:

1)    Ensure the ticket is in the right client's name

2)    Take note of the ticket contact, as VIPs and company liaisons tend to have a different relationship with the MSP to determine whether a different engagement process might be expected

3)    Review and clean up the description so everyone who reads the ticket can easily pick up the facts and nothing but the facts

4)    Edit the title to be the best summary of the issue/request

Now, the big resource planning moment!  With the historical information in-hand and the pre-positioning scheduling in-place from Resource Planning Part A, the superhero is ready to take the next action:  determine the correct workflow for this request.  For example, is the request categorized as an incident or service request? 

Resource planning isn't done solely at the workflow category level but also at the sub-category level.  Days or weeks in advance, someone looked at the data and determined the incident response hours needed and service request response hours needed.  Put yourself in the mind of our superhero at the resource planning point in the triage process:

·      Incidents:

o   Critical

Usually assigned to one of the best techs in the house due to client urgency and impact. So, why not give this high-value tech a heads up in advance that they're the go-to person for ## hours that day?  Or maybe even pre-schedule them for critical response – you do have an SOP for that, right?!

o   High

Usually needs to be engaged on within half a day – so make sure someone with a mid-level skill set is available every afternoon and the following morning to cover this type of incident.

o   High Backup

Due by the end of the day, so make sure you always have someone available with the right skillset through every mid-afternoon.

o   Medium

Three days in advance, a good superhero will look across the calendars and pick their go-to person.  Then, when the 3-day-out selection becomes tomorrow, you already know who's going to catch this request, assuming it doesn't require special scheduling

o   Standard

We'd never tell a client their request is a "Low" priority, which is why we rename this one to be Standard. These have the most relaxed SLA and can go on almost anyone's dashboard, skillsets permitting, of course. Note:  it's the SLA automation that makes sure these requests are engaged on within expectation and prevents getting lost in the shuffle.

·      Service Requests:

o   Quick Hits

To end the battle between lofty ITIL standards and the MSP reality, a Quick Hit is a service request (for the ITIL police!), but because we have external clients, we're going to treat these types of requests with a high priority SLA (so Account Managers relax... we're taking care of your favorite client – how do we know they are your favorite client?  We looked at your commission checks!)

o   Moves/Adds/Changes (or M/A/Cs)

We've reached another decision point that, on the surface, might not make sense, but just humor us for a moment as we leverage the PSA software to work with us and not against us!

• M/A/Cs < 4 hours

This size of estimated hours to remediate requests [check the MTTR report for better data] fit nicely in the Ready to Engage widget or Queue view and play along nicely under SLA management with Incidents.  For this reason, they are Reviewed and Assigned, unless the Customers is needs to be part of the engagement, then they are required to be scheduled )  

• M/A/Cs > 4 hours

Most techs would say taking their eyes off the dashboard for more than 4 hours is stressful.  The solution is to schedule these requests where they fit in the calendars. This way, everyone slotted for this work knows they're not expected to be watching the dashboards and superheroes remember not to dump tickets in the Ready to Engage widget; unless of course the SLA is beyond the calendar scheduling or overloads the widget/queue)

o   Installations

More involved than M/A/Cs requiring some planning time ahead of the engagement.  Now, we wouldn't be the first to tell you that all engagements need planning, but for most engagements, the planning time is part of the engagement.  Installs on the other hand need some level of coordination or Client-Facing communication for the engagement to be accomplished smoothly.  For these, planning a few days before the actual engagement is very beneficial.  Here the Tech is scheduled for an hour or two of planning time in advance of the engagement.

o   Projects

So, just what is a project? It's worth your time to sit down and decide when something is an IMAC and when it's a Project.  The determining factor is the risk tolerance of the MSP.  How many labor hours (and please make the threshold in hours not $$ - techs know hours, they are less aware of $$) is the MSP willing to risk?  Here, the risk is not just limited to not getting paid but more about not getting paid for out-of-scope or schedule over- runs – in other words, the risk of not ending on-time and on-budget.  If this is foreign to you, from Advanced Global's experience, the threshold is 16 hours and any engagement over 16 hours needs a signed proposal, SoW, BoM, planning time, client communications strategy, and an internal and external close-out meeting.  If the request doesn't merit all this extra work, then it's an install not a project.

o   Recurring Schedules Usually preventive maintenance, alignment, or technology advisor visits.  Now, we’re onto another advance Resource Planning decision:

• Recurring Just in Time visits (if the visit is not for a specific day and time, with or without the Client, then Created Recurring Ticket X days before due date works just fine.  Have the JiT mechanism create the ticket and dump it into a queue or add it to the Ready to Engage widget – hard to plan for, but easy to do)

• Recurring Scheduled with the Client (if the visits are on-site, require Client presences, or have a short availability window; then they should be mapped where they are least disruptive and scheduled in the calendars  

Now these 12 workflows are ones that every MSP encounters.  Some MSPs encounter others.  For example: Sales, Procurement, Cloud Services, Software Dev, Website Dev, etc.

So, while all of this is running through the superhero's head, it does become intuitive and second nature in time.  Along with the Advanced Resource Planning part.

At the end of the day, an MSP should know every hour needed for every workflow into the future (today, next three days, next three weeks) and every hour available for project work four weeks and beyond.

This is Resource Planning for MSPs.

- Steve and Co