The Good, The Bad And The Admin

If somebody tells you they brought in a new process and met no resistance at all, I'd want to have a look at the process. Hesitation is the normal response to a new way of working and it's usually the correct one, since most of us have had something land on us that turned out to be more hassle than it was worth.

That's where I'd start with continuous improvement in construction, where the problem is rarely appetite, since most site teams would happily take a better way of working if one turned up and plenty of them have ideas about what it would look like.

What usually turns up instead is another layer on top. A process arrives to fix something, another one lands on top of it the year after, then a third gets added and nobody ever takes the first two away. After a decade the people doing the work are carrying four or five versions of somebody else's good idea, every one of which made sense when somebody had it.

So the improvement announced in a meeting becomes the thing that quietly stops happening on site, while the conclusion drawn upstairs is that the industry resists change. It resisted more work, which is a different problem with a different answer.

What I learned doing this outside construction

Before I came into this industry I was responsible for a service operation running across seven regions, all meant to be following the same process. In practice each one had picked up its own exceptions, its own little habits and its own way of handling the awkward jobs, every one of those a sensible local call at the time somebody made it.

You could see what that was costing as soon as you put the seven side by side. Customers got a different experience depending on which region they dealt with and anyone moving between regions had to relearn parts of the job. The directors were getting information too patchy to act on, since the one top level figure everybody watched moved around depending on who pulled it together and how they read it.

What we put in was a single structured process across all seven, which improved our contractual position and gave customers something better, neither of which is what got it adopted.

It got adopted because it was easier than what people were doing already. The new process took tasks the teams were carrying anyway and combined them into one simpler thing, so the working day got shorter rather than longer. There was hesitation at the start, as there should have been, then it went once people worked out that this replaced things instead of stacking on top of them.

The part I didn't see coming

Standardising the process improved the figure we had been watching, which was the point of doing it. What I hadn't expected was that it also gave us figures we'd never had before.

Once every region was recording the same things in the same way, questions that used to be arguments turned into things we could look up. Some of those answers showed up within weeks while others needed months or a couple of years of data behind them before they told us anything, with a few pointing at problems nobody had identified as problems.

That's the part I'd want anybody starting this work to understand, since one improvement is only ever one improvement, with whatever value that happens to have. The thing that changes a business is that a well designed process starts giving you the information that shows you what to fix next, so the second one is easier to find than the first and the fifth is easier again. The knowledge comes from the structure instead of from the effort.

A business that can close that loop gets slightly better every quarter, so those quarters add up in a way that's hard to catch from the outside. A business that can't has to work the same lessons out again on every job, usually with a different team, where the people who solved it last time have moved on to somebody else's project.

Why construction has it harder

This is harder in construction than it was in the operation I'm describing. Seven regions doing the same work in slightly different ways is a simpler problem than twenty projects a year with different teams, different clients, different site constraints and a programme that never repeats.

The consequence of that difficulty is that most construction businesses treat every project as a fresh start, so whatever got learned on the last one leaves with the people who learned it. Improvement stays down to the individual, so good site managers run good jobs and the business never gets any better at running jobs.

Getting out of that doesn't take a transformation programme, since all it takes is picking the thing that costs you most, recording it the same way on every job, then leaving it alone long enough to see a pattern. The small version of this works far better than the ambitious one, since one thing recorded the same way for a year tells you more than a big system everyone has given up on by March.

It's also fairly obviously given where you're reading this, what I'm building.

Asking why, repeatedly

The habit underneath all of it is refusing to accept that something is done a certain way for a good reason, which mostly means asking why until you get an answer that still stands up.

Plenty of the time you won't get there, since the real reason is that somebody solved a problem a different way in 2017 and the workaround outlived the problem, so the step survives because nobody has gone back to check whether it's still needed. Those steps are where the easy gains are, so finding them takes persistence more than it takes analysis.

It's also the least popular thing you can do in a business, since asking why five times in a row makes you sound either naive or difficult. I've found it pays to be thought both.

Where it starts

The first improvement is the hard one to find, since you're looking for it with whatever information you already have, which is usually not much.

After that the process tells you where to look.