Overcoming the Vendor Honeymoon – Taking Control of Your Project

When a hospital embarks on a large project to install one of the common HIS systems, the demo is still fresh in everyone’s mind.  A visual image of a smoothly run project with a vendor dedicated solely to you is the expectation that most teams have.  There is an air of excitement as you await the kickoff, knowing that you will be guided every step of the way.  You’re on your honeymoon!  Within a few months, you realize that the project plan doesn’t really list all your tasks, learning the new system is not as simple as you had hoped, redesigning workflows is difficult because you’re not confident of what to expect, issues seem to be on the rise – more questions than answers, and the vendor is busy with 3 other clients!  Honeymoon…officially over!

During many of the hospital IT projects in which we’ve been involved, we notice that the hospital team does indeed have a tendency to rely quite heavily on the vendor.  When a hospital believes that the vendor will take charge of the entire project, it can sometimes set unrealistic expectations.  When Atlanticon is hired to help with the installation of a new system, one of the first things we attempt to do is ascertain whether the hospital’s project team consists of veterans or rookies.  We do this for a lot of reasons, but one of them happens to be the topic of this article.  We like to help hospital project team members gain a realistic expectation of what duties belong to them versus what they should reasonably expect of their vendor.  By taking control of your project early, you increase your chance for a very successful installation! 

Typically, a project veteran (one who has dealt with more than 3 system installs) understands the limits of their software vendor, and more importantly, understands what tasks will fall to the hospital team.  Rookies, on the other hand, experience what we call the “Vendor Honeymoon” phase – something we’ve all lived through and certainly nothing to be ashamed of.

Sooner or later, the hospital team realizes that the project belongs to them and the success of the project lies on their own shoulders.  This is the point at which we notice the project taking a very positive turn.  Vendors know their own systems, but they don’t know your hospital.  Vendors are very aware of how their system works out of the box, but they may not have all the answers once the system is tailored to your needs.

Here are some of the more common areas of a project where the hospital team should take early ownership:

• Project Plan – a vendor will provide a plan that covers their tasks and some of yours.  You need to actively include all tasks that are the hospital’s responsibility.  Don’t forget tasks surrounding downtime planning, change management, operations and infrastructure tasks, hardware acquisition and installation, forms changes, policy revisions, and activation planning.  And keep in mind that you will not remember to include every task initially – prepare to continue updating the plan with additional tasks and reminders as each new phase is beginning.
• Scope – the vendor will identify the scope of what you purchased and the scope of their services, but only you know how you intend to utilize your purchases.  For example, you may purchase the Order Entry module.  The vendor will not know that you intend to utilize it for order entry to 29 departments and that 17 of those will receive printed requisitions and 12 will generate charges upon order.  Take control of detailing the scope.
• Issues – the vendor will have an interest in tracking the issues that they need to fix.  However, they should not be responsible for all the issues that are hospital specific.  You should implement your own issue tracking system and be diligent about logging every issue and key decision.
• Testing – the vendor can help resolve issues found during testing, but typically can’t prepare your test scripts.  Most hospitals heavily tailor the system, and by the time testing arrives you are the expert in how the system should work at your organization, i.e., you are responsible for creating your own test scripts, preparing the logistics of the test room, running the test phase, and logging the issues that arise.
• Activation Planning – the vendor will be prepared to be on-site, help with conversions and cutover planning, but for the most part, activation planning belongs to you.  You will need to determine where your command center will be located, how to set it up with equipment, develop a support schedule, and create a step-by-step activation plan.

 These are just a few examples of areas where responsibility should be clearly understood.  We hope that this small list can guide your team into an early realization that the project belongs to you.  Face it and embrace it!

As always, we would certainly enjoy speaking with you about your own experiences with this topic.  Good luck in your next project!