Mitigating the common pitfalls of LIMS implementation
Posted: 19 February 2014 | | No comments yet
Over the past 20 years, I have participated in numerous LIMS implementation projects in a variety of roles. I have participated as a subject matter expert (SME), validation coordinator, programmer, System Administrator and technical representative, and have worked both in the laboratories and IS during these projects; gaining an insight to both perspectives. Over time, I have come to realise that all projects will experience common pitfalls that impact the success of the project. The information presented below is based on my personal experiences across all LIMS projects in which I’ve participated.
In general, the problems in every project revolve around three things: Budget, Timelines and People. Issues from any of these can derail a project. What many people fail to realise is that the most common points of failure in a project occur before a vendor is even selected. This is primarily due to a lack of understanding of the effort and cost involved in a LIMS implementation. Failure to understand and address these issues in the infancy of the project will certainly have a negative influence on how the project proceeds and whether it is successful in the end.
The first decision is determining the project budget. Whatever you think a LIMS project will cost, add at least 10 per cent. For larger projects, such as multi-site or international implementations, add 20 per cent to your projected budget. This covers changes in scope, changes to the timeline, consulting costs, validation and all those unanticipated cost overruns. Every project I have been part of has run over budget. In the end, this reflects poorly on the entire team.
Now that you have a budget, you need to determine the timeline. In the pharmaceutical industry, on a project that requires validation, the minimum time for a LIMS implementation is around 18 months. A typical, multi-phase, multi-site project will take 18 – 36 months to complete for the first phase. Phases are normally broken out by site or functionality. To properly determine the timeline, the scope of the project must be understood and agreed to by everyone involved. Granted, there is always ‘scope creep’ (e.g. functionality not in the requirements), but the better the project is defined at initiation, the fewer changes in scope will occur as the project gets rolling. And of course, scope creep will lead to an increase in spending, thereby impacting your budget.