Think smaller

Over at my other blog, I mentioned the fact that the Danish Tax Department is going to go through a major overhaul (Denmark overhauls its tax department).

One of the major triggers for this overhaul, is the problems that the Tax Department have had with creating new IT systems in recent years. Two major IT systems have failed - one which was going to calculate the taxation value of property, and another which was going to be used to collect overdue taxes and other debt to the state.

The failure of these IT projects have cost billions of dollars in both wasted development costs and in lost revenue to the state of Denmark.

As a frontrunner to the overhaul of the Tax Department, the Ministry of Taxation had already decided to not let the Tax Department do the development of the property system but instead do it themselves. This was a major break away from the traditional roles of the Ministry and the Department, where the Ministry was focused on law-making, while the Department had the responsibility of enforcing the laws (e.g. collect the taxes), and make the systems necessary to do so.

As part of the Ministry of Taxation's decision of taking the responsibility of developing the property evaluation system, they also decided to do it in-house, rather than using public tenders to get it developed.

I was recently at a talk given by Steen Larsen, the head of development at the Ministry of Taxation, called "A New Way of Doing Public IT", where he explained the things they had done to create a succesful project, which would deliver a working system on time.

This was very interesting, though I think the title was overselling it a bit, as there are several public agencies and departments which do much of the same as what he described.

Listening to the talk, and seeing the ideas behind the overhaul of the department, I can't help worry if they have identified the right problem.

It seems to me that they still have a tendency to think in large monolitic systems.

As Steen Larsen described it, the IT system they were building was both a system for evaluating the properties, and for the case workers to do their work.

It seems to me, that it should be possible to split these areas of concern up, so they could be considered two different systems, and making the sizes somewhat more manageable. Generally, this allows for a greater chance of success.

Hopefully, the tendency of thinking in monolitic systems is only when they describe the systems, and not when they do the actual development.