Technical report and proposal writing notes — Unit 3

A Technical Report is a highly structured, formal document that presents information, analysis, and recommendations regarding a specific problem, experiment, or project.

Unlike an essay, a report is designed to be scanned quickly by busy professionals (engineers, managers, clients) who need to extract specific data to make decisions.

⇒Key Rule:

A report relies strictly on facts, data, and objective analysis. It NEVER contains the author's personal feelings or unsupported opinions.

• Accuracy: All data, calculations, and facts must be 100% correct.
• Clarity: The language must be simple, direct, and unambiguous.
• Conciseness: Avoid wordiness. If a graph can explain a point better than a paragraph, use the graph.
• Logical Organization: Heavily relies on numbered headings, subheadings, and bullet points to guide the reader.
• Objectivity: Written in the third person (passive voice often preferred in methodology sections).

Reports are classified based on their purpose:

• Informational Reports: Simply present data without analysis or recommendations (e.g., Daily Progress Reports, Inventory Reports, Incident Reports).
• Analytical Reports: Present data, analyze it, draw conclusions, and make recommendations (e.g., Research Reports, Troubleshooting Reports).
• Feasibility Reports: Analyze whether a proposed project or solution is technically, financially, and legally possible before starting it.

A formal technical report is strictly divided into three major sections. No matter what the topic is, this architecture remains constant:

• 1. Front Matter (Prefatory Parts): Everything before the actual text begins (Title page, Abstract, Table of Contents). Numbered in lowercase roman numerals (i, ii, iii).
• 2. Main Body: The core text (Introduction, Methodology, Results, Conclusion). Numbered in Arabic numerals (1, 2, 3).
• 3. Back Matter (Supplementary Parts): Extra information that supports the body (References, Appendices).

⇒Title Page

Must include: The full title of the report, the name/designation of the person it is submitted TO, the name/designation of the person submitting it (the author), and the Date.

⇒Abstract / Executive Summary

The most important part of the report. It is a miniature version (about 10% the length) of the ENTIRE report. It summarizes the problem, the method used, the main findings, and the final recommendation.

⇒Table of Contents (TOC)

Lists all major headings and subheadings (exactly as they appear in the text) with their corresponding page numbers. It acts as a map for scanning.

⇒List of Figures and Tables

If the report contains more than three visual aids, a separate page is required listing them. (e.g., Figure 1: System Architecture Diagram ..... pg 12).

⇒1. Introduction

Sets the context. What is the problem? Why was this report written? What is the scope (what is included and excluded)?

⇒2. Methodology / Procedure

Explains how the data was collected or how the experiment was conducted. Was it a software simulation, a physical lab test, or a user survey?

It must be detailed enough that another engineer could replicate the exact same test to verify your results.

⇒3. Results / Findings

Pure presentation of data. This section is heavily populated with graphs, charts, and tables. Do NOT analyze the data here; just present the facts.

⇒4. Discussion / Analysis

This is where you interpret the results. Why did the software crash at 1000 users? What do the data trends mean? How does it compare to previous models? This requires critical thinking.

⇒5. Conclusions

A logical summary drawn from the discussion. No new information can be introduced here. (e.g., "The current server architecture cannot handle peak load due to insufficient RAM.")

⇒6. Recommendations

Actionable steps based on the conclusions. What should the company DO? (e.g., "Upgrade the servers from 16GB to 64GB RAM immediately.")

⇒References / Bibliography

A strictly formatted list of all external sources (books, journals, websites) you used. Prevents plagiarism. (Common formats: IEEE, APA).

⇒Appendices (Plural of Appendix)

Used for bulky supplementary material that would interrupt the flow of the main report. Examples include:

• Raw data tables (10 pages of numbers)
• Extensive mathematical proofs
• Blank survey questionnaires
• Source code listings

Writing a good report is a staged process:

• 1. Planning: Define the purpose and target audience. Gather all necessary data.
• 2. Structuring: Create an outline. Decide what goes into Intro, Body, and Conclusion.
• 3. Drafting: Write the rough draft. Do not worry about perfect grammar here; just get the facts down. (Pro tip: Write the Abstract LAST).
• 4. Revising: Fix grammar, ensure objective tone, format headings consistently.
• 5. Proofreading: Final check for typos and spelling errors.

Visual aids are mandatory in technical reports, but they must follow strict rules:

• Every visual aid must have a Number and a Title (e.g., Table 1: CPU Temperatures).
• Titles for Tables go ABOVE the table. Titles for Figures (graphs, diagrams, photos) go BELOW the figure.
• Every visual aid MUST be explicitly referred to in the text. (e.g., "As shown in Figure 2, the voltage spiked..."). Never drop a graph into a report without discussing it.

A Proposal is a persuasive document designed to convince a reader to authorize or fund a specific project, buy a product, or hire a service.

While a report looks at the PAST (what happened), a proposal looks at the FUTURE (what we want to do).

The ultimate goal of a proposal is to get the reader to say "YES" and sign a check or a contract.

• Internal Proposal: Written to someone within your own organization (e.g., proposing a new software tool to your manager). Usually shorter and less formal.
• External Proposal: Written to an outside client or government agency. Highly formal and legally binding.
• Solicited Proposal: The client asked for it (usually by issuing an RFP - Request for Proposal). You know exactly what they want.
• Unsolicited Proposal: You initiate the proposal without being asked. Extremely difficult to win, as you must first convince them they have a problem before offering a solution.

A standard proposal follows this logical flow:

⇒1. Problem Statement / Background

Demonstrates that you clearly understand the client's problem. (e.g., "Your current database architecture is causing 5-second lag times during peak hours.")

⇒2. Objectives

What exactly will this project achieve? Must be measurable. (e.g., "To migrate the database to AWS and reduce query time to under 100ms.")

⇒3. Methodology / Technical Approach

HOW you plan to solve the problem. What technologies, frameworks, and processes will you use? This proves you have the technical competence to do the job.

⇒4. Timeline / Schedule

A step-by-step breakdown of when milestones will be achieved (often shown using a Gantt Chart).

⇒5. Budget / Cost Estimate

A detailed, itemized list of all costs (Hardware, Software licenses, Man-hours, Taxes). Must be highly accurate, as proposals act as contracts.

⇒6. Qualifications / Personnel

Why should they hire YOU? Brief resumes of the key engineers working on the project, highlighting past successful projects.

While proposals are persuasive, you must NOT use the language of an aggressive car salesman. Avoid emotional appeals.

• Bad Tone: "We are absolutely the best software company in the world and will magically fix your terrible database!"
• Good Tone: "Our team has 10 years of experience migrating enterprise databases, resulting in an average 40% performance increase for our clients."

Persuade with logic, facts, case studies, and guarantees, not adjectives.

⇒Unit 3 Mastery

• List the three main sections of a formal report structure.
• Why is the Executive Summary the most important part of a report?
• What is the difference between Results and Discussion?
• Where do raw data tables and code listings belong in a report?
• What is the difference between a Solicited and Unsolicited proposal?
• Contrast a Technical Report and a Technical Proposal on 3 points.