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.
The ONLY person who would think all that is a good idea are the engineers who were able to update their linkedin with "implemented ML based solution to replace human resources with computer resources to streamline the welfare system for the state of X"
Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
231–240 of 333 posts
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#232Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#233Not having ever worked on anything like this, the death knell for these projects must be the inability to ever reduce functionality into a reasonable core set. Basically the 80/20 rule but where there are practically an infinite number of edge cases that stretch the project on indefinitely? You could serve 80% of the payroll burden with software that cost $10m. 90% coverage costs $100m. 98% costs $1,000m. And 100% co…
> 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…
“So Oracle has this great product that will do eighty percent of what you want just by throwing the right switches in the software—no special code or anything—and it all falls down because someone asks that innocent little question: ‘What else would you like it to do?’” (p. 231).
https://www.amazon.com/dp/B00AK78QVI/ref=dp-kindle-redirect?...
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#234Earlier quoted context omitted.
> So, what makes a payroll system at this scale so difficult? Complex pre-existing business rules of a large, sui generis employer (governments, especially sovereign ones rather than localities, often are because the laws that apply to other employees don't apply to them, and the rules that do apply often aren't coherent across-the-board policies determined by a central org focussed on HR, but often are set in specia…
It seems like lots of the payroll was being carried out by humans in local units. Humans are very good at holding lots of exceptions in our heads and, in the absence of clear rules, doing reasonable things. Computers are shit at both of the above. So things like Bob negotiated with his boss to leave early on Thursday to cover childcare and, in exchange, is coming in early on Tuesdays... but got asked to come in Satur…
I believe the answer is "neither". Federal employees are exempted from both. That case would be decided based on federal law and the union contract. It's made more complex by the fact that the union contract is often applied retroactively to events several years in the past due to how long negotiations take.
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#235Reminiscent of the state of Indiana's lawsuit against IBM for allegedly botching a project to automate the state's welfare system — lots of finger-pointing on both sides; the trial court's 65-page decision started out with the words, "Neither party deserves to win this case" [0]. The case has been up to the Indiana Supreme Court already [1]; on remand last summer, the trial court found that IBM is liable for USD $128…
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…
The functional consultants had varying degrees of technical experience (some were highly technical, including having CS degrees), but in general they were people who in a previous life became really good at managing and hacking their company's ERP system, became the goto person to deal with crap, and figured out they their domain knowledge was highly valuable.
The competence of our technical consultants was questionable. On my first project the senior tech consultant told me that I was the first person he worked with (himself included) who structured his code into modules. He was like, "it makes it so easy to use your stuff!" :) But the functional expertise was excellent and the reason the company had an excellent project success rate.
The company basically imploded after some senior technical engineers and managers bought into the Java and XML fad. Their plans failed horribly because the technology was too complex for the technical consultants (not to mention too immature), and it left little room for leveraging the expertise of the functional consultants as pivoting to Java and XML effectively required reinventing everything. Chaos ensued and, after being bought by a major ERP systems vendor (ironically for their strong project success rate), effectively disbanded.
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#236Earlier quoted context omitted.
Back in 1999, I was in the elevator and I heard the admin. staff say PeopleSoft (the software) doesn't do anything. This was @ Polytechnic Uni. in Brooklyn. This conflicted with the school's public message where (officially) adopting PeopleSoft was a big step in the right direction. I always wondered if PeopleSoft improved since. I guess not?
My employer recently switched from PeopleSoft to Oracle for HR stuff. So now instead of the system itself being slow to respond, it is plenty responsive when I put in for time off. However, if I fill out the form too quickly it rejects the input as invalid. They can't even get form input validation to work correctly.
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#237Earlier 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.
The ONLY person who would think all that is a good idea are the engineers who were able to update their linkedin with "implemented ML based solution to replace human resources with computer resources to streamline the welfare system for the state of X"
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#238Earlier quoted context omitted.
Or in Queensland with the $1.5b health payroll failure. https://www.itnews.com.au/news/queenslands-ibm-ban-lives-on-...
I have known two people who worked in the Queensland Health payroll roll-out. Both actually blamed the government for constantly changing specs, and politicians making claims in parliament about deliverables and deadlines that they then had to meet. They also said IBM (or whatever actual contractor they had on the ground) should have managed things better. I now work with someone who was at Main Roads Queensland who…
I'll bet there's plenty of IBM salespeople who hate that one guy who made bank on the QHealth deal...
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#239Earlier quoted context omitted.
> In IBMs defense, I don't believe our public sector has the experience or aptitude required to act as a supporting interface for a job of this scale. How in any way is this "In IBMs defense"? We should think it OK that they pursued and committed to a large government contract that in reality they were not qualified to complete? The sentence reads more as a condemnation.
“Our” in this case clearly refers to Canadians, not IBM. Do you know what public sector means?
Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B
#240Reminiscent of the state of Indiana's lawsuit against IBM for allegedly botching a project to automate the state's welfare system — lots of finger-pointing on both sides; the trial court's 65-page decision started out with the words, "Neither party deserves to win this case" [0]. The case has been up to the Indiana Supreme Court already [1]; on remand last summer, the trial court found that IBM is liable for USD $128…
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 do understand what you meant here, and it's mostly right. But there are also obvious exceptions.
You can often make a sale by promising more than your competitors. If your competitors' bids are calibrated by what's actually possible, and yours isn't, then you'll win the bid... and then, years later, be unable to deliver what was specified, and have to renegotiate. But hey, you won the bid!
I guess that, if the market doesn't keep track of these renegotiations and failures-to-deliver, this is the optimum strategy over the short- and even medium-term. But it gets your company known to devs as a company that chews up and spits out talent. Devs that get stuck on projects trying to do the (literally) impossible, slogging forward each day with the knowledge that all of this is going to be ripped out when the deadlines pass and the renegotiation hits, don't tend to recommend to their friends the companies where they had to do that. So, over the long-term, this is a recipe for a talent shortage.
But, like you said, there's always contractors: fresh pools of devs who never signed up to work for something like IBM, headed by either unscrupulous or just plain naive management willing to take on such jobs with literally-impossible specs.