“Respect the current process, roles, responsibilities, and titles.”
If you’ve been following along our blog for a while, you might have read this statement in some of our articles. This is one of the principles of Kanban project management. This principle explains how Kanban does not come with an extensive list of roles or titles to fill.
Teams can start with whatever roles they have and establish new ones that will make sense for them later on. “Start with what you’re doing now,” as we say in Kanban. After years of practice and use in the workplace, Kanban has evolved. There is a clear emergence of two Kanban roles – the Service Delivery Manager and the Service Request Manager.
Service Delivery Manager
The Service Delivery Manager (SDM) is responsible for ensuring a smooth flow of work. This kanban role is also known as Delivery Manager, Flow Manager or Flow Master. It first emerged in 2005 when Microsoft started used Kanban. While we do see organizations establishing SDM as a distinct job position today, its first implementation wasn’t the case. In its early conception, a project manager performed the Service Delivery Manager role. The Project Manager role was then elevated to perform the necessary service delivery functions expected of them.
Service Delivery Managers have the following responsibilities:
- Making sure that work items flow through the Kanban System
- Facilitate continuous improvement initiatives and process reviews
- Facilitate Kanban meetings or the 7 Kanban cadences if the team adheres to it
- Ensure that processes are working towards delivering customer satisfaction
There is no hard rule on how to implement the SDM role. Options include expanding the responsibilities of an existing project member or adding a new team member to fill the role. The role can be filled by an existing team member or performed by the team as a whole. But this requires a high level of service delivery capability and maturity. This means that the service delivery principles and mindset are so ingrained in each team member that the functions of an SDM become second nature to them. They do not need someone to point out the delays and bottlenecks in their system. They have meetings regularly that are productive. They continuously improve their process to ensure consistently high levels of customer satisfaction.
Having a team with such high levels of maturity could be a long way to go. So for organizations where customer focus and service delivery maturity is weak, a service delivery manager position would be very helpful.
Service Request Manager
While the Service Delivery Manager handles the flow of work within and out of the Kanban system, the Service Request Manager (SRM) handles the flow of work into the Kanban system. Before the team commits to their work items, it’s important that a discussion about what yields the most value for customers has taken place. This is not to say that the SRM will decide which items the team would commit to.
The SRM initiates the discussions that lead to decision-making around these service requests. Imagine the SRM facilitating a discovery session with stakeholders, account managers, and product managers. Add in a kanban board filled with ideas and suggestions for their products next release. They would go over each one and facilitate the exchange of opinions and ideas from everyone present in the room. The SRM doesn’t call the shots, but they do maintain the policies that govern the selection and review process for these service requests.
The Service Request Manager is often compared to and regarded as a similar role to the Product Owner in Scrum. While there may be some similarities, the intention for the roles is completely different. While the SRM is an advocate for the needs of a product or service’s end-customers, it is not meant to perform decision-making responsibilities around what gets into the product and what doesn’t.
The reality is that one person cannot be all-knowing of what yields the most value for customers. The role should evolve to be someone who can facilitate discussions around the product. The Service Request Manager is responsible for maintaining the mechanism that drives product governance and direction. This would require creating and upholding system policies, including evaluating and managing the risks that go into these product decisions.
While the role is not very common in organizations, we do see that the responsibilities are more often performed by account managers, product managers, or even project managers. There would also be instances where a Service Delivery Manager performs the functions of an SRM. This would often be in cases when the organization has a strong sense of their customer’s needs. But for instances when product ideation and discovery is a focus of the company or customer contact is weak, having a dedicated person to perform the Service Request Manager role would be beneficial.
When do we need a Service Delivery Manager and a Service Request Manager?
As previously mentioned, these two Kanban roles are not mandatory. However, having either one or both of these roles will be beneficial for the organization. Having a Service Delivery Manager puts a step forward in ensuring that operations are not just efficient but are working towards what customers actually want. Traditional project managers would focus closely on operational metrics which do not necessarily translate to high levels of customer satisfaction.
It is important for organizations to realize that no matter how fast they create their products if it doesn’t align with customer expectations, it would not be successful. A service delivery orientation and mindset is first and foremost customer-centric. Having an SDM role filled will ensure that this area is covered and you can continuously improve processes to drive better business outcomes. That being said, we recommend that when implementing Kanban, you should have a Service Delivery Manager.
The need for the Service Request Manager is mostly driven by the lack of solid customer interaction. Most organizations have account managers or product managers that go into the field and interact with customers. In this case, they can fulfill the role of an SRM. But if the connection with customers is insufficient or distant, there will be a need to establish a role that is able to proxy for customers.
Another driving force for having Service Request Managers would be if the organization has a strong research and development forefront. For highly innovative companies, a Service Request Manager will be in charge of marshaling ideas and options that would make it to the product backlog. For very large organizations with a suite of interrelated products and services, having a Service Request Manager is also advisable.
Do we need to hire new people to fill these Kanban roles?
The quick answer is no. However, certain situations may require you to add new people.
Although no one is stopping you from having these Kanban roles filled, we strongly believe that you also do not want to introduce too much change in your process all at once. When you first implement Kanban, you don’t want to immediately introduce these new roles. We believe that the injection of these Kanban roles would gradually happen over time.
You also don’t necessarily need to hire new people. Instead, try having the role be performed by an existing team member. You most likely already have a project manager on your team. You can explore having their role evolve into a Service Delivery Manager. The same applies to the Service Request Manager. Try to assess what current roles and functions you have within your team that can naturally be elevated to these Kanban roles.
Now, there could be reasons for you to have dedicated persons for these roles. Having a dedicated SDM would allow you to have a person outside of the workflow who can offer a different point of view as to how work is flowing and done.
A different perspective can offer different angles or opportunities to improve your processes. This also allows your product teams to focus on the way they do their work, while the SDM essentially manages the flow of the work. As for the Service Request Manager, we strongly suggest you have a dedicated person for this role when dealing with product ideation, innovation, and discovery.
We see these two Kanban roles gain recognition and are being utilized more often. We certainly won’t be surprised if these roles somehow evolve in the future or we may have other roles that will be introduced. The nature and complexity of how we do work and what types of products and services will be demanded of us in the future will drive these evolutions. In the meantime, try and see what these Kanban roles can do for your organization.