Greetings!
If you've recently gone live with a new project or system enhancements congratulations are in order. You've undoubtedly poured a lot of dedication into it, and your hard work deserves celebration. However, before you breathe a sigh of relief, let's talk about what comes next – a phase critical to ensuring the success of your efforts.
Enter "hypercare" – the period following go-live that demands thorough planning and execution. But what exactly is hypercare? It's the short period of time post-deployment where additional resources and attention are dedicated to supporting the users and business processes. During this phase, the project delivery team remains actively engaged, ensuring a seamless transition and addressing any unforeseen challenges.
In the article below I compiled a few different activities that I typically participate in during the initial weeks post-go-live. I hope that this list will inspire you with fresh ideas of things you can consider during the post-deployment phase.
This is the first part of the article where I will concentrate on the users.
During the initial few weeks, it is crucial to provide the users with as much support and guidance as possible. Depending on the available resources and locations, there are a few options to consider.
Issue management
First of all, make sure that all the users are aware of how to raise any issues and where to seek assistance if required. Depending on the implemented model of support, it can be either a separate system, it can be done by email or even on an Excel spreadsheet stored in a central location. No matter how the issues are raised, proper communication needs to be sent to the users prior to go live and also once the system is live.
Be ready that for the first couple of days, there might not be any issues raised or there will be only a small number of them. It doesn’t mean that everything is perfect though. Sometimes it might take the first few days for all the users to get around to logging in to the new system properly for the first time, so there might be a delay in seeing any peeks in the numbers. Make sure that the issues are actively checked and addressed.
Also, be prepared that the issues will vary from actual issues like not being able to access the system or having enough permissions to the users raising new requirements and ideas - and calling them “bugs”.
Why? It is quite common that if the previous system had a certain functionality and the new one does not, the users would consider that as a “defect”.
Ideally, the differences between an actual system issue and a request for change were explained to the users during the training or in the email communications. Unfortunately, sometimes the users will have their own definition of it and we just need to support and guide them around that.
Response mechanisms
Secondly, have means of advising users how quickly they can have an update on their issue. Have a system in place and prioritise any access issues first. What is more, make sure that the users will be informed that for example, they will hear back within the next working day or so.
If you are using a separate system, use email notification and include that in the message. If there are any delays in resolving a backlog of issues, also advise the users of it. It is critical to let the users know that their issues did not go to a black hole, but that someone is dealing with them. Otherwise, the users might straight away have a negative experience with using the system and it does not translate into long-term good system adoption.
If you opted in for the automated email notification, make sure that you also include links to an internal support page where users can find some training materials, most common issues, Q&As and so on. Sometimes, users will be able to self-help themselves before someone will officially be able to address their issue.
Internal issue review
All the issues should be monitored closely and triaged as soon as possible. Allow users to categorise their issues themselves and to assign a priority. However, during the triage someone should review whether a raised support ticket is an actual issue or a bug and if the priority is correct. If needed, change the category and priority.
The crucial thing is to also notify of any changes made to the initial classification made by a user and to provide justification. If a user has raised a high-priority defect that turned out to be a low-priority new requirement, it should not be changed without justifying the user why. Simply, the user has taken time to communicate something to the support team, therefore they deserve the courtesy of knowing why things have been changed. If users are asking for changes, advise that there will be future improvements made to the system and that their suggestion was added to the backlog for review.
Ideas and suggestions
I have mentioned above that it is quite normal for some users to start raising ideas and suggestions and calling them system defects or bugs. You should consider being prepared for that eventuality by creating a mechanism that will allow users to provide their ideas.
One way of doing this is to create a support ticket category called either “new requirement” or “idea”. That approach will work fine during the hypercare as the project team is still reviewing all the issues. It will also work well if the customer has an internal support team that will be looking after the new system. However, if the support will be outsourced to an external 3rd party, it is better to introduce another mechanism of raising new suggestions that are kept separate from any issues. Thanks to that, the new requirements can be logged as the system backlog, which is then reviewed and prioritised internally before any new work is undertaken. Again, this can be as simple as sending an email to e.g. a business analyst or more advanced like a separate system.
Self-help resources
Creating a company internal page with different available resources is a great way to limit the number of potential support tickets and guide users on how to help themselves. You can easily create a SharePoint site and upload any training materials that were created for the users’ training. Include additional resources like links to Microsoft websites and also add the previously mentioned Q&A (questions and answers) section on it as well. Not sure what to add to it? Each day (once or more, depending on volume) analyse all the incoming issues. If there are any frequently asked questions raised by the users, include the answers to them as a self-help resource. The Q&A section should be updated regularly to ensure that is up to date.
Transparent communication
When you’re updating the Q&A section and adding new content, make sure that you will notify the users about the updates. Either send an email advising that there are new updates or just copy and share the new content in the email. Some people might worry that there will be oversaturation with all the information and updates. However, I strongly believe that the users need to know that they are fully supported in different ways possible.
Interactive support sessions
Dial-in clinics, sessions or surgery calls can be another great way to support the users post-go-live. Each day or even twice a day, open a Teams call where everyone is welcome to join for either the entire session or just to ask a question and dial off. At the sessions, allow users to share their screens and demo the issue they’re having. Also, do the same for them – even if something was covered in the training/training materials, show that to the users once again. Some users might be absorbing new technical knowledge at a different pace than others. Be mindful of that and also be patient. And remember - empathy for the users will take you far!
On-site support
This idea might be slightly more challenging, especially with a large group of users spread across multiple locations. However, if possible, consider having on-site supporters (they can also be called “floor walkers”). Basically, for the first few days at least, have you or/and someone else in the (customer) office walking around the floors either asking questions yourself or letting the users come to you.
Before doing that, make sure that an email communication is sent to the users, so they will know that you will be there and they can talk to you. If you are brave enough, bring some fun to it and wear a distinct t-shirt, costume or at least a badge. Things like that will help to build a positive association with the new platform and make technology less scary.
Also, do not be afraid to ask for support from the end users themselves. If you have met any users (e.g. during workshops or training) that were particularly interested in the project, “recruit” them to help you support their colleagues. Even if they will end up directing most of the questions back to you, it will still help the overall initiative. Why? It will be easier for some users to ask for help from someone they know rather than asking you directly if they only just met you.
Feedback and surveys
Do you want to know what users think about the new system? Why not consider sending a feedback request or even a short survey to find out? Avoid doing this in the first or second week though. Ideally, leave that towards the end of the hypercare period. That will give users some time to start getting used to the new system and they will form an opinion about it, so allow them to share it with you.
What other activities you are usually undertaking to actively support your users?
Conclusion
Navigating the post-go-live phase requires a holistic approach centred on user support and engagement. Prioritise proactive communication, empower the users and give them means of raising issues and providing their ideas and feedback. That will help to sustain the project's success beyond deployment.
For the next blog, I will cover additional aspects that require your attention during the hypercare period, so stay tuned!
Comments