To put this in some perspective, they're mostly doing it because the Brits did it first.

Still, having any recognition and awareness that there is a problem there is heartening. We're just getting started here; last I heard, the good old habits were still in force, i.e. of starting software efforts with price tags expressed in hundred million euro multiples, letting them run for a while, then scrapping them as not even worth deploying.

Procurement is one of the big culprits here; a classic case of lost purposes. Ostensibly to save money, departments give a lot of power to policy-making bodies who then dictate a risk-averse process that departments must follow before they can spend their own money. This means that contracts now mainly go to contracting firms who positively relish dealing with red tape, but are less competent at actually shipping code.

Typically this leads to disasters, see above, which result in tightening financial controls, giving even more power to purchasing organizations, the almighty tail wagging all the dogs. The departments' own IT people, in this setup, end up doing nothing much beyond filling out paperwork, while all actual competencies such as writing the software are "externalized" to contractors.

So the job description is basically to cure government of this addiction. I've been given control over a budget of a couple million euros to start with, and instructions to split it over about 10 worthwhile projects this year. Each project should have a 6-month roadmap, with a first go/no-go milestone at two weeks in (and an obligation to report in with something they've learned by getting out of the building and talking to end users). At least half of the development crew (4 to 6 people) should be in-house to the departments, not contractors. That should leave much less room to hide incompetence, but we'll also provide a bit of mentoring to make sure these teams know a minimum of good engineering practice.