University of Ottawa

Customization Payroll Disaster at the Government of Canada

Assignment #5

Group #22
Last Name First Name Student Number

Diaz Paredes Daniela 300126507

Dowling Lilli 300105387

Guirguis George 300174455

Nielsen Amelia 300210087

Zagallai Shahd 300174444

Zhou May May 300147238

ADM 2372, Management Information Systems [P]

Dr. Alhassan Ohiomah

April 5th, 2022

Question #1: The Information Systems acquisition strategy PSPC should adopt for the
Customized Payroll Systems (6 Marks)

The information systems acquisition strategy PSPC should adopt is to lease the
application and install it on the government of Canada’s platform. Leasing will save the
organization time and money. As a matter of fact, PSPC budget requirement aligns with the
leasing strategy, PSPC wanted to save money on payroll processing by adopting one common
payroll system. As mentioned in the report, it is crucial for PSPC to save time, as originally the
traditional systems development life cycle takes a long time and extensive consultation took
place. Thus, leasing is the best and most time efficient option. Another subject to highlight is that
existing vendor software will most likely include some features that are needed by the
organization in this industry. The government of Canada is a very large organization, that may
prefer to lease pre written applications to test potencial IT solutions at lower price prior to a
major investment (ie. finding/testing what works out best within their organizations). This
leasing strategy could help avoid inefficiencies and excess costs that occurred with the
implementation and customization of the Phoenix pay system. Testing prewritten applications to
determine which characteristics are ideal for their organization will streamline the customization
process later on. Assuming they will still need a customized application, then customizing a
prewritten application would be the best option, but prioritizing testing and accuracy before
implementation will be the key to success. Additionally, the Government of Canada cannot
afford the long wait for applications to be developed in-house. Thousands of federal employees
have been impacted by the poor development and implementation of the Phoenix pay system (ie.
There were 150,000 federal employees with errors in pay that had to be corrected.). Thus, the
government of Canada must act fast and lease an application to correct the numerous issues.

Question #2: The Systems Development Life Cycle (SDLC) of the Customized Payroll Systems
project (18 Marks)

1. Investigation
The investigation stage of the SDLC is to determine the Customized Payroll System
project’s goals and to determine its feasibility. There are 3 outcomes, do nothing, modify or
enhance the existing payroll system or develop a new system. Which in this case is the Phoenix
payroll system. The goal of the Phoenix payroll system was to centralize the payroll system so
that more employees and agencies could get paid by one area, reduce cost, to reduce manual
labour for payroll specialists and to reduce pay errors such as overpayments. For example, I
work at CBSA and although I am from another agency, I get paid from PSPC’s Phoenix system
(I am in fact one of the summer students who did not get paid for months). Based on the
information that the budget took over a year to be approved, two years for customization by IBM
to be completed and only tested for less than a year, economic, technical and behavioral
feasibility did not seem like an issue before the implementation, but soon was a problem after.
The government laid off thousands of payroll employees and were shortly re-hired due to the
outcome of errors in the system. The outcome of the project was more ineffective than their old
payroll system, and resulted in errors which would need to be corrected manually, especially
with hundreds and thousands of employees relying on the Phoenix system, the errors overtime
overloaded the amount of payroll employees available.

2. Analysis
The goal of this project again is to centralize the payroll system so that more employees
and agencies could get paid by one area, reduce cost, to reduce manual labour for payroll
specialists and to reduce pay errors such as overpayments. Since the old payroll system is done
manually, the IS made by IBM would replace it with payroll software.
During the analysis stage of SDLC, it is important to do a buy vs. build analysis, this takes into
effect the cost, budget, controls, the problem, timeline, risks and opportunity costs.
Build Buy

- Current Legacy payroll system. - Third party from IBM.

- Enhancing a system that has already
been used for 40 years.
- High maintenance and manual labour
- Cheaper in terms of cost
- Lack of internal knowledge to create
IT systems, most softwares is
third-parties for the government.
Furthermore creating process diagrams showing the Legacy system vs the Phoenix pay system.
- Erasing a 40 yr old system that has
been working for the government.
- Less manual labour.
- System that is able to track payroll for
multiple agencies and departments.
- Expensive (high cost)
- Low maintenance
- Risk of lack of control for
implementation
- Reduce employee pay towards payroll
staff.

3. Design
The Public Services and Procurement Canada (PSPC) wanted to adopt a modern database
approach that met all their goals and was efficient. Before implementing this system, they have
already established their problems in their current payroll system. Their problems with their
current payroll system was that they were spending too much money on their system because
they hired over 1,300 payroll specialists. As well as it definitely was not time efficient and
effective because they were calculating partial pay period amounts all manually for 101
departments in the Government of Canada.
The architecture of the Phoenix project is to collect the data of all the 290,000 employees
in the government and calculate their partial pay period. The desired features in this IS for
payroll is to save money such as not having to hire payroll specialists to calculate payroll
manually and replacing them with a new IS, making an IS that calculates all employees pay and
sending them their money and making a system that is efficient and easy to use. The IS should be
able to collect employees’ data on their annual salary or their amount of hours worked to find out
the amount they should be paid Biweekly or the payroll system they have in place. The IS design
should take over the jobs of 1,300 payroll specialists that the government hired. The design of
the IS should be able to manage everything that has to do with the processing of paying
employees in all departments and filing employment taxes.
The layout of the IS should be easy for the employees to use to find all the information
that they need such as the amount they are being paid and their T4 when they are ready to file
their taxes. When layout is done, the government should get a couple employees and create a
focus group with different generations and see if they are able to use the new Payroll system with
some instructions. The focus group is user interface, seeing how the employees interact with the
new IS and how they respond to the new Payroll system.

4. Programming and Testing

Programming
The programming stage is the part where IBM starts to create the IS with the design they
have created that meets all the requirements that the Government of Canada had given them.
This is the actual writing of the IS where everything comes together and builds the IS according
to the designs and outlined specifications. With an IS that is for 101 departments, it is necessary
that more than one IS developer is writing this system. Having a team of developers will make
creating the IS quicker and easier because there will be more people working and thinking
together to create the best IS for the government’s payroll issues. The team of developers are
responsible for the control and use of the government’s employee data including the database or
the library of application files they have to offer.
During the programming stage, the IT specialists need to choose what type of software or
style of coding to create the IS efficiently. This stage is the longest stage, it took IBM around
three and a half years to get the Phoenix project approved and customized to the government’s
liking. The IT specialists will have to follow the government’s coding standards and guidelines.
When finishing up with the developing the new Payroll system for the government, the
developers should be checking off all their requirements. This is important to do before testing
the system because it will give the developers an idea of what is missing from the system and
what the developers have done correctly. By having a checklist, it will ensure that they will not
need more tweaking after the testing stage. To conclude, the check/requirements needed to be
implemented in the system to be able to be seen as flawlessly are as follows:
- Will it reduce the amount of money the government uses just for their employees’
payroll?
- Is it easier and efficient to use the new system throughout all ages? Is it user
friendly?
- Does the system give the correct information and wages to the employees?
- Does the system work flawlessly?
- Does the new payroll system contain adequate controls?
 - Does the system give the correct employment tax documents?
- Can the system work correctly without much assistance from the developers?
- Does the system calculate the employees’ pay based on the factors of the time
they work, their hourly wage or salary and their vacation or holiday pay during
the specified time period?
Testing
Before implementing their new IS for payroll, they did a pilot test in June 2015. Pilot
testing in this situation is a rehearsal of implementing the system, allowing the IBM to test their
Phoenix project with a group of users to test the IS before the implementation. As well as
identifying the issues in the IS before launching and using it for all departments. For this
situation, the testing stage is necessary, it will help the government have an idea of how their
new Payroll system will be and the type of data they need to be collected to get the IS to be used
to its fullest potential.
Testing an IS is mandatory because it ensures that each function in the system works
flawlessly. For example, the IS should be able to do exactly or more than the payroll specialists
do manually. The IS should be able to collect data on all 290,00 employees from the 101
agencies and departments in the government. The IS needs to be able to know what each
employee is paid salary wise or hourly which comes to about $22 billion per year. The IS should
be able to calculate the employee’s pay and send their money directly to the accounts as well as
giving them an electronic document showing what they received. After implementing these
factors, the Phoenix project should be a flawless Payroll system for the Government of Canada.
After the testing, IBM took an extra two months to make sure the IS was ready to
implement and to assess conversion plans and contingency plans at individual departments and
agencies. This time was used to fix any issues that they were aware of when testing the IS. Also,
listening to their employees and employers on all the things that they perceive as an issue.
Having feedback during this time from people that are going to be using the IS daily is
mandatory because they need to be able to understand how to use it. Gaining feedback can also
be overbearing or overwhelming because in a tight schedule, the feedback can make the process
much longer than needed. This step is very mandatory for the Government of Canada because
they are using the direct implementation method and if the IS does not have a good performance
then it can cause the government more problems than good results.

5. Implementation
The Implementation method the Government of Canada used to place their new Payroll
system was direct. The direct implementation method is when the old system is completely
stopped right as the new system is implemented. For this situation, creating the IS was pretty
rushed, they wasted no time to create a new system that met their needs and goals. Their
implementation timeline was certainly short as well, after a year and a half of creating the system
and it being approved they were all ready to replace their old Payroll system. Even though it took
another two years to customize the system to the needs of the government, they only tested their
new system for a couple months. When the Payroll system was customized and approved, they
went straight into their new system. When implementing the system with the direct
implementation method, the risks are much greater and it is seen in the Phoenix project. The
risks that they have endured was long delays on when errors occur, the payroll specialists lose
their jobs because they are replaced by an IS and their employees are unfamiliar with the new
Payroll system. For example, the employees in the Government of Canada might not understand
or know how to find their partial pay period amounts. During the implementation stage of SDLC,
the government should be training their employees how to use their new system to make sure
they are getting paid correctly, finding their T4 to do their taxes and other information that will
make the employee’s life easier.

6. Operations & Maintenance

The Systems Development Life Cycle does not end after the IS is implemented into the
government’s payroll software. This part of the cycle is to modify the IS according to the user’s
requirements and feedback. It involves performing more changes and correcting all the technical
errors that have surfaced throughout the implementation stage of the cycle. Also, during this part
of the cycle should be the time to upgrade the IS so it can be able to change and meet the goals
that need to be met by the government or organization at hand. The Operations and maintenance
stage will always recur until a completely new system is to be implemented. There will always
be something to fix or change within the system. These changes can be bugs, launching a new
feature, fixing issues and updating the IS so it is up to date with the latest technology. To stay
with the newest technology, a new Development Cycle can be launched to change the IS or
implement better technology to make the IS stronger and efficient.
The situation with the Government of Canada’s payroll system, after the implementation
of the IS they stated that the results were chaos. “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.” (Ohimah, 2022) This was stated after the implementation of the
Phoenix project that IBM created. Not only does this mean that they need to fix the payroll
system but they also have to correct all the errors that were created because of the new payroll
system. The estimated amount of payroll that needs to be corrected was over $520 million which
is a lot of money to be miscounted. These errors will be hard to fix because it will cause the
government to spend more money on fixing the issues and they will most likely lose employees
because they are not receiving the correct payment or not getting them in a timely manner.
The types of maintenance that the Phoenix project needs are corrective, perfective and
preventive. The maintenance necessary will be that the government will have to reevaluate the
payroll system and if the system that already had the Payroll Specialists were the right approach
from the beginning. The second thing would be to reimburse all the government employees that
received their paychecks wrong or not at all. Also The third thing is to fix the Phoenix project
that will do its job flawlessly without any complications. Also, the IT Specialists should listen to
the government employees and everyone that uses the IS for their feedback on what they found
are the IS’ weaknesses and strengths. These points are very important to implement in the
maintenance stage of the cycle because it will either fix the IS or make the government lose even
more money.

Question #3: The Systems Development Method PSPC should adopt for the Customized Payroll
Systems project (6 Marks)

There are five systems development methods: (1) waterfall, (2) agile software
development, (3) joint application design (JAD), (4) rapid application development (RAD), and
(5) end-user development.
Public Services and Procurement Canada (PSPC) should adopt the agile method. To
begin, Ohiomah (2022) described agile methodology as “focusing on early and continuous
delivery of useful system or software components meeting bare minimum requirements.” In
other words, this method breaks the project into key tasks and implements the system in smaller
chunks. So, instead of waiting several years for a finished project to be implemented, the agile
method is quicker due to iterative development. Thus, this makes the project less risky. And
collecting feedback after each implementation is another advantage. As a result, this allows for
improvements before the next round of module implementation. Thus, there is more flexibility
with the agile method. Essentially, this method tests integration after finishing each module,
which provides visibility into the process and results in a higher success rate. For PSPC, they
began the process for a new payroll system “in spring 2009,” and all “departments and agencies
went live with Phoenix … on April 21, 2016.” Thus, this project took seven years to complete
and implement. As a result, “the results were chaos.” In seven years, a lot can change, such as
technology and user requirements. In addition, it is stated in this case that “the system was
implemented before it was properly tested.” The agile method would solve this issue as iterations
ensure that projects “achieve rapid feedback and acceptance,” (Ohiomah, 2022). However,
successful agile development can be challenging, so PSPC needs constant communication,
development, and testing.
The waterfall method is not appropriate for the customized payroll systems at PSPC
because PSPC cannot know all of the requirements beforehand. Also, since each stage is
sequential, the method does not let you go backwards. Since their previous system life cycle took
seven years to complete, not being able to go back to previous phases could significantly impact
the success of the project. Moreover, this method “assumes that requirements do not change over
time,” (Ohiomah, 2022). However, this is not an accurate assumption, as many things can change
over time, especially over seven years. In addition, under this method, their pay system would
have failed. For instance, to fix the Phoenix system, “PSPC stated that it could take another five
years and an estimated additional $500 million.” Therefore, the waterfall method is not
appropriate for the payroll system at PSPC due to the method’s poor and inaccurate assumptions.
The joint application design method is not appropriate for the customized payroll systems
at PSPC because there are too many system analysts and users. For example, the payroll system
was “used to pay about 290,000 employees,” and “there were over 1,300 people who were
considered to be payroll specialists.” Due to JAD requiring “group meetings of systems analysts
and users,” to “define and agree on systems requirements,” this would not be feasible (Ohiomah,
2022). Attendance from all members would be difficult. And there would likely be more group
conflicts in a large group. Therefore, the joint application design method is not appropriate for
the payroll system at PSPC due to a large number of participants.
The rapid application development method is not appropriate for the customized payroll
systems at PSPC because of prototypes. For illustration, in 2020, Rainer, Prince,
Splettstoesser-Hogeterp, Sanchez-Rodriguez, and Ebrahimi, noted that prototyping “is not
practical with large numbers of users.” Since the Government of Canada has many payroll
system users, this would not be ideal. Moreover, the RAD method does not produce the final
system. Instead, prototypes “look and act like the desired system,” (Ohiomah, 2022). And Rainer
et al. (2020) stated that users might grow a connection with the prototypes and not want to use
the final system. However, this causes issues since the prototypes are created quickly. So the
quality may be poor. Furthermore, the RAD method is inappropriate, as it also goes through the
JAD approach. Therefore, the rapid application development method is not appropriate for the
payroll system at PSPC due to the use of prototypes.
The end-user development method is not appropriate for the customized payroll systems
at PSPC because of the lack of development expertise. For example, to fix the Phoenix system,
they must spend “$500 million per year in programming, maintenance, and other costs to
stabilize the system.” Thus, there is a significant need for IT support, which is not part of this
method, as “end users build and maintain the system,” (Ohiomah, 2022). Additionally, the chaos
from the Phoenix system negatively affected “150,000 federal employees,” and spanned
“employees from 101 agencies and departments.” Ohiomah (2022) explained that this method
may not be “consistent with organizational goals.” Thus, PSPC needs to fix their payroll system
and ensure it aligns with its organization’s goals. Therefore, the end-user development method is
not appropriate for the payroll system at PSPC due to the lack of IT expertise and organizational
goal alignment.
Therefore, the PSPC should adopt the agile method for their customized payroll system
project. This method ensures the continuous delivery of useful features of the final system. And
by using iteration development, they will experience a higher success rate from more visibility
and flexibility. However, the following methods are not appropriate; waterfall, JAD, RAD, and
end-user development. The waterfall method has poor assumptions, affecting the success rate.
Second, the JAD method would involve too many analysts and users. Third, the RAD method
uses prototypes. Prototypes are not suitable for large numbers of groups. Finally, the end-user
development method lacks IT expertise and may not align with organizational goals.
 References

Ohiomah, A. (2022). Week 10 - Acquiring IS [PDF slides]. Retrieved from

https://uottawa.brightspace.com/d2l/le/content/276898/viewContent/4426103/View

Rainer, K., Prince, B., Splettstoesser-Hogeterp, I., Sanchez-Rodriguez, C., Ebrahimi, S. 2020.
Introduction to Information Systems. (5th ed.). John Wiley & Sons.

What is SDLC? Phases of Software Development & Models. phoenixNAP Blog. (2022, February
9). Retrieved April 5, 2022, from
https://phoenixnap.com/blog/software-development-life-cycle

[PDF] System Development Life Cycle Methodology. Chapter 2 - Free Download PDF. (n.d.).
Retrieved April 5, 2022, from
https://silo.tips/download/system-development-life-cycle-methodology-chapter-2

7 phases of the System Development Life Cycle Guide. 7 Phases of the System Development Life
Cycle Guide. (n.d.). Retrieved April 5, 2022, from
https://www.clouddefense.ai/blog/system-development-life-cycle#:~:text=What%20Are%2
0the%207%20Phases,testing%2C%20implementation%2C%20and%20maintenance.

Innovative architects. SDLC: Seven Phases of the System Development Life Cycle. (n.d.).
Retrieved April 5, 2022, from
https://www.innovativearchitects.com/KnowledgeCenter/basic-IT-systems/system-develop
ment-life-cycle.aspx
Personal Ethics Statement Concerning Telfer School Assignments

Group Assignment:
By signing this Statement, I am attesting to the fact that I have reviewed not only my own work,
but the work of my colleagues, in its entirety.

I attest to the fact that my own work in this project meets all of the rules of quotation and
referencing in use at the Telfer School of Management at the University of Ottawa, as well as
adheres to the fraud policies as outlined in the Academic Regulations in the University’s
Undergraduate Studies Calendar Academic Fraud Webpage.

To the best of my knowledge, I also believe that each of my group colleagues has also met the
rules of quotation and referencing aforementioned in this Statement.

I understand that if my group assignment is submitted without a signed copy of this Personal
Ethics Statement from each group member, it will be interpreted by the Telfer School that the
missing student(s) signature is confirmation of non-participation of the aforementioned
student(s) in the required work.

Lilli Dowling 2022-04-03 M.Z 2022-04-03

Signature Date Signature Date

Dowling, Lilli 300105387 Zhou, May May 300147238

Last Name, First Name Student Number Last Name, First Name Student Number

Amelia Nielsen 2022-04-03 Shahd Zagallai 2022-04-03

Signature Date Signature Date

Amelia, Nielsen 300210087 Zagallai, Shahd 300147777

Last Name, First Name Student Number Last Name, First Name Student Number

Daniela Diaz 2022-04-03 George Guirguis 2022-04-03

Signature Date Signature Date

Daniela Diaz 300126507 George Guirguis 300174455

Last Name, First Name Student Number Last Name, First Name Student Number