The final report and presentation

Two days before the final review, Farah printed the whole draft report and laid the chapters side by side on the boardroom table. Then she went through it with a red pen, looking for one thing: numbers. The contract value appeared fourteen times. It had four different values. The schedule chapter said 56 weeks, the cash flow chapter used 60, the risk chapter said 'about 14 months' and the executive summary said 'just over a year'. None of these was exactly wrong, but together they told a reviewer that the team had not read its own report. Farah spent the next evening making one table of key numbers and checking every chapter against it.

This lesson covers the twelfth deliverable: the final report and the presentation that defends it. It draws on project documentation and communication (CON-375) and on everything else in the program. A capstone is judged on its content, but also on whether a busy reader can understand it, trust it and use it. That depends on structure, consistency, clear visuals and a confident, honest presentation.

Who reads the report, and what they need

A construction management plan has several readers. An owner reviewing a proposal wants to know quickly whether the contractor understands the project, can deliver it on time and on budget, and will be good to work with. A contractor's senior manager deciding whether to bid wants the risks, the margin and the resources needed. A capstone assessor wants evidence that the team can apply what the program taught, with reasoning that can be followed. All three are busy, and all three will read the executive summary first and perhaps only.

Ruth gave the team a rule: write the report so that she could make a decision from the first two pages, check any number in under a minute, and find the detail behind any statement in the appendices. That rule shaped everything else.

Structure of the report

Each chapter should open with a short statement of what it concludes, follow with the evidence, and end with the decisions or actions that follow. Long tables, takeoff sheets and detailed schedules go to appendices, with the key results summarized in the chapter and a clear reference to where the detail sits.

Writing the executive summary

The executive summary is written last and read first. It is not an introduction. It states the answer. The Tamarack team's summary began: 'Tamarack can build Pembrook Fire Station No. 3 for a stipulated price of $13,812,567 within the town's 14-month schedule, reaching substantial performance in 56 weeks with four weeks of time contingency. Three conditions are essential: a letter of intent within days of bid evaluation so that structural steel can be released, an early order for the standby generator, and an agreed interface plan for the town's alerting and exhaust extraction vendors.' Every sentence after that supported or qualified those statements.

A good executive summary uses plain language, gives numbers with units, names the main risks and responses, and avoids jargon a council member would not know. It should be possible to read it aloud in under three minutes. Ruth's test was to hand it to someone outside the industry and ask them to explain the plan back to her.

One version of each number

Farah's red-pen exercise led to a key numbers table at the front of the report, maintained by one person, from which every chapter took its values. Tomas also wrote a short program that compared the key numbers quoted in each chapter's draft against the master table, so that last-minute edits could not introduce new inconsistencies.

# Check that every chapter quotes the same key numbers as the master table
master = {'bid': 13_812_567, 'gfa_m2': 1_740, 'weeks_plan': 56, 'weeks_base': 60,
          'contingency': 314_300, 'p80': 409_000, 'ld_per_day': 2_500}
chapters = {
    'Executive summary': {'bid': 13_812_567, 'weeks_plan': 56, 'contingency': 314_300},
    'Estimate':          {'bid': 13_812_567, 'gfa_m2': 1_740, 'contingency': 314_300},
    'Schedule':          {'weeks_plan': 56, 'weeks_base': 60, 'ld_per_day': 2_500},
    'Cash flow':         {'bid': 13_812_000, 'weeks_base': 60},
    'Risk':              {'contingency': 314_300, 'p80': 409_000, 'weeks_plan': 57},
}
problems = 0
for ch, nums in chapters.items():
    for key, val in nums.items():
        if val != master[key]:
            problems += 1
            print(f'{ch}: {key} is {val:,} but the master table says {master[key]:,}')
print('Inconsistencies found:', problems)

Cash flow: bid is 13,812,000 but the master table says 13,812,567
Risk: weeks_plan is 57 but the master table says 56
Inconsistencies found: 2

The check found two problems. The cash flow chapter had rounded the bid to thousands without saying so, and the risk chapter still quoted an earlier 57-week plan. Both were small, and both were exactly the kind of error that makes a reviewer doubt everything else.

Visuals that carry the argument

Many reviewers look at the figures before reading the text. The best capstone reports use a small number of clear visuals that each make one point: the roadmap of deliverables, the WBS, the summary network with its critical path, the bar chart of the schedule, the S-curve with cash position, the logistics plan for each phase, the hazard ranking, the risk matrix and the risk histogram. Every figure has a title and a caption that says what the reader should notice, uses the same colours for the same things throughout, and is referred to in the text. Screenshots of software that cannot be read at page size do not count as visuals.

Producing the document

Production takes longer than teams expect. The Tamarack team set its internal deadline five working days before the submission date and used those days for assembly, checking and printing. One person owned the master document and merged chapters; nobody else edited it directly in the final week. Every figure was checked at the size it would be printed or projected. Page numbers, a table of contents, numbered figures and tables, and cross-references that pointed to the right appendix were all checked by someone who had not written the chapter. A list of abbreviations went at the front, because a reader who stumbles over 'ITP', 'SPI' and 'MOP' in the same paragraph stops trusting the writer. Finally, every source used, from code clauses to cost data, was cited, and permission to use any real project's documents was stated in the introduction.

Planning the presentation

The final presentation is usually 20 to 30 minutes, followed by questions. It is not the report read aloud. It is a story with a beginning, a middle and an end: the problem, the plan and the decision the audience is asked to make. The Tamarack team's storyline followed the structure in the figure below.

Each member of the Tamarack team presented the part they had led, but Farah opened and closed, so that the recommendation came from one voice. The team rehearsed three times in full, with a timer, and once in front of Tamarack's estimating department, who were told to interrupt. Slides used large figures, few words and the same key numbers as the report. A backup section after the closing slide held detailed tables for likely questions.

Defending the plan: questions and answers

The question period is where a capstone is often won or lost. Reviewers ask questions to test understanding, to probe weak points and sometimes to see how the team handles pressure. The Tamarack team prepared by writing down the twenty hardest questions they could think of, sharing them out, and drafting short answers with the evidence behind each.

Three habits make answers strong. Answer the question asked, briefly, then stop. Point to the evidence in the report, so the reviewer knows the answer was not invented on the spot. And when you do not know, say so, explain how you would find out, and offer to follow up. A team that admits a gap honestly earns more credit than one that bluffs.

Reflection and what comes next

Many capstone courses ask each student for a short individual reflection: what they contributed, what they learned, what they would do differently and how the project connects to their career. This is worth doing well. Employers interviewing new graduates often ask about their capstone, and a student who can explain the critical path of a real building, the reasoning behind a contingency or how a team resolved a disagreement stands out.

At the final review, Ruth thanked the team and told them what she would do with the plan. Tamarack would bid the next municipal station using the team's procurement schedule as a template, would adopt the key numbers table and consistency check for every proposal, and would offer two of the four team members positions as project coordinators. The plan had done what a construction management plan is meant to do: it had helped people make better decisions.

Your capstone deliverable

• A complete final report with an executive summary, chapters for each deliverable and appendices.
• A key numbers table and a consistency check across every chapter.
• A set of clear figures with captions that each make one point.
• A timed, rehearsed presentation with a storyline that leads with the recommendation.
• A list of likely questions with prepared answers and evidence.
• An individual reflection on your contribution, learning and next steps.