View source for Justifying LIMS Acquisition and Deployment within Your Organization/Introduction to LIMS and its acquisition and deployment/What are the alternatives to a LIMS?

===1.2 What are the alternatives to a LIMS?===
Introducing new technologies and products often causes people to balk because they represent a change to current operations and an expense, even if the change is beneficial. As such, some may view the acquisition, deployment, use, and maintenance of a LIMS to be too daunting. The organization may even see the value in a LIMS yet ask several questions in regards to its necessity:

*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 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, with similar characteristics to a LIMS, as a solution. 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 its labs to see if actually will). 

Before we get into a response to that second question, here's a question for you. What business is your company in? Is it a software development organization, or does it want to become one? This is an important question because someone in the organization inevitably 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. Reasons for software project failure include<ref name="DACD5Reasons22">{{cite web |url=https://dac.digital/why-software-projects-fail-and-how-to-make-them-succeed/ |title=5 reasons why software projects fail and how to make them succeed |work=DAC.digital Blog |publisher=DAC.digital |date=19 April 2022 |accessdate=19 July 2023}}</ref><ref name="Singh23Reas22">{{cite web |url=https://www.netsolutions.com/insights/23-reasons-why-software-projects-fail-with-solutions/ |title=23 Reasons Why Software Projects Fail (with Solutions) |author=Singh, S. |work=Net Solutions Insights |publisher=Net Solutions |date=15 June 2022 |accessdate=19 July 2023}}</ref><ref name="Forbes14Comm20">{{cite web |url=https://www.forbes.com/sites/forbestechcouncil/2020/03/31/14-common-reasons-software-projects-fail-and-how-to-avoid-them/amp/ |title=14 Common Reasons Software Projects Fail (And How To Avoid Them) |author=Forbes Technology Council |publisher=Forbes |date=31 March 2020 |accessdate=19 July 2023}}</ref>:

*insufficient organizational leadership;
*insufficient understanding of business and department problems and requirements, even as they evolve during development;
*inadequate planning and project management;
*undefined project roles and responsibilities;
*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;
*lack of focus on project success;
*lack of focus on soft skills such as training and team building; and
*scope creep.

The bottom line is this: software projects develop issues, and while they may eventually succeed, they may take a year or more to work through during development. Meanwhile, your lab is suffering under whatever issues caused you to look for a LIMS in the first place. When you're done with developing the solution, 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. Do you have the resources and commitment to make it yours?

We find that software development approaches have their own issues to address, but what about spreadsheets and ERP systems? Spreadsheet-based systems, while seemingly inexpensive, are costly in development time and use. Additionally, 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, especially through changes that may not be documented. They are also difficult to validate and keep under modification control. Those factors are red flags to regulatory inspectors, particularly regarding development documentation.<ref name="LiscouskiImproving23">{{cite web |url=https://www.lablynx.com/library/articles/improving-lab-systems-from-paper-to-spreadsheets-to-lims/ |title=Improving Lab Systems: From Paper to Spreadsheets to LIMS |author=Liscouski, J. |publisher=LabLynx, Inc |date=April 2023 |accessdate=19 July 2023}}</ref> As for ERPs, those systems may address some of the requirements of your lab, but they will have significant problems with instrument connections, a significant source of productivity gains in the laboratory. Do these and similar alternatives represent the most cost-effective way to manage risk and utilize your resources towards the goal of improving laboratory productivity and compliance? The purpose-built LIMS may make more sense given the challenges posed by forcibly shoehorning these alternatives into a role they weren't necessarily designed for.