System boundaries are total fiction, but they matter in a project. If not defined at all or not defined correctly, these boundaries can fuel a good deal of confusion in a project.

But first, let’s step back and look at our own body, which is actually a collection of a number of systems–digestive system, respiration system, nervous system and so on. All these systems work seamlessly, but each system has its own structure, complexities, inputs and outputs.

A typical building is no different. It needs many systems to integrate and work together to become a fully functioning facility. A typical pharmaceutical plant would include systems like electrical power, emergency power, chillers, boilers, purified water, compressed air, chilled water, hot water, fire protection, Air Handling Units and air distribution (referred to as HVAC system), process equipment, automation and many other systems. Within these systems may be sub-systems. For example, an HVAC system may include a number of Air Handling Systems serving different areas of the facility.

Just like the body, to grasp and manage a complex pharma project, one needs to dissect it into multiple systems. That brings us back to the basics:

• What’s a system boundary?
• Why does it matter?
• How does one decide these boundaries?

System boundary, as the name indicates, is the boundary where your system A ends and system B starts. For example, for a typical Air Handling Unit system, on one side of the isolation valve, you would say it’s a chilled water system (system A) and on the other side, you would treat it as an AHU system (system B). Similarly, for a compressed air system, one could create a boundary between the generation (air compressor system) and distribution (piping, valves, etc.). The same goes for a chilled water system: Chillers could be treated as a system, while the associated chilled water loop as a separate system.

So basically, a boundary is just a fictitious line drawn on drawings to show the separation of systems. Coming to the next question, why does it matter?

Well-drawn system boundaries help in multiple ways:

First, by going through the system boundary exercise, you get to know the project in its full scope without missing anything. These boundaries help to assess the magnitude of the work involved.

Second, it also provides clarity on the scope of work in terms of construction, commissioning and documentation. For example, the main piping contractor may be responsible for piping up to the isolation valves at an AHU, and from there on, the piping could be in the scope of the HVAC contractor.

Finally, how do you hand over a huge facility to the users unless you divide it into manageable parts? That’s where systems come in handy; you hand over system by system.

This is a tricky question. Normally, this work falls into the lap of the commissioning team and should be done by someone senior and experienced enough to know the different systems and be able to connect with various Subject Matter Experts (SMEs).

If I were to do this work, I would take the following steps:

• Study: Read the Basis of Design (BOD) document, drawings, user requirements, and any other documents that describe the scope of a project. This homework is important before you talk to anyone to seek help.
• Speak: After having a baseline understanding, I will speak with key SMEs and see whether my understanding matches their understanding regarding the scope of work and key systems.
• Prepare: Next, I will create the first draft proposal on (a) the number of systems and (b) indicative boundaries.
• Review: I will then invite all key team members and present them with my first draft of system boundaries. It could be in the form of a few slides and a worksheet.
• Refine: Based on the feedback from the workshop, I will refine it and present it again.
• Closure: Based on the second workshop’s feedback, I will refine it again and close the story by publishing the system boundaries to everyone.

Following a systematic process is a sure way to arrive at correct systems and boundaries logically. For a typical project, you may end up with 150 to 200 systems. Neither you want to dissect too fine nor too broad.

System boundaries may be total fiction, but that’s the way to get a grip on the complexity and scope of a project–and manage it well.

---