Process Improvement is Trickier Than You Think

There’s a famous 2001 paper by Nelson Repenning and John Sterman titled Nobody Ever Gets Credit for Fixing Problems That Never Happened, which explains how process improvement initiatives fail. I’ll summarise the paper in a bit, but I want to walk you through an anecdote first.

There’s a delightful experience that you may have had where you walk into a company — it could be your first week of work or whatever — and realised “wow, the processes here are really good. I’ve been to other places doing identical things, but the way they do X seem a lot better than in my previous jobs!” And then of course as the months drag on you figure out the things that the company isn’t so good at, the shine wears off somewhat, but you cannot deny that they’ve excelled at doing X; you realise the processes and culture and incentive mechanisms and org structure all fit perfectly together to deliver superior outcomes.

You could have a number of reactions to this. One common one is to use this experience as a reference in future companies, so that when you move on you go “oh, oldco was awesome at X when I worked there” and you try and copy certain bits of the process at your new workplace. Another is “oh, my previous company was awesome at X and this new company sucks by comparison”; you wring your hands because you know what truly good looks like; you can’t change things at your new company and so you hate that part of your life now.

The reaction that I tend to have is “who designed this, and how can I speak to them?” … because good processes rarely emerge on their own. Sure, they don’t necessarily have to be designed up front (good org processes tend to emerge through a series of trial-and-error loops), but in my experience someone has to be driving that change. And it’s usually illuminating to talk to that person; you’re more likely than not going to learn something about the way things work in the company.

Here’s another common experience that you might have. There’s a natural tension that exists between doing the work and improving the process. Say things are blowing up all the time and you can barely handle the torrent of tasks on your plate, which means you don’t have any extra time to improve the process you’re running. In some companies, the default solution to any problem is to hire more goddamn people. (This is particularly true with companies from China, for reasons that are better explored elsewhere). In other companies, you don’t improve the process so much as assume that ‘this is the way things have always been done’; nobody spends any time thinking about process improvement.

If you take a step back and think about these two scenarios, you’d quickly realise that the first experience (where some process is so darned good) must have been the result of people resisting the second experience (where you spend all your time working and none at all on process improvement). And perhaps it’s not so difficult to do process improvement in a small company context, but it gets increasingly complicated and difficult the larger the company becomes. So it’s particularly admirable if a large company has good processes that produce excellent business outcomes; the people who did such process improvements expended more energy making this the case.

At this point you might say that I’m describing a very common business experience. So here’s a thought experiment: if you work at a company (or even if you work for yourself), pause for a moment to look at some process you’re executing. Now ask yourself:

1. When was the last time this process was changed for the better?
2. How often do you typically change a process? (Also: can this particular process be improved?)
3. If you can think of a process improvement, why hasn’t it been implemented? (Or conversely, why was it changed?)

If you’re anything like me, your answers to the above questions are probably “a) the process hasn’t been changed for some time, b) we only change processes when we think there’s a problem, and c) it takes considerable effort and work to change it, which means we can only do it during a lull period.”

So, ok. Keeping your answers in mind, consider the following. You know how ‘continuous improvement’ is this fancy term from lean manufacturing that’s bandied around in other non-manufacturing contexts today? Well, think about what it means. It means that you have to spend a portion of your work time on process improvement activities. It means that one out of every five days, say, is spent not doing the work, but working on the work — taking a critical look at the way you run things, and testing small changes to improve. And it means that you do this forever — there’s no special time you set aside to improve your process; you do this at regular intervals throughout the year, workload or crunch period be damned.

Continuous (process) improvement doesn’t sound so easy when described this way, now, does it?