Effective communication is a key to being a good engineer. This is even more true in design, where there is less hard information (numbers, drawings, analyses…). How does one communicate a concept? These notes are intended to help you overcome typical difficulties in arranging and presenting material for your design projects.
Writing a report is like telling a story or explaining a mathematical derivation. It must be arranged so that each step is in order and explained well enough and with just enough (and no more) detail, so that the reader is led forward to the unavoidable conclusion of your work.
Questions to which you must have answers before writing a report are:
Your written reports should follow the same patterns as those typically found in technical papers. Find any technical paper in a reasonable journal and study it for tone, presentation, grammatical structures, and so on. You can read my own papers online; some of them are quite good that way. Some of the rules of good technical writing that I've found useful are in this page.
The most important one, however, is “be organized.” That means creating a document or a presentation that flows well from the statement of the problem, through a description of your solution, to conclusions indicating why your solution is a good one. I've found one trick that helps keep a document or presentation organized is to model it on the shape of a diamond. At its top and bottom, a diamond is very small; it only gets thick in the middle.
“Huh?” you say.
At the beginning is an abstract or summary of the work; this should be no more than 500 words (about 1 page) and should accurately describe both the problem you are solving and your solution to it. It's small, like the top of the diamond. Obviously, there's room for no details at all in the abstract.
Then comes the introduction, which lays out the background and describes the problem in detail (but ONLY the problem). You should be able to accurately describe the problem you address in your report in some detail. The introduction would also include background material intended to let the reader understand why its an important problem to solve and why a good solution would be of general benefit. Its bigger than the abstract (maybe many pages), but not as big as the body of the document.
The next section is the body of the document, which details all the things you did to reach your solution plus a detailed description of the solution. This piece can actually consist of many sections; it's up to you how you want to divide it up. This is the biggest part of the document – the middle of the diamond.
After the body is a section discussing the solution, its suitability, recommendations for future modification and improvements, problems encountered, and so on. It is smaller than then body.
Finally, there is the conclusion, which is very small. It should essentially repeat the contents of the abstract, but emphasizing the key benefits of your solution too. This is the bottom tip of the diamond.
While this is the order of the report, it is not the order in which you should write the report.
Indeed, one might even consider the very top tip of the diamond to represent the title of your report – in which case, the title would be the very last thing you write. This makes sense – the only time you're really in a good position to give your report a title is when the whole thing is finished.
Another technique for laying out your reports is to “script” it. Scripting is rather the opposite of the classical technique of note-taking.
Since many people have never been taught how to take notes, here is a quick refresher.
To script a report, you run the note-taking process backwards, starting with short items and working your way to longer descriptions.
For example, say you have written the following key point:
“The basic design/build/test cycle first advances the design state then analyses it with respect to requirements, at every systems level.”
This could be expanded into the following paragraph:
“There are two major processes in an iterative design cycle: the progression from requirements through design to a design state, and the analysis of a specified design to determine its performance relative to requirements. This design, build, test cycle can be applied both at the level of the whole spacecraft, and at the level of a single subsystem. Spacecraft studies at the conceptual level may involve one or both of these processes, depending on the goals of the study.”
When you're scripting a paper, report, or thesis, you should make sure you start with the goals – the things you want to achieve in each chapter, section, and eventually, paragraph. And using the diamond, you want to start from the middle: the body of the work. Let's look at an example. Say you've laid out your thesis to contain the following chapters.
You're going to start with the body of the thesis, Chapter 3. Say your thesis involved studying the bending characteristics of implanted rods meant to stiffen upper leg bones (femurs) to help them heal when they break. You have conducted the experiments and found that the alignment of the rod inside the bone is a primary determinant of the strength of the bone after it has healed. This is the key issue you want to address in the body of your thesis. You would lay out the sections in Chapter 3 as follows:
This has its own page.
These are the standard formating rules:
The report should be written as a technical report targetted at upper management and technical staff, not a sales or marketing tool to convince prospective customers to “buy” your product. The goal of the report is to convince your management and client that your product is worth putting into production.
The report will contain the following sections:
See writing samples for examples of actual, poorly written student texts, plus revised and improved versions for each example.
Here's an excellent example of good composition, taken from an email message of November 2012, to solicit systems engineers to participate in an online survey as part of a student's doctoral research:
For organizations that execute contracts, the ability to capture contracts is key to survival. Organizations use proposals to capture contracts. In the proposal process, systems engineering is often utilized in a number of different ways, including defining the solution that will be offered to the customer.
A survey is being performed to assess the relationships between various systems engineering factors and proposal success. The survey focuses on systems engineering activities, regardless of whether the employees performing the work have titles that include the words “systems engineer”. The results of this survey analysis will allow organizations to focus on competencies related to factors that have been empirically demonstrated to lead to proposal success.
I am a Ph.D. candidate at the University of XYZ focused on determining the most advantageous use of systems engineering in proposal management. A key part of my research contribution is a statistical analysis of the results collected by this survey. By participating in this survey, you will be contributing to identifying critical success factors for winning contracts. Once the results of this research are published, you can compare the proposal management practices within your organization to the findings of this research and identify opportunities for improvement.
Proposal efforts that result in contract awards and proposal efforts that do not result in contract awards are both of interest. If you have knowledge of multiple proposal efforts, we welcome multiple responses, one response per proposal effort.
Three 25 dollar (USD) ABC.com gift certificates will be distributed to randomly selected respondents. All information provided will be kept strictly confidential….
Here's why this is such a well-composed piece of text:
Here's a slightly more humorous reason to write carefully: you want to make sure you're saying the right thing to your audience.
Suits and ties are NOT required, but a clean, well-groomed appearance is an important part of being a professional engineer.
Make sure you stick to the time schedule. Your team will be cut off immediately if you run out of time.
The team should work together to make sure the overheads or powerpoint presentation is well-done; all team members must contribute to the preparation and delivery of the presentation.
The presentation should summarize your project in a professional and technical manner. You are NOT trying to sell your product.
Here are some hints for oral presentations:
In 2016, one MEC723 team developed a truly outstanding Google Slides presentation. You can see it here. Focus not on the design itself, but rather how it was presented:
Some links that may be of use in preparing your presentations include: