91–100 of 200 posts
There's a dimension left out here on the Phoenix disaster: It wasn't really IBM's fault at all. 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 Ph…
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.
There's a dimension left out here on the Phoenix disaster: It wasn't really IBM's fault at all. 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 Ph…
> 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 impo…
Earlier quoted context omitted.
Yup, this kind of contracts game is what really needs modern innovation. I think the space is kind of living in an extensions of 70's assumptions with many decades of beauracratic rules added on to try to fix up fundamental problem. For another factor, it would be lower risk to allocate into many smaller projects and sign contracts in phases and sub-systems - but then the funding of the total project becomes more at…
They are barely able to state the outcome of project so expecting them to do the necessary legwork to break projects into logical subprojects is too much to ask. 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.
Historically Slovakia gets lumped with Eastern Europe in popular perception - Slovakia is nothing like Romania, the Ukraine, Albania or even Poland in turning out petty criminals or promiscuous online fraudsters. Not to forget Western Europe, France has a far more unhealthy work culture and fraud at work and as a way of living is far more acceptable than in Slovakia. Germany and Austria tend to value probity far more…
Does anyone else remember the days when "No one ever got fired for buying IBM" was true? You might pay a little extra, but it was never a total fail to use IBM products. I'm not sure when that changed, but I feel like these days, IBM is closer to Oracle than AWS.
Clearly too many people remember. Shows the power of branding. IBM has largely moved out of the consumer space, and occasionally their research labs come out with some cool new tech (Watson and such). In the common consciousness they were the Apple of their day who then ascended out of the market to bigger, cooler things. As a result most people, including non-technical business execs who make purchasing decisions, d…
There's a dimension left out here on the Phoenix disaster: It wasn't really IBM's fault at all. 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 Ph…
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.
Earlier quoted context omitted.
At some level, isn't IBM supposed to point out that training and transition are important for a large project and shouldn't be left out?
They most likely did raise this, but when asked to provide a more "competitive" bid, they axed training and who knows what else. This is common in large enterprise sales deals. For professional services deployment engagements, there is always the possibility of an amendment to the services scope (often referred to as a change order or change request). If the project is estimated to take over a year to deploy, by then…
Earlier quoted context omitted.
> 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 impo…
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.