“Hi, nice meeting you Shuman. What do you do?”
“I am a Service Delivery Manager.”
“Service Delivery Manager eh?… so… what DO you do?”
This is typically how the conversation goes when I meet someone new. It seems like the role of a Service Delivery Manager (SDM) is not very self-explanatory. After reading this article, I hope you can get a better understanding on what a SDM is, as well as what I do to fulfill the responsibilities of a SDM.
What is a Service Delivery Manager?
If you are familiar with the Kanban Method or Systems Thinking, you will realize that a business requires interactions among multiple groups to complete most end-to-end customer requests.
Typically one would associate customer-facing groups with fulfilling customer demands. However, it is important to note that other groups, despite being invisible to customers, have significant impact on delivering services too.
The following are some examples of customer demands, along with the groups that help serve the customer:
- Eating out: Host, Waiter, Bartender, Chef, Bus Boy
- Travel through flight: Airport Staff, Customs, Ground Crew, Air Crew
- Software feature request: Client Services, Product, Design, Engineering
Most businesses are organized into specialized departments: Marketing, IT, Finance, etc., yet the functional managers of the departments usually do not have a clear view of the entire service delivery pipeline. In order to deliver service that spans across multiple groups, someone needs to manage the end-to-end delivery of the request. This particular person is what we called the Service Delivery Manager.
In my opinion, there is no one-size-fit-all way to fulfill the responsibilities of a Service Delivery Manager. Therefore, the following is NOT intended to be a recommended best practice, but merely the approach that I choose to fulfill the role based on my situation.
So… what DO I do?
“94% of problems in business are systems driven and only 6% are people”
- Dr. W Edward Deming
We have all heard cases in which customers complain about their expectations not being met. Based on what I have learned, most of the time these problems are related to the system instead of the people.
A system is a collection of elements that interact with each other to fulfill a common purpose. Thereby a service delivery pipeline is a system that consists of multiple interdependent components for the purpose of delivery services to customers.
As a Service Delivery Manager, I mainly focus on unblocking, designing, improving, and inspecting the service delivery system to close the gap between customer expectation and system capability by assuming the following roles:
1. Plumber — Unblocking the System
I believe that most people are intrinsically motivated to do great work, which feeds into delivering great work, and then translates into happy customers. However, somehow we often hear customer dissatisfaction related to wait time, quality, scope, etc. What could possibly cause this mysterious gap between people’s commitment to excellence and meeting customer expectations?
One reason could be that the system unintentionally restrains people from giving their best. Another reason could be that although people are individually delivering what is expected of them, the interactions or hand-offs between people are not the greatest.
Hence, as a person with an end-to-end view of the system, I help unblocking the service delivery pipeline, just like a plumber unclogging the drainage system, such that the pipeline could flow smoothly. See the table below for examples of some systemic problems along with our solutions on unclogging the pipeline by applying the Kanban lens:
Unclogging is usually more than being reactive and fixing the flow in an ad-hoc fashion as problem arises. So how do I proactively design a systemic change to improve the service delivery system?
2. Architect — Mapping and Designing the System
In order to improve something, I first need to understand. Unlike real-life buildings though, the service delivery pipeline does not have a physical, observable form. Thus, functioning as an Architect, I need to map out the current process and observe the flow of work throughout the system. Some observable points include:
- Where do our customers submit their requests?
- Which group delivers the service to the customer’s hand?
- What are the dependencies among groups?
- What are the prerequisites for groups to start their portion of work?
After carefully understanding how components in the process interact with each other, I can then design an actionable experiment on improving our service delivery system as a whole along with hypothesis for the impact of change. For instance:
- Problem: Engineering is starving. There isn’t enough work!
- Experiment: Introduce a buffer in front of Engineering that always has at least 2 items ready to be picked up
- Hypothesis: If we introduce a buffer in front of Engineering to queue up work that is ready to be picked up, and if we make sure that the buffer has at least 2 items in there at all times, we expect to see no starvation in Engineering anymore as seen through the visualization board. We will check in after 2 months to assess the impact of the experiment.
Now that I have an experiment ready to go, what is next?
3. Change Agent — Improving the System
After drafting an experiment for improvements to the system, it is essential to reach out to stakeholders from different domains within the pipeline (and sometimes including the customers) for feedback.
While gathering feedback, I typically focus on their concerns and resistances. Whenever possible, I invite stakeholders to partner with me on tackling these impediments. Some major hurdles include:
- Lack of supporters
- Not the right time to implement the change
- Limited spheres of influence to enable the change
Occasionally impediments are too persistent for us to start the change right away. This is when we either redesign the experiment, or lay some ground work prior the beginning of our next attempt.
After everyone agrees to support, we will refine the approach and hypothesis together so that we collectively own the experiment. With stakeholders’ enrollment, we can finally start implementation — but how do we know if we are actually creating positive outcomes?
4. Data Scientist — Inspecting the System
After the change has started, we need some kind of mechanism to inspect the effectiveness, health, and improvement of the service delivery system. In other words, we are trying to validate our original hypothesis. Thus, acting as a Data Scientist, I gather information to answer the following questions:
- What do customers expect from us?
- How much of the customer’s expectation are we satisfying?
- What is the health of our service delivery pipeline?
- How are we improving our service delivery system?
Discovering customer expectations informs us of our goal, and understanding our delivery capability gives us our current state. The delta between the two, therefore, is our area of improvement. As the change provides positive outcome, the delta should start shrinking.
If the delta continues to exist after the experiment is completed, then I continue to put on the Plumber, Architect, Change Agent, and Data Scientist hats for the purpose of providing better services to our target customers.
The above roles do not necessarily operate in sequence as listed above, instead they can intermingle based on need and situation. For example, while I am understanding the system as an Architect, I also need to act as a Data Scientist to gather the current metrics of the pipeline.