Earlier quoted context omitted.
> 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 funda…
> We're discussing how it failed your way 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 mu…
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.)