The first step of any successful laboratory automation project begins with clearly and succinctly defining the technical requirements of the data management system along
 |
with the laboratory manager, end-user, information technology (IT) personnel and all other stakeholder needs requirements. For many projects, this involves the creation of a team that will work to create flow diagrams that capture the business processes and rules of the organization, as well as interview and survey key stakeholders to gain a clear understanding of the automation and data management challenges. Once this process is completed, project managers must assign a priority to the various requirements that the new laboratory automaton solution must address. A second and equally important step is to effectively communicate those requirements, project scope and cost range to the vendor partners.
Introduction
There are several elements that must be clearly defined for any laboratory information management system (LIMS) or laboratory automation project to be successful and to allow effective project management; they include scope (S), which deals with the magnitude or size of the project (system requirements) and is what we will focus on in this presentation, realizing that we must also consider, performance (P), cost (C) and time (T) in relationship to scope. Performance refers to the quality of the work performed, Cost includes the labor costs, software product costs, hardware (servers, firewall, PCs) and all related project costs and time refers to the length of the project typically expressed in days, months or years to completion. Figure 1 depicts the relationship between the key elements of any project. It is clear to see that, if there is an increase in scope, this will cause an increase in the time and cost to completion for the same level of performance. If the cost is the limiting project factor, then the scope may have to be scaled back or quality may be impacted.
Effectively defining LIMS system requirements
Since system size is a measure of the magnitude of all components of a system that are within the current scope, the system scope should be documented in the project plan before the system size is estimated. The scope statement defines what the project will and will not include in enough detail to clearly communicate to all participants.
In order to capture the laboratory automation and data management requirements in the implementation of a LIMS, it is important to have a team and a plan of attack that includes the process maps of the main functions that the laboratory is trying to automate.
For LIMS projects, this involves the creation of a cross-section of a multi-disciplinary laboratory management team that consists of laboratory management (quality system engineers, project champion, and a regulatory expert), IT and key end-users. This team will work to create flow diagrams that capture the business processes, as well as define the requirements and rules of the organization.
The scope must be a complete definition encompassing all types of requirements:
• The external business requirements are generally the most obvious requirements and those for which the definition of scope is the easiest.
• The system design may imply requirements that are not specified. For example, the design of a client/server system may have the need for a fire wall between data moving in and out of the environment.
• Other components are often implied but not clearly defined, such as performance, instrument interfaces, PDAs, operations and implementation. These components should be included if they are within the scope of the system being sized. If there is any question regarding whether something is included, it should be assumed to be within the scope of the sizing until the system scope specifically excludes it.
Analytical testing laboratories often share many core requirements for LIMS, which include sample tracking functionality, data entry, electronic data entry, sample scheduling, stability, quality analysis/quality control (QA/QC), time tracking, chemical inventory, personnel and equipment management and maintenance. In addition to these core features, laboratories often seek the ability to integrate with enterprise applications, such as SAP, enterprise resource planning (ERP), or other similar packages. Business managers may require specific reports or integration with other enterprise solutions or accounting packages.
To enhance productivity and data accuracy, laboratories often require instrument integration from their LIMS and data management tools that will meet regulatory requirements unique to a specific industry.
Specifications
Bringing together key participants that represent a multi-disciplinary team in a structured environment under the direction of a trained facilitator can solidify the problem definition and lead to the production of a problem specification which will serve as the foundation on which to build the requirements document or request for proposal. When a multifunctional team is assembled, it can analyze its business processes, identify bottlenecks and communicate its wants or desires from the system and the business advantage that the proposed solution is to deliver.
To start with, the team should approach end-user requirements gathering by following the traditional system development life cycle route with interviews, extensive research, process analysis and other tasks appropriate to a structured analysis. This can be done internally, or an outside consultant or even the LIMS vendor partner can conduct this assessment. There are advantages to having an outside firm perform the needs assessment as they can be objective and have extensive experience and can offer suggestions and share solutions that were successful in similar projects. One advantage of utilizing outside vendor partners is that you will have the opportunity to evaluate their expertise and they will have the advantage of seeing some of the challenges laboratories are facing firsthand prior to making any recommendations for or implementing any new laboratory automation technology.
If the decision is made to complete the needs assessment internally, below are some suggested steps to completing the task. It does not require a significant technical knowledge to develop functional requirements. It is also important to note that not all advantages are limited to a reduction in operating costs, some deal with
 click to enlarge Figure 2: An example of requirements from a request for proposal |
improvements in quality and improved client satisfaction. A key task is to assign a group to identify and obtain any documents that describe the customer needs; this could consist of any formal studies that were conducted, a statement of work (SOW) or a request for proposal (RFP). These documents will provide good overviews but, to get the specifics, it is important to conduct interviews. Before interviews can begin, key people must be identified and a cross section of members from different departments that are represented in the multidisciplinary team should be interviewed. It is important to identify the right people to interview; one dissatisfied person can do a significant amount of damage and can sabotage the project. There are some suggested interviewing tips that include the following:
• Let the interviewee know that you are there to help solve a problem and that their input is critical to finding a solution.
• Ensure the interviewee that automation will not replace them, it will only eliminate mundane tasks so that they can be available to work on more challenging tasks.
• Share the information that has been collected from interviews with the rest of the team. This information sharing creates trust and partnerships that will lead to obtaining more information.
• Following the interview, summarize the interviewee’s answers and read them back to them for accuracy.
• Be prepared for the interview and create a script that asks the same questions of a number of interviewees. This can lead to a statistical sampling and useful data.
• Don’t assume anything. If an interviewee says that this technology will save their departments a hundred hours, ask others in the department to confirm this estimate.
There are two kinds of performance requirements, which together define specifications (system requirements); these include the functional and technical requirements. According to Wikipedia, a requirement is defined as a singular documented need of what a particular product or service should be or do.
• Functional requirements: These describe what the deliverable is supposed to do. For example, the LIMS must automatically e-mail status reports and post a copy to the LIMS intranet site.
• Technical requirements: These describe the features of the deliverable. For example, the e-mail reports must be in read-only PDF format.
Rating requirements
Once this process is completed and the team has summarized all of the functional and technical requirements, project managers must assign a priority to the various requirements that the new laboratory automaton solution must address. Many teams break the requirements down into three “pots”:
• Need: very important
• Want: less important (business case may not be able to immediately justify the purchase based on return on investment (ROI) calculations, but may be desirable at a later stage).
• Nice-to-have: not critical to addressing any current business issue (it would not add immediate value, but perhaps as a need arises in the laboratory this option would be desirable).
Once all of the requirements have been grouped, I suggest that the project focus only include needs requirements. Wants and nice-to-haves should be put aside until the ROI calculations justify their purchase.
A second and equally important step is to effectively communicate these requirements, the project scope, performance, time frame and cost range to the potential vendor partners and to understand each vendor’s current product status in meeting those requirements. This is often done via a very lengthy Excel spreadsheet that documents each requirement and asks each vendor to respond item by item to determine if the software meets the specified requirements. In many cases, the clients will request that the vendors state if the functionality is available out-of-the-box or with modifications, if the requirement cannot be met, or if the requirement can be met with a future upgrade.
A good set of requirements is critical for any project to be successful, especially LIMS and laboratory automation projects. This is where many projects fail, in that they do not specify correctly what the system should do or what is the target. In fact, many systems have just been given a deadline for delivery, a budget to spend and a vague notion of what they should do. The typical result is that a significant amount of resources are squandered and the laboratory may have limited useful functionality (such as sample tracking) but will have considerably missed the mark to completely address their data management and laboratory automation requirements.
Conclusions
LIMS and laboratory automation requirements should be defined in the beginning of a project by a multi-disciplinary team. The old adage that ‘if you fail to plan, you plan to fail’ holds true in LIMS projects as in any other project. A well-defined scope is critical for any project to be successful. By gathering the input of many end-users and key team members, the RFP should be representative of the real needs of the laboratory. Once all of the data has been assembled and organized, it is important to determine the impact of each item on a laboratory’s business in terms of time savings, cost savings, and enhancing data quality and customer satisfaction. Total project costs can be captured with an Excel spreadsheet and an ROI calculator can be integrated into the spreadsheet so that the team can see how long it will take for the new LIMS, automation technology and hardware to pay for itself.
There are also numerous tools available, such as Microsoft Project, in which team members can allocate resources, define tasks and task times to manage the project, as well as make sure that milestones are achieved and that there are common project expectations.
The team should review system requirements, rank those that are needs, and eliminate the wants and the nice-to-haves. These can be added at a later date. A correct definition of system requirements is one of the most effective ways of meeting user needs and reducing the costs of post-implementation adjustments.
Christine Paszko is VP of Sales and Marketing at Accelerated Technology Laboratories. She may be reached at [email protected]
