I’m writing this blog entry in a tool from Microsoft called Windows Live Writer. It’s designed for writing and posting blog entries. Funny thing about it: It works great for blogging. And because it is designed specifically for blog writing, it serves my needs right now better than other Microsoft software solutions like Notepad or even Word. I could write my blog with either of those applications, but it wouldn’t be as efficient for me. In the same vein, should I need to whip together a flow chart, I’m most likely going to switch over to a tool like Visio instead of using Paint or Word, even though I could use either of those two latter tools, because Visio was designed for drawing.
At this point, you probably think I’m an idiot, right? I’m pointing out details and advice that you can get from any intern in your office. But even though this is basic information that we all inherently understand when it comes to our office computer tools, it’s a concept that is far too frequently forgotten when it comes to implementing a scheduling software solution.
At some point in your healthcare scheduling implementation, you have a software scheduling system that you have picked and are going to implement. It is at this key juncture, as you prepare to design your scheduling process and configure-then-deploy your solution, that you need to take very careful consideration of the features of the scheduling system that you have purchased to implement. Every scheduling system is designed to do certain things really well. That’s how they differentiate themselves from each other and that’s what makes some products really great.
But as I wrote last week, there is no perfect scheduling system! Every system is going to be flawed somewhere, somehow, and not handle every single function or process as perfectly as a user might want. But, balancing that out, all good software systems have a team of folks who have worked hard to figure out the best ways to handle certain processes and have incorporated that knowledge into their application. Their system going to be awesome for certain processes and functions because they designed it to work in a certain way! The challenge for you, the implementation team, is to design your scheduling system and processes to take advantage of what your software solution does really well and avoid trying to make it do things it was simply not designed to do.
This is maximizing your system solution. And it is a challenge because when it comes to scheduling processes and functions, as we talked about before, your users are emotionally attached to their current processes, which you are not going to be able to perfectly duplicate in the new system. Think about the office software we started with. If you have Word, you can do a lot of great things with Word that are specifically related to word processing. It is what Word does best. Microsoft also put in Word a subset of tools related to shapes. If you have some simple shape-related requirements for your word processing, Word has you covered. But if you want to draw intricate network infrastructure diagrams or edit photos, you are going to go to other tools that do those tasks well, like Visio and Photoshop respectively, instead of sticking with Word’s shape-related tools. Trying to do those tasks in Word will just frustrate you and not get you quite where you want to go.
The same concepts apply for scheduling solutions. Every scheduling system has unique features that make it designed to handle specific processes really really well. And each one has processes that it doesn’t handle quite as well. A good implementation design is one for which you design scheduling processes that take advantage of the scheduling system’s strengths. This is a common sense rule that is pretty easy to follow, practically speaking. There’s a corollary to that rule that is much harder to follow: Don’t fight the system and try to make it do what it doesn’t do. That is a sure-fire path to a frustrating process design, frustrated users, and an implementation that may be very well viewed as a failure.
Unfortunately, that’s much easier said than done. You remember those processes that users are emotionally attached to? Convincing them that it’s no longer going to be possible to (pulling from a real life example) create rotating schedule patterns for a month at a time that have special rules for when there is a fifth weekend in the month, and that instead, they are going to create a six week scheduling pattern that allows for rotating every third weekend (did you follow all that?!) is a massive challenge and a good reason to have a change management strategy and strong leadership support. But it also is a good example of taking advantage of a scheduling system’s strengths (patterns of multiple weeks) instead of fighting to come with an awkward way to handle an obscure process that your scheduling system (nor any good system that I have ever seen!) does not support.
I have seen scheduling implementations get bogged down and stall out because the implementation design team can’t get past a process that the system doesn’t support. And instead of designing a new process that the system handles beautifully, they create an ugly process that barely accomplishes what they wanted. The end result: The user is not happy with the ugly process. The funny thing is: If the implementation design team did not create the ugly process and instead created a process that maximized the system functionality, the user would still not have been happy, but the process would have been great instead of ugly. Bottom line: Users may not be happy no matter what you do. Deal with that separately and don’t let it affect your design.
Your design should be taking advantage of what your scheduling system does well – that’s why you bought it, after all! (There’s another topic – how this guideline should impact your vendor selection process – but we’ll save that for another day…)
