Meditech 6.0 Diary Part 4 — Finding the Right Project Management Formula

First of all, I want to thank the numerous people who have called and written thanking me for writing this blog. I am really surprised and happy to see I have so many readers following this series. I am glad the information has been helpful and am happy to field any questions or post information you feel would help others.

So on to this month’s adventures. To start with, we progressed from the onsite kick-off meeting to introductory calls from the module team leads. Most of these have just been the basic, “Have the teams been identified?” type of discussion. We don’t expect that to change until after our first teams get back from base dictionary and set-up training the first week in January.

As reported last month, Meditech does not take responsibility for providing you (the customer) an overview of how all the dictionaries play together and should be set up for maximum downstream benefit. As reported last month, they state that is what the consultants are for. The expectation from Meditech is that in Magic-to-6.0 migration, you (the customer) are very familiar with your current environment and structure and KNOW how you want that to look in the future (even though you have not had any experience with the 6.0 modules and may be implementing significant new functionality). One consultant referred to Meditech’s approach as “an assembly line process,” with no effort on their part to advise on customization or think outside the implementation silos.

So off we went attempting to find a dictionary consultant who could advise us on how we should structure the dictionaries, review our processes, and guide our overall build. Now bear in mind that we installed our current product back in 1994. We do not use some of the functionality in the current modules today because of how we structured our dictionaries back during that install and did not want to go back and redo them. In other words, how you end up structuring dictionaries today does have a huge downstream impact on future functionality and processes.

Speaking of processes, you should take the opportunity the migration project provides to look at every Meditech-related process you have today and ask if that’s how you want to keep it in the future. For instance, we will reduce our patient registration screen significantly and streamline the whole patient registration process making that department more efficient.

Back to the consultant search … Interestingly, due to these blogs, I have been inundated with Meditech consultants calling and offering up 6.0 resources and expertise. During interviews with them though, many have not had any 6.0 experience or they are literally pulling independent contractors off the street whom they have had no previous experience with. In other words, before hiring a 6.0 consultant you need to do lots of homework in terms of reference calls and interviews. Also, don’t hesitate to ask technical questions or drill down into what the true role of the consultant was at the time of the specific engagement.

We specifically were looking for a consultant who knew enough about the Magic and 6.0 dictionary structure to advise us on how we need to think about dictionaries and structure them moving forward, especially having no knowledge on many of the clinical dictionaries used by CPOE or closed-loop medication checking reconciliation. Also how would the OR module use the materials dictionary, etc. We had numerous discussions with consultants from the “of course I can do that” to the “it will take several experts” approach. After in-depth discussions and interviews, we came to the conclusion that indeed there was not a single person we spoke with who seemed to know enough about all the 6.0 modules and dictionaries to take the single-consultant approach.

So off we went looking for a team that could do this. We actually interviewed several very experienced consultants who, under the team approach, could produce what we were looking for. In both cases, the difficult part was not in locating the expertise on either clinical or financial modules, but rather the expert who could take both their findings and combine them into something more holistic in nature.

We finally got it down to two consulting companies, one of which had actually championed this approach initially. It turned out they also had some high level project management staff experienced in 6.0 who were able to convince us they could tie the information together and get us what we were looking for.

This same company also gave us some good advice. They said though they could tell us where we were today and give us a document on how to proceed, much of the information in that document would not make any sense until months from now when we were actually doing the work. At that point, we would have questions and need additional advice, because we will have arrived at a point to discuss cause and effect of specific decision points.

After thinking about that, I had the, “Wow, I should have had a V8 moment!” They were totally right. We can get all the pre-implementation advice on the market, but until we really start doing the builds, we may not even know what questions to ask. So we contracted in a bucket of hour for ad-hoc calls and question/answer sessions that can be used at any time over the term of the contract.

Next we wanted to hire a project manager coach to assist our as-of-yet unassigned PM. We know that to be successful with a project of this scope and nature — and also adhere to the terms of the contract — we must provide a project manager. From the hospitals I have spoken with, there seems to be three approaches: the CIO acts as the PM; they hire an external consultant as the PM; or they used an internal PM.

The feedback on success seems to be mixed, but a couple of common themes did emerge. First was that it is too much work for an existing CIO to easily take on with the other duties on that person’s plate. Also, by doing so, it makes the project IT-centric instead of organizational in nature. Secondly, many of the external PMs did not have 6.0 experience, so you would essentially have consultants learning on your dime.

Along with that, the success rate was mixed. This was due in great part to the fact that the PM did not know the inner workings of the organization and, in some cases, even ended up doing the dictionary builds or other implementation work because they could not get the users to do what they were assigned. In the third case, it was often problematic that the internal PM was overwhelmed by the overall size and scope of the project and also struggled to get uses to do what was assigned.

We have decided to go the internal PM route. We have a candidate identified, but need to free up that person’s time by shifting resources, tasks, and duties to other parties. Since real work does not even start until the beginning of February, we still have time to address that and have been taking actions to make it so. As part of our approach, we agreed that since our PM was new, having an external PM with 6.0 experience would help increase the probability of success.

We identified and contracted with a consulting firm that had what we felt was an excellent resource. The person had a role in several 6.0 implementations and also years of project management and consulting experience with a proven track record. They also were very supportive of the hospital using their own PM as opposed to bringing in a full time consultant.

This is very important, as feedback from one site that contacted me (but prefers to remain anonymous) is that, “Frankly, Meditech is still learning about the ins and outs of the 6.0, platform and project management for that matter. There were times that we (the project team) had to push Meditech for answers to not extremely difficult questions.”

Personally, I feel that since Meditech is an international organization, it should follow proven standards of project management from PMI. Several organizations have reported that their Meditech PM did not even provide them with a complete project plan (just the generic project information on the Meditech Web site) including milestones. As previously reported, we had to look at the individual training sections on the Meditech Web site and pull our own consolidated training plan together from that. It was a lot of work considering it should be a core project deliverable.

Hardware-wise we had Dell/Perot back on sight finishing up the SAN build, virtual servers, and VPN device. Dell/ Perot were onsite to install the software required to drive the hardware. Install consisted of VMware ESXi, Microsoft SQL and various flavors of Windows Server. As a Microsoft Volume License shop, we provided the Microsoft and the vCenter software licensing and media. The install took several days and went smoothly.

While this was worked on, Dell set up the VPN connection. This process took a couple of days as we worked through some issues with duplicate IP networks that existed at both sites requiring some special configurations in the router. When we had everything working, we asked how the authorization and access to this connection was managed. The Dell technician reassured me that only authorized people could use it since it was using a RADIUS authentication model.

While this is nice, we still have concerns about Meditech or Dell employees being able to access our systems at any time. What’s to prevent a disgruntled employee on their end from doing damage to our systems? I have not received a satisfactory answer from Meditech or Dell about this issue. More importantly, I was unhappy we had to purchase a costly piece of hardware just because it made it easier for Meditech and Dell/Perot to manage their employee lists authorized to access our data.

To address this concern and combat having to physically plug and unplug the network access to the device to manually control access, we have created some scripts that will enable or disable the port on the switch as needed. We were informed by the Dell technician during the install that some sites do manage access this way (although he did his best to assure us that no unauthorized access was possible).

Since all of this happened in the two weeks before the Christmas holiday, and we did not have enough time to completely configure the backup system utilizing the new EMC networker and ML6000 library. While scheduled for the second week of January, we found it strange not to mention a data risk since the archiving phase was going on and data was already migrated. While not a huge risk, since the data still resided in the old Magic system, it was a bit of a concern not having backup capability and maybe having to invest a lot of FTE hours doing it over if something happened. Again, this came down to effective project management for me, requiring “herding the cats” and adjusting tasks when something doesn’t align anymore.

Next month, I will discuss how the initial week of training went; Zynx order sets; and how the consulting engagement looking at the libraries is going. Until then, Happy New Year, and may you migration to 6.0 go smoothly.

For all of Jorge Grillo’s columns, click on his name below