A significant part of my consulting practice involves conducting autopsies on large, failed IT projects. Appallingly, most of the disasters could have been anticipated from the data available during the project. While project teams are rarely surprised by the outcomes, sponsoring executives are often unaware of the looming tragedy until it unfolds—sometimes at the expense of their careers.
One preventable cause of these disasters is premature go-live.
Sometimes compelling factors drive go-live date targets. For example:
- High-visibility commitments may be difficult and embarrassing to walk back (think: the HealthCare.gov debacle).
- Defaulting on contractual commitments may have significant financial consequences.
- Reputations may be damaged by the failure to meet a promised date.
- Significant costs may be required to continue the current solution past the cutover date (such as renewing expensive leases, licenses, or maintenance for equipment, software, or real estate).
- People currently working on the project may be needed elsewhere, creating a resource crunch that would impact other projects if the current effort were extended.
Most of us have experienced these schedule pressures; they are legitimate, and I don’t intend to minimize them. But, as real and daunting as these pressures can be, they have to be balanced with the consequences of a potentially disastrous premature go-live. We must consider both scenarios in our decision-making.
Estimating implementation time frames is an imprecise science, subject to error as well as externally imposed risk and uncertainty. As our information systems become increasingly interconnected and sophisticated, coordinating significant changes takes time, patience, and hard work.
Systems often have substantial elements of organizational change that must be addressed prior to go-live. If your new or changed data system requires meaningful alteration in how people do their work, significant time may be required to understand the implications of the change, modify work processes, and develop and provide training to users. Changes in the workflow may have ripple effects in other parts of user organizations that must be understood and dealt with.
Replacing all or part of an existing system can also be complicated by differences in how data is captured and stored between the old and new systems. The mechanics of stopping an existing system, converting and loading data, and restarting the new system are easy—and devastating—to underestimate.
A consultant working on a fixed-price, fixed-schedule project recently advocated for going live on the appointed date, saying glibly, “People are never ‘fully ready.’ Sometimes you just have to flip the switch and deal with the consequences.”
What gave me pause (and prompted this article) was that we were discussing a public safety system in which people literally could be harmed or killed if the implementation had significant problems that could not be promptly remedied.
Before you find yourself advocating similar idiocy, I encourage you to consider the following questions about readiness for go-live.
1. Is your system ready?
Has it been thoroughly tested? Is there an honest assessment of the quantity and priority of known defects? Have business users weighed in with an informed opinion about the acceptability or the feasibility of workarounds for known issues?
2. Are your data exchange partners ready?
Have interfaces been tested fully? Is instrumentation in place to monitor traffic and identify problems? What is the business impact to your system and your partners’ systems if there is a significant disruption of data flow or a significant error in the data? What are the consequences of data delays? Can your data exchange partners support your cutover date?
3. Are your users ready?
Have the implications of changes been thoroughly analyzed and communicated? Are users ready for the changes to their workflows? Does the organization understand the secondary effects of these changes on adjacent workflows? Are user staff sufficiently trained on the new system? Will there be enough staff available during cutover to deal with the learning curve of the new system and processes and work through unforeseen issues?
4. Is the information systems infrastructure ready?
Are you confident that there is ample processing, network, and storage capacity to support the new system? Are help desk staff and operations staff trained and ready?
5. Is there a go-live playbook or schedule?
Did you provide details of the steps required to gracefully deactivate the current systems, migrate data, convert interfaces, and begin processing with the new system? Are roles and responsibilities during cutover clear? Are the timings of the cutover schedule reasonable? Has there been a successful dry run?
6. How and when will you know that the cutover was successful?
Success here would mean not just all aspects of the technology, but also the impacts on the workflows and humans who interact with the system. Has monitoring been established to provide early warning of problems?
7. What are the consequences of a failed implementation?
Have you considered the failure modes of the new system and the associated risks to your mission and that of your partners? Are there feasible workaround processes in place should cutover disruption be extended?
8. Is there a feasible fallback plan?
Can cutover be aborted if significant issues are discovered? How long can the new system be in place before the cost and complexity of backing out of the system will be prohibitive? What is the “point of no return” on the implementation? Is the fallback plan as detailed as the go-live plan? Has it been tested?
Tim Lister is one of software project management’s guiding lights. A few years ago, he gave a conference presentation about estimating called “We need it by October: What is your estimate?” in which he railed at the strong desires of powerful people that overwhelm the honest assessments of schedule and risk that were delivered by the people who must do the work.
The same concerns and risks apply as projects approach their go-live dates. Before succumbing to the inertia and inevitability of a committed date, it is imperative that an honest assessment determines whether the system and the ecosystem in which it must operate are ready for the transition. Rather than focusing on the list of reasons why a system “must” go live on the appointed date, have a candid conversation with executive stakeholders about the true status of the effort and the potential consequences of a failed implementation.
Let’s apply these eight considerations to the implementation pressures identified at the start of this article.
High-visibility commitments may be difficult and embarrassing to walk back: Which is more embarrassing, having to postpone the date because the implementation isn’t ready, or a premature launch that suggests either complete disregard of the fact that the system wasn’t ready or incompetent monitoring and managing of the implementation?
Contractual commitments may have significant financial consequences upon default: Are there no contractual consequences to a failed implementation? Are the cost implications of failure less than the cost of a change order or amendment to the contract?
Reputations may be damaged by failure to meet a promised date: Which reputation would you prefer, one for foolishly proceeding toward disaster without regard to the consequence, or one for admitting that there were issues and risks and encouraging management to address them before they become disasters?
Significant costs may be required to continue the current solution past the cutover date: If the implementation is a disaster, these costs may be necessary anyway, except now they must be negotiated from a position of panic and weakness. The costs will be compounded by the expense of cleaning up after the disaster.
People currently working on the project may be needed elsewhere: If the implementation is a catastrophe, those same people will likely be required to help clean up the mess, resulting in the same disruption to the subsequent projects—but denying those projects early warning to deal with resource issues that could have been anticipated.
The most useful question in my kit for discussing project risks with powerful executives is this, which I ask at the start of each engagement:
If, at any time, I develop concerns about our ability to successfully deliver this project according to your time, cost, and scope goals, when do you want to know?
I have been asking this question professionally for twenty years, and in twenty years, no executive has ever responded that he or she didn’t want to know promptly. The times I have had to deliver bad news, it was disappointing and frustrating, but no one ever said they would have preferred not to know.
Don’t let all the reasons a system simply must be implemented by a target date overwhelm compelling evidence that the system or the organization it supports is not ready. Treat your executives the way you want to be treated. Deliver the truth and support their informed decisions.
Going live on time should not be the default. Going live when the system and organization are demonstrably ready should be the goal.
User Comments
Great article.
I would add 'is your business ready?' Often times, engineering/development is ready but the other departments impacted that are responsible for customer enablement such as Support, Product Marketing, Marketing and Sales are not ready. These teams need to be enabled pre, during and post go-live.
Yes. All of these.
To #1 I would add:
(A) do you have a plan -- agreed with your business stakeholders -- for addressing and implementing outstanding high-priority defects? Sometimes a workaround that sounds sustainable for a few weeks becomes intolerably burdensome over a month or more.
(B) does the business understand and agree to the cumulative effect of all the agreed workarounds? And is there training in place to ensure workarounds are implemented? (Including for the help desk?) These are obviously important when you have a large number of outstanding defects. Business stakeholders may have agreed to each workaround in isolation, but become concerned or even overwhelmed when confronted with the whole picture.