Working with Iterative Improvements

In a lot of change work organisations aim for perfection. In sayings like operational excellence it is integral that perfection is the aim. The problem with that way of thinking is that nothing ever gets perfect. This also ruins a lot of good efforts when trying to make changes in a company.

“Have no fear of perfection, you’ll never reach it.”

– Salvador Dali

One good example are IT-projects. Most companies both need to do them and have done them. There is both an experience that they cost a lot of money and often fail. There are some reasons that can be examined in the perspective of the problem solving eyes. As an organisation wish to start an IT-project the first thing is to make a specification of what needs to be done, what the project should aim for, what the result should be. This is actually where all the problems begin! Why? Because as the organisation starts to do the IT-project there are some basic misunderstandings. Firstly there is a belief that as you change the system it is best to start from the beginning with a blank sheet of paper. The problem with that is that the project becomes way too big and too complex to handle. Secondly there is a belief that someone knows how the system works today or that it doesn’t really matter to understand how the system works today since it will change anyway. To understand how a system is currently working and why is the basis not to introduce things that are wrong in the future. Finally there is a belief that a group of stakeholders can explain what they want from a theoretical reasoning and that they can explain that in a specification. Since the need keeps changing and it is very hard to understand what to ask for as a non-expert in IT the task to make a specification is impossible.

The solution is to use some of the concepts explained earlier. With the idea of modularisation the functions of a complex structure are separated into components. With a modular product, process or service a component can be changed or improved as long as the interface towards other components is not changed. With the same thinking a part of an IT-system that performs a certain function can be isolated with well-defined interfaces to the rest of the system. As this is done the isolated component can be investigated. When it comes to an IT-system a good thing is trying to visualise the data handled on some sort of card and then explaining the logic how the IT-system works. Allowing stakeholders and managers to interact with actual data with the logic of the IT-system allows everyone to understand how the system work today. With the same cards stakeholders can elaborate with new ways of working and new logic. In this way the specification is built through problem solving rather than theoretical reasoning.