Recently I wrote a blog about the steps required to successfully identify and select a clinical systems vendor that will truly deliver against your needs. Here is the recap of that post:
- Write a business case
- Collect detailed requirements
- Write a clear RFI
- Quickly narrow down your list of candidates
- Host some dog & pony shows, and finally make a decision.
Whew! That’s a lot, and each step is a lot more difficult and involved than it sounds. But that’s the case with just about everything in life really, so I’m sure that being the smart and determined blog reader/system selector that you are, you managed to get through them all. Nice job!
By now however you probably realized that clinical systems selection is just the tip of the iceberg. Now that your company has dropped a good chunk of change because you wrote that nice business case explaining why buying the clinical system was such a great idea, you have to make sure that people actually, you know, use it. Clinical systems implementation can be a tricky business.
All the business cases in the world won’t help if the system doesn’t get rolled out properly, and even the most perfect of clinical systems won’t be of any benefit if implemented in a vacuum.
Spare Some Change (Management)
Any time there are changes, there are going to be problems. People don’t like change. The lack of a change management strategy is one of the biggest reasons these shiny new clinical systems fail to deliver on what they promise. In short, management needs to communicate the changes well before they start happening so people can prepare themselves for any clinical trial software.
Really what needs to happen is essentially a marketing campaign – first teasing the upcoming changes (and the new clinical trial system), then some ‘benefits management’ (letting people know what’s in it for them…you still have that business case, right? Time for a little copy/paste…), setting expectations for future shifts in the way things work, a big launch that’s given some degree of fanfare, and a follow up campaign to reinforce the new order of things (and to remind people how great everything is working out). This is essential for all clinical trial software, especially for clinical project managers.
All of this needs to be scaled to match with the impact that the new clinical trial management system or any other clinical trial software will have on the organization – be careful not to overdo (or underdo) it!
While this is covered to a degree in the change management piece, it goes a lot deeper than that. First, you need to find the system a home – who is going to ‘own’ the CTMS software? Is it clinical project management? You also need to make sure that every layer of the organization that will be affected by the new CTMS software or other clinical software is addressed in a more ‘personal’ manner. Have conversations with individuals to get a better understanding of their concerns and perhaps more importantly get an idea of their expectations of the new clinical system. Hopefully you’ve already addressed everything way back when you collected requirements, but things change and people come up with new ideas as they see for themselves more of what the system can do. Regardless, you need to make sure that what the people need (a good set of clinical trial reports, for example) will be available from the CTMS system at launch, or you’re setting yourself up to fail.
At a higher level, some organizational changes may be necessary to get everything out of your new clinical system that you want. For example, before the new clinical system you may have had people doing manual data entry as half of their jobs. But the new CTMS system uses fully automated data feeds – what are you going to do with all of that free time now? Or the opposite might be true, where you need some kind of system administrator or business analyst permanently attached to the new system. Make sure you plan ahead!
Process is Paramount
A new clinical system will almost always require a new set of processes. After all, the reason you’re getting a new system is that it’s better (and therefore different) than your old clinical system. But it’s not just the actual interaction with the new clinical system that will need to be looked at. This is a great time to step back and evaluate your overall clinical processes in the area that the new clinical system is a part of (and you’re already of a continuous improvement mindset anyway, right?). This is a great way to “market” your new CTMS system – because let’s face it, the old system wasn’t that bad.
Usually the problems are at least 50% process oriented, if not more. By revamping your processes you can not only make them more efficient but they can be designed in such a way as to dovetail nicely with the new system. When you are issuing your communications throughout the CTMS system selection/implementation project, this becomes a much more powerful message than merely touting a new CTMS system. “Hey, we’re overhauling everything so your lives are about to get way better!”
Testing Users’ Patience
There’s nothing worse than rolling out a clinical system that people find to be buggy and unstable. Even if the issues are minor, a bad first experience can leave a bad taste in people’s mouths for a long time (and perhaps forever). Doing thorough clinical system testing (especially if your CTMS system has been configured or customized) is critical.
User acceptance testing will also help to get a greater number of future users involved to not only spot technical issues but to identify general deficiencies in the system before it gets rolled out to the population at large. Testing is painful but necessary if you are to release a quality “product” to your pharma organization.
Systematic System Training
Even the most simple of clinical systems will require some training, and there’s nothing better than some hands-on sessions where users get their hands dirty. Just keep the extent of the CTMS training in line with the complexity of the CTMS system – don’t overcomplicate things.
Further, training should be focused for each job role as there’s no reason that a person in one job needs to know every little thing a person in a completely different job does in the CTMS system (other than at the highest of levels). A CTMS training plan should be developed well before clinical system roll out so everyone knows what to expect and blocks off time for training on their calendars. But training doesn’t end with the actual training – users will also need access to detailed documentation for refreshers, and creating other aids such as “cheat sheets” and FAQs can go a long way in making sure people can easily put your new clinical system to good use.
By now you’re probably regretting purchasing this new clinical system. Whose idea was this anyway? Take a deep breath and fear not, for with some planning and oversight (and a good fully dedicated clinical project manager) your clinical system can experience a smooth roll out and significant user adoption. Which means you did such a good job with this one that you’ll be the one put in charge of the next one…way to go!