Go-Live is a Crucial Step in Planning for Success
By Mary Theel, RN, MSN, Senior Consultant, Application Services
“Go-Live” can be considered the moment changes and/or a new process is introduced to our users. This needs to be closely considered and planned during the initial planning process. Items to consider would include setting a target date, the go-live event and how it will occur, and what the needed resources are for the go-live.
The events of the go-live depend on the actual changes occurring, ranging from a code upgrade to an implementation of a new form and process for an individual department. The impact to the user needs to be determined: Will there be a downtime in which the system is unavailable to all users or is it a change in workflow for a select group of people? This impact needs to be clearly communicated to all persons directly or indirectly affected by the new change.
Implementing the Change: Passive Changes and Cutover Steps
There are often two major categories of implementing the change. One is passive changes, or changes that can be introduced and hidden from the user until they go-live. Completing passive changes will facilitate the go-live event. This may be a PowerPlan™ that remains in a testing mode, a build that is not released to the positions, or a package that is installed to prepare the domain.
The second change category involves cutover steps. These need to be planned and taken at the time the change will impact the users. For example, a front-end scan (cycling the Citrix servers) would require the user that is on the affected server to sign out but not necessitate a complete downtime. Required build steps may need to be taken right before the new functionality is available to the user. These may be to change the status of the new build, so it is available. There are often security changes to give the new functionality to the appropriate user.
Go-Live Support
Prior to the go-live, review the status of any issues or risks that exist and determine what could be a showstopper. Determine how any issues could be managed to mitigate a negative impact with the go-live. A “Go/No-Go” meeting should be held with the project team and stakeholders to make the final decision for implementing the change.
Go-Live Support and resources needed will depend on the extent of the change. Recommended resources include technical support, subject matter experts (SMEs), and super users/champions who will all receive and investigate issues reported to a central location. Technical support will be available to perform high-priority fixes. SMEs are available to assist in process decisions, and the super users/champions will be available to provide face-to-face support for the users involved.
For a major change that will impact a larger number of people, set up a command center or central office to receive all calls. The center needs to have a staffing plan with schedules for each person. The length of maintaining this center will be determined by the actual change, however, be prepared to cover 24/7 for a period of days as necessary for a major system change.
A communication system needs to be set up so incoming calls can be answered immediately. Contact number and FAQs/ informational memos need to be published and distributed throughout the organizations or to the impacted users. Remote communication to support staff outside of the office will need to be defined.
It is best to place the super users within the work area with their peer group. In addition, a super user may be assigned to make rounds through the facility. Their role needs to be clearly defined and communicated. They need to understand change control principles so they can communicate accurately any request they may receive. Always have a physician liaison available.
The organization may choose to use elbow-to-elbow support in which a super user or champion is paired with a primary user and follows them throughout the day. This person should have a previously established professional relationship with this user and understand the current state and the changes occurring.
All issues and calls should be be received and recorded in a central location. One person should be assigned the responsibility for collecting, documenting and triaging the issues. The triage process would determine if the issue is a patient safety, financial issue or interruption in clinical workflow. These become a high priority to investigate and fix. Other issues may need to be addressed with process definition or training. Personal requests for changes should be addressed after go-live.
Monitoring: Wrap-Up and Lessons Learned Meetings
Wrap-up meetings need to be held regularly during the go-live period and continue until determined they are not necessary. The meeting is a report format/communication of the events, findings or issues that occurred since the last meeting. Include all team members in the meetings as problem solving, process redefinition or education may be discussed.
Go-live is often considered the end of the project, however we need to consider it as a critical stage in the project. Post implementation, schedule a lessons learned meeting two to three weeks post go-live. Include all members of the project team to report what went well and why. It can also include discussion of unintended outcomes of the change. How could they have been avoided and what should be done differently in the future for a similar implementation? Additionally, you will want to create a plan to address maintenance and ongoing support.
At HPG, our expertise goes far beyond EHR implementation. By connecting as a partner for our clients and working as an extension of their team, we provide the highest levels of support, agility and strategic guidance available. Our expert consultants are ready to assist with similar projects in the future.
