Live data from Hacker News

Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

itprotoday.com

301–310 of 333 posts

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#301
The only solution to tax / accounting law and software problems is to create a reference accounting system and set it as a applicable law. In other words, to describe the law in unambiguous language.

Do we really have to write a law in the same way as Romans did? Math as a science made progress after it invented a new precise language for itself.

I'm not talking about the whole law. Only about that according to which the software is built. Since no one calculates taxes today by hand, it is worth to write the law so that it can be easily applied.

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#303
post #94

The software platform itself, a heavily modified version of Oracle’s PeopleSoft program ... What implementation of Peoplesoft isn't heavily modified? Adapting business processes to COTS software packages is extremely challenging. Anyone remember the absolute bank that Peoplesoft consultants made back in the day when ERP and Business Process Re-engineering was all the rage?

When I last "dealt with" PeopleSoft, the standard operating procedure was: 1) Pay PeopleSoft/Oracle a metric f--kton of money. 2) A CD arrives in the mail. (This little envelope cost $800,000?) 3) Your PeopleSoft consultants show up, laugh at that CD (tossing it into the microwave) and pull out their own distros with a zillion customizations that they proceed to spray over your servers. You have no idea what they are…

That's so depressing. What really gets me is just how bad the actual Peoplesoft product is: in my experience it's unreliable, poorly designed and unpleasant to interact with.

My company recently switched away from Peoplesoft fortunately.

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#304

I was the CTO for a large, Fortune 100 company. When I first took over the position I would regularly get requirements documents for internal projects that were 3 or 400 hundred pages. The project team would dutifully carry out the requirements gathering process, everything was meticulously documented, with data flows, and process maps, etc. Everything was a requirement, everything was mandatory, and everything had t…

I've seen quite a lot of this too, though from other vantage points.

I don't disagree with anything you say, and would probably go down a similar route. These projects have enormous and unacknowledged risk. One of those risks (the most common pone) is that the project does actually arrive at completion, is good enough to go into use, but it's still pretty crap. Not better than what could have been achieved at a fraction of the cost. You should (as CEO, CIO) take this as a given, and act accordingly. IE, minimize these projects and find alternatives.

So, this isn't a criticism...

Here's the problem as I see it: Custom, "enterprise^" software is important, very. A lot of things could work a lot better if we had better enterprise software, much better. Especially for government, the ability to produce good software that works is tremendous. Transport systems could be better, welfare systems could be better, democratic systems could be much higher information, education.... Google maps really raised the minimum standard for public transport "timetables," especially buses. This changes public transport, enabling multi-stop routes (you would never find them otherwise), casual use, tourist use...

So... How do we do this better? Personally, I think the recurring failure details are probably a red herring. You imply problems like not having a designer, just a dump of requirements from anyone who has the juice to make them. Problems like cargo-cult design around existing processes, rather than adapting to new tools. IMO these are symptoms of bad meta-systems, the "economy" around making decisions, buying services, designing solutions, etc. Also, naturally, the incentives.

Will this be a problem forever?

^I'm at a loss for a good general term. Hopefully everyone understands what I mean.

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#305

I was the CTO for a large, Fortune 100 company. When I first took over the position I would regularly get requirements documents for internal projects that were 3 or 400 hundred pages. The project team would dutifully carry out the requirements gathering process, everything was meticulously documented, with data flows, and process maps, etc. Everything was a requirement, everything was mandatory, and everything had t…

In this specific case a simple Google search would have sufficed[0].

[0]: https://www.smh.com.au/technology/worst-failure-of-public-ad...

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#306
post #28

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.

SAP is just as bad - at my last place there was a member of staff who worked 4 days a week - SAP could never get the rounding on their annual leave correct, often leaving them with 0.999 or 0.499 days left that they couldn't book. We had to just record it manually.

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#307
post #38

Reminiscent 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…

IBM consulting and many state governments are a mess. It’s no surprise a large project requiring both to function properly failed.

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#308

I was the CTO for a large, Fortune 100 company. When I first took over the position I would regularly get requirements documents for internal projects that were 3 or 400 hundred pages. The project team would dutifully carry out the requirements gathering process, everything was meticulously documented, with data flows, and process maps, etc. Everything was a requirement, everything was mandatory, and everything had t…

I've participated on several >$10M Canadian Gov't IT projects over the years and you nailed it. Business groups will fight tooth-and-nail to keep their existing processes - partly to maintain status-quo, but also because the folks who represent the business know little about system's analysis/design, so they just simply aren't in a mindset to re-engineer. Combine this with the vendor's (not so hidden) agenda of milki…

A factor here that might be overlooked (and I'm not making excuses for the bad process you're describing) is that changing business processes means re-training all your non-technical staff (and everything that comes with that - training materials, manuals, forms, public-facing processes, etc).

In a unionized environment like the Canadian federal government, that would likely incur not only a fairly high cost (but less than a failed technology project for sure), it's also a massive HR undertaking that business-side managers and leaders want to avoid at all costs.

So they'd rather push all that work onto the technology teams to ensure process remains the same, even if it's the wrong thing to do.

My personal anecdote on this: years ago in a past job, I led a team that worked on a project for Bell Canada to build a retention portal for their call centre agents, and the requirements were full of crazy and sub-optimal flows and features, and every single one we questioned was justified with "any other way would require too much re-training of unionized call centre staff".

In one case, for a call centre in New Brunswick, the union actually had a clause that major process re-training could only be done every 2 years, regardless of cost.

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#309

I was the CTO for a large, Fortune 100 company. When I first took over the position I would regularly get requirements documents for internal projects that were 3 or 400 hundred pages. The project team would dutifully carry out the requirements gathering process, everything was meticulously documented, with data flows, and process maps, etc. Everything was a requirement, everything was mandatory, and everything had t…

I've participated on several >$10M Canadian Gov't IT projects over the years and you nailed it. Business groups will fight tooth-and-nail to keep their existing processes - partly to maintain status-quo, but also because the folks who represent the business know little about system's analysis/design, so they just simply aren't in a mindset to re-engineer. Combine this with the vendor's (not so hidden) agenda of milki…

I've consulted to the Canadian Government on both a data science project and on cyber security as well. The technical people inside GC know what they need and it isn't IBM building custom software for something like payroll. They should use off the shelf stuff for the 95% of employees that have run of the mill circumstances and just use humans to handle the super long tail of bespoke needs that no other Canadian employer has to deal with.

The problem is that the political side of the government doesn't trust their own technical staff and they get convinced by these horrible consulting companies like IBM that the only way to write good software is to spend hundreds of millions on it but don't worry it will pay for itself with all the cost savings on staff.

They try to minimize risk through bureaucracy but they end up getting the opposite of what they want. Less useable, less secure software at 50x the price. What they would do if they understood software is communicate to the public about how good software projects need fast iteration and that mistakes might be made sometimes, but that the important thing is that they are easy and fast to fix and that there are risk mitigation strategies to stop mass leaks when penetrators get into networks.

Also, the CSE should just be empowered to take GC servers offline whenever they don't conform to a predefined list of security practices. It's 2018 the fact that all of GC isn't on HTTPS / HSTS is quite frustrating and it requires all departments to get on HSTS preload lists because of the stupid way gc.ca is a subdomain of .ca.

Re: Canada to Scrap IBM Payroll Plan Gone Awry Costing $1B

#310

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.

Have you actually tried what you are saying ? Because it's a nice idea just completely unrealistic. Software engineers who are not just technical but SMEs as well as having excellent skills in stakeholder engagement are incredibly rare. And most of them know how good they are and are contracting at, you guessed it, around 300k/year. Talented engineers are usually quite savvy when it comes to money. Also for most proj…

This is what the US Digital Service is doing. Recruiting these folks /is/ damn hard, but one thing that helps is being able to offer the opportunity to make truly meaningful large-scale impacts. It's a pretty unique environment with some interesting challenges...
Post reply on HN