Developing and Managing Lab Automation Projects

Managing automation projects is a lot like managing other IT projects.. not something that your average scientist has done a lot of. So how would a scientist go about effectively managing a high profile lab automation project? That has been the question that I've sought to answer for my own purposes over the past 5 years.

System Design

It's important to do your looking into the options that exist on the market. This will help get an idea of what the technology is capable of, and this will help build realistic plans. Vendors typically tend of have different strengths and weaknesses. Vendors can certainly help you develop your system, but it's important to have a dynamic that you can trust.

System design is one of the most crucial aspects of developing an automation solution that accommodates all of the plans. In whatever format you see fit, it's important to outline workflows with detail. In a system with multiple instruments, I like to map out the process using a format typical for business process mapping and notation (BPMN). Adequately defining your processes up front is probably the most powerful thing you could do to prepare yourself for the project.

This format below provides a way to chart each piece of technology in the plan, there will be less surprises down the line with missing functionality. If you don't plan well, the unknowns will be a killer. This is known as scope creep, and it's the bane of IT projects and those who continue to support them. It's also important here to round up performance specifications such as the experiment throughput that you are after.

A solid automation project plan should include the scope and processes as described above, the responsibilities of the project team, plan for testing and moving into production capacity, contingency planning, etc. The more detail the better in a scenario like this. This will also give you plan assets that will save you a lot of time in explaining your project scope to automation vendors. I recommend using a throughput to measure the effectiveness of the system during development. If you need the system to support several thousand samples per day, be sure to say that up front.

Quotes and Approvals

Once you have a plan in place, you can reach out to vendors to get the quotes for the system. This tends to happen before the purchase actually takes place, and even before you have management approval on the project. Without getting quotes, you won't know how much to ask for or how long it will take. If you are working with a company that handling all of the system integration, then they should round up all the necessary quotes and plans required. However, they will still need guidance to make sure there isn't any issues with your vendor heavily resisting scope creep down the road.

Pitching your project to acquire budget. Typically all of the steps is work that will go in before the project actually starts.

Real Kick Off and Project Planning

Here is where the project will effectively start, Purchase Order (PO) - Vendors typically won't do any real work towards building your system until they receive a PO. This is where you will get the details ironed out that may have been grazed over in the quoting process.

Engineering will typically be done by vendors that are integrating your systems, unless you are a mechanical engineer or have engineers working on your team. This is important to reduce issues in the long run by making sure all of your contact points between devices are solid.

Software engineering may be a factor in your project depending on the complexity. It's always best to try to remain within the confines of the functionality that vendor software provides, because it' can be difficult to get product-oriented vendors with a lot of customers to make changes. Typically the vendors make their software in a product-oriented way. This is ideal because it means consistency across systems. I've found that some companies using a more 'project-oriented' approach will make hard coded software changes to support each project, and this is not ideal in my opinion. The software is the underlying driving force, so consistency is best if you are going to have more than one of a given instrument.

Application development is the transition of your workflows into a user friendly application. Things to think about in this phase are the experiment details, required functionality, intuitive usability, error handling. Typically vendors provide scripting environments to control their robots, and you can pay them to script methods for you too. Here is where you workflow map comes in, because for each workflow the programmer will directly use those BPMN charts to make sure all parameters are covered. Having those is incredibly helpful, otherwise get ready to play a game of 200 questions.

Installation and validation

Vendors will provide lead times for all of the instrumentation involved. Typically the project plan will include the minimum expectations set out in the project specification documents before job is complete, and this is often tied to final payment on the system. If you want specifics verified at this time, be sure to include them in the specification documents. Generally I pay the vendors for both a Factory Acceptance Test and a Site Acceptance Test. This means they need to pass my expectations at the factory before shipping, and then again before the instrument is ready for production. Of course you could do only one or neither of those tests too.

All of these project phases factor into a final timeline, which will likely be one of the first 2 questions asked by management: When will this be up and running? The other question of course is: How much will it cost? The cost and timeline is what the stakeholders will be most concerned with, along with the assumption that the system will fulfill the requirements of the workflows planned.

Launching into production is honestly another game entirely. I've found that devices in a production environment show you how they really are, testing never seems to capture the full scope of usage in the projects. This is also a good indication that I could have planned better. In a production system, higher demand drives need for quicker response when issues arise. Successful systems typically have talent in house to address issues, ironing out of kinks, and continually optimize performance and drive new expansion of system capabilities.