Build a shared factual base
Keep a current source for the project description, location, status, figures and dependencies. Record the date and owner of important inputs. Audience versions should draw from the same underlying facts, even when they use different levels of detail.
Agree which statements are approved and which still need review. A shorter version must not turn a conditional proposal into a settled commitment by dropping its qualifications. Keep meaningful conditions beside the claim they affect.
Map the questions before creating versions
Ask what each group is being asked to consider, what they already know and which questions remain open. Ask the people preparing the engagement which questions need the most attention.
The example below shows possible differences in emphasis. Use it to start that discussion, then adapt it to the actual people and project.
| Audience | Possible question | Useful supporting material |
|---|---|---|
| Investor or partner | What supports the plan, and what does it depend on? | Economics, delivery milestones and evidence |
| Agency or official | What is proposed, and what is its current status? | Project scope, location and dependencies |
| Landowner | How does the proposal relate to the site? | Boundaries, access and clearly stated terms |
| Community audience | What is proposed here, and what is still being assessed? | Local context, understandable plans and a route for questions |
Change the route through the material
Keep the project facts stable while changing the opening, order and amount of explanation. An investor discussion may need the commercial proposition early. A site conversation may need the map first. Choose the route around the purpose of the meeting.
Use a common core of checked slides and a defined set of audience-specific pages. Avoid creating separate decks that drift into conflicting descriptions of the same project. Give versions a date, audience label and person responsible for updates.
Leave room for questions that are not resolved
Some questions require a technical answer, further assessment or a decision outside the presentation team’s role. Say which question is open and who can address it. Do not use a polished slide to imply that an unresolved issue has been settled.
When adapting a deck, check whether the new emphasis changes how a claim could be interpreted. Removing a dependency because it interrupts the flow can make the shorter version misleading.
Review each version against its purpose
Read the opening and ending together. Does the audience know why they are seeing the project and what happens next? Check that each central question has an answer, a supporting reference or an explicit owner for follow-up.
A useful handover includes the shared core, the audience versions and a record of what changed. That makes the next update easier to manage without rebuilding the entire presentation.
- ConsistencyThe same facts and status across versions.
- RelevanceAn opening and sequence suited to this audience.
- TraceabilityCurrent sources and owners for important inputs.
- Follow-upClear questions, responsibilities and next steps.