http://wiki.c2.com/?WasChryslerComprehensiveCompensationSucc...
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
These things are hard to get right in any complex enterprise.
51–60 of 333 posts
http://wiki.c2.com/?WasChryslerComprehensiveCompensationSucc...
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...
These things are hard to get right in any complex enterprise.
Not 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…
Also there's a good chance that the decision to go with IBM as a vendor, and the conduct thereafter, was corrupt from the start. That would go a long way toward explaining why so little due diligence was observed in assessing whether or not to continue the project with them at any of the stages it could've been. Yes, people do make huge blunders in powering forward with overpowered, unnecessary solutions to problems…
This is actually pretty minor league compared to U.S. government failures.
e.g. https://www.wired.com/story/us-border-patrol-hasnt-validated...
It is also a political pork barrel project.
> The project was meant to save costs by firing 1,200 employees handling payroll at various departments around the country and replacing them with about 500 people in a centralized location using Phoenix to handle most of the government’s payroll needs.
What's not written there is that the decommissioned long gun registry was located in a rural part of New Brunswick. When it was killed by the conservatives, they had a big political issue on their hands because suddenly hundreds of federal government clerical workers were out of a job in this area. So what was the solution? Re-hire the same people and put them on the Phoenix payroll project. Never mind that not one of them had any experience with IBM, Oracle, PeopleSoft, payroll, finances, or anything else related. They wanted butts in chairs in front of keyboards and to keep those people on the federal workforce payroll.
https://www.google.com/search?num=100&client=ubuntu&hs=ssW&c...
quick edit, history lesson:
early 1990s, Chretien Liberals: we need a gun registry
liberal party: okay we passed a gun registry law
liberal party: we need a pork barrel project to make these people in small town new brunswick happy, let's hire 500 people in miramichi
liberal party: this gun registry has now cost 400% of what was originally budgeted
liberal party, paul martin government loses an election to stephen harper and the conservative party
harper conservatives: we promise to scrap the long gun registry
harper conservatives: we've removed the long gun registry but now all these people are out of work and pissed off
harper conservatives: we need to overhaul our old payroll system that runs on a bunch of old minicomputers, let's hire ibm
harper conservatives: let's re-hire those people we fired and put the payroll center in small town new brunswick!
harper conservatives lose the 2015 elections
trudeau liberals: wtf is going on with this contract the previous government signed. wtf is going on with this clusterfuck of oracle, ibm, peoplesoft and porkbarrel politics of employing people who are not payroll specialists.
trudeau liberals, later on: seriously this is broken beyond repair
Canadian here. This has become a huge political football. People are blaming the current Liberal government, when the project was started by the Harper Conservatives. The full extent of just how fucked up it is has just now become public knowledge. It is also a political pork barrel project. > The project was meant to save costs by firing 1,200 employees handling payroll at various departments around the country and…
and that's why governments should hire software engineers that can be in the loop and understand not only the technical but the policy side. Hiring an army of contractors earning 300k/year to deliver "something" in the waterfall model is a recipe for disaster.
Agile is much better when no one has figured out a way to pay people money
Not 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…
As techies, we think the technical solution is the most superior solution but that is not always the case. Here is an example of something that just happened to me 2 hours ago today. User called and said osTicket system I manage treats '0' as blank. So when they fill out a form with question 'How many X happened today?' and they enter '0', the system just treats the field as unfilled and does not print '0'. That's a big problem for auditing because they absolutely need to be able to show that it was '0'. I started digging into the source code to see where '0' int was treated as a blank. osTicket being PHP where 0, '', null, and false can all be treated as FALSE, it could've been 8+ hours worth of work digging into the right piece of code to figure out the fix.
So I called the user up and we discussed the best way to handle this. In the end, I added a new question above this one: 'Did one or more X happen today? YES/NO'. If it's 'NO', it doesn't matter the 'How many X happened today?' with '0' doesn't get printed.
To make a major implementation work, this kind of discussion needs to happen 10000x a day among 1000+ people, many of whom may not have the authority to just decide things on the fly.
Earlier quoted context omitted.
Also there's a good chance that the decision to go with IBM as a vendor, and the conduct thereafter, was corrupt from the start. That would go a long way toward explaining why so little due diligence was observed in assessing whether or not to continue the project with them at any of the stages it could've been. Yes, people do make huge blunders in powering forward with overpowered, unnecessary solutions to problems…
> blunders this big usually don't take this long to suss out This is actually pretty minor league compared to U.S. government failures. e.g. https://www.wired.com/story/us-border-patrol-hasnt-validated...
I am guessing one of the reasons is probably the software selected... oracle
Software implementations usually fail because of the implementors failing to understand and map the business needs prior to beginning in detail, vs launching with whatever and making twice as much money fixing it after the fact "as you go".
I have lead a few full cycle ERP implementations, and replaced vendors along the way if they were not performing.
The challenge remains is software vendors are not sufficiently motivated enough to learn the business in detail before implementing software to help run the process.
Was not surprised to see Oracle and PeopleSoft involved. I hope they get the crap sued out of them. That stuff is toxic, and I pity any organization that Oracle got its claws into using that junk.
So, what makes a payroll system at this scale so difficult? On the face of it, there are salary employees and there are hourly employees. How many taxing bodies does Canada have? Federal, provincial, and municipal? Is that a few dozen or a few hundred? Is Canadian tax code crazy complicated that doesn't allow for a rules based system? I'm honestly curious as to how a "simple" payroll system can go so far off the rail…
> 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…
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 Saturday and now has overtime and what does he get paid based on province or local rules? Does OT end at midnight or not? Do employees get paid non-required OT as a courtesy? And frankly, lots of payroll probably sometimes violates the rules in minor ways, but as long as the employee is happy and the org is happy no-one is upset. Computers are not good at letting small things like that go. And that's a pretty trivial case.
What about eg janitorial that is paid by multiple government orgs on some cost sharing arrangement because the orgs share office space, but is covering an event for a 3rd org in the 2nd org's space? And that janitor is on a particular contract, one of perhaps 5 or 6? If that has to get encoded into a central system, have fun with that. God only knows how many exceptions there are across a quarter of a million employees.