The Catastrophe. The Frustration. And Then The Plan.

I have experienced many situations in which deploying systems thinking at the start of projects would have saved a lot of time and money.  Although, if systems thinking had been deployed, I would not have as many funny stories to share.  

At one point, I was involved in the build out of a scientific research and development lab.  I came onto the project at the tail end, when the lab was coming to fruition.   As lab equipment was being received and installed, complaints were rolling in regarding equipment randomly turning off.  Initially, I attributed this to…human error and faulty equipment.  (I know, terrible assumption.)  The lab was constructed by a reputable team of engineers, and we provided the engineers with the lab equipment layout and equipment specifications, so it HAD to be an issue with the equipment or people, right?

Wrong.  

It turned out that the circuits could not support the load of the equipment.  Every outlet in the space would trip and turnoff equipment, rendering the lab unusable.   After a small sigh and a short period of resting my forehead on my desk, I got to work.  In the end, we needed change controls to redo the circuitry because there wasn’t enough power to support the equipment required for the lab activities. And that cost $$$$.   This is one of many spectacular examples of how MBSE could have saved time and money.  

I’ll tell you a little bit of the MBSE approach I would take for this problem. And by approach, I mean the three pillars of MBSE – modeling language, modeling tool, and modeling method.  Specifically in this example I use SysML(Systems Modeling Language) as the language.  For those who are software engineers or developers, you are likely familiar with UML (Unified Modeling Language).  SysML is a graphical modeling language that is an extension of UML.  The modeling tool I am using is Cameo Systems Modeling v. 19.0 with the SysML plugin from Dassault Systemes (previously No Magic, Inc.)  The diagrams (or as I like to refer – pretty pictures) are generated using SysML and are used to provide you with a view of my model.  

The high-level overview of my modeling method:

1. Generate use cases for each laboratory space.  Generating use cases supports black box thinking.  I need to understand the main goals of the lab for all users and stakeholders, not just the assumptions of the few who initially designed the lab.  
2. Define user-specific activities or sequence diagrams to describe each use case.  The initial lab build out focused on critical activities that the lab needed to support, but bypassed the full range of activities requirement to enable each use case.  This resulted in forgetting about critical equipment that was needed to enable the ‘critical activities’ in the lab.
3. Define the enabling technology for each activity by means of a context diagram.  By developing context diagrams, I will understand all the equipment that is required to change the inputs into outputs for each activity and any other equipment that may be required to support analysis of the controls. By developing use cases, defining all activities to support the realization of the use cases, and defining context diagrams, I can develop a comprehensive list of equipment required for the lab space.
4. Populate my model with blocks for each enabling technology (specifically, systems or tools that require a power source) and calculate the anticipated power consumption for each laboratory space given anticipated multiplicities for each block.

If this method had been deployed at the start of the project, we would have avoided massive change controls and been able to open the lab on time (and on budget.)  Keep a look out for the next blog in this series where we dig into use case development.