Isn't this basically a given? I find it hard to imagine that any organization could come up with good, complete requirements before they've had any software written.
Governments by their nature tend to approach everything from a legal perspective.
This then means the requirements of these big IT project end up being a mass of legal documents which try to describe what is being delivered by whom.
Then when the whole thing falls apart it ends up in the courts and the court then decides who promised what based on those original contract documents.
The relative was asked about his CS job, and at some point details were being discussed. The relative said something like “we have made what was asked for but because we have run out of time, that’s what the customer is getting. We know what they actually want and need, but that’s not in the contract”.
The person we were talking to was the customer.
Something government contractors learn to be good at is following a spec. These lawsuits often end-up costing the taxpayer a fortune for the government to be told that everything was delivered according to their spec.
The consulting company will then recoup it's losses from the lawsuit using their hourly billing clause where it stipulates that they can modify the software for X$/hour.
It’s also why Gene Kim & co wrote “The Phoenix Project” [1].
Everyone involved in software-building, non-tech industry should read it.
In the end it’s just lean turned agile software dev. Reduce waste.
[1] https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
Take a look at how kmalloc_obj is going in DragonFly BSD.
Government IT challenges three technical team leads to get to solution like kmalloc_obj. Performance pays for 1st prize and the rest get less money. Cut the time horizon from start to finish for the piece work to 18-months. Spread the risk of total failure to zero.
They should never produce more than a page or two of specs, outside of the central task itself, because most everything will change when under production anyways. A project like this is big enough that apps became a thing, and fundamentally changed twice, in the lead-up to the actual work.
And all the little things they could control are just bikeshedding, best done by an impartial designer or by A/B tests.
They would need to hire software engineers and, quite frankly, most municipal governments aren't capable of adequately compensating these positions.
Of course they are, because they already are compensating them plus contract management overhead on both sides of the contracting arrangements (which are usually made even greater because they have different contractors for different phases of an effort), plus contractor profits.
Aside from simple corrupt motives (both by responsible managers involved in deals directly and higher-level politicians who favor inefficiency of kicking things off to industry because it buys support from the beneficiaries), this is done because it spreads the blame in the event of failure, which is seen by many involved as more important than maximizing likelihood of success or cost efficiency.
But citizens (well, at least those not corruptly benefitting) shouldn't tolerate that.
