This document provides guidelines and suggestions on how to write an effective report at the conclusion of your project. It discusses mindset, intended audience, format and style, logistics, and specific report sections. Common pitfalls are reviewed at the end.

Except where explicitly stated these are general guidelines. We want to give you flexibility because every project is different. That said, we expect that nearly every report will contain all of the sections and content described below, though weighting of sections will vary.

The first several sections of this guide are general, and apply to the report as a whole. The remaining sections apply to specific report sections.

Mental framework for writing a successful report

Imagine you are either:

A grant-funded researcher who must report on progress made at the conclusion of a first project, with the plan of asking for continued funding to carry on the work.
A consulting company seeking a final $200k payment on an initial phase with the hope of securing follow-on work.

In either case, focus on the fact that someone has engaged you to do this work, that they have objectives of their own (developing leading-edge research in Canada, validating a new product idea), and that their impression of you depends entirely on the quality of your report. This is especially the case for grant-funded work, where you may never even meet or talk to those who review your work.

Conversely, flip the scenario and imagine that you are the client or grant funding agency and you are reading reports from several competing teams or companies. You sponsored a first small project with several different groups, but now you want to fund the best team or company for the second, much larger project. Also imagine that each of the teams managed to make the same amount of progress in the first phase, and the only differentiation is the report. What are you going to look for in a report that will strongly convince you a team is experienced enough to take on the full project?

A great report will:

Always keep the sponsor’s priorities and objectives in mind as you are “closing the loop” on the proposed project.
Demonstrate that your team has the strongest command of the fundamentals, so that the sponsor is confident you will be successful and will overcome any problems.
Communicate a large and complex topic clearly and effectively. It will break down the topic in a logical way, and provide the reader with a mental framework to follow the discussion. It won’t just pile on detail after detail, with no context or structure.
Demonstrate a chain of logical reasoning that ultimately closes the loop. How is it a chain, and how is it logical? It is a chain because there should be a connection from the original objectives, through the project execution, the design/process chosen, the results and analysis, all the way to the conclusions and recommendations for future work. It is logical because nearly everything in the report should be connected to the sponsor’s objectives and supported by your understanding of the theory or fundamentals. How is it a loop? It is a loop because it circles back to address the sponsor’s objectives and motivations - why did they sponsor the project, and how do your conclusions and recommendations support or answer these objectives, especially with respect to the next phase of work?
Be polished. It will look and sound like a professional document and the complete lack of errors, the consistent and sensible formatting, and the high quality figures will convince the reader that the team can be trusted to do independent work of a very high quality.

Who is the audience and what is the appropriate level of detail?

You will rarely write for a single audience. In your client’s company, the CEO or CTO likely approved the $500k project and will want to read a high-level summary of what has been achieved and what the conclusions and next steps are. On the other hand, the engineering team that will use your results will want details. The sections below contain additional section-specific guidelines on audience, but the following is a general guideline.

For the Executive Summary, Introduction, Background, Conclusions, and Recommendations sections, you need to communicate the broad, high-level points that all decision makers will value. You can of course communicate important technical findings, but only if they are really important and if you provide context and interpretation (“We showed that the sensor has a precision of +/- 0.03 degrees Celsius” vs “...which exceeds the client’s core goal of…”).

For the more technical parts of the report - the Discussion, etc. - assume that your audience is a combination of: your sponsor, Project Lab staff, and next year’s 459/479 class. This presents a conflict: your sponsor may be much more technically sophisticated in this area than Lab staff and future students. Here’s the solution: you do not need to provide a comprehensive explanation of every detail to fully educate a non-expert, but you must provide a chain of “stepping stones” (think Wikipedia pages) that give a technical but non-expert reader a path to reach the more detailed level. From one stepping stone to the next a non-expert technical reader should be able to see how the leap could be made (“Hmm… okay, I can see how that could work…”) though they may need to do some background reading (“I guess I’ll need to refresh my understanding of magnetization…”). If the leaps you make are too big (“Huh? How did they get to that point?”) it will be very difficult for the reader to even educate themselves to follow you.

As always, you will need to use your words/figures judiciously. Educating your reader, sharing important learnings, and justifying an optimal path forward that is aligned with their core objectives are all better than an exhaustive description of every detail or thing done.

Length

The body of your report must be less than 4,000 words. The “body” does not include the table of contents, image captions, appendices, etc.

Format, tone, polish, and voice of the report

Use page numbers. The title page through the table of figures are numbered with small Roman numerals (i, ii, iii, etc.), though the page number is not shown on the title page. From the Introduction through all appendices, the pages are numbered as 1, 2, 3… The Introduction is page 1.

Use 1.5 line spacing and 10-12 point font size. Please use a sans-serif font.

Your final report is a professional document. In many cases, your report might be the first (or only) impression people have of you and your team - it is your reputation and your brand.

Use sensible headings and subheadings which respect the structure of your project and which are clear and unambiguous (bad example: “Module 3”). You do not need to use the exact same headings that are used below, especially the second- or third-level headings. Do what is sensible for your project.

Be sure to reference anything borrowed from another source or to back up any important statements or claims with the relevant source. Include a numbered reference that links to the references section at the end of the document. Do not simply copy URLs into the body text. This is important to avoid accusations of plagiarism but also to provide your reader with the resources they may need to educate themselves.

The tone of your report should be professional. This does not mean overly formal, wordy, or flowery. Just keep it simple, direct and clear. For example, the tone of this document (the one you are reading right now) is less formal than what you should provide. It is written in an almost conversational style. Your reports should be more neutral and professional. If you can eliminate a word without sacrificing clarity, eliminate it. This document uses contractions (it’s, they’ve) and yours should not (it is, they have).

Your report should have zero spelling or grammatical errors. Please carefully read your report before submitting. Note: many of the new word processing tools (LaTeX) do a very poor job of checking grammar and spelling.

Please also watch out for ambiguous writing. When you read through your report, ask yourself, “Could this text be interpreted in more than one way?” If the answer is “yes” then you must rewrite the text to make the meaning more specific.

Try to provide a justification or motivation for some detailed discussion prior to having the discussion. Don’t write two paragraphs discussing some phenomenon or observation in detail and then finally explain why it is relevant. It is almost always better to situate this information in the broader discussion first, so the reader is motivated to pay attention. This is not the case if you are writing a suspense thriller… but you are not writing suspense thrillers.

Avoid very informal language or colloquialisms like “overkill” (excessive) or “cheap” (inexpensive) and also avoid “weasel words” like “thing”, “stuff”, “about”.

Also avoid overly wordy writing. For example:

“...communicating with the IMU to receive sensor readings” should be “reading from the IMU”

"issuing the appropriate command to the servo motors in accordance with the PID control" should be "controlling servo motors using PID control"

We do not penalize you for having fewer than 4,000 words. No fluff, please.

Use the active voice in your writing, not the passive. If you are unclear on the difference between the two, please refer to this very short article. The active voice makes it clear who or what is involved in an action and eliminates ambiguity. Passive voice writing can leave the impression that the writer is avoiding taking or assigning responsibility:

Active: “Perform the maintenance procedure on a regular basis.”

Passive: “The maintenance must be performed on a regular basis.”

A few tips on the writing process

Think about your conclusions and recommendations early, ideally long before you finish the project or run out of time. Even better, think about them during the proposal. This will ensure you get the data/results you need to draw meaningful conclusions and recommendations.
Start with a bullet-point outline and get the structure and priorities right before you have generated lots of text. It is very hard to adjust once you have a lot of content. Using bullets is the quickest way to get the flow and level of detail right, and to figure out what can/should be included in an appendix and what must be in the report. It’s also a great way to identify what would be the most impactful figures.
Spend the time (1 hour?) to make a simple “template” figure (PowerPoint, OnShape) that you can use to generate a consistent set of figures in your report.

SPECIFIC REPORT SECTIONS FOLLOW

The remainder of this document describes specific sections of the report.

Title page

Below is an image with an example of a good title page. Please follow this format closely - by this we mean make sure you include all the same content, and in roughly the same layout. Please use a smaller font; the font in the image below is oversized for readability in this image. A picture is not required, but if you have an image that is visually compelling, please include it. And remember, use a real title for your report, not the short title/code we assigned you.

Executive Summary

A decision maker (CEO, grant agency reviewer, etc.) approved and committed $500k to your project one year ago and now wants to see what was achieved. They have a million other things on their mind and it’s almost guaranteed that they have a pretty dim recollection of what this project was about. They may even have joined the firm/agency after the project started.

That’s okay: your Executive Summary will be detached from the report by the project lead and given to the decision maker. It will refresh them on the background and motivation (even including a short description of the sponsor), provide a brief summary of what was done, and state in accessible language the key conclusions and recommendations.

Key quantitative results can be concisely stated, but only if they deserve this real estate and if you put them in context. Was the project specifically focused on achieving some discrete quantifiable objective? If so, that could be mentioned as an efficient way of conveying what was achieved. But don’t list a bunch of low-level numbers and details at the expense of diluting the big takeaways.

After reading it in 60 seconds the decision maker will say, “Right, I remember why we did this. Interesting… it seems like X and Y aren’t possible, but this recommendation for investigating Z is really intriguing. I’m going to call a meeting with the project lead to see what we want to do with this.”

The Executive Summary should be self-contained and require no outside material in order to understand the above content. It is NOT an introduction to the report. It is an actionable summary of the entire project.

This is straightforward. Please make sure your headings are descriptive so that it is easy for a reader to quickly navigate to the correct section. It is extra helpful if there is synergy between the TOC, how you’ve “structured” your discussion (more later), the system level diagram, and the terminology used in the text. An example of a bad section heading is: Module 2.

Table of figures

Provide a table of figures with figure titles and their corresponding page numbers. Do not include entire figure captions in the table of figures. Ensure figure titles are meaningful and descriptive. Bad: The circuit. Good: The first version of the motor controller circuit testing apparatus.

Introduction

How to think about the Introduction

The Introduction provides context for the report by indicating its purpose (objectives), significance, scope, organization, and relevance to the sponsor of the project. This is your opportunity to demonstrate that your team has a broad understanding of the project: you know who the sponsor is, what they care about, why they are doing this project, how this project compares to the state-of-the-art, etc. It is also an opportunity to clearly define the scope - what the project did and did not include.

Information about the sponsor

This can be quite brief, but you should at least communicate some basic information about the sponsor. Who/what are they? Where are they? What do they do? Why are they interested in this project? You want to demonstrate that you really do understand the sponsor and their needs. Imagine being the CEO of a company reading reports from a preliminary research project completed by several firms, each of which is vying for the next phase. All else being equal, you will pick the team that conveyed an understanding of your organization’s needs and goals as they are more likely to head in the right direction without constant check-ins.

Background and significance of the project

This is also your opportunity to demonstrate your knowledge of the field. What is the state-of-the-art? What are surrounding technologies, products, methods, or processes that are relevant to consider? What are important reference papers that an interested reader can refer to? How does this undertaking differ from existing or previous efforts, and why was this project conducted? The answer to this may not be terribly satisfying (The sponsor couldn’t find a testing jig that is cheap enough, or that fit their particular part…). That’s okay. Again, if you were reviewing these reports, you would pick the team that is aware of the broader picture, competitors, previous work, etc.

Statement of the problem and project objectives

It is good practice to restate the problem and the project objectives from time to time to correct for project drift and scope creep. Doing this near the start of a report reminds the reader of what the project attempted to do. If you do not clearly state the problem before you start describing the solution, your audience may have a different problem in their head while reading your report and they will start to get frustrated: “Why don’t they talk about X?!” vs “Oh, right, yeah, we decided not to do that.” For research projects, keep the previous paragraph in mind: is there a knowledge or innovation deficit that is being addressed?

Scope and limitations

Similar to the above, this is your chance to fully specify what your project does and does not include. If your project changed directions significantly, this is a good chance to discuss, briefly and at a high level, how and why it changed, especially if you had to reduce the scope. This sets the reader’s expectations right at the start and avoids confusion and frustration. Many of the people who read/viewed your proposal may not have had any updates since the start of the project.

Note that this is not meant to be a detailed explanation of the project or the pivots - these will come in the Discussion. You are merely informing readers of high level scope and setting expectations for the report.

Discussion

How to think about the Discussion

This is the body of the report where evidence and arguments on the subject material are developed in a structured and logical manner. While the Executive Summary and Introduction were high-level, less-detailed, and written for a more general audience, the Discussion section is written with a more technical audience in mind.

Each subheading (Theory, Design, Tests) requires a separate subsection in the Discussion. However, since every project will have a different focus, not every report will contain all of these subsections. Use these as a general guideline to see how your project work can be grouped together in written form to provide a logical description of the project, methods, and results.

Before discussing the separate subsections, three further comments on structure, reasoning and required content are needed.

Structure your Discussion

You will be conveying a lot of technical information in a small amount of text. This information has many “dimensions” and you will need to think carefully about how you present it so that the reader is able to follow your thought process. A bad report will dive straight into the details, and then churn through the whole project at a detailed level. This causes two major problems: 1) it is exhausting for the reader because the material is detailed, (seemingly) endless, and has no context, and 2) they will have to construct their own “mental map” of how everything fits together, which can lead to confusion.

A good report will communicate to the reader how the project can be broken down into a logical structure. The report will then move through this structure in a logical way, without losing the reader. For example, your report might first break down your algorithm or design into major functional requirements or subsystems. Perhaps you’ll start by identifying each of these subsystems, and provide a high-level explanation of how they work together. Then you might dive into each subsystem in turn, discussing the details, before backing out to a higher level and moving to the next subsystem.

One way to think about this is to imagine minimizing the amount of RAM (random access memory) that the reader needs in order to follow along. Do you feed them detail after detail after detail, and they must hold all of these details in their mind and then try to piece them together into an overall picture? Or do you give them a structure for the whole project, so that they can organize all of the details in sensible relation to each other and then dedicate all their RAM to one subsystem at a time?

Demonstrate a chain of logical reasoning

Aside from some possible general interest or background information in your Introduction, everything in your report should be tied into a “chain of logical reasoning.” What does this mean? You are engineers, and you’ve been engaged to solve a problem. So, everything you present should in some way be connected to the sponsor’s objectives and supported by logical reasoning based on your understanding of the engineering or theoretical fundamentals (see next section) of the project. In terms of testing: What was it you were trying to test and why? How does this meet the sponsor’s objectives, and what is it about the fundamentals of this process that led you to test in this regime? Hopefully you can see how these connections form the previously-mentioned loop.

Another consideration is to clearly state any important takeaways or conclusions. You will do this explicitly in the Conclusions section for major takeaways, but while you are discussing your project outcomes you will likely close-out many detailed discussions with a concluding statement or concluding remark before moving on to the next topic. If there is a point to be made, make it clearly so that the reader knows what they are supposed to take away from the discussion and how it impacts the bigger picture or the overall project at a higher level (“These results demonstrate that…” or, “Therefore it was not possible to…” or, “Which then meant that we had to add X functionality to subsystem Y...”). Maybe they agree with you or maybe they don’t, but at least you have stated your findings in an unambiguous way.

Use figures and diagrams to communicate visually

A good figure or diagram is always worth at least a thousand words.

For some projects, it is very helpful to include a system level diagram that shows the major functional components, how they relate to each other, major inputs and outputs, etc. Ideally the system level diagram will map onto the report structure in a sensible way, with consistent labels.

For other projects, a sequence of images can convey a sequential, mechanistic process in an intuitive way.

Use clear and intuitive tables and charts to explain relationships and to communicate results. Focus on facilitating easy analysis and comparison. Make tables consistent, keep axes at the same scale, etc. Don’t require your readers to store data in their RAM for analysis.

Invest a (relatively) small amount of time in generating a small number of core figures or simple CAD models that will allow you to generate a range of useful figures for the rest of your report.

Refer to the separate figure guidelines for substantial further guidance on making quality figures and on avoiding common pitfalls.

Theory (or Fundamentals)

This section will be a core part of the foundation of many project reports. You need to demonstrate that you understand the fundamentals of how the problem and the solution work. As mentioned at the beginning of this document, a comprehensive review and derivation of all of the theory is not required. But you should review the critical aspects that are necessary to support a full discussion. If sections of this review can easily be carved out and included in an appendix without compromising the flow or readability of the document, then move them to the appendix (for example, lengthy calculations or derivations). If you are concerned about the correct level of detail (elementary vs. expert), start at the more elementary end but move quickly to the more expert level leaving “stepping stones” along the way so that a technical but non-expert reader can follow your path (They know which terms to Google or which Wikipedia pages to read!). Try to make your Discussion accessible to your sponsor, Lab staff, and future 459/479 students.

Design, approach, method, etc.

This is where you will describe what you actually did or built, and it is likely the biggest section of most reports. This section will vary widely between different projects, but all teams should start by asking themselves, “Who is my audience, and what is the most useful information to convey to them?” The suggested audience in this case is a combination of: your sponsor, an engineer in their organization who will continue the work, and future 459/479 students. In terms of what is useful to convey, the most critical pieces of information are:

Non-obvious and impactful learnings that you uncovered during the project (learnings that could take a future person several months to discover for themselves)
Critical decisions that you made and why you made them, including, if relevant, alternatives that were not pursued
Important tradeoffs, relationships, and limitations that you identified
Negative as well as positive results, so that your sponsor doesn’t pursue an idea that you know won’t work
The most critical or nuanced design details that are the least obvious or have the greatest potential impact on performance - if you designed a helicopter, for example, you’d probably talk about this part in detail, even if it meant foregoing any mention of the choice of upholstery for the seats

If all you do is describe your design, your sponsor or a future group would (possibly) be able to replicate your system or process. But what would happen if they tried to continue the work? Would they pick a direction that you already know won’t work because they weren’t present when you realized that direction was flawed? You don’t need to exhaustively describe every step, every learning, and every test that didn’t work. Focus on the major findings that built up your insight.

In your Deliverables you will hopefully include detailed designs, protocols, manuals, and other documentation - there is no need to repeat this information in the Discussion unless it is necessary to support the primary findings. For example, code snippets are rarely useful, unless the success of your project was enabled by some really novel syntax. If you’ve designed a really complex mixed-signal PCB for a SQUID, however, and the key challenge was mitigating noise, you would be remiss not to include an image of the ground plane pours.

Lastly, if you feel there is a large number of useful but perhaps low-level details that the sponsor would like to know, but that take up a lot of text and aren’t required for a high-level understanding of the Discussion, you can place these in an appendix - “For a more detailed discussion of X please refer to…”

Tests, results, and discussion of results

Testing and validation rarely get the attention they deserve. This section is where you demonstrate, in no uncertain terms, what you have achieved. If you become an academic research scientist, this will likely be the most critical and heavily-scrutinized part of any future report or paper that you will write. The same is true in industry. You will be finishing a contract, asking for a final payment, and hopefully you have clearly specified performance objectives and the tests that will be conducted to demonstrate whether or not you have met them.

Per the discussion on logical reasoning above, take care to justify why the tests you performed were the most appropriate tests to demonstrate the performance of your system against the sponsor’s objectives. Your tests should be motivated by some initial requirement, they should be informed by your understanding of the theory and fundamentals, and the analysis and conclusions should stand up to scrutiny. How meaningful are the results? Could they be interpreted in any other way? How variable are the results, and what are potential sources of variability? What was/wasn’t controlled? How well do your tests represent the real operating conditions or relevant range for your system, process, or phenomenon? Please think about this last question carefully as it really captures the purpose of testing. Too many tests in 459/479 reports can basically be described as, “We turned it on, here’s a plot of it running.”

What is the result of a test? It is not sufficient to simply present the data and then carry on. Is the measured performance acceptable or not? What does the data mean? You do not want your audience to guess. You need to interpret the results and provide context. Readers may challenge your interpretation, and you may need to defend it, but this is better than leaving them to guess.

Think carefully about how to most effectively communicate the results, especially with respect to tables and graphs. Do you provide several different graphs (requires lots of RAM from the reader), or do you plot multiple data series on one graph for easy comparison? Are axis scales identical for inter-graph comparison? Do you write out all of your experimental details in crowded and confusing paragraphs (lots of RAM required!) or do you summarize your experiments, their parameters, and the results, in convenient tables for rapid and easy comparison?

Finally, don’t just drop results into the report without any context. Here’s a bad example: “The optimal sampling frequency was found to be 16 kHz.” Why? How? What makes it optimal?

Conclusions

What was the original motivation for doing the project? What were the objectives? What did the sponsor want? The Conclusions section is how you close the chain/loop of logical reasoning for the whole project by providing a high level interpretation of the results to answer the original objectives. You are communicating to the reader:

The most important results, insights, or relationships (whether positive or negative) and what they mean for the project goals
What issues or risks remain, or what new issues or risks appeared

Your conclusions must be firmly supported by your results (the chain of logical reasoning) and they should prepare the reader for the recommendations that follow. Note: the conclusions are NOT a summary of the work that was done (a common issue in previous reports).

Again, imagine being the client CEO reading the report. Did you pay these contractors $500k to just do a bunch of work and generate a bunch of data that you have to interpret? More likely you thought you were getting an expert who would help you understand and interpret the results and make decisions to continue moving toward your goals (or to decisively cancel the project).

Recommendations

So, what now? In a few years, when you are an expert in your field and you are consulting for $200/hr, you will conclude your projects by providing extremely valuable insights and directions for future work based on the thorough investigation you conducted during your project. Or, as a researcher, you will spot the most promising future direction for your research team and you will be able to communicate a clear plan for moving forward.

Lacklustre recommendations simply describe how to get your prototype working, or how to make fairly low-level improvements and modifications. Blockbuster recommendations provide the sponsor with valuable and actionable insights on the next stage of work. Some examples include:

New or remaining major risks that still threaten the viability of the project or the sponsor’s objectives
Further priorities and directions of investigation to continue the de-risking and development process
New opportunities that may be relevant to the sponsor’s objectives
Relevant and interesting new phenomena or questions that deserve investigation
Suggestions of how the sponsor could improve peripheral project elements to support the project (for example, improve/standardize future data collection to avoid having a messy/useless database)

Take care to describe each recommendation as a separate, actionable item. Here’s one way to think about how good recommendations might be utilized: the project manager reading your report will basically cut and paste each recommendation into a management meeting slide deck and then propose these recommendations to senior management to ask for further resources and support. You want to make their job as easy as possible because you are the most likely candidate for receiving those resources.

Finally, we want to give you flexibility to structure your report in the way that best suits your project, but it’s difficult to imagine how recommendations can sensible precede conclusions.

Deliverables

If you were to hand off your project to your sponsor by giving to them a cardboard box that contained ALL of your deliverables, what would be in that box? Obviously we’re not in 1995 and a significant part of many projects will be purely digital and conveyed through the cloud (Github, etc.), but the point of this section is to provide a clear and concise numbered list of everything that you will provide to the sponsor. If you had signed a contract, the contract would have an appendix or schedule of deliverables and you would deliver against that list. If there are significant discrepancies between the final deliverables and those that were described in the proposal, provide a brief explanation of the discrepancy.

Appendices

Appendices contain useful supplementary information that is not required to understand the core text. A rule of thumb is that if the reader has to constantly refer to the appendices to understand the core text, the report needs to be restructured.

Examples of material that should be included in the report:

List of technical resources and individuals consulted during the project
Complete data or complex calculations that would interrupt the report but that the reader may need in order to verify your conclusions
Software code
Mechanical drawings of key components, electrical schematics, flow charts, etc.
Bill of materials (itemized list of components and their cost) for the project
User manuals

General guidelines for Appendices:

Treat each Appendix as if it were a main heading in the report: begin each Appendix on a new page with the heading “Appendix.”
If you have more than one appendix, begin each one on a separate page and use A, B, C, and so on to distinguish them.
Figure and Table numbering should appear as if it were the next one in the body. For example, if the last illustration in the body is Figure 7, then the first one in an appendix will be Figure 8.
Number the appendix pages just as you do those in the body, beginning with the page after the Conclusion and Recommendations.

References

As with the Table of Contents, this should be straightforward. Follow a consistent style when citing references. It is critical that your reader be able to retrieve the information you reference.

A common reference style in the sciences is the American Psychological Association (APA) style. This is a good starting point but can be modified (for example, to include reference numbers in the main text rather than a full citation - “Beckett, 1995”).

The most important point, however, is that you provide references to back up important claims and to give credit for ideas or materials (especially images) that you have used.

Common pitfalls

The list below is an accumulation of notes gathered while reviewing previous reports. The above guidelines were written with all of these issues in mind, but these may be useful as a quick recap:

The report is a long list of exhausting details, with no ‘mental map’ or structure provided first. Reading it is a slog, and the reader lacks context for what they are reading. Provide the mental map first. Some examples:

Describe the background, motivation, theory, etc. before getting into the details of your method or design.
Introduce all of the major components and subsystems and how they relate to each other before diving into the details of each component.
Place your system level diagram early in the report, before you discuss all the details.

The conclusions are not useful, impactful, or actionable, or they are simply a long list of what was done in the project. You need to state clearly what you are concluding from the work you’ve completed, and what your results mean. You are not simply telling the sponsor that you did some work. Consider the utility and impact of the following skeleton examples:

It works and we are done.
It doesn't work yet, we're not done, but we feel we have de-risked things sufficiently to claim that it is possible and only more engineering is required to make the method fully operational.
It doesn't work yet, we're not done, we can't state conclusively whether it will or will not work - we just don’t know enough yet.
It doesn't work and we're confident that because of the fundamental issues described herein it won't work and this path should be abandoned.

The conclusions are too bold and are not supported by the data and results. Make sure your conclusions are reasonable and appropriate.
The Executive Summary is simply a summary of what was done in the project.
The tests performed did not seem to be well thought out. Instead of being a carefully-planned examination of the system’s ability to perform under a range of operating conditions representing the expected operating environment, they are simply a demonstration of some of the features implemented.
The sequence of information makes the flow of the report awkward. For example, for every paragraph, think whether you provided the reader the framework onto which they can integrate the new information you are about to present. Don’t provide the rationale/motivation for a certain test or design decision after the paragraph in which the test or decision was discussed. Don’t provide the results of a test before describing the purpose and method of the test.
Data is not presented in a fashion that makes understanding and comparison simple. Instead, the reader has to piece the information together, try to map one plot onto another, or compare data in their head. For example, make the vertical and horizontal axes of plots cover the same range if you want the reader to compare the data. Present data or key information in a tabular format for easy comparison. If you just list things out the reader will have to store everything in their limited RAM for comparison.
The report contains vague or general statements: “The performance of the system should be improved.” If it’s not possible to provide quantitative statements, provide specific and technical qualitative statements about what improvement means.
The report leaps into complexity, detail, or advanced material too quickly, and does not provide the reader any sort of trail to allow them to follow along, even if this would require educating themselves. Instead, provide “stepping stones” so that the reader can see how you progressively move from basic to more advanced discussion. You can do this by citing references, or briefly mentioning major aspects of the relevant theory and how they are connected to the project.
The report simply states or claims findings or judgements without educating the reader or sharing any knowledge supporting the claim or judgement. For example, “The optimal sampling frequency was found to be 16 kHz…” Why was this optimal? Educate the reader.
The voice and tense of the report are incorrect or inconsistent.
The tone of the writing is too informal and is not suitable for professional communication.
The formatting is unclear or inconsistent.
The Report contains lots of Arbitrary Capitalization.
The report is unnecessarily wordy or the language is overly formal and flowery. “...communicating with the IMU to receive sensor readings…” vs. “...reads IMU data…”
Acronyms are not explained on first use.
Jargon is not explained.
The report contains colloquialisms or informal and imprecise language not suitable in a technical documents. Some examples from previous reports are below:

“Overkill” vs. “excessive”
“Play nice with” vs. “Integrates well with”
“Huge”
“Bad”

There are several spelling and grammatical errors. Note: LaTeX and Overleaf do not appear to be very good at spell-checking.
References are not provided for key claims, ideas, or figures. This is especially true in the Background section.
Figures are presented without meaningful captions. Include enough information in an image caption to allow a user who reads just the caption to quickly understand the most important points.
Labels in figures do not match terminology in the text, or no labels are present. Always ask yourself how you can make a figure more helpful. Remember to put yourself in the shoes of an unfamiliar reader. Make it easy for them.
Graphs do not have adequate or sensible labels for series, axes titles, etc.
Graphs simply don’t make sense or don’t present meaningful information.
Graphs or figures don’t seem relevant to the discussion.
Figures in the PDF are blurry.