Ten years ago I became CIO of CareGroup. On that day, I learned an important lesson about leading change. Just hours after getting the job I decided that we’d embrace a service-oriented architecture (SOA), standardize all desktop/server/storage infrastructures and implement centrally managed applications.
Ten years ago I became CIO of CareGroup. On that day, I learned an important lesson about leading change. Just hours after getting the job I decided that we’d embrace a service-oriented architecture (SOA), standardize all desktop/server/storage infrastructures and implement centrally managed applications.
At 8 o’clock the next morning, I was scheduled to meet with my 300 staff members and share with them my vision for the future. Luckily, experienced leaders counseled me on that first day. I discussed my vision with three Board members; Warren McFarlan (Professor at Harvard Business School), John Keane Sr. (CEO of Keane Inc.) and Sam Fleming (CEO of DRI/McGraw Hill). They told me that announcing a strategic plan without engaging all the stakeholders in the process would lead to mixed support and adoption.
Instead of arriving at the meeting with all the answers, I arrived with questions. I explained to the staff that we wanted to improve customer service, encourage innovation and ensure our work was aligned with the needs of our stakeholders. I challenged them to tell me what they thought we should do. In the next 30 days I met with every staff member in IS as well as every senior manager in CareGroup to gather their priority lists, synthesize their input and ensure they had a voice in the future. The result was a new IS operating plan focused on getting the basics done right. We clearly communicated the work to be done; the next step was to implement the changes.
I’m a fan of John Kotter and his work on leading change. His recommendations include: defrosting the status quo; taking actions that bring about change; and, anchoring the changes in the corporate culture. The planning meetings described above defrosted the status quo. Here are the actions I took to bring about change:
Create a vision for change: The community came together with a vision of a Web-centric organization and I broadly communicated it.
Establish a sense of urgency: Everyone recognized that IT innovation was essential to coordinate clinical care, improve safety and enhance our competitiveness, especially after the merger of Beth Israel and Deaconess.
Elicit executive and peer sponsorship: The CEO declared that medication safety, personal health records and enhanced communication to all levels of the organization were the strategic goals of the entire organization for that year.
Communicate vision to implement change: We established steering committees, project charters, project plans and communication plans.
Empower employees to implement change: We aligned responsibility, accountability and authority throughout the IT organization so that managers had the resources and authority they needed to support our improvement efforts. We created a Special Projects team to coordinate the improvement projects without disrupting day to day operations.
Establish short-term goals: We created the first Web application in healthcare to share data (with patient consent) among multiple organizations. We created the first Web-based provider order entry system, and we created the first personal health record to share all hospital data with patients.
Encourage additional changes: We created a non-punitive culture in which everyone was encouraged to identify mistakes and opportunities for process improvement.
Reinforce changes made as permanent: We built standard processes to deliver service, prioritize new projects, and communicate our multi-year plans to the community.
That first year we implemented strong project management methodologies, eliminated unnecessary work and focused on getting basic services like e-mail, networks, storage and electronic result reporting rolled out to everyone in the community.
Since then I have relied on my IT governance committees to prioritize change based on strategic importance, impact on patients, improvements in quality/safety and return on investment. To align clinicians and IT, I have a clinical information systems steering committee with membership from 11 subcommittees including: the Chair of the Laboratory Information Systems Committee; the Chair of Radiology Information Systems Committee; the Chair of Critical Care Information Systems Committee; the Chair of Inpatient Information Systems Committee; the Chair of Ambulatory Information Systems Committee; the Chair of Health Information Management Committee; the Chair of Community Information Systems Committee; the Chair of Decision Support Information Systems Committee; the Chair of Revenue Cycle Information Systems Committee; the Medical Executive Committee Representative; and, the Operating Room Executive Committee Representative.
When I execute complex clinical projects each year, I’m typically asked three questions about my approach to leading change in healthcare:
What are our biggest challenges running large clinical information systems projects? Every project must start with a charter that identifies the stakeholders, roles/responsibilities and the purpose of the project, and the milestones and metrics for success. The only way to balance scope, timing and resources is to have an unambiguous definition of who cares about the project and who does the work, why the project will be done, when the project will be done and how success is defined. As the project proceeds, there will be many requests to expand its scope, add more features, increase the number of interfaces and expand the stakeholder population being served. The committee providing governance to the project, guided by the charter, must resist the change in scope. If change in scope is deemed critical to the project’s success then the charter should be changed to reflect the impact on project timing and resources, ensuring that the change is broadly communicated.
What are the biggest mistakes? Projects must ultimately be driven by their business owners such as the doctors, nurses and staff who’ll be using the finished system, not by IT. Having clinician-driven projects ensures the application becomes “the clinician’s system” and not the “IT system which administration forced on us.” Also, software should not be used to change workflow. Before implementation of the software, business processes should be optimized and workflow documented. Then, software can automate that workflow. If software is used to force behavioral change, clinicians will blame it for any frustrations they have about the process change.
What are the top three best practices to ensure success? Big bang IT never works. Pilots and phased implementation of applications reduces the risk of failure and ensures the resources are available to respond to any infrastructure or application issues which occur during roll out. Broadly communicating the benefits of the project and the urgency to implement it really helps with clinician acceptance/adoption. Project management is key. Ensuring the scope is constrained, milestones achieved and participants coordinated are prerequisites to a successful project.
As a clinician myself, I use the systems we create. Being a physician CIO/CMIO helps me understand the clinical impact of every project, engage the clinicians in every project, and establish trust with all the doctors and nurses in the hospital.
Occasionally, I try to execute a change management project more quickly than usual, bypassing my own advice. Whenever I do that I find that adoption of the new technology is delayed, budgets are at risk of overrun and frustration escalates.
My decade of experience executing change suggests that Kotter was right. Building a guiding coalition, broadly communicating the vision and celebrating a series of short term successes really works. I’ve watched projects without vision, resources or communication cause pain and anxiety throughout the organization. The good news is that we now know how to execute change and it is the role of senior management to enforce Kotter’s principles in every change project.
