Development of Success Criteria for Payroll System

2358 words (9 pages) Essay

18th May 2020 Information Systems Reference this

Disclaimer: This work has been submitted by a university student. This is not an example of the work produced by our Essay Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UKEssays.com.

Executive summary

Majority of firms install technologies in HR administrative applications. While payroll processing is a routine transactional activity, harms to organizational well-being and dissatisfaction by employee can be caused by poor design and implantation of payroll system. Based on a flawed payroll system in a large and complex public sector organization in Canada, we set up success criteria for a payroll system and compared it with the implementation done by the public sector in Canada.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Find out more

Introduction

 The office of the Auditor General of Canada outlined that, in 2009, ” the Government of Canada started an initiative to replace the 40-year-old system it used to pay 290,000 employees in 101 departments and agencies.” (Office of the Auditor General of Canada, 2018, para. 1.1).

 Additionally, “Public Services and Procurement Canada was responsible for this initiative. The Department undertook two projects to support the initiative. One was to centralize pay operations for 46 departments and agencies in a new Public Service Pay Centre in Miramichi, New Brunswick. The second was to switch to a new pay software for all departments and agencies. The initiative took seven years to complete and had a budget of $310 million, including $155 million to build and implement the new pay software.” (Office of the Auditor General of Canada, 2018, para. 1.2). “The government expected the initiative to save it about $70 million a year, starting in the 2016–17 fiscal year.” (Office of the Auditor General of Canada, 2018, para. 1.3)

 “In June 2011, after a public competition, Public Services and Procurement Canada awarded a contract to IBM to help it design, customize, integrate, and implement new software to replace the government’s old pay system. The Department chose a PeopleSoft commercial pay software, which was to be customized to meet the government’s needs. The Department called this system Phoenix” (Office of the Auditor General of Canada, 2018, para. 1.5)

  “Development of Phoenix began in December 2012 and was implemented in two waves. The first wave included 34 departments and agencies on 24 February 2016, and the second wave included the remaining 67 departments and agencies on 21 April 2016. ” (Office of the Auditor General of Canada, 2018, para. 1.6)

Success Criteria

 The triple constraints of project management were designed as a guideline for project managers to plan, supervise and control a project. The Triple Constraint is defined by ‘A Guide to the Project Management Body of Knowledge(PMBOK® Guide)’ as “a framework for evaluating competing demands.” (Fahrenkrog et al., 2004) They are: time, cost and scope. These denoted key factors that not only outlined the framework of a project but also provided a guideline for project managers in making adjustments in the event that there was a problem with one or other of these constraints (Siegelaub, 2007).

 In modern time, a success criterion of a project can’t just be determined by the triple constraints. Considering one of the world’s greatest tourist attraction, the Sydney Opera House, an iconic structure recognized as a global symbol of Australia. The original project plan at 1957 was scheduled for 6 years at a cost of $7 million (Jones, 2006),  but it was formally completed in 1973 (Jones, 2006), more than double the estimated time, and having cost more than $100 million, which is more than 10 times the original cost (A brief history of the Sydney Opera House, 2003). But no one really cares anymore on how the project was managed, and almost everyone sees it as a success story.

 Which brings us to our next question: What constitutes success for a payroll system? If a project success cannot be considered by completing on schedule, staying within the budget constraints, and meeting technical performance criteria, then how should project success be defined? (Baker, Murphy and Fisher, 1997)

Functional requirements met

 As its name suggests, a payroll system produce pay checks and manage benefits payments for a company. A research conducted by Przemyslaw Lech (2013) stated “For the organisations, being subject to the study, the achievement of business and organizational goals is the determinant of perceiving a project as a success. The necessary condition for accomplishing these goals is the fulfilment of functional requirements of the project and, what is more important, alignment of the functional requirements with the business and organizational goals.”

 This is backed up by a study conducted by Morris and Hough in their study of the performance of a number of major projects. This study states that the evaluation of success criteria evolves with time and that some judgement on a project can only be made at the ed of a project. They have identified four criteria of success and one of them is “the project delivers its functionality”.

 Another research done by John Wateridge (1998) through an extensive questionnaire and subsequent in-depth interviews were conducted on the success criteria and the factors which were employed to deliver that criteria. According to John, there were major differences of opinion regarding the criteria for success and conflicting views on what is perceived as criteria. One of the six most important criteria across all respondents and all project were “achieves purpose”. 

Testing

 Testing phase of any project is very important as it will point out the defects and errors that were made during development and implementation phase. Testing a project ensure the quality of the product delivered to the customers helps in gaining their confidence.

Find out how UKEssays.com can help you!

Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.

View our services

 A study conducted by Shanin Dezdar and Ainin Sulaiman (2009) provides a comprehensive review of possible references to critical success factors (CSF) of enterprise resource planning (ERP) implementation projects. All CSFs were re-arranged into 17 distinct broad categories of CSFs. The actual analysis stages of CSFs involved reviewing the constructs in terms of frequency. By expanding the process to consider the frequency of CSFs, Shanin and Ainin can gain a better grasp of the relative importance of the factors. All CSFs were re-arranged into 17 distinct broad categories of CSFs. “Software analysis, testing and troubleshooting” is amongst the 17 distinct CSFs, with a frequency of 34% out of 95 articles.

 A research done by Fiona Fui-Hoon Nah and Janet Lee-Shang Lau and Jinghua Kuang (2001) stated “Software development, testing and troubleshooting is essential, beginning I the project phase. The overall ERP architecture should be established before deployment, taking into account the most important requirements of the implementation. This prevents reconfiguration at every stage of implementation.” They added “Troubleshooting errors is critical. The organisation implementing ERP should work well with vendors and consultants to resolve software problems. Quick response, patience, perseverance, problem solving, and firefighting capabilities are important. Vigorous and sophisticated software testing eases implementation.

Project Analysis

 Before implementing Phoenix, Phoenix executives did not ensure that it could properly process pay. Certain critical pay functions failed to be performed by the system when it was implemented, including processing requests for retroactive pay. Many of these critical flaws were known prior project implementation but was overlooked by the department. Additional faults were only discovered after Phoenix had been implemented by Public Services and Procurement Canada or other departments and agencies. (Office of the Auditor General of Canada, 2018, para. 1.31).

 To save on money and time, Phoenix’s functions were scaled back. In the spring of 2012, IBM quoted $274 million to develop and implement Phoenix. In 2009, a Phoenix development and implementation budget of $155 million was approved. There was no consideration by Public Services and Procurement Canada to appeal to the Treasury Board for a bigger budget to create and implement Phoenix. Instead, Phoenix executives collaborated with IBM to devise methods to cut down on the scope of work in order to adhere to the allocated budget. As a result: (1) Some pay processing functions were removed completely, (2) Some pay processing functions were not tested prior to launch, (3) The project schedule was shortened by condensing the time between two waves of Phoenix from seven to two months, and (4) The number of IBM and Public Services and Procurement Canada employees delegated to work on the development and implementation of the Phoenix project was reduced (Office of the Auditor General of Canada, 2018, para. 1.32).

 Overall, Phoenix executives decided to defer or eliminate more than 100 critical pay processing functions, including but not limited to the ability to: (1) Process requests for retroactive pay, such as acting pay – pay offered to an employee taking on the full responsibilities of a higher-graded job, (2) Inform employees by email of actions required to be taken on their behalf to process pay requests, and  (3) Automatically calculate certain types of pay, such as pay increments for acting appointments

 There was no evidence that the Phoenix functions that had been approved as part of the February and April 2016 implementation were in place by those dates and were fully tested before implementation (Office of the Auditor General of Canada, 2018, para. 1.36). Phoenix was also not tested as a whole system before implementation by Public Services and Procurement Canada and did not know whether it would be operational (Office of the Auditor General of Canada, 2018, para. 1.38).

Recommendation

 Public Services and Procurement Canada should ensure its project managers comprehend and communicate to involved stakeholders the consequences of changes to functionality. They should also allocate testing phase to ensure the system is fully functional and not compromised by any critical flaws or errors prior to implementation.

Conclusion

 A few success criteria and an analysis comparing the criteria to the project was given by the author reveals why it was a failed project: functional requirement not met and poor testing of the system was conducted.

 The Office of the Auditor General of Canada declared that the Phoenix project was “an incomprehensible failure of project management and oversight”. Failure to pay people on time and the right amount can cause employee dissatisfaction and can severely damage the employer branding. Apart from loss of employer reputation, the costs of rectifying the flaws of a new payroll system can run in to millions of dollars for a large organization. For the case of the Phoenix, a recent federal report in 2018 estimates the system already cost the government more than $1 billion and could require an additional $500 million a year until it is fixed. The report says the government’s best estimate is that it could take five years to stabilize the Phoenix pay system (CBC, 2018).

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: