User:Shawndouglas/sandbox/sublevel8

1. Introduction to LIMS and LIMS acquisition

1.2 What are the alternatives to a LIMS?

Introducing new technologies and products often causes people to balk because it represents a change to current operations and an expense, even if the change is beneficial. As such, some may view the acquisition, use, and maintenance of a LIMS to be too daunting. The organization may even see the value in a LIMS but finds several questions arise:

• What happens if we don’t make the change to a LIMS?
• Is there an alternative technology that is less costly?

The answer to the first question is straightforward: lab costs continue to increase, operations stagnate, sample backlogs increase, and lab personnel—including management—become increasingly frustrated. This in turn means the lab may fail to achieve its goals. That second question is politically charged, however, particularly in medium to larger organizations. There are two frequently encountered answers, both involving internal software development: let's use a spreadsheet, or let's use an enterprise resource planning (ERP) system as a solution with similar characteristics to a LIMS. The latter often occurs if a company has recently invested in an ERP solution with the idea that it will take care of all of the company’s needs (i.e., they may not have checked with the labs to see if actually will).

Before we get into a response to that second question, I'd like to ask you one. What business is your company in? Is it a software development organization, or does it want to become one? I ask this because what often happens is someone in the organization proposes custom software development as an alternative. Suppose you are seriously considering developing a LIMS alternative in-house or through a consulting firm. In that case, that is something you have to think through, taking on all the issues that plague large software development projects, including ongoing maintenance and support once the project is completed.

Software development projects are fraught with issues. Examples of reasons for software project failure include:

• insufficient organizational leadership
• inadequate planning and project management
• inaccurate time and cost projections
• inadequate use of available resources
• insufficient understanding of changing software development practices
• poor or mismanaged communication methods
• poor response to project challenges that inevitably arise
• scope creep

• “14 Common Reasons Software Projects Fail (And How To Avoid Them)”, see https://www.forbes.com/sites/forbestechcouncil/2020/03/31/14-common-reasons-software-projects-fail-and-how-to-avoid-them/amp/ • “23 Reasons Why Software Project Fail (with Solutions)”, see https://www.netsolutions.com/insights/23-reasons-why-software-projects-fail-with-solutions/ • “5 reasons why software projects fail and how to make them succeed”, see https://dac.digital/why-software-projects-fail-and-how-to-make-them-succeed/

The bottom line is this: software projects develop issues, and while they may eventually succeed, while they are in development which may take a year or more, your lab is suffering under whatever issues caused you to look for a LIMS in the first place. When you're done with the development, will you have something better than commercial products or just the best you can settle for? Commercial products will be continually improved with new features and capabilities added. That's their business, is it yours?

Different software development approaches will have other issues to address. ERP-based systems will have problems with instrument connections, a significant source of productivity gains. Spreadsheet-based systems 8 while seemingly inexpensive, are costly in development time and use. Spreadsheets are single-user-at-a-time systems. Everyone else has to wait their turn if someone is working with the system. They are fraught with errors creeping in, changes that may not be documented. They are difficult to validate and keep under modification control. Those factors are red flags to regulatory inspectors, particularly regarding development documentation. Is this the most cost-effective way to manage risk and utilize your resources?

Citation information for this chapter

Chapter: 1. Introduction to LIMS and LIMS acquisition

Title: Justifying LIMS Acquisition within Your Organization

Edition: First Edition

Author for citation: Joe Liscouski, Shawn E. Douglas

License for content: Creative Commons Attribution-ShareAlike 4.0 International

Publication date: