Improving the LSS Data System Upgrade Experience
A couple weeks ago one of my clients upgraded their LSS Data Systems software from 6.07 to 6.08. I am happy to report that on Go Live day the code move went faster than expected (although the Meditech side of things had some hiccups which caused delay) and the issues resulting once users were back in the system were fairly minimal and weren’t overly stressful on the end users. If one were to step in on Go Live day they would certainly conclude that it was a successful Go Live all around.
Getting to that point though was an entirely different story. In terms of functionality, this should not have been considered a major upgrade. A handful of new functionality items were put in, but the vast majority of the patches were for bug fixes (as they always are). Provider training on the new functionality lasted about 1/2 hour in groups, nurses didn’t require any formal training sessions, and the front desk workers spent about the same time training as the providers. Yet, from upgrade presentations presented by LSS to Go Live, the whole process took a hurried and somewhat stressful 5 months to accomplish. No, it wasn’t because of bad employees, it was because of a systematic failure.
From a client’s perspective, there are some pretty basic steps for them to complete an upgrade. Those are:
- Figure out how the new stuff works and how you can use it.
- Build and test the new stuff.
- Train people on the new stuff.
- Celebrate after the new stuff is live!
Therefore, if a vendor holds up step 1, people start to get a little cranky. Especially if you’re holding up that whole celebrating thing. Each step is dependent on the prior. For this upgrade, people were so cranky we didn’t even do step 4.
In the first draft of this post I was going to list everything LSS did wrong, but there were so many repeated mistakes that it got boring. I didn’t even want to get into the number and turnaround time of bug fixes that were needed. Let’s face it, those are always an issue. Instead, I’ve listed out the highlights chronologically based on reviewing e-mails and calendar items for your enjoyment. But first, here’s how LSS can improve the upgrade experience for their clients. These are really groundbreaking ideas, guys!
- Release good code. Everything goes better if you test correctly. Don’t ask your clients to “Partner” with you and make them test your code.
- Document what was changed from the previous release in terms users can utilize for build and training. Also, put this together before giving an update to a client…then give that documentation to the client when they get the code.
- Train your specialists on the changes in the upgrade. This shouldn’t be a “Let’s figure this out together” experience.
- Tell the client all the things you will be doing throughout the update.
And now, I present a timeline of events so you can relive this experience too:
Late April – Began asking for full set up guides of the new functionality
pieces.
May 9 – Escalated to director level who responds that all guides and
presentations are on the website and available. Turns out they aren’t.
About 50% are.
May 15 – The new test directory is set up by LSS and content is copied from
the Live directory without telling anyone.
May 17 – A detailed comparison of what is and what is not on the website is
delivered to the Director. LSS proceeds to put up 80% of the guides. The
director e-mails back to tell us to look harder at the website, because
they’re really there. We are also alerted that the remaining documentation
does not exist, because the functionality will not be available in our
release. LSS will provide a top-off release that will include the remaining
pieces of functionality.
May 17 – A call is held with specialists, supervisors, and the director to
discuss unresolved bug issues, and when new code will be moved in and from
which directory content will be copied from. Numerous technical issues crop
up when attempting to follow instructions from LSS on putting patients into
the new test directory. An e-mail is sent to the Associate VP of LSS.
May 20 – Monday morning response from the Assoc. VP acknowledges vast
communication failures throughout the timeline of the project thus far. Vows
to correct this…by setting up a weekly update call specifically for the
update. This is in addition to normal weekly service calls.
May 24 – LSS supervisor contacts the client about a Go Live Plan and to set
up a weekly call.
May 25 – It is discovered that the set up guides are not entirely accurate
or complete.
May 31 – First weekly update call happens with LSS supervisor and
specialists. At the start of the call, LSS asks the client what they want to talk about. Client requests correct information about what is included in the update.
June 3 – LSS offers a site visit to help allay concerns. An LSS director
asks for a visit agenda for a the visit he suggested. A walk-through of all
new functionality is requested. It is stressed that the concern is for
clinical functionality only.
June 7 – LSS decides that the update calls can be handled by specialists
without a supervisor there. They suggest bringing a billing product specialist and
a clinical product specialist out on site. It is again stressed that clinical
functionality is the concern. The clinical specialist notes that he has not
been fully trained on the new functionality.
June 17, 18 – An LSS clinical product supervisor and a billing product specialist visit, numerous clinical issues are found and concerns about the new functionality are jotted down. Additional questions are raised on how the new
functionality works. It is stated by LSS that a third party vendor will be
necessary to contract for a piece of the functionality that will be brought
up with the update. Go Live date of Sept. 4 set.
June 19 – Build and cycle testing of new functionality starts fresh.
June 24 – Weekly update calls are resumed with manager and specialists on
call.
July 8 – Nonchalantly, LSS releases a compare document showing differences
between the old release and the new release. Armed with new information,
cycle testing and build pushes forward.
July 12 – Call is had with another client, the beta site for the latest release. They report that everything worked perfectly and that minimal technical issues were
found. My client has serious doubts about the authenticity.
July 15 – LSS manager asks if LSS has provided all of the project management
documents and assistance that was originally requested. The correction is
made that the original and all subsequent requests were solely asking how
the new functionality works.
July 22 – LSS asks if we remember that whole needing a third party vendor
thing for a piece of functionality, because that wasn’t actually true…
July 29 – LSS moves in a code top-off that contains the remaining
functionality pieces that were previously going to be part of the original
code. Documentation is again asked for and not received.
July 30 – Integrated testing scenarios between LSS modules and Meditech
modules are executed. Numerous issues are found with the connections.
August 8 – LSS announces changes to their support structure.
August 12 – It is realized that one of the newest pieces of functionality
that everyone was really excited to get doesn’t live up to the advertising
and will not be used because it is a huge letdown.
August 15 – Most technical Go Live issues are resolved by LSS.
August 19-23 – End-User training is executed. Providers received 30 minutes
total of training each because the visible updates were fairly minimal.
This bucks the LSS director’s recommendation of 8 hours per users of upgrade
training. Clearly, he took a conservative CYA approach for his estimation.
August 22 – A list of fields to copy to Live is given to LSS for Go Live
day. Some mysteriously cannot be copied for unknown reasons and therefore
must be built manually.
August 27 – After receiving a request for a list of Toolbox parameter (settings only LSS can change) changes between the old and new version the specialist escalates this request to his supervisor.
August 28 – The supervisor responds to the request with a quick “You don’t
need to know, but if you want to go look yourself”. I do go look myself and
find numerous new fields that have no documentation.
August 29 – All Go Live barrier issues are resolved. Annoyances remain. Client declares they are good for Go Live on Sept. 4.
August 30 – The LSS specialist tracks down what the parameters do by asking
LSS development. It is assured that no negative effects will be had by not
filling them out with the exception of those connecting LSS to the client’s
patient education server that were entered during the set up process. Those
should definitely be copied into Live on Go Live day.
September 4 – Code is moved into Live. Manual transfer of fields completes.
Testing finds a handful of issues including the fact that those patient
education related fields were not copied over. Most issues are corrected
before bringing users into the system. Sighs of relief. No celebrating.
September 4, 5, 6 – Random errors are found, but most are resolved quickly.
September 6 – An on-site demonstration of LSS’s web-based EHR is shown.
Conversation is had about existing functionality and LSS proceeds to state
incorrect information about their own product which is countered by the
client.
Aaron Berdofe, MHI - Health Informatics 