“A camel is a horse designed by a committee.” — Alec Issigonis
Good process design results in a process that is more likely to work. Great process design results in a process that is even less likely to not work. Great process design is not the result of compromise and trade-offs, but of a singular vision of what the process must do.
Great process design is the safest process design, because safety is the natural outcome of things working. Hazards result from things not working, either because they never worked (a design problem) or because they stopped working (an operations and maintenance problem).
A process design team is not a committee. Each member of the team has a contribution to make, based on their experience and expertise, but they make their contributions individually. A process safety team is a committee. Each member of the team also has a contribution to make, based on their experience and expertise, but their contributions are collective.
There is an important distinction between design and review.
Process Design vs. Process Review
The difference between process engineering and process safety engineering is that process engineering is about figuring out how to make a process that will work, while process safety engineering is about figuring out what will happen if the process doesn’t work.
Process review cannot begin until there is a process to review, while process design could begin with a blank sheet of paper, although it rarely does. One of the worst things that can happen to a process review team is to be presented with an incomplete process with instructions to fill in the blanks—to design the process. That is not the role of the process review team, even if some of the members of the team are perfectly qualified to perform the role.
Worse, even if some of the members of the team are perfectly qualified to perform the role of process designer, it is unfair to the other members of the team to hold them hostage to the design process.
Process Review vs. Process Hazard Analysis
Process review looks to confirm that the process will work as designed. Usually, that means the process review team is looking to see if there are any flaws in the design that would prevent it from working.
Process hazard analysis takes it beyond that. Instead of simply looking for flaws in the design that would prevent it from working, it begins with the assumption that each element of the design is going to fail to work at some point. It then seeks to discover what harm will result from that failure.
Both process review and process hazard analysis will discover hazards, either hazards of design, or hazards of operation and maintenance. They take a different set of skills, however. It is a rare process review team that is ideally suited to process hazard analysis, and likewise, a rare process hazard analysis team that is ideally suited to process review. It is wise, then, to conduct the process review separately from and before the process hazard analysis (PHA).
With existing processes, this is not typically a problem. The process is in place, having already been through a process review (or many), and the staff associated with the process, including but not limited to the process engineer, are constantly reviewing the process in the quest to improve it. When they are true to the spirit of process safety, each of these improvements goes through a management of change procedure that then performs some form of PHA specific to the improvement.
Then, regardless of changes that have been implemented, the staff associated with the process subjects it to a periodic validation, to make sure that new hazards haven’t been introduced or that existing hazards haven’t been overlooked.
Reviewing New Processes
New processes are trickier. In many cases, they are under timing constraints, and the PHA is scheduled before a process review is complete. Often, the PHA is the first time that members of the PHA team have seen the process design. They will have questions about how the design works. They may also have opinions about how it could work better or if it will work at all.
When we plan for a PHA, particularly for one conducted in the form of a Hazard and Operability Review (HazOp), we generally budget about 2½ hours per piping and instrument diagram (P&ID), unless we have good reason to believe it will take longer than that. One of the reasons that prompts us to schedule more than 2½ hours per P&ID is when the HazOp is of a new process. We know from experience that there are going to be more questions.
How much more? When we believe that the process design is essentially complete and that the review is really a PHA, not a design review, we typically plan on 3 to 3½ hours per P&ID. This is not only to conduct the design review, but to give team members time to question the designers and understand the process. If we believe that a design review has not been completed, then we insist that the design review be done before the PHA begin.
But what if it doesn’t become apparent that a design review still needs to be completed until the PHA is already underway? In some cases, we’ll proceed, acknowledging that the make-up of the team will probably need to be adjusted accordingly. It is simply unfair to PHA team members with little to contribute to the design review to insist that they remain. In most cases, as awkward as it may be, we will stop the PHA with plans to resume after the design review is completed.
Designing During a Review
One of the most important things I learned about PHAs in my early training as a PHA facilitator, back when dinosaurs still roamed the earth, is that “Evaluation and design is part of ‘consider’, not the PHA.” To this day, I include that statement in the training I give on PHAs. In fact, I believe it to be so important that I repeat it in a second slide, in huge, bold letters:
“Evaluation and design is part of ‘consider’, not the PHA.”
When the need for design becomes apparent, as it always does, the recommendation is something along the lines of “Develop a design that best addresses some specific design objective.” The team, which is there to find hazards, is not tasked with developing designs.
Are there exceptions? Sure. If the design modification is relatively straight-forward, and the team can quickly achieve a consensus about what needs to be done, it makes perfect sense to document their suggestion. But even in those circumstances, this recommendation needs to be made with the full understanding that the process designers may come up with a better solution. While the process safety regulations require that all PHA recommendations be addressed, they do not require that they all be implemented as recommended.
How do I decide that a design modification is relatively straight-forward? If the person proposing the modification can describe it without going to the board. The moment they go to the board, or worse, that a second person joins them at the board, then the design needs to be addressed separately.
Reviews are Intentional
Design happens whether intended or not. The opposite of good design is not no design, but bad design. Reviews, on the other hand, must be planned. Because the skill set for a design review is different from the skill set for a hazard review, they should be done separately.
That won’t always be the case, and most teams can cope with slight deviations from this best practice. When the rule is ignored completely, however, it is a terrible waste. So, plan for design reviews to be done separately and before hazard reviews. Otherwise, you’ll end up with a camel when you wanted a horse.
