Phoenix, frankly speaking

Recently, Privy Council Clerk Michael Wernick sent a letter to department/agency (hereafter: departments) heads using Phoenix asking them to report to him by Thursday, Nov. 16 on what they are doing, or plan to do, to stabilize Phoenix. And on Nov. 21, the Office of the Auditor General is expected to release its report on the Phoenix Pay System (pro-tip for Clerk: use the DMs’ responses as basis for management’s response to the AOG report).

The project is well beyond the SNAFU stage of project implementation. What needs to be determined is if the FUBAR status the public service pay system is temporary, or permanent. To do so, an accurate representation of the current situation is required in order to revisit commitments to move towards the future state of desired expected results. Moving forward, activities to deliver on that future state need to incorporate insights from the Lessons Learned report, and more.

I’ve outlined below what more is, in keeping with the employer’s stated commitments to open and transparent government; results delivery; and respect for organised labour. I have also suggested appropriate performance metrics to be reported on publicly. Adopting these commitments meaningfully will tackle many of the root causes for the mess we find ourselves in collectively today.

Did you see the movie Hidden Figures? The part where the boss lady tells the team leader for the (human) ‘calculators’ — actual job title — that they won’t be needed anymore, because NASA bought some spiffy IBM off the shelf products? Yeah, a great scene. Prophetic, even, given the ongoing hype that automation and AI are gunning for our jobs and that we are replaceable widgets. Phoenix was going to be just such a spiffy IBM project — it was going to standardise and automate processes; be easier to use (self-access); it was going to harvest efficiencies while reducing costs.

It was going to be beautiful.

And then someone plugged in the machine and…all hell broke loose.

Before I go any further with this post, I’m going to put down some context notes to ground my observations. Here are some quick facts on public service pay systems:

· 8.9 million pay systems transactions annually

· 22 employers are in the system

· 80 Collective Agreements (CA)

· 80 000 business rules (wages, hours, benefits, working conditions, and associated rules in a CA)

As with most large, complex projects, the Phoenix roll-out was broken down into manageable work chunks, with a phased approach for staggering roll-out across departments. Standard project management practices were used in scoping out the project as well as the subsequent stages. It was always going to take several years to roll-out.

Phoenix Phase I work progressed in a dynamic public sector context that shifted almost year to year, creating new drivers for change as well as pressured to deliver. Among the notable:

· The Greening Government Initiative;

· The Back Office Transformation Initiative;

· The Strategic and Operating Review (SOR) of 2011;

· The Deficit Reduction Action Plan of 2012;

· Information technology (IT)-related initiatives including the creation of Shared Services Canada (SSC); and,

· The development and implementation of MyGCHR (Peoplesoft) in many departments — 44 to date.

The Phoenix project itself — or Transformation of Pay Initiative, was made up of two elements: Pay Modernization and Pay Consolidation. Phoenix’s long term expected result was to be the bedrock for long term sustainability of the federal pay administration and services.

So, what went wrong with Phoenix?

Well, pretty much everything that could. I mean everything (below is not an exhaustive list):

· Using an off-the-shelf software solution designed for a different workflow and organisational culture and trying to re-engineer it (this had never been tried before)

· Firing the subject matter experts you need (viz. the compensation advisors)

· Changing the scope of the project constantly

· Killing the change management component of the project — which flies in the face of any understanding of what large scale complex projects are

· Failing to recognise that the HR-to-Pay processes were of a whole rather than discrete processes (a basic failure to map the current state to plan and deliver for a future state)

· Failing to capture actual business processes in all their complexity

· Failing to collaborate with the end-user (or their agents) of the system (viz. the unions on behalf of staff)

· Failing to establish clear accountabilities and governance structures across departments and project leads (who’s on first? PSPC? TBS? Department Heads?)

· Defaulting to CYA and massaging of evidence when the true impacts on usability and performance were becoming clear…

Ech. It’s almost too perfect in its awfulness to be believed — but don’t take my word for — read the Report by the independent, third-party firm contracted to look into the mess (add another 100K to the overall bill, at least).

The Phoenix project will go down in the history books of a classic example on how not to roll-out large scale projects in a complex socio-technical system. The one consistent feature of Phoenix has been its ability to circumvent almost every known sound management practice for large complex projects (whether one is talking about project management; performance management and measurement; risk management, etc.).

The sobering news — yes, there’s more — is that we’ve only made it partway through the transformation. Not all departments initially slated to migrate to MyGCHR been completed. Of course, the status of SSC and large scale IT project investment, management and ownership is now an open question.

Phoenix remain in the news as employees continue to be underpaid, overpaid, or not paid at all. And its employees that continue to shoulder the burden of this failed initiative.

So where are we at now?

MOVING TO A STEADY STATE

The Phoenix system needs to move to a steady state that incorporates as many of the desired features of the anticipated new system as possible — or, it needs to make an evidence-informed decision as to other courses of action, should the IBM platform be incapable of being stabilised with desired features. Failure on this file is not only an option, but one that’s been exercised already. To move beyond failure, to stabilise the system, a number of changes and actions need to be implemented, and their impact/progress towards objectives measured.

The Public Services and Procurement Canada Minister’s Mandate letter included general commitments to open, honest government that is accountable to Canadians; as well as specific pay commitments such as public servants being paid accurately and promptly. As public servants and members of organised labour directly, you and I are adversely impacted by the employer’s actions (or failure to act). I make a series of observations on necessary interventions consistent with the Lessons Learned report; the employers avowal of principles and practices; and drawing on my functional areas of expertise, to suggest courses of action the employer — and the employee — must take on in order to remedy issues..

I make them knowing that the people who have borne the burden of this fiasco are the public service staff who have found themselves under/over paid, or not paid at all. The burden has been shared by many front-line workers too: project officers; risk management specialists; advisors and analysts — people I have no doubt were signalling issues and red flags that were ignored. Last but by no means least among the front line workers are the compensation advisors who were ‘let go’ before the project roll-out, then hired back when the employer belatedly understood the sheer folly of assuming that the “giant calculator” it was intent on replacing was in fact made up of highly trained subject matter experts — and a poorly designed and executed IT system was no match for their expertise in service delivery.

Read Part II. Or skip to the end, and read Part IV.