EC-15.4 The Demonstration and the Final Report

What this is and why it exists

A good project presented badly is assessed as a mediocre project. That is not unfair: convincing someone who was not there is part of the engineering.

This topic is placed last and given ten hours for a reason. Rehearsal, a fallback recording and an honest limitations section account for most of the difference in outcomes.

None of it is about presentation skill in the theatrical sense. It is about anticipating what a reader or an examiner needs and providing it.

The vocabulary

• Demonstration — showing the working result to an audience.
• Fallback — a recorded version, prepared in case the live demonstration fails.
• Limitation — a condition your result does not cover.
• Baseline — the target or comparison against which a result is judged.
• Defence — answering questions about the work, including about what you did not do.

The mental model

Plan a demonstration that survives going wrong. Rehearse it, prepare a recorded version, and know which parts can be skipped.

Equipment fails during demonstrations often enough that a plan for it is preparation rather than pessimism. A recording made the night before costs an hour and converts a catastrophe into a mild disappointment. Knowing which parts are optional means an overrunning demonstration can be shortened rather than cut off.

Present to people who were not involved, which means starting with the problem and why it matters.

Not with your architecture. An audience that does not yet know why they should care will not follow the part you are most proud of. That part is usually three levels of detail down. Two minutes of context buys attention for twenty minutes of work.

The report is structured around the original question. Problem, approach, design, results, discussion, conclusion.

Each section answers something. A section that exists because reports usually have one is a section nobody needs to read, and its presence dilutes the sections that matter. The test is to read your objective and then your conclusion and check that the second answers the first.

Results are presented so a reader can judge them, which means numbers with uncertainties, compared against the requirements they were meant to satisfy.

A result with no comparison to a target leaves a reader with no way to tell success from activity. The requirement said two hundred milliseconds; you measured one hundred and eighty, plus or minus ten. That is a result. It ran quite fast is not.

Limitations are stated by you, before anyone asks. What was not tested. What conditions were assumed. What would fail outside them.

Stating these strengthens a report. An examiner who finds a limitation you did not state will assume you did not know about it. That conclusion is worse than the limitation itself would have been.

Finally, the defence, which is more predictable than people expect. The questions actually asked are why not this approach, why not that component, and what would you do with another month.

The answers are the decision records from the design work. If you kept them, this part is reading. If you did not, it is reconstruction under pressure in front of people who are assessing you, which is the argument for keeping them.

What you should now be able to explain or do

• Plan and rehearse a demonstration, with a recorded fallback and skippable parts.
• Open a presentation with the problem rather than with your design.
• Structure a report so that each section answers something and the conclusion answers the objective.
• Present results with uncertainties against the requirements they were meant to satisfy.
• State the limitations of the work before anyone else finds them.
• Answer questions about alternatives from recorded decisions rather than from memory.

Check yourself