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 to prove your business case.
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 issues and when they get fixed. Sure, these “bugs” are the visible part of going live and we want users to have a positive experience, so we want to squash those bugs quickly—but they’re not nearly the entirety of the post-go-live and business ramp-up process.
Instead, your global program needs to create a team structure that will monitor and prioritize the right activities of your controlled ramp-up, communicate and deal with issues as they come in an effective manner, and set the business up for success. Here’s how.
Focus on Planned 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 and implementing makeshift resolutions that crucial Day 1, Week 1, and Month 1 business activities can become an afterthought. That’s why the planning and rehearsal of the ramp-up plan to get to business as usual, aka “steady state”, is so important.
The point of the go-live period is to perform the final activities to transform from a legacy state to the new and stabilized way of working, 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 reacting at the last minute if (or rather, when) things go awry.
Set Up Command Centers Smartly
When you have a project team spread across the central office and global satellite offices, 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 and issue resolution 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 global issue is a local problem. 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 places.
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 issues arise 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!
An example was a project that involved teams from the US West Coast, Europe, and India. Given that the Indian team was about 12 hours ahead of Pacific Time, the US team rarely talked to them except via email. Bugs identified during the Indian team’s working hours often times didn’t get fixed because they weren’t part of the daily conversation the rest of the global teams were having.
The solution was to start having the 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. 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.
There was now an effective chain of communications and responsible parties.
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)
1-2 months 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.
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.
Rather than just dumping 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 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, or 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 development 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!
There’s the old adage, “plan for the worst, hope for the best” that absolutely applies to planning for the transition from go-live to business as usual on a project. Don’t underestimate the importance of planning and preparation, focusing on what’s critical to success, creating the right team structures, and implementing a clean handoff to your project. With these elements, all the hard work you and your team put into the project over months (maybe even years) will pay off in the long run.
Share: