Payroll can be Trendy

“Parallel Run is SO LAST YEAR”…..This has got to be one of my favourite comments from the consultancy team this year.

In recent writing I’ve been into a hefty debate about the role and rationale for payroll for their leadership (take a read here for article 1 and article 2) and hence time for a fashionable update for the fun of the payroll or systems professional themselves.

Many of us will be familiar with the basics method of making system changes to a payroll, whether this be in the context of introducing a new HRIS, 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 2 or 3) in the old and new system side by side. This is of course the parallel run.

Look to an exact match (allowing for rounding, but sometimes to the penny), examine and correct variance until good to go. Everyone does it like that. Do they need to?

I’m hearing a growing voice that perhaps not so. But just as this year’s onesie is next year’s comfort blanket I wonder if the best of the project thinking isn’t take 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 the word 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’ve a lot to lose. You may add a (d) we’ve no clue what on earth else to do. In brief, I’ll take each on here:

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 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 2 or 3 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 3 months? How do you know? Are the volumes the same in those 3 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 for sure 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 argument 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 next year a tweak to a pay calculation or a scheme change, or even budget day’s HMRC changes next time round.

Read on and you may conclude that the extra achieved by the parallel run exact match is not necessarily worth the agro of the lots-of-extra resource needed to pile into the intensive parallel period.

We’ve got a lot to lose….
And yes, you have.
There is a lot to lose if a payroll project over-runs, is poorly managed and for sure if it ends up in a reliance upon a poorly configured payroll system. There is a lot to lose if impacts of payroll configuration choices are not understood, 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, 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 3 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 for “all scenarios”. Devise a set of tests that are “all scenarios” and work them through in an 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 a more controlled result, without 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 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 system change. Make the most of new functionality, iron out old errors, make processes slicker with 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 the case as to why payroll is notjust the click of a button” )

About the Author: Kate Wadia

Kate’s passion at work is for bridging the gap between technology and people at work, translating for HR professionals the language of HR systems and making meaningful their potential. She believes that success with people technology is through people and that people are the differentiator. Using simple techniques drawn from HR experience, project management, business psychology and analogy with everyday life, Kate presents and explains how to work well with technology and technology projects in an HR leadership role. With a background in contrasting private and public sector HR management, Kate developed her thinking in seeking for herself to understand her first HR systems project-work. Kate is currently the Managing Director of Phase 3 Consulting, offering an independent take on the HR systems market in the UK, through a network of experts and a talented, growing internal team. Kate’s guiding principle is that openness offers knowledge-sharing, credibility and trust. Incorrigibly enthusiastic and up absurdly early for a working morning, she swears that she only drinks three good coffees a day, but nobody believes her! Kate also writes as an HR Zone columnist.

Subscribe for Insight Updates
Get the latest content first.
We respect your privacy.