Going live on a project is a critical time, and while you can’t usually predict what will go wrong, the approach you take can make the difference between scrambling to put out fires and actually focusing on creating value that will endure beyond that initial go-live period.
The problem is, many projects measure the 1-2 month stabilization period after go-live—fondly referred to as hypercare—by counting the number of bugs and when they get fixed. Sure, bugs are the visible part of going live—we want users to have a positive experience, so we want to squash those bugs quickly—but they’re not the entirety of the post-go-live and business ramp-up process.
Instead, your team needs to create a structure that will monitor progress of your controlled ramp-up, deal with issues as they come in an effective manner, and set the business up for success. Here’s how.
Focus on Tasks, not Tickets
Part of that focus on bug fixes means that the go-live team may be so centered on preparing for issue monitoring that crucial Day 1, Week 1, and Month 1 activities can become an afterthought. That’s why the planning and rehearsal of the ramp-up plan are so important.
The point of the go-live period is to stabilize the business, so it’s important to stay laser-focused on those objectives, even in chaos. Before go-live, create a schedule of key activities that need to happen in the first weeks to create a controlled ramp-up. Rehearse those tasks prior to the cutover so you can identify potential failure points. Involve key team members and get them to think through contingencies and weak points. Create a backup plan as part of your cutover plan so you’re not thinking on your feet if (or rather, when) things go awry.
Set Up Command Centers Smartly
When you have a project team spread across the central office and satellite offices (often globally), it can be challenging to keep the project running smoothly. Often, the central office has most of the project expertise, which can make decision-making difficult at other locations.
As best you can, spread the subject matter expertise across locations. That might mean certain team members might need to travel from one location to another, but it’s necessary to create effective coverage.
You should also have super-users at each site so that you have feet on the ground that are experienced with the new solution and can quickly identify roadblocks and bugs. When those issues do arise, have a designated lead at the local command center to make local decisions and determine when escalation is needed. Not every issue needs to be escalated to the central office, and not every local problem is a global issue. The more you can deal with locally, the fewer hiccups the project as a whole will have.
Also, make sure you have the expertise you need in the right place. If you have a manufacturing location, make sure you’ve got your manufacturing SME there, not in another office. Each site has its own function, and each will have different needs. Identify what those are and have your most crucial resources at the most crucial place.
When You’ve Got More Time Zones, You’ve Got More Problems
Global go-lives have their own unique problems, many of which stem from the fact that team members are located in different time zones around the world. Unfortunately, many often have the attitude at the end of the day that whatever happens next in the project isn’t their problem until 8 am the next day. But this can bottleneck information and create snarls in the decision-making system.
A better solution is to have handoff calls as each business wraps up for the day. This allows team members to get information out of their minds and hand it off to another team member, who can take the baton and keep the marathon going. Don’t let a team slip out of the office with all that information in their head; they won’t remember it tomorrow!
Here’s an example: I’ve been on projects that involved a team in India. Given that they were about 12 hours ahead of Pacific Time, we rarely talked to that team except via email. When problems arose, they didn’t get fixed because they weren’t part of the daily conversation the rest of the teams were having.
We started having India teams hand off to teams in Europe at the end of the day even though that wasn’t their normal process. Then Europe would hand off to the US teams. There was now an effective chain of responsible parties.
Whoever’s in the last time zone “cleans up and turns off the lights,” so to speak. It’s that team’s responsibility to write a recap of the day and email it to the project teams in every time zone so they also have a handoff on what to start working on the next day, and get caught up on which issues are still open.
Manage Issues and Expectations
When it comes to issue resolution, be sure to align on the definition of issue severity before you start the ramp-up. Train your team on how to identify each issue according to its severity before go-live!
- Low: workaround exists; not urgent to fix
- Mid: workaround is difficult or nonexistent; should be fixed within 4-6 weeks (within ramp-up window)
- High: issue stops functionality of other components; fix ASAP
- Critical: there’s a complete breakdown in major processes; extremely urgent to fix
All too often, team members try to gloss over what should be labeled as yellow-level issues because they don’t want the finger pointed at them. That, or they over-escalate issues to critical when they shouldn’t be. Critical status should be reserved for truly heinous things. You know an issue is critical because you’re on the phone with all of the business and project leaders instead of creating a ticket! Train people to be judicious when they assign a level of criticality to an issue.
Don’t Fumble the Hand-Off (of the Backlog)
A few weeks after go-live, your hypercare will end. There’s no more budget left and everyone’s getting assigned to new projects. That, however, doesn’t mean all the issues you’ve had on the project miraculously disappear. How you handle them now will determine the future success of the solution.
Rather than just dump the issues on the ongoing support team, make sure you’ve considered (and identified) the following.
Issues That Can Be Closed and Never Fixed
Sometimes new systems suggest new processes, and that’s okay. It’s not uncommon to have issue tickets logged and no one can remember why they were added, especially on a long project!
This category also includes issues that maybe only occurred once a long time ago and haven’t been reported again since, those that were fixed or mitigated but never followed up on, and even issues that turned out to not be such a big deal. Close them!
Issues That Are Actually Change Requests
Throughout a project, you’ll often find tickets proposing new functionality or even new project ideas in ticket form! These need to be forwarded to the right place in the business before the end of your ramp-up.
In either case, make sure the team you are handing off to can appropriately address a given open issue. If you, for example, don’t have your own coding resources, you might need to move it to a new project or a team that does have the appropriate resources available. There’s no point in handing off an issue to someone who can’t help with it!
Reviewing the backlog can be a tedious task, but don’t skip it! Appropriately closing the ticket or reassigning it can ensure that the remaining issues are supported by the regular business support team in the future.
There’s the old adage, “plan for the worst, hope for the best.” This applies to planning for post-go-live support of the project. You can’t underestimate the importance of planning and preparation, focusing on what’s critical to success, and implementing a clean handoff to your project. With these elements, you ensure all the hard work you and your team have put into this project over months (maybe even years) pays off in the long run.