Navigate / search

A Framework for Project Launch Decisions: To Go or Not to Go Live

Go, Wait or Stop Light

By Eileen Strider

Although everyone knows that the Affordable Care Act (Obamacare) system was not ready for prime time on the October 1 launch date, does anyone really know how the decision was made to go-live? Was it a conscious decision with full consideration of the readiness of the system or a de facto decision when October 1 arrived?  And closer to home, do you know how your project will decide if it’s ready to go-live when the planned go-live date arrives?

My project and IT management experience is that most people don’t believe that they could actually say “No, the system is not ready and should not go live on the scheduled date.”  Here are just a few reasons why:

–       I’ll be the only one to say no.

–       No one will listen to me anyway.

–       I’ll be blamed for the project’s failure.

–       I’ll be labeled “Not a Team Player”.

–       I don’t have the courage to say no.

Any or all of these may actually happen. If you watched the congressional hearings, you saw lots of finger-pointing and heard lots of blaming from all parties involved; none of which fixes the system problems.

You can avoid this scenario by using a straight-forward process for deciding to go live or not on the planned launch date.

Here are the steps in this process:

1. Establish Go-Live Criteria

Identify objective criteria that must be met for the project to successfully go live. Don’t say that everything must be complete; be very specific about what must absolutely be working properly at Go Live. Each project is unique, so your project’s criteria will be unique. Establish the criteria as soon as you know enough about the project to define success.  If you have a project charter, use it to identify success criteria. Add to the criteria when you know enough about what technically is needed for success. If you discover another success criteria later in the project, revise the criteria. Just don’t wait until the last minute to set the criteria.

The key to success on this step is involving the project’s business sponsor in this step.  The sponsor should approve the Go Live criteria and understand exactly how it will be used. Typically there are both functional and technical criteria identified. Depending on the nature of the project, there may also be regulatory and legal criteria.

Here are a few examples of typical go-live criteria, along with indicators for how you know that criteria have been met.

System Functionality: Critical parts of the system work as specified: Testing is the activity used to verify this criteria is met.  Specify exactly which testing must be completed such as user acceptance testing , performance tests in terms of response time, load tests, security tests, integration tests between the new system and legacy systems, data verification testing, etc.

Data Readiness: Data required to operate the system has been loaded and verified. If data conversion is involved, this has been completed and verified as accurate. Data conversion often requires a significant amount of data cleanup. If data in the new system is incomplete or inaccurate, a significant correction effort might be required after go-live. This can be extremely aggravating to users of the system. Report testing should be complete.

User Readiness: This may involve user training, new/revised business process training, user equipment, help screens, tutorials, documentation, etc.  Define exactly what must be complete, especially for critical users. By complete, I mean verifying that users have developed enough competency to use the system effectively and efficiently; not just that you’ve checked off that they attended training. If your users are the general public, be sure testing was performed by a sample of members of the public.

User  Support: User support staff  is in place, including any special help to be provided on launch day. User support may need to go beyond your usual Help Desk support, depending on the volume and sophistication of the users and the complexity of the system. For example, on site hand-holding might be offered the first week after launch. Manual backup procedures may be needed.

Operational Readiness:  Support infrastructure, equipment, tools and procedures are in place and ready for use. Operational staff are trained. Technical support staff is in place and prepared to handle reporting, prioritizing and fixing problems. Be specific about skill areas where support may be needed and staff appropriately for launch day: network, security, functionality, performance, data, reporting, legacy systems and testing professionals.

External Factors: Interfacing Organizations and departments have been communicated with and are ready for launch.

2. Identify the Decision Maker

The person(s) who accepts this responsibility must be willing to say Yes, the system is ready to launch or No, the system is not ready until unmet criteria are met.  This is why it is critical that this person be involved in establishing the criteria. If this person is not willing to say no, then he/she is not the right person to make this decision. It’s best if one person makes the decision, preferably the project sponsor. If it’s a committee making the decision, then it’s important that they work effectively as a group during the project, so when the day comes to make this decision, they will be able to reach agreement.

3. Set a Date for the Decision

Set a date for when the final decision will be made for the project to Go Live or Not Go Live. This date should be close to the scheduled go-live date, but early enough to determine if you can fix last minute problems and complete criteria testing.

4. Monitor Progress and Manage Expectations

Use your project’s Issues Log and Risk Management process as monitoring mechanisms. When updating the issue and risk logs, don’t sugarcoat, downplay or obfuscate what is stated. Be sure to include the impact to the go-live date. Create a project environment where team members know you really do want their honest, professional input.

Educate the project stakeholders especially those who can or might be critical of the project about the go-live criteria and the process for making the decision. Keep them informed about progress and issues so that when it comes time for a final go or no-go decision, they are not surprised. Again this means don’t sugarcoat, downplay or obfuscate the impact of issues when you update them.

5. Make the Go/ No Go Launch Decision

On the date set for the launch decision, provide the decision maker(s) with complete and straight-forward information about the state of the project in terms of the Go Live Criteria. Answer her/his questions in a straight-forward manner; don’t soft pedal or spin your answers. Be sure the Decision Maker is fully aware of and understands the consequences of the decision whether he/she decides Go or No Go. There are consequences either way. Help the decision maker assess which consequences are least costly and most helpful to the organization and its customers.   Saying No does not mean the system will never go live. It means launch will be delayed until all criteria are met. If the decision is not to launch on the scheduled date, develop a plan for fixing outstanding problems, completing criteria and re-testing including an estimated cost for the delay and a revised date for go live.

6. Communicate the Decision

The decision maker should be the person to communicate the decision including the rationale. If the decision was not to launch, then also communicate the recovery plan including the estimated cost for the delay and a revised date for go live . If there are people who choose to blame, the decision maker must be willing to listen to the criticism and not become defensive. If criteria was adequately identified, the decision maker was given full disclosure of the state of the project and made the best decision he/she could make, then he/she can typically live with the criticism and consequences.

 Optional Step

If the final decision was a no-go, then repeat the process to make the next go or no-go launch decision.

Straight Forward But Not Easy

Using this process may be straight forward but that does not mean it is easy. It requires building and maintaining a trusting relationship between the project sponsor, project manager and the project team. Establishing go live criteria together can begin to build trust in a new relationship. It deepens each person’s understanding of what is important to the other person in order to ensure success.

Saying No to a project launch is not something done lightly and is not easy. It takes personal courage and conviction that you are making the best decision you can to ensure a successful launch. It means you weighed the pros and cons, the short term impact and the long term consequences on all affected parties.  Saying No to a project launch takes courage. This process can help you find your courage by providing a solid framework on which to base your launch decision.

Comments

facebook like