September 20, 2016Doug Hadden
There are a number of developments in a pair of high profile government “enterprise software” failures: pondering the “Phoenix” Government of Canada pay system and the “Cover Oregon” healthcare site. Both enterprise software implementations had been declared ‘successful’ by vendor or client.
How anyone can describe these projects as successful, with a straight face, is beyond me. The Phoenix payroll problems have affected about 1/3 of all federal public servants in Canada, and the Government Oregon abandoned the Cover Oregon project.
There’s nothing wrong with the software in use for Phoenix was a recent assertion, it’s a lack of training that has led to the problem. It’s not a “software malfunction“. Meanwhile, the supplier for Cover Oregon has agreed to refund $100 Million to settle a lawsuit.
Why is this important for enterprise software risk management in government?
‘As-Designed’ Software Malfunctions
Those of us in the enterprise software space are familiar with “as-designed” defects. These occur when the software behaviour doesn’t match user expectations, but are fully compliant to the specifications developed. This may have played a role in both situations.
- Commercial Off-the-Shelf (COTS) software from Oracle was used for both situations. Oracle PeopleSoft in Canada, implemented by IBM. Oracle Siebel in Oregon, implemented by Oracle. COTS software tends to be of high quality with few defects. There is likely nothing technically wrong with either Oracle application, however errors can be introduced during implementation.
- Private Sector design, rather than what we call “Government Resource Planning”, has been known to cause problems in the public sector. Functionality that makes perfect sense for a business can present governments with problems. There is a high likelihood of missing government functionality. Both applications could be very robust, but lacking expected or needed functionality.
- Customization of COTS software tends to be high in government because of the inherent private sector design. Specifications for customization need to be completed by the systems integration firm. It’s entirely possible that not all requirements were effectively articulated. It’s also possible that mistakes were made in requirements gathering. Ultimately, the software could have operated 100% as-designed, but not meeting the real need.
- Customization and Configuration are considered synonyms by some. There is a significant difference. In my reading of the Cover Oregon project, Oracle asserted that scripting was not customization – it was configuration. Customization can take time, often consuming needed quality assurance cycles. The customization could have been faulty although the applications have no “malfunction”.
The risk lesson for government organizations is:
- Clarify what’s really off-the-shelf, and what needs to be configured, scripted, and code customized.
- Focus not on what is different in government, not on what is similar between the public and private sectors.
- Recognize that needs articulation is the number one contribution that governments can make for GRP success.