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.
> Your projects will never succeed this way, but you’ll have plenty of people to blame for the failures.
We're discussing how it failed your way, so I'm not so sure you're presenting a better alternative.
The problem with your method is that two separate companies have deliverables that must be correct, whereas with mine only one does. And my way removes the back-and-forth which is a huge source of errors.
It's fundamentally impossible (absolutely, 100%) to write specs for a complex product before the product work begins.
So you can make it work your way, with a separate firm writing the specs, but you need to couple them with the dev firm and give up on the fantasy of up-front specs.
But that comes with its own problems and increased cost so imho you're better-off just letting one firm do it.
You mean the guaranteed-to-fail-but-spreads-blame method that I mentioned is common and closely related to your proposed method which shares those traits? Because that's neither “my way” nor something I recommend as an alternative.
> The problem with your method is that two separate companies have deliverables that must be correct,
No, only the final delivery company’s one must be correct. The preceding one influences the likelihood of that, of course, just like the extra domain-expert contractor brought in to validate the requirements in your proposal. (Who, if the agency for which work is being done is bringing them is as a requirement “validation” expert because it assessed that it can't do that, is effectively defining the actual requirements, even if nominally they are just validating the other firms work on behalf of the customer.
> It's fundamentally impossible (absolutely, 100%) to write specs for a complex product before the product work begins.
Yes, you seem to understand a key part of the basic problem, but then describe a rearranging-deck-chairs-on-the-Titanic solution that does nothing to address it.
> And my way removes the back-and-forth which is a huge source of errors.
No, it just changed to nominal role (but not really the functional role) of one of the three (customer, requirements crafter/validator, developer) parties to the back and forth.
My way is to recognize that if you are going to build and operate a complex IT-dependent business function, a prerequisite step to success is to own the IT capacity to govern the necessary system components, including their incremental development and adaptation to evolving business needs. And closely related to that is arrange the work into increments that (among other criteria) can be plausibly specced in advance but also where the setback isn't intolerable when an increment’s main output is information about where your understanding going into it was wrong.
> My way is to recognize that if you are going to build and operate a complex IT-dependent business function, a prerequisite step to success is to own the IT capacity
Right, just become an IT organization. That's the simple answer nobody talks about.
This is a non-answer because even most companies that want to can't do this, and as a taxpayer I don't want my government developing IT excellency, I want bureaucrats doing their core task not writing specs. (When they leave the agency they could go to the business process consultancy I mention, where they monitor and advise the developers in tax questions and departmental process issues.)
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.