“There are no secrets to success. It is the result of preparation, hard work, and learning from failure.”
Review the importance of planning early for the implementation and activation of a project.
Develop an activation plan from the initial brainstorming activity to the final version that can help mitigate the risks associated with system activation.
Describe a variety of plans and tools that can assist with planning for system implementation.
Articulate the use of a communication plan to document who, what, when, and how activation communication should be conducted.
The activities surrounding the implementation of a new system will vary depending on what is being implemented. Most activities will need to occur, but the specifics may vary. There are very few references on the best practices for implementation planning, but this chapter will provide some guidelines and tools that will assist with implementation, activation, or going live, as well as when variations will occur and why.
The type of project will influence the amount of planning required, when you should start, and what activities will be needed. These activities include determining what needs to be done before, during, and after activation or going live, and who will be doing those activities. When will people need to be onsite, and where will they be located? Communication is always required, along with just-in-time training and support.
One example is the implementation of a new application where the processes are moving from manual or paper to electronic. Everything is all set, and it just needs to be turned on—right? It is never that easy. After the application has been designed, developed, and tested, there are still some details to work out and tasks to be done. For example, will information or data need to be loaded into the new system? If this is an electronic health record (EHR), will all active orders need to be added? When will that occur, and by whom?
Activation planning should occur early in the project to allow enough time for decisions to be made and details to be worked out.
Small project - start planning 2 months out
Larger, more complex projects - start planning 4 to 6 months out
Another example would be an upgrade to an application that is already in use. Typically, the application needs to be turned off for the upgrade to occur, which results is a period of downtime where the end users cannot access the system. Planning needs to include how patient care will continue without the application as well as how information will be entered after the application is back up and running. Control of the upgrade tasks is essential to ensuring the shortest possible downtime. Adding new functionality or a new interface between two applications may require a different set of tasks and may or may not require downtime.