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.
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:
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:
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.
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:
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…
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.
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.
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:
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.
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.
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.
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 the use of HR technology in performance management frameworks.
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.
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.
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.
Assad founded Phase 3 in 2004 and is responsible for the strategy, growth and finances of the business.
