The abstract and executive summary are key components because they allow readers to quickly decide whether or not they need / want to read the entire document. Audiences use these summaries to determine:
- Whether or not the document is relevant
- What the main conclusions of the document are
What they share: is this specific role in the document, content, and general structure:
- These summaries are both stand-alone documents, meaning that they should be thought of as being independent from the report. In other words, the readers of your summary may not read the report; it also means that the readers of the report may not have read your summary. Practically speaking, this means that the documents are purely summary: they should not contain any information that is not in the report. However, you should not cut and paste from your report; some readers will read both, and will recognize copied sentences.
- They should contain all key elements of the report. Given the generic structure of an engineering research paper (See Online Handbook/Accurate Documentation / Conducting & Understanding Secondary Research in Engineering), this would typically include:
- Situation: provide context information
- Problem: define the problem that the paper addresses
- Solution: describe the solution – its key characteristics, fundamental principles, and how it solves the problem
- Evaluation: evaluate how well solution solves problem
- Recommendations: give suggestions for future work or implementation
Where they differ: is primarily in audience, which translates to differences in focus, level of discourse, and length.
- The audience for an executive summary is precisely what the name indicates – executives and managers; the audience for the abstract is usually a more technical reader. A design report may include an executive summary aimed at your boss, who may need to decide whether or not to use your design, and also an abstract for your peers or other engineers who may need to thoroughly understand the design.
- As audience changes, the content and focus of the summary changes as well:
|Focus: Problem (especially financial aspects), Recs (esp. results of implementing)||Focus: Solution, Evaluation|
|Language: Less technical, more financial||Language: Technical, less background|
|Length: Often longer than abstract to reflect different focus, need for background and higher likelihood that readers will only read this summary||Length: Less than a page, usually one paragraph long|
(See Abstracts and Executive Summaries iWrite Site and below for examples and commentary.)
Commentary: This abstract almost demonstrates almost a sentence-component correspondence. (1) = situation, (2) = problem, (3) + (4) = solution, (5) = evaluation, (6) = recommendation.
Source: Adjusted from Crowe, 1985, cited in 
Commentary: This ES is slightly longer than the abstract above, and adds key details in the following areas:
- Problem definition: sentences (3) and (5-6) elaborate on the problem, focusing specifically on its cost.
- Recommendation: it justifies the recommendation by citing cost recovery potential and potential for post trial applications.
In essence, it provides a more detailed argument for the recommendation by identifying the monetary cost of the problem and comparing it to the solution.
It removes some details about the technology (packet switching technology – sentence 4 above) that may be foreign to non-technical readers.
 Michael Markel and Helen Holmes. Technical Writing: Situations and Strategies. Scarborough: Nelson Canada, 1994.