Have you ever wondered why there are so many instances of poorly designed processes? We certainly have. Processes that seem overly complicated, cover too many special cases, exemptions and god knows what in their desire to be all encompassing and be all things to all people. Or processes that are so customer unfriendly that it makes you wonder how they ever saw the light of day. But why?

The first hypothesis might be that the people designing and implementing the processes are all incompetent, but we have never seen evidence for that. It’s more the opposite – they tend to be too competent, which enables them to make things complex and still make it work. If you were indeed incompetent, you couldn’t make the complexity work.

So if we entertain the notion that the people who design our business and government processes are mostly highly competent, why are we so often saddled with processes that barely work or drive you insane?

The second hypothesis could be that they don’t care about the end user – they are designing for themselves so to speak. But again we have seen little evidence for that. It does sometimes happen, but it is not the norm. Again, we see more on the opposite end of this scale – they care too much about too many (possible) end users and too many possible use cases.

So the third hypothesis should be that process design and implementation is often done by committee and by people who feel that they are not in the position to have tough conversations – either through lack of mandate, lack of authority or lack of ability to stand up to entrenched interests or groups wielding significant power. This is much more in tune with our experience over the last 15 years of working with businesses and public sector organisations.

The starting point is usually that the objective and ‘terms of reference’ (priorities, constraints, decision authority, budget etc.) are ill defined, contradictory or completely vague. Without such clear objectives and term of reference it is impossible to make difficult decisions without upsetting individuals or groups involved in the design and implementation process.

More often than not this vagueness in the objectives and terms is there for a good reason – it was the only way to get the project going in the first place. By ignoring the hard decisions sufficient support could be garnered and the project passed some first hurdle to getting established.

After getting the project off the ground should come the piece that’s often missing – negotiating the terms and parameters of the project. It is really at this stage that all the hard work needs to be done. This often happens for projects where the objective is quite clear and well-understood, but tends to be postponed until ‘later’ for anything where there is disagreement, competing objectives, impossible constraints, insufficient funds/resources, power plays etc. In short, for anything that really needs to go through this phase to have any chance of success.

I still remember quite vividly when I was put in charge of my first large product development project nearly 20 years ago. The objective was to produce a better calculator for teaching math in school. The terms were quite clear – make it tactile (large touch screen), intuitive (formula editor, computer algebra, constraint based geometry) and hit the price point of the competition (existing graphic calculators – USD $99). Sounds great – everything is crystal clear, right? But impossible in 1998, the hardware bill of materials was in excess of $110 and could not be reduced without violating the other objectives. I wouldn’t let the project proceed past the initial proof of concept until these contradictions were resolved. That took 12 months and the resignation of the Sales & Marketing Manager to finally get it over the hurdle. In the end the $99 price point was dropped and changed to $199.

At the time I considered it normal to stop the project from going any further against the wishes of the head of product development. I have since seen plenty of examples where taking such a stance would not have been possible and where the individuals or teams responsible are put under enormous pressure to proceed with unclear terms, unresolved major issues, contradictory objectives etc.

The result is always the same – the project either fails or morphs into something complex and often unfit for purpose because what matters are the power relationships of the stakeholders and not what the end users want or need. Germans have a catchy name for such a contraption – eierlegende Wollmilchsau (egg laying wool milk sow).

So I would venture the main reason that we end up with overly complex processes or products is because it is become too cheap to implement complexity. Especially if the products or process are largely embedded in software. Negotiating contradictory or competing objectives or terms is hard and can get very unpleasant. It requires significant personal investment, causes emotional strain and can easily result in undesirable career outcomes if you misread the situation or power constellation. So it shouldn’t come as a surprise that often plan B – give everyone what they want – quickly becomes plan A. This works even better if you are not affected by the end product.

If this all sounds like people going down the path of least resistance, you have read it right. It’s just that in recent times the nature of what constitutes ‘least resistance’ has changed. Today anything that can be done in software is usually ‘least resistance’ – the underlying complexity is largely hidden from view and only in extreme circumstances do software projects get too big to make failure highly likely.

Consider two simple examples to illustrate the point. You are planning to build a house. Your budget does not allow for all the features you both want – so you either find a way to resolve what gets build, you borrow more money or you don’t build the house. In all likelihood having and settling the ‘what gets build’ argument is the path of least resistance.

Now consider updating the new client acquisition process on your company website. Sales wants it one way, marketing a different way and the MD has seen something he liked on a business trip somewhere. Will you have the argument or simply implement all the features (and confuse the hell out of the poor users visiting your website)? In most organisations doing the latter will be the path of least resistance.

And so we end up with poor processes or products. Because it’s simply too cheap to do (and it’s not your money anyway) and it absolves us from having tough conversations and dealing with the inevitable fallout of upsetting entrenched interests.

On the flipside this implies that if you do have the arguments and insist on the best possible outcome for just the target group of your process or product, you are probably onto a winner. Just look at the early iPod and iPhone products (before they were fashionable) – design, user interface and ecosystem worked together to reduce complexity and make it appealing to a certain audience; allowing Apple to charge a premium price.