Exploit variation in demand to create capacity for improvement.

One of the problems that many knowledgework processes face is that workload is highly variable. It comes in significant bursts, sometimes with predictability (eg seasonality), sometimes not.

If we graph it against time, this might be typical, with or without overarching trends.

Demand varies unpredictably over time.

Demand varies unpredictably over time.

Classical Lean views variability as waste – and it is, particularly where the peaks of activity represent overburden to our teams – and seeks to remove it. But it’s a regular problem for delivery leaders who seek to keep stable teams (which should be all of us…): how do you cope with this variability?

There are a number of approaches to this, and I’ve seen them all tried.

Firstly – and this can run in parallel with the others – level the workload.

This takes working with customers, and essentially saying ‘No’ and/or ‘Later’ to requested work. The idea is to smooth it by removing some of the least valuable work, and delay some of the rest that has a low time sensitivity. It’s not a bad idea, and certainly a discussion about what’s possible is always going to be valuable, as is a value- and Cost of Delay-based prioritisation discussion.

Secondly: staff the team so that they are always kept busy.

The peaks will be handled with overtime – and I’ve seen teams working mandatory 60 hour weeks for a couple of months to do this. The idea here is that we can’t possibly have people relaxing at work: they might end up playing Tetris and we can’t have that. But why are we blaming the people, and then flogging them? Overtime uniformly fails and delivers lower productivity than you started with after a couple of weeks. Let’s put responsibility on the system, and recognise that having some downtime is only waste on the quickest possible review, and that the costs of doing so are minimal. It’s only our attitudes to work that allows this.

Managing variability for minimum downtime.

Managing variability for minimum downtime.

Thirdly: swap people in and out of the team to match demand.

This works just fine for long term and predictable changes in demand: over the next 6 months, we’ll need three fewer people. At the end of the financial year, we’ll need another two as the customer rushes to spend their budget. This type of work is growing as it becomes more significant to the customer. But trying to apply this to the short term variation is next to impossible because the inefficiencies of bringing people into a team and then out again are painful.

Fourthly: staff the team such that all but the highest peaks are covered.

Exactly what level this is is a context-specific decision, but I’ve seen organisations have a serious attempt to set it at a long term level of 70% utilisation (success in achieving it is another matter). The highest peaks are handled with mechanism 1 above, but what do you do with the troughs?

Managing variability to handle peaks (with some demand levelling), and to support improvement

Managing variability to handle peaks (with some demand levelling), and to support improvement

It’s simple: you schedule lower priority work that can be put aside when customer work picks up. The stuff you always mean to get round to, but under constant pressure, never do. Maintenance. Documentation. But the absolute best thing you can do with spare capacity is improvement. David Anderson goes as far as to say that slack is the silver bullet of improvement.

Having the strength to make this change takes a change in mindset. How often do you hear We don’t have time for improvement”? Well, now you do. But you have to accept that improvement is not additional to your job: it’s part of it. And an essential part of it too.

When your long term average utilisation on value creating work is 70%, then absolutely you should be scheduling the 30% (or a major part of it) as improvement capacity.

Follow me
Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 Job = Work + Improvement by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

%d bloggers like this: