The Project Go/No-Go Checklist
By James W.J. Hutt | minute read
Many projects have failed at the last hurdle due to poor implementation planning or inadequate analysis immediately prior to go-live. It is the project manager's responsibility to ensure that the implementation has been planned out and communicated to stakeholders, and that sufficient due diligence is undertaken before the project proceeds. This second point is often overlooked. Many project managers put together some form of implementation or cutover plan yet fail to carry out the necessary rigorous analysis to determine whether they should proceed. This article focuses on this analysis - what is termed the 'go-live decision'.
The decision to go-live or not should not be taken lightly; it is without doubt one of the most important decisions in the project lifecycle and getting it wrong can jeopardise the success of the entire project.
Going-live without everything in place may result in:
- Unresolved defects
- Inadequate testing
- Insufficient training
- Business processes not understood
- Procedures not written
- Stakeholders missed
- Lack of communications
- Data migration failure
- Interfaces not working
- System administration and support not in place
- Business areas not ready for the changes
- No contingencies in place
- Workflows and exceptions not mapped out
- No backups and disaster recovery in place
- Inadequate system security
- Unclear responsibilities, accountabilities and ownership
- Inadequate implementation strategy
- System/application failure
- Impact to the business/organisation
- Project failure
Whilst the project manager is always under pressure to deliver within schedule, sometimes it is prudent for them to step back and delay go-live rather than risk the consequences of steaming ahead.
What due diligence needs to be done?
Ideally the project should secure an independent resource to perform the readiness assessment. If the analysis is undertaken by the project manager, or people closely associated with the project, there is a risk of bias or influence from the pressure to implement on time. Using an independent resource provides a level of impartiality and therefore credibility to the decision making process. It is also useful to get an outsider's perspective, especially if it's from someone with years of project experience and knowledge. Well funded projects often employ outside consultants to perform audits and health checks throughout the project lifecycle, including the go-live readiness assessments.
Unfortunately not all projects have the means or desire to employ consultants, and therefore need to utilise internal staff. In this case it's best to use a resource with prior project experience (e.g. another project manager), but with no vested interest in the outcome of the project. This improves the chances of an objective outcome and recommendations. Remember, it is in the project manager's interests to get an honest assessment of where the project is really at, as any major deficiencies must be either addressed or mitigated against before go-live. If the outcome of the assessment is pre-determined or intentionally slanted, there is little point in doing the assessment!
If it's not possible to secure an independent internal resource to carry out the readiness assessment, the project manager can do it themselves. However they need to make sure that they give an honest account of the situation, ask searching questions of people and don't hide issues. These assessments should never be conducted without extensive consultation, as it's vital to speak to as many project people as possible to find out the true state of play. Some people may hide issues or only tell you the positives. It's important to get the 'warts and all' view, as any major issues and roadblocks must be uncovered and addressed before a decision is made.
What should the assessment cover? Rather than starting from scratch, it's easier to use a Go/No-Go checklist. This provides a starting place, based upon common best practice, and ensures that you won't miss any key areas in your review. Use what's in the checklist to prompt other questions and checks that may be relevant to the project.
The project does not have to tick all of the boxes to proceed, and there is no required score or pass/fail mark. However, if there are several glaring gaps the decision becomes fairly obvious. The checklist helps to identify serious gaps and deficiencies to be addressed before go-live. It may also provide support for further funds or resources if a particular area needs addressing. The checklist should support the decision making process, rather than form the basis of a decision. Whoever makes the decision (normally a steering committee) must also consider the bigger picture and include other factors such as external pressures, urgency to proceed, appetite for risk, consequences of delays, etc.
If significant gaps are identified, it is usually far better for all concerned to delay implementation until these gaps have been addressed/mitigated. The implications and costs of a failed or troublesome go-live are often far worse than a minor delay in the schedule. The only exception to this is if there is a non-negotiable implementation date (e.g. a response to legislation changes that have to be in by a certain date). In this case the gaps on the checklist should be prioritised and addressed in order of importance and ability to resolve. In this case by going-live the steering committee would essentially be accepting the risks identified in the assessment, on the basis that meeting the implementation date is more important than mitigating the risks and having a smooth go-live.