A welcome innovation of recent times: the emergence of post-implementation HyperCare as a new and additional stage in the project lifecycle. Find out more about this concept, why it works so well with Cloud SaaS, and how to implement it successfully in your organisation.
Common Problems
Perhaps you might recognise some or all of the following, from your own change efforts? I have certainly seen many of these patterns repeat, across several different organisations:
"Repeated No-Gos" - when presented with a list of the current defects - and asked to accept them all for a go-live - the SteerCo finds it hard to agree and prefers to defer the go-live date 'until we are in a better place'. This can be frustrating, particularly when none of the items really fall into the 'fundamental' category. One suspects a fear that the project team will just "bash it in and run away", rather than stay the course to clear down the defect list. Or a fear that a small support team will be under-skilled and/or under-resourced to tackle these items in BAU.
"Whack a Mole" - after go-live, there remains a long list of outstanding tickets. Some of these are genuine bugs, some are unmet requirements, but many are really new changes (not part of the original scope). Your business colleagues will not agree that the project is really finished until all tickets are cleared off. As you resolve them, new ones are added to the list. So it becomes a game of "whack a mole", where you need to resolve existing tickets faster than new ones can be generated, until the level drops to near-zero or everyone just gets tired and are finally ready to move on.
"Hogging the Spotlight" - in large organisations, few parts of your business get continual attention, from a change perspective. So when it is their turn in the spotlight, they can be reluctant to let that light move on. This manifests as a sort of "whilst you guys are here, can't you just..." behaviour. The original scope can become kinda irrelevant after a while, as more and more asks are piled on your plate.
"The Agony and the Ecstasy" - if you have ever seen this wonderful movie, you will recognise the scenario. Michelangelo is painting the Sistine Chapel and Pope Julius II is impatient to see it done. "When will you make an end of it Michelangelo?"... "When I am finished". Sometimes, it is not your business which is the problem, but the desire for perfection in your own project team!
How can Hypercare help?
Hypercare is a period of elevated BAU support, following go-live. It originated, as a concept, in the Client Tech space; specifically from Software Companies keen to keep their paying customers happy. It is closely associated with - but distinctly different from - the more traditional, commercial concept of a "warranty period". In my experience, there are three very important components to get right (in using this method in your business):
Hypercare must be led by the Support Team, not the Project. By insisting on this, you help to ween the customer off of that dependency-forming habit of high-attention project activity. It also frees (most of) the project team to focus on the next wave, or project, and gently moves the spotlight on. Finally. it renews the bond between the customer and their support organisation, which is very helpful for the longer-term relationship.
Hypercare should have a defined duration and I have typically found 3 months to be ideal. It helps to soften this by saying "if tickets haven't fallen to 'normal BAU levels' by the end of the three months, we will absolutely extend the HyperCare period until they have". This focuses both the Pope and Michelangelo on the need to "make an end of it" and defines a threshold for when sufficient moles will be judged to have been whacked.
Hypercare is part of the project SDLC. In other words, you are not really done with this wave/project until you exit HyperCare. This helps with that risk of repeated No-Go calls: everyone understand that the definition of done includes a successful HyperCare period and no-one is running away until that is signed-off by everyone.
The Vital Role of Business Change Management
It might have occurred to you that a concept like HyperCare fits perfectly with the business change management concept of a post-implementation adoption drive. Indeed! You may be familiar with the J-Curve of Change from my first book (published in 2005): the observation that business performance falls initially - after a go-live - even when change is well-planned and executed (as people adapt to the new system and/or processes):
A three month HyperCare period would normally fit the Change "Transition Period" well, so whilst your IT Team are bashing those tickets, your Change Team could be mitigating the performance disruption, through post-implementation training, communications, reward mechanisms, and adoption drives.
Final Thoughts
Why not give HyperCare a spin? It has already been adopted across a large number of businesses - particularly in 'demanding' environments or cultures where a high standard of care is expected. It could well be the 'missing piece' in your Solution Delivery Lifecycle (SDLC):
© David Viney 2023. Licensed for re-use with attribution under CC BY 4.0
Preferred Attribution Code Snippet
The <a href="https://www.david-viney.me/post/hypercare-meet-your-new-sdlc">HyperCare - Meet your new SDLC</a>, by <a href="https://www.david-viney.me/">David Viney</a>, licensed under <a href="http://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>Like the Post?