Large-scale public sector IT transformation doesn’t normally makes headlines, particularly in the usually sleepy news cycle of summer in Canada.

But this year, we’ve witnessed the gory details of a slow-motion play by play of the extraordinary rise and fall of Phoenix, the Government of Canada’s new centralized pay system. As change management professionals, this has given us a front row seat in what is sure to become the poster child project for how technology and process centralization can go horribly wrong.

While I have no direct knowledge of the project, or the inner workings of what  is certainly a massively complex and ambitious transformation, I’ve been fascinated to watch the story unfold from the lens of change management.

If you aren’t familiar with the issue, here’s a brief summary:

Under the Harper government’s Shared Services model for administration, an ambitious plan to centralize the pay system for Canada’s 300,000 public servants was initiated in 2009 and was launched by the Trudeau government this past February. Over the last six months, 80,000 employees have experienced pay problems: some have had errors in their pay, some have been overpaid, and more than 700 haven’t been paid at all. Those who received no pay tended to be those whose pay processes were non-standard, such as students and workers returning from maternity or medical leave.

That’s how the otherwise rather dry topic of federal pay system renewal became headline news across Canada. Stories from employees receiving no pay ranged from students who couldn’t pay rent, cancer survivors who couldn’t afford out of pocket health expenses and hundreds of employees experiencing significant stress caused by losing their income (and, not insignificantly, still being expected to perform at their jobs). For many, it’s been a summer where usual activities such as holidays and summer camp have become impossible. Legions of employees are suffering from debilitating stress, anxiety and insomnia as a direct result of this failed technology deployment.

On top of these massive problems, major privacy breaches of employees’ sensitive personnel information were also identified, and may leave the Government of Canada vulnerable to legal action. This compounds the primary legal risk exposure faced by the Government of Canada given that not paying workers is a violation under the Canada Labour Code.

At a system level, this is remarkable. The Canadian government prides itself on being a digital powerhouse – not the kind of banana republic that might have basic pay problems with almost a third of its employees. From a procurement perspective, this story may be a searing chink in the armour of the oft-repeated axiom that “nobody ever got fired for hiring IBM”, the technology partner who was awarded the $180 million contract to deploy the off-the-shelf PeopleSoft solution.

Lessons In Change

Following an emergency meeting of the government operations and estimates committee, escalated efforts are now underway to correct the technology with the goal of resolving all issues by October.

In the interim, what lessons does this live case study offer to change leaders and practitioners?

Here’s what I see as main insights for change management emerging from Phoenix to date:

1. The role of risk analysis: It would be fascinating to uncover what risk analyses were conducted at the design stage of the Phoenix project. It now seems clear that any initiative affecting the hot-button issue of pay for employees should be treated with particular care. Additionally, a full identification of the reputational risks involved in the roll-out may have been helpful in making a business case for an enhanced focus on the change process, including readiness assessment, testing, communication, training and sustainment.

2. The business case for meaningful consultation: Much of the coverage of the Phoenix system problems are reports that in fact, IBM built the system as it had been requested and scoped, and that it’s functioning as it was designed to perform. If this is correct, it points to significant gaps at the needs analysis and business requirement design stage. While conducting meaningful consultation with employees across a mammoth organization such as the Government of Canada would be a herculean task, the value of such an exercise may now be evident. For example, issues related to military employee pay problems caused by their use of a different employee number system surely would have surfaced had front-line pay administrators at National Defence been asked about their particular needs for a new centralized pay system.

3. The value of listening to feedback leaders may not want to hear: There are widespread reports that concerns were raised that Shared Services was not ready to roll-out Phoenix, but that those red flags were ignored. This pattern escalated in April when public service unions urged the government to delay the rollout of Phase 2 of Phoenix (to an additional 67 departments). These concerns underscore the importance of building and nurturing a culture of trust and collaboration among project teams, in which difficult truths can be expressed, and heard.

4. The real cost of change: As practitioners, we often struggle with measuring the intangible results of a change initiative. In the case of Phoenix, the cost of the problems in deployment go well beyond the estimated $20 million required to fix the issues. A true cost analysis must include the massive ripple effects to operational functioning and effectiveness. Of interest would be: what is the cost of Phoenix to employee engagement? It’s hard to imagine that unpaid employees are able to work at their full potential – and this gap will necessarily have a massive ripple effect on collaboration efforts up, down and across 300 departments and agencies. How can a manager effectively direct an employee who isn’t getting paid? How can a team mate ask for a deliverable from a colleague who is working without pay and can’t pay her rent? What is the direct and indirect effect of these gaps on service delivery for Canadian taxpayers? (On that note, is there a taxpayer in Canada that has faith that the money spent in overpayments will ever be fully recovered?) A full understanding of the potential cost for change failure may, in retrospect, have been helpful in making the case for a stronger level of investment in project readiness and change management.

5. The importance of training: Consistently, officials commenting on the Phoenix deployment have pointed to gaps in training for the key teams responsible for implementation. The fact that this exercise was run out of an office set up in Miramichi, New Brunswick may have exacerbated the pressure on training a team that is relatively isolated from the level of capacity that might have been available in Ottawa. While there never seems to be enough time, money or energy to do training right on large-scale technology projects, the Phoenix example reinforces the vital importance of this core change management function.

6. The significance of a sustainment plan: Not surprisingly, many of the compensation advisers working at the beleaguered Pay Centre in Miramichi are suffering mental health problems, resulting in increased absenteeism and stress leave. This is a double whammy effect since the very people public servants are counting on to solve the problems in the pay system are themselves struggling in what has to be a particularly stressful and negative environment. This points to the importance of a sustainment plan that helps manage the energy of a team responsible for the long-term operation of a new system.

While the Phoenix issues are resolved in the coming weeks and months, the project will no doubt become the new cautionary tale for change practitioners working on public sector centralization initiatives in Canada.

Fast forward months and years from now: All a change manager will have to say at a project meeting is “remember Phoenix?” for a sponsor’s blood to run cold – it may be just the reminder that’s needed when a sober second look at the importance of risk assessment, consultation, training or sustainment is in order.