So you’re entering the implementation phase of your new HRIS/payroll software product. How do you determine if your new HRIS/payroll system is performing as you expect it should? It’s called Parallel Testing. The below article was originally posted on compareHRIS.com.
Parallel Testing is the most complex part of HRIS/payroll implementation
The complexity of Parallel Testing is due to several factors, some of these being:
Parallel Testing is also arguably the most important part of a HRIS/payroll implementation because it provides assurances that employees’ pay is being calculated correctly.
What is Parallel Testing?
In a HRIS implementation, the essential objective of Parallel Testing is to prove that payroll is being calculated accurately. To make this assertion, a Parallel Test follows these basic steps:
Any discrepancies between the two outputs need to be explainable – and acceptable.
Even if payroll functionality is not being implemented as part of the HRIS project, some element of parallel testing is necessary to ensure that data is being passed from the new HRIS and processed by the legacy payroll accurately.
The Parallel Test phase is one of the last phases of a HRIS implementation. It must not be the first time the business rules and payroll calculator are tested so it occurs after the functional/system test phase. Furthermore, Parallel Tests are dependent upon the successful completion of Conversion Script Testing. Conversion scripts are required to “populate” the new system with the foundational data required to ready the new system for Parallel Test data input.
Planning the Parallel Test Phase: 8 Considerations
1. What pay cycles will be tested in the Parallel Test phase?
Pay cycles selected for Parallel Testing should not have an unusually high amount of input data. Examples of cycles with high volumes of input data are: annual salary review cycles and cycles coinciding with a large employee intake, such as graduate onboarding. Too much data entry risks overwhelming Parallel Test resources and thus potentially compromising time lines.
Conversely, it is important not to pick a cycle with abnormally low transaction volumes. For example, pay cycles that coincide with major national holidays such as Christmas, or Eid. Selecting such cycles will limit your ability to “test” a realistic variety and volume of transactions.
2. How many pay cycles should be Parallel Tested?
Any Parallel Test must consist of at least two pay cycles. The first Parallel Test cycle is generally marred by a lot of data input and technical errors. Essentially this cycle can be considered a “shake down”.
Two pay cycles generally provide enough information to determine whether the new system is accurately calculating pays. However, it is worth keeping inputs and outputs of a third legacy pay cycle in reserve as a contingency.
3. Will your pay cycles be consecutive?
Selecting consecutive pay cycles is advisable. Testing consecutive pay cycles provides several benefits:
If there is a compelling business reason not to test consecutive pay cycles, it is advisable to develop a risk mitigation plan. The plan will confirm how specific tests, such as the automatic incrementing of the output file number, will be tested and; whether accruals are occurring correctly across pay cycles.
4. What will be tested?
In addition to checking the calculation of pays, Parallel Testing should also check:
It is also important to consider whether it is necessary to test output files from the new system being successfully uploaded by recipients. Such tests require a lot of lead-time and liaison with the receiving parties. Therefore, it is advisable to begin planning discussions for these tests as soon in the project as possible.
Note: if payroll is not being replaced as part of the HRIS implementation, these tests will be less important as the file format will not change.
5. What verification methods will be used?
Agreement of the methodology to compare new and legacy system outputs and to identify discrepancies is required before beginning Parallel Testing. A thorough Parallel Test will involve a line-by-line comparison of every row of at least the payroll output files.
Most vendors will have tools that facilitate comparing the two output files and highlighting any differences between the two. If no tools are available, a good work around is to export both files to Excel and use V-lookup to identify differences. Once the verification methodology has been agreed upon, it is necessary to determine how to categorize each discrepancy found between the new and legacy system outputs.
6. How will discrepancies be categorized?
Below are some examples of the types of discrepancies found in Parallel Tests and how they can be categorized:
7. Who will participate in the Parallel Testing?
Many HRIS projects focus mainly on finding the above discrepancies and hence put little thought into how the data will get into the system in order to run the payroll engine and produce the output files. The second part of Parallel Testing, entering payroll input data, provides the opportunity to:
To capitalize on this opportunity, every effort should be made to facilitate the operators who will be responsible for the data entry once the system goes live, those being the people completing the requisite data entry for the Parallel Phase.
The challenge posed by this approach is that these operators will essentially double their workload during the data entry part of the Parallel Test; not only will they be entering data into the new system for Parallel Testing, they will also be required to continue to enter data into the legacy system for the current, live payroll. Thoughtful planning is needed to:
8. How will you communicate progress with the steering committee/stakeholders?
Finally, it is important to determine and plan communication meetings to the steering committee/stakeholders who ultimately need to approve the go/no-go decision for the system implementation. Recommended communication meetings are:
This article is part one in a two part series. Part two of this article will walk you through the various “sub-phases” of Parallel Testing and give some advice for maximizing the effective execution of these sub-phases. You may read part two here, Executing Parallel Testing in HRIS/Payroll Software.
About the author:
Bernadette Chandrasegaram is an independent consultant who works with clients seeking to optimize their support functions.
Copyright 2010 Bernadette Chandrasegaram, all rights reserved.