How to Create Solid User Requirements for a System Application
A laboratory informatics solution (e.g., LIMS, ELN, CDS) is only as strong as its foundation. The strongest foundation for a laboratory informatics solution implementation is a thorough user requirements document, generated to identify exactly what the system is intended to do. This requirements document, also known as a User Requirements Specification (URS), is used extensively throughout the selection, development, and implementation of the solution and in the end, is the yardstick used to measure its success.
Unfortunately, many times this document is not created with the attention to detail that its importance deserves. On numerous occasions CSols has been brought on to help get a project back on track after the client spent painstaking hours developing an incomplete URS, or worse, evaluated vendors without a URS, only to wind up unsatisfied with the outcome. Too often, requirements generation is looked at as a checkbox exercise where many in the business assume they will have plenty of time to correct any inconsistencies as the project evolves.
Compounding the problem of incomplete requirements documentation is that many project decisions are made based on the incomplete document before the realization dawns that the requirements were not detailed enough or suited to actual business needs. The result of such neglect can be time and cost overruns, a system that is inefficient, users who are unhappy, and the possibility of total project failure.
So, what can be done to position an organization for success with respect to creating solid user requirements for a LIMS, ELN, or CDS project? The following tips outline some sensible approaches to generating a solid user requirements document while also providing some additional benefits to your company’s culture.
Generate A Buzz
We all love recognition, right? Great contributions to a project are no exception. Make sure the importance of the project is communicated across the organization when the process of requirements gathering begins. Having this message come from management (the higher up the better) will go a long way in conveying its importance to the company. It is crucial that the project’s importance is communicated, with an emphasis on why it’s important. Explain how the solution will make people’s jobs easier, increase efficiency, and impact the bottom line.
The resulting buzz will help to attract high achievers in the organization who want to be involved. People will feel the project buzz and realize that contributing to the project’s success will not only help the company but also allow them to have input into the solution and possibly gain more visibility and recognition for themselves. This buy-in will help to ensure that requirements are drawn from a robust pool of end-users and stakeholders.
Create A Solid URS Team
OK, now that you have attracted some of the best and brightest, make sure the user requirements team is well structured. If your initial efforts have not attracted users from all impacted business units, ensure that you will get their input by adding team members from IT, the labs, quality control, the business, and any other affected areas. One common cause of incomplete requirements gathering is that certain affected areas were never given the opportunity to provide input. Whether due to oversight or the assumption that their needs have been understood, this can be a huge mistake. Without input from all impacted business units, your user requirements will not be complete.
When selecting representatives of each area for their input, make sure that they are subject matter experts (SMEs) in their areas who are empowered to either make or influence decisions for their department. Note that the most appropriate SME to fulfill the team’s needs is not usually a member of management, but a person who is close to the processes themselves. The best SMEs will be vocal advocates for their own needs as well as willing to listen and understand the needs of other areas and how all those needs fit together. The assignment of these strong SMEs to the team can require a short-term sacrifice of resources available for day-to-day operations but will pay off at the end of the process.
An added benefit across the organization is that through the work of this team, great communication channels and relationships are formed that can be used in the future. The team will provide much better insights into overall processes and cross-department impacts may be achieved through the discussions.
Additional Reading Resourcing Your Project Team for Success
Clarify The Intent For Your URS
We can all be too clever for our own good, and generating user requirements is no exception. Avoid creating requirements that are too difficult to understand or at an inappropriate level of detail (either too much or too little).
In a recent validation project for an electronic master batch record system completed for a life sciences company, the URS document was not specific enough because the client was unfamiliar with the validation process. Extra work was needed to identify what functionality to test. A good way to avoid this pitfall is to make sure everyone on the team clearly understands what the requirement document is, what purpose it serves, and the appropriate level of detail it should contain.
Conducting a quick training session on these topics will ensure that the team is on the same page and will go a long way toward easing any discomfort in team members who have never experienced a requirements generation exercise.
The Payoff For Generating A URS
Though it can be thought of as another boring document generation exercise, the generation of user requirements for a LIMS, ELN, or CDS can be so much more. Take advantage of the added benefits you can receive through this exercise, such as:
- Organizational team building and relationship generation
- Improved communication across the organization
- Improved understanding of overall processes and impact
- Empowerment and development of colleagues
Another benefit for creating solid user requirements is it’s use during the vendor selection process. It can be used as your guide, allowing a level playing field on which stakeholders can evaluate vendors, which is a key part of ensuring you have chosen the best LIMS for your laboratory. Postimplementation, it provides an objective measure of how successful the LIMS implementation has been. If the user requirements were met, user adoption should be high.
The development of user requirements may be the most important task in determining the success of an informatics project. If you provide the proper resource, time, excitement, and priority to generate these requirements, the payoff will be well worth it.
What do you see as the main obstacles in an organization to generating solid user requirements for an informatics system?
