The School of Knowledge is a newsletter for SME owners and investors who want frameworks they can actually use —frameworks, checklists, and operating manuals every weekend, built to read on weekend and use on Monday.
On Friday the 11th of September I boarded a plane from Manchester to Majorca to celebrate both my in-laws 70th birthdays with my wife and family. It couldn’t have come at a better time. I’d just spent the last three weeks working 12 hours days to hand over a project, in addition to renovating the ground floor of my house. Neither were finished but I was happy to forget about them for a week.
I boarded the plane and loaded up things to read for the short flight. I selected an article that’s been sat in my ‘read later’ list for a few months and it turned out to be something I desperately needed to read. The kind that feels like cold water has been thrown on your face after a deep sleep.
We’d secured a new client for a relatively small sized project after another contractor had let them down at the eleventh hour. The project had a handover date that simply had to be met, which on the face of it looked impossible to meet—yet the opportunity presented was too good to turn down. The client was a trust with more than a dozen schools in its portfolio, and schools always have work that needs to be done and money that has to be spent.
I’d decided that I was going to run the site because of the constraints it presented: a very tight timescale and LADs (financial damages for exceeding the handover date) of £6,000 a week until completion. It’s not that I didn’t trust any of my employees—but being honest—I wasn’t even sure we could deliver this.
For the last 13 months we’ve been using a project and financial software called Procore; an American company listed on the NYSE that serves the construction industry. The software has a steep learning curve, but has potential to not only save time and money on projects, but ensure everything is correctly recorded and compliant in an ever regulated industry. I’d noticed issues some of my site managers were having implementing the software, but I felt confident this software could be the difference between a successful handover, or financial and reputational damage.
I was wrong.
Using the software on the project started off great, but as time went on and that impossible deadline loomed, the software became a burden. I was left with a choice of ensuring all the fancy tools were being used or actually getting the work done. Something many readers will resonate with regardless of industry. In the end, I defaulted to the easiest communication methods of phone calls and emails to organise my site, labour and materials.
Including training we’d spent in excess of £25,000 to find out the software was a dud. That was until I read: “Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement.”
Suddenly, it all made sense.
The 2002 award winning paper might be nearly 25 years old but it still perfectly describes the constraints, traps and biases people have when it comes to implementing something new into their business. The authors, Nelson P. Repenning and John Sterman, are experts at understanding and implementing organisational processes, systems thinking and process improvement at the business level.
What I want to do today is give you the meat and veg from the paper without you having to read the 30 pages, as well as show you how my own attempt at process improvement failed exactly how the authors described. I’ll then state what I’m going to do to rectify my shortcomings, which should be useful to anybody thinking about process improvement themselves.
If you have your own business and don’t understand why things aren’t working as you think they should—or if you’re boss is constantly on your back when it’s clear as day what the real problem is—I think you’ll enjoy reading this.
The Dynamics Behind Process Improvement
Today’s managers face a paradox. On the one hand, the number of tools, techniques, and technologies available to improve operational performance is growing rapidly. On the other hand, despite dramatic success in a few companies, most efforts to use them fail to produce significant results. The inability of most organisations to reap the full benefits of these innovations has little to do with the specific technique. Instead, the problem has its roots in how the introduction of a new improvement effort interacts with the psychical, economic, social and psychological structures in which implementation takes place. - Repenning and Sterman.
The difficulties I experienced a few weeks back will resonate with many of you. Whether it’s implementing new project management software, updating a manufacturing process or going all in with agentic AI across your business; a lot of the time it just doesn’t work as well as you thought or expected. But who’s to blame? Is there an issue with the software? Is AI just hype after all? Perhaps your employees aren’t as intelligent as you thought they were; perhaps you’re not as intelligent as you thought you were either. The real issue of why businesses fail to successfully implement new software, new process, new technology is a systematic problem. Consider why, some 25 years later, with all the technology and with all the data we have at our disposal—we often aren’t any better or closer to achieving our goals.
Why?
Because, some things change with time, but some things don’t. And something that doesn’t seemed to have changed very much over the last 25 years, is the choice people are often forced to make: work harder to achieve the goal or work on improving the process.
How Process Performance Works
The actual performance of any process depends on two factors: the amount of time spent working and the capability of the process to do that work. - Repenning and Sterman.
There are two ways to improve the performance of a process: increase effort or increase time spent on improvement. Increasing effort leads to improvements in output only for as long as the extra effort is being expended. If a manufacturing line works an additional 8 hours a week, all things being equal you should expect an extra 8 hours of output. But, output is capped by the amount of additional effort expended. The other option is to spend time improving the capability of the process. Capability is the ability to achieve a specific outcome and can be thought of as a stock that increases or decreases over time like a reservoir does with water. The authors argue that gains made in improving the capability of a process increase output for every other subsequent hour of effort. Time spent on improving the process increases the flow of investments in capability that augments process capability. So, if time spent working on improving the capability of a process is by far the better long term and obvious solution, then why do we not default to choosing it? Well, getting to the root cause of a problem or finding appropriate ways to test for better solutions takes time and can yield flaky results. Crucially, there’s also a delay in time that feeds back into the capability of a process.
In addition, processes—whether good or bad—atrophy. The introduction of new technology can make existing processes cumbersome, processes become outdated, and expensive machinery and plant eventually succumbs to wear and tear. This is shown as an outflow in the diagram represented as capability erosion.
The goal of any process is to achieve a particular outcome shown in the diagram as desired performance. The actual performance of the process may show you have a performance gap. The performance gap is what you physically feel or see when something isn’t working as well as you thought it would.
So how do you close that gap?
Closing the Performance Gap
The first option available to managers to close a performance gap is to work harder, as shown by the balancing feedback loop B1. This increased effort—represented as time or energy—increases the performance of a process and aims to close the gap between actual performance and desired performance.
Pressure to do work includes explicit messages, such as telling people to work harder, faster or longer—sometimes all three—and imposing more severe penalties for missed targets. It also includes implicit actions such as micro-managing or stringent oversight to ensure targets are met. Other measures can include the frequency and detail of performance reviews and the increased seniority of persons undertaking them.
The second option available to close a performance gap is to improve the capability of a process. This is represented in the diagram as B2, another balancing feedback loop that requires you to work smarter. Managers under pressure to close a performance gap can choose to apply pressure to improve capability. Time spent on improvement of a process is an investment in capability that in theory, improves capability. Mechanisms to improve the capability of a process can be improvement programmes, feedback and openness to experimentation and investment in training. If these investments are successful they should eventually increase the capability of a process leading to benefits that positively affect your bottom line, improve working conditions or make employees value their jobs more. However, there are limitations to selecting this option.
As mentioned earlier, there is a delay from the time spent improving a process to benefitting from an improvement in capability. Furthermore, the improvement programmes, free reign or investment in training may not produce the results you wanted—you could actually make things worse. Finally, working smarter doesn’t really help managers facing the pressures of closing a performance gap right now. Because of this, working harder is often the default behaviour, despite the obvious benefits to worker smarter. I’m not saying that working harder should be removed as an option; but it shouldn’t be considered standard practice.
Is it any wonder why people, machinery and morale decays quicker than people expect?
The Reinvestment Loop
To understand why people inadvertently prefer working harder to working smarter you have to understand the connection between the two options. Most businesses hate waste (even though most are obviously wasteful) and rarely have the excess capacity that’s needed to improve capability. Consider the options available to me on my project: 1. work harder to deliver an impossible deadline, or else financial damages of £6k per week or, 2. work smarter by removing myself (and my staff) away from the project to work on improving our processes. It might look like there’ wereotwo options there but I can tell you now it didn’t feel like there was. The only option we had was to work harder. On the final week, one of my employees did a 20 hour shift!
The limitations and costs of working like a donkey for so hard and so long should be obvious to anybody who’s ever done it. The diagram below introduces a reinvestment loop that acts as a positive feedback loop driving whatever option has been chosen. To chose to work harder is to chose to positively reinforce that behaviour, which unsurprisingly, leads to working harder in the future. It might be called a positive feedback loop, but unless you don’t enjoy spending time away from work—or if you love being overworked—there’s nothing positive about it. It makes people miserable and businesses weaker. Consider the comparison of a reinvestment loop in working smarter, though. Businesses and organisations that invest in working smarter improve process capability, therefore increasing performance and closing the performance gap. As the gap shrinks, more time is available to invest in improving capability, which leads to further improvements in process capability.
Shortcuts and the Capability Trap
My sister in-law said something years ago that’s always bugged me. She said: “I do the bare minimum at work, or else that new and increased effort becomes my baseline.” Good luck being a cog I thought. But, after reading the article and thinking this through I can understand where she’s coming from. If businesses do opt to working smarter And increase desired performance it is entirely foreseeable that management may get tempted to cut costs, increase pressure to improve schedules or remove some of the extra resources that helped improve performance in the first place. This then takes time away from improving capability which after a delay widens the performance gap; and around you go again in that vicious loop of working harder. Again, why would we deliberately chose to reinvest in a loop that is not to our benefit? Diagram 5 introduces a link between time spent on improvement and time spent working, shown as balancing feedback loop 3 “shortcuts.”
When there is a performance gap there is an increase in pressure to do work, which offers two options: spend additional time on improvement or spend additional time working. You can see how tricky this is, especially if you have a stone-faced boss wanting nothing but results, but isn’t intelligent enough to spot the repercussions of constantly grinding the axe.
And this is why shortcuts are tempting, because there’s an injection in actual performance for the additional time spent working. This is the capability trap, and shows the pressures people face to take shortcuts or cut corners to provide immediate results that only bite them on the backside weeks or months later. If you’re taking shortcuts to meet demand—you’re not spending time on improvement—and capability eventually depreciates.
To illustrate what we’ve discussed so far let’s look at two simulations as represented in the illustration below: one where a team opts to work harder and the other team chooses to work smarter.
The first team begins to notice a performance gap between desired performance and actual performance, and decides to crack the whip and force everybody to work harder. Overtime is mandatory, maintenance schedules are put on hold and additional staff are brought in to help close the gap and get this shoddy mob in gear. There is immediately an increase in actual performance because of the additional time spent working on the process. So far, so good. However, time is no friend to those who persistently take this path. Time spent on improvement has decreased at the expense of time spent working, and eventually (after a delay) capability decreases.
The second team also begins to notice a performance gap between desired performance and actual performance. They’ve had this issue before, and don’t want this becoming routine so decide to invest in capability of the process. After identifying the problem, the manager opts to spend time on improving the process. There is immediately a drop in actual performance as people are taken away from time spent working, however, after a delay there is an increase in capability which closes the performance gap and desired performance is achieved.
The capability trap is not limited to one type of industry—from SAAS to construction—no one is immune from it. But why? To understand why intelligent (and unintelligent) people persistently fall into the capability trap, and opt to work harder, I want to discuss my previous project.
Case Study
On my project, capability is defined as my companies command of the tools, documentation discipline and ability to run a project without me being there. Additionally, this was the first project where we would implement every single one of the tools not only on our side—but client side as well.
The first week we hit the ground running and completed all our weekly projects tasks. This was achieved because the first week consisted mainly of demolition of which my company was responsible for. Between taking walls down I would jump on my mac and begin to use the software in lieu in how we would usually send, request or record information needed throughout the projects lifecycle. The software also has a mobile app which meant there wasn’t a choice between being on site or in the site office like previously; I could do what I needed to do anywhere.
The second week also got off to a good start, but as the week went on small things started to go wrong; they always do in construction. When you start to investigate things that were hidden when you priced a job, seldom do all your projections go the way you want them to. The first issue was the floor. Instead of there being one layer of floor to uplift there was three, four layers in some areas. Our floor layer brought in: ”the finest German engineering” machine to assist, only for it to constantly break down. Even when it did work, it wasn’t much use—the floor was effectively concrete. I had to jump in and help the flooring subcontractor until two days later we threw in the towel and decided on a different plan. With the programme already slipping, and the pressure to do work building, the second week was where weekend work began as I diverted from working smarter to working harder.
The third week introduced more problems, and I had reverted back to old habits of organising my site because that was the quickest and easiest thing for me to do. I was deliberately taking shortcuts to meet current demand. My site office had turned into storage as we were running out of space on site, and my phone was constantly overheating—especially when using the software app—meaning most of time it stayed in my pocket so it wouldn’t die and I could take or make calls when needed. I’d also given an incorrect measurement to the laminated cubicle manufacturer after not back-checking their design against the architects screenshot that was issued outside of the software. Subsequently the install date was moved a week back, which further increased pressure to do work and spun the work harder flywheel even more. This is a classic problem in construction; one that turns your stomach upside down because you know it was entirely your fault and it was entirely preventable. Now there was just absolutely no time to even consider working smarter. That was a distant memory; a dream I had a few weeks back.
The fourth week I was on a sun lounger in the Majorcan mountains and the first couple of days I was anxious. I was on my phone at 4am in the airport responding to emails and chasing people, until my wife reminded me where I was and what the occasion was. It was even harder to ‘switch-off,’ because I was with my father-in-law—founder and business partner.
Back on site, still more problems were surfacing. The dry lining company hadn’t finished their work the prior weekend meaning one of my site managers did a 20 hour shift the following Wednesday to finish it off. Whilst also replacing the carpet in the meeting room, it became clear that some of the floor sub-structure had rotted from a previous leak and was close to failing. It would have been easy to cover it back up and replace the carpet given the time pressure—especially as you couldn’t see or even feel it—but my site team (correctly) decided to put it right before laying the floor. Work, harder, harder, harder boys!
Whilst on that sun lounger it occurred to me that the two other site mangers I had on that job didn’t know how to use some of the newer tools I had decided to implement on the project. One of the tools requests and manages different types of project documentation, and the other tool is designed to centralise, define and standardise quality, safety and compliance requirements across projects. Furthermore, they did not have access to any of the financial tools which would include the quotations from the subcontractors, costs thus far and remaining budget. The only way to get them, was via email or make a call to the commercial team. I had also taken the decision to not upload this project to our old system, in fear that—as had happened before—information and usage was split between the two. If anybody has been responsible for implementing a new process—and people constantly chop and change between the two—you will understand how infuriating and discouraging that can be.
So was the project a success? From a delivery perspective—yes. The client was over the moon that we managed to meet the deadline and wanted more work doing which subsequently moved the handover date back five days. Was the project a success from a software implementation and new process perspective? No, it wasn’t. However, there were silver linings from using it. I now realise just how much time needs to be spent front loading the software, before anybody even steps foot on site to prevent the software from acting like an anchor.
Regardless, I’m immensely proud of what we delivered given the time we had to do it. We even decided to reward our staff with bonuses. However, the observant reader should now notice why this type of reward for this type of behaviour is exactly what the authors warn against. What was I rewarding exactly?
Working harder.
The Biases That Keep You Working Harder
Managers who mistakenly attribute low performance to the attitudes and dispositions of their workforce inadvertently force the system into the capability trap. - Repenning and Sterman.
There are two biases the article names that feed the capability trap:
Fundamental attribution error. When a manager sees low performance, they tend to credit it to the workers character. This is easy to do, because managers can’t be in all places at all times. And because they can’t be in all places at all times they jump to conclusions, led by their previous experiences with that member of staff. It’s far easier and quicker to blame it on the characteristics and flaws of the individual, than it is to blame the system. We overate personality and underrate circumstances when judging others.
Think about it, you’ve always got an excuse when you mess up, don’t you?
Self-confirming attribution error. A manager takes issue with a member of staff who he believes is slacking. His output is 25% lower than the two other people who make up his team, and as a consequence he’s slowing down other departments reliant on them passing on their completed work. The manager pulls him aside and lets him know his performance isn’t good enough and needs to improve; he’s letting the team down. Frustrated, and slightly embarrassed, the worker finds another gear which immediately boosts his performance and output. The manager sees this and approves of his newly developed appetite for hard work. But what has happened to the managers suspicions about him slacking? They’ve been reaffirmed. As time passes the employee becomes exhausted, but rather than slow down to a manageable speed (and risk the wrath of his boss again), he decides to take shortcuts to continue to meet demand. This obviously can’t go on forever (regardless of what the 24 hour hustle culture says), and eventually he slows down leading to his manager being back on his case; except this time he’s not only lazy, but useless and incompetent, because his manager’s found all of the shortcuts he’s been taking. When workers sense this self-confirming bias they often try to hide their shortfalls rather than flag them early, which turbo charges the bias.
Recognising the shortfalls of these two biases is the first step to improving processes. After all, if you aren’t willing to accept that the system may be the problem, nothing you do will produce lasting change.
Make Working Smarter the Standard
You could drive your car at 100mph without wearing a seatbelt and live to tell the tale 99 times out of 100. But it only takes one time for you to mess up, hit something and smash headfirst through the windscreen into an early grave. Likewise with working harder; nothing looks like it’s broken until it’s in pieces in front of you.
I’d spotted the gap before we even stepped on site. I just did what the article says everybody does—I bet on working harder closing it instead. My company’s difficulty in getting value from Procore is a capability problem—not a software problem. My staff and I have not undergone the implementation needed to give the software the best possible chance of success, regardless of how much time I have spent trying to understand it. This is how working harder increased our short-term results, but decreased our capability in using the software because there has been next to no time to implement it across the board as we focused on delivering projects over the busy summer period.
Software may have improved enormously since 2001—but the constraint is having the spare capacity to learn it—and that hasn’t changed.
Before I wrap this up, I wanted to offer a counter argument. Sometimes people genuinely are lazy, incompetent or a bad hire. You can offer some people all the support, all the training and give them access to all the tools and they’ll still not meet the standard. You can’t put square pegs in round holes—no matter how hard you hammer them.
This is the peril management faces; understanding the difference between acknowledging it’s a system problem or a bad hire. On top of this, improved capability has its own issues: once performance is where it needs to be, it’s easy for management to look at cutting back on learning, staff or resources because they don’t understand the ramifications of doing so further down the line. Waiting for them in the future: another bout of working harder.
Anyway, here are some ideas of how I expect to make the software a success moving forward:
The software must be front loaded with as much of the project information as possible (or at least requested) prior to a boot stepping foot on the ground. Organised before the project begins so it can be managed, not collected by the site teams.
I’m part way through creating a management system that has work instructions, SOPs and assigned roles and responsibilities for each tool. The management system also has a register with all documents listed, links to training materials split by tool and direct support to Procore where needed.
Changes to the documentation are version controlled and will be re-issued per change, with a description (and where possible) demonstration of the change.
A link to the management system will sit front and centre of all project dashboards moving forward.
The first companywide meeting has already taken place where everybody had the opportunity to discuss what’s working, what isn’t and where they think improvements could be made. Moving forward these will be conducted quarterly.
All existing, and new staff will undertake mandatory training and select webinars to create continuity of shared knowledge.
Staff will be encouraged to experiment using the software and opt to join beta programmes offered by Procore.
Enquiries are now being sent through the software to ensure the whole lifecycle of a project is captured in one place, reducing the risk of double entry in the old system.
All of our supply chain is to be issued with invitations to the software, including instructions on how to use the software and links to training materials or support.
Likewise upstream to our clients.
Reports will be generated from the data collected across the software—such as time taken to close out requests for information, quotations and quality issues—to see what processes are working and which are not.
I wanted to demonstrate the difficulties organisations and individuals face in process improvement by showing you the feedback loops that drive it, by not only adding commentary to the original article—but where I personally have failed at process improvement. Yet again, our biases blind us from identifying whether it’s a systems problem, a me problem or a them problem. Organisations that are not only able to successfully identify the root cause—but have the capability to improve capacity—are what create great long lasting companies. I have some work to do.
The next article will close out Hamilton Helmer’s 7 Powers, and yep, you guessed it: it’s looking through the lens of companies who are renowned for their process improvement capabilities.
Until next time,
Karl.
I’d love to hear about YOUR attempts at process improvement. If you’re up for a discussion, head into the chat.
Sources:
