Begin with the proposal and the decision
State what the project is and why the audience is seeing it. Are they considering a site, reviewing an approach or deciding whether to continue a discussion? Put that context before a detailed account of the technology.
A useful opening lets an unfamiliar reader describe the proposal in ordinary language. Define technical terms when they first matter. Keep necessary precision, but explain what a specification changes for the project rather than expecting the number to speak for itself.
“A proposed energy campus at this site, with the infrastructure connections and development steps shown below.” Follow it with the specific question for the meeting. This is an example, not a client project description.
Choose the visual around the question
Use a map when the question concerns location and relationships to surrounding infrastructure. Use a diagram when readers need to understand how components connect. Use a timeline when phases and dependencies explain the proposal.
Each visual needs a point, readable labels and enough context to interpret it. A diagram of a proposed system should distinguish what exists from what is planned. A map should make its boundary, legend and relevant source information visible. Decorative complexity can obscure the very relationship the visual is meant to explain.
Separate the layers of detail
Keep the main presentation focused on what readers need to assess the proposal. Put calculations, detailed specifications and supporting references in a clearly organised appendix. Give each main claim enough evidence that it can be examined without opening every backup page.
Detail has not been resolved simply because it has moved to an appendix. Link it to the question it supports, identify its source and have the appropriate technical owner check the explanation. A reader should be able to tell where to go when they want to look closer.
Keep status and dependencies visible
A concept, a submitted proposal and an approved plan describe different stages. Label the status of each important element near the relevant claim or visual. State the date when the status is time-sensitive.
Show the dependencies that affect the next step. If a connection, agreement or approval is still required, make that part of the explanation. A useful presentation gives the audience a view of both the proposal and what remains unresolved.
Check the presentation with a fresh reader
Ask someone unfamiliar with the project to describe the proposal, point out what already exists and name the next decision. Their questions can reveal where the sequence relies on knowledge that only the project team has.
Then review factual accuracy with the people responsible for the technical material. Readability and technical review answer different questions; both belong in the process. The Arevia case shows how project context, maps and terms can be organised into a presentation.
- ProposalCan a new reader explain what is being considered?
- ContextDo the visuals show the relationships that matter?
- StatusAre existing, proposed and unresolved elements distinct?
- DecisionIs the purpose of this conversation explicit?