Food Plant Basis of Design: The Document That Aligns Budget and Capacity

1. Give the Design Basis a Clear Decision Purpose

Define what the current issue of the basis is intended to support. A concept-stage issue may be used to compare sites and process options. A later issue may support detailed engineering and purchasing. The level of evidence should match the decision without obscuring the assumptions that remain open.

State the project scope and the boundaries of the document. Identify whether it covers one process area, a complete production line or the entire facility. Explain interfaces with building design, utility studies and owner-managed work so readers know where to find related requirements.

The GAO cost-estimating guide identifies a technical baseline and documented assumptions as important elements of a reliable estimate. For a food plant, a controlled design basis helps connect those inputs to the engineering work. It does not turn an early estimate into a guaranteed price.

The document should answer a practical question: which agreed inputs were used for this drawing, quotation or budget? If the team cannot answer that consistently, the basis needs better structure or control.

2. Owner Brief vs Basis of Design vs Detailed Drawings

The owner brief describes the business outcome and constraints. The basis of design translates them into agreed engineering assumptions and boundaries. Detailed drawings and specifications develop the selected solution. These documents should connect, but they perform different jobs.

A basis of design should not become an uncontrolled collection of every project file. It should identify authoritative inputs and references so the team can find the relevant detail without creating conflicting copies.

3. Define the Product Envelope and Preservation Assumptions

Describe the product families and the characteristics relevant to the process concept. Include the intended preservation route, packaging, distribution conditions and important quality requirements. Identify the representative products used for planning and the limits of their applicability.

Mark unresolved development questions. A product that has not completed the relevant process work should not be represented as having a fully approved commercial process. Identify the specialist decisions and evidence needed before the engineering basis can be finalized.

Distinguish launch products from later options. If a future product changes the process or room requirements materially, record it as a separate scenario. This helps the owner decide which provisions to include initially and which capability belongs in a later capital phase.

DPS’s capital-planning and process-engineering work can help organize these product assumptions into a conceptual scope. The value lies in an explicit operating envelope that the owner, quality team and engineering disciplines can review together.

4. Use Saleable Output and a Defined Time Basis

State demand and capacity in compatible units. Annual cases, weekly production, packaged units per hour and process mass flow may all be relevant, but the conversions must be documented. Define the product and pack mix behind each figure.

Separate a machine’s offered rate from the saleable output expected over a schedule. The basis should identify planned time, production windows, changeovers, cleaning and other modeled losses. Supplier acceptance conditions may be narrower than the owner’s overall business output requirement.

Record the scope of each factor used in a capacity calculation. If planned cleaning time has already been subtracted, do not include it again in a general running factor. If yield is applied to saleable output, state whether any product loss has already been accounted for elsewhere.

The objective is a calculation that another discipline can reproduce without guessing. When a product mix or operating assumption changes, the same structure should show how the required process, packaging and storage duties may be affected.

5. Record the Operating Calendar and Campaign Logic

Describe the launch shift pattern, operating days, planned shutdowns and the production planning horizon. Explain whether the facility is expected to run long campaigns, frequent small orders or a mixture of both. A capacity statement without that schedule can support several incompatible design interpretations.

Include cleaning and changeovers as operating activities with defined assumptions. Identify which events occur per shift, per campaign or between particular product families. The quality and operations teams should approve the relevant sequence rather than allowing each supplier to invent its own favorable schedule.

Keep staffing assumptions visible where they affect the operating plan. A schedule that assumes continuous replenishment or immediate quality support needs an appropriate operating model. Do not describe those activities as engineering capacity if the owner has not planned the people or services to support them.

Use separate cases for launch and a later development phase. This prevents the initial estimate from silently including a future operating schedule while the business case assumes a more limited opening plan.

6. Identify Verified Site Data and Provisional Conditions

The basis should identify the parcel, building reference and available survey or drawing information. Record which dimensions and conditions are verified and which come from preliminary documents or assumptions. Keep the evidence date and source available to the disciplines using it.

List material site constraints, including access, available space and the major utility or discharge questions that affect feasibility. Detailed studies may be held elsewhere, but the basis should reference their current issue and preserve important qualifications.

A seller’s statement, an initial site visit and an engineered investigation do not provide the same evidence. Avoid combining them under a single unqualified label such as “existing conditions confirmed.” State what has actually been established.

If the preferred site changes, issue a controlled revision and identify the affected work. Reusing the same production concept in another shell may still change the layout, utility interfaces, construction scope and schedule. The basis gives the team a place to track that consequence.

7. Connect Quality Requirements to Design Inputs and Owners

List the approved quality and food-safety requirements that influence the engineering, together with their decision owners and supporting references. Separate legal requirements, customer commitments and internal preferences. Their approval processes and evidence may differ.

Do not use the basis to declare that a generic process or layout is compliant. The relevant qualified specialists should establish the requirements for the actual product and operation. The engineering task is to incorporate approved requirements and expose interfaces that need further review.

Gray’s food plant design guidance describes why production and food safety need early consideration in facility planning. In a design basis, this becomes a practical requirement to identify the quality inputs before separate disciplines develop incompatible solutions.

Record unresolved items with a decision date and consequence. If a product-processing decision could change utility demand or room segregation, the basis should make that dependency visible. A drawing cannot safely resolve an open quality decision merely by showing a plausible arrangement.

8. Use Fields That Connect Assumptions to Evidence

A readable basis does more than list values. It explains where a value came from, what condition it describes and who can change it. This is especially important when a conceptual project includes a mix of measured data, owner targets and supplier estimates.

Keep the main document concise enough to use. Detailed data can remain in controlled attachments, provided the basis identifies the authoritative issue and the important conditions that affect the project.

9. Show How a Schedule Revision Changes the Design Case

Consider an invented single-format example with eighty scheduled hours per week. Ten hours are allocated to planned cleaning and five to changeovers, leaving sixty-five production-window hours. A separate residual running factor of 0.90 excludes those planned activities, and a saleable-yield factor of 0.98 is applied once.

At a hypothetical rate of 4,000 units per running hour, the resulting output is 80 minus 10 minus 5, multiplied by 0.90, 0.98 and 4,000: 229,320 saleable units per week. The values are teaching inputs, not equipment ratings or food-industry performance benchmarks.

Basis B changes only the assumed changeover time. The lower result should trigger a review of the commercial plan and technical options, not disappear inside an unchanged capacity headline.

10. Visualize the Consequence Rather than Hiding It in a Revision Note

The schedule revision reduces modeled output by 14,112 units per week, about 6.2 percent of Basis A. That does not prove the process needs faster equipment. It shows that the revised product or campaign assumptions no longer support the same output under the rest of the teaching model.

Possible responses include revising campaigns, adding operating time, changing the commercial mix or developing another technical concept. The owner and relevant specialists should compare those options. A design-basis revision is valuable because it exposes the decision before the team continues developing an incompatible scope.

11. Define Utility Interfaces Under the Same Operating Scenarios

Reference the utility demand basis used by the process and facility teams. Identify required conditions at the relevant boundaries, the operating scenarios and the status of supply information. Keep detailed load schedules as controlled references rather than copying values into multiple uncontrolled tables.

A utility requirement should say whether it describes normal operation, a peak event, startup, cleaning or a future phase. The scenario should match the production schedule used elsewhere in the basis. Otherwise, a plant can be sized using a peak assumption that the estimate or provider inquiry never included.

DPS’s utility-load and process-layout coordination can help identify these interfaces during planning. Define the project’s required deliverables so the provider inquiries, on-site systems and equipment packages are developed against the same assumptions.

When a product or schedule changes, review the affected utility scenarios. Do not assume every load scales directly with saleable output. The revised cleaning sequence or startup pattern may matter more than the annual volume difference.

12. State Equipment and Installation Battery Limits

Identify the physical and functional boundaries of major packages. A supplier’s skid, the plant-level control system and the installation contractor may each assume another party provides an interface. The basis should establish the common boundary used when specifications and estimates are developed.

Record who supplies connecting piping, power, instrumentation, communications, guarding, testing support and other relevant work. Detailed responsibilities may be held in a matrix, but the basis should reference that matrix and identify the assumptions that affect the overall concept.

A package comparison is meaningful only when the parties use compatible limits. One quotation may include local controls and another may exclude them. If the estimate adds the same controls under a separate heading without reconciliation, the total can contain duplication as well as gaps.

Keep owner-supplied equipment visible. Existing or purchased assets still need data, integration and acceptance assumptions. A low acquisition cost does not eliminate the requirement to establish how the asset fits the proposed process and operating plan.

13. Connect the Design Basis to the Basis of Estimate

The cost estimate should identify the design-basis issue used to prepare it. Its own basis explains pricing dates, methods, allowances, exclusions and uncertainty. These two documents are related, but a technical assumption and a pricing assumption are not the same thing.

DOE’s cost-estimating guide discusses documenting the estimate basis and treating escalation and contingency appropriately. For this project, the practical requirement is traceability: the owner should be able to see which defined scope the estimate includes and which information remains provisional.

If the design basis changes, identify whether the estimate must be updated or whether the change falls within an already defined allowance. Do not let an old budget total continue circulating without a note explaining that it reflects a superseded production or site assumption.

Separate a cost increase caused by added owner scope from uncertainty within the original scope. Both affect the investment decision, but they should not be reported as the same kind of event. A controlled design basis helps preserve that distinction.

14. Use a Change-Impact Matrix Across Disciplines

Not every revision affects every discipline equally. A useful change process identifies the possible interfaces, assigns a review and records the outcome. It should be light enough to use while still preventing consequential changes from moving through one team unnoticed.

Attach the review result to the revision rather than merely noting that a value changed. The next reader should understand the consequence and the reason the project continued on the selected basis.

15. Assign Approval Roles without Making Every Detail a Board Decision

Define which inputs belong to commercial, quality, operations, finance and engineering leadership. The capital sponsor should approve the overall operating and investment basis, while qualified specialists own the decisions appropriate to their disciplines.

Set thresholds for escalation based on the project’s governance needs. A minor clarification and a new product family should not require identical review, but neither should be allowed to alter an important interface silently. The actual process should be agreed by the owner and project team.

Record approval status and unresolved items separately. A basis can be approved for a specific planning purpose while containing provisional information, provided the limits are explicit. Approval should not erase qualifications or imply that the document is suitable for a later purpose it does not yet support.

Keep one authoritative issue available to the team. A signed document is not useful if suppliers and contractors continue receiving older attachments through informal channels. Version control is an operational discipline, not simply a document-numbering exercise.

16. Review the Basis Through Realistic Operating Scenarios

Run the team through a representative campaign, a changeover, a cleaning event and a launch scenario. Ask each discipline which assumptions it uses and where it depends on another party. This reveals conflicts that may not be obvious in a document review conducted one discipline at a time.

For example, a layout may assume immediate movement of finished goods while quality expects a hold. A utility model may assume cleaning occurs after production while the operating plan requires overlap. Neither conflict is resolved by improving the formatting of the basis; the owner needs a coordinated decision.

Conclude with a controlled issue and an open-item register. Assign the evidence and decisions required for the next issue so the review produces a clear progression rather than an indefinite request for more detail.

17. Reconcile Supplier Data Before It Becomes the Project Basis

Supplier information can improve the basis, but it needs review against the owner’s requirements and the package boundaries. Identify the product, operating conditions and acceptance assumptions behind a proposed capacity or utility value.

Do not substitute a favorable brochure rating for a project-specific duty. If a supplier’s proposal changes the assumed operating sequence or available format range, record the difference and obtain the appropriate owner decision. A quotation is evidence of an offer under conditions, not automatic validation of the entire plant concept.

Keep the status of data visible: preliminary, proposal, approved or another project-defined designation. The detailed design team should know which values can be used for development and which still need confirmation. This helps avoid redesign caused by treating an early outline as final dimensional information.

When multiple suppliers provide related packages, reconcile their interfaces together. The basis should identify any remaining mismatch before the owner relies on the combined quotations as a complete production system.

18. Preserve the Business Meaning Behind Technical Values

A design basis becomes easier to review when leaders can connect its values to recognizable products and customer requirements. Use representative samples, controlled packaging information and plain-language scenario descriptions alongside the technical schedules.

This does not replace engineering data. It helps prevent a common misunderstanding: a number may be technically consistent while referring to a product or format the commercial team no longer intends to launch. The basis should make that connection clear enough for a nontechnical sponsor to ask the right question.

Keep those reference samples and specifications controlled as the project develops. A revised package or recipe should enter through the same change process as a revised capacity target, with the affected technical assumptions identified.

19. Commission a Basis That Supports the Next Capital Gate

For an early DPS engagement, ask for a scope that connects owner requirements, conceptual process and layout, major utility assumptions and investment alternatives. Agree on the basis-of-design format and the decision the first issue must support.

Do not ask for a fully settled document when the business still needs an options study. Instead, require clear scenarios, traceable assumptions and named open items. As the owner selects a route and better evidence becomes available, the basis can become more defined without losing the history behind the decisions.

Dennis Group’s service structure illustrates the breadth of planning and engineering activities in food projects. Your own engagement should select and assign the activities actually needed. The useful standard is a common basis the project team can use, not a document title that implies more certainty than the work has established.

20. Keep Commercial Assumptions Distinct from Technical Verification

An owner can approve a demand scenario for planning without claiming that every future unit has been sold. An engineer can calculate a capacity requirement without proving that a particular supplier will achieve it. A process specialist can identify work needed for product approval without implying that the process has already been established. The design basis should preserve these distinctions.

Give each important statement an appropriate evidence type. A commercial forecast belongs to the business case; supplier-confirmed operating data belongs to a technical package; a product-specific quality decision belongs to the responsible review. They may support one another, but none automatically replaces the others. This prevents the document’s approval status from lending unsupported authority to an unresolved input.

When management asks what is proven, answer in terms of the evidence and its boundary. A useful basis can include uncertainty and still support a decision, provided the sponsor understands what would happen if a material assumption changes. That is more informative than treating every approved cell as an established fact.

21. Close Open Items with Evidence Rather than Deleting Them

An open-item register needs a closure record. State the information received, the decision made and the references updated. A line that simply disappears between issues leaves later readers unable to distinguish a resolved question from a forgotten one.

If the answer differs from the planning assumption, identify the affected work before closing the item. A utility response may confirm service only under a different connection arrangement. A supplier may confirm the offered capacity only for part of the product envelope. The resolution can therefore create a scope decision even when the original information request has been answered.

Review the remaining open items at each capital gate and identify which are acceptable for that decision. Some can be carried into detailed design; others may be essential to site selection or equipment ordering. The owner should see that distinction explicitly rather than inheriting a long list whose consequences have never been prioritized.

22. Food Plant Basis of Design FAQ