Is Process Optimisation Killing Your Business? – Part 2

By: Nicholas Hill

CEO

27th May 2020

5 minute read

In Part 1 of this blog I described how, for well-intentioned reasons, the trajectory of the business process is always in the same direction: increasing over time. In this part of the blog, I’ll describe some of the less desirable side effects that this increase in the process can have, how it can have a negative impact on your business, and most importantly, what to do to prevent it.

THE EFFECTS

All of these well-intentioned drivers add positive value to a business because most of the time they are attempting to ensure best practice is followed. However, they also add friction and reduce flexibility, hindering the organisation’s ability to execute projects with short timescales or react swiftly to changes of scope.

A typical tendency of process improvement is to apply it across the board. So if a process is introduced or changed as part of a remedial action that came out of one project, it will be applied to all areas under the guise of ‘preventative action’. The improvement that was relevant for one instance in one project is now attempting to fix problems that may not have existed in other projects but just adds friction to the process. In effect, the height of the quality ‘bar’ is pushed up to that which the most demanding project demands. But now all projects have to get over that bar, whether it is appropriate or not.

If you are writing software for critical applications, such as aerospace or medical device, you rightly need a consistent and rigorous approach, accurate specification, careful execution, painstaking verification and lots of checks and balances. So your organisation builds these features into the quality procedures for writing software. But somewhere else in the business someone is trying to rapidly put together a technology demonstrator for a new product idea. The demonstrator is built around a Raspberry Pi and needs some quickly written code to show how the product might interact with a user. Someone argues that although this demonstrator is only there to show how something might work and not actually deliver a solution, there’s a danger that some of the code might get carried over into a subsequently developed product. So you apply the full-blown software quality process just in case. And you find you can’t possibly get the job done in the timescale available and the cost is out of all proportion to the task.

The similar setting of the quality bar according to the highest need can happen everywhere. For example in the sales process (when the controls appropriate for selling the largest jobs get applied to small ones), or project management (when the process used to start, run and close a project have been scaled to handle the largest, most complex projects and put an unacceptable overhead on smaller projects). This may have been done with the best of intentions, but reflects that fact that it’s much easier to argue for more process than less. The latter is seen as risk-avoiding and so “good”, the latter inviting risk and thus “bad”.

Over time it is easy to get into a situation in which a company is very well set up for executing the largest, most complex, most difficult projects, but has lost the ability to both sell and execute the more pacey, short or risky projects. The organisation has become too slow and too expensive because of the process overhead that has accreted to the business.

In this mode, the organisation is behaving like a railway train, following a carefully controlled path to a pre-defined destination, with specified milestones along the way, and with a large amount of scrutiny, oversight and supervision. So how can we get it to behave like a 4×4 when we need it to, possibly just exploring the landscape, possibly finding the shortest route to the destination, constrained only by the terrain? In disrupted times like we are currently experiencing, these questions become even more pertinent.

THE SOLUTIONS

The first step to avoiding this situation is becoming aware of the problem and realising that action is needed.
A business will typically see an inevitable slow accretion of process over time, so something must be put in place to push back against this tendency. And that takes conscious action. The dialogue must be changed from one of risk-taking versus risk-aversion, which inevitably tends to favour the latter, to around the benefits versus potential costs of any proposed increase in the process. Any business contains a mass of compromises, and finding the right balance is key, but you can’t do that if only one side of the equation is considered.
Many businesses would benefit from the ability to be schizophrenic: sometimes rigorous and risk-averse, sometimes pacey and adventurous. When developing a medical device or aerospace product, design staff need to be able to work in an entirely different mode to when they are brainstorming ideas and putting together experimental models and prototypes. Although process and standards must be applied across the business, a one-size-fits-all template should be avoided. I’ll illustrate this with some examples of how this could be applied in practice.

Process

Overhaul company procedures with the aim of reducing the mandatory process to the minimum. All activities must comply with these, so think very hard about the cost and benefit of each individual requirement before putting it in place. Handle more complex or demanding projects by adding in an additional process that is tailored to that project’s requirements.
Company procedures can end up containing a large amount of excellent advice that has accrued over time. While much of this may be useful it has two detrimental impacts. Firstly it contributes to procedures growing very large and nobody will read long quality documents. Secondly, it may not be clear where the end of the mandatory instructions and the guidance begins. Address this by stripping out all of the guidance and putting it into separate documents that can be referred to when needed.

People

In order to work across the full range of potential projects, we must recognise that different people are more comfortable with different types of project activity. This is nothing to do with their technical specialism: it is about where they sit on an axis that we could call “starter-finisher”. Those at the “starter” end of the scale will be more comfortable with the typical early stages of a project: more experimental, more open-ended, riskier, less well defined. Those at the “finisher” end of the scale will be more comfortable working on the later stages of a typical project: with a clearly specified requirement, with a strong process or framework, with clear boundaries around who is responsible for what and with a desire to push on until every bug is fixed and verification step is complete.

The starters will be great at getting fresh ideas on the table and demonstrating what could be achieved but will get bored long before the product hits the production line. The finishers won’t cope at all well with the somewhat nebulous and ill-defined state of the early project but will make sure we deliver the fully finished article that the customer needs. There’s nothing wrong with this, though both starters and finishers may have difficulty understanding each other!

What is important is that the business recognises these traits and realises that starters work best with minimal process whereas finishers work best where there is a strong process. Accommodating this in a single business is not always easy.

In Part 3 of this blog, I’ll continue to show what you can do to prevent being dragged down by process, to be able to be both rigorous and a fleet of foot, discussing the role of environment, business model and communications.