Hospital Software Implementation Experts

Healthcare Installation Tips

Team Hierarchy—Stacked to Succeed

When establishing a functional team for your HIS project, take the time to outline the hierarchy and clearly define the roles. We recommend a structure that covers all levels from the Executive level down to the Team Member level. The responsibility for members at each level should be clear.

The Executive Level is responsible for providing overall support, serving as the Champion for the project with Administration, the internal user community, and the external users and customers of the project. This level usually consists of a Steering Committee, but can be a smaller group of Executive representatives. This level sets the tone for the project by providing stable, consistent guidance, decision making, budget review and support, and leadership. The Executive Level gets reports and escalation events from the Program Manager.

The Program Level is headed by a Program Manager who drives the project, maintains the Master Project Plan, assigns Project Managers, attends and chairs key committee meetings, serves as the voice of the project to various hospital areas / committees, and maintains communication with the vendor. This position sets project standards with regard to status collection, issue handling, risk review, and guides the Project Managers through the various phases of the project. The Program Manager utilizes the Project Managers as his/her key team to assign, strategize, and carry out all the duties necessary for the project.

The Project Level consists of Project Managers who serve as the primary oversight body of all the various sub-teams for the project. Project Managers help assign critical Team Lead positions, maintain their teams’ project plans, provide plan % status to the Program Manager, and control the speed and quality of all facets of their team. These individuals work closely with one another, monitoring issues, insuring cross team functionality, projecting resource needs, and setting the pace for delivery and quality of the project.

The Team Level is made of Team Leads who are responsible for insuring that all project tasks are completed in accordance with the project timeline. Team Leads are instrumental in determining the necessary makeup of their teams and utilizing the project sub-plans developed by their Project Managers, enhancing that plan to contain the detailed tasks, so all tasks are completed on time. The Team Leads utilize Liaisons and other committees to gather feedback, gain signoff / approval, and oversee their applications and/or areas of responsibility to validate they are being handled with the utmost quality. Team Leads take direction from the Project Managers and work with other Team Leads to insure consistency and cohesiveness within the project. Team Leads maintain the issues for their respective areas of the project in the project issue tracking system.

Finally, the Team Members take direction from the Team Leads and conduct all the tasks assigned, reporting and working through issues as they arise. Team Members must follow guidelines set forth with regard to reporting, tailoring, approval, and all other project-related policies and expectations. Team Members may serve on multiple teams and must work with other Team Members to gain knowledge and assist as needed. Your project will be much more successful and your teams more functional and empowered once everyone knows their roles and limits.

Vendor Selection / Management

Vendor Built System—Is It Right For You?

Anyone with an HIS has faced this question: Should we do our own tailoring, or utilize the vendor’s “rapid build” process? Whichever way you choose, you have much work ahead of you. If you believe that contracting with the vendor to do the build for you will make your job easier, you’ll want to pay attention to this article.

Once sold as a creative solution to smaller hospitals with limited HIS staff, vendors have started to target larger institutions. Why would a larger organization want the vendor to tailor their system? Some may not be able to dedicate staff to learn a new system, and some may want to engage the vendor in the project from a responsibility and accountability standpoint.

If you choose to contract for a vendor built system, there are several steps that you, the hospital, can take to help your project stay on target:

Require the vendor’s analysts to have a minimum of 3 years hospital experience and at least 1 year with the application. You need skilled builders who know hospital operations.
Your project team will need to make informed decisions. Provide them with essential training, encourage contact with other sites, and allow time for them to learn the base system.
For each tailoring decision, understand your options. Will your decision impact charging, the ability to chart, or any other interrelated function?
Maintain a clear, concise record of all data sheets you provide to the vendor, including date requested, date submitted, and version control. Keep clear records of what was submitted so you can use it during your validation and testing.
Insist that the vendor build small subsets of each module, then come on site to do demos. Do not submit an entire data collection sheet before you see how a few sample items look and function in the system. For example, ask the vendor to build a few orderable items from each department and demonstrate how the system functions using this subset. Only after you are satisfied that the system works as expected with your data, should you begin gathering and submitting the rest of your items for building.
Require that the vendor present Conference Room Pilots at various stages of the Build process. By monitoring the progress, you can make course corrections if necessary, plus your team will become much more familiar with the product and the impact of their decisions as a result of these presentations.
Plan your testing early, making sure that you receive clear documentation on how the system has been built, so your test plans are accurate.
Assign a dedicated project manager to oversee your project, helping to keep your assignments on track as well as monitor the vendor’s deliverables.

When determining if you will tailor your system or contract with the vendor for the job, our final suggestion would be for you to consider what your long term support plans are. At some point, the vendor is going to leave, and you have to be prepared to troubleshoot and tailor the system. Would you benefit more from your staff learning these skills early in the project or at the end?

Defining Project Success

Shortly after your project goes live, you’ll want to determine if your activation was a success. The overall value of a new system is measured by the sum of its parts. There are ways to quantify “success” objectively and subjectively. Both can be used to your advantage if done properly.

Objective measurements of your success may consist of the following:

Average retrieval time for lab results will be reduced by 25 seconds.
Reported patient safety issues due to medication errors will be reduced to 1 per month.
Application will remain available to the user community 99.98% of the time each month.

Subjective measurements may come from the following types of evaluations:

The equipment in my department is fully functional, and all PCs, printers, and other project related devices work as expected.
Users in my department are able to access the system with all necessary security rights.
The training I received was adequate and we are now functioning with appropriate knowledge of the system.

Both of these types of measurements are valid, and it is up to your Executive Team to determine what their measurement of success is going to be. Executive Teams typically enjoy objective measurements – something that can be definitive. These measurements take some upfront effort and some level of Management Engineering to get consistent data before and after.

Project or Program Managers should also appreciate subjective measurements. These are usually done with a Lichert scale survey. Our suggestion is to develop ten different questions with a 1-10 scale ranging from strongly disagree to strongly agree. Survey each department 5-10 days post activation and arrive at an acceptance percentage for each department as well as the facility average. Then survey the same individuals 30-60 days after activation and compare the improvement. This not only gives you firm proof that the perception has improved, (which is usually attributed in some part to getting comfortable with the system) but it also pinpoints areas of dissatisfaction.

Preparing For Your Go/No-Go Meeting

We’re all familiar with a Go/No-Go meeting – the event whereby key personnel sit around a table and give the “okay” to proceed to activation. This is an extremely important milestone, and you want to make sure that everyone is truly ready. When your people give you the thumbs up, you want to feel confident that they are basing their answer on firsthand analysis with total confidence that their application, team, or technical aspect of the activation is ready to go.

Atlanticon suggests preparing a bound document well in advance that requires that all Team Leaders and other personnel responsible for facets of the project, sign off for their areas. Circulate it early so there are no surprises.

Schedule a preliminary Go/No-Go meeting at least 30 days prior to your final meeting, performing a verbal survey of everyone’s readiness at that time. Pose the question, “If you were expected to sign this today, could you? If not, then what do you need to do in the next 30 days to turn it around?”

Be prepared to deal with someone who may refuse or be reluctant to sign. Will you require that they sign with conditions? What action will/can you take at this late stage?

Conducting these meetings in a large room with the document being passed around to all signers gives this event the importance that it deserves! Above all, you want to activate a system that is SAFE for the patients. The purpose of a Go/No-Go call is to do the right thing. If someone truly can’t be ready, and their situation makes for a dangerous future, then you must make the tough call.

Training Strategy — An Important Step

Honestly, I could write for days about the importance of a good training strategy. When Atlanticon is asked to lead a training effort, we begin with our standard 40 page strategy and adjust it for each client. I'm not trying to impress you with the number of pages, but I do want to make you aware that training is no easy phase, and there are many items to address. Our training strategy was developed by Brian Beals, one of Atlanticon’s most senior PMs and Training Specialists, and has been utilized and revised over the years by other senior consultants, Bruce Dobrient, and David Kowal.

As you approach your training phase, it is best to assign a Training Leader that is a veteran of training and who has exceptional organizational skills. This individual is going to be responsible for putting together the Training Strategy.

Since each hospital is vastly different, training strategy can vary. What works for one may not work for another. Keep in mind that the strategy document should cover all the things you intend to do leading up to, and during training, and should be the document that guides your training team in the development of their approach.

Here are just a few things to address in your Training Strategy document:

Room space and location - where will you train and how much space will you need
What type of training - instructor based, computer based, etc.
How many hours of training
Will there need to be pre-req classes, such as Windows awareness
What automated tool will you use to schedule classes
Will you be reporting no-shows to management, and what corrective action will occur
Will you have a system that allows the instructor to take over the terminals
Are you providing enough lead time for printing your class materials
How will physicians and their office staff be trained
Will you provide access to the training domain after training
Will you refresh your training domain with updates if the system is still being built
Will you build starter data and have to restore it after each class
Will there be a competency test at the end of the class
What if someone does not attend training and/or does not pass the competency
How much time will you leave between the first training class and activation
Will you distribute the Production logins and passwords at the completion of class
Have you created job descriptions for trainers and targeted the right personality

As I mentioned earlier, training is no easy task. And developing a good Strategy Document is the key to making sure that all your bases are covered before you embark on this critical phase of your project. Should you wish to discuss training ideas with one of our training experts, please contact our office and we’ll arrange a call.

Activation Planning — Cross the Finish Line in Style

Activations come at the end of many, many months of hard work. There's a lot at stake and you need your activation to be well planned.

I'm going to list a sampling of the key things Atlanticon follows when involved in Activation Planning. Hopefully, these "top 20" will aid you in your thinking process:

Create A Small Activation Planning Team. Include the interface, conversion, and one or two other key team members - select those that are self-starters and motivated - the ones that are always thinking.
Develop An Activation Assumptions Document. This document is critical. It should contain all the major assumptions upon which you will plan the activation. State the date and time of activation, where the Command Center will be located, how long the activation support team will be 24 x 7, when the vendor is to arrive, what issue tracking system will be used, where will the help desk be located. Include as many assumptions as you can. This Assumptions document must then be blessed by your CIO, the Executive Team, and the Vendor.
Plan The Activation Steps. Once you have an agreed-upon Assumptions document, you can begin to plan the steps. Start at a high level - make sure that you know when the conversions will begin, when the interfaces need to queue, when the old system is shut down, when the converted data is complete, and when the recovery of current patient data begins.
Introduce Other Teams. As you start your outline of key steps, you will slowly start to work through any conflicts. Gradually, introduce other key team members, such as Registration followed by Pharmacy followed by Nursing.
Broaden The Steps. As each group is introduced to the planning, they can start to contribute their key steps. When will I readmit the in house patients, when will the allergies be updated, how will I handle the inhouse medication profiles, when should order entry on active orders take place.
Insure Proper Sequencing. With each addition, you are starting to get a plan that is free of major sequencing issues. The most serious problem that can arise in an activation is when your steps are out of sequence - for example, you don't want to place medication orders before the allergies and existing meds are entered - you'll risk missing an interaction or drug alert.
Gaining User Satisfaction. Document the approach you are going to use for gaining user satisfaction.
Conduct A Dress Rehearsal. Remember, a Dress Rehearsal is a walkthrough of your activation plan. We like to select key elements from the activation plan and request that the task owners come prepared to present, discuss, or demonstrate how they will accomplish their task(s). As a group, you will be amazed at how one member's explanation causes others to recognize how that task may impact other tasks. You walk away from this with a team that is much more aware of the big picture.
Develop Orientation Packets. Prepare to conduct meetings with all your support team, informing them of your expectations, using these Orientation Packets.
Identify Roles Of Your Support Team. Will you have Roamers, a Physician Hit Team, Department Support?
Support Schedule. Develop an easy to read schedule of all your support. Make sure that all teams and departments are covered.
Managing Food. Don't forget to assign someone to be in charge of food during the activation. Many places don't have food available for the night crew. And be sure to insert rules about lunch/dinner scheduling so an entire support team doesn't disappear at the same time.
Users’ Activation Guide. Develop a Users’ Activation Guide - which covers details of the activation at a Dept Managers level. Remember, many departments don't understand what is involved beyond how they are affected. This is your opportunity to give high level details to all areas of the hospital. I suggest conducting a full facility managers meeting and present this information, requiring the managers to take the Users’ Activation Guide and communicate it to their department.
Change Management / Public Relations Campaign. Make sure to develop a good Change Management and Public Relations campaign. Be sure to cover your internal customers, physicians, physician offices, clinics, executives, patients, and the community. Be aware that your executive team may have strong feelings about how a new system is announced to current patients.
Review The Plan. Review your activation plan repeatedly until everyone works through their roles.
Project Signoff. Develop your Project Signoff document. This is used at your Go/No-Go meeting.
Strong Coordinator. Keep your Activation plan visible and assign a Coordinator who will insure that everyone marches in step.
Meeting Schedules. Schedule key meetings throughout the activation, making sure to gain input and feedback from department liaisons, managers, vendors, and executives.
Issue Dashboard. Develop a useful dashboard that can be easily maintained throughout the activation. This dashboard should give you a quick glimpse of issue closure and critical status.
Hot Topics Communication. Develop a Hot Topics news brief that goes out each day at the same time. It should cover key information that is helpful to the user community. By preparing a binder or special location in each department, you can have a designated spot for all users to retrieve this sort of communication.

Atlanticon has helped orchestrate many successful activations. We would be happy to schedule a one or two day overview of activation planning at your site. We have many checkoff items that help insure your activation is as smooth as possible.

Project Phases — Avoiding Phase Overlap

There is much to be said about Project Phases - we all know that these are typically PLAN, DESIGN, BUILD, TEST, TRAIN, ACTIVATE. There are many variations to these phases and each of us is free to insert more phases to our plans if it makes sense.

Without getting into great detail about what goes into these phases, I want to touch on something more simple - "Phase Overlap." Have you ever been in a project where one of your phases begins before you have finished the prior phase? Despite your efforts to build a great project plan, unexpected things resulted in your team not being able to stay on track. No slack time, vendor delays in delivery, more issues than expected, or a team member that isn't able to deliver - these are all common events that can cause "phase overlap." Sound familiar?

There are a few things that can be done to avoid this:

AVOID ANNOUNCING THE ACTIVATION DATE TOO EARLY. Don't publicize your go-live date to the entire community when you kickoff the project. Instead, announce that you'll go live in the Summer of 2008 or the fourth quarter of 2009. You and your executive team can know what your target date is, but avoid announcing an exact date until you absolutely have to.
BUFFER and PRODUCTIVE TIME. Build in a time buffer to each phase by budgeting people at 32 hours of productive work per week. Don't expect a pace of 40-50 to last very long. Priorities change, vacations arise, roadblocks are encountered, etc.
DEFINE PHASE COMPLETIONS. Clearly define what constitutes the end of each particular phase and don't deviate from that. For example, it isn't good enough to simply say that the DESIGN phase ends on Nov 15. You have to clarify that the Design phase is over when 100% of all design documents have been signed off by the user champions, and that is to occur no later than Nov 15. Also, set mock signoff deadlines prior to each phase completion date to pinpoint potential trouble areas.
PHASE CELEBRATIONS. Schedule a MILESTONE celebration at the end of each phase - this lets your entire team know that they have accomplished something major. No one wants to be the one person that delays the end of a phase.
THINK TWICE ABOUT OVERLAP. Think very carefully before you decide to start a phase when the prior one has not been completed. Why would anyone want to start building when design hasn't finished? Or start testing when building is still going on? The answer is that you don't want to - but even the best-intentioned leaders will convince themselves that they have no choice but to overlap phases in order to stay on target. Don’t fall into this trap.

I know these seem like simple suggestions, and they are. However, many projects do get away from the best PMs. Atlanticon tries to approach each client and each project as unique - and we try to build in safeguards to help keep projects on track. While nothing ever guarantees perfect success, these simple tips can make a big difference.

Making the Project Scope Useful, not Useless

Many years ago, we noticed that most sites develop Charters and Scopes and Implementation Visions - nicely bound and impressive to view from a distance. But once they were written, they collected dust and were never referenced again - certainly not what most would consider useful project documents. The problem was that very few people ever referenced these items, and they were not widely shared among the stakeholders, let alone the project team.

We also noticed that vendors would provide a Scope Document as part of the purchase. These Scope Documents stated WHAT you bought, but did nothing to state HOW you would use them in your organization. Integrated systems are highly flexible, and how you choose to use them can vary greatly from hospital to hospital.

So, projects would march along feeling comfortable because there was a Charter on the credenza in the CIO’s office and the vendor had provided a Scope Document. Here’s where the problems would begin. Part way into Design, nursing might say that they need 25 assessments built, and Pharmacy feels that they could benefit from 5 or 6 as well. How about 50 or 60 ordersets to go along with that? And a couple dozen reports. After all, you did buy a report writing utility. Your project has now encountered SCOPE CREEP, and you are still in Design mode.

At Atlanticon, we believe in providing a Common Sense approach to projects. Projects should not be measured by the pounds of documents created, but rather, the ease with which your team can carry out their duties and the quality of your finished product. In order to aid in this, we encourage all hospitals to create a Scope Document that explains your project, not your purchase. It should cover:

What you've purchased
The primary function / purpose of each purchased item
Who will use it
And exactly How it will be used

You also want a Scope Document to cover ALL the new components, such as:

New Systems
New Applications
Support Tools
Hardware
New Interfaces
Conversions

Finally, you want a Scope Document to be bound, approved, and signed by all the Stakeholders before your project begins. This keeps your project from creeping into the next 3 years.

Atlanticon believes that a proper Scope Document should address purchased modules as follows:

Application: Order Management
Function: Allows the tracking of all orderable items and provides clinicians a method for requesting items and services electronically, generating an interface message to outside systems and/or printing requisitions in the providing department.
Used By: In our project, nurses, unit clerks, and doctors will be placing electronic orders to Radiology, Lab, Physical Therapy, Nutrition, and Cardiology. Paper requisitions will print in all these departments, except for Lab and Radiology, who will each receive their orders across an interface and generate requisitions from those departmental systems.
How Used: Each of the departments will perform their duties based on these orders, with Cardiology and Physical Therapy generating automatic charges as a result of the order. Nutrition will generate worklists to assist them in filling trays. Radiology and Lab will receive these orders via interface and perform their duties, as outlined in the section specific for their systems.

Each application, each interface, each conversion should be similarly spelled out.

And if your plans change slightly during the Design phase, the Scope Document should be revised and the revised section clearly marked, following approval by your steering committee governing scope changes.

Another example of how a Scope Document can benefit you comes in the area of hardware. This document should state what types of new hardware the users should expect, helping answer the common question, "Will my printer or workstation need to be updated or replaced?" By stating this upfront, your technical team has a clear guideline on who gets new equipment.

A Scope Document is like a Project Plan - it's created once and maintained / reviewed / referenced repeatedly. And by obtaining the necessary approvals, your scope can't change without the impact being escalated to the Executive level for approval. Furthermore, anyone in your organization can read and understand your project.

Keep in mind that Charters have a place—they serve as a starting point and a vision for the project. And Scope Documents from the vendor serve a purpose, telling you what you have contractually purchased. However, there is not enough detail to make it clear to everyone what the limits are. Scope Documents are all about setting clear limits and providing definition. What systems are involved, what departments are involved, what applications will be used, what interfaces will be in place, what type of equipment will be used, etc. Read your Scope Document carefully and determine if it clearly gives you limits. And make sure the vendor agrees to it—you don’t want to document that you’ll register patients in 15 locations if the vendor was of the understanding there would be 2 points of registration.

Document it, get it approved, bind it, and get all stakeholders to sign it. The Scope Document will help keep your project on track.

When to Boost Your Staff with Consulting Help

Many CIOs and Directors have faced an identical dilemma: “How do I install a new HIS with my current staff so busy? And if I choose to use consultants, how do I utilize them?”

The best answer is, "Use consulting help where you will get the most benefit." Each site is different, and before coming up with the right answer, you have to figure out your most pressing needs. When it comes down to it, you have TWO options for how to use your consulting dollars:

Option 1: Utilize consultants for their skills and expertise in implementing projects, focusing on their knowledge of a particular application. Bring them in to make sure your new project stays on track and is built to allow you to make the most of your new system.

Option 2: Use your OWN people to learn and build the new system. Insert consultants to take over the daily support of the legacy system while your trusted staff obtains all the new knowledge. After all, it's your staff that will need to be the experts after activation. Don’t allow them to get behind the 8 ball.

Assigning your staff to build a new system yet failing to free them from day-to-day support, can cause frustrations. Some of your staff may prefer the comfort of supporting your existing system, occupying their time with old duties and never jump fully into the new system. Be cautious of this. As you plan your next project, please consider both options - Atlanticon is very willing to help with either one.

Vendor Contracts — Keeping Control

For those of you who are about to initiate a vendor contract for a major HIS project, your time to clarify some basic expectations is now. In addition to the legal review required of all contracts, you as an IT or Project person will be living with the contract throughout the entire life cycle. You can benefit by adding some commonly overlooked items before the contract is final.

Once the contract is signed and your project begins, you are locked into the terms. While each contract is vastly different, we have some very simple tips that should be considered. By covering these in the contract, you will have better control as a customer:

Experience - insert requirements into the contract for the experience level of the vendor's analysts - don't take junior level experts
Scope - understand that the scope document the vendor provides usually covers what you purchased and/or the services the vendor is going to commit to the implementation. It typically does not address how you intend to utilize the system. Your RFP may not adequately cover your expectations.
Structure - you need to determine your internal team structure so it works in conjunction with the team the vendor puts together. Discuss this with the vendor and insert language that helps insure the best possible team on both sides
Domains - be clear in the number of pathways, domains, or environments the vendor will commit to build/maintain for you. Development, Training, Production, etc., are examples. Will you need a temporary domain to receive conversion tests?
Build - be very wary of a process where the vendor performs the build for you. How will you control the outcome and how will you insure the quality, maturity, experience, and understanding of those that build?
Team Knowledge - insist on your team receiving adequate training of the system capabilities prior to the decision making phase. Otherwise, you may become your worst enemy and make decisions without adequate knowledge.
Iterative Build - interim build checkpoints or conference room pilots should be put into the contract, with the clear expectation that your system will be built in small pieces until you are comfortable with the design. Perform an iterative build, making sure you are confident that your design is sound and approved by all.
Testing - don't be shortchanged on the timeline provided for testing, and most importantly, understand the vendor's commitment to addressing issues between rounds of testing. Will they provide test scripts?
Liaisons - be prepared with your Liaison strategy and commitment levels, and be confident in the role they will play as subject matter experts with their vendor counterparts
Issues - have the right issue tracking system in place - hospitals tend to delay this. Issues arise and commitments need to be documented, especially during the contracting phase. Be clear who will control the tracking of issues - avoid offers for your vendor to track your issues.
Training - don't fail to count your training dollars in your budget, and set clear expectations of what support will be provided by the vendor. Will they provide a CBT? Will they provide sample training material?
Committees - establish the appropriate level of committees to guide the project, such as Steering Committee, Physician Committee, etc., including members from the vendor.
On Site - clearly document the expectations for vendor visits, including agenda, number of visits, duration, schedule, and participants. Clarify that your visits should begin by noon on Monday and end by 5 pm Thursday, or whatever you feel is appropriate and reasonable.
Partnership - prepare the contract in such a way that there are incentives for both sides to work as a team and succeed together. Be cautious of using too many penalties, as they may backfire and cause one side to take shortcuts to avoid them. Insert checkpoints that will support honesty in disclosure of critical issues. It's all about the safety of the patients - don't lose sight of that in your contract.

Project Liaisons—Gaining Commitment

HIS projects require dedicated effort and involvement from each and every department that will utilize the system. Most hospitals do a fairly good job of obtaining representatives or “subject matter experts” from the larger departments, radiology, lab, nursing. But is it enough?

In order for a project to be most successful, every department needs to be involved in the decisions, the design, the build, the testing, the training, and the activation. How involved? It depends on the complexity of the system in each area. For example, if physical therapy will only receive electronic orders into the new system, their involvement won’t be nearly as much as radiology, which might have an interface to an RIS, generate charges, post results, and insert PACS images.

In either case, all involved departments need to assign a Liaison to the project. And it is up to the project manager to estimate the amount of effort necessary from each. This is tricky to do, but not impossible. The amount of time required of a Liaison may be heavier in certain phases of the project. The project manager should also clarify the duties of the Liaison—how much of their committed time will be spent in testing, design, communication, etc.

In order to solidify commitment from the department and the Liaison, we recommend a Liaison Commitment Form—a simple agreement between the project team and the department and Liaison which outlines the importance and the expectations. It empowers the Liaison to make decisions on behalf of the department and helps secure the mindset that the project belongs to every department, not just IT.

Atlanticon is willing to discuss this in more detail with anyone challenged by a lack of departmental commitment.

Project Readiness—Signing Off In Style

After many, many months of very hard work, you turn on your new system, All goes well – patient care picks up where it left off, new registrations start flowing, bills drop, meds are charted, and you find yourself standing with a large group of happy colleagues. It’s the dream of every project manager. But if things don’t go so well, you may find yourself standing alone. While it may not have been your sole decision to go live, it may seem like it.

HIS projects are group efforts. They don’t belong to IT and they don’t belong to the project manager. The success belongs to everyone – each department, each liaison, each analyst, each vendor rep, each director. If everyone is willing to share in the success, they must all be willing to share in the responsibility. We frequently see a team divided at the first sign of a post-activation problem. But it doesn’t have to be that way - - - provided you implement a good Project Readiness Signoff document

Prior to go-live, your project needs to have two Go/No-Go meetings with the result being that all involved parties sign a well drafted Project Readiness Signoff. There are three major steps to a successful signoff:

You must have the appropriate people at the table to sign their respective sections. An IT member should not sign off for any department – the department Liaision and/or Director should.
The document must address each signoff area very thoroughly and clearly. Don’t simply state that “Pharmacy is ready for activation.” Instead, word the statement, “Pharmacy has been thoroughly involved in all decisions made, validated that the compendium is built properly, all meds have been tested and can generate charges, pass to charting, and cross the interface. Pharmacy agrees that the system is ready for activation and all Pharmacy personnel are familiar with the system and deem it safe use.”

Include all appropriate personnel of the project (your extended project team, if you will) in the signoff process – those in charge of each involved department, the interface and conversion leader, equipment manager, help desk supervisor, training leader, activation planning crew, finance, etc.

When your extended team signs and gives their blessing to proceed to activation, they now have a stake in the outcome. And in the event that something goes wrong, the “team” is more likely to stay together and fix the problem.

The final benefit to having a quality signoff is that each person, knowing they are expected to sign, will put a little more priority on a review of the system prior to go-live. That extra bit of validation may uncover some remaining bugs before activation.

Setting an Activation Date

In the recent past, Atlanticon has consulted with many different hospitals, all asking us to help them determine an activation date. Setting an activation date is an extremely important and sensitive subject.

Setting a date is important for the obvious reason—you need a target to drive toward. But what drives the setting of a date? Many things:

You must shut down an existing system at a certain time due to support or contractual dates
A new implementation has a daily cost—the sooner the activation, the better
Commitments made by executive staff to the Board, the community, or other stakeholders
Contractual obligations with the vendor
A rush to recognize the savings or benefits of the new system

While no one can argue the importance of setting a date, Atlanticon cautions against publicizing it too early.

Accurately setting an activation date too early in the project can be like trying to hit a bullseye in the dark. Large HIS projects have enormous amounts of variables that can alter the activation date. Unexpected team member changes, faulty code, errors in design or build, unexpected system issues, delays in hardware readiness, slow decision making, and interface issues are just some of the many things that can help derail a project.

Once your executive team publishes a date to the user community, it becomes very difficult to change that date. Changed dates can give the perception that the project wasn’t managed properly, the vendor wasn’t delivering successfully, or the system isn’t safe. And the real reason may be none of the above. But the fear that a delay will be received incorrectly, is sometimes enough to force a project to move on when a delay may have been in the best interest of everyone.

There is a reasonable way to approach this. We recommend that you select a date that is driven by a complete and thoroughly reviewed project plan. Once that date is selected, it should not be published to anyone outside the immediate project team. The early announcement should be general, such as, “The new system will be ready for use in the first half of 2010.” When is it safe to pick a date and put a stake in the ground? Atlanticon recommends that you announce an exact date at the completion of integration testing round 1. Only then will you have a comfort level that design is solid, build was successful, and the system functions as a whole. You will have at least two more rounds to work through remaining issues, but at least you’ll have a fairly strong comfort level with the date you announce.

More Through Motivation

Have you ever been part of a phenomenal project team? You feel that together you can accomplish anything. Everyone has a “can do” attitude, each team lead takes ownership of his/her assignments, and teammates jump in to help when a colleague is in trouble.

While these projects leave a wonderful, lasting impression, not all projects enjoy the same dynamics. Occasionally, Atlanticon joins a project and we witness a lack of motivation, team burnout, and even organizational resistance to change.

Hospital IT projects need to succeed - patient safety is at stake. You need your project team to be stellar. Your employees are the most valuable resources you have. Giving them an emotional tune-up from time to time is a great investment.

When Atlanticon encounters some "not-so-stellar" team dynamics, we recommend a pep talk. Not just any pep talk—we encourage our clients to seek the help of a specialized speaker – one that focuses on motivating teams and encouraging a cohesive work relationship. The turnaround in morale and project enthusiasm can be amazing.

Lack of motivation can account for a 15-30% drop in productivity, and that’s an enormous cost by all counts. Enlisting the help of a speaker for even one successful “session” can pay for itself many times over by way of performance improvement, and help you achieve a long lasting change in how your team views themselves. Here are some indicators that your team might benefit from a team building session:

Lack of participation at team meetings and/or general non-responsiveness
High occurrence of absences, especially when deadlines are looming
Complaints about too much work or responsibility
Lack of ownership of issues or tasks
General feeling of negativity and isolationism
Open comments relating to failure of the project

Atlanticon exclusively utilizes one partner for this purpose, Ms. Jane Boucher, a nationally known author and speaker on this topic. She is the author of, “How To Love The Job You Hate” as well as several other motivational books.

Jane is also very effective when asked to review a work team to identify reasons for diminished performance. She effectively takes the next step to help mediate a team to be highly effective. Next time you notice a low morale, remember this article and consider the benefits of repairing the team you have. People need tune ups too!

If you think your project or organization might benefit from such a service or would like to discuss this further, please contact us.

Assigning Ownership in Your Project

Have you ever learned a lesson the hard way? Those lessons seem to stick, and I’d like to share one of my own, courtesy of the first project I ever managed. They don’t teach this stuff in textbooks – or if they do, they don’t highlight it enough.

I was managing the install of a large HIS. My project plan was in good shape, I had all the major teams created, departmental liaisons were established, and we were rolling. We were about to positively alter the workflow of every department in the hospital, replacing nearly all the legacy systems. Months into the project, the training phase was about to begin. The training leader was now ready to review all the modified policies and work them into her training curriculum. We had liaisons. Surely they knew that they needed to modify their policies by this time. Well, apparently they didn’t. One quick meeting and we recognized that there had not been a single point of contact from the project team assigned to ensure everyone understood the task of “Revise policies” – and more importantly, to ensure that they were all completed in a consistent, hospital-accepted fashion. And who would have known that policy revisions have to go through a committee that only meets every other month (and just met the prior week.)

Here’s where my big lesson came in – the part that added pain to the learning experience. Since I had failed to assign anyone as the point person, and now everyone was too busy to take on this task, I learned that the Project Manager (me) gets to absorb the unassigned duties.

I spent the next two weeks of my life working way too closely with policy details from every department, helping everyone understand the changes that would take place and how those changes would alter current departmental policy. Calling an emergency meeting of the Policy Board so they could review and approve nearly 75 new and revised policies, was not a picnic either.

We have incorporated this lesson into Atlanticon’s standard methodology—and leave nothing to chance when it comes to ownership. We push to make sure that there is a designated owner for all aspects of a project. Every key file, every set of screens, all reports, policies, finance, forms, security, activation—all these areas need a designated coordinator to make sure that proper attention is being given.

Atlanticon utilizes an org chart for naming leaders to all teams, in concert with an Ownership Matrix that covers the bases for all key files, applications, and other functions. This results in team members that know what is expected early in the project, it reduces the chance of someone inadvertently overwriting your work, and gives the entire team a solid understanding of who they need to speak with for most of the areas of a project. All of this reduces the unnecessary traffic that a PM has to handle and it’s just one additional approach that helps make an Atlanticon project go more smoothly.

Simplifying Your Post Activation Audit

Objective measurements of your success may consist of the following:

Average retrieval time for lab results will be reduced by 25 seconds.
Reported patient safety issues due to medication errors will be reduced to 1 per month.
Application will remain available to the user community 99.98% of the time each month.

Subjective measurements may come from the following types of evaluations:

The equipment in my department is fully functional, and all PCs, printers, and other project related

devices work as expected.

Users in my department are able to access the system with all necessary security rights.
The training I received was adequate and we are now functioning with appropriate knowledge of the system.

Project or Program Managers also appreciate subjective measurements, usually done with a Lichert scale survey. Some project teams have great intentions, but due to a lack of time or a lack of experience, end up doing nothing in the way of a post activation audit. Atlanticon suggests that before you opt for “nothing” at least consider the subjective style of auditing. It’s simple AND effective.

We suggest you develop ten different questions with a 1-10 scale. Survey each department 5-10 days post activation and arrive at a satisfaction score for each department, each question, and across the facility. Survey the same individuals in each department 30-60 days later and compare the improvement. The numbers are very powerful and speak volumes about the success of your project.

Not only will you have quantitative numbers to boast your success, but you will have been able to pinpoint dissatisfied areas, allowing you to focus some much needed attention.

Tracking Issues in Your Project

Tracking project issues properly and diligently is one of the most important things you can do for your project. One of the first things we do when joining a project is to assess the manner in which issues are being tracked, and the tool that is being used to track them.

We should define an issue first. An issue should be any outstanding question, concern, problem, or decision that you feel needs to be tracked or documented. Let’s face it - issues begin mounting as soon as the system is selected. Every issue you encounter should be logged and tracked, reducing the chance of addressing the same item twice - - or not at all.

Project issues belong to you, the hospital. In order to effectively record and track them to completion, you should avoid the following common pitfalls:

Don’t try to make the current help desk software double as a project issue tracking system.
Don’t utilize the vendor’s issue system as your only means of tracking issues.
Don’t open the issue tracking system to too many hands.
Don’t attempt to use a spreadsheet based software to track issues.
Don’t wait too long to begin tracking issues.

Atlanticon has created an Access based issue tracking system called HITS, which stands for Hospital Issue Tracking System. It was developed for use at all our client sites to help them alleviate the cost of purchasing a system specifically for tracking issues. HITS became so well utilized, that we decided to give it away to any hospital that has an issue tracking need. It’s our way of helping offer something to the healthcare IT community.

Here are some of our recommendations when it comes to issue tracking systems:

Recognize the value in documenting key decisions and resolutions
Utilize a flexible, report-rich database system
Plan ahead and create fields and values that make sense and are useful
Determine who will have access to it (we recommend team leaders and PMs)
Develop clear rules for logging issues, defining what your team deems an “issue”
Make the review of issues a standard part of your regular team meetings
Assign someone to oversee the quality of information being logged

Here is a sample of the issue entry form from HITS. Feel free to contact Atlanticon for a complimentary copy of HITS.

Implementing Ordersets – Good Planning is the Key

When implementing an Orderset within a new HIS system, correctly meeting the needs and wants of your physicians, nurses and other end users is key to success. It is often very difficult to address existing and newly requested functionality, requirements, and regulatory compliance while at the same time reducing medical errors and addressing many other issues and concerns. That’s why it’s important to thoroughly work through and map out the entire process.

Utilizing experienced resources to plan, design, build, test, and implement the new system is vital for getting the system up and functioning within the allotted timeframe and budget while at the same time gaining approval from the end users. With a resource that provides the proper experience, information, planning and foresight, you can avoid unwanted issues and problems.

The Plan The plan needs to include adequate communication, design, approval, testing, and training with the appropriate clinical representatives. The representatives should thoroughly understand the new capabilities and limitations of the system and whether or not the new functionality will work seamlessly with the expected workflow process. Your plan should also include processes that accommodate new requests and requests for revisions, and processes that address how these changes will be implemented and communicated to the users.

An effective plan will provide a thorough review with the clinical decision representatives to make certain all concerns and potential issues are identified and that a clear process for resolving those issues is in place. Include the following primary phases/activities in the plan:

Assessment – Create a list of all currently active Ordersets and the proposed list of Ordersets required for activation with the new HIS system. Identify current and proposed processes for revising active Ordersets and adding new Ordersets. Prepare a project plan that identifies key tasks, personnel and the time needed to accomplish the project.
Communication – This should be ongoing. Share all information with individuals or groups who are involved or use Ordersets; this will greatly reduce the chance of missing key elements of the process. The significance and spirit of the Orderset requires excellent, open communication among all parties.
Development Planning – Further develop the project plan by adding detailed information and tasks. Assemble key individuals and groups who will be involved in the project and discuss their roles and responsibilities. Identify and document the standards that will be used when designing and building each Orderset. Create documents and templates that will be needed to design, build, test, and communicate each step of the project.

Identifying the complexity of the various Ordersets and separating them into groups based upon complexity helps determine the timeline and level of effort to complete the development of the Ordersets. In some cases the use of a “trial” or test phase to validate the amount of time and level of effort for each “class” of Orderset will help you plan. Have a kickoff meeting with all parties present. Review each step of the process and fully explain how the primary tasks should occur and why each step is important. You’ll find your resources are more likely to provide better quality and energy if they understand the importance of the “why’s.”

Design Phase – Create a paper or electronic version of the requested Orderset (making sure to adhere by the standards that were previously identified), and gain approval/signature for the design. This should be done systematically by facility, specialty, group, or individual based on the needs of the organization. This systematic approach will allow for the least amount of interruptions in the normal day-to-day operations of the personnel that will be providing the design specs and approvals.

There will be modifications to the requested Ordersets, so bear that in mind when determining how to track the Ordersets and their associated change requests. Using good change management practices will save time, effort and, most likely, your sanity.

Build – Build the approved design on the new system. Remember to build these in the appropriate Pathway and migrate them when they have been fully tested. Some may argue that building them in the Production Pathway is safe and better. Trust us when we say it is not wise to build anything in your Production Pathway. This can cause numerous issues within your new module/system that may never have been considered or impact your other modules negatively. Remember most systems today are integrated, enterprise solutions and should be tested that way to ensure a smooth running solution.
Testing – This is a two-step process. The analyst who is building the Orderset on the system should verify that the Orderset has been built to design specifications and test to make sure the Orderset will process correctly (i.e., all orders are orderable at each facility that will utilize the Orderset). Next, a clinician who will be utilizing the Orderset should test to make sure the Orderset processes and functions as intended (i.e., order/actions appear at the expected time).
Approval – Obtain final approvals and signatures for the build from the appropriate committee, group, or individual. It’s best to have signoffs at each stage of the development process. This helps to ensure each stage is on track and reduces the chance that the Ordersets will have to be redeveloped. When clinical and business users understand the system capabilities and participate throughout the process, the better your results will be. Keep in mind this system is for them—they need to feel involved and be part of the new changes.
Training – Provide an appropriate amount of training on the functionality and process for entering, discontinuing, or modifying the new Ordersets. Training should actually begin during the Assessment or Development Planning phase. This will help down the line, but more importantly, it will enable the clinical representatives to make more knowledgeable system and workflow decisions. While seeing demos are beneficial, rolling up your sleeves and actually using the new Ordersets makes a significant impact.
Activation – Prior to activating the Ordersets, communicate to all appropriate personnel specifically which Ordersets will be available and on what date and time. Keep in mind that the migrations from the Development Pathway to the Production Pathways will need to be considered. Remember, it’s never as simple as turning on a light switch.

Problems with Ordersets development initiatives usually begin in the Assessment Phase, when clinicians and other essential personnel are not familiar with the functionality and capabilities of the new system. Communication and documentation are vital for preventing misconceptions about the functionality of the new system.

When you follow the above key steps to create a smooth transition from your facility’s current Orderset functionality to the new system’s functionality, you’re setting up for success.

Efficient Report Coding for Effective Use

When designing and developing custom reports, it is best to step back from the detail to see how a few slight modifications in design can open opportunities for the reuse of programs in other areas of your organization. For example, consider a request to produce a report that prints information for patients with Multiple Sclerosis. By designing the report so the Multiple Sclerosis code was an input parameter instead of hard coded within the report, the organization can also produce a report for the Cardiovascular Department that listed all heart related problems. There is no need to worry about the user having to enter the specific code for the report they need. By using some creative screen building techniques the parameter can be applied to the report behind the scenes.

Cost savings for developing reports that are parameter driven not only save time and resources during initial development, but will also keep long term cost down for report maintenance and during system upgrades. The fewer custom reports you have to maintain, track, and migrate, the better.

Create and use a Custom Reports Standards document that outlines all the “must have” elements on each report. For example, all reports must identify the source program name, be able to process for one or all facilities, include totals whenever applicable or have a page number in a certain location. Setting standards early can improve support capabilities by making custom reports easier to identify and locate.

Have you ever found a user pulling the same report 3, 5 or even 10 times in a row for different patients? Have you noticed what that does for overall system performance? If the report is driven by the entry of an account number, consider modifying the report to print by user’s Hot List or Common List of patients, such as those assigned to a nurse during his/her shift. This allows the user to put the entire group of patients in one report request, causing a single occurrence of the report to process instead of one occurrence for each patient. Using this coding method will greatly improve the efficiency of both the report and overall system performance.

Tips on Building Your RIS Exam Dictionary

While this article was written with GE’s Imagecast in mind, it applies to most all RIS projects. When designing Imagecast RIS, one of the most important aspects is preparing and building your Exam dictionary. Every exam that can be performed in an Imaging department is built as a specific entry in the Exam dictionary. Most functions performed within the system will reference the Exam dictionary at some point. The Exam dictionary contains information relating to every diagnostic test that is performed. Each entry includes billing codes, duration, which room(s) the exam can be performed in, and many other data elements which enable proper scheduling.

One of the most troublesome aspects of building the Exam dictionary lies in the naming convention given to the exams. In Imagecast, each exam is assigned a description as well as an exam code. The codes and descriptions are used by all clinicians accessing the system when searching for exams to schedule, arrive, or complete. As the exam code section of the Imagecast exam dictionary is limited to ten (10) characters and as each code must be unique, the following recommendations should be followed in order to make the search process easier for your end users:

Begin each exam code with an abbreviation of the modality for which it belongs. For example, an Ultrasound of the Carotid Arteries could be given an exam code of USCAR - (US for Ultrasound, CAR for Carotid).
Abbreviate contrast information for exams. When building CT Abdomen exams, this is an example of codes:

Standardizing whenever possible will make codes easier to maintain and simpler for schedulers to find. Here are some examples:

Avoid building exam codes with special characters such as dashes or slashes. A user will have more difficulty searching for an exam code of CT-ABD versus CTABD because they have to enter the dash.

Build the Exam dictionary in Excel or on paper BEFORE entering into the actual dictionary. Make sure supervisors and leads from each modality (CT, MRI, US, etc) have reviewed for accuracy and signed off before actually loading the information into the system. Exams that are found to be inaccurate can be inactivated, but never deleted.

Approaching the build of the Exam dictionary requires a concerted and organized effort. By spending additional time on design to insure a consistent naming convention is used, by completing the entire exam dictionary in Excel and by obtaining validation from all Radiology departments you are headed towards a successful implementation.

Good Planning is Key to Implement Ordersets When implementing an Orderset within a new HIS system, correctly meeting the needs and wants of your physicians, nurses and other end users is key to success. It is often very difficult to address existing and newly requested functionality, requirements, and regulatory compliance while at the same time reducing medical errors and addressing many other issues and concerns. That’s why it’s important to thoroughly work through and map out the entire process.

Assessment – Create a list of all currently active Ordersets and the proposed list of Ordersets required for activation with the new HIS system. Identify current and proposed processes for revising active Ordersets and adding new Ordersets. Prepare a project plan that identifies key tasks, personnel and the time needed to accomplish the project.
Communication – This should be ongoing. Share all information with individuals or groups who are involved or use Ordersets; this will greatly reduce the chance of missing key elements of the process. The significance and spirit of the Orderset requires excellent, open communication among all parties.
Development Planning – Further develop the project plan by adding detailed information and tasks. Assemble key individuals and groups who will be involved in the project and discuss their roles and responsibilities. Identify and document the standards that will be used when designing and building each Orderset. Create documents and templates that will be needed to design, build, test, and communicate each step of the project.

Design Phase – Create a paper or electronic version of the requested Orderset (making sure to adhere by the standards that were previously identified), and gain approval/signature for the design. This should be done systematically by facility, specialty, group, or individual based on the needs of the organization. This systematic approach will allow for the least amount of interruptions in the normal day-to-day operations of the personnel that will be providing the design specs and approvals.

Build – Build the approved design on the new system. Remember to build these in the appropriate Pathway and migrate them when they have been fully tested. Some may argue that building them in the Production Pathway is safe and better. Trust us when we say it is not wise to build anything in your Production Pathway. This can cause numerous issues within your new module/system that may never have been considered or impact your other modules negatively. Remember most systems today are integrated, enterprise solutions and should be tested that way to ensure a smooth running solution.

Testing – This is a two-step process. The analyst who is building the Orderset on the system should verify that the Orderset has been built to design specifications and test to make sure the Orderset will process correctly (i.e., all orders are orderable at each facility that will utilize the Orderset). Next, a clinician who will be utilizing the Orderset should test to make sure the Orderset processes and functions as intended (i.e., order/actions appear at the expected time).

Approval – Obtain final approvals and signatures for the build from the appropriate committee, group, or individual. It’s best to have signoffs at each stage of the development process. This helps to ensure each stage is on track and reduces the chance that the Ordersets will have to be redeveloped. When clinical and business users understand the system capabilities and participate throughout the process, the better your results will be. Keep in mind this system is for them—they need to feel involved and be part of the new changes.

Training – Provide an appropriate amount of training on the functionality and process for entering, discontinuing, or modifying the new Ordersets. Training should actually begin during the Assessment or Development Planning phase. This will help down the line, but more importantly, it will enable the clinical representatives to make more knowledgeable system and workflow decisions. While seeing demos are beneficial, rolling up your sleeves and actually using the new Ordersets makes a significant impact.

Activation – Prior to activating the Ordersets, communicate to all appropriate personnel specifically which Ordersets will be available and on what date and time. Keep in mind that the migrations from the Development Pathway to the Production Pathways will need to be considered. Remember, it’s never as simple as turning on a light switch.

When you follow the above key steps to create a smooth transition from your facility’s current Orderset functionality to the new system’s functionality, you’re setting up for success.

Assessment – Create a list of all currently active Ordersets and the proposed list of Ordersets required for activation with the new HIS system. Identify current and proposed processes for revising active Ordersets and adding new Ordersets. Prepare a project plan that identifies key tasks, personnel and the time needed to accomplish the project.
Communication – This should be ongoing. Share all information with individuals or groups who are involved or use Ordersets; this will greatly reduce the chance of missing key elements of the process. The significance and spirit of the Orderset requires excellent, open communication among all parties.
Development Planning – Further develop the project plan by adding detailed information and tasks. Assemble key individuals and groups who will be involved in the project and discuss their roles and responsibilities. Identify and document the standards that will be used when designing and building each Orderset. Create documents and templates that will be needed to design, build, test, and communicate each step of the project.

When you follow the above key steps to create a smooth transition from your facility’s current Orderset functionality to the new system’s functionality, you’re setting up for success.

If you would like additional information regarding this article please send an email to Business.Services@Atlanticon.net requesting a copy of “Good Planning is Key to Implement Ordersets”.

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!

Project Work Area – Sitting Together, Succeeding Together

How many times have you been involved in a large project where you feel as if your teams are working in silos? Well intentioned project members work diligently on their assignments – teams for pharmacy, orders, registration, and clinical documentation, all work hard to design and build – yet they seem to lack the confidence that they are building an integrated system that makes sense and works seamlessly. That’s because integrated systems require integrated design, integrated tailoring, and integrated testing. And how do you get at? By incorporating integrated seating!

Whenever a hospital undertakes a large implementation project, Atlanticon suggests the creation of a common work area to insure you 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. They 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.

Call Today & Start the Conversation

Our team of healthcare system installation professionals have the experience you demand to help you with any phase of your project — from vendor selection through final audit. Contact us today.

866.213.3100
Dayton / Fairborn, Ohio 45324

Dayton Ohio Website Design - Web Site Helper LLC