The decision to go live or not to go live is one of the most important decisions in the project lifecycle, and it should not be taken lightly. Wrong decisions can jeopardize the success of the entire project. The decision to go live is highly dependent on the quality of end-to-end testing, user/organizational readiness, and sign-offs from business stakeholders.

The implications and costs of a failed or unstable go live are often far worse than a minor delay in the schedule. Most of the time, the project manager and the delivery team can be under pressure to deliver the project on time. However, if there is any doubt, it is important to take a step back and delay go-live rather than risking the project's success.

The following are a few instances we have encountered in this area:

• Imagine that you are in a room full of executives, making a decision about pulling the trigger on a new system. Everyone is under pressure from the CEO to say we are ready. However, most of them are not ready. They do not have enough time to go through the testing phase due to lack of staff, but everyone says yes (there is a fear of getting fired, considering this is way back in 2009 when the economy wasn't doing well). You fail to push back as well. Any guesses as to what happens next? The customer goes live, and it is very painful to stabilize the system, but a lesson has been learned!
• A similar situation occurs again, a couple of years later. Of course, you are smarter this time. The CIO calls for a meeting to check the readiness of the project. Everyone says they are ready (the CIO is driving the dates very hard, and again there is a fear of getting fired). It is your turn – you bravely stand up and say no, and hand over a list of areas you are not comfortable with and that need more testing. The CIO calls for another meeting to better understand what is needed to finish those areas and decides not to go-live. Your team ends up extending the schedule by six weeks based on what is on the list. The CIO thanks you (and still continues to) for standing up and challenging the decision to go-live based on the bugs that were reported/fixed in those six weeks.
• On another project, you are involved in the capacity of an executive reviewer; you challenge their readiness, but the CEO doesn't want to listen. You tell them that it is their call and that we are supporting the release if they sign a liability waiver as your team is not comfortable with them going live (due to a lack of testing from the business team). When you give them a piece of paper to sign, the CEO chooses to reconsider his decision. The customer ends up delaying the release by four weeks. The CEO is not very happy when he receives the pushback but now feels thankful to your team for watching his back.

There are more instances like these that we can share. The point is to think about the impact on business. As a consultant/project manager, you are their advocate, and you need to protect the customer from hurting themselves (even though it's not what they want to hear, you are doing it in their best interests). This is the time to utilize the relationships and respect you have earned from the customer to protect them. Don't be shy.

It is even trickier when you have to stand up for someone else's deliverables. For example, say the customer owns certain deliverables internally, which are not production-ready. You need to request the delay due to their internal deliverables as you don't want the project to fail due to specific areas.

Saying that you need more testing is easy. The tough part is to decide how much more time you need. You won't get such an opportunity again. Thorough planning needs to be done to identify all the pieces that are incomplete and to put a plan together so that you can come up with a realistic date. Many project managers fail in this exercise; just hitting the snooze button and delaying this by a few weeks without identifying the action item won't help the project.

Picking realistic dates that will work for the business is important. You don't want to perform an ERP go-live right before or during the peak periods of the business. Challenges from go-live will have a severe impact on the business. There are many examples of companies going out of business due to an ERP go-live during or just before the busy holiday season.