A laboratory informatics solution (e.g. LIMS, ELN, CDS) is only as strong as the weakest part of its foundation. The foundation for an implementation of a laboratory informatics solution is the user requirements document, generated to identify exactly what the system is intended to do. The 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 thoroughness and attention to detail that its importance deserves. 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, it is often the case that many project decisions are made based on the document contents before the realization occurs that the requirements were not detailed enough or suited to actual business needs. The result of such neglect can be time and cost overrun, 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 system application project? The following tips outline some sensible approaches to generating a solid requirements document while also obtaining some additional benefits to your company’s culture.
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. Having this message come from management (the higher the better) will go a long way in conveying its importance to the company. It is crucial that the project’s importance is communicated, but emphasis should be placed upon why it’s important. Explain how the solution can make people’s lives 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!
OK, now that you have attracted some of the best and brightest, make sure the user requirements team is well structured. It is essential that the user requirements include input from all areas that will be impacted by the informatics solution. Often, certain areas that are impacted were never given the opportunity to provide input to a solution. Whether due to oversite or the assumption that others already understood their needs, this can be a huge mistake! It is essential that all areas have input into the generation of the user requirements.
When selecting representatives of each area for their input, it is imperative that they are subject matter experts (SME’s) for their areas and are empowered to either make or obtain decisions for their department. Note that the best SME’s to fulfill the team needs is not usually a member of management, but a person who is close to the processes themselves. The best SME’s are willing to be vocal as well as listen and understand other area needs and how it all fits together. The assignment of these strong SME’s to the team can be a short term sacrifice to resources available for day to day operations, but will pay off handsomely in the end.
An added benefit across the organization is that through this team, great communication channels and relationships are formed that can be utilized for the future! In addition, a much better insight into overall processes (as well cross-department impact) may be realized through these team discussions.
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). 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 at the same understanding and will go a long way in easing any discomfort in members who have never experienced a requirements generation exercise.
Though it can be thought of as another “boring” document generation exercise, the generation of user requirements for an informatics solution can be so much more! Take advantage of the added benefits you can receive through this exercise, such as:
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 generating these requirements, the payoff will be well worth it. The alternative could be devastating!
What do you see as the main obstacles in an organization to generating solid user requirements for an informatics system?