In the South, sometimes you’ll hear someone say, “Every once in a while, even a blind squirrel finds an acorn.” I used that phrase as a salve on my wounds when I told the COO at my last company that I was, in fact, wrong, and he was–as unlikely as it may have seemed–correct.
Before I go any further, I want to be clear: the COO and I had–and still maintain–a fantastic relationship. We were just never afraid to go toe-to-toe and fight for an idea. At my core, I’m a “marketplace of ideas” kind of guy and think the best path forward should win. All that being said, since I’m the one writing this blog and he can’t refute this directly, I’ll say that my ideas won a disproportionate amount of the time. In this particular case, however, he was right and I was wrong.
What was the topic that brought us to fisticuffs and ultimately lead to my stunning defeat? The Service Delivery Model.
At my previous employer, as I’ve discussed throughout the series, we learned a lot of things the hard way and had to make some big organizational changes. We transitioned from people to process-delivered solutions and developed a tight product suite ready for delivery. The next step was taking that product suite to market, which required a guarantee of high-quality service delivery. To achieve exceptional service that was repeatable, our COO’s plan was to implement a Service Delivery Model, in this case ITIL,* though there are others. He presented his case with all these flowcharts and buckets of responsibility that, to me, looked like the most inefficient plan in the world. It was after this presentation that he and I had our “discussion.”
From where I was sitting, he’d presented an onerous process that would take forever to implement, completely stifle innovation, and slow down new product creation. He countered with the stance that without a Service Delivery Model, there was no way to reliably grow and deliver consistently high-quality service. Eventually, he won the group over, we proceeded with the plan, and I quietly prepared my “I told you so” speech.
Here’s the thing, once the process was fully implemented, we got so. much. better. We delivered better products; we onboarded new revenue more quickly; our churn went down; and our support metrics improved. The COO wasn’t just right, he was REALLY right and I was REALLY wrong. Insert foot in mouth.
Why the Service Delivery Model Matters
For so many Managed Service Providers, teams are defined by the type of technology that they work on: the network team, the server team, the storage team, etc. In the ITIL framework, resources are aligned to functional areas. Teams are formed, and each group is assigned a component of the framework.
Service Delivery Components in Action
Service Strategy Group
This is the group that I led. We looked at market conditions, trends, customer requests, innovative approaches and other data to inform our approach to the market.
We met, brainstormed a new offering, and put that into a Service Requirements document. This document would NOT contain design elements. It would simply lay out the market data, what the customer should expect to see in the product, and what they would pay for this service. That document was then sent on to Service Design.
Service Design Group
This is the group that took our Service Requirements document and engineered the actual product. The team would explore off-the-shelf products, custom-made solutions, support costs, new vendors, etc. Armed with this information, the group would tell the Service Strategy team that the product could be built according to the requirements established by the Strategy Team or that it wasn’t actually feasible. In the case of the latter, it was likely because the costs were too high given the expected pricing, it was too difficult to support, or it wasn’t a big enough market to justify the resource allocation.
Service Transition Group
If a product met the requirements set by the Service Strategy team and was determined to be buildable by the Service Design Team, the Service Transition team would begin to document the new offering and build the operational processes around the new product.
Service Operations Group
This is the group that delivers the offering. They take the operational models developed by the Service Transition Group and put them into practice in a live environment.
The CI team takes feedback from all the stakeholders and improves the product. If sales volume is low because the product is too expensive or too complex, they find ways to make it less expensive or more simple. If the underlying technology is creating support problems, they identify ways to make the process less problematic. Certain recommendations go back to Service Strategy and the process starts over.
While this seems like a lot of work, let’s contrast it with what we were doing before and, likely, many of you are doing right now:
- Engineering develops new products and services. That means they probably design awesome things that no one wants to buy. Or, solutions are over-engineered and no one can afford the offering.
- Sales and marketing develop new products and services. They run out, sell something, and toss it over the fence for post-sales to figure out. Revenue goes up and support costs go through the roof.
- Sales and engineering collaborate on new offerings. They meet about once a month and absolutely nothing happens because there is either no leader or no process to guide the discussion.
I could probably write a thousand blogs about the nuances of the Service Delivery Model, but I’ll spare you the finer details. What I’ll repeat here is that I was wrong. Aligning to ITIL did not slow us down at all. It gave us a system to follow, aligned our resources to the appropriate functional areas, and provided executive sponsorship to ensure things were moving along at a steady clip. If you aren’t aligned to a Service Delivery Model Framework, I’d encourage you to look into it. You’ll be better off if you do. It may even provide you the opportunity to learn a little humility, as I did!