A lot of demand comes into teams who think they have no other choice except to say “Yes” to it and start working on it. This is a common mistake and usually requires a deeper understanding of the demand coming into your system of work and / or the capacity of your team to deal with it. What you will likely find is that only a small proportion of demand is irrefutable, much of it can likely either be avoided or deferred.
A key part to understanding why not all demand is irrefutable has nothing to do with demand, but it has everything to do with capacity. In knowledge work systems, capacity is finite – you don’t have unlimited capabilities to deal with whatever comes in the door. Furthermore, expanding that capacity is often neither cheap nor rapid – it’s knowledge work for a reason in that it takes skills and particular talents to be able to deal with it. So at some point, you’re going to have to say no to certain requests, whether you like it or not.
If you do say yes to everything and go over your capacity, you’ll end up slowing things down and rushing which will impact quality – neither of which are good for providing a “fit for purpose” service. Furthermore, due to the nature of capacity being finite, by saying yes to something you are impliedly saying “no” to other things. That is, every time you take on a piece of work, you decrease your capacity to take on other pieces of work. This might not necessarily be a conscious choice, but it’s one that you should start to think about. Saying no is not necessarily a bad thing – it means you’re focussing on what is most important for your business. It’s also a mark of professionalism and leadership to be able to have honest and forthright conversations up front, because if you do say yes to everything, you’re just delaying that tough conversation and will be breaking commitments to do so.
I think the important distinction here also comes in from the fact that not every request should be “committed” to. Some people view the fact that a request comes in means that they must make a commitment. Being able to separate the request from a commitment to get it done is a key point in kanban – make sure the commitment point and capacities are known and a discussion is being had with the requesters as to what should be committed to. Making this process transparent goes a long way towards deeper conversations about managing the competing risks of the different requests.
It’s inevitable that you will have to say no to certain types of demand – so how do you do it? Firstly, understanding your different sources of demand is a good point. Some sources of demand may not have the same importance or cost of delay than others. You’ll need to establish some policies around what should come in and what get’s left behind. There may be different classes of service that you need to apply to certain requests that help you decide what to take on and when. There are also other kinds of policies that you can adopt that will help inform what to start on.
Another way of looking at what we call “deferred commitment” is not necessarily saying no, it might just be a “not yet”. That is, we don’t want to start things too early and have them sitting on the shelf collecting dust. There’s an opportunity cost in starting some things too early and you want to make sure you’re not “saying no” to some thing by “saying yes” to others too early. Sometimes, some items can be deferred for some time which might be enough to take the stress of your teams and overall system of work. Knowing when the right time to start things is as important as what to say “no” to.
Not all demand is irrefutable, you may find much of it is deferrable or not needed at all. Establishing a transparent process with appropriate policies to limit the work coming into the system will take the pressure off your delivery team and allow you to provide a more predictable, reliable and fit for purpose service. Our case study in the Kanban System Design course covers this topic really well. I guess the question you should ask yourself is do you want to be an order taker or a leader?