A Checklist for Managing Go-Live Decisions and Risks

From time to time, large mission-critical data systems require significant upgrades, or even outright replacement—imagine changing ERP or financial system vendors or products, or replacing an aging custom mainframe system.

Sometimes it isn’t practical to cross the chasm in several bounds by rolling out new functionality in bite-sized pieces. In some situations, you get one shot: a “big bang” rollout. System users leave the office Friday afternoon, while you and your team look forward to a long weekend of cold pizza and warm soda while you swap out the old system and install the new one.

These projects can be fraught with risk: If things go badly, they can destroy a business and damage careers. One coping technique professionals use to avoid getting overwhelmed is “doing the best you can with the resources we have.” No one can fault you for that, right? The problem is it can create a mindset that downplays or accepts risks that may be accumulating to untenable levels.

One process that can help keep you honest is developing checklists that describe very clearly what is expected to be accomplished and verified at each milestone. This is sometimes called a go/no-go checklist because if the criteria aren’t met, that suggests the date is a no-go.

I use the word suggests because the exact nature of the discrepancy or shortfall may be well understood and manageable. A project sponsor may choose to accept the risk and continue the project on the current trajectory even if all the criteria aren’t strictly met, but it encourages a conscious decision on behalf of executive leadership to continue.

What does that look like? Here’s a checklist from one of my projects that had a decision point four weeks prior to the scheduled go-live date:

The go-live is assumed to be in jeopardy unless

1. A clean data conversion has been performed and verified
2. No Severity 1 errors persist
3. All Severity 2 errors that persist have workarounds acceptable to the users or are on a trajectory for correction and regression testing within seven days
4. All necessary hardware and software are in place and running current versions of the firmware/operating system
5. User training is complete
6. Updated desk procedures are created and ready for distribution to all affected users
7. Help desk documentation for the new system is ready
8. All system interfaces have been tested and certified
9. Business partners have confirmed their willingness and ability to support the go-live date
10. The CIO and managers of any impacted user departments have agreed in writing to any exceptions to items on this list

A series of checklists such as this one during a project essentially formally ask, “Are we still on track to go live with acceptable levels of risk?” It’s a good question, but it can be challenging to get a straight and comprehensive answer.

Note that building the exception process into the list encourages conscious management decisions. If your team decides to go live when one of these criteria is not met, it should at least be with an appropriate understanding of the risk involved.

• Login or Join to add your comment