In our 12-part series, Kate Wadia – Managing Director at Phase 3 Consulting – guides the HR professional through how to navigate, succeed and lead with HR tech project-work. From the inception of the business case to the handover into BAU, we’ll follow an indicative project timeframe to explain the way and the why of a project step-by- step, to give you a full toolkit of practical points, a deciphering of definitions and the top tips to get results important to HR and the wider business.

Last time we did the talking part of getting it out there in training and communications planning; this time we’re doing the doing. The practicalities and realities of a go-live moment is another of the stages of HR technology implementation that’s kept rather under wraps.

Here I will explain what to expect when you go live, how it works and the choices to be looking out for that help to manage that transition milestone effectively.

Go-live is two things:

1. A practical step – something has to be done with the technology to make it available to your users
2. A risk point – making the new technology live could turn risks into issues

Risks are around how the technology works, but also the organisational and cultural factors associated with the change. Improve your risk management by preparing the ground well with the guidance that I’ve offered throughout each stage of the technology journey.

For example, notice in the advice that follows how:

• The right preparation of data (part 4) impacts first impressions and support load
• The right project method (part 5) makes sure that the go-live risks are assessed
• The right acceptance testing (part 8) is a way to protect against deal-breaker experiences
• The right engagement activities (part 9) will optimise live system usage

Don’t wait for your own organisation’s go-live milestone to appreciate how the end-to-end stages of HR systems project-work really do rely upon one another. A continuity of vigilance through all of the project stages, with the right advice from the start at system selection and kick-off, must be your aim.

The Moment: what to expect and how it works

When a project team makes a web-based system live, this can imply different things depending on the plan made. This rests to a large extent upon which environments, instances or applications that you have had available and how access to those has been managed to date.

These tasks could be on the to-do list for that transition point:

• Activate security profiles. Turn on the availability of sets of functions ready for the associated sets of users.
• Switch around system settings to make process live. For example, turn on RTI functionality or check boxes to activate email or task workflow.
• Publish URL links to users, pointing them to the new live system. Put these links in available places on a permanent basis.
• Manage a cut-off point for entry of data from old systems to new. I believe this is the hardest part of what’s to be done practically in going live, where your careful choices  can make the greatest difference
• In a small number of remaining cases where systems are not web-based, such as very limited local applications, going live may require a download or a disc installation by the IT team onto machines

Spelling out what happens when technology goes live shows that the practical steps in themselves are unlikely to be so terribly complex, although they can be intricate. Going live smoothly is much more about what could happen next….

Key Question: what is the difference between an environment, application, instance, and installation? Which and how many of each do you need?

The environment usually means the combination of hardware and software application. An application is simply a program with a specific purpose. Each time a program runs it is a new instance. Only on-premise solutions need an install which is simply the installation process-run.  

In taking HR systems live therefore, whilst you may find these terms bandied loosely around (about which I would not worry!) it is most correct to say environment for hosted web-based systems, and it’s a safe bet for cloud solutions too. On-premise or for local applications, install is quite right.

Much more important is which and how many to use in your project. For sure you will need some kind of test (or sandbox) version as well as live (or production). This may become live at the milestone moment. Most likely you need to retain at least one test environment during BAU.

Advisable is to have a third space to develop, play around and do any other non-live work that could interfere with pure, like-for-like test comparisons.

If you’re feeling greedy and your product suppliers will offer it, then it’s even better to benefit from a separate training environment and/or a reporting environment too. The latter is because report-runs place quite a processing load upon your system.

The question of the value of each – if you have a choice – are best answered by IT professionals, with consideration for any extra costs you face.

Risk Management: the rub of going live

It is helpful to look at two types of risk as the HR system becomes available to users.

Firstly there are the technical risks. I alert you to those of performance load and to change control. Secondly there are organisational risks in the people dynamics associated with any change. The advice that may be most valuable with respect to culture and behaviour change in your implementation project is how to optimise and encourage use of the system.

In part 5 I described how project management and method can work for HR. One of the key assurances you’ll derive from sound method, even if simple, is knowing that you have a good grasp on risk throughout. Identified, or worse-still unidentified risk, translating into a live issue is the rub of the go-live moment.

• Performance of the system is the responsibility of your IT hosts, whether those are internal or external. Load upon the technology, due to the number of concurrent active users and processes, is a key distinction between the moment before and after go-live. This can to a degree be stress-tested beforehand if your hosts have concerns and should after be monitored. This is one reason to choose a ‘soft launch’ or phased approach.
• Change control again is about method. Unless you have supported transition into real system use with the establishing of watertight method for controlling further system amends then it is very hard later to redeem that. If you don’t have internal best practices on change control to comply with, then seek some advice about keeping a simple dialogue and log of system configuration changes made in an ordered way. You will also wish to have clear records about actions taken in response to support queries and of ‘known issues’.

What are the choices to make to help to reduce these practical risks?

The key choices are all about timing. That is both timing to make the new system available to users and timing to manage data.

Timing to make the new system available relates to both performance load (see above) and to managing support and the people factors.

Tip: You may be surprisingly close to a live state anyway. A working environment may be live in all respects except for the publishing of a link to direct users that it’s there and where to find it. Or you may simply be changing your use of a test application to being called live. I think that it’s reassuring to be aware of how limited the technical task of going live could in your context be, taking away one fear-factor about this key milestone.

Some organisations wish to create a ‘big bang’ launch moment, which has clear advantages in creating awareness and noise around the system as well as some obvious efficiencies. A big bang will get you to full system benefits quickest if it’s well-managed and if you can provide the practical and people support.

Otherwise you can opt to phase your release. Phased approaches are styled in different ways, such as pilots, phased roll-out or ‘soft launch’. With partial release of technology like this, you give access to a limited set of users and you may also give limited functions to those users. This offers a rather more cautious way to check out any potential that performance or organisation cannot cope well.

Tip:  The descriptions here show that an apparent choice between ‘big bang’ and phased implementation is not a binary one. That means that you can afford to feel less weight of the decision-making here. Consider cutting and dicing how you make the technology available in different ways based on the types of users, where they sit in the organisation, as well as the types of use they’ll make of the tech. For example, releasing a limited set of functions to all users would to some be called a ‘big bang’, but the same result others think of as a phased stage 1. It doesn’t really matter what you call it!

Secondly you must plan how to time your data cut-offs and migrations. Consider two types of data:

• Some data is variable and has a time-based characteristic. Super-users and functional professionals must enter payroll data, new starter and leaver information into the old system until a determined date and then into the new. Have a read about parallel-running. Take compliance xceptionally seriously on this point.
• Some data is continuing and is to be migrated across. Less mission critical to the smoothness of going live perhaps, but to be part of that plan. Remember that data that is apparently in poor shape (and remember the homework of part 4 on data) makes for seriously bad press when you do go live.

You can plan for hard cut-off points and one-time migrations or you can require dual-entry into both systems. Choosing a cut-off point within a payroll cycle can be tight and dual-entry is less sensitive to time. But it does require a doubling of effort and resource, so consider your control versus your volume. Where there is doubling of effort at any project stage, back-fill into old operations and make sure that the users of the future get to grips with project and new-system ways of working.

Key Question: when is it wise to pull the plug?

This is a brave question to address and a far braver decision to make. It is easy for me to hazard that it’s taken less often than it should be by project leads. Here is an objective view:

I would seriously consider pulling the plug if there are questions around data security. Let’s call this a red stop-sign issue.

I flag as amber on whether to suspend release questions around performance load and unexpected changes to the user experience (how the system appears to be working). In these cases you will wish to assess quite how bad an experience there is, or there is set to be. How ready are you to cope? Mitigate with helpful messages and extra monitoring.

Green for proceeding with caution is the data. Data needs to be good, but it rarely needs to be perfect. Likewise the user experience should be as expected, but it does not need to be perfect! I have seen client organisations threaten to stop all of their good works because of a small system defect or configuration error not yet resolved.

Please do make your decision based on your own understanding of the implications, examining the contextual detail and seeking advice on that detail. 

Planning for Optimum Uptake

Great new technologies offer little benefit if no-one uses them. Make deliberate plans about how you’ll make sure that your users make the most of what is becoming available. Avoid a scenario whereby the HR teams have to support users of the new system as well as significant numbers of those avoiding it or working around process created.

In part 9, all about training, communications and engagement, I looked at some of the considerations of culture and managing change. I promised a list of ideas for tactics to engage users and promote the message. Think of these as the desirables of communication strategy in HR systems projects, as opposed to those I suggest in part 11 ahead about ensuring adequate support.

Use carrots and sticks too!

Helpful carrots could include:

• Focussing on holidays. Everyone loves holidays. Make holiday-booking a part of any early delivery. Combine with new sickness reporting to improve compliance with the latter.
• Showing clear offsets for any extra effort or direct systems interaction you require of managers or team members. Are you reducing other types of admin load for them? Are you getting your bit done quicker?
• Offer new information. Business intelligence, dashboards, great data visualisation or access to real-time information are often the most winning ways to persuade of the value of new systems, particularly at more senior levels.
• Small-scale fun with direct reward for system use can work well. Target an area of compliance with the greatest business benefit, combined with widest applicability. Or go for the most user log-ins, which could be amongst a team.

Meanwhile sticks are most effective with pay. If you want employees to access e-slips only then simply offer no other means of getting a payslip otherwise. Improve submission of variable pay elements by moving to the month later any temporary pay not entered in time.

Sometimes it is worth including use of HR technology in performance management frameworks.

Drive uptake with desirables of communication!

• FAQs – those that focus on the employee’s main interest (tips on this in part 9)
• System messaging and/or commandeering ‘company news’ features for this
• Payslip messaging
• Some gloss factor! Postcards or credit-card size is nice. Use slide decks too.
• Prominent on-screen advice to save your systems administration team pain (e.g. avoiding password resets or where to find more help)
• User-defined system text fields
• YouTube videos – video formats are great, but do consider the degree of publicity
• Information reaching potential new recruits in starter packs, onboarding and induction
• Help points in all formats, including a person – add reassurance factors into your plan
• Webinar sessions – aim for interaction. Add other material people can access at home on the sofa
• Publish to shared organisational repositories – conversations within collaboration tools, shared libraries, intranets or chat forums
• Roadshows – which could be virtual or geographical

Why not also ask your product supplier what they can offer? The digital design skill and content ideas of these companies very likely exceeds your own when it comes to their own technology and it may be at-the-ready.

Step 10 in short!

Reap the rewards of everyone’s efforts so far as endeavours throughout the project-work pull together to achieve a smooth go-live moment.

Reduce the technical performance, organisational and cultural risks associated with making your HR system available to its intended users by preparing well. Make informed choices about how you would like the go-live milestone to happen for the business. Or if choices are in short supply or perhaps not your decision, at least don’t feel confused about goings on that are not so very mysterious.

When it comes to the people implications of going live, you can improve uptake with comprehensive communication, change champions and the odd carrot. But…

I cannot tell you that now is the moment to relax! 

There is a significant amount of leverage on the success of early days that you can pull upon and it’s not just all about day one. There is also an important transition to make from project mode to business as usual (“BAU”).

Safeguarding early days and better BAU are topics for the concluding parts of this series.

Take 1 Step on Step 10!

Be sensible about going live. Common sense says no live steps on a Friday afternoon, nor in any form of silly season. Perform your own internal sense-checks if you have a big fear factor by thinking through what (little!) is really happening at any one moment. Perform external sense-checking prior to going live by involving your project team advisors in an exercise in risk assessment, looking at likelihood and impact. What is the worst that can go wrong? The best is smooth success and a quick move into business benefit.