September 21, 2016Doug Hadden
My blog post yesterday covered recent developments in two large enterprise software failures in government. That entry covered the difference between achieving what was designed (“as-designed”) versus what was needed. This entry covers the issue of training, particularly with the Government of Canada’s “Phoenix” pay system.
This was the assertion last Thursday that there is nothing wrong with the software in use for Phoenix, it’s a lack of training that has led to the problem. This sounds like an excellent point, unless you have some experience in enterprise software. It sounds too much like the old joke about the successful operation where the patient dies.
Training is Part of any Enterprise Software Project
Enterprise software projects need to be virtually turnkey. In other words, training and handover are part of any implementation project by systems integration firms. When about 1/3 of public servants experienced pay errors, including some not being paid at all, it’s a project failure. The failure could have come from reducing the training budget or from skimping on training. It could be a vendor or customer fault, or both. Why wasn’t the lack of training identified as a root cause after the first pilot?
We live in a new era of ubiquitous computing on computers, smartphones and tablets. New cars have sophisticated computers and instrumentation. Learning unnecessary complex enterprise software is no longer an accepted cost of doing business. Many of the legacy ERP software packages, such as Oracle PeopleSoft used for Phoenix, have user interface designs that stretch back to the 1990s. I wonder how much training ought to be required for those familiar with Government of Canada pay rules if the software was usable. It’s not as if public servants in Canada are uneducated, unskilled or unfamiliar with IT systems.
Maybe it’s about ‘Workarounds’
Many legacy enterprise software applications are designed for users to navigate in specific ways. This often adds some data entry burden and requires operating in counter-intuitive ways. Users will often find workarounds. These workarounds may have resulted in errors. Or, workarounds should be used, but there was no training.
Passing the Buck
Phoenix has become so politicized that it’s hard to separate fact from fiction. It’s so politicized lawyers are now involved, meaning positions are staked-out that may have little to do with reality. There could be some truth to the notion that more or better training may have reduced errors. The interesting thing about “technical updates” on Phoenix given to the press is that there is little about “technology”.
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016