Soap dispensers, bank accounts and the theory of constraints.

The ActiveOps Group Headquarters are in Reading, United Kingsdom. Think Apple’s Cupertino Campus scaled down with all the nice bits removed and you’ve got it.


The ActiveOps Group Headquarters are in Reading, United Kingdom. Think Apple's Cupertino Campus scaled-down with all the nice bits removed and you've got it.

On joining ActiveOps, I found to my horror that the Gentlemen's toilets were equipped with three washbasins and only one soap dispenser. Worse still, the soap dispenser was located on the wall immediately to the left of the first basin. I found myself screaming "I don't believe it", embracing my inner Victor Meldrew.

I realise that screaming at soap dispensers isn't necessarily the first impression you want to create when starting a new role, but in ActiveOps I'm amongst kindred spirits. It's not that we all spend our days thinking about soap dispensers, but we are devoted to making operations run better.

So, what's wrong with the soap dispenser?

The process for handwashing follows three steps. Get soap, wash hands, dry hands. There really isn't a different way of doing it. Wash hands, dry hands, get soap - that just doesn't work (and gets quite messy).

Now you might think that the issue is with having just one soap dispenser. But that's not it. "Get soap" is very quick, a few seconds. "Wash hands" is much longer. The Centre for Disease Control and Prevention recommends at least 20 seconds. "Dry Hands" varies from seconds (paper towels) to hours (those old-fashioned hand dryers that never seem to do anything).

We know from the Theory of Constraints[1] that the throughput of a process is governed by its slowest step. So (as we have paper towels) its "Wash Hands" that should be the constraint. There are 3 basins, so our through-put should be 3 people every (say) 30 seconds.

The problem is with the location of the soap dispenser. By having it to the left of the basin you have effectively changed the process. People don't "Get Soap" and then move to a different basin, they use the basin immediately in front of them. The process is now two steps; get soap and wash hands, dry hands. Only one basin is used, and our through-put is reduced to one person every 30 seconds.

All of the architect's dreams, all of the builder's work, all of the financial investment in having three sinks, all of this turned to ash for want of two more soap dispensers. "I don't believe it".

And this isn't restricted to toilet design, it creeps into our own processes.

A few years ago, I opened a business bank account. I chose the bank that offered a full on-line process. It wasn't easy but after an hour of typing I'd completed the final screen and pressed "enter", "I accept the terms and conditions", "yes I really accept the terms and conditions", "no - I really am of a sound mind" and the final "I promise on the lives of my nearest and dearest that I agree".

I then received a message to tell me to call. The process required a final interview with a compliance officer. The next available appointment was in two weeks and I should count myself lucky as it was normally 6 weeks.

All that investment in IT and project time, all of that marketing spend, all turned to ash because of the inability to capacity manage, creating a rate-limiting step and building massive inventory.

The Theory of Constraints is 35 years old but remains as relevant in today's digital world as it ever was.

It would be great to hear your examples of "I don't believe it" processes. Please add to the blog discussion.

As for the toilets in ActiveOps Group HQ? After extensive negotiations with our landlord, we have a second soap dispenser. The fight continues...

[1] "The Goal", Goldratt, 1984



“Stuart has over 28 years of experience of leading change in service operations. His career has spanned project and programme management, strategy, consulting and leading operations divisions and functions. After 17 years with HSBC working in the UK and India, he moved to Abu Dhabi heading operations for ADCB.

Stuart joined ActiveOps in 2016 and leads its Customer Success function.”

Stuart Pugh, Chief Customer Officer, ActiveOps