Reference no: EM133054199

Case: How to Get Change Wrong: The Phoenix Payroll Fiasco

Questions:

In 2010, Canada's Public Services department launched a request for proposal for a new federal payroll system. The system was intended to replace a host of different systems being used in 101 departments, impacting 300,000 workers. The new system was estimated to cost $186 million, and the plan was to ultimately reduce and centralize payroll staff and save the government money associated with having disparate systems that were difficult to maintain. By 2016, despite problems in early testing, this new system was being rolled out to an initial 34 departments representing 120,000 employees. Problems occurred almost immediately, with roughly 30 percent of employees being paid incorrectly. Between 2016 and 2018, even as the rollout and implementation expanded to other departments, these problems continued. Some workers were paid too much, but many were paid too little. Some were not paid at all for months at a time and needed to be issued unconventional emergency support payments by their managers just to meet their most basic expenses. Other people who were being unpaid or underpaid ended up losing their cars, homes, places in university classes, and other critical resources when they were unable to pay the associated bills. The stress these struggles created also negatively impacted health and family well-being. At least one suicide was directly linked to a mortgage foreclosure caused by the Phoenix payroll fiasco. After four years of struggles, tens of millions in costs overruns, numerous legal actions and financial settlements with affected workers, and many attempted fixes, the project was finally deemed a complete failure in 2020 and the federal government is once again seeking a solution, starting from scratch. The frustrating part of the Phoenix fiasco is that managers already knew how to do better. The software development life cycle (SDLC) is a well-developed framework that provides specific guidance for each stage of projects that involve technological change. The first phase, requirements analysis, involves collecting detailed information from end users about their needs. There is evidence that this was not done adequately since the biggest problems with Phoenix revolved around non-standard forms of pay such as disability and maternity leaves and student internships. Even when requirements were appropriately documented, they were not then respected in the subsequent design phase of the project, when the application was actually built. Executives attempted to control cost and time overruns in the design phase by unilaterally removing more than 100 of the system's 984 pay-processing functions. The end users who had helped develop the system requirements were not consulted on these decisions. The leaders responsible for the initiative also ignored extremely well-known best practices related to the systems testing and implementation phases. For example, an early test of 81 payprocessing functions showed that fully 20 percent failed the test. These failures were often ignored, and even when they were addressed and allegedly fixed, they were never re-tested. Astonishingly, the system was also never holistically tested in its entirety! Furthermore, the software vendor (IBM) had asked the government to roll the system out to a single department first and had recommended they deliver extensive end-user training. This advice was ignored. Not only was the initial rollout much broader, involving over 30 departments, but the old system was actually shut down when the new one launched. (It is an established best practice to run two systems in parallel until the stability of the new system is confirmed.) This was done despite the fact that testing had revealed significant security weaknesses that would not be addressed for at least nine months. Over a dozen serious privacy breaches were officially documented during that nine-month period. Making a terrible situation worse, training was inadequate and ill timed, leaving many workers unsure and struggling to use the components of the system that did work. A formal audit of the project rollout concluded that executives had received clear and unambiguous signs that Phoenix was not ready to be implemented and that they chose to proceed anyway. Why would they do that? Numerous explanations have been put forth, including that they had significant financial bonuses associated with timely rollouts, that decisions were often made in group settings that lessened individual accountability and encouraged shifts in perception of risk, and that there was broad-based denial about the potential for seriously negative outcomes. All of these reasons make sense, but none fully explain why well-known best practices were simply ignored at almost every phase of the SDLC. Organizational change tools are only functional when appropriately used.

1. Consider what you have learned in the modules on organizational change, leadership, groups and teams, motivation, communication, and decision-making. For each of these 6 modules identify one theory or key concept that is especially relevant to understanding why this change initiative failed. Explain your reasoning for each one in 2-3 sentences. The goal is to show that you can connect abstract concepts from the textbook to real-world situations.

2. Applying what you have learned about motivation, incentives, and organizational change, what would you have done differently in order to get a better outcome? You may find it helpful to use the Kotter or SDLC model to refer to things you would do differently at each step in the process. Remember to include information about how both project leaders and end-users of the system are evaluated and incented.