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.
Which is why most governments struggle with big IT projects.
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.
I was in a pub with a relative, and we got chatting to another random patron.
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”.
> 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.
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.
Take a triple bottom line solution to the problem.
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.
Right. But the client should never come up with the detailed spec. If they know what needs to be done it'd literally be faster for them to code it themselves.
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.
Yes, but your way would likely strip a friendly consultancy off a contract for a couple million of your favorite currency to produce said specifications.
> 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.
> 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.
They have the budget for it, that's sure. But more often than not the municipal workforce is heavily unionized and has paygrades that are below market rates.
> They have the budget for it, that's sure. But more often than not the municipal workforce is heavily unionized and has paygrades that are below market rates.
That (the below market rates) is part of the setup to promote outsourcing. A heavily unionized workforce doesn't make it harder to for an organization to increase tech role pay to market rates if it wants to, it makes it fight harder to avoid to doing so.
That would be even worse! Can you imagine the headlines where it's a private company that tells the government what they need to buy AND sells it? Horrible conflict of interest.
The best solution would be for government IT to simply be competitive with the private sector for talent acquisition. That would probably mean that most senior software engineers will end-up being above the mayor's paygrade however.
Can you imagine the scandal if you fully specified a product and they built it and it wasn't even fit for task. Your contractor says "They never said it had to fly, they just sent us 5999 pages of specs about the logo, the color of the seat, the tray-table latch mechanism, etc." You'd look even dumber because you proved you don't understand your own business.
No organization should expand outside its desired core competency. Specialization is for organizations. If you want competency you hire it as a consultant. If you need to check that consultant, hire another.
Hire one company to write the spec and the product. Hire two others, small firms, one in the problem space (tax, airlines, etc) to check the business requirements and one in the software space to make sure spec/dev/test processes are adequate.
> Can you imagine the headlines
Yes, 100% lies written by a bitter communist. Modern corporate media in a nutshell. But the government already took the brunt of that for screwing up earlier. The screwup you mention would be no worse. Partly because the news is hyperbolic and nobody believes it these days - every problem reported is the worst ever.
> Hire one company to write the spec and the product. Hire two others, small firms, one in the problem space (tax, airlines, etc) to check the business requirements and one in the software space to make sure spec/dev/test processes are adequate.
Your projects will never succeed this way, but you’ll have plenty of people to blame for the failures.
Which is why it's already common for government IT projects to use a close variant of this approach, but usually separating out requirement writing to a firm notionally expert at doing that in the problem space instead of having it checked by sich a firm.
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.