Timelines – Should They Stay or Should They Go Now

Guiding your Healthcare IT project along a timeline dictates a lot about your project.  Keep in mind, some contain hard stops that not only can’t be moved but are show stoppers.  Building allowances in your timeline for evolving information to influence workflow is a necessity.

Software vendors, such as Epic, are very upfront and provide boilerplate guidelines to work with.  PLEASE remember these are just guidelines. While they are given with best practice knowledge in most cases, they are not customized for the needs of your institution, your staff who will be doing this work, or the clinicians you need to adopt the system.  It’s important to put some leg work into what makes this timeline feasible for your facility, project team, end users and a few other affected areas.

You need to do your due diligence and speak with those within your establishment that have implemented any type of software institution wide and get your own set of lessons learned within your own group.  You will find that there are certain departments that “need a little extra personal attention”  while other groups may need hardware upgrades.  Don’t forget to factor in the training time for all groups.  Work closely with your existing departments to get their concerns addressed.

Take all of the above and mix them into the vendor’s suggested timeline and you should come out with a timeline that is more realistic for your group.

Throughout your project plan there are checkpoints built to see just how you are doing.  Are you a little behind or are you uncomfortably behind?  If you are either, find out why and fix the situation.  If it is because people aren’t making decisions quick enough, express that to your stakeholders so they can go to bat for you, impress upon them that their lag is causing  a ripple effect in the timeline.  If it’s build, bring in a few consultants for 60-90 days to catch up.  If you are ahead, that’s not a bad thing; make sure to share with your project team so they know that they are accomplishing great things.

You can push back a Go-Live if need be; don’t feel that your original timeline is an absolute do-or-die situation.  Nothing hurts more than going live and finding out the product just won’t do what you expected.  Your end-users and leadership will lose their faith in the product and project team incredibly fast so let’s not put them into this position.

If everything is going ahead of the plan and timeline presented, move the Go Live date up if it’s possible.  There are a lot of positives to that.  One of them is revenue.  It takes a few days to follow the money through the system and verify that everything is flowing through claims and such the way it should. Even though you checked it a thousand times in testing, there’s nothing like real life excitement when you see everything falling into place.  Then there is the report writing factor.  Every system has canned reports but those of you that really want those customized reports, you can’t configure them until people know exactly what they want to see.  That happens only with real data in the system.

Whether you push a date back or move it up, make those decisions as soon as feasibly possible so all departments can do their planning for the event.  Writing schedules and posting them with enough advance for families to adjust their home schedules to accommodate a family member being gone for long periods of time or even working a different shift to help is the fair thing to do.

We have truly only scratched the surface on this topic.  Contact Amy Noel at DCS (Amy@dcshq.com) She has access to complete project plans and personnel to help you through it all.