Ready or not, here they come

A lack of operational readiness when IT go-lives begin can throw participants into confusion and panic – and an otherwise well-run IT project will be perceived a terrible failure.

young boy hide and seek game hiding
Thinkstock

Do you remember playing hide and seek and hearing the seeker call out, “Ready or not, here I come!”

Despite the loud warning from the seeker, if the participants weren’t ready, it just wasn’t a fair game.

Participant readiness is just as important when it comes to major information technology (IT) implementations or upgrades. Just like the unready participants in a game of hide and seek, a lack of operational readiness when IT go-lives begin can throw participants into confusion and panic – and an otherwise well-run IT project will be perceived a terrible failure.

Operational units, key stakeholders, educational personnel, support teams, hardware capacity, communications personnel, help desk support and other stakeholder areas must be properly prepared and made ready before go-live. The traditional IT concerns with schedules, carefully configured software and hardware, meticulously followed user requirements, strict adherence to vendor requirements and so forth are important – but readiness must also be a major focus. Otherwise we will experience the phenomenon of IT celebrating an implementation success, while a confused customer population sees the implementation as an abysmal failure.

It is not unusual to hear bewildered IT professionals defending themselves against complaining customers by citing their sound project execution and faithful adherence to ITIL. Too often, the IT success metrics are focused on getting the system live instead of delivering a satisfying customer experience, which should include:

  • A low level of pain and stress during and after go-live
  • Support and just-in-time training sufficient to ease adoption during the go-live
  • No surprises in the way the user interface operates
  • No surprises in workflow changes
  • No loss of function without mitigating measures put in place
  • No new functionality with which users are unfamiliar
  • No degradation in performance, especially terminal response time
  • Easier rather than more difficult application navigation
  • No loss of reports or loss of information on reports
  • No hidden workload foisted upon users because of system design
  • No maintenance responsibilities to which no one is assigned
  • Timely training focused on the way users do their work (workflow based training)
  • Communication of issues as they are encountered and a plan to rapidly respond to the unexpected
  • Communications throughout the project to keep users informed

The best way to guard against “ready or not” style implementations is to develop an operational readiness playbook to accompany the implementation plan. The operational readiness playbook views the implementation through the eyes of the customer rather than the eyes of IT technicians who are governed by a different view of reality.

The IT view is not wrong, but it is incomplete. An operational readiness playbook will provide a repeatable process for ensuring successful go-lives – and it can be updated as organizational dynamics create new factors governing success.  

Often implementation plans are based upon the best-case scenario where all things work as planned, but this is not reality. Implementers must use “what-if” scenario-based planning to anticipate what could go wrong and then develop plans to react if any of the scenarios occurs.

For example, what will you do if the estimates for upgrading server capacity were wrong, and the application begins to run slowly? Or, what action should be taken if we discover a large number of physicians missed training and are now struggling with the go-live?

Potential detractors, historically disgruntled users or other stakeholders likely to be dissatisfied with the coming changes need to be identified and measures taken to reduce their disruption and likelihood of putting a bad face on the implementation. LEAN Six Sigma suggests creating a stakeholder management plan as a way to ensure challenging stakeholders don’t derail your project, and to make sure supportive stakeholders feel empowered and informed. For each stakeholder, identify the issue to be resolved, the actions needed to resolve the issue, a completion date, and person responsible for taking action. 

Communications can go a long way to ensuring organizational readiness, especially if the communications are two-way. IT leaders must listen carefully to uncover both the real and imagined issues of stakeholders, and prepare a plan to communicate effectively the project team’s plans to address these concerns.

Another tool from LEAN Six Sigma is helpful developing your communications plan. The idea is to know who you need to communicate to as well as what, when, and how for each stakeholder. As well, it includes a feedback loop plan to test if the communications were effective.

These and other creative readiness practices will eliminate stakeholder panic and drive project success if instead of the old ready-or-not approach IT announces, “We know you’re ready, so here we come!”

This article is published as part of the IDG Contributor Network. Want to Join?

SUBSCRIBE! Get the best of CIO delivered to your email inbox.