Last Friday, De Volkskrant exposed how much trouble the Dutch tax office has had in recent years to build software and manage its IT projects. Below I’ve listed the four main things they lack according to the article.

The responsible State Secretary, Eric Wiebes, admitted publicly that IT is “the tax office’s Achilles’ heel”. The report goes into the tax office’s 600 plus (!) IT systems and the estimated 750 million euros of tax that isn’t collected due to outdated technology. That is just sad!

They based some of the story on internal review documents, and interviewed a contractor, who gave details of a number of things many developers will recognise as serious red flags.

So, what did they lack, what should they have done differently? I thought I’d summarise some findings on this blog. Note that these might come across as common sense if you work for a fairly modern digital company.

The article in De Volkskrant, 18 August 2017

Take small steps

Some managers at the Tax Office preferred a rather traditional way of working: to build a fully featured product at once. All or nothing.

The alternative to this approach is to build a simple, minimum viable product first and then extend that with relatively small features when and if they are needed. It is the de facto standard for software development and what all modern, successful companies do in some way or another.

There is a difference in the two approaches from a management point of view: the modern approach requires active involvement, decision making and taking responsibility. When new stuff is added feature by feature, someone, whether it be a project manager or product owner, needs to know what the features are and take bold decisions about priorities. It also takes honesty and putting yourself in a vulnerable position: you’re sharing your work more often and give people the chance to comment. For the greater good!

Distribute responsibilities

The article also gives details of how management repeatedly made uninformed decisions. Tax Office managers ‘made decisions about IT without any technical insight’, which lead to non-vulnerable systems being replaced unnecessarily, and critically vulnerable systems being left without a replacement. ‘Often, the directors didn’t know for which part of the new technology they were responsible’, an external auditor said. Another issue is that no one seemed to know what systems were for and how they were supposed to save money.

In big IT projects, I think it is not inherently bad if management is not aware of all the technicalities involved. This stuff can easily get complex. It’s not uncommon in technical meetings that a majority of the room does not understand what is being discussed (sadly, this really happens). Because of that, people can say nothing and make it sound like something. Given all that, management, if not technically inclined themselves, should have themselves informed by other people who understand the full, technical picture.

Test early, test often

Software wasn’t regularly tested with reality (as in: the IT reality wasn’t checked with the real world reality). There was hardly any contact between the developers and the case workers that were the intended audience for the software. Nobody kept an eye on whether the systems being built did what they thought they would do.

As an organisation that produces software, if you don’t regularly test your stuff for bugs, with users, for accessibility, for security or with reality… you are just being overly confident — delusional, perhaps. Pride goes before destruction, and haughtiness before a fall. Software needs to be tested, and this needs to be done as early and often as possible. This is to verify that stuff does what it should do, and also that stuff still does what it used to do.

Work together

Another thing the article goes into is that the more traditional members of the team were less prone to come into work, they worked from home most days, some came in only once every fortnight, for meetings. From an employee point of view, this might sound like a fantastic benefits package. But to be fair, if it leads to bad software that you are partly responsible for, I’m not so sure I would go for it.

Communication (with team members, with management, with clients) is arguably the most important skill in modern software development. This is not impossible when working from home, with the right A/V and good internet speed you can do your dailies from a distance. However, especially in large and complex organisations, it is essential to be on site regularly, to make it easy to verify assumptions.

Conclusion

The above principles are extremely common in almost all modern and mature digital organisations. Companies like Amazon, Google and my bank seem to effortlessly produce interfaces that are easy to use, have few bugs and are able to disrupt people’s lives in a way that is often so positive. I think aspects like taking small steps, distributing responsibilities, testing early and working together help these companies to have success.

The Dutch Tax Office has a long way to go, but I am really hoping it will manage to shift into this direction, too. In the meantime, I try to be vigilant of the above symptoms when they occur at the projects I work on. I am also curious to hear if you have worked in any organisations that had problems like these, and if so, how you tried to solve them.

---

Originally posted as Small steps on Hidde's blog.

Reply via email