On thinking big and acting small

Computable Magazine the Netherlands, Govern IT by Hans van Bommel

We like to think big. Particularly when we want to build something and the drawing board is patient, seemingly impossible castles in the air actually make it to the execution phase. This happens especially to people who are highly ambitious but somewhat lacking in experience in change management. Sometimes that can be an advantage, for example in the case of the Dutch government when they decided, just after the flood disaster in 1953, to protect the vulnerable lowlands with the Delta Plan. But there are times when thinking big is dubitable. Like when the city of Amsterdam decided to build a new subway line under the swampy Dutch soil, all based on an inadequate outline of the costs. For the next 20 years they were faced with a long, major headache involving the collapse of 17-century dwellings. Fortunately the subway project actually got there in the end, unlike a similar project in Liège. A half-finished network has been hidden in the ground there for 50 years.

???????????? In IT we also like to think big. A lot of people approach IT systems like big buildings that need big solutions for constructing or replacing them. Which has caused a few, well, fiascos in the first decades of this century. It has cost us a shipload of money. Existing business processes needed to be captured in systems, often on a grand scale. Most comparisons between building IT and constructing physical buildings or infrastructure soon collapse for a number of reasons, but when you look at that kind of megalomania there are some serious parallels. Happily this trend seems on its last legs because thinking in big systems is no longer the fashion. Things have to change after 20 years of running headlong into walls time and again.

???????????? Very simply put: the problem was really that we thought we could improve our IT by replacing one system with another. It always involved migrating from system X to system Y. The old system would slowly become obsolete, and once it really had to go, a new system would be designed on paper by some IT architects.? IT people would write code, or we’d buy a standard package if we suspected it might fit. Next, a big bang moment would be chosen for the big switch-over. We replaced systems with other systems that supported more or less the same process, in fact pretty much the way we designed the early IT systems aimed at digitising the then known processes. (Incidentally: we called that 'innovation’, but in fact that was nonsense, because nothing changed in the business, did it?)

???????????? Invariably, things would go wrong during these migrations. Why? Because they were always in an environment with lots of factors and actors that all have connections with each other. When you switch from one system to another, you'll be faced with so-called high dependencies. The system you're trying to replace 'lives' in a context that you need to deal with.

???????????? Compare it to the Delta Works again. When you decide that the current works are no longer sufficient because (for example) sea levels are rising, you build up your dikes step by step, right? You wouldn't design a completely new system that takes over the whole job of the old Delta Works, would you? Because then you can be sure all the lowlands behind it will flood.

???????????? It's always a tough decision for any organisation: when is change necessary? Fortunately we see a development there too. In terms of IT, many businesses and organisations were well ahead of society. In recent years that role has been reversed. Society, in which we as citizens use more and more IT support in everything we do, has become directive for the enterprises. Change is a constant there, and it's needs-triggered by the people. This is what is now happening more and more within organisations. What do we support exactly, and with which IT support? The demand for new IT is not born from a technological approach in which the old way of thinking pushes you to a new system, but it's born from product innovation. And that comes from the business itself. As long as the old systems can deliver the support for the desired business innovation, you focus on optimising the system. If necessary you can work with a new technological basis for just this specific innovation.

???????????? In reality it is the enterprise itself that needs to transform to keep up with digitisation, and in many more fields than just IT, technology or infrastructure. Digital transformation is really not about applying AI, adding blockchain to the landscape, or processing payments without an intermediary. It's much more in the people themselves and in the organisation; in the demand from the business; in thinking big but acting small. In that respect, managers and directors only need to look around a little better. The digitally transforming citizen is a good case study.