Hacker News new | ask | show | jobs
by danmaz74 3025 days ago
> There's a dimension left out here on the Phoenix disaster: It wasn't really IBM's fault at all.

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.

4 comments

Payroll projects are always disasters.

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.

> 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.

I've written RFP responses in the telecom industry. "Excruciating" is about right. Thing is, if you are not highly detailed you'll fall between the stools of waterfall and agile. It sounds like this project went astray that way. Not sufficiently spec'ed, everybody gets everything they want, and not agile. You cannot make a sensible kanban board out of change orders.
That is the face of the problem.

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).

Not to mention government procurement processes do everything in their power to make it difficult to write a good RFP and the major players are highly skilled at responding to RFPs for the purpose of winning the bid, not necessarily to deliver on the RFP's requirements.
I've worked in government and commercial sectors. Big procurement organizations are a pain in any situation. Government adds some wackiness because of transparency and personal liability that procurement officers are living with.

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!)

I've seen multiple government projects where the RFP's were actually written by the company eventually winning the bid - what a surprise...
you're both right, but you're a bit more right. IBM should have been pointing out that losing the institutional knowledge may cause problems. they possibly assumed some of their milestones and deliverables would be while working with existing staff. if the existing staff is let go, many of the assumptions in the original estimate are just wrong at that point.
The managers needed IBM to tell them about the concept of institutional knowledge? They need to be told that people with experience have learned their jobs? That new employees need training? This is like Management 101. Just how incompetent are these managers?
So incompetent they hired someone else to write software only they could possibly know how to write.

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.

Haven't read the docs, so I don't know what the contracts and proposals states, but regardless of how obvious some things are, putting that in writing is a bit of a CYA.

"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."

The competent managers likely had no say in the matter.
That's a trick question, there are no competent managers in government service for the most part. They either burn out from managing without the ability to recruit competent staff, or they moved elsewhere to make drastically more money.

I'm sitting with a 4x multiple on my old public service job.

They're the ones spending the money. It's not "oh, we're getting paid? Caveat emptor." Everyone involved has a social responsibility, but the ones who are getting paid to be there have more responsibility.
Yeah, with that price tag IBM could have rolled out multiple federated payroll systems and then iterated on the theme until they had a unified system, but they would not have been able to farm out the development to off-site contractors.
Exactly. Based on IBM's track record around the world (I know of IBM payroll projects for Canada, Australia, Pennsylvania which have failed while New Zealand and Slovenia have been mentioned in comments), I'd say failing on low ball government payroll projects and then taking the government to the cleaners is strategic at IBM.

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.

IMHO most of the times such concerns are completely ignored by management.

Customer even gets angry and asking for removal of such risks. Vendors comply by sneeking it in the contract in clever words.

I've seen that pattern several times, often enough that it's a bit of a red flag as it seems management know their own weakness but don't want to be exposed to it.
Yeah, some of these comments here seem very naive.