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.
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.