Steady Speed Wins the Race: How taking time to implement Priority Change is better for your MSP

It’s absolutely INSANE to continue the same Service Delivery process while expecting Operational Performance to improve (* This is based on the definition of insanity, which is doing the same thing over again and expecting different results).  But we maintain status quo because introducing change in a production environment is very risky.  The last thing we want techs to focus on is what’s changing in Autotask and why.  Better they continue to focus on meeting clients' expectations.

When it comes to Service Delivery Foundational Improvements, there seem to be two camps:

1)    Those who say “D@%#.. the torpedoes, full speed ahead”

2)    Those who want collaboration and buy-in before moving forward

It might surprise you, but #2 is the fastest way to introduce change. 

Over the last five years, we’ve had three clients who preferred the first method.  We’ve even been told they’re going to make the changes at "Warp Speed." And those clients have paid the price.  The amount of rework, adjustments, and holding the team accountable takes way longer than those that just take their time, work through the ramifications of the change, at least ask the Lead Tech if not all techs for their input, and implement changes in a controlled fashion.

Case in point:  One client blazed through our Service Delivery Foundational Improvement program (usually takes ~3 months, depending on the organization's size) in six weeks.  We met four times per week, so the investment by Advanced Global was the same.  Missing from the exercise was the reflection and communication time, including allowing the techs time to fully understand and respond to the changes.  It took a year to drive the chaos out of the Service Delivery Operation, mostly because going at that speed introduces more chaos than it resolves.

Advanced Global’s Process of Removing Chaos out of an MSP

So, what’s a better process?  While Advanced Global isn’t perfect (though we are improving with each reiteration), here’s our preferred process:

1)    Discuss the status quo and gain a firm understanding of how a process is working today, including what’s working well and what isn’t

2)    Present to the Management Team a different way of thinking while doing the same process

3)    Provide background, tangible real-world experience, connection to the current process, and a picture of what life could be like with the change

4)    Provide the team with educational materials, so the Management team can collaborate visually and more effectively with the Service Delivery team

5)    Listen for feedback/guidance on making the change and hold the business accountable implementing the change in a reasonable timeframe

As an example, many of Advanced Global's articles revolve around Request Segmentation as the first step in maturing from a Reactive, Break/Fix Service Delivery Operation to a Proactive, Data-Driven one.  In those articles, we make an iron-clad case that leveraging the underutilized Priority Field to communicate into which workflow the request has been segmented/Triaged is best. 

Here’s how the Request Segmentation phase of our SDFI program is laid out in the Autotask project template, including introduction of the Priority Field change:

• First Meeting: Intros and understanding the existing Service Delivery process

o   Homework: review videos and articles on the concept and benefits of Request Segmentation

• Second Meeting: Discuss what the world would look like if Client Requests were segmented into 11 different workflows

o   It’s far easier to optimize the operation by dividing the mound of tickets into small groups by workflow

o   The software can be configured to tell the difference between one ticket and another; therefore, some processes can be automated

o   With automation, the techs know what to work on next, and the client will know who and when to expect engagement

o   It’s far easier to tell which tickets are stuck, needing intervention

o   Tech Priority Change educational materials provided

o   Homework:

§  Collaborate with the techs

·      Explain what’s changing

·      Why the change is needed

·      The benefit of the change to them

·      How the change will impact them going forward

§  When ready, Implement the change

• Third Meeting: Validate the Autotask Priority Field changes that have been made, and introduce Workflow Usage, Triage Process, and Calendar Scheduling SOPs

o   Homework:

§  Apply the new SOPs

§  Review of Advanced Global daily Priority Field QC reports

• Fourth Meeting: Discuss how things are going, Queue Review, and move to close out the phase if the Client is ready

o   Homework:

§  Resource Planning 101 SOP

§  Further adoption of the Proactive, Data-Driven Request Segmentation process

We hope this article has been helpful in highlighting how to stop the insanity and introduce Service Delivery Operational changes in a production environment.  Moving at a steady, continuous improvement pace is far better than doing nothing or going at "Warp Speed."  We (every Service Delivery Gladiator we know) work hard to improve the work environment for the techs, the client experience, and the bottom-line profits.  The last thing we want to do is introduce more chaos than we resolve.  Change isn’t easy; changing habits is even harder.  But with a steady collaborative pace, vast improvement is possible.