APRIL FOOLS DAY…The day we, who don’t like surprises, all dread.
A father ruins a little girl’s dreams of sleeping in by running to the window bright and early on April 1st and yelling “It’s snowing, it’s snowing, no school today!”, only for the little girl to run over to that same window and realize it’s 70 degrees and sunny outside…time to go to school.
However, there are those who like “gotchas” and LIMS projects provide no shortage of those. Below are just a few things to keep in mind when working on your LIMS project so you don’t get “fooled”:
LIMS Implementation Gotchas
April Fools: “Sure, our LIMS supports that capability. Did I mention that it’s an extra cost option?”
- A user requirement to integrate instruments is discovered when developing the functional requirements of the system. Oops, this functionality requires the vendor’s integration package to be purchased.
- “We didn’t account for that in the budget! What do we do now?”
- Do you want to perform CAPA investigations? You’ll need to purchase a module for that.
- “We didn’t account for that in the budget either! What should we have done?”
Not understanding your Total Costs can lead to budgetary problems when selecting and implementing a LIMS. It is imperative to determine your total cost of ownership so you don’t get “fooled” when extra cost items crop up.
- Do your research. Make sure you know what the total cost of implementing a new LIMS or new functionality is before requesting your budget.
- Hardware Costs
- Servers, printers, barcode readers, RFID scanners, etc.
- Software Costs
- LIMS licenses, Add-on modules, vendor packages, database licenses, etc.
- Personnel Costs
- LIMS team members (backfill for their time)
- Outside SMEs
- Vendor resources
- Make sure you have a “cushion” in your LIMS budget to cover unknown, surprise costs that may arise once the project has started.
- Be ready to “trade off” or delay the implementation of one functionality for another to stay within your budget. Decisions should be based on priorities and the criticality of the capability needed to support the business need.
- Hardware Costs
LIMS Validation Gotchas
April Fools: “My project is delayed because the validation testing isn’t complete.”
- A project manager realizes his LIMS project is delayed because the validation work won’t be completed in time. What happened to cause this?
- User requirements were not concise and/or accurate so the functionality developed does not satisfy/meet the requirements. Either the code or the requirements need to be adjusted to assure the solution operates as expected.
- Development of the functionality was not finalized when the test scripts were written, the code was changed, now edits need to be made before running the scripts.
Validation is one of the last steps in a LIMS project, leaving little time for rework. So, if you don’t want to be “fooled” during testing you should:
- Always conduct a thorough interview with your users to determine exactly what requirements a particular functionality will need to encompass.
- The developers should be a part of this process as well so they understand exactly what the system needs to do!
- Implement a “code freeze” prior to writing the test scripts for the functionality so last-minute changes don’t get left out of the testing and re-writes of the test scripts won’t be needed thereby not causing a delay in the project.
LIMS Usage Gotchas
April Fools: “I thought implementing a LIMS would make my technicians and analyst more efficient right out of the box.”
- A lab analyst is surprised when they realize that documenting results in a LIMS and documenting those results in paper lab notebooks or on paper forms are not that different, from an effort perspective. So, what is the gain for automating the lab with a LIMS?
- Interfacing Instruments
- Interfacing Systems
- Automated Calculations and Reports
- Review/Approve by Exception
- Automating Training Records
- Instrument Calibration and Maintenance
- Standards & Reagents Management
- Freezer Management
Misconceptions about what a LIMS is supposed to do can result in negative feedback at the end of a project. So, if you don’t want the end users to be “fooled” you should:
- Involve your end users in the development and prioritization of the needs and requirements. In this way, areas where efficiency gains for the scientists can be attained will be identified, designed, and implemented into the solution, in a timely fashion.
- Be transparent with the end users throughout the LIMS selection and implementation processes so they know what to expect from the LIMS, how it will benefit them, and the changes in their normal, everyday work processes that the new LIMS will drive. Assumptions are the fuel for an April Fools Prankster!
Running into a “gotcha” during your LIMS project may feel like someone pulled a prank on you but these should always be viewed as learning experiences. Just like the little girl who thought it was snowing in April, sometimes we get “fooled”….that’s when we get taken to school!
What LIMS gotcha’s have you encountered in your project? Let us know, below in the comments.