I'm working with team working in a service delivery model. They are getting requests from the rest of a rather large organization. They don't have too much contact with the business side. We are implementing Kanban. How can they use Kanban to shape the demand? I understand how Uber shapes the demand by dynamically changing the price, but this team is not charging their clients. Are there any techniques to shape the demand in this case?
Shaping demand isn't a Kanban problem per se, but Kanban can certainly help in two ways. First, Kanban provides a lot of visibility. That means that if you try some action to shape your demand, you can fairly quickly see concrete numbers to tell you if that action was successful.
Second, Kanban does have the notion of "Classes of Service" which can be leveraged to some degree to drive the nature of requests. For example, I know a team who told their internal customers "If your request fits into one of these standard builds, we can automate it and the SLA is 4 hours. Custom requests require a meeting and we try to fulfill them in 2 days, but some requests take longer." Now, you might think, as they did, that this won't work because people need what they need. That isn't how it played out though. It turned out that most custom requests were just people taking different options because they didn't know if mattered what they selected. Once the standards were in place, a lot of people followed them, lowering overall workload on the team.
Theory Behind Demand Shaping
In the Uber example, there are a few things that you have to look at. First, they treat every driver as effectively interchangable (within its class - you have things like UberXL). This means that their primary concern is a roughly even number of drivers and requests. Second, the motivating factors for drivers and riders are wait time and cost. The driver wants to make more money, the rider wants to pay less, and they both want low wait time for rides. Now, because wait time is reduced when the number of drivers and riders is in balance and it's hard to manipulate in isolation, the cost becomes the main lever, causing them to raise and lower the cost of rides to balance out the ratio.
For your team, you need to identify what you are trying to shape and what your users value. Are you simply trying to shape number of requests because all requests are roughly equal or are you trying to shape types of requests too? As you said, there is no direct charge, but what do your users value? In the example I gave above they valued turn-around time. This applies for a lot of internally-facing teams, but not all. You need to find that and then incentivize the behavior you are looking for. As I said before, where Kanban will help the most is that any action you take should have measurable results in your kanban system.
You cannot. Kanban (and the alternatives) are systems to work through what is demanded. It has no methods to shape demand because that's the wrong end of the system.
Kanban is the way to make sure, tasks are done most efficiently by the team. How many tasks come up is beyond that plan.
Imagine a callcenter. They introduce a mechanism to route their calls most efficiently maybe using Kanban. But there is no way for that process to control whether it's a slow day, or their product just broke down in a spectacular fashion and every other customer is calling the hotline.
Kanban works and it does not care whether there are 5 or 5000 requests. You may find a way to prioritize those 5000 requests but there is no way to stop it from becoming 50000 requests. Not inside Kanban. You will need a different system for that.
One possible approach would be to use the cycle time and backlog size to calculate the typical time it will take for a new work request to complete.
Cycle time (work starts to production) = 4 days
Current backlog = 5 items
Time for new requests to start = 4 x 5 = 20 days
This assumes that new work items will be added at the bottom of your backlog.
Publish this value and the more you have on the backlog, the larger the value will be. This can act to discourage the flow of new work requests. As the backlog gets shorter, the value drops and so encourages more work items to be added.