In structural engineering, the work product is not just steel and concrete—it is the documentation, drawings, models, and reports that communicate intent, safety, and constructability. These are what clients, contractors, and regulators see, review, and ultimately rely on. Yet, time and again, engineers fall into a trap: equating output with value.
The distinction is critical.
A report that stretches across 100 pages, filled with screenshots of analysis models and tables of raw output, might feel like a comprehensive deliverable. But does it provide real value? Does it empower a client to understand the assumptions, check the logic, and trust the design? Or does it simply bury the essentials under a mountain of data?
This article explores why engineering deliverables should prioritize value over volume, and how structural engineers can strike the balance between thoroughness and clarity.
Understanding Output vs. Value. Let’s start with definitions:
- Output: The raw products generated during the engineering process—software printouts, tables, meshes, analysis graphics, endless screenshots, or unfiltered calculation notes. Outputs often show what was done, but not necessarily why it matters.
- Value: The distilled, purposeful information that allows stakeholders to make informed decisions. Value lies in concise, transparent communication of design assumptions, governing cases, and final results. Value explains why the structure works and how it complies.
Think of it like cooking: listing every spoon you used (output) is not helpful. Serving the meal (value) is what matters.
The Common Pitfall: Mistaking Volume for Quality
In the age of advanced software—ETABS, SAP2000, SAFE, Tekla Structural Designer, or Revit—it has become too easy to generate massive amounts of analysis data. Many engineers, especially early in their careers, are tempted to export entire sets of analysis outputs directly into design reports.
The reasoning is often:
- “If I include everything, no one can say I missed something.”
- “More pages must mean more thorough work.”
- “The client will be impressed by the volume.”
But in reality:
- Reviewers rarely have the time (or patience) to sift through pages of unedited outputs.
- Clients are not paying for raw data—they want actionable clarity.
- Regulators and independent checkers need transparent traceability, not software manuals.
Excessive, unfocused reporting does not protect the engineer—it dilutes the message and makes it harder to demonstrate competence.
What True Value Looks Like in Structural Deliverables
Value emerges when deliverables are focused, clear, and decision-oriented. A strong structural design report, for example, should not be a copy-paste of software runs. Instead, it should:
- Define the Basis of Design
- State applicable codes and standards (Eurocode, ASCE 7, AISC 360, IBC, SANS 10160).
- Outline assumptions: importance category, site class, exposure category.
- Clarify design life and reliability criteria.
- Summarize Loads and Combinations
- Present input parameters clearly: dead, live, wind, seismic, snow, temperature.
- List governing load combinations per the relevant standard (e.g., EN 1990 §6.4.3; ASCE 7-16 §2.3.2; SANS 10160-1 §6).
- Provide reasoning for worst-case selection.
- Explain the Structural System
- Brief narrative of frames, slabs, foundations, and lateral systems.
- Diagrams or simplified sketches showing load paths.
- Show Key Results
- Member demand vs. capacity checks.
- Deflection and drift summaries.
- Punching shear, stability checks, and robustness compliance.
- Address Connections
- Connection design outputs are often overlooked but critical.
- Include moment/axial/shear capacities for key joints.
- Highlight constructability considerations.
- Draw Rational Conclusions
- State compliance with governing codes.
- Provide notes on serviceability and durability.
- Identify any assumptions that require verification during construction.
By presenting information this way, a design report becomes more than a box-ticking exercise—it becomes a decision-making tool.
A Tale of Two Reports
To illustrate, let’s compare two approaches to a structural design report for a data centre project:
- Report A (Output-driven)
- 120 pages.
- 60 pages of finite element mesh screenshots.
- Endless printouts of member forces, unfiltered.
- No clear indication of governing combinations.
- Little to no discussion of connections or assumptions.
- Report B (Value-driven)
- 35 pages.
- Concise summary of design codes, load assumptions, and combinations.
- Clear tables comparing demand vs. capacity for major members.
- Appendices with detailed checks for traceability.
- Cross-references to drawings for constructability.
Report B is shorter, but infinitely more valuable.
Why Value Matters to Different Stakeholders
Different readers interact with deliverables in different ways. By focusing on value, engineers can meet everyone’s needs more effectively:
- Clients
- Want assurance the design is safe, compliant, and cost-effective.
- Value clear executive summaries and logical traceability.
- Contractors
- Need constructible, buildable details.
- Value clarity in loads, tolerances, and connection requirements.
- Regulators / Independent Checkers
- Need transparency to confirm compliance with design codes.
- Value structured inputs, clear governing cases, and rational conclusions.
- Design Teams (MEP, Architecture)
- Need coordination information: slab penetrations, loading allowances, secondary steel requirements.
- Value clarity over raw output.
Codes of Practice and Their Implicit Expectation
Design standards themselves emphasize value over raw output:
- Eurocode EN 1990: Basis of Structural Design requires clear identification of load actions and verification against ultimate and serviceability limit states (§6.4). It doesn’t ask for software manuals—it asks for transparent reasoning.
- ASCE 7-16 (§1.4) emphasizes establishing minimum loads “for the safe and economical design” of structures. Again, clarity of assumptions is critical, not a flood of unfiltered outputs.
- AISC 360-16, Appendix 1 specifically calls for verification of member stability and connection integrity. AISC design guides also encourage concise but traceable presentation.
- IBC 2021, Chapter 16 focuses on structural integrity through proper documentation of load combinations, not on excessive reporting.
- SANS 10160 (South Africa), particularly Part 1 (Basis of Structural Design and Actions for Buildings and Industrial Structures), requires that reliability differentiation, load factors, and combinations are clearly documented (§6.2). It is explicit that design outputs must demonstrate adequacy against ultimate and serviceability limit states—not bury the logic in volume.
These codes reinforce the idea that engineers are responsible for communicating assumptions, governing cases, and compliance—not drowning stakeholders in data.
Practical Strategies for Shifting from Output to Value
Engineers and firms can take several steps to ensure their deliverables are value-driven:
- Start with the Audience in Mind
- Write reports for humans, not for software.
- Ask: “What does my client, contractor, or regulator actually need to know?”
- Use Layered Communication
- Executive summary for decision-makers.
- Main body for key design checks.
- Appendices for detailed calculations.
- Integrate Visuals and Tables
- Use charts to summarize demand vs. capacity.
- Show load paths with diagrams.
- Replace raw dumps with concise summaries.
- Standardize Templates
- Develop firm-wide templates that prioritize clarity.
- Include mandatory sections for inputs, assumptions, and governing results.
- Audit Deliverables Internally
- Peer review reports not just for technical correctness but for clarity and value.
- Ask reviewers: “Can you follow the logic without external explanation?”
Case Example: Connection Design as a Litmus Test
One of the most common weaknesses in design reports is omission of connection design. Many engineers assume that connection design will be left to fabricators or deferred to later stages.
But failing to include connection checks undermines value because:
- Connections often govern constructability.
- They influence member sizing (moment vs. shear connections).
- They affect costs significantly.
For example:
- An output-driven report might simply state, “Connections designed using software package X, see Appendix.”
- A value-driven report would present, “Moment connections at gridlines 3-5 sized for 120 kNm capacity with 4 M20 bolts, per EN 1993-1-8 and SANS 10162-1. See drawing S-302 for details.”
The second approach directly supports design understanding and constructability.
The Risk of Overlooking Value
Producing output-heavy deliverables carries risks:
- Delays: Reviewers take longer, RFIs multiply.
- Miscommunication: Contractors misinterpret vague data.
- Loss of Trust: Clients perceive poor communication as poor engineering.
- Legal Exposure: In disputes, unfiltered outputs can be used against engineers, whereas clear reasoning protects intent.
Value-driven reporting, by contrast, mitigates these risks and strengthens professional credibility.
The Future: Digital Deliverables and BIM
As BIM and digital twins become standard, the question of output vs. value will only grow more relevant.
- Navisworks or Revit models can be flooded with unneeded detail (every bolt modeled), or streamlined for coordination (penetrations, loads, clearances).
- IFC models can contain all reinforcement, or only critical placement logic.
- Digital reports can embed hyperlinks for deeper detail rather than overwhelming the main text.
The future of engineering deliverables lies in clarity through digital layering – where stakeholders access as much detail as they need, but only when they need it.
Conclusion
Engineering deliverables should not be judged by weight or page count. They should be judged by their ability to:
- Communicate assumptions transparently.
- Demonstrate compliance with codes.
- Provide clarity to contractors.
- Inspire confidence in clients.
A structural design report that focuses on inputs, governing load combinations, calculation summaries, and connection design – rather than drowning readers in software screenshots—delivers true value.
At its core, the principle is simple: outputs are data, value is clarity.
Engineers who prioritize value in their deliverables not only serve their clients better but also protect themselves professionally, streamline construction, and uphold the reputation of the profession.
