Back to TopBack to Top
 

The (IT) Project was a Success, but the Patient Died [Part 2]

 

September 21, 2016

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?

Why Training?

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”.

The following two tabs change content below.
Doug Hadden

Doug Hadden

Executive Vice President, Innovation at FreeBalance
Doug is responsible for identifying new global markets, new technologies and trends, and new and enhanced internal processes. Doug leads a cross-functional international team that is responsible for developing product prototypes and innovative go-to-market strategies.

Leave a Reply