Many hospital IT projects suffer from a well intentioned, but untrained project manager.  A typical IT department handles approximately one hundred projects a year, and is frequently forced to promote analysts or clinicians into project leadership positions without any training. 

Atlanticon has spent many years developing a unique three day approach to project management.  We focus on teaching the real skills necessary to make your projects run more efficiently by giving you effective techniques and tools.  Our common sense approach is broken into four categories - Project Setup, Design and Build, Testing and Training, and Activation Planning.

Please click on the video link and take TWO minutes to learn more about it.  It could be the best two minutes you've spent for your department

An Assumptions Document is simply a collection of all key information, stored in one document, and submitted for approval.  Whenever you begin to plan for a major event, such as your testing rounds, your activation, or even the onset of your project, you work off of assumptions.  We all do it in our everyday lives, right?  We assume certain things and then act as if they were fact.  Most of the time, your assumptions are correct – but how many times have you acted on an assumption and been wrong?  It happens in projects all the time!

When Atlanticon is called in to help on a project, we take even the simplest of assumptions and document them.  We build a strategy off those assumptions into an Assumptions Document, then submit it for approval at the highest levels of the organization.  Then, and ONLY then, do we feel comfortable moving ahead with full scale planning.  For example, when we are asked to lead the planning efforts for activation, some of the items covered in our Assumptions Document might be the exact date/time of the cutover, the amount of downtime expected, where the Command Center will be located, how long the team will be on 24x7 support, how the issues will be tracked, and what areas are being activated.  It’s amazing how many times “solid” information isn’t so solid when it reaches the top for approval.

Imagine if you spent weeks planning for your activation, operating under the assumptions that you would utilize your large training room as your Command Center and would go live with a big bang on Saturday at 1am when the inpatient units are slow.  The entire team is planning and rehearsing, and you are communicating this information to your end users.  Then what if you go into the next steering committee meeting with 3 weeks until go-live, and you hear the CNO say that Saturday at 1am is the worst time for the ED, Tuesday at 7am is better for everyone – and there’s not a Superuser commitment to support a big bang – you’ll have to stage your units for smaller go-lives over the course of 2 months.  And by the way, the Training Room is pre-booked for some international symposium that your Chief Medical Officer has had in the works for months.  Does any of this sound familiar?  You’ve just spent a lot of time planning one way, and suddenly have to regroup and start over.

Project Management is a lot easier when you can apply enough common sense tools and techniques.  Take the time to draft Assumption Documents before each major undertaking where moderate to heavy planning is going to be involved.  Submit to the appropriate people for approval, and then you can move forward in your plans with the confidence that you won’t become the “ME” in ASSUME.

• Physicians find it easier to write or verbalize orders – reluctant to enter themselves
• Pharmacists and Clinicians use different names for the same medication
• Lack of a unified body to oversee the creation and management of Ordersets
• Electronic Signatures can be technically challenging
• Not enough equipment and/or equipment not in the correct locations
• Everyone wants their own Ordersets, and the numbers have become unmanageable

Meaningful Use is going to dictate that every hospital adopts CPOE.  It’s not a secret - we all know it is coming – in fact, the latest inpatient requirement for 2011 is that 10% of all orders directly entered by an authorizing provider, must be through CPOE (and ED orders most likely won’t count.)  So if you don’t have CPOE plans in the works, you’d better get moving.

Question: What is CPOE without Ordersets?

Answer: Unsuccessful.

You remember the old saying that you should have a good manual process before you automate it?  While that doesn’t always apply, it certainly does apply to Orderset development.  Poor leadership in this area will cause your project to take an excessively long time to complete.  You must be able to quickly gather the Ordersets that will make up your organization’s CPOE backbone.  There are a number of steps to accomplish this:

1. Build a multi-disciplinary team structure for rapid review and approval
2. Collect and categorize all current Ordersets, paper or electronic
3. Identify commonalities
4. Develop a template that is categorized by discipline, Rad, Meds, Labs, etc.
5. Draft guidelines for what the organization will allow, such as should each physician be allowed his or her own set of admission orders or should a more universal one be built
6. Draft the list of Ordersets to be developed
7. Begin the efforts

 All these steps can be going on outside of the IT arena.  In other words, let the IT department work on the technical details of software, screen build, table structure, electronic signing, security, etc., while another group tackles the compilation of Ordersets.

While I oversimplified steps 1-7, my intention is to let you know that there is a process and approach that can be applied to get this done as painlessly as possible.

Atlanticon has experts that provide great guidance and leadership in helping lead your Orderset development.  You don’t want this step to be the one that hinders the completion of a good CPOE project.  If you would like to discuss this or enlist our help, please don’t hesitate to contact us.

In this article, we’ll present one sample approach to Change Management.  And if your current Change Management process isn’t exactly what you would consider acceptable, perhaps our approach can be a good start for you.  You don’t have to have an overly complicated process – just a well communicated one.

Let’s begin with an explanation of Change Management.  Change Management consists of several key components: documenting and understanding all changes that need to be made in your production environments, insuring that one change doesn’t interfere with another change or create a negative impact with current setup, communicating the upcoming changes to the user community, executing the changes, and validating their success.

Failing to follow a good change management process can cause you grief in many different ways.  For example, if you fail to communicate a much needed change going into production, your user community will not be prepared, and what should have been a nice “fix” will turn into some bitter feelings from your users.  Another common side effect of poor change management occurs when changes are made to one system, such as table values changing without making the same changes in your downstream systems.  Interface rejections and delayed service can leave a nasty mark.

Here’s a step by step approach to building a workable Change Management process:

1. Assign a Change Management Coordinator (CMC).  This person will be the center point for communications and will coordinate and facilitate your Change Management meetings. 
2. For the sake of this sample approach, we’ll assume that changes are migrated to production weekly.  We’ll also assume that you have system owners (analysts) who manage or oversee your various systems – pharmacy, lab, radiology, ADT, etc.
3. Every week, each system owner must submit, on TUESDAY, the changes they intend to migrate to production the following week.  Any and all changes should be included – changes to the dietary system, changes to your ADT module, new reports, additions to your order table, etc. 
4. On WEDNESDAY, your CMC will validate and compile all changes in a log and distribute to all system owners, as well as to the Interface, Help Desk, and Operations Managers.  A sample “log file” can be found below.
5. On THURSDAY, your CMC will facilitate the weekly Change Management meeting with all system owners to discuss each change, and allow the group to validate that there will be no negative interactions or outcomes.  During this meeting, any discussions of downtime or sequencing of migrations will be determined, as well as a plan for how each system owner will validate that the changes were successfully completed.  In addition, if the team identifies a change that may cause potential negative impact, the team should reject the change, request a review/revision, and reconsider it during a later meeting, when a higher confidence level can be reached.
6. Following the meeting, communications will be prepared and sent to the hospital user community, notifying them of the upcoming changes.
7. On FRIDAY, the CMC publishes the final list to the system owners, Interface, Help Desk, and Operations.
8. On TUESDAY of the following week, the changes are migrated.  System owners will be notified so they can validate the success of the migration.  *Migrations are done on Tuesday to allow the remainder of the week to remedy unexpected problems.
9. The CMC will maintain a very careful log of all changes for easy referral of problems back to a particular migration.

SAMPLE CHANGE LOG FILE

As you can see, this process can occur weekly or bi-weekly, depending on the frequency of your changes.  We suggest you select a CMC that will adhere to times and deadlines, keeping your process on track.  With each passing week, your team will become more familiar with the process and with the changes that occur in all the systems.  And your user community will be extremely grateful to be so well informed of the upcoming changes.

When faced with IT projects, you plot your progress in the same way.  You know you have a go-live date of November 30, so you intend to have Planning done in February, Design in April, Tailoring in July, Testing in October, and Training in November.  BUT…when you don’t finish Planning until March, Design gets pushed back.  When Design finishes up in June, it pushes Tailoring back two months.  And already, you can see how missing that first date has started to seal your fate.

It doesn’t take a whole lot to be able to predict that your go-live date is in jeopardy.  Ever fallen into this trap?  If you have, you are not alone.

Many, many projects suffer from missed dates.  And surprisingly, the majority of projects start missing dates in the first phase!  Why?  Maybe this sounds familiar: a hospital decides they want to be live on System X by a certain date.  The vendor confirms that it can be done – the date is now etched in stone.  But then the contract needs a tweak here and a legal review there.  And there’s still the matter of signing that PO, not to mention you’d better assign a PM.  So, once the ink has dried and the kickoff is about to begin, you actually start the project six weeks behind schedule, unable to adjust the go-live date.

Date slippage is every Project Manager’s headache, but it becomes the project’s nightmare when the dates have slipped before the project even begins.

The message to all CIOs is to stand up and speak up early in the process.  The first key to proper date management is to avoid allowing a vendor to set the date too early, and avoid letting your executive team dictate a date that you might not be able to safely deliver.  You should let the activation date be set as a result of YOUR Planning phase.  A good Project Manager will take into account contingencies, resources, conflicting projects, and many other things that are often overlooked by a vendor.

The second key to proper date management is to keep the milestones visible and your team leaders focused on those dates.  They should be fully aware of the importance of hitting each date, and serious discussion should occur the first time any date is missed.  The team must understand that the project plan can be like a house of cards, and missing dates early can be similar to pulling a card out from the base.

Pay close attention to the dates, keep everyone focused on the milestones, and work as a team to hit every date in the plan, and you can avoid falling victim to, “Miss Your Date – Seal Your Fate.”

So basically, you design your system, build it, and put it through all the functional testing you want.  Perhaps you even make it through Integration Testing.  Is that enough testing?  No, not in my opinion.  I always believe that your rounds of scripted testing should be done by skilled analysts.  I’ve seen some hospitals try and use end users to help with integration testing, and it doesn’t always come out well.  End users don’t necessarily understand the importance of documenting steps used to recreate issues, and sometimes they can overlook problems that a skilled IT person might spot.  A good rule of thumb to remember with testing: The IT department is responsible for making sure the application FUNCTIONS, while your end users need to make sure the application is FUNCTIONAL.  And this is where a CRP comes in.

I would encourage you to set aside a couple of two day periods where you can execute a CRP, after you are confident you have worked all the bugs out of the system.  Set up a room with various stations to simulate a day in the life of a patient.  You can even enlist the help of a colleague to act the part of the patient.  Get your end users to man their stations, and go through the paces, using only a general guideline of what the patient will encounter, i.e., no detailed scripts.  Your patient will walk to the terminal that is designated as “Registration.”  Let the end user do their thing!  Then move your “patient” to the next station – perhaps it’s the lab, radiology, or even the nursing unit you have simulated in the room.  Give each end user the opportunity to simulate their normal workflow.  Make sure that printouts are routed to a handful of printers right there in the room, and that the equipment you intend to use, WOWs, monitors, laptops, etc., are all in use.

Allow your end user “testers” to spend as much time as needed and collect their feedback.  Was the workflow acceptable?  Did the printout provide them with enough information to do their job?  Was the data they needed accessible and easy to read?  By scheduling two sessions, you can have time to make adjustments and give it a second go.

• Testing is executed, but unsure if problems are fixed
• Hard to measure whether testing round was successful
• Begin integrated testing with an unprepared system

In a typical integration testing round, which I think we’ll all agree is the round that we most look at to see if we have a fully functional system, the teams usually move through scripts with a pass or fail for each line item.  And then we’re left to wonder if the problems are really getting fixed between rounds.  We’re aware that a round of testing is done, but how did we really do?  And we’ve got to wonder if we really came into integrated testing having done as much due diligence during unit testing as possible.  

We’ve developed a fairly simple way to help you make sure you get the most from your testing and the most from your team as they prepare and conduct testing.  This process helps address all three of the challenges we listed above:

1. Count the number of line items for EACH integrated test script.
2. Tally the number of passes and fails.
3. Do the math – and assign a grade.
4. Make the team know they are to be graded.
5. Tally the pass/fails for each specific team across all scripts.
6. Let the team fix and retest – then re-grade!
7. Expect an A+ from everyone and every script.

While this is a very simple approach, you can see that it sets expectations before integration testing begins – and this will encourage your team to fix as much as they can so they pass as many items as possible.  It gives you numbers to determine your level of success.  And it insures that each issue gets resolved with you ending up with scripts that can be executed flawlessly.

We know that no amount of testing is ever “enough” but we hope that this tip was helpful and look forward to hearing your personal experiences with testing.

As a consulting firm, we strive to look for ways where we can be most effective.  We’re constantly looking at the issues that IT leadership faces, trying to determine how we can make a positive difference.  The solution was simpler than we thought.

We recently interviewed 100 Healthcare IT leaders and asked them how many “projects” they had on their plates for the year.  We defined “project” as an upgrade or new install, something that was significant in that it required a plan, design, testing, and some level of activation support (i.e., installing MS Word did not count!)   -  83  -  That’s right… the average number of projects on an IT department’s plate for the year is 83!!!

If this sounds like you, then read on…  When are consultants used – and why?  As a consulting firm, we are typically utilized for our specific expertise with a product line – GE, Epic, Siemens, Cerner, McKesson.  We’re usually brought in to handle the high visibility projects, and this seems to be the norm for most firms.  Yet over the years, we have seen that these big projects suffer, not from a lack of manpower, but from a lack of AVAILABLE manpower.  And why is that?  Because most of their team is juggling 3 or 4 of the other 83 projects at the same time, and simply can’t devote full attention to the bigger systems.

So here’s where the simple solution comes in.  Consider using consultants to come in and help you tackle some of the smaller projects to free up your staff.  Most consultants, while skilled in specific big hitter systems, are brilliant analysts, capable of running with nearly any type of IT project.  They are good utility fielders who can work a multitude of positions.  Don’t start a big project without the full support of your own internal star players.

Whenever a hospital undertakes a large implementation project, Atlanticon suggests the creation of a common work area to help your team deliver an integrated system.  Projects suffer from communication issues all the time, and a good Project Manager will step in to encourage good communication and even install methods and tools to help the right hand be aware of the left hand’s activities.  But there is no better way to accomplish a cohesive work team than to designate a common work area and require your teams to perform key tasks together.  The synergy that is created by working in a common area is unbelievable.  Teams feed off one another, they learn how each team is progressing, and the result is a more integrated system.  

Expect some pushback and be prepared to deal with it.  First, everyone has their own office / cubicle and doesn’t like to leave it.  Second, designating a common area may not be easily feasible in your organization.  And third, it may seem difficult to coordinate.  But you need to overcome those obstacles, as there is a big payoff to having your teams spend time together daily. 

Atlanticon recommends the following for all large projects:

• Establish / reserve a room large enough to house the IT members from each of your key application teams, as well as some additional spaces for invited guests (liaisons, interface, or conversion staff for example.)
• This room will probably be used ultimately for testing, training, and maybe even your activation command center.
• Designate a time each day (8 am – 12 pm or 1 pm – 4 pm) for your team to collect there so schedules can be built around that time.  Require your key application teams, Pharmacy, Orders, Clin Doc, HIM, Registration, CPOE, etc., to plan on working on their project related tasks in that room.
• Enforcing the use of the Project Work Area for the design and build phases make the most sense, as these are phases of the project where it’s essential that the teams develop an integrated project.
• Your PM should drive this cohesive approach, and encourage / schedule “show me” sessions – allowing each team an opportunity to present what they are doing with design or demo portions of their build to insure that other teams can ask questions, compare, and most importantly, be confident that they are creating a system that will work together FOR the user community.

While most sites have initially been reluctant to enforce Project Work Areas, every single one has been very pleased with the outcome.  All of us are inherently resistant to change – and we’re uncomfortable giving up our ‘turf.’  But project teams need to look at the bigger picture and recognize the value of this minor, yet important, approach.  Very recently, one former client from Virginia called to say, “We hated it when you made us do it, but it turned out to be the best thing for this project and for our users!”  They now designate Project Work Areas for all their projects.

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!