It’s a sad story. A government seeking to replace legacy technology, mitigating risk and saving public money by modernizing payroll. The result: more than ¼ of public servants experience pay problems – mostly underpaid. Some have not been paid at all. One observer called it a “debacle“. It’s become highly politicized, with daily stories in the Canadian press.
For those unfamiliar with the problems in the system named “Phoenix”, check out the timeline from the Canadian Broadcasting Corporation (CBC).
We all recognize the media can focus more on the sensational, and less on the technical project and software details. The current government party, the previous government party and the systems integrator have all been blamed. The purpose of this entry is to provide a more dispassionate analysis.
What’s missing in the media coverage is this sort of problem is not unusual. The United States Government Accountability Office concludes “federal IT projects too frequently incur cost overruns and schedule slippages while contributing little to mission-related outcomes.” Complexities in public financial management and the political dimension leads to more problems in government IT projects than in the private sector.
Rational and Human Decisions Made
Let’s be clear, the decisions made by public servants in procurement and implementation are rational, and within the typical footprint of information technology decisions made by governments and large businesses. This includes:
-
Selection of the most successful Enterprise Resource Planning (ERP) system for human resources and payroll: Oracle PeopleSoft: Phoenix is a PeopleSoft 9.x module, which gives the Government of Canada a strong reason to transform 70 different Human Resource Management Systems currently being used across the federal government departments to one single PeopleSoft 9.x (MyGCHR).”
-
Competition among stable and proven systems integrator firms during the procurement process. IBM won the competitive bid process. IBM is an eminently qualified company. This combination of Tier 1 ERP and Tier 1 systems integrator is an established strategy to reduce risk.
-
Rational budget, reported to be around C$300M, with a very attractive project ROI. The move to centralize payroll was expected to reduce staffing and information technology needs.
-
Well-understood business rules for the production of payroll in Canada. It is true the payroll regime is complex, but is highly codified. There are numerous applications that were used in previous decentralized payroll regimes that encapsulated these rules.
It is difficult to argue with the decisions made. Easy in hindsight.
What Went Wrong?
It is difficult to interpret the implementation details from media reports. We all know large IT projects are risky in government. I might be reading through the lines, but here are some patterns seen from other governments:
-
Big isn’t always better, as I pointed out in a previous blog entry on government shared services, big doesn’t mean better.
- Blame doesn’t make for an environment for success, as pointed out by industry analyst Michael Krigsmann: “There are whole strings of failed IT projects where everybody points fingers at everybody else, and there’s no one who ultimately takes responsibility.”
-
Escalating commitment is a typical organization dynamic where organizations “when faced with increasingly negative outcomes rather than alter their course.”
- Focus on timely delivery in large projects often results in acceptance of poor quality. This is a classic problem identified in the “project management triangle” – fast, good, cheap. Reports suggest that public servant bonuses were tied to meeting time lines. This creates perverse incentives to accept poor quality in favour of driving the project based on the original project plan.
-
Customization of PeopleSoft to meet business rule needs add risks. Legacy ERP systems, designed for the private sector, often require significant code customization to meet complex government business rules. Many governments find that the effort to customize off-the-shelf systems through programming is as much of a burden as developing from scratch.
-
Training is never finished, particularly for ERP systems, is a critical factor for success. It’s not yet clear whether there has been a lack of training or not. It doesn’t seem probable that any lack of training is responsible for employee names to randomly disappear from the system.
-
Risk management isn’t about risk avoidance, as pointed out in a previous blog entry, the selection of established vendors does not abrogate the responsibility of clients to mitigate risk.
What is the Solution to the Problem?
Political pressure and intense media scrutiny is not a recipe for success. High-stakes projects often suffer from reduced consideration of innovative ideas and reliance on decision by senior managers rather than those who may be more qualified. Typical solutions to IT problems do not appear to be realistic:
-
Putting more people on the project is likely to generate even more problems, as articulated in the 1960s in the “Mythical Man Month.”
-
Reverting to the previous system, while re-configuring the new system may not be realistic given the layoffs of public servants who operated the previous decentralized system.
-
Re-tendering for a new systems integrator or different software appears to be too late.
Here are some helpful ideas:
-
Audit project governance, processes and documentation to determine whether the project can be improved through agile methodologies or review points and make changes.
-
Adjust scope and time deliverables so that the project is not presented as a “big bang” where 100% of all problems need to be solved by October 31. Classes of pay types should be delivered in iterations starting with those impacted most.
-
Create a risk mitigation strategy where management focuses on areas of highest concern of likelihood x impact.
-
Communicate beyond the press to employees and citizens who are the most important stakeholders. The media is defining the narrative, and it could be entirely misleading.