From the article:
The second thing is that government is the archetypal simple shopper. "We'd like a computer system please but we don't really know quite what one we'd like": face it, salesmen dream of moments like this.
As everyone who has ever run a successful project knows, the first thing to do is to get the specifications right. Only once you've have, written in stone, what the system is going to do and how it is going to do it, can you possibly start to bring in anyone to start building it for you.
That is unfair - to say that government doesn't *know* what it wants isn't necessarily true in many cases. Those in government departments might know *exactly* what they want but the procurement rules prevent stating too specifically, a mixture of treasury, national and EU rules. Specs must be "only as specific as they need to be" and state the minimum necessary level of capability.
The principle is that the government departments must not get too narrow minded and supposedly thinking too specifically will limit the department from identifying any savings or alternative and novel ways of acheiving an objective (or solving a problem) *. However, it could often be argued that this would mean that specs are left too vague for the system/solution to be implemented properly. This isn't limited to software projects but software seems to be less easy to contain within open requirements than other areas of procurement.
But to say this is ignorance from the department rather than, say, accountants making rules in areas for which they do not have expertise, is unfair IMHO.
* - For more info, have a read of 'Investment Appraisal'.