The process of implementing a laboratory informatics system is complex. It operates across many spectrums: digital, human, machine, market, strategic and more. As a member – or leader! – of such a complex implementation, it’s important you have a solid grounding in some fundamentals.
In this post, we’ll be discussing how to prepare for a LIMS implementation from the perspective of a project planner. It’s important to keep in mind that the contribution of every team member is integral the project’s success.
We’re going to break down a successful project implementation into the following four categories or quadrants:
· People
· Process
· Infrastructure
· Data.
While additional categories aren’t hard to find, we find these four provide a solid project readiness foundation.
How many times have you heard: “This system would run perfectly if it weren’t for these users logging in”?
Maybe that’s true on a philosophical level, but it does sort of defeat the purpose, right?
Understanding the behavior and expectations of the people related to your new laboratory system might just be the most difficult of the four quadrants to fully get a handle on. Because of this, it’s worth spending some time documenting these diverse behaviors and expectations before starting a new project. Based on that need, we’re going to subdivide the People category into three groups: stakeholders, governance, and training.
Stakeholders
Believe it or not, identifying the stakeholders is one of the most overlooked aspects when starting a project. The term stakeholder is rather broad. The PMI Lexicon of Project Management Terms defines a stakeholder as:
“an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.”
Strictly speaking, that would make a competitor a stakeholder in the status of your success – namely because they want you to fail! So let’s use a simpler definition which includes only those people in – or closely partnered with – your organization (those who want your project to succeed).
TO-DO ▼
· Identify stakeholders by type. For example: sponsor, business area lead, subject matter expert (SME), project manager, IT team member, end user, etc.
· Make a written note next to each stakeholder that concisely identifies specific concerns, needs, and wants. This is where knowing the stakeholder type is useful. For example, a project sponsor will certainly be interested in managing to budget, but may also need to meet a specific timeline (e.g., status reports need to be provided to the organization’s board of directors).
Governance
True, governance isn’t a person. Think of it as guiding people’s behavior – either when they operate within the project or lab, or when they configure the system for operation.
TO-DO ▼
· List all the governances to which your project may need to be accountable.
· Organize these by type. For example, standard operating procedure (SOP), corporate standard, regulation (law), certification, best practice, expectation, requirements for drug screening, background checks, etc.
· When listing out all possible governances, note the type, its specific name (if it has one), and how it will affect the project. For example, we all know that among other things, 21CFR11 and Annex 11 will govern how electronic records are captured and stored in a LIMS, ELN, LES, etc.
You’re going to want to refer to this last task when it comes time to write requirements and draft testing documents. Knowing governance types may also help guide your requirements document to the appropriate staff knowledgeable in particular area for a review of the content.
Training
The training list almost certainly refers to a few of the groups listed in the stakeholders list completed above.
TO-DO ▼
· Categorize training by type; for example, end-user, train-the-trainer, help files, computer-based training, etc.
· When documenting training needs, list the training type, the primary audience, any secondary audiences, and pertinent comments. You may find that certain types of personnel to be trained may be highly self-directed, which would make them a candidate for computer-based training, whereas another type needs hands-on training, which might require a classroom-style learning environment.
· This list will help you identify and plan for the kinds of training that need to be scheduled to ensure a successful implementation. It will allow your organization to match the type of training with the needs, wants, knowledge, and previous experience of the group.
There are four subtopics to be considered within the Process category:
- scope awareness
- business process
- business requirements
- quality requirements.
Scope Awareness
Before starting a project, you need to have a clear understanding of several documents. And – it should be emphasized – communicating the scope of the project to all stakeholders will be key to reducing scope creep and frustration later in the project.
First is the Project Charter, which the PMI Lexicon defines as:
“a document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.”
Included within the Project Charter should be a Project Scope Statement, which identifies the project scope, major deliverables, assumptions, and constraints. Hopefully it is detailed enough; if it is not, make sure to add a detailed scope statement somewhere else within the project documentation and communicate it to all stakeholders.
Second is the Statement of Work (SOW). When working with a LIMS vendor to implement a system, the SOW extends the Project Charter by identifying which activities or deliverables are within scope for the service provider.
In other words, by comparing the Project Charter’s Scope Statement and the SOW, everyone should know who is responsible for which parts of the project.
Business Process
Not to jump ahead, but it is nearly impossible to write user requirements against complex processes when stakeholders come from various parts of an organization that might not communicate frequently.
For example, it might be easy to indicate that a LIMS must support data download from an HPLC, but without knowing all the technical and procedural variations, fulfilling these requirements might turn out to be much harder than expected.
TO-DO ▼
· Start clarifying these business processes by asking stakeholders to diagram the processes of the intended LIMS system. If you have not yet settled on a diagramming standard, you might want to consider using BPMN. It’s easy to understand and commonly used.
· The benefit of diagramming processes is that it allows people to think through exception states and forces different parts of the organization to identify challenges that might be solved in the new system.
Business Requirements
Documenting business requirements typically comes in the form of a User Requirement Specification (URS). This documents how the LIMS is required to function in order to meet the objective of the Project Charter.
When reading a good URS, it is sometimes helpful to start reading like a toddler – look for the pictures! – which is why the previous exercise was so important.
While a BPMN diagram may not contain the detail necessary to implement a LIMS system, it is typically a first good step to clearly communicate business intentions to resources at a variety of levels, including: business analysts, developers, end users, testers, quality representatives, etc.
TO-DO ▼
· A complete URS should also include inputs from all other topics within this post. It must cover the full scope of the project, include quality requirements, reflect governances such as regulations, infrastructure concerns and more.
Quality Requirements
Requirements for quality come from a variety of sources. For example, a corporate standard (see the Governance topic above) might require that installations qualification (IQ) are performed according to good documentation practice within a pharmaceutical space.
TO-DO ▼
· Look for existing document templates that may already exist within your organization; for example, maybe internal stakeholders are used to receiving status updates in a certain format.
· Change control documentation will almost certainly be required. This will include both changes to the future operational system, but also document templates to control changes to the project and its scope.
· Finally, look for pre- and post-document approvals. It’s really frustrating to discover that an IQ should have been pre-approved by a Quality department before being executed…and it can cause a significant project delay if installations must be re-executed!
As we all know, data is the heart of the new laboratory informatics system. Therefore, understanding the texture of this data is extremely important. There are several subtopics when considering data:
- master data
- harmonization
- internationalization
- historic data.
Master Data
Every test executed in the laboratory starts with a pre-defined test definition, which we’ll call master data.
Certainly, your organization will already have master data defined either within paper SOPs or in a legacy system – both of which will need to be translated into the record format of your new LIMS.
Creating master data is as much art as it is science. It requires an understanding of how the new LIMS defines products, conducts sample submission, instantiates tests, evaluates specifications, uses instruments, storage, custody, and much more.
TO-DO ▼
· Modern LIMS systems typically have many ways to express master data, so it’s important to spend some time not only training on the new LIMS system, but speaking to a professional services expert who can recommend best practices.
· The most important activity you can conduct prior to starting a project is to collect and analyze all master data. Having this data in a single location for analysis will not only save you time later but will allow you to complete some analysis activities later within this topic.
Harmonization
Although a LIMS is not a data warehouse, you can learn a lot from warehousing techniques.
TO-DO ▼
· Important harmonization tasks will be to review your current data for consistency, identifying data that must be de-duplicated, extracting common formats, identifying the maximum length of data items and data types.
· Each of these activities will bring a constraint to your new LIMS system. For example, knowing that M, boy, and Dude all represent a single value, “Male”, will be important when reporting data in the future.
· A tricky area is specifications. For example, a measured value may be expected to return around 110mg, which would indicate a numeric specification scale >=0. However, what happens when an instrument’s detection range is only accurate >0.05? In this case, you may need to enter a textual value indicating simply that the returned value is out of detection range, which changes the nature and complexity of the specification you’ll need to create in the LIMS.
Internationalization
If you only have labs that operate and report within a single country with no plans to change that then your work here is done! But if you are a global organization, you’ll need to add the following to the project plan:
TO-DO ▼
· If you need to collect or serve data to multiple regions, potentially in multiple languages, then time zone, language, and currency need to be addressed in your new LIMS system.
· It’s important to identify these requirements before the project begins, and even provide your LIMS implementation teams with master and instance data that has a mix of ranges and values.
· If you expect to report values in both English and Chinese, start with datasets that contain both, since both on-screen values and reports will need to display both single- and multi-byte characters correctly.
· For time zones, you’ll need to decide whether the new LIMS should present all dates using only GMT, or if they should reflect the local time of the user. And what about scheduled events? Which time zone should they honor?
Historic Data
Whether your organization has a legacy LIMS or uses paper, the mapping of historic values to the new LIMS will be both important and potentially time-consuming.
TO-DO ▼
· This activity considers much of the analysis work executed above, which requires an understanding of historic and future master data configuration, the lengths and types of data, and potentially the need to transform data into harmonized values.
· Frequently, the import of historic data into the new LIMS is itself can be a rather large sub-project and understanding the scope of this task prior to starting the implementation will be important.
Finally, it is important to develop a thorough understanding of the infrastructure requirements for the new LIMS.
Procurement
It should go without saying, but it is important to understand the procurement requirements of your organization before starting any project.
We’ve seen several projects start using a database by one vendor, only to find out that the procurement department won’t support its purchase due to the existence of a blanket license from another vendor.
Such issues can cause lengthy project delays! Not only do all development systems need to be re-installed for the new database, but sometimes individual queries or reports using database-specific syntax need to be refactored for the new database (or more preferably, into general SQL syntax).
Hardware & Software
The hardware and software requirements of your new LIMS system should be clearly documented by your vendor. Once you understand the procurement process, requesting these should be (hopefully!) simple.
TO-DO ▼
· Consider all of your integration points. For some organizations, identifying the number, type, and locations of barcode scanners and printers can be a rather large task in itself!
· Consider the governance of your organization’s technology, and which web browser or operating system will be supported.
· Don’t forget the non-LIMS software! Many organizations require additional instrument software like Chromeleon or Open Lab, special barcode software, etc.
Load Balancing and Disaster Recovery
Having a load balanced, redundant, disaster-ready infrastructure can add a lot of cost to your system but the need should be identified very early in the project.
TO-DO ▼
· Don’t take for granted that every vendor will consider load balancing and disaster recovery in their out-of-the-box design. Be certain to ask the right questions: Does your software support application clustering? Can I mirror a database server in case of a disaster?
· If you are uncertain of whether your organization requires a highly available LIMS, check out this post on the total cost of ownership for Cloud Hosting versus On-Prem systems. The post has some basic calculations on availability requirements that might be helpful when considering acceptable downtime.
· Finally, be certain to work with your local IT department to identify the necessary backup schedule, and to test a full disaster scenario. Unfortunately, we see laboratories encounter unexpected failures (e.g., corrupted virtual servers) only to discover the regularly scheduled backup was unusable.
Some Final Words on LIMS Implementation
LabVantage understands the nature and complexity of lab informatics projects. We know that past challenges can be turned into future best practices. And while agile, creative problem solving sometimes saves the day, it is absolutely not a replacement for thorough planning rooted in industry standard behaviors, patterns, and practices.
Do you have an upcoming LabVantage LIMS project? Contact us today to review the LabVantage Project Readiness Plan. We’d be happy to discuss these items in more detail with your team to help make your project the kind of success all your stakeholders expect!
