Peter and I would like to welcome you to module four on change management.
During this particular module,
you'll be hearing about concepts of workflow redesign or re-engineering,
you'll be learning about the PDSA cycle and we'll be talking about change management.
It's certainly an exciting time right before Go Live, right Peter?
Maybe lots of sleepless nights for those who are involved and many moving pieces.
Can you speak a bit to past experiences with the time period leading up to a Go Live?
Yeah, for a really big project like for us our enterprise wide epic roll out of the EHR,
what we undertake is a actual fairly form will Go Live readiness assessment meetings.
For that process, it's
such a challenge because you've got all this different work being done,
people have been out doing that workflow redesign that built things.
They had been working toward getting ready
and everyone's got some ownership and there are different piece of this,
but from the standpoint of the overall project,
you have to figure out who's on track and isn't on track and it's
a very sensitive item because no one likes to be sort
of in a big group meeting and to be called out around that process,
but it really is important.
So, it for a big Go Live that impacts of a large enterprise and thousands of users,
we did those assessments at 90, 60,30,
15 days before the Go Live and had
developed a fairly formal process for reviewing where we were.
Right. At that time it's not just the one hospital,
but the other hospital and all the different departments who are
reporting on we're on track versus where a bit behind, but have a plan.
Yeah.
Versus we're in the red.
Right.
Those are the ones that you're calling the most attention to.
Touch on that a little bit more of what you said though
about how no one wants to be the one that's in the red
and how it can be difficult for people who take pride in their work to communicate that,
but it's so important and it's not a critique,
this is just a part of the readiness assessment.
Yeah, it's fascinating as someone who's been apart or trying to lead those,
it's important early on to coach people to let us
know when you've got a problem and to make sure that as a part
of zeroing in on that problem you're not making them
feel terrible for where they are and
encouraging that sort of candor because we don't have that,
you can't fix the problems and yet it's
such a hard issue because of the pride of ownership.
So, what I'll often do
is bring that up at the start of every one of the meetings make sure that
everyone understands those sort of ground rules or if
I'm not able to do that someone who's involves certain set that tone.
I think as a leader, it's important to,
yourself if you're involved in having gotten something to call yourself out,
and say, "Hey, I'm sorry.
In this particular case,
I didn't get this done or I did hear about that",
because what you'll see is discomfort on folks as to
whether they escalated or not and we do teach them to
escalate and so it's important to have the way
I describe it is have broad shoulders in this process.
See you if you can accept
whatever responsibility possible that tried to cover your colleagues.
At the same time,
this is the point where you're holding one another accountable.
So, really talented people are able to do both those things,
they're able to have broad shoulders and they're able to hold other people accountable.
I think that's a great technique that you talked
about in order to disarm individuals and make them more
comfortable really leading by example and sometimes taking that on
can make people exhale and feel a bit
better about acknowledging what resources they need,
because I think one of the most frustrating things for you as a leader would you say is,
when someone's tried to handle it themselves for too long and then you find out
about it because things have snowballed and that there's so much more undoing.
It's exactly right and this is exactly the same case as the clinical world,
where the less than you want is an internal resident who
has a patient who's deteriorating and they haven't escalated to get help the patient,
and so again, that's giving everyone a clinical analogy,
I think is helpful and also just setting examples of, "Hey,
last time, this group was in the red,
but they mentioned that they described it."
So, when you get to the 60 day meeting,
you point out "Hey,
you from the 90 day we've really made some great progress in
the following areas," and show success stories,
and make sure that everyone feels comfortable in the process.
Just to clarify for students, in module one,
we focused on organizational readiness for change and whether the culture,
and the systems, and the resources,
and the finances might support a large-scale change initiative.
The readiness assessments we're talking about here,
are once a lot of those decisions have been made and before going into production.
Can you speak a little bit about some of the testing that goes on
and I know that sometimes you know before it Go Live,
you can find out some surprises which you want to find out,
but it can be some difficult sleepless nights for folks.
Yeah, I mean, I guess I would summarize it there and there are
some real experts that can describe
all the different aspects of unit testing and integrated testing,
but I'll summarize it to say that you can
declare yourself to be in the green as
long as you have a very limited set of test scripts.
That's a good way of putting it. Right. Yeah.
But it doesn't necessarily mean that you're really
ready to handle all the complexity that comes up.
On the other hand,
if you have two and exhaustive set of test scripts,
you'll never be able to get them done and so
you'll require too long and the project will drag.
So, there's a sweet spot there and it involves always thinking through G,
what is it that I really do need to test for and certainly
looking back if you're rolling something out of your iteratively,
look at what went wrong last time or look
what recent problems have come up and refine your test scripts.
I think that's a great example of finding
the balance and sometimes it's tempting everyone wants an A plus.
So, if you have the four test scripts and you're acing them,
but then at the time when things go into production you'll be in for
some unpleasant surprises and along the lines of that,
can you speak a bit to the time period following the Go
Live and how important that is to be getting immediate feedback?
Once the system is live and having those channels of communication open,
it's not an abrupt ending.
Oh, gosh! It isn't and that you've got to have done enough work,
enough testing, enough preparation,
enough training, that during the Go Live,
you're not just completely overwhelmed by what the issues that people are having.
So, everything sort of comes together at that point.
