Laboratory Information Management Systems (LIMS)
User Requirements: No Surprises is Key to Success
Mark Taras, PMP
Laboratory Information Management Systems (LIMS) are by nature complex to design and build. They can be successfully applied across almost every facet of lab work, or once built, unfortunately, turn out to be essentially worthless.
Which of these will be the outcome of your LIMS project is dependent on you and your team. There are many opportunities to go wrong in a LIMS implementation including:
- Users not knowing what they want
- Incorrect solution delivered
- Developers with little understanding lab operations
- Taking on too much
- Bad development
- Missed schedules
- Lack of teamwork
- Software vendor is sold or goes out of business
- Never being able to get some aspect of the system working properly
None of the above is likely unknown to those with LIMS development experience. Many of these problems have their roots in poorly formulated requirements. A LIMS team is usually comprised of members from diverse backgrounds and functions -- different groups, different sites, and even different companies.
To succeed, the team needs an experienced project manager; a leader who understands what LIMS technology can do, what the company and users needs are, as well as the limitations of his or her own team.
The project requirements specification or requirement document is the guiding light and roadmap for any LIMS project to meet its objectives. It should list out precisely what the system is to do. And it should be the most carefully read, scrutinized, and discussed document associated the effort. But sadly, requirements are often as much source of confusion as clarity.
Typically this document is written based on inputs from both users and the system business owner. But what the users want and what the final LIMS contains can be two very different things. Even when the developer closely follows a requirements document, the results can disappoint users.
Moreover, the further along developers get implementing incorrect functionality, the more difficult and costly it is to repair. The children’s game “telephone tag” -- where what the first person said is changed significantly by the time the last person hears it -- illustrates this. If it costs $1000 to go back one step, imagine having to go back ten steps through ten different people to get to the correct original message, and to have to do so more than once. The costs can add up quickly. But if the proper checks are in place along the way to ensure requirements are met, a lot of time and money will be saved and major frustrations avoided.
But how can this best be done? First, users, business owners and developers need to communicate frequently -- even at the risk of over-communicating -- during the analysis and formulation of project requirements. This is because in even the best requirements documents some amount of interpretation is inevitable.
So it is key that needed functionality be described in simple non-job specific jargon. This is because developers relying the document probably will not have the same knowledge as those with an in-depth familiarity of day-to-day lab operations. Developers are charged with creating something that fits the written requirements; in the absence of clarity, this can differ painfully from user expectations.
Developers, users, and business owners need to meet regularly to review progress and to discuss requirements. The more frequent these meetings are, generally, the less rework will have to be done. Clearly, the frequency will vary from project-to-project, as well as within a given project over time.
In the beginning, when the developers are just beginning their work, regular weekly meetings may be in order. But as they gain familiarity with the project, the frequency of these meetings can probably be reduced to as little as once every two or three weeks.
A very useful exercise, best suited for an early session, is to have the developers role play being users and in doing so tell the actual users how they, the developers, think the software should be implemented, how it should interact with other systems, etc. The more in-depth this goes, the better the outcome will be. The objective is to establish and verify that the developers have a complete understanding of the business processes that system will be used for, as well as verifying that the users fully understand what information services will actually be encompassed by it.
User and business owners also need to have a realistic sense of project scope. Left on their own, they will likely tend to want the LIMS to do everything it possibly can do. So again, early on it is imperative that limits are defined and agreed to with respect purpose and functionality. This will avoid front-loading the first system version with too many “nice to haves” and help motivate an on-schedule and on-budget program.
If the developers, users, and business owners do not communicate effectively with one another, the resulting system may lack fit to its intended purpose. It is absolutely critical that there are no surprises for anyone concerned, especially the end-users. Here, for example, having the system users create and begin to deliver their own training program prior to system completion can also be quite useful. And ultimately, it will allow the quickest and most efficient production rolled out possible.
Bottom line: The entire team, under the direction of the project manager, needs to stay relentlessly focused on good communication, clear project goals and a timely completion. To do otherwise means unnecessary risk. To do so from the start stacks the odds in favor of getting the best returns for your LIMS investment.