Don't confuse Go-Live with the end of the implementation project! Or even the beginning of the end, assuming a short transition window. Of course there's no inherent reason why a project can't be designed for multiple go-lives, but this rule applies to project phases as well. Many large programs, especially those in the Department of Defense, confuse acquisition milestones and contracts management with go-live decisions. They are NOT the same. Make a risk-based decision - what's the risk to the business? - when determining to go live. Separate your program milestones and your systems integrator contract closeout from the go-live decision. Remember that the point of the program or project is to deliver capability to the organization. The sooner you can accomplish that, the better off your customers are.
Fundamentally, assess go-live readiness as a function of tomorrow’s risk being less than today’s risk. First, ensure compliance minimums are met (security, financial, environment, safety, occupational health, …). Second, triage those requirements that are not completed or fulfilled. Then ask: If the new system can deliver better than today’s, why not proceed?
Graphically, let’s view the question of today’s organizational performance as “risk that has materialized.” You can do better, but you’re being held back for some reason (the antiquated IT). Chart it out like the image below:
Now assume there are some must-have compliance requirements. (Technically that’s redundant – there’s no such thing as an “optional requirement,” but that’s another post.) Occupational safety and health items (confined space entry permits, or lock-out / tag-out check before work orders can be released), or environmental checks (permits preceding the release of production orders, such that discharges can be limited, or requiring the availability of waste disposal resources before a production run starts) may be required. Likewise assume some must-have’s in the security and financial side: FISCAM or Blue-Book compliance (DoD users know these well), or commercial equivalents like GAAP-compliant financials. In the health-care arena there is HIPAA compliance, and many organizations have union contracts that must be honored within the business processes and their controls. Depict these as vertical boundaries intersecting the materialized risk threshold:
Already you can begin to see the implications – there’s no upper bound to the “domain of right solutions!”
But let’s posit a specific state that we want to be in, as expressed in the requirements for the new system. That would be depicted as a point or a region within the (very large) domain of right solutions:
Now you get to assess where the new solution is within the infinitely large domain of right solutions. If it’s above the threshold that eliminates today’s risk, and is compliant with operational, security, and financial controls, then it is a “win” for the business.
There is still operational risk materializing – you can do even better. But you already have a project and a team in place to get those last benefits / meet those last requirements. Meanwhile, you can go live with what you have, delivering capability to the organization, and still complete the project to obtain all the performance that the business wants out of its systems and processes.
“Completion” and “Go-Live” then become two different measurements! The question isn’t whether the software is ready, it’s whether the organization is ready and can use the processes developed so far. A project, and the organization, are better off committing to later phases (spiral development, or new Agile “stories”) than they are delaying the go-live. The net/net is that capability is delivered faster, and (some) business benefits are obtained sooner. This is but one critical example where IT <> Acquisition Program Management <> Contract Management.
Have a strong and well-used Risk Management tool and methodology, and decide to go live on an assessment other than whether the requirements are met or the acquisition milestones are achieved!