311–320 of 333 posts
Earlier quoted context omitted.
“Our” in this case clearly refers to Canadians, not IBM. Do you know what public sector means?
I read the comment you're replying to more as "IBM shouldn't commit to projects if the client isn't mature enough to make it work."
Earlier quoted context omitted.
> IBM isn't a successful technology company with a proven record building good products. Whoa, what? Sure, some of their achievements are in their past, but that claim really overlooks a ton of history.
Agreed, IBM has a long track record. Their recent history doesn't have a lot of W's though.
Earlier quoted context omitted.
> You could serve 80% of the payroll burden with software that cost $10m. 90% coverage costs $100m. 98% costs $1,000m. And 100% costs $∞ I read something in a trade journal probably probably about 15 years ago, that really stuck with me: When businesses buy big software solutions (I think the article was about ERP systems), they should prepare to adjust and change their processes (within reason, of course) and not ju…
Except that there are often legal reasons for things to be in a weird way. Or it would require a long negociation with trade unions and 3 strikes. I have some sympathy for the complexity large organisations (public or private) have to deal with (even if “keeping it simple” is still too underrated). I have way less sympathy for the ERP software than can only handle one use case and then it takes a bunch of non technic…
Earlier quoted context omitted.
Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company. But after selling the deal, their workers have to solve a difficult engineering and organizational management problem…
I wholly disagree with your criticism of the middle. The original article points to the cause of failure which was dismissal of SMEs prior to deployment. Almost all projects of this size are doomed to complexity overload but that is surmountable, but loss of Product Owners and SMEs is not.
Earlier quoted context omitted.
ML based welfare eligibility screening seems a few short steps from Kafka. I'm not sure if that's what they were doing, but it seems like something that somebody would think is a great idea.
States were successful in moving Medicaid enrollment to outsourced providers. THis was probably seen as building on that theme. I think IBM bought an Irish company that did similar work in the UK, so it probably looked achievable, and a potential Cash cow for other states. (Accenture was able to sell child welfare solutions at great profit in the 90s) Its a great business as it generates alotmof complimentary sales a…
In the 90s that would have been Andersen Consulting rather than Accenture. Although having worked with them at the time and found them worse in every way than IBM is described in this thread, I wouldn't be surprised to learn they profited at the expense of poor children.
Earlier quoted context omitted.
http://wiki.c2.com/?WhyIsPayrollHard
Similarly, Gay marriage: the database engineering perspective https://qntm.org/gay
Earlier quoted context omitted.
> That stuff is toxic, and I pity any organization that Oracle got its claws into using that junk. In my experience, no one is really duped by these big companies. The people writing the checks generally start their search with magic quadrant leaders and then further narrow it down to the biggest players because "we can't trust our business to some no-name." It's really a situation that companies willingly put themse…
I've yet to see any way to procure custom "Enterprise" software that isn't awful, and sadly I do believe duping is a huge part of it. The duping starts long before the Oracles/IBMs/Whomever of the world ever reach a customer too - the "analyst" firm role is a huge problem with companies like Gartner/Forester who dream up the "Magic Quadrant" that people purchasing this stuff end up stuck relying on. I've seen in seve…
Falling behind? Ship half a feature, lie about it or explain how it's going to be working in the next release (and when that doesn't happen, blame the customer's requests for churn, or the height of the tide, it doesn't matter). In danger of actually completing a contract? Trod hard on the bugs, you don't want that money pump to stop. Larry Ellison needs a new dock for his yacht? Time to increment the product's version field and let a thousand consultants bloom. Ka-ching, baby.
My experience with the space, both as a developer of Enterprisey software at several start-ups and as a customer, was that this corner of the industry is ethically sick, and I won't have anything to do with it.
Earlier quoted context omitted.
Probably because you don't notice the corruption. That vendor that has lots of technical issues and the manager that is refusing to change. Well, they know each other and the vendor is giving kickbacks for dragging it out as long as possible.
Most of the corruption in government IT contracting is more subtle; its things like government managers developing relationships with contractors and favoring them subtly without kickbacks, simply because they are comfortable and feel better working with them. The people doing it probably mostly feel like they are actually doing a public good and working around red tape, because they genuinely believe that intangible…
Earlier quoted context omitted.
And, often times that discussion leads to a decision maker saying - that shouldn't be the case, it's your problem, not ours that you can't handle that. So you end up assigning someone to 8+ hours of work to do it, you also have to end up having 2-4 meetings on the topic, and on and on.
8 hours of work to fix a small issue like this one is just bad design. In this case using php.
Everything is bad design everywhere, at least when you're a consultant. You're generally not brought into projects that have good design, and everything's roses.
I've been on a few projects with amazing design, and it was a very different experience. I didn't even argue for more work for them, because they had it all under control.
They essentially, wanted to be confirmed how great they were. I don't know if the CIO was curious if it was true, or if they all just wanted pats on the back, but we taught them a few really detailed things they didn't know, helped on a few really tricky edge cases, and said you're golden, keep killing it.
Earlier quoted context omitted.
Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company. But after selling the deal, their workers have to solve a difficult engineering and organizational management problem…
Early in my career I had a brief stint as an engineer at a consulting company in the ERP industry. Our projects always had at least one functional consultant whose expertise was _using_ the ERP systems and understanding how they integrated with other systems and procedures. This was a different position than PM, who was often an employee of the client company who drew the short straw. The functional consultants had v…
A functional consultant on our team who is great. Connected to their functional consultant who was wildly differing in skill level, from expert to can barely use a computer.
Technical Consultants, which involved 1 Senior who knew everything about one segment of topics. Another Senior who knew everything about a different segment of topics. A junior to learn things. And the PM which was also the sales lead looking for more work.
1 of those Seniors needed to be able to have social skills and diplomacy, the other didn't. You could hide the 2nd through preplanning.
The junior just needed to know to keep his mouth shut.
Then you'd have a variety of other seniors who you could call in on a particular topic, but you'd try not to use, as they are on projects.
And in our case, we had a GM who was more functional than all of us, almost as technical as all of us, and the best in front of customers. He could be brought in to deal with any special scenarios, and to gut check our plans.
So we were really, ridiculously successful with that model.
Basically, really well paid, SMEs, no cruft except a younger guy to learn on the job. Such a good structure.