What is a Service Request Manager?

Are you ready to optimise your delivery ecosystem today?

book demo

What is a SRM?

Name: Service Request Manager (or SRM for short)

Focus:

That the right requests are worked on based upon the agreed prioritisation
Doing the right things
Effectiveness, not efficiency

Differentiator: Hyper focused on delivery value to meet customer needs

Related Roles: Service Delivery Manager, Value Stream Manager

Similar Roles: Product Owner

So what does a SRM Do?

We’ve previously talked about the Service Delivery Manager. You can catch up on the blog here. A similar preface to that blog is that this is not aimed to be the definitive guide on Service Request Managers. It’s our take on the role based upon our observations and discussion with those out in the industry.

The Service Request Manager is a companion role to the Service Delivery Manager. Where the Service Delivery Managers (SDM) works on the delivery system (downstream), the Service Request Managers (SRM) works on the selection of work in the funnel of options (upstream). The same way that the SDM is facilitating the process downstream, the SRM is doing something similar for the upstream.

The SDM ensures that the delivery system is doing the things right.
The SRM ensures that the delivery system is doing the right things.

For those product owners that are already playing in the strategic space, they may well be playing the Service Request Manager role without realising. It's having a business and strategic view: understanding your stakeholders and customers; being able to juggle across the competing demands; which results in the ability to conduct (the sometimes brutal) prioritisation.

As such they are the owners and custodians of the policies that drive the upstream system. You may notice there are some overlaps with the product owner role, but we’ll discuss that a little later.

Upstream Funnel

A key part of the role is facilitating all the workflow steps in the upstream: the funnel that comes from all the options we have, from the backlog, to the pool of options, what are the good options, the best options, the ones that are to be selected to do next.

Just because it’s in the backlog, it doesn’t mean they have to be done. The SRM needs to understand that we don't necessarily need to do all these. They need to be able to answer: Of all these options, how many of them actually align with the current strategy? It’s narrowing down the focus on the options we actually do want to play. What is the next best thing for us to work on?

Some examples of Upstream workflow steps:

Options | Good Options | Next Options
Idea | Analysis | Concept | Ready to Pull

To be able to do that, they need to be intimately across, and be able to define, the policies related to the upstream funnel. They need to know when and which demands progress in the funnel based upon the numerous factors such as:

Sources of the demand
Alignment to strategy
Class of Service
Desired delivery date
Team capacity
Cost of Delay
Risk assessment
Sequencing/Dependencies
Scheduling
Any new events that might change any of the above

The “art” of the SRM role is being able to merge all these factors together into a pull-based system. These policies and considerations will be different to each delivery system, and so need to be assessed and updated constantly.

A really important part of the SRM’s role is determining how each demand will enter the delivery system: at what priority, class of service, and whichever properties that drive how the work is tackled.

_{A Service Request Manager can be like the person taking all the orders at a busy coffee shop.}

Class of Service

Let’s take Class of Service as an example. For those not familiar with Class of Service, it’s a way to communicate to the delivery system how certain pieces of work should be approached. A typical set may look something like this:

Expedite
Standard
Fixed Date
Intangible

The SRM is the one that assigns the class of service for each piece of work. They don’t necessarily need to do this manually for each individual item, they can do so by defining clear policies on what Class of Service should be assigned under what circumstances. (Eg any Severity 1 Production Defect demands will automatically be assigned the Expedite class of service.) The SRM is the one that understands the criticality of the requests, has a picture of how it competes across every other demand in the system, as well as how it fits across upcoming future work.

Strategic Thinker

SRMs typically also have a more ‘strategic’ lens. They are able to look further ahead, align with the strategy, and prioritise all the competing demands together. As such they facilitate and participate in the Risk Review, Operations Review, and most importantly, Replenishment meetings. Pulling stakeholders and the team together, as required, to be able to navigate through all the competing demands.

For them to do their role well, they need to be thinking ahead. They need to be skilled in sequencing, scheduling, and reserving capacity for them to be able to ensure things are being shipped on time, maximising value, reducing the cost of delay etc.

What are some key attributes of a SRM?

Understanding your stakeholders/customers

Stakeholder management is a key aspect of the role, as they are potentially working with many facets within the business and trying to juggle various demands from all these stakeholders. It's certainly not an easy role to be able to juggle all these (often competing) desires a be able to manage expectations accordingly.

The role requires a strong ability to understand the demands, the current strategy and how to align it across the various stakeholders. Being able to understand the customer. Ability to read the system and the current environment they are operating in. To then be able to communicate to the team, to the customer, to the stakeholders. Be able to back up the calls and decisions made.

Prioritisation

Possibly the most important thing for the Service Request Manager is the selection process. They are the ones that actually bring effectiveness to the delivery system. The ability to analyse the options, understand the landscape, and make choices on which option to play.

To be able to do this, they need a strong understanding of the business context, the current strategy, and the drivers that created the strategy. This enables the SRM to have the context and knowledge to ensure that the delivery system is always maximising effectiveness. To then be able to make those micro-decisions daily to ensure that effectiveness is always being maximised.

“In a complex system of knowledge, work is moving so fast and information is emerging by the minute. What is the right thing to do is really contextual and temporal."

~ Marcio Sete, CPTO at Flomatika

What determines what is the right thing? What is the right thing now, based upon the agreed criteria, might not be the right thing tomorrow. They should always look to postpone options to the last responsible moment. That capacity is not used where it’s not needed right now.

Responsiveness

The big benefit the SRM role brings is the ability to rapidly respond to changes in a timely manner. Have someone in the team who is able to make those micro selections on a daily basis to ensure effectiveness is constantly maximised. They are a custodian of a pull-based flow system, and so are always able to look at the ‘next’ thing in a timely manner, and not need to wait for the next sprint or iteration.

Flomatika for example (at the time of writing) conducts Replenishment Sessions 3 times a week. We want to have very small feedback loops in being able to pivot/persevere, or respond to new changes. This can be very different to some enterprises which may only replenish their teams once a quarter. We’ve also spoken to people who work in an environment where they plan 2 quarters in advance, that their teams are at ‘full allocation’ and couldn’t possibly fit anything that isn’t already part of the plan. Commonly I’ve also seen teams that run two weeks sprints, but their Sprint Plans are often changed before they are even halfway into the sprint.

By having a Service Request Manager think in terms of the flow of the work, they can set the frequency of their Replenishment Sessions to ensure they are responding at the rate that their environment requires. They continuously ask “What’s the next right thing to do?” Constantly feeding the Delivery System at the rate (how often) and volume (how many) that suits the way they work, their typical productivity, and their environment. The decisions made today by the SRM, might not be the same decisions they make next week due to changing circumstances, and being able to respond to those in a timely manner.

Ability to Discard

Perhaps a less talked about ability of a Service Request Manager is to discard options. As part of their continuous evaluation of available options, they may identify some that simply don't need to be done. If it doesn’t align with the strategy, or has no hope of making it to the front of the pull system, why keep it as an option, where it is possibly clogging up your upstream funnel?

How do they differ from Scrum’s Product Owners?

Scrum is the most popular agile framework out there, and so there is often a comparison made between a Scrum Product Owner and Service Request Manager. It seems there is a wide range of how the PO role is played out in the industry, and even across different teams within the same organisation. We see Product Owner roles from being rebadged business analysts (writing the user stories), all the way up to acting as Product Managers (empowered to make the big strategic decision).

There are some overlaps between the two roles, but it’s certainly more than just writing user stories and executing on a plan. The SRM is focused on maximising effectiveness; doing the right things: consolidating all the various demands and factors that go into sequencing the work in a pull based system; and managing stakeholders. If your Product Owner is doing all this, then they are playing the SRM role.

As mentioned in our SDM blog, we can see this role also as a hat worn by someone that perhaps has a different title.

How does SRM and SDM work together?

“Well, I think it's like Batman and Robin, isn't it? “

~ Marcio Sete, CTPO at Flomatika

The two roles need to work together hand in hand. Be communicating with each other at all times. The Service Request Manager focuses on developing a strong understanding of customer needs and expectations. Be familiar with all the stakeholders, their needs and wants, be able to manage expectations and know how to balance those needs with each other. Be able to embody the strategy, understanding what we're trying to achieve together. This then manifests into managing the policies of each of the workflow steps, conducting the triage, and moving the options through the funnel: Pool of Options, Good Options, Best Options, Next Options, Ready to Start.

Then the SDM takes over, ensuring the team is pulling the next most important things to work on as defined by the policies. Ensuring that the selected piece of work progresses through the downstream system as efficiently as possible. Even if a piece is in the middle of delivery, the SRM is still involved. If circumstances change, and an item may need to be discarded, the SRM makes the call.

Service Request Manager an Emergent Role?

From what we have seen, the Service Request Manager is even less common than the Service Delivery Manager. However having someone playing the SRM role brings the benefit, having someone razor-focused on maximising effectiveness (doing the right things) enables the delivery system to be much more responsive to changing circumstances.

It’s not an easy role to play, often needing to juggle multiple competing demands in a complex system. As we see the continued transition towards Value Streams, we believe this role to become more prevalent in the future. Perhaps you’re considering it for your own teams?

‍

Other blogs you might be interested in:

‍