Payroll can be Trendy
“Parallel Run is SO LAST YEAR”. This has got to be one of my favourite comments from the HR technology consultancy team this year.
In recent writing, I’ve waded into a hefty debate about the role and rationale for payroll (take a read here for article 1 and article 2) and hence it is time for a fashionable update for the fun of the payroll or HR systems professional themselves.
Many of us will be familiar with the basic method of making system changes to a payroll, whether this be in the context of introducing a new HRIS service, migrating part of the organisation across on harmonisation, acquisition or tidy-up, implementing new schemes or calculations for absence, pensions, holiday/overtime, or integrating with other systems. Once the build is in place – in a “parallel” environment, we mirror and match a couple of pay periods (commonly two or three) in the old and new system side by side. This is, of course, called ‘the parallel run’.
Look to an exact match (allowing for rounding, but sometimes to the penny), examine and correct the variance until you are good to go. Everyone does it like that but do they need to?
I’m hearing a growing voice that perhaps they don’t. But just as this year’s onesie is next year’s comfort blanket, I wonder if the best of the project thinking isn’t taking a turn against this approach. One of the best of P3C consultants has argued this for years to me and delivered some sound results in major projects. But the voice is getting louder, and I’m convinced. I’ll be supporting an offer to clients that parallel runs are, yes, a bit pre-2017 for sure, and that we are wise at least to look at other options.
The option comes down to testing, testing, testing.
The testing model says we don’t seek to replicate exactly any one or more payroll periods and argues that (a) we can’t and (b) we achieve nothing in so doing. There is an instinctive (c) and we have a lot to lose. You may add a (D) that we’ve no clue what on earth else to do. In brief, I’ll take each on in the words below.
We can’t create the same…
I stress and assure, for all those knee-deep (neck deep?!) in parallel running right now, that we almost can, but the point is an important one when our payroll consultant experts can also offer you the assurance that there may be other solutions that are going to take an awful lot less resource to achieve the same end.
How are the two or three pay periods chosen? Often this is simply a snapshot from the calendar which just so happens to be part of the project working time. Of course, this could be fairly arbitrary. Are all pay scenarios going to occur in those three months? How do you know? Are the volumes the same in those three months? What about occurrences – additional pay elements, scheme changes, reports – that only occur annually? What about the things that you know academically could happen but as yet are hypothetical?
It is even true that parallel runs seem to provide a degree of known omission. For example, you may be aware that only a certain amount of history has been brought over and deep within the organisation’s pay period run there are certainly calculations occurring, including elements that draw on both historic and current data sets. And we have heard about weeks lost in a project plan to arguments over pennies.
We achieve nothing in so doing…
A qualification is that we achieve nothing extra. Given that the precise same payroll period is never going to occur again (unless you repeat your project and re-parallel-run?!) then what are we proving? The parallel run may prove that July 2016’s payroll can be ever so precisely achieved in a new system, which is just fabulous. But it is interesting to consider how much this tells us about August 2016 – and certainly what’s going to happen when new pay policy means that next year a tweak to a pay calculation or a scheme change, or even budget day’s HMRC, changes next time around.
Read on and you may conclude that the extra results achieved by the parallel run’s exact match are not necessarily worth the aggravation of the lots-of-extra resource needed to pile into the intensive parallel period.
We’ve got a lot to lose….
There is a lot to lose if a payroll project over-runs, is poorly managed and certainly if it ends up in relying upon a poorly configured payroll system. There is a lot to lose if the impacts of payroll configuration choices are not understood. Such as If a system is not sufficiently robust to accommodate your world if the end result is confusion, error or project paralysis.
None of this relates to the approach to parallel running. It relates to confidence in expertise available to you, tightly controlled change methods, and a focus on the right project priorities rather than deadlines and doing some homework in advance.
There is also a lot to lose in the amount of time and effort that is typically taking in asking a small payroll army to replicate three months of payroll running in a second environment when the same – and the Pro’s responsible for putting me up to this article would say better – result.
We’ve no clue what else to do
The sensible thing to do is to seek to strip out arbitrary effort and yet to plot a logical test of payroll system function which proves, in a more controlled way, end results you are hoping to achieve. We are proving that configuration is accurate to cater to “all scenarios”. Devise a set of tests that are “all scenarios” and work them through offline. Remember that it’s highly questionable as to whether your parallel run period really did include “all scenarios” and I can think of a few different ways to arrive at your list of those scenarios to the point of conviction.
The benefits are that you’ll see a more controlled result, without the extensive intensity of data input requirements and in a much shorter space of calendar time that is not reliant upon the timings of payroll.
It is wise to point out that, of course, the data pulled into the testing environment does have to match that in the legacy system when it comes to factors tested – a simple question of comparing apples with apples. Yet I’m hearing the suggestion that we compare apples with apples and not the whole orchard.
And finally
Accepting that net pay outcomes are to some extent a case of having to wear the uniform, by way of a concluding fashion statement, please do be wary of project-think that feels terribly pleased on recreating what was there before. This, in itself, is not an argument against the parallel run method, but it is worth a self-check.
Building the old system in a new one limits the possibility of your HR system change. Make the most of new functionality, iron out old errors, make processes slicker with the new configuration and process re-design. Just because net pay is a match doesn’t mean you have an efficient HR and payroll system. Don’t settle for the same; go for your best.
(And if you missed it, here is the case as to why payroll is not “just the click of a button” )
For more information, visit the Our People page by clicking here, or find out more about our payroll services.
