When a team can't meet customer demand, that demand starts to go underground.
This can have unintended side effects...
Many of the teams I work with struggle with demands from their customers.
Often, this hits in them in two ways. In one way, there's too much demand for their services. They have a large and growing backlog of requests for minor updates, trivial new features, etc and they spend a lot of time managing this backlog, prioritising requests, weeding out duplicates, killing out-of-date requests.
In another way, there's not enough demand for their services. They know they could do stuff that would add enormous value for their organisation.Perhaps they can see ways to improve existing products, channels and campaigns.
Perhaps they could improve internal processes and systems, thus increasing their capacity to meet customer demand. Perhaps they could refine existing systems in ways that would obviate the need for many of the requests in the backlog.
Most of these teams seem to start by trying to "educate their customers". They try to persuade people to prioritise the first type of demand more strictly, and to eliminate low value requests.
They try to explain the possibilities they see for improvement. Their goal is to shift things to a state where they can focus more resources on high value activities, and begin to kill off the backlog of low value requests.
A worthwhile goal. But I'm not sure they'll achieve it.
I'm more inclined to start by trying to understand their customers and the types of service they need. Often, when I talk to these customers I hear about some very different demand patterns.
For example, I can often begin to identify five distinct types of demand:
- Unseen demand. A lot of stuff gets done without ever finding its way onto the backlog. Teams do all sorts of work for their customers without any sort of formal request being raised – informal updates, regular administration, user support, etc.
- Normal demand. All the requests that get handled normally – they go onto the backlog and get serviced within agreed service levels.(People often have little idea how much fits within this category. They can see their own requests, but not all the other work the team is dealing with).
- Unmet demand. These are the requests that go into the backlog and sit there. Customers are asking for stuff, but the team is failing to deliver it to the agreed service levels.
- Suppressed demand. There are also "requests" that never go into the backlog. Customers want stuff but they don't bother asking for it because they no longer believe that the team can deliver it.The larger the backlog of unmet demand, the more likely it is that there will also be lots of suppressed demand.
- Unknown demand. Customers often don't even realise that some things are possible. In that case, they can't possibly ask for them.
When a team focuses on educating the customer, it's focusing on unknown demand.It may be right to assume that surfacing this demand will reduce a lot of the unseen and unmet demand (e.g. by reducing its priority or obviating the need for it), thus making it easier for the team to deliver more effectively. But that's an assumption.
I think it's at least as likely that bringing unknown demand into the open will push more of the existing demand into the suppressed category. And I think that suppressed demand is dangerous. When customers have a lot of suppressed demand, they begin to look for quick fixes.Or they start to bring in additional suppliers. And so on.
Such actions have side effects. They may increase coordination overheads, or they may complicate the underlying architecture of the systems. These in turn damage the team's ability to deliver, thus creating further unmet and suppressed demand. A downward spiral.
There's rarely an easy fix to problems like this. Making the unseen and suppressed demand more visible often helps – simply seeing the problem can spark creative thinking amongst team and customers.
It generally helps to kill trivial requests as quickly as possible.And improving the way we prioritise is also good, but only if prioritisation doesn't itself consume a lot of the team's time.
And of course, we can try to raise the capacity of the team, either by adding more people, or by improving the facilities available to them, or by improving their skills and methods. But that nearly always takes more time and effort than we expect.
One thing, however, is clear. Trying to change the dynamic between team and customer without fully understanding the balance of capacity and demand is risky. I'd treat every change as an experiment: move in small steps and monitor always for unforeseen side effects.
Graham Oakes helps people untangle complex technology, processes, relationships and governance. He is a guest blogger on Econsultancy.
No hay comentarios:
Publicar un comentario