OE1-1.4 Technical Reports & Proposals

What this is and why it exists

Two documents look similar and do opposite jobs. A report tells someone what happened. A proposal asks them to fund what has not happened yet.

That difference in purpose drives every structural choice in this topic, and it is the thing to hold on to.

The vocabulary

• Routine report — a short, regular report on ongoing work.
• Project report — a long report recording a complete piece of work.
• Executive summary — a short standalone summary for a decision maker.
• Proposal — a document arguing for work that has not been done.
• Scope — what a proposed piece of work does and does not include.
• Deliverable — a specific thing the work will produce.
• Heading — a signpost letting a reader enter a document part way through.

The mental model

Match the document to the situation before writing anything. Writing the wrong document well is a common and expensive mistake.

A routine report is short, regular and mostly what you will actually write. It says what was done in the period, what the state is now, what is blocked and what happens next. Doing them well and quickly is a genuinely valuable skill. The way to do that is a fixed structure you reuse every time, so neither you nor the reader thinks about the shape.

A project report records a whole piece of work. Its structure is close to the technical article from the previous topic. That is worth noticing, because the same rule applies: method separate from results, and results separate from interpretation.

Style over a long document is the material from the second topic applied at length. Consistency matters far more over twenty pages than over one. The same term for the same thing. The same level of detail in comparable sections. The same voice throughout.

Structure is doing real work in a technical report, and there is a test for whether it works. A reader should be able to enter at any heading and know where they are. Nobody reads a long report from start to finish. They arrive at the section they need, from the contents or from a search, and the headings have to orient them without the preceding pages.

The executive summary is the part most read and most rushed. Write it assuming it may be the only part anyone reads, because for the person deciding it often is. It must stand alone: the question, what you found, what you recommend, and what it costs. No references to sections they have not read.

There is an argument for writing it first as a draft, even though it is finished last. If you cannot state your conclusion and recommendation in a paragraph, you may not have one yet. Finding that out before writing thirty pages is worth the discomfort.

Now proposals, and the shift in purpose changes the order of everything.

The reader of a report is learning. The reader of a proposal is deciding. So a proposal leads with what is being proposed and what it will cost, not with the background that led you to it. Background is context for a decision they are trying to make quickly.

A proposal argues rather than records. It has to establish four things. That the problem is real and worth solving, that the approach will solve it, that you can do it, and what it costs. Scope matters more than in a report, because an unstated boundary becomes an argument later. Say what is not included as clearly as what is.

Significance is worth reading with your own future in mind. For most engineers, funded work starts with one of these documents. The proposal is what gets the project approved, and a good idea without one stays an idea.

What you should now be able to explain or do

Choose the right document type for a situation. Write a routine report on a reusable structure. Structure a project report so a reader can enter at any heading. Write an executive summary that stands alone, and say why drafting it early is useful. State what a proposal must establish, and why scope needs an explicit boundary.

Check yourself