How to Write a
Good Engineering Brief

The quality of the engineering brief is the single most reliable predictor of whether a design project will run smoothly. A clear, complete brief produces a clean first-pass design that requires minor refinement. A vague, incomplete brief produces a design built on assumptions — some of which will be wrong — and a revision cycle that costs time, money and goodwill on both sides.

This is not a problem that more engineering skill solves. An experienced engineer working from a poor brief will still produce the wrong design — efficiently. The information required to produce the right design must come from the client or project owner, and the engineer cannot manufacture it from capability alone. Understanding what information matters, and how to communicate it clearly, is a skill that sits on the client side of the table as much as the engineering side.

This article is written for both engineers briefing other engineers and for non-engineers who need to commission engineering design work. The principles are the same in either case.

What a Brief Is For

An engineering brief serves two distinct purposes that are often conflated:

First: It defines the problem — what the designed system, component, or structure must do, in what environment, subject to what constraints. This is the requirements brief — the information from which the design is derived.

Second: It defines the deliverables — what the engineer is expected to produce, to what standard, by when, and for what fee. This is the commercial brief — the information from which the scope and programme are agreed.

Both are necessary. An engineering brief that defines the problem clearly but fails to specify what deliverables are expected produces excellent design work with no agreed basis for handover. A brief that specifies deliverables precisely but is vague on requirements produces agreed deliverables that may not solve the actual problem.

The Core Content — What Every Engineering Brief Needs

1. Project Description and Context

A brief paragraph explaining what the project is, what it sits within, and why it is being done. This gives the engineer the context to make sensible judgements when the brief is silent on a specific point — which it inevitably will be. An engineer who understands that a system is going into a pharmaceutical cleanroom environment will make different default decisions about material selection, finish, and accessibility than one who understands the same system is going into a waste processing plant.

Include: the end use of the designed item, the industry sector, the site or facility type, and any relevant background about existing systems it will connect to or replace.

2. Functional Requirements — What It Must Do

The functional requirements define what the designed system must achieve. They should be stated as measurable outcomes, not as descriptions of a design. For a mechanical system, functional requirements typically include:

• Process duty: Flow rates, pressures, temperatures, heat transfer rates, mixing requirements, separation requirements — whatever the system is thermodynamically or hydraulically required to achieve
• Capacity: Design throughput, peak throughput, turndown ratio if applicable
• Response time: How quickly must the system respond to demand? Relevant for heating, cooling, control systems
• Availability and uptime: Required operational hours per year, planned maintenance windows, redundancy requirements
• Output quality: Purity, temperature uniformity, pressure stability — any quality characteristic of the output that the design must achieve

3. Operating Conditions

The operating conditions define the environment in which the designed item must function. These are not optional — without them, the engineer cannot size components, select materials, or determine structural requirements. The most common brief failures involve missing or incomplete operating conditions.

For process systems and mechanical equipment, operating conditions include:

4. Design Life and Maintenance Philosophy

How long is the designed system expected to last? This is not a trivial question — a system designed for a 5-year operational life makes different material, corrosion allowance, and mechanical life decisions than one designed for 25 years. State the intended design life explicitly.

Also state the maintenance philosophy — whether the system will be maintained in-house or by a contractor, what the planned maintenance interval is, what maximum downtime for maintenance is acceptable, and whether the system must be capable of in-service maintenance (cleaning, filter change, seal replacement) without full shutdown. These requirements directly affect design decisions about access, redundancy, and component selection.

5. Physical and Spatial Constraints

The designed item must fit in the available space, connect to existing interfaces, and be installable through the available access. Spatial constraints that are not communicated in the brief become expensive discoveries during detailed design or, worse, during installation.

State: overall envelope dimensions available, floor loading limits, height restrictions (particularly relevant for vessels, overhead pipework, and tall equipment), access routes for delivery and installation (door widths, ceiling heights, crane availability), connection points for existing services (pipe sizes, connection types, flow directions), and any structural elements that cannot be penetrated or loaded.

6. Applicable Standards and Codes

State which standards and codes apply to the project. In many cases the client will not know the specific standard numbers — that is the engineer's job — but the client can and should state the regulatory framework that applies:

• Is the equipment pressure-containing? (PED/UK PER applies)
• Is it installed in a potentially explosive atmosphere? (ATEX Directive applies)
• Is it machinery? (Machinery Directive / UK Machinery Regulations apply)
• Is it in a food or pharmaceutical environment? (FDA, EHEDG, GMP requirements)
• Does the client have a preferred or mandated design standard (BP Engineering Technical Practice, Shell DEP, client specification)?
• Does the project fall under CDM?
• Are there insurance requirements specifying a particular inspection body or standard?

7. Interface Requirements

Any system connects to other systems. Interface requirements define those connections and must be agreed before design begins — because both the new design and the existing system may need modification at the interface, and discovering that the interface doesn't fit after detailed design is complete is an expensive problem.

Interfaces to define: pipe connections (size, rating, material, connection type), electrical supply (voltage, phase, frequency, available fuse rating, earthing arrangement), control system connections (signal type, protocol, integration requirements), structural connections (loads the existing structure must accept), and spatial interfaces (the three-dimensional envelope the new design must fit within at its boundary with existing equipment).

8. What Must Not Happen — Exclusions and Constraints

Stating what the design must not do is as important as stating what it must do, and is far more commonly omitted. Constraints that are obvious to the client — based on their operational experience, site history, or company preferences — are rarely obvious to an engineer approaching the project fresh.

Examples of negative requirements that should be stated explicitly:

• "No copper alloys — the process fluid causes dezincification"
• "No threaded connections on the process side — regulatory requirement"
• "No welding on site — hot work permit restriction in this area"
• "Must be capable of operation by one person — no two-person operations"
• "No glass sight glasses — site policy following a previous incident"
• "Equipment must be removable without structural modification — this is a leased building"

9. Quality, Inspection and Certification Requirements

What level of quality assurance applies? What documentation is required at project completion? These requirements directly affect cost and must be stated in the brief, not discovered at the end of the project:

• Mill certificates — 3.1 or 3.2? (see the mill certificates article)
• Hydrostatic or pneumatic test requirement, and witnessed or unwitnessed
• Non-destructive examination extent — radiography, UT, WFMT
• Third-party inspection requirement — client's own inspector, insurer's inspector, Notified/Approved Body
• ATEX certification requirements for components
• Painting and coating specification — standard or client specification
• Final documentation pack content — as-built drawings, databooks, O&M manuals, H&S file

10. Programme and Budget

When does the design need to be complete? When does the equipment need to be operational? Are there fixed milestones — a plant shutdown window, a regulatory deadline, a contractual commissioning date — that the programme must accommodate?

On budget: stating a budget in the brief is not weakness — it is information. An engineer who knows the budget is £30,000 will design differently from one who believes the budget is £100,000, and both differently from one who has no budget guidance at all. Withholding budget information to "let the engineer come in with their best price" results in proposals that may be either over-specified or under-specified relative to what was actually needed.

Stating Assumptions Explicitly

Every brief contains gaps — information that is not known, not yet decided, or simply not thought of. The worst approach is to leave those gaps silent. The better approach is to state them explicitly as assumptions: "We have assumed the system will use mains cold water at 3 bar supply pressure. Please confirm." This allows the engineer to flag incorrect assumptions before they are designed in.

Similarly, when the client makes an assumption about what the brief implies — "obviously they'll use stainless steel throughout" — that assumption should be stated. What is obvious to the client from years of operational context may not be obvious to an engineer approaching the project from outside.

The Brief Is Not a Design

A brief should not specify the design solution unless the client has a specific technical reason for that requirement. "Install a centrifugal pump with a variable speed drive" is an engineering decision — it forecloses other solutions (positive displacement pump, gravity feed, compressed air pump) that might be more appropriate. If the client's operational experience has determined that a VSD centrifugal pump is the correct choice, that is fine — but it should be stated as a preference or requirement with a reason, not as an assumed obvious choice.

A brief that over-specifies the solution removes value from the engineering engagement. The engineer's design capability — their ability to select the best solution for the stated requirements — is only exercised if the requirements are stated, not the solution.

Brief Format — How to Structure It

A brief does not need to be a lengthy formal document. On smaller projects, a structured email or a one-page document covering the ten sections above will often suffice. What matters is coverage and clarity, not length.

A suggested structure for a written brief:

1. Project title and reference
2. Background and context — one paragraph
3. Functional requirements — what the system must do
4. Operating conditions — the process and environmental parameters
5. Physical constraints — space, weight, access, interfaces
6. Standards, codes and regulatory requirements
7. Exclusions and constraints — what must not happen
8. Design life and maintenance requirements
9. Quality and certification requirements
10. Deliverables expected — drawings, calculations, documentation
11. Programme — key dates and milestones
12. Budget guidance
13. Assumptions — what has been assumed in the absence of confirmed information
14. Contact for queries — a named technical contact who can answer engineering questions during the design phase

The Brief as a Living Document

The brief is the starting point for the design, not an immutable document. As the design develops, some requirements will need clarification, some constraints will become clearer, and some assumptions will be confirmed or corrected. A good brief process includes a mechanism for capturing these changes — a revision history, agreed change control, and clarity on what changes require a revised fee or programme.

Changes to the brief after design work has begun cost more than changes made before design starts. A change in operating temperature that is communicated before a vessel is sized requires a minor calculation revision; the same change communicated after the vessel has been fabricated may require scrapping the vessel. The client who keeps the engineer informed of developing requirements throughout the design phase avoids this problem. The client who treats the brief as fixed and then introduces significant changes at the end of the process should expect a change order.

What Happens With a Poor Brief

The consequences of an inadequate brief are predictable and almost always follow the same pattern. The engineer makes assumptions to fill the gaps — typically conservative ones, because an engineer who doesn't know the operating pressure will design for the highest plausible pressure to avoid under-specification. The resulting design is over-engineered, over-priced, and may not fit the actual requirements. The client requests revisions. The engineer revises against requirements that were available from the start but not communicated. Multiple revision cycles follow. The project runs late. The relationship deteriorates.

None of this is inevitable. It is the predictable consequence of starting design work with insufficient information, and it can almost always be prevented by spending more time on the brief before instructing the engineer to begin.

Summary

A good engineering brief defines the problem — not the solution. It states the functional requirements, operating conditions, physical constraints, applicable standards, what must not happen, quality requirements, and the programme and budget context. It explicitly states assumptions. It is clear, complete, and signed off by someone with the technical and commercial authority to commit the client to the requirements it contains.

The time invested in a thorough brief is recovered many times over in avoided revisions, faster design, and a better engineering outcome. An engineer who understands exactly what is needed will design it correctly on the first pass. An engineer who is guessing will revise until they get there — at the client's cost and on the client's programme.