The Go-Live Milestone: Getting it out there!

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:

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:

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.

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:

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:

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!

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.

Tagged ,