Now, for a bit of change in focus.
I think it’s important to understand how change methodologies work in the context of software implementation, while still keeping one eye pointed on how these methodologies might work in social change efforts.
To repeat my hypothesis, some change methodologies and experience in corporate sectors can be transferred to efforts to make social change, and that these methodologies, well implemented, could be measured and shown to be much more effective than traditional organizing efforts. Again, this is simply a concept I’m playing with and welcome feedback from readers.
I realize that just because change methodologies utilized in a corporate environment often work to help individuals accept and embrace change doesn’t necessarily mean they can be successfully applied in the framework of social change in the larger community.
From my experience, in some cases the methods and tools work well and other times the result is not so clear.
This article is to explore a case study of when and how change methodology worked and did not work. My hope is to level set with how change methodology can be effectively utilized in a corporate setting and to challenge myself and readers to transfer these learnings into a new model for social change applications.
Here are a few accountings of experience to demonstrate.
The Nightmare
When a software implementation goes sour in a healthcare environment, the consequences can ripple throughout the organization and into the patient community. Such an experience happened last year with an integrated software tool that was designed to help Radiologists with documenting their consults, viewing their patients x-rays, and managing their schedule.
The project resulted in a less than optimal implementation and for purposes of learning I want to explore what went wrong.
Poor planning: the first fatal flaw
imagine waiting for a dozen years to finally get the funding for improving a legacy system that didn’t meet the needs of clinicians, techs or patients. The anticipation and expectations for this system were sky high.
Now, imagine that anticipated project being sandwiched between the implementation of the organization’s largest software implementation and the end of a fiscal year. Four weeks after the implementation of three sophisticated software applications throughout a 260+ bed hospital, the new Radiology system took its turn at the plate, hoping to survive the go-live experience.
The story’s details are less important that the outcome, which featured unhappy end users, broken functionality in the system, and unclear work flows. This interruption in patient care took on the form of internal protests, poor treatment of administrators and helpers, and demands for changes.
The poor results can be traced back to poor planning, and playing a starring role in this production was poor leadership, and poor decision-making.
Poor leadership
This is the most critical factor and examining what went wrong it’s clear that the lack of senior leadership attention (which was largely diverted to the inpatient implementation) allowed for poor project leadership to fumble its way to implementation.
Project leadership had no sense of change management, effective communication, team building, end user readiness, and effective decision-making. With no mentorship, and little accountability, the project allowed for the configuration, design, and testing to be closely monitored, but the preparation of end users for the change suffered from lack of skills on the project team.
To examine more closely, leadership failed to engage Imaging management with the expectation that the managers lead the change effort at the local level. Instead, managers who were only slightly resistant to the change didn’t understand their role and how to prepare their staff and the physicians for the change. Not having experienced a software implementation, they didn’t know quite what to do and the project leadership didn’t have a plan to help them.
Poor decision-making
Before going much further, I want the reader to understand that implementing electronic medical record systems is extremely complex, and being still in its infancy the methodology is still evolving.
Still, decision-making as a basis for any kind of effort should be more refined and not be part of the reason a project fails. In this case, my supposition is that poor methods of decision-making, including the project leadership’s inability to call the question and force decision-making, sabotaged the potential success.
The lessons here can be as simple as proper meeting process, facilitating of discussions that should lead to decisions, and improving the ability of decision-makers to understand their shared destiny.
Ignoring these fundamentals doomed the effort
In short, nothing went well.
In Sum
So in examining how to avoid such a debacle in the future, a few key things were called out:
1. Leadership of the Imaging department had to make faster, more complete decisions about how the work was going to flow in an electronic system, and how to get users of that system to adjust to the new workflow. The lack of investment in change management resources and tools made a difficult effort all the more challenging.
2. The system build had to be completed with firm, non-changing decisions with plenty of time to build training curriculum and conduct effective training.
In fact, changes to the system happened just weeks and in some cases days before the implementation, and during the time end users were being trained. That resulted in the system looking significantly different from the training environment from which the end users were being trained. Big mistake.
3. No change management. Somehow, the organization I work in sees change management as a valuable tool to help move end users to acceptance of change, yet doesn’t allocate resources. There are areas where change management is in place–for example, training and supporting new users to work in the system is an undisputed need that receives funding without a challenge. But getting users ready to participate in the training, to be pyschologically ready for change and have their concerns/questions addressed, is just not built in. Therefore, it’s largely not done.
Recounting the nightmare is not helpful (though possibly entertaining). What’s important to know is that the Radiologists involved revolted, and as a result got part of their legacy system back. Any of them who had crossed over that psychological hurdle to embrace the changes have now been empowered to resist.
The Antidote
Telling the failure story is difficult, and incomplete as well. Changes continue to happen over the year since the implementation failure occured, and many improvements were built into the system to better work for the Radiologists and Techs who use it. But the damage was done.
In my next article I’ll explore how these lessons learned were translated into new approaches that led to very successful implementations.
