Working with Iterative Improvements
In a lot of change work organizations 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 organization 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 organization 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 modularization 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 visualize 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.
The way of attacking IT-projects have proven extremely efficient with excellent results. In fact some implementations have ended up with the organization keeping the manual work since it gives better control over parts of the decision making that is not suitable for computers to do. The reasoning is valid for any project where organizations tend to make big projects that should be performed towards a theoretical specification.