Ready for Lift Off

Many months have gone by since you first decided to replace your payroll system. Since then you have been through the lengthy process of defining your requirements, short-listing suppliers and making your final selection. It was hard work and time-consuming, but nothing in comparison with the next phase - implementation.

What is involved in implementing a new payroll system? How extensively should it be tested before it is used live? What pitfalls are to be avoided? The guidance in this article makes the assumption that the payroll department has some sort of external technical help, either in the form of a dedicated IT department, or an internal computer specialist, or a consultant provided by the supplier of the system.

Project team
The starting point for a successful implementation is getting the project team right. An effective project team is made up of people with the necessary skills to deliver the end-product. It will not necessarily be the same cross-functional team that specified the system requirements and chose the system. Instead, the implementation team may be limited to members of the IT and payroll departments, plus HR if it is an integrated system. Individuals from other dependent departments may be drafted in when required. Depending on the terms of the contract, the supplier may provide a consultant to work with the project team in various stages of implementation. Above all, commitment is the essential quality of all project team members as the amount of time involved, not necessarily during office hours, and in addition to their regular jobs, will be considerable.

The project team's first job is to identify each stage of implementation, identify resources and set a timetable. The key stages are to:

• create a test environment and load up the new system
• define the work required to turn the system as supplied into the system as required
• build and test the enhancements and interfaces
• convert the data from the old system to the new and test for accuracy
• run the new system in parallel with the old
• carry out extensive testing of the new system before "going live".

Testing
Every stage of the implementation process involves testing. The tests take different forms as the implementation progresses and each must be completed satisfactorily before moving to the next stage. The different types of tests are:

Unit testing
This is the lowest level of testing and is likely to be performed by the technical members of the project team with guidance from the supplier. A "unit" is any identifiable component or function of the system, e.g. a report, a data interface with another system, a database procedure, a payroll calculation formula - anything that, in conjunction with all of the other units, is necessary for the entire system to operate correctly.

System testing
Once all of the "units" of the system have been tested in isolation, the next stage is to check that they all work together as a whole, by repeatedly running through the entire payroll process from start to finish. The tests should examine both the functionality of the system and the non-functional aspects of the system such as performance, capacity, usability and reliability. System testing should also be conducted by technical staff.

The payroll members of the project team may be called on to prepare the test cases that will be used. This is a demanding, time-consuming and imaginative job that requires dummy employees to be created so that every conceivable payroll situation can be applied to them, realistic or otherwise. Then the expected results for each test case must be calculated, providing lots of "gross to net" practice! If the results of the system tests do not match the expected results, the reasons for the discrepancy must be discovered and corrected.

Acceptance testing
Once the technical team is happy that the system is operating correctly within the company's IT environment and, as far as they can tell, is giving accurate results, it is the users' turn to test the new payroll system. This testing phase should be managed by the user department, although some technical resources, including a consultant from the supplier, should be on hand to help if problems are encountered. It will eventually be the payroll manager's job to "accept" the system as being fully functional and accurate, and it is the objective of acceptance testing to provide this level of confidence.

Although training users to use the new system is a separate and essential exercise, acceptance testing may be the first opportunity that some payroll staff have to get hands-on experience of the new system. If possible, everyone in the department should be involved in some way in acceptance testing.

As with system testing, the process involves a series of full payroll runs for a limited number of employees. Again, a wide variety of scenarios are tested and compared with the pre-prepared expected results. Few problems should be found if system testing has been performed thoroughly but, as more users may be involved in preparing the tests, previously untested situations may be identified.

Parallel running
This is the final testing phase and involves running live data on the old and new systems in tandem, or at separate times, to see if they give identical, or acceptably similar, results. At least two full acceptable runs should have been completed before using the output from the new system to pay employees.

Parallel running is an essential process and, depending on the methods used, can involve a lot of time and work. For example, should payment details be input separately into both systems, or should the older system be prepared and the pay data transferred electronically into the new system? How, and to what extent, will the output from the two systems be checked to find any discrepancies? Can the existing staff cope with the work, or should temporary staff be involved?

Training
Depending on the size of the implementation, training of users can be delivered on the supplier's premises, or locally by the consultant, or by using a trained member of the project team. Although the acceptance testing and parallel running phases provide hands-on experience, there should also be formal training in all aspects of the system. Training should not be given too early, otherwise users may have forgotten what they learned by the time the system goes live.

Pitfalls
Based on the experience of a number of system developers, the following traps should be avoided!

• not having involved the payroll department closely in the original system specification and selection
• using a project team that does not include the payroll manager, and not involving the payroll department closely at every stage
• little or no access to the supplier's consultant during implementation, or failing to make good use the consultant's services
• setting an unrealistic implementation timetable, and not contingency planning
• failing to identify and accommodate the system and human interfaces on which the payroll depends
• underestimating the resources needed for each phase of testing
• putting too little effort into unit and system testing, leaving the users to find all the problems
• not involving everyone in the payroll department in acceptance testing and parallel running
• limiting the range of scenarios to be tested
• training users too early so they forget everything.