A large part of the reason must be found in the rigid way in which requirements specifications are prepared, let us take the public sector in Denmark as an example. Let’s say that company X has won a large and beautiful project to build a new IT system for a public institut. There are just two key challenges:

1) It is extremely difficult to formulate requirements so that the solution ends up creating value for the employees and actually suits their needs

2) In the two years that go by on average from when a tender begins, until the service has been delivered, so much happens in government requirements, technology, workflows and society in general that we will be left with a solution that is already on its way to retirement, and most times even before the IT system is finished. 

There are alternatives. In the requirements specifications, you can make increased demands that the solutions must be flexible and that you can easily iterate on even the most basic functions in the system. And then, of course, one has to weight this requirement highly so that it counts in the decision. In this way, we can ensure that we get an end product that can be adapted to reality, and that we are left with far more timeless solutions that we can further develop. At the same time, it is ensured that the solution can be adapted to the employees’ everyday lives on an ongoing basis – and that the employees themselves can influence how the systems support their work. 

In the optimal world – which hopefully is not too far in the future – the format of the requirements specification itself will be much more flexible than today, so we can build a “model” of the system before we start building the system itself. This is how architects have worked for centuries, and we can learn a part from that. 

We haven’t developed much in the process behind the development of IT for 40 years. Is it not about time?