Recently while conducting some market research I read a startling statistic. Industry analysts like Strategic Directions estimate that of all commercial LIMS deployments undertaken, 60% failed to deliver original customer requirements. This was largely following expensive and time-consuming deployments.
Now, being a slight cynic at heart (and a big fan of Levitt and Dubner’s Freakonomics) my immediate reaction to this statistic was one of scepticism. After all it is a self-admitted ‘estimation’ as opposed to a quantitative data analysis. Another factor that made me pause for thought was the abstract concept of ‘failure’ based on customer expectations (which of course can be notoriously unrealistic). Especially considering the lofty expectations of the functionality of an out-of-the-box LIMS which many commercial labs have.
Even despite these factors potentially contributing to the hyperbole of the statistic presented, the true number must surely still be surprisingly high. I therefore decided to examine just a few of the issues that could hamper, or completely collapse, a commercial LIMS implementation.
Exceeding Budget
The first issue that could lead to the scuppering of your LIMS implementation is undoubtedly, budget. Budget is quite literally the be-all and end-all of any large-scale IT project. When your average initial implementation project can cost between £150,000 – £1,500,000, it can be difficult to predict how much it will cost. If the goalposts are set this wide from the offset, setting your budget can be problematic. When a difference of +/- £100,000 can spell the end of an implementation project, accuracy is of tantamount importance.
Therefore it’s aspects of an implementation project that cannot be accurately predicted that pose the biggest threat its success. Despite the vast majority of implementation projects being supported by a consultant, there will often be some form of issue. Additional requirements also may become apparent during the process. Depending on project size and complexity, this can require anything from a small additional amount of coding, to potential revalidating the entire system. All of which could spell disaster for your budget.
Validation, Validation, Validation
Custom coded LIMS can be fantastic for extending the capabilities of your system. It could be for adding in a particular module in order to suit business requirements, or revamping the entire system in order to manage workflows and data effectively. However as flexible as these solutions can be, they do come with an inherent risk in the implementation stage. Even if you are simply modifying the original LIMS with custom modules. The main issue of custom coding is remaining compliant when working in any kind of GxP environment.
Based on this, any changes to the system have to be validated to ensure compliance. With the addition of custom modules or even a full customised solution, this can result in an excessive amount of time-consuming validation. Of course when implementing your LIMS, time equates to money. On the subject of validation, even in a non-regulated environment it is also important to remember the sometimes fickle nature of software development. While some clever coding might fix the immediate problem you seek to address, revalidation is still necessary. This is to ensure that it does not inadvertently break another feature.
Personnel Vacuum
Imagine you set out your initial project team of ‘x’ people, but after a few months something becomes clear. Either the workload is too much or there is additional support required. It could be in business analysis, coding or implementation. This additional support either comes from within your existing staff, who are now tied up until the completion of the project, or from external consultants. This may run the inherent risk of unfamiliarity with business processes and increased cost. If the implementation is not properly planned or unforeseen issues arise during the project, it can have disastrous consequences.
Conclusion
Through examining of the various factors that could impede or derail a LIMS implementation, it is perhaps conceivable that 60% could be accurate. In terms of failing to meet customer expectations, 60% seems excessive, but it is true!
I’d be interested in hearing your thoughts on the subject. Any tips you have for a pain-free LIMS implementation/horror stories of implementations gone wrong!
I’ll be following this blog up with a second part next month. I’ll be discussing methods that can be employed in maximise the success of your LIMS implementation.
Thanks for reading!
