Mid-project, a client says, “We didn’t expect the cafeteria to run this many covers.” Or, “We’re adding an evening shift.” But in reality the kitchen was never sized for either.
Most Project Heads have been in that meeting. When they are traced back, the cause is rarely the layout. It is an assumption that was never written down and confirmed before design started. A MEP consultant can size a kitchen accurately only against operating facts the client has actually committed to.
OPSTRAH’s answer is the Design Basis Report (DBR): a structured, signed-off record of exactly what the kitchen must serve, produced before any layout, utility sizing or equipment schedule is drawn.
This post covers what the DBR captures, where it sits in the process, what happens when it is wrong, and how a Project Head should use it as a control point rather than as paperwork.
What a Design Basis Report Actually Is
The DBR is not a design document. It contains no layout, no equipment list and no drawings. It is a documented, client-confirmed record of operating facts, and it is the source from which every later calculation is drawn.
OPSTRAH’s DBR format records the following:
- Total employees and future expansion
- Additional visitors
- Working hours
- Kitchen type and cooking medium
- Meals served and the cafeteria operating model (self-run or third-party vendor)
- Payment mode
- Cuisines and food categories
- Seating count and table rotation
- Drinking water provision
- And last but not the least, fire suppression intent
These read like simple facts but each one is a sizing input.
Cooking medium sets gas and electrical loads and shapes kitchen ventilation design. Seating count and table rotation determine peak-hour covers. Working hours determine how long the plant runs. A change to any one of them changes a number somewhere downstream.
Where It Sits in the Process, and Why That Position Matters
The sequence is fixed. The Design Basis Questionnaire is issued first. The client’s responses are compiled into the Design Basis Report. From there, the confirmed figures feed the Kitchen Mechanical Data Sheet, which records water, electrical, HVAC and gas requirements, and, through the Design Brief Report, the Area Program, which underpins BOH planning.
Each output has a defined job.
The DBR fixes the operating facts.
The Kitchen Mechanical Data Sheet converts them into utility requirements. The Area Program converts them into space. Because each conversion uses the previous document as its only source, an unconfirmed figure at the top has little chance of being caught by the stages below it.
For a Project Head, the structural point is this: nothing after this stage is independent of it. Equipment layout, equipment schedule and BOQ, finishes, tender documents and shop drawing evaluation are all downstream of what was confirmed here. An error at this stage is inherited by every stage after it.
Here’s the rewrite from “What Happens When the Basis Is Wrong” through the conclusion. Everything above that heading stays as it is.
What Happens When the Basis Is Wrong
One wrong assumption can quietly travel a long way. Here’s how it usually plays out.
Say covers are understated by 20%. The Kitchen Mechanical Data Sheet then undersizes water, HVAC and gas, and the commercial kitchen HVAC design built on it carries that shortfall into the finished kitchen. Say future expansion is understated. The layout has no room to grow, so the first extension means moving walls. Say the cafeteria operating model is recorded wrongly. The equipment schedule now serves a workflow that will never exist.
The evening shift from our opening scenario works the same way. Longer running hours change how much air the kitchen needs to extract and replace, how staff move through the space and when service windows open. If the shift never made it into the DBR, nobody planned for any of that. By the time it comes up, the equipment is already specified, and what should have been a line in a document is now a kitchen ventilation design problem.
Here’s the part worth remembering. None of these is a design-skill failure. The layout can be spot on and still fall short, because it was drawn against the wrong brief. It’s a documentation problem, and it starts at this stage.
We’ve covered the cost side separately in The Hidden Cost of Poor Commercial Kitchen Planning and How Early Kitchen Planning Improves Project ROI post . Here, the point is simply that the DBR is where this risk either gets created or gets prevented.
Why Getting This Right Early Is a Documented Discipline
You don’t have to take our word for it. The Construction Industry Institute (CII) built the Project Definition Rating Index (PDRI) to measure how well a project’s scope is defined before work begins. Its research across capital projects points the same way each time: the better the scope is defined at the front end, the more predictable the cost, the fewer the changes and the better the schedule holds up. Projects that start execution with strong scope definition tend to outperform those that don’t.
To be clear, PDRI is a formal industrial tool, and it isn’t what OPSTRAH uses. A kitchen project is also a much smaller job than the ones it was built for. But the idea underneath it is the one the DBR relies on. Agree the basis first, write it down, and outcomes get better. For you as a Project Head, the takeaway is simple: how well a project is defined at the start is one of the things you can actually influence.
What a Project Head Should Do With the DBR
You sign off on scope, so this part is really about you.
Start by reading every line as a commitment, not a formality. Check covers, shifts, future expansion and the operating model yourself. It’s tempting to hand the sign-off to someone else, but you’re the one in the room if the kitchen can’t cope with what was recorded. A DBR that only the consultant has read is just a document. One you’ve questioned line by line is a control.
Next, treat any change after sign-off as a proper change, not a quick request from the client. Once the DBR is signed, altering it has a downstream cost. Log it, look at what it does to the Kitchen Mechanical Data Sheet and Area Program, and approve it the way you’d approve any other change in scope.
Then keep the DBR close. When a scope question comes up months later (and one usually does), it’s the document everyone can point to. It settles the conversation quickly, and that’s exactly what you want from paperwork.
If you only have a few minutes at sign-off, ask four things. What’s the peak cover count? Which shifts will run? How far ahead does the expansion allowance look? Who will run the cafeteria? If any answer sounds uncertain, sort it out before you sign, not after.
How OPSTRAH Runs This Step
Here’s how we do it. We send the Design Basis Questionnaire to the client. Their answers are compiled into the DBR. We get it signed off. Then the Kitchen Mechanical Data Sheet and Area Program are built from those signed figures, including the inputs for commercial kitchen HVAC design.
As your MEP consultant, this is the step where we ask the most questions and draw the fewest lines. That’s on purpose. Confirming an assumption is a lot cheaper than correcting one later.
Conclusion: The Document That Decides What Gets Redone
Let’s be honest. The DBR isn’t the exciting part of a kitchen project. The layout, the equipment and the finishes are. But the DBR decides whether any of that has to be done twice. When it’s complete and signed, every later stage, from BOH planning to shop drawing evaluation, has something firm to work from.
If you’d like to see how a DBR is structured, we’re happy to share a sample. And if a kitchen brief is about to go out, let’s talk through the scope first. It’s a much smaller job to confirm an assumption now than to fix one later.
