Building the confidence to go-live

Anyone who has been responsible for a major ERP go-live can attest to the following scenario:

You have executed your project plan with some bumps along the way. Overall you are where you expected to be with development and testing, data might be a little bit behind, but training is nearly completed. The boxes have been checked and you believe you are ready to go live. Suddenly a tsunami of pressure starts to build from the business against going live. They are not convinced that the system is going to transact properly, they worry their people aren’t prepared enough, and there is too much risk to the business to allow a go-live to mess-up the quarter.

Now you are caught in a dilemma to which very few people can actually relate. On one hand, you are accountable for the overall project budget and schedule. You recognize that to delay the go-live will likely cost the company millions of dollars in additional time and fees. Also, the reputation of schedule slippage will not do a lot for your credibility as you lay out future plans. On the other hand, if the business tanks, there is a good chance your career could be over. Nobody will remember you came in under-budget and on schedule if the business is in disarray — that is a guarantee.

Guidance from your system integrator

If you are in this situation and you ask your System Integrator (SI) for advice, it is likely you will get one of three answers depending upon the deal construct in place:

Condition 1: Firm Fixed Price Deal – “We have seen this situation countless times before. Don’t let the users’ comments sway you. We have done the work and checked the boxes. You are ready to go live.”

Condition 2: Firm Deal but the SI is mainly responsible for system configuration – “Our part of the deal is solid, your part is not so good, we suggest that you delay and use that time to fix more problems. We will make it time and materials (T&M).”

Condition 3: Time and Materials Deal – “You should never go live unless the users are comfortable. We need to fix all of the problems and delay until we are sure the business is ready.”

What should you do?

Before I dive into that, let’s explore how we got to this point in the first place.

The primary pressure point of the situation is the business’ overall comfort level associated with the go-live. Perception is reality, and if the business does not feel ready to go live, they probably are not. In many cases the business concerns are simply a product of lack of visibility of all of the things you have done to protect them. In other cases, the first time the business sees the entirety of the solution (system, data, and trained users) is just a few weeks before the projected go-live. There is a high degree of probability they are discovering things they didn’t fully appreciate when the original specifications were agreed to. Finally, you probably have not given a lot of thought to the criteria you are going to use to provide a way to balance the overall risks to the business with the risks and costs to the program during a go-live.

7 things you can do to reduce the anxiety associated with making the go-live call

Having misgivings about actually pulling the trigger? Here’s a handful of tips and techniques you can used to mitigate the stress of a go-live moment.

1. Align program delivery with FEMA

For manufacturing businesses, Failure Effects Mode Analysis (FEMA), is a very common term associated with Lean and 6-Sigma. It is common to develop fish-bone diagrams of all the things that could go wrong with a manufacturing process and then identify tactics to reduce the probability of failure. Walking through the FEMA process with your business early in the delivery process and aligning your program deliverables with the tactics to reduce the probability of failure will allow the business to fully understand what is being done to protect them.

2. Implement three-dimensional high definition reporting

This technique involves developing a status reporting process that engages multiple project constituents in providing risk evaluations based upon a common set of reporting metrics. Often we rely on a single individual to interpret the numbers. By engaging users, function teams, technical teams and independent parties to review the program statistics and provide commentary, the project leader can get a 360 degree view of the risk levels. This will help reduce the number of hidden opinions that crop up before a go-live by bringing them into the fold early.

3. Establishing standards early for go-live

This serves two purposes. Your SI is going to be largely driven to deliver the working configuration. Because their payoff is at stake, they will do a good job of keeping the standards for technical quality in front of you. They are not as likely to bring to your attention until late in the game concerns with training or data. Keeping training and data status measures visible throughout the project will allow you to justify the assignment of resources to these items versus items the SI feels are critical for configuration. The second purpose will be to align the business with these go-live criteria early on rather than in the heat of the moment just before the go-live. The business will want to have everything perfect (not practical). You can use the time to move them to a more reasonable position.

4. Advance the availability of solution integrity quality metrics

Not until all three components of the business solution (system, data, and people) are combined into a single test do you really get a read on the overall effectiveness of the solution that will be implemented. Push hard with your SI to devise a plan that will bring these three components together as early as possible in the development cycle. Do this even if it means some extra costs. If you can pull this quality look forward by three or four months, it will more than offset the costs associated with the fire-drill at the end of the project.

5. Build contingency plans and back out plans into the go-live

This is another two-purpose tactic. In the construction of a back out plan (some will deem this impossible), you are forced to consider the worst-case scenarios. In making this worst-case scenario assumption and having to determine how to get out of it, you will actually improve the quality of your go-live plan. This exercise will also ensure that special precautions will be taken to allow for a full back out. Thinking through these precautions will enable you to find holes in your go-live plan and fill them prior to go-live. The second purpose of the back-out plan is to allow the business to understand that this is not an all or nothing proposition and there will be options after go live (not good ones, but options).

6. Put penalty clauses in the next SOW

You obviously will not be able to change an SOW for a current go-live. However, that does not mean you cannot hold your SI accountable for bad advice. If you have a multi-wave approach with fixed bid contracts, then I would suggest that you craft language into the next SOW that provides for a “full-stop” of work for a period of a month if the business is not operating properly during the first six months of the previous deployment, regardless of the reason why. The full stop would be crafted in such a way that the SI would be required to return the full staff after the one month period with no penalties attached.

7. Establish an independent review

Assessing readiness for go-live is an audit-like function. Bringing in a 3rd party evaluation will allow for a fresh and unbiased perspective on the possible risks associated with the go-live. It will improve the chances that the decision you need to make will be the right one. Like my father once told me, the best advice comes from the person with the least at stake.

If you take these seven suggestions to heart before you approach the go-live date, you should feel much more confident when your SI says that you are ready to deploy.