Mitigating the common pitfalls of LIMS implementation

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.

Budget

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.

Timeline

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.

Selecting the project team

The next consideration, is selecting the right people for the project team. All too often, I have worked on projects that are overstaffed, but don’t empower any of those assigned to make the key decisions. This leads to inefficient meetings because the SMEs cannot make decisions. Instead, they repeatedly have to go back to their management and decisions are delayed until the next meeting. Frequently, team members are assigned to the project who do not want to be on the team. This will cause low morale and impact the timelines because they don’t attend meetings, don’t contribute and are often the first and loudest to complain about the system. Ultimately, this leads to a lack of acceptance by the end users.

The second element of a project team is the Steering Committee. It is important to identify not only the team members for the Steering Committee, but the expectations and scope as well. Steering Committee members must be empowered and willing to make decisions about the direction of the project. If a Steering Committee is not designed to provide the necessary guidance and direction to the project team, including conflict resolution and changes in scope or timelines, the project is destined to stall and possibly fail each time a major issue is encountered. However, if the team members on the Steering Committee understand their role in the process and are empowered to make final decisions on behalf of the project, major issues will be discussed and addressed in a timely manner. It is not uncommon for an ineffective Steering Committee to have lengthy meetings to discuss issues only to end the meeting by agreeing to discuss the issues in their particular areas and come back to discuss the issue again at a future meeting. This drags out decision making (assuming decisions ever get made) and frustrates the project team.

Understanding the process

Once the project team is selected, and before an application vendor is selected, it is critical to understand the business process that will be managed using the LIMS. Depending on the scope, this can be a very challenging task. For single site implementations, mapping the current process (‘as-is’) and the desired process (‘to-be’) is relatively straightforward. There is little disagreement about the existing processes and typically, little fuss when defining the desired processes once the system is implemented. However, the more extensive the project, the greater the challenge in defining and agreeing upon processes. When dealing with multiple departments that perform the same functions, or when the implementation will be across more than one site, it is important to have each group or site map out what they see as the current processes. Once the initial mapping is done, a business analyst can help compile the information and identify the differences. Additionally, the business analyst often helps identify options for addressing the gaps.

Harmonisation

Once the differences in processes are identified, the next step is to attempt to harmonise the processes across all areas that will be impacted by the LIMS. This will reduce the amount of customisation required to ensure LIMS meets the needs of all users. Although it is simple to say ‘harmonise your processes’, in practice, this is one of the most challenging aspects of an implementation. However, if done effectively, this preparatory work will lead to reduced impact to timelines and cost. If harmonisation is not done, or the process isn’t complete, the project will experience delays, cost overruns and frustration by all those involved. Often, the SME is not fully familiar with all aspects of the business. Therefore, when working on the harmonisation process, it is important to have more than one representative from each area that is contributing. Once everyone agrees on a harmonised process, the ‘to-be’ process can be mapped. This, along with the User Requirements (URS), is the starting point for selecting a vendor.

Consultants

After vendor selection is complete, it is normal to bring in vendor consultants and/or independent consultants to help with the implementation process. It is rare that a pharmaceutical company has the internal resources to fully configure a LIMS. Most vendors offer consulting services for project management and technical expertise. Validation consultants are typically independent from the vendor.

There are several common behaviours that are encountered with consultants, regardless of the source. The first behaviour that is seen is “just tell me what I need to build the system. I don’t care how the business operates”. This behaviour will lead to extreme frustration for both the consultant and the customer. Because the consultant does not take time to truly understand the business need, they are unable to make appropriate recommendations for the configuration. This leads to rework which leads to extended timelines and budget overruns. If this is the type of consultant you are working with, it is vital for the health of the project to get them to understand early on the importance of understanding the business. Over time, even the consultant gets tired of reworking their own code!

The second behaviour is “your business is operating incorrectly. I cannot configure what you’re asking because it’s wrong”. If you have a consultant who insists they know best how to run your business, get a new consultant. This type of individual will not be open to anything the customer says. If they will even configure the system, it will be configured as they feel you should run the business and will not take customer requirements into consideration. This will lead to a failure during validation and a redesign of part or all of the system.

Third: “I will control everything and give you the finished product. I don’t need to talk with the users; I’ve been doing this for years.” This behaviour is as dangerous as a consultant who thinks they know your business better than you. If your consultant insists on running the project without consulting you, the project will fail. When the consultant is in charge, there is no control over budget or timeline. It is in the best (immediate) financial interest of the consultant to drag out the project as long as possible. If your consultant is trying to take over your project, get them off your project as quickly as possible.

Finally, the ideal consultant: “What is your business need? How do you want the system designed? Is everyone in agreement before I start to build?” Unfortunately, most consultants are not 100 per cent ideal. However, if they possess a fundamental understanding of the pharmaceutical industry, good people skills and technical knowledge of the particular LIMS being configured, they will be successful in supporting your project. A consultant, who takes the time to ask questions, understand the business and take direction from the internal project lead, will keep the development part of the project within budget and timelines.

Configuration versus customisation

What is configuration of LIMS? What is customisation of LIMS? Is there a difference? The conversation around configuration vs. customisation is one of the most common and contentious ones in a LIMS project. I’ve worked on projects where the team spent months defining the terms and deciding what was acceptable. In the end, there was little difference between the two terms. It’s really just a matter of semantics. Both configuration and customisation require a modification of the ‘out-of-the-box’ product. Since LIMS, regardless of the vendor, is intended to be modified in order to meet specific customer needs, implementation of LIMS requires configuration at a minimum.

The most common distinction used when defining configuration and customisation is based on whether coding is required. Configuration is often considered alteration of settings within the application and is designed to be modified by the customer to alter system behaviour. Customisation is typically considered any changes that require coding. However, the line gets blurred when the vendor creates a product that considers a certain amount of coding to be configuration and part of the system design.

It is therefore important to define the terms for your implementation after the vendor has been selected. If you attempt to define this prior to selecting a vendor, you may find that the definitions are insufficient based on the LIMS selected. This can lead to wasted time while the terms are redefined. Worst case, it can lead to a lack of functionality if a hard line has been drawn in the project that does not allow for customisation. If a project team has decided that no customisation will be allowed, and customisation is defined as any coding being done to alter behaviour of the system, and the software selected allows for and expects a certain amount of coding in order to make the system function for a given customer, the project will fail to succeed.

Validation

The final hurdle in a project is validation. The time and cost of validation is frequently underestimated. There are several common mistakes made with the validation of LIMS. The most straightforward part of the validation is the installation qualification (IQ). The operational qualification (OQ) and performance qualification (PQ) components are more challenging to define.

One of the biggest mistakes made with the OQ is attempting to write the scripts at the wrong time. If functionality is still being designed and users have not tested and accepted the functionality, scripts cannot effectively be written. An outline can be started, but providing detailed scripts on functionality that will likely change is a waste of time and money. Instead, wait until each set of functionality has been completed and accepted before writing the scripts. The other common mistake with writing OQ scripts is outsourcing. While outsourcing in general is not always a bad thing, if the script writers are not familiar with LIMS and are working remotely to write the scripts, the scripts are less likely to effectively challenge the system. However, if the script writers spend time on-site, working with the development team to understand the functionality, the test scripts will challenge the system effectively and the customer saves time and money.

There are two common issues when writing the PQ scripts. The first issue is that scripts are normally written by end users. These users are often not properly trained in script writing. The solution? Have the people writing the scripts work with a trained script writer to ensure the scripts meet validation requirements. The other issue is frequently found when the project covers multiple sites or departments that use the same functionality. Does everyone execute the PQ scripts? Are the scripts identical for each group or site? These are decisions that depend on the level of harmonisation that is performed at the beginning of the project and the level of group or site specific configuration and customisation. However, from my experience, it is most effective to plan for each group or site to execute the PQ scripts that apply to their area. This way, the team plans for the longest, most costly approach at the beginning. If the team determines that the testing can be consolidated, everyone wins.

The final question that comes up during the validation process is whether to run performance or load testing. This is not a decision that should be made lightly or at the tail end of the project. Load testing is not the same as performance testing. It is designed to ensure the system can handle the data and users that are expected in the system during normal usage. Load testing takes significant planning and resources. If it is not planned for in the early stages of the project, it will cause delays and cost overruns in the project.

While many issues are related to personnel, it is important to remember that all three areas, budget, timelines and people, impact each other. As soon as one item is skewed, the others are impacted. With a well thought out project plan, and some precautionary measures, you can avoid or minimise these pitfalls and have a successful LIMS project!

Biography

Cindy Novak-DeLaurell has been working in the Biotech and Pharmaceutical industries for over 20 years. During her career, Cindy has participated in numerous LIMS implementation projects in roles ranging from subject matter expert to technical specialist. Cindy is currently supporting the global deployment of LIMS within Allergan.