I respectfully disagree. IBM management either knew what they were contracting was a recipe for disaster, or they were incompetent. In both cases, as they were supposed to be the billion-dollar expert on the matter, they bear great responsibility for this failure.
And at an industry level, companies that promise the impossible push out of the market more honest ones, and they deserve all the bad PR IBM is getting on this one.
Any vendor will do exactly what is asked, no matter what. IBM, Dell, Accenture, Deloitte, McKinsey, etc. There is no reason why a customer should allow a contractor like this to run roughshod over them -- thats incompetence and bad governance.
I've run big projects with vendors like this. You write good RFPs and hold feet to the fire and they will deliver.
That's the key bit though. Its not easy to write good RFPs. Unless done to an excruciating level of precision (which they very seldom are), you leave wiggle room which the vendor will naturally take advantage of when things get tough.
In the construction business, there’s no need to state that nails get hammered or screws turned, unless there is a very specific application. But they tend to structure projects in a way where there is an incentive for success and punishment for failure. That's not to say that it's perfect, but there are far more $10M+ failed IT projects than failed construction projects.
If you work in this industry, you've seen your share of IT vendors delivering barely literate offshore workers through 2-5 layers of contracting pimps. That simply doesn't happen with pipefitters and others.
In IT, the tenure of the CIO other senior leadership is often is lower than the vendor and the project. The incentive for the CIO is to listen to <insert vendor here> because they may communicate what is happening better AND they may want a job with the vendor later. Without the threat of reprisal, many organizations will make poor decisions (both vendor and customer).
But end of the day, if the people writing technical requirements have the time and know WTF they are talking about, it works. If you hire <vendor a> to write an RFP that <vendor b-y> responds to and <vendor z> evaluates, how could the result not be a shitshow? (Btw, that happened in a Fortune 500 org!)
There is a degree of management bankruptcy implicit in a large proportion of outsourcing projects. Hiring a vendor to handle billing for your public records dept makes sense, because you can’t afford to maintain a stable of experts on billing.
But a lot of the skill brought in by good contracing firms is in extracting and negotiating requirements. Because your management team has no idea how the work actually gets done.
Think about that. It is cheaper to have some other company come in and learn your problem domain than it is for your company to write down clearly what it is they do and figure out a set of steps to attract employees to do the work for them.
Personally, I think that has Management 101 written all over it in large block letters.
"We're estimating based on having access and participation from your senior/experiences payroll employees. Substantial changes in personnel will impact the viability of the project."
I'm sitting with a 4x multiple on my old public service job.
IBM have made billions doing so. Bad publicity is just a good start.
The really interesting point is that if this business plan is shown to be strategic (if I were Canada, Australia or Pennsylvania I'd be looking at full discovery of all email records), IBM would then be vulnerable to civil suit for fraud.
Customer even gets angry and asking for removal of such risks. Vendors comply by sneeking it in the contract in clever words.
In the end project is either canceled or goes over budged or barely manage to deliver anything.
No disrespect but we have come to a point where IT have started appearing magical to pointy hairy bosses who think juse because it's software everything is infinitely malleable with no impact on quality, cost, or time.
It's all about managing the personal bonus and career, who cares for the success 9f project?
Those companies did continue to do business with us though and we've normally earned back our losses and more on future projects.
That's what honest vendors do. That's not what IBM did.
The software developed by IBM was so complex, that it required the expertise of the people who got laid off to operate it. The novices who took over didn't know how to make the software work, and chaos ensued.
The Canadian government is as much at fault as the developers on this one. (I speak as one who is paying for this fiasco :o).
The first $200 million of cost overruns I'm willing to pin on the Government of Canada. The subsequent billion dollars and the failure of the system to work at all is the vendor's fault.
If the Government of Canada is entirely impossible to work with, the vendor should have shut the project down at 200% of budget rather than run it to six times budget and still fail.
It's obvious that there was zero actual knowledge involved related to implementing large systems - just by the fact that someone thought it was a good idea to take a behemoth system excreted out of Oracle, and then pass it through the corporate body of IBM, before inserting it into a huge government organisation, while at the same time getting rid of any process expertise and business knowledge they might actually have on-board.
However - I don't think it's probable that any amount of training could save the situation to any measurable degree whatsoever.
Is IBM to blame? Well, I think they knew what would happen.
If the project is estimated to take over a year to deploy, by then you're in a new budget cycle and the vendor has come to an agreement with the procurement department to charge for additional services as required in subsequent phases.
So biding yourself into a project to low gives you enough leverage when the point of no return is reached to still make a big plus.
my earlier post: https://news.ycombinator.com/item?id=16495431
basically, it's a political game... the same jobs they "lost" in miramichi because of the firearms registry legal change, they tried to get back. Same pork barrel politics that congressmen in the US play with trying to bring jobs to rural districts.
The Canadian public service is really complex. There are multiple unions with multiple overlapping collective bargaining agreements, where the public service is allocated to different classes. These classes are paid specific rates, with retroactive pay being common for changing classes. The majority of the problems with Phoenix have been employees moving from their classes and being paid the correct amount. It has also adversely affected non-unionized positions.
My understanding is that the Harper government (Prime Minister until 2015), who was responsible for the negotiation and for laying out the requirements, was trying to save a money and not responibly create a pay system. Two major factors that jump out at me:
1) Requirements did not call for training. The system was implemented and IBM was not required to train any operators on how the system functions, which is important because all new staff were hired to run the system and,
2) Due to the need for cost saving measures (the government was trying really hard to balance the budget, as the election was coming up), the previous payroll staff were terminated and a new payroll centre was opened in Miramichi, which is a small town in the middle of nowhere.
So, on top of new software, the government lost all of its institutional knowledge regarding payroll and how things are supposed to work. It's actually hard to say how much of this is IBM's fault and how much is the governments, because the government doesn't know how to fix it. No one knows how Phoenix works and no one knows how it is supposed to work. It's just a big mess with no end in sight.
Could IBM have done a better job? Probably, but garbage in, garbage out.
For further reading, the Auditor-General's report: http://www.oag-bvg.gc.ca/internet/English/parl_oag_201711_01...