Lab Automation

http://www.labautopedia.com/mw/inde
x.php/Project_Management
Planning and Managing the Project
 Project Management
• Laboratory automation is about integrating
processes, systems, technology and people to
achieve improvements in laboratory operations,
capability, quality and productivity - at the
bench, laboratory and enterprise level
• It is an endeavor that must be carefully planned
and researched to provide the maximum benefit
• Project management, therefore, has become a
key part of practicing lab automation
 Got the right project?
• Economic justification…..done
• Strategic justification…. potential impact on
intangible factors such as safety, skill retention,
capabilities and quality – qualitative factors..done..
• Impact of project on the workflow of your lab and
your organization? – study on bottle necks, rate
limiting processes…done..
• Plus other questions…related to deciding on the
‘right project’…all done
Once the ‘right project’ has been
decided upon…
Need a proper Project Management
 Project Management
• Develop a strategy and plan for the entire project.
• First step - formation of a project team, consisting of
"stakeholders" in project.
• Who should be the members?
• The key function of this project team is to go through
a Requirements Analysis, resulting in a Functional Requirements
Document (FRD)
• A document formally outlining the operational requirements of a
proposed system and specific conditions or stipulations related to
the project in general – like a problem statement…everybody must
understand
• This document is not a technical specification
• Example:
http://www.justice.gov/jmd/irm/lifecycle/appendixc14.htm
It must include whoever is ultimately going to be the owner/operator(s) of the
automated system. Many are the projects that have succeeded technically but failed
operationally because the "hands-on" laboratory staff were not on-board with the
project. It is vital that the eventual system owners/operators be identified at this stage
of project planning and that they have a positive attitude toward the endeavor. The
project team must also include those who will be the recipient of whatever is the
output of the automated system - a processed sample, assay data, etc. They must
understand and be prepared for any impact on their work that may result from the
new automation and should be encouraged to voice any concerns early. A person who
is the next cog in sample processing should certainly know that pending automation
may result in many more samples in their inbox or a change in timing of the arrival of
such samples. A person who depends on the results of a manual assay that is planned
to be automated must be comfortable with any changes or shifts that may occur to the
data. Finally, the project team must include secondary up and downstream people
who may be indirectly impacted by the new automation. If the new system is going to
involve a great increase in the use of consumables, then the person responsible for
purchasing and maintaining that consumable supply should be included. If the new
system will result in a great increase in raw data output from the laboratory, then the
person responsible for data processing and management should be included. If the
new system will result in a great increase in chemical or biological waste, then the
resources responsible for waste handling and disposal need to be involved.
Important Issues to Include in FRD
• Project objective
• Performance requirements – workflow study,
required system throughput, system availability,
total capacity, user interaction issues, reliability
(MTTF, MTBF), recoverability, audit trail,
interfaces
• Validation plan and test protocols
• Timeline
• Financial issues
Project objective: What is the overall project goal? What factors will define success? How does this project map to business
objectives, requirements and goals?
Performance requirements: What are the key measurements of performance necessary for the system to be successful?
What factors constitute failure risks? Examples include:
Required system thoughput: From the start of operation, what is the expected time for the processing of the first unit
or sample to be complete (ramp up time)? How many units or samples must be processed per unit time thereafter?
System availability: How many hours/day and days/week is the system expected to be available for use?
Total capacity: What is the amount of work the system can be loaded with at any one time, i.e. sample capacity.
Expected frequency of user interaction: How often is it desired for the system to require user interaction? What "walk
away" time is expected?
Reliability: What is the acceptible level of reliability? What is the consequence of unreliability? Are the samples
being processed irreplacable? Are timely results critical to the enterprise? Reliability can be stated as:
Mean-Time-To-Failure (MTTF): The mean (average) time the system is operable from start of operations before
the first failure occurs.
Mean-Time-Between-Failure (MTBF): The mean (average) time between failures of a system, including the time
of repair and recovery from such failures.
Recoverability: In the event of system failure, what type of recovery capability is expected? Must the system self-
recover? Is it sufficient to allow errors to be discovered at the time of the next scheduled user interaction? Should
the system announce an error condition, and if so how? What is the criticality of tending to an error situation?
Audit trail: What level of automatic documentation of operations is required? List the included data.
Software interfaces: Name the applications with which the system must interface and what data is to be exchanged.
Hardware interfaces: Name any specific hardware which must be part of or interfaced to the system. For instance, a
given assay might require a very specific detection device.
Validation plan and test protocols: Plans for actually testing and measuring key performance criteria. Include statistical
expections of precision and accuracy, throughput, failure rate, etc. Note: Specifics of equipment are unknown at this point,
so protocols must focus on known measurables in the process to be automated which will exist regardless of equipment
involved.
Timeline: Overall project timetable, including checkpoints and milestones.
Financial considerations: Overall project budget, including on-going operational costs.
 Technology Issues
• Much of lab auto involves use of technology
• After FRD, issues concerning technology can be tackled.
• Must consider:
 Process complexity
 Stability of procedures
 Capacity and throughput needs
 Experience with automation
 Funding
 Timeframe of need
• Future adaptibility
Process complexity: Simple processes point
toward simple technology, and vice versa.
Stability of procedures: Complex systems are
often not easily and quickly adapted to rapidly
changing procedures.
Capacity and unattended throughput
needs: High capacity and long periods of
unattended operation will require more complex
or at least larger systems.
Staff experience with automation: Take small
steps, build up experience and succeed.
 Build or Buy?
• Choice in sourcing lab auto technology..
• Off the shelf?
• Get technology vendor to work closely with you?
• Relevant skills available?
• What skills are needed?
• FRD very important! With FRD , vendors can
come up with proposals…Request For Proposal
(RFP)..
 System Testing and Validation
• There are two basic types of testing and validation -
• FAT, or Factory Acceptance Testing carried out at the
location where system engineering and fabrication is
done
• SAT, or Site Acceptance Testing done at the final
location for the system, typically the laboratory of
the system "owner“
• Must obey protocols and requirements originally set
out in the FRD
• Discuss why FAT and SAT?
 Ongoing operation and support
•Automation projects are not actually done once SAT is complete.
•Things will be taken for granted after that..
• The project “Champion” moves on: This often can't be avoided, but a broad team, with broad buy-in is the
best way to maintain focus and interest.
• System documentation is never completed, and after time, no one understands it: Be sure documentation
needs are listed in the FRD and don't declare SAT done w/o delivery of said documentation.
• The system is just not reliable: Did your reliability requirements match your technology entry point? High
reliability requires more mature technology.
• The physical location and layout are not flexible: Did you consider possible system changes when you
were planning?
• Appropriate long-term support not available: Build support funding into the funding original request. Be
up-front about on-going costs. Evaluate the potential longevity of products and providers.
• The original system provider bites the dust: Occasionally this happens, but good planning and research
on providers can minimize the risk. There are other ways to protect yourself, such as escrowing of
software or parts.
• The system is not adaptable to changing needs: You can't anticipate everything, but you know whether
you work in a slow or fast changing laboratory environment. If the latter, then you must place system
flexibility high on the requirements list.
•Compiling a rigorous FRD and having internal laboratory automation expertise is the best hedge against all
these scenarios.
 Performance Monitoring
• Important to monitor and detect
deviations because system will handle
huge number of samples – how?
• Design automated systems to monitor
themselves, recording and reporting key
operational parameters as checks of on-
going performance quality….
• Standard tests are performed by automated
systems at regular intervals
• Results are captured, stored and analyzed
automatically for non-conforming performance
• Immediate automatic notifications (e.g. email)
are sent regarding non-conforming performance
or other errors
• Critical information is tracked with control
charts and electronically posted regularly
• Periodic summary reports are generated and
distributed automatically
 Regulatory Issues
• Regulated laboratory environments, such as some in the pharmaceutical
industry, pose a unique environment for system project management
• Project planning practices must follow regulated environments.

• Develop a Functional Requirements Document (FRD) or User Requirements

Specification (URS) in a regulated environment
• Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT) =
Installation Qualification (IQ) and Operational Qualification (OQ) in a
regulated environment
• Ongoing operation and support / Performance Metrics
Monitoring = Performance Qualification (PQ) in a regulated environment
• The intention is to build quality into the process of planning, acquiring, installing
and operating laboratory automation systems via assuring that sound procedures
and practices have been followed and are documented and traceable
• In USA – FDA have GLP and GMP guidelines