Deploying technology successfully is a hard task, and the pilot phase is a critical step to assess whether the solution will be adopted and bring the expected benefits. Running a pilot and flying a plane are quite similar: the first (take-off) and last (landing) moments are the most critical and the ones that require the most attention. In between, the crew can usually relax a little bit more and rely on autopilot.
After sharing the 5 steps for running effective technology pilots last week, I will now deep-dive into the take-off, or the hyper care phase and what to do in the immediate weeks after the pilot go-live to ensure that your project does get off the ground and reach cruise speed.
Why is Hypercare important?
In the ideal world, we wouldn’t need Hypercare – and perhaps that is why a lot of organizations are just launching their digital solution, and waiting until the end of the agreed period to see if there has been adoption and results. In the ideal world, the solution has been connected perfectly, all data flows correctly, and the users can do exactly what they want/need without any training and experience errors.
The reality? There ALWAYS are some errors, things that weren’t considered and those will lead to dissatisfaction or issues. And think how important the first experience is: if there are problems, or issues that aren’t addressed immediately, your project will die down by lack of adoption. Think about this marketing saying that one dissatisfied user will tell 6 people. Any bad experience with the tool will snowball and may give the solution you are trying to get adopted a bad reputation.
To avoid these critical early mistakes, or at least minimize their impact on adoption, best-in-class organizations set up an Hypercare phase. The Hypercare is a phase in the pilot, typically the first few weeks after the GO-live, where the project team will function with an elevated level of support and resources. During this phase, every aspect of the solution will be scrutinized, issues identified, tracked, and resolved to ensure a successful first contact with the tool.
Running an hypercare phase will therefore aim at having a complete view of the functional and technical performance of the solution, from end to end (including actual user feedback). It should also be used to start iterating on the KPIs, weekly flashes, and other information you are going to produce and use to evaluate the solution. You may realize that some important evaluation points were missed while others may actually be less relevant than you imagined. Either way, it is important to remain open-minded and flexible during this period: be ready to try, change, and experiment with a lot of things during that limited time.
A big part of the success of your digitalization project will rely on these few weeks of hypercare, make it count!
How to run Hypercare
The hypercare should start the very day the solution is pushed to the end-users and should run for a defined period of time: ideally up until the first pilot review.
The goal of an hypercare phase is to make sure that there are no blind spots. the project team’s attention will be focused on the pilot metrics all the way down to the most operational aspects, all the way to the number of clicks users are taking if that’s relevant! Each transaction should be looked at and understood from end to end. – there probably won’t be that many, the big bang deployment doesn’t exist in digital transformation.
Set up an agile team and experiment
The project team – with the suppliers! – will have to dedicate time and resources to produce and analyze the data, track user feedback, and ensure speedy resolution of any issue arising. The hypercare should be led by the project manager and the core project team, but it is also desirable to have other functions stepping up in the process. Good practice in some cases is to ask suppliers to assign a dedicated Customer Service (CS) person, preferably one of the best in the CS organization, who could then act as the focal point, track and resolve any issue that was arising. This really is important as in most cases, the customer service will be done through a general alias/phone number and the information gets lost, the dots aren’t connected. Make sure you understand how your supplier CS is organized; if there are different levels of supports and what are the main workflows, etc… When engaged correctly, the supplier’s CS can truly turn into a key enabler for success.
During this time, the entire goal is to understand what is happening and PILOTING it. Understanding and tracking the KPI isn’t enough, the goal of a hypercare phase is also to try as many things as possible. These piloting activities can be technical (changing a setup), communicational (sending more, or different documentation…) or a change in scope (Extending or restricting the scope, experimenting with additional functionalities that were deemed less relevant, etc…). When making these decisions, make sure you are tracking the effects week on week so you can roll back quickly anything that wouldn’t make sense. Organizations that launch tech pilots and wait until the end of the pilot period to see if it works are very likely to face disappointment. Instead, the successful ones will experiment with all sorts of things and be bold, after all, this limited scope of users means the risks are very low, and trying anything later will become more complex and risky!
Eventually, those tasks require a level of attention that is not sustainable and that’s why it should only last for a few weeks. If you need to maintain a high level of control and follow up after, this probably means that you have a deeper problem: either the solution does not work or it doesn’t answer the needs of your stakeholders.
And put the user at the center of it all
A successful hypercare will look at the technicals (is the solution working as expected), measure benefits (is the solution delivering what it is expected to) but most importantly, will focus on the users and their experience.
The first goal and one that needs that need to be achieved as soon as possible is to train the pilot users to use the solution. The training should cover two parts: how to use the solution (where to click) and when to use it (what are the use cases where the solution is relevant). There are many ways to deliver training: live training and office hours are my favorites, but online classes, quizzes, and other learning tools can be effective as well. What is important is to give these training resources to the user, and make them available at any time through offline versions. These offline documents are often overlooked and consist of a few PDF uploaded on a drive somewhere. This is not right, these documents are what will help your users use the solution you want them to use, so they have to be well thought out: it can be very disheartening for a user who takes the time to seek information and only find uncoherent, half-complete documentation.
The second goal will be to establish a 2-way communication channel with the users and collect feedback. The project team should have several KPIs from the pilot to judge performance but qualitative feedback is at least as important and collecting it requires a different set of mechanisms. Setting up a system of ticketing, or a dedicated email address to send feedback onto can be a good way to collect feedback passively. The main issue with these methods is the bias they incur as people are more likely to give feedback when something went wrong rather than take time to give positive ones. Focus groups with 10 – 20 pilot users can help overcome this bias, they are a powerful tool to understand user perception and experience with the solution (or lack of as you should also invite people who didn’t use it!). These sessions will give you insights that hard data never will, positive or negative.
In summary, if you want to make sure your pilots do take off and don’t become one of these zombie projects, those that are moving but with such little vitality that it’s as good as dead. The first weeks are crucial to get your project take-off so don’t miss out your window. Running a structured hypercare does take time and resources, but it is worth it as it is the only way to really test and deploy new tech.
Leave a Reply
You must be logged in to post a comment.