One of my firmest beliefs is that when we try new things, particularly when introducing new procedures, we should keep things as simple as possible. The ITIL 4 guiding principles back me up on this; “Keep it simple and practical”.

But why?

To help answer that question, let’s contrast simplicity and complexity.

In general, simplicity is cheap. It requires less time, and less effort. Simple solutions can be expressed quickly. Simple instructions can be followed easily, maybe even memorised. Even data entry takes less time, the simpler the data. Simplicity has limits, though.

Complicated solutions have one special area of advantage: potential. They can be specific, multifaceted, or detailed. Complex solutions can be fully and technically accurate; the real world is inherently complex.

But while complexity grants us potential, that potential is not always realised – particularly at the start of a journey. Meanwhile, increased complexity comes with increased costs, and diminishing returns; we can do too much to get too little.

If it sounds like an ideal solution would be a balance between simple and complex, you’d be right. Or, put another way, the ideal situation is to work at the right level of complexity for the organisation.

But here’s the real trick: nobody can just intuit the right level. You need to find it. Any position that can be paraphrased as “start with the right answer” is going to run into problems in the real world.

This is where another ITIL guiding principle comes in: “Start from where you are”.

We do not operate in ideal conditions. We can neither engineer ideal conditions, nor ignore the reality that life is sometimes very far from ideal. But my argument is that in lieu of starting with the perfect solution, we should start with an imperfect, simple solution.

And the reason is that not only is simplicity cheap, but that fixing simplicity tends to be cheaper as well. A very simple model will almost certainly require refinement, but you’re generally on the less costly side of iterating refinements with simplicity.

It’s also easier to understand what refinements might be helpful, when there are fewer factors in the mix. If you start with too much complexity, you can box yourself in, and it can be much harder to bring things back.  Simplicity also helps to keep people engaged – being told that a change is a good idea is less compelling than being able to see it for yourself, in plain terms.

Finally, maturity tends to feed maturity. Some of the ways in which it can be valuable to interconnect processes don’t really make sense until you start to understand the value that you’re getting from those processes individually. That comes with time, and experience.

Keeping things simple helps to us keep on track. And, as I often say, we can always make things complicated later.

Simplicity Itself / ITIL Tattle by blogadmin is licensed under a Creative Commons Attribution CC BY 3.0