Why I Was Wrong About Something I Thought Was Obviously Right

A long habit of not thinking a thing wrong gives it a superficial appearance of being right. – Thomas Paine

Many years ago I went to a two-day management session for young engineers.

One of the things we had to do was give a presentation on the challenges of developing a product.

I remember that presentation – our group talked about the iron triangle of cost, quality and time.

As you will remember, if you try and improve any two the third tends to go out of control.

If you want to reduce the cost and improve the quality it inevitably takes longer.

This is not a new idea and, a few decades later, I’m still bringing it up every once in a while.

So it’s a little embarrassing to realise that I’ve been wrong all this time.

Wrong at least when it comes to applying this model to modern organisations.

I mentioned in my last post that I’d picked up a book by John Seddon and I’ve also been watching a few videos.

And what he talks about does make you question these long-held assumptions.

I suppose the iron triangle theory came out of a world focused on manufacturing and production.

At the same time, that’s old stuff really. When manufacturers started to focus on managing variation they found they could improve quality, get things out faster and keep costs down and the iron triangle was relegated to the dustbin of historical theory.

I just hadn’t received the memo.

Anyway, if you work in a service organisation, as most of us do, how should you think about service design.

Let’s take an example.

Let’s say you have a small consultancy that provides environmental consulting services.

When the volume of work coming in gets too much for you to handle you look at recruiting.

You hire an admin person, then another consultant, perhaps some graduates.

Pretty soon you have a team and it seems to make sense to start getting some specialisation going on.

That team can do ponds, for example, while the other one can do rivers and the one in the back room can do marshlands.

Pretty soon you have all these teams doing different things and if a customer comes along who has a pond, river and a marsh you get all three teams working hard on their little bits.

Things get dropped, one team’s priority is another team’s back burner work.

Things take longer, mistakes start being made and people get upset.

So you hire a manager, assure customer that you have SLAs in place, get yourself ISO 9001 certified and sit back knowing that you’ve improved the organisation.

Except, the mistakes keep happening and happening and happening.

The problem is that you try and tell people what to do rather than letting them figure out how to make the customer happy.

All this structure and specialisation and job roles are about control – about you being able to create a system you can control.

But an organisation is not like a car with pedals and a steering wheel – it’s a system that responds to what’s going on outside and inside it.

And that means you need to think about designing your business differently.

What you should start with is the customer and what his or her demand is.

Take a simple example – a customer comes in to your business with a broken pot – that’s customer demand.

What that customer wants is to get the pot fixed – that’s value work.

As a business your role in this is to provide the expertise to fix that pot.

And the entire point of your organisation should be to make that happen cleanly – without making a hash of it.

You might think that it’s expensive to have the expertise there to fix the pot – surely it’s cheaper to do it with someone less expensive or outsource it to someone else?

But what ends up happening is that all those attempts to reduce cost actually end up increasing costs – through breakages and failures and misunderstandings and confusion.

The point is that you can throw away the iron triangle and be able to provide a great service, quickly and cost effectively.

But you’ll need to change the way you think about how you build your organisation – and start to think in terms of systems.

And that’s a topic for a book, not a blog post.

Cheers,

Karthik Suresh