Welcome back to this series! Perhaps you previously read a post that described a problem I encountered in a previous life – a new process development lab rendered unusable because the circuitry could not support the equipment power consumption.  

The equipment list for the laboratory was generated during a roundtable discussion. The details in the spreadsheet were incredibly comprehensive - all of specifications for the equipment were listed, including everything the engineering team needed to know for power consumption. After the brainstorming session, the team realized some gaps in equipment. Additional equipment was ordered but never added to the list and was not communicated to the engineering team responsible for lab construction.

Roundtable brainstorming sessions are incredibly popular and can be very useful, especially if they are structured to ensure efficiency and complete coverage of the idea at hand.  However, if brainstorming sessions are not structured, we risk overlooking key things.  

When starting a new project, I encourage following a robust process.  In this case, a proposed first step would be identifying use cases for the laboratory.  This would give a wholistic view and enable planning for the ‘now’ and the future. If use cases are identified upfront, they can be systematically analyzed to further understand enabling processes and equipment.

Brainstorming sessions could be structured to identify use cases, analyze use cases, and then identify the equipment requirement for each step. Sure, this sounds like a bit more work then everyone sitting in a room for an hour to generate an equipment list. Maybe this would take 5 hours, maybe 6? But that's a lot less time and money than having to rip a brand new lab apart to redo the electrical system. (Wait, I forgot to mention about the HVAC too...)

If you are not familiar with a use case, one of my favorite definitions comes from ‘A Practical Guide to SysML The Systems ModelingLanguage’ (S. Friedenthal, et al.)

A use case describes the goals of a system from the perspective of the users of the system.  The goals are described in terms of functionality that the system must support ….

In this case, the use cases are the functions that the system, the lab space, must enable for the scientists to … do science.

The Use Case Diagram in Figure 1 shows example use cases for a cell process development laboratory.  Notice that the Culture Cells use case has an extending use case named Passage Cells and an included use case named Prepare Culture Media.  Achieving the ‘Max cells’ extends the Culture Cells use case.  (Note– Passage Cells does not always happen if someone performs Culture Cells.)   Prepare Culture Media will occur at some point when someone cultures cells.  

By identifying use cases, included use cases and extending use cases, I gain insight into things like equipment and material usage.  I can ask follow-up questions to aid in a use case analysis. To name a few -

• What is your process for passaging cells?
• How often do you passage?
• Are you satisfied with your process?
• What improvements do you think could be made in the future?

Taking time to identify the use cases (for any project or system) enables definition of the scope and boundary of the system under development. Once the full scope is defined, you can perform a use case analysis to understand the needs and processes that enable the use case. By analyzing the use cases, I can identify all types of equipment, quantity of each, and usage rate to enable a power consumption analysis. (Look out for the next blog in this series that describes a use case analysis!)

‍

Resources

Friedenthal, S., Moore, A., Steiner, R. (2015). A Practical Guide to SysML: The Systems Modeling Language - Third Edition. Waltham, MA. Elsevier.

‍