On just about every Laboratory Information Management System (LIMS) or Electronic Laboratory Notebook (ELN) implementation project we have assisted a customer with, this question arises. The answer is very telling as to how the entire implementation will play out. There have been numerous occasions where CSols was brought onto a project late in the game after the client spent painstaking hours developing an incomplete URS or evaluating vendors without a URS, only to wind up displeased with the outcome. We have found that most clients acknowledge that it is best to develop the User Requirements Specifications (URS) prior to selecting software, but many do not have the time or expertise to do this. Instead, they select software and later throw together requirements to reflect the chosen solution.
An argument can be made for both sides of this debate.
By developing the URS before selecting software, you and the key stakeholders can be assured that the application really meets all of your needs. On occasions where no application meets 100% of the requirements, it helps to have prioritized requirements so a quantifiable score can still be derived.
This method also allows a level playing field for stakeholders to evaluate vendors. It takes away the human tendency to apply bias to selections based on various reasons (aesthetics, flashy features, etc.). Anything that is not in the URS does not get a score in this method. This extends to the RFP and overall vendor selection process. In this way you ensure that you are comparing apples to apples each step of the way.
By selecting an application that meets your needs, there will likely be less downstream changes to your processes and workflows. For example, if you organize entities in your current workflow by “Project” and the chosen application cannot comply with that logic you may need to switch to “Batch.” This could have been avoided with a requirement in your URS for “Project” naming conventions and organization.
This process also reduces cost for several reasons. First, it reduces the need for unnecessary “bells and whistles” from applications that are outside of intended scope and requirements. Additionally, it reduces rework costs by doing it right the first time. Lastly, during the process many organizations take the opportunity to streamline their processes thereby increasing efficiency and saving operating costs.
There are some strong arguments made for allowing the software selection process to guide the URS creation. The most compelling is that you may not know what you want until you see the options. Although there may be merit to this concept, it is not the only way of educating yourself on product offerings. It is always a good practice to familiarize yourself with the functionality of the systems that address your solution space. Another good way to gain knowledge is to leverage subject matter experts to help educate you on your options.
Another reason we have heard for not creating the URS first is that the URS template can be provided by the software vendor once the application is selected. While this may be true, the URS is of little value (outside of validation concerns) once an application has been selected. The URS that would be provided by the vendor would likely just list everything that their system is capable of. It does not take into account what your organization values, requires, or needs. Therefore, there are countless requirements that are unnecessarily included. A generic URS will not rank your priorities and will not paint the full picture as to why you need all those bells and whistles for your procurement group [Tweet This].
Some organizations want to save upfront time and just dive into the selection process. Although that seems straightforward at first, time is generally spent later on with either a project restart of correctly going through the steps or by recreating the URS and other needs assessment processes at a later time.
Having conducted many strategic planning and selection projects at CSols, we have come across both scenarios and found that developing the URS before selecting the LIMS yields a higher rate of successful implementations.
During strategic engagements, we work with the key stakeholders to determine what their needs and requirements are and help generate a priority for each. From there, we are able to assist the client in making a list of the “top contenders” – generally about 4 or 5 application vendors. We find that making the process as systematic and quantitative as possible leads to the best long-term success in a deployment. The next step in our process is to release the RFP to the selected vendors and allow them to weigh in on each of the requirements. By the time the vendor is selected, the client and CSols can feel confident that the choice was made for the right reasons. They can refer back to notes on how each vendor scored on every requirement. It also prevents the rework of noticing a nice-to-have feature late in the process from one vendor and wanting to reach back out to the previous vendors to see how they rate on that topic.
As a vendor-neutral consultancy, we are able to help at each step in the process and use our industry experience to ensure our clients are satisfied and end up with the best software solution for them.
Which approach have you seen taken on your informatics solution selection initiatives? Tell us in the comments below!