The Go-Live Milestone

Getting It Out There!

I smile as I reflect on the flow of our current series, Smooth HR Technology Projects: 12 Significant Steps to Success featured by HRZone and how the ‘go-live success moment’ is part 10 of 12, because the wonderful ‘phew’ of getting your new HR system out there on go-live day is so often regarded as a closing project chapter.

Read The Go-Live Milestone for plenty of advice about how to make that milestone, which I describe as both a practical step and a risk moment, an exciting celebration of success.

I cover what going live actually means – you are not alone if you don’t know. I cover the choices you have, how to mitigate risk and even brave the question of the circumstances in which you might need to pull the plug on the whole shebang.

Why part 10 of 12? There are plenty of ways to follow the day on which your system first reaches its end users in which you can optimise the uptake of HR tech and see project work safely transitioned into operations known as BAU. 

Recap on the work up to system release date with the full series here.

12 Significant Steps to Success Part 10: The Go-Live Milestone – Getting It Out There!

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 stage 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 opportunities to look out for that help to manage that transition milestone effectively.

‘Go-live’ is two things:

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

Risks occur around how the technology works, but also in 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 technological 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’ projects 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 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 processes 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 when 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 refers to 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, ‘installation’ 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 a live (or production) version. This may become live at the milestone moment. Most likely you need to retain at least one test environment during BAU.

It is also advisable 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 trainingenvironment and/or 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 behavioural 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 a sound method, even if simple, is knowing that you have a good grasp on risk throughout. An 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. The 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 be monitored after. This is one reason to choose a ‘soft launch’ or phased approach.
  • Change control again is about method. Unless you have supported the transition into real system use with the establishing of a 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 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.

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 the 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-outs or ‘soft launches’. With the 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 indications that performance or organisation cannot cope well.

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 exceptionally 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 it is 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 a 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 this route is 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 just 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 it.

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 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 a direct reward for system use can work well. Target an area of compliance with the greatest business benefit, combined with the 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 the 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 the 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.

The full Smooth Technology Projects series can be read here.

Enjoy additional content via our Phase 3 Insights library.

For more information, visit the Our People page by clicking here.