Reference no: EM132868933

Answer the following based on the case below (word count doesn't matter as long as the responses are detailed):

You are entrusted as the consultant to formulate recommendations concerning the approach the Public Services and Procurement Canada (PSPC) to adopt in order to get the suitable Customized Payroll Systems to fill the specific and common needs of PSPC as much as possible. Make a report detailing your recommendations on:

• The Information Systems acquisition strategy PSPC should adopt for the Customized Payroll Systems
• The Systems Development Life Cycle (SDLC) of the Customized Payroll Systems project
• The Systems Development Method PSPC should adopt for the Customized Payroll Systems project

Case:

Customization Payroll Disaster at the Government of Canada

The Problem

The Government of Canada had been using a legacy payroll system for over 40 years. It wanted to integrate its systems that were used to pay about 290,000 employees from 101 agencies and departments with wages of about $22 billion per year.

Payroll was processed in many different locations, often using different forms and processes. There were over 1,300 people who were considered to be payroll specialists. Their jobs included the recording and processing of payroll payments and adjustments, and correcting payroll errors. Many processes, such as calculating partial pay period amounts, were done manually. Sometimes, the same employee (particularly contract employees) were paid twice by different agencies or departments.

The IT Solution

Public Services and Procurement Canada (PSPC) wanted to save money on payroll processing by adopting one common payroll system that was more comprehensive and versatile and accessible by all departments and agencies: a modern database approach. It also intended to save money by physically consolidating the payroll processing for close to half of the departments and agencies at a new pay centre in Miramichi, New Brunswick.

The traditional systems development life cycle takes a long time. The initial proposal to replace the existing system was developed by PSPC in spring 2009. Extensive consultation took place, and a public request for proposals was issued, and the results carefully analyzed during the period June to October 2010. Over six months later, in June 2011, IBM was selected to customize the Peoplesoft commercial payroll software into a new system that PSPC called Phoenix.

It took over a year and a half (to December 2012) for the budget allocated to the Phoenix project to be approved, and another two years for the customization to be completed, which was pilot tested in June 2015. During the first two months of 2016, independent advisors (S. J. Systems and Gartner) were asked to review whether the software was ready to implement and to assess conversion plans and contingency plans at individual departments and agencies.

The PSPC oversight group, called the Public Service Management Advisory Committee, was informed and was part of the decision-making process. On February 24, 2016, 34 departments and agencies went live with Phoenix, followed by the remaining 67 on April 21, 2016.

The results were chaos.

The Expensive, Painful Results

In spring 2018, the Auditor General of Canada reported in the Building and Implementing the Phoenix Pay System report that "the Phoenix pay system is less efficient and less cost-effective than the old system, and thousands of employees have not been accurately paid or paid on time." In 2017, the Auditor General had reported that a year and a half after Phoenix launched, there were 150,000 federal employees with errors in pay that had to be corrected. Vulnerable employees, like students working on a summer contract, did not get paid for months. Some lost their year at school because they could not afford to pay tuition. Some contract employees were paid even after their contract expired and wondered about the impact on their income taxes and when they would be asked to repay the funds.

Over a thousand payroll employees were re-hired after they had originally been laid off, to help correct the errors. Over a year after the system had been implemented, the estimated amount of payroll that was outstanding and still to be corrected stood at over $520 million.

A separate satellite payroll office was established simply to handle the backlog of errors, so that the "regular" payroll could be effectively processed.

Information systems and functional departments usually set targets on quality control and accuracy. PSPC's target for payroll accuracy was 95 percent, which still would have resulted in 5 percent of employees not being paid accurately, a rather poor record. Sadly, as of August 23, 2017, only 49 percent of payroll processing met the accuracy standards of the PSPC. That meant that 51 percent of payroll payments were going out wrong, creating more errors. Fifty-one percent of 290,000 is an awful lot of errors.

As of June 2018, PSPC stated that it could take another five years and an estimated additional $500 million per year (which calculates out to a total of $2.5 billion) in programming, maintenance, and other costs to stabilize the system.

An analysis of the "why" behind the problems led to the conclusion that information given to the decision-makers about the Phoenix system was incomplete &, in some cases, inaccurate. The system was implemented before it was properly tested, and some of the testing that had been completed had shown flaws that should have been corrected before the system was implemented.