These large government software projects end up costing way more than they should pretty much every time. The process is just broken. There's way too much design by committee and tying the hands of the people who are doing the actual work, preventing them from implementing the correct solution and instead making them implement the one the disconnected-from-reality specification writers decided on.
Then they have to go back an iterate the correct solution, which involves more committee meetings at huge expense and rewriting documents and disseminating them to everybody...
The CA government engaged the vendor, IBM, after they had decided on a list of requirements from what they wanted from a solution. In your argument you say that the hands of the people doing the actual work were tied. Well that's the vendor, and so no, their hands weren't tied.
And not sure if you've ever worked at a project like this but the committee meetings aren't expensive. They are basically free. And there often should be far more of them. The real cost comes from major changes in the design too late in the project plan.
Committee meeting take the time of multiple people. They are absolutely not free. People's time is by far the biggest expense in a development project like this.
In the long run they can save money (getting everybody on the same page to avoid conflicts in the future), but you're paying up front for that. In practice the value of the meetings decreases with frequency (in the reducto ad absurdum case 100% of your time is spent in committee meetings and nothing gets done).
Only engaging with the vendor after the requirements were drawn up is what I'm talking about. They contract with IBM and hand over a 2,000 page document describing their requirements, then discover that it's impossible to implement and end up spending many years and millions of dollars on trying to fix it.
> but the committee meetings aren't expensive. They are basically free. And there often should be far more of them. The real cost comes from major changes in the design too late in the project plan.
> The term was coined as a metaphor to illuminate Parkinson’s Law of Triviality. Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively. It was popularized in the Berkeley Software Distribution community by Poul-Henning Kamp[1] and has spread from there to the software industry at large.
Often multiple smaller/medium-sized systems are better for the particular task than one large. Even more so for taxation and payroll systems where taxation/regulation varies greatly.
IBM can claim that they have indeed delivered the thing that was ordered, while CA remain disappointed that the effect they had in mind is missing.
In Canada's defense though, it's sometimes hard to find someone who will even take on contracts of this magnitude. Getting good terms, even more so.