How to Write a Technical Report

What Is a Technical Report?

A technical report presents the results of an investigation, analysis, design project, or study to a defined audience — typically a supervisor, client, or regulatory body. Unlike a research paper, which is written for peer scientists, a technical report is often written for mixed audiences: engineers who need the technical detail, and managers or clients who need the conclusions and recommendations without wading through every calculation.

This dual-audience requirement shapes everything about how a technical report is written. The executive summary carries the message for decision-makers; the body provides technical depth for specialists; appendices hold the raw data and calculations.

Technical Report Structure

Section	Purpose	Audience
Title Page	Report title, authors, date, reference number	All
Executive Summary	Key findings and recommendations — standalone	Managers, clients
Table of Contents	Navigation for longer reports	All
List of Figures / Tables	Navigation for visual elements	Technical readers
Introduction	Purpose, scope, background context	All
Background / Theory	Technical context, standards, assumptions	Technical
Methodology / Approach	How the investigation was conducted	Technical
Findings / Results	Data, analysis, observations	Technical
Discussion	Interpretation, comparison to standards	Technical + Management
Conclusions	Summary of what was established	All
Recommendations	Specific actions derived from conclusions	Managers, clients
References	Standards, papers, codes cited	Technical
Appendices	Raw data, calculations, drawings, code	Technical specialists

The Executive Summary

The executive summary is the most important section of a technical report. Many readers — particularly clients and senior managers — will read only this section. It must be:

• Self-contained: readable without referring to the rest of the report
• Concise: one page maximum (200–400 words for most reports)
• Focused on outcomes: what was found and what should be done — not how
• Written last: after the rest of the report is complete

Introduction

The introduction establishes context for technical readers. It covers:

• Purpose: why the report was commissioned or the investigation was undertaken
• Scope: what is included and — crucially — what is excluded (and why)
• Background: the engineering or technical context necessary to understand the findings
• Report structure: a brief map of what each section covers

The introduction is not a summary. Do not state conclusions here. It orients the reader; the findings sections deliver the substance.

Background and Technical Theory

For academic technical reports (undergraduate/postgraduate engineering assignments), this section presents the theoretical principles underpinning the analysis. Include:

• Relevant engineering principles, equations, or models
• Applicable standards and codes (ISO, BS, ASTM, Eurocodes, IEEE standards)
• Assumptions and their justification
• Limitations of the theoretical framework used

Need help writing your technical report?

Our engineering and STEM specialists produce professional technical reports with executive summaries, full analysis, and properly formatted references.

Get Help Now →

Findings and Results

This is the technical core of the report. Present data clearly using tables and figures, and describe observations in plain language. Key rules:

• Report measured values with appropriate significant figures and units
• Express uncertainty where relevant (±tolerance, confidence intervals)
• Reference every figure and table in the text before it appears
• Report negative results and anomalies — do not suppress inconvenient data
• Use consistent notation throughout (define all symbols in a nomenclature section or on first use)

Discussion

The discussion interprets the findings in the context of the report's objectives and the applicable standards or design criteria. Key questions to address:

• Do the results meet the specification or regulatory requirement?
• Where results fall short, why — and by how much?
• What are the engineering implications of the findings?
• How do your results compare to industry benchmarks or published data?
• What uncertainties or limitations affect the interpretation?

Conclusions and Recommendations

Conclusions and recommendations are often confused. Keep them separate:

• Conclusions state what was established by the investigation. They are factual statements derived directly from the findings: "The measured fatigue life of the component at 350 MPa was 2.4 × 10⁵ cycles, 18% below the design specification."
• Recommendations state what should be done as a result. They are action-oriented and addressed to the decision-maker: "Recommendation 1: Reduce the operating stress to ≤300 MPa by redesigning the fillet radius from 2 mm to 4 mm."

Number recommendations sequentially and prioritise them where multiple actions are proposed. Each recommendation should flow clearly from a specific conclusion.

Appendices

Appendices contain material that is necessary for completeness but would disrupt the flow of the main report. Common appendix content in engineering technical reports:

• Raw data tables and measurement logs
• Full calculations and derivations (main body shows only key equations and results)
• CAD drawings, schematics, and circuit diagrams
• Software code or scripts
• Survey instruments, interview transcripts
• Product datasheets and material specifications
• Calibration certificates for instruments used

Professional Writing Style

Technical reports are written in formal, precise, impersonal language:

• Use passive voice where the actor is unimportant: "The sample was tested at 25°C" — not "we tested the sample"
• Define all acronyms on first use: "finite element analysis (FEA)"
• Use SI units unless the project specification requires otherwise; always state the unit system used
• Avoid colloquialisms and vague qualifiers ("fairly good", "very large") — use specific values
• Present tense for established facts; past tense for what you did and found

Common Mistakes

• Executive summary that summarises structure rather than findings: "Section 3 presents the results…" — instead, state the results directly
• No units on measurements: every numerical value requires a unit
• Recommendations not derived from conclusions: every recommendation must connect to a finding — no "floating" advice unsupported by the analysis
• Calculations in the body instead of appendices: put detailed working in appendices; show only key equations and final values in the body
• Missing table of contents in reports over 10 pages: longer reports must be navigable

Frequently Asked Questions

How is a technical report different from a research paper?

A research paper is written primarily for a peer scientific audience and published in a journal. A technical report is written for a specific client, organisation, or academic audience, and may or may not be published. Technical reports often include recommendations (research papers typically do not), and the executive summary is written for non-specialists in a way that a paper abstract is not.

Should I include a list of symbols or nomenclature?

Yes — for any technical report where multiple mathematical symbols are used. A nomenclature section (usually placed after the table of contents) defines every symbol used: "σ — tensile stress [MPa]". This prevents the reader from having to search back through the text to find where a symbol was defined.

How many recommendations should I make?

Three to seven is typical for most engineering reports. Fewer than three may suggest the analysis was too narrow. More than ten risks diluting the priority message and making it harder for decision-makers to act. Where many recommendations exist, group them by priority: immediate actions, medium-term, and long-term.