– Pythagoras (est. 569bc-475bc), Greek philosopher and mathematician
In last month’s post, Start Your Project with PACE, we talked about the need to start projects properly. Projects need the right stakeholders involved and engaged at launch. Those stakeholders have to take a comprehensive view of the planned change and consider all necessary and relevant decisions. They have to be supported and equipped with the practices, processes and resources that will allow them to guide a change to a successful conclusion. And, those conditions need to persist from the get go to the project’s end.
This month’s story, the Canadian federal government’s payroll project, has been in the news for a while now. Unfortunately, it’s another one of those all too frequent multi-million dollar initiatives that didn’t go nearly as well as promised. We’ll take a brief look at what was planned, how the change proceeded and the results achieved. We’ll also look at the lesson learned in the hopes that a project failure of this magnitude won’t be repeated, at least by the readers of this blog.
But, before we go on, I have two questions:
- Why do we continue to lead projects to failure, wasting millions of dollars, time and opportunity in the process and then conduct audits and lessons learned studies postmortem to determine what went wrong?
- Why don’t we, instead, do a pre-check, leveraging the wisdom applied and gained through all those project postmortems, and build our wisdom and insight into the planning and execution of our projects?
Project success shouldn’t be a surprise. It should be planned that way!
Thanks to R.A. for the idea for this story.
In 2009, the Canadian federal government decided to replace a payroll system that was increasingly costly to operate and maintain and had been in place for forty odd years. The new system would be used to pay some 300,000 Federal government employees.
The scope was huge. According to a report entitled Government of Canada Transformation of Pay Administration (TPA) Initiative prepared by Public Works and Government Services Canada, there were over 100 different departments and agencies affected, involving 27 collective agreements requiring 9 million annual transactions for more than $20 billion dollars.
The TPA initiative involved two projects. One component, referred to as Pay Modernization, was the implementation of new technology based on a PeopleSoft payroll application. Another element of the change, referred to as Pay Consolidation, involved the reduction of in excess of 2000 payroll advisors spread across the country to 550 staff housed in a new processing center in Miramichi, New Brunswick.
As the Payroll changes were being planned, developed and implemented, three other major changes were occurring across the government; the consolidation of data centers and staff across the country into the new Shared Services Canada organization, Human Resources Services Modernization and the implementation of My Government of Canada Human Resources.
Announced in 2011, Shared Services Canada (SSC) was to modernize, standardize and consolidate IT resources across 43 departments, reducing the number of data centres from almost 500 to 7, consolidating and securing 50 overlapping networks, ensuring all emails were managed through a single common infrastructure, and equipping departments and agencies with updated hardware.
The Human Resources Services Modernization (HRSM) initiative was also launched in 2011. The objective was to modernize human resources services to reduce the number of HR systems to one for the entire government. Included was the implementation of Common HR Business Processes, to bring consistency to the delivery and management of HR services.
In summary, the government was undertaking a massive change that affected all of its organizations and employees, the related business policies, processes and practices, the underlying technology platforms and interfaces and relationships with its unions and vendors. And it was doing this while other major technology and process changes were occurring.
The government’s stated goal was to ensure the long-term sustainability of Government of Canada pay administration and services. When fully implemented, the initiative was to generate savings of over $70 million per year. The total cost was estimated at $309.5 million, $186.6 million for the pay modernization component and $122.9M for the Pay Consolidation.
The system was called Phoenix. Massively complex, the changes involved 22 different employers – the core public administration plus separate agencies – with over 80,000 business rules governing wages and salaries.
The timeline presented here has been dredged from a variety of sources including government documents, the Auditor General’s report on Phoenix Pay Problems, a Lessons Learned study conducted this year by Goss Gilroy Inc. and a multitude of reports and commentary in the news media.
- Spring 2009 – Approved Transformation of Pay Administration (TPA), including two projects Pay Modernization and Pay Consolidation.
- February 2010 – Issued request for proposal for System Integrator.
- August 2010 – Announced Pay Centre installation in Miramichi, New Brunswick.
- June 2011 – Contract issued to IBM for system integrator and PeopleSoft’s Payroll software.
- December 2011 – Internal project re-allocation and departmental transfers. The 46 departments to consolidate pay services identified.
- Fiscal Year 2012 to 2013:
- Removed funding for change management from the project, to be a departmental mandate.
- Approved Pay Modernization (representing $186.6M of the $309.5M).
- System integrator proposed implementation in 2 rollouts (1 release) versus original plan to launch in 1 rollout.
- Independent review conducted and indicates go ahead to move to Pay Modernization’s implementation phase.
- Fall 2013 – Combined Pay Modernization and Pay Consolidation governance committees for TPA.
- March 2014 – Office of the Chief Human Resources Officer confirmed that all departments were aligned to the Common HR Business Processes.
- June 2014:
- Phoenix design complete.
- Instance of PeopleSoft to be used for Phoenix changed from 8.9 to 9.1.
- Delay in roll-outs of departments moving to My GCHR causing modifications to which departments and agencies were in each Phoenix roll-out.
- SSC experienced delays setting up network connectivity to the Quality Assurance environment for testing purposes.
- Independent review Health Check completed and indicated okay to continue.
- Spring 2015 – Modified planned July pilot with Natural Resources Canada to become an internal pilot to conduct parallel pay runs for additional reconciliation testing.
- Summer 2015 – Deferred functionality enhancements because of timeline pressure
- September 2015 – Departments received readiness checklist for Phoenix.
- Fall 2015
- Moved roll-out from October and December 2015 to February and April 2016. Moved testing to January 2016.
- Independent review signals things are okay to go live.
- January 2016 – Public Service Management Advisory Committee consulted and those present indicate departmental readiness to go live. Phoenix had 109 defects at go-live with none identified as being critical.
- February 2016 – First roll-out: 34 departments, 120,000 employees.
- April 2016 – Second roll-out: 67 departments, 170,000 employees. Hired 50 resources for telephone support team in Miramichi.
- May 4, 2016 – First full payroll from Phoenix for nearly 300,000 employees.
And then the complaints began.
The Office of the Auditor General of Canada completed an audit of the Phoenix pay problems in September, 2017. Among its findings were the following:
“Overall, we found that a year and a half after the Phoenix pay system was launched, the number of public servants in departments and agencies using the Miramichi Pay Centre who had an outstanding pay request quadrupled to more than 150,000. Departments and agencies have struggled with pay problems since the launch of Phoenix. However, it took Public Services and Procurement Canada four months to recognize that there were serious pay problems, and it took the Department about a year after that to have a better understanding of the problems.
“The problem grew to the point that as of 30 June 2017, unresolved errors in pay totalled over half a billion dollars. This amount consisted of money that was owed to employees who had been underpaid plus money owed back to the government by other employees who had been overpaid.
“In addition, departments and agencies struggled to do the tasks they were responsible for in paying their employees under Phoenix. Public Services and Procurement Canada did not provide sufficient information and reports to help departments and agencies understand and resolve their employees’ pay problems.”
The Goss Gilroy Lessons Learned study is a searing indictment of the project’s conduct. The report summarized the challenges this way:
“It is our view, that it was the underestimation of the initiative’s complexity that led to its downfall. Had the initiative been managed recognizing the wide-ranging scope of the transformation, not limited simply to a system replacement or the movement of personnel, then the initiative definition, governance and oversight, change management, outcomes management, project management and capacity management principles underlying the 17 lessons learned could have been established and closely followed.”
The report goes on to sum up with these thoughts:
“Furthermore, perhaps more important than capacity and capabilities is having the appropriate culture within which to undertake a complex transformation. Agility, openness, and responsiveness are key features of a culture that needs to be aligned with the magnitude and challenge of the transformation.
Finally, in our view, these are lessons that are yet to be learned, not lessons that have been learned through the course of the management and implementation of the TPA. It will be critical for the government to actually apply these lessons in future transformations and more immediately in the transformation challenge currently before the government in addressing the multitude of issues with pay administration today.”
The Goss Gilroy Lessons Learned study found a litany of errors and omissions. A few examples:
- The overall management of the end-to-end process transformation was not in place.
- No comprehensive plan for transformation of business processes, people/skills, organizational culture, services and functions, quality and timely provision of HR data and related HR systems was ever developed or implemented.
- The Common HR Business Processes were not implemented to a sufficiently detailed level in order to ensure government-wide consistency.
- One result of the too-narrow scope was an incomplete accountability framework for the transformation. The roles and responsibilities were not effectively designed, documented nor implemented as part of an overall accountability framework.
- There was no overall governance body for the TPA as a whole.
- There was limited independence of those tasked with the challenge role.
- The culture was not open to risk and did not reward speaking truth to power.
- Phoenix was not fully tested. Testing volumes and coverage were reduced in the final stages due to time and budget pressures.
There is much more in the Goss Gilroy report to explain the problems encountered in the Phoenix implementation. Perhaps the most significant finding: failure was built into the project from the start. It didn’t have a chance! Needless to say, it was not and is not yet successful. The project will exceed budget. By how much is yet to be determined. The amount of annual savings is a question mark. Will Phoenix rise from the ashes of this debacle as did the legendary Phoenix of Greek mythology? That remains to be seen.
How a Great Leader Could Have Succeeded
The Goss Gilroy Lessons Learned study provides a terrific framework for rectifying the ills of this particular flawed venture or, for that matter, planning and managing any project. The framework presented in the study includes six major lesson areas and seventeen specific lessons as shown below.
While not as granular as Project Pre-Check’s PACE reviewed in last month’s post, it still covers the essential transformation questions. Had the TPA Initiative used this Goss Gilroy framework at the beginning to address the questions it poses, the project’s chances of delivering a successful outcome would have been greatly enhanced.
Finally, Roger Martin, director of the Martin Prosperity Institute at the University of Toronto, provides some insightful advice about the roles and responsibilities of senior managers in managing transformative change. In a recent article entitled CEOs Should Stop Thinking that Execution is Somebody Else’s Job; It Is Theirs, he states “The common perception is that strategy is done at the top of the org chart, and execution is done below. It is exactly the opposite.” He goes on to suggest that “the things that happen in the activity called ‘strategy’ and the activity called ‘execution’ are identical: people are making choices about what to do and what not to do.”
According to Martin, there is an interconnected cascade of choices in any major change initiative, from the most senior management levels through to first line managers and staff. The information and engagement about the decisions being taken has to flow both ways, from senior managers to reports and back, to ensure the choices fit and reinforce one another. Martin’s advice for managing the cascade effectively?
- Make only the set of choices you are more capable of making than anyone else.
- Explain the choice that has been made and the reasoning behind it.
- Explicitly identify the next downstream choice.
- Assist in making the downstream choice, as needed.
- Commit to revisit and modify the choice based on downstream feedback.
If such a practice had been in place on the TPA initiative, clear accountabilities would have been an obvious and essential prerequisite. Speaking truth to power would have been an institutional feature. Issues and concerns would have been more eagerly voiced and more readily accepted. It’s certainly more nuanced than the command and control world that existed for most of this undertaking. But it was and is desperately needed.
Oh, and about those two questions I asked at the start of this post, I’d love to hear your thoughts. Thanks.
So, be a Great Leader. Look for and promote decision-making cascades. Use a framework like Goss Gilroy Lessons Learned or Project Pre-Check to answer the critical who, when, what, where and why questions. Put the energy up-front into laying out a route that everyone commits to follow. Keep asking those “beautiful questions” and checking your answers throughout the project. And, put these points on your checklist of things to consider so you too can deliver a successful change.
Remember, Project Pre-Check’s three building blocks cover the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework (PACE) best practices right up front so you won’t overlook these key success factors.
Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, we will post it so others can learn from your insights. Thanks
Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check – The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath – The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at firstname.lastname@example.org.