No project starts with a strategy to ignore the quality of design, but in the powerplay of a typical biopharma project, it happens: Under the severe constraints of time and cost, the design gets rushed and its quality gets crushed.

However, the quality of design eventually reveals its true colors during construction, commissioning, and qualification when design-related roadblocks bog down the project. These problems could come in many shapes and sizes: conceptual design mistakes, services and equipment clashes due to ignored space constraints, undersized equipment, missing instruments, control logic issues, out-of-tolerance humidity, temperature, and room pressures, and irreversible maintenance constraints. Unfortunately, in the rush of a project, few people realize that the quality of design decides the fate of the whole project on all three critical dimensions: Cost, schedule, and quality.

I have seen that projects where the design goes through rigorous quality reviews and checks by the client’s own team always end up with a safer and sounder design, making everyone’s life easier down the road. This post lays down the groundwork for HVAC Design Qualification (DQ), which is one of the key milestones in the process of qualifying direct-impact HVAC systems. Let’s look at:

• What is DQ?
• When to do it?
• How to do it?
• Barriers to a smooth DQ

As a formal qualification exercise, the objective of DQ is to ensure the quality of design by systematically verifying that the final HVAC design meets or exceeds the user requirements. In essence, DQ answers a simple question: Are the HVAC systems designed to deliver what’s required in the end?

For example, if HVAC URS (User Requirement Specifications) requires a minimum 15 Pa pressure difference between rooms of different grades, DQ involves verifying it in the pressurization drawings. Similarly, if the URS requires a minimum of 30 Air Changes Per Hour (ACPH) for Grade C rooms, the HVAC AFIDs and Room Book should show that systems are designed accordingly.

But DQ doesn’t cover all user requirements; it covers only the critical, i.e., quality-related user requirements. In the context of HVAC, these critical requirements typically include anything that could potentially impact product or process quality: GMP room classifications and cleanliness requirements, pressures, temperature, relative humidity, terminal HEPA filters, GMP alarms, low-level returns, etc.

But what about the rest of the requirements in the URS, such as engineering, business, and EHS (Environmental, Health & Safety) requirements? Well, these requirements also need to be verified, but under DR (Design Review).

An engineering exercise, DR covers all URS requirements (quality and the rest), and it must be done before DQ. If DR is done diligently, DQ is simply repeating the checks (for the quality items in URS) for qualification purposes. [Just to clarify: By DR, I don’t mean the design company presenting its design in PowerPoint slides in a messy 2-hour meeting with 15 different people looking at it and commenting arbitrarily. DR means the client’s SMEs (with the design team) systematically walking through the whole URS and verifying each requirement in HVAC design documents. And properly documenting the outcome of this review.]

Unfortunately, DR is not an easy undertaking: It requires a good understanding of HVAC URS and design and painstaking reviews of URS vs. design. No wonder, many projects skip DR, which is the key reason behind unfortunate design mess-ups.

DQ requires two inputs: 1. Approved URS and 2. Final approved design documents.

Typically, the qualification teams wait for both items to fall in place, which drags the DQ down to much deeper into the project. Sometimes, DQ gets executed long after the actual design is finalized, towards the end of construction or commissioning. But by that time, it’s too late to fix any design gaps.

Ideally, DQ should be initiated as soon as the approved URS is available. Once the URS is available, one should start reviewing the available design documents to get a sense of alignment between the design and the URS. Initially, you’ll hit multiple roadblocks: Missing documents, incomplete drawings, wrong drawings, misalignment between drawings, and so on. That’s fine if you understand that by initiating DQ earlier, you’re helping to plug the design gaps, tidy up all design documents, and raise the quality of the overall project–when it is easy to do so.

Overall, the DQ team should be a driver of design quality, not a passive recipient waiting for the design documents toward the end of the project.

Like any other qualification exercise, DQ requires a pre-approved protocol to execute, but essentially, it includes the following three sections:

1. Prerequisites
2. Documentation checks
3. Design checks

DQ begins with checking the status (approved?), version number, and date of approval of the following documents:

1. URS
2. SCA (System Classification Assessment)
3. SRA (System Risk Assessment):

All these prerequisites are inputs for design, and that’s why it should have been frozen and approved before embarking on DQ.

This section is a kind of inventory of the latest design documents–drawings, specifications, data sheets, etc. In a way, this is like freezing the design and drawing a line—beyond which, any further design changes should go through a formal engineering change control system.

This is the heart of DQ, where all the critical (quality-related) user requirements are listed. Each requirement needs to be verified against the relevant design document(s). This is where HVAC design goes under the quality scanner–and must come unscathed.

The diagram below shows a simple anatomy of a typical HVAC DQ.

Finally, what can go wrong with a DQ despite all good intentions?

Here are some pitfalls to avoid to ensure DQ is a smooth affair:

• Vague URS: A precise, complete, and realistic URS is critical for a smooth DQ. But if the requirements themselves are vague, incomplete, or plain wrong, that’s a recipe for not just a DQ but a whole project mess.
• Messy design documents: Proper design documentation is a must for a smooth DQ.  Sub-standard design package (incomplete, wrong, or inconsistent drawings, specifications, etc.) is another pitfall to avoid.  
• No DR: If there is no Design Review prior to DQ, that’s a potential risk for DQ. DR is supposed to arrest any design gaps well before a DQ gets formally executed.

These barriers convey a simple message: DQ is not an event; it’s a process, and if the DQ team proactively works to ensure the quality of URS, the quality of design documents, and the execution of a DR–the DQ will automatically fall in place. It’s not a “paper exercise” to somehow get over with, but a byproduct of sincere efforts to ensure the quality of design.

To conclude, unlike deliverables, schedules, or costs, the quality of design is not measurable and can’t be tracked. And that’s where lies the risk of the quality getting sidelined, something that Einstein highlighted ages ago.

Not everything that counts can be counted, and not everything that can be counted counts.

Albert Einstein

A successful project is one where people don’t depend on the Design Qualification (DQ) to certify the quality of design. Instead, design and its quality are nurtured from the beginning, knowing it will affect everything else down the road.

---