12.7 Style Recommendations

12.7 Style Recommendations

During the preparation of the course project, you will have to deal with two types of technical writing, which will be principally different in style, purpose, and content.

Type 1: Technical Report

This type involves articulation of comprehensive technical information on an issue, technology, or application. The style is more of a technical paper with lots of details and graphical material, references, and the scope will be rather broad. The purpose of technical reports is to collect versatile information on an issue in one place, present it logically and fully, and make it available for further use by scientists, engineers, government representatives, businessmen, entrepreneurs, the public, and other interested parties. Technical reports may present really large volumes of information from multiple sources, and typically, the broader the view, and the more different aspects and angles of the subject matter are discussed, the better! Technical reports are extremely useful when you try to research and learn as much as possible about a specific topic. The examples of technical reports are commonly available (free or for a charge) on the websites of Government agencies such as DOE, NREL, EPA, etc. [EXAMPLE Technical Report], and many commercial companies also produce such reports for their internal R&D efforts.

Type 2: Project Proposal

This type of writing should include ONLY the information that justifies the implementation of the proposed idea. The style will be geared towards a reader – a client, a reviewer, an authority, an investor, a committee, or the public – anyone who would have to make a go/no-go decision on the project. Here, any technical excursions should be articulated in a way to convince the client of the project idea (not to confuse them) or to justify an investment. The primary purpose of this kind of writing should be to deliver the idea clearly, quickly, and in the most compelling way. That would not mean the most comprehensive or most scientific way, but rather via the structure and narrative most accessible and appealing to a particular "client." In this case, including more information is not always good and can even be bad in terms of clarity and focus of your narrative. For project proposals (even in scientific and academic fields), the technical justification is much more compact, and more effort is spent on highlighting the competencies and capabilities of the proposer, and justification of expected outcomes. The language in a proposal is usually geared towards a broader audience, with fewer area-specific terms and slang, to make sure the message is understandable to a wide range of stakeholders.

These two types of writing can be parts of the same investigation. For example, a technical report can be prepared to justify project development and investigate technology alternatives. At the same time, the project proposal will deal with narrowing down the focus and transferring the knowledge into the implementation stage.

These two types of writing should not be mixed up, though. If you are writing a technical report, you are dealing with a broad variety of factual data and need to make sure that every description or key statement has justification and references. You can go broad and deep without yet knowing which of that information will be ultimately needed. You do not have to convince anyone of anything, but rather build a resource and sometimes provide objective recommendations based on your research. On the contrary, if you are writing a project proposal, you should focus on the client and how they would read it and understand your information. If you overload them with technicalities and present ALL of your great research, chances are they will lose focus and will not appreciate the idea you are trying to deliver in the long run. Here, a concise and compelling presentation most often wins over a sophisticated and scientific one. If there is information that is interesting and relevant to the topic but does not directly “sell” your ideas to the client, maybe it’d rather be omitted not to become a distraction. Sometimes less is more, but you need to make a careful call here not to become too plain and too simplistic in your message, either.

Your Technical Review should be prepared in the style of a technical report (Type 1). You should feel free to collect any information that helps you to learn the topic and present the key findings without reservation. However, the Technical Review will only serve as a resource, an informational depository for the project proposal to pull data from, and in no way should it be presented as an organic chapter in the final proposal as is.

Your Final Proposal should be prepared in the Type 2 style, obviously. The assessment you perform should not be just a class exercise, but rather should justify the project implementation in the specific societal context. Introduction and Conclusion sections should speak of that purpose in particular, since, as you know, most proposal reviewers with their busy schedules will read those sections first and then see if they want to go on and read the rest.

Use of Graphics

Use of graphic information, such as images, plots, maps, schematics, charts, tables, etc. is highly encouraged. I agree with a common statement that often a picture is worth a thousand words. Representation of your findings or background information in the figure helps organize it, summarize it, and to make it an easier reference. Also, it increases the credibility of your proposal and makes it easier to read, especially since most of us are visual learners.

However, there are a few things about figures to keep in mind. First, please be sure that the graphics you present are indeed relevant and actually serve the purpose of making your message clearer rather than vague. Pictures should not be just placeholders (they can be on a website, but not in a technical proposal) – they need to have a good load of useful information. Second, quality is essential. Nothing irritates the reader more than a copy/pasted blurry image with a barely readable font. If you cannot get a good-quality image to use, better include none. Third, provide a caption. Ideally, the figure in a technical document should be readable independently of the text, at least at first approximation, so provide a short but informative title under the image of what it is that you are showing. And also if you include it, the text narrative should refer to it and use it in the story. The same tips go for tables.

A few words about image credits. These days, millions of pictures are available from the internet, and they are easy to borrow. Many of those images you find are in fact subject to copyright, meaning that you cannot use them publicly without permission. This is important to keep in mind if you think of publishing or distributing your work in any way. So I recommend two things:

• Create your own graphics – it is fun and makes you better understand the information you present (and you also earn extra credit for this in the final proposal!).
• Provide credit for any borrowed graphics in your reports (this should include the author/organization that owns the image and URL you got it from). In case your report ever goes public, you will be able to track it back to the source and work out any permissions you need.

Page limit and formatting

Please follow these format requirements when preparing your final document for submission: 

• Font: size 12 pt / any professional font of your choice
• Spacing: at least 1.5 (except for reference list)
• Page limit: 20 including graphics and references (over-limit papers will be returned for re-formatting)
• Title page (including project title, author's name, year, SDG icons for the goals addressed)
• Figures and Tables should be numerated for easy reference.
• Figure captions: under the figure / Table captions: above the table.