Build an evidence file before a persuasive presentation
For each site, start a record of what you know, what you have assumed and what remains unanswered. Name the source, the date and the person responsible for the next check. A planning map, a seller’s statement and a consultant’s written opinion are not interchangeable evidence.
Use a short decision log to connect findings to choices. If a servicing question could change the project scale, record the scenario affected and the cost of finding out. This makes a site meeting more useful: people can discuss the decision that is blocked, rather than repeat everything collected so far.
Show what changes the feasibility result
A single forecast can hide the assumption doing most of the work. Prepare a base scenario, then change a small number of drivers deliberately: timing, construction costs, the proposed program or revenue assumptions. Keep the source and scope of each input beside the number.
The purpose is not to find a scenario that looks attractive. It is to discover which information would improve the decision and which downside you would need to fund. The feasibility guide includes a clearly fictional example and explains how to avoid counting the same allowance twice.
Connect a construction change to its consequences
A requested change may affect scope, cost, sequence and a future operating requirement. Record those effects together before the team starts treating a request as an approved instruction. Identify the person who can decide, the evidence they need and the version of the estimate they are reviewing.
An issue log and a change log serve different purposes. Link them when useful, but do not let an unresolved question appear completed merely because it has a price. Contractual notices and approvals must follow the actual agreement and applicable rules.
Prepare the operating team before the last site visit
Start the handover list while there is still time to find missing information. Organize it by system and responsibility: what is being handed over, who receives it, what needs to be demonstrated and what remains open. Keep evidence of training and completion beside the item rather than in a separate, unsearchable email chain.
A handover package is useful when the next person can operate and maintain the property. Review it with the owner or manager, and distinguish internal tracking from inspections, permissions and formal acceptance required for the specific project.
Common questions
Can a planning model confirm that I can build a project?
No. A model organizes assumptions; it cannot establish legal rights, issue permits or confirm technical feasibility. Use it to identify the questions that need written answers from the municipality and qualified professionals for the site.
How many scenarios should a small team maintain?
Keep enough to expose the decisions, without producing versions nobody can explain. Start with a documented base and a few purposeful variations. Record what changed and why, and retire obsolete versions so an old assumption is not mistaken for the current plan.
Does a completed task mean the work is formally accepted?
Not necessarily. A task status is an internal coordination record. Formal inspection, acceptance, occupancy and contractual requirements depend on the work and location. Record the actual evidence and responsible authority instead of inferring approval from a completed checklist.
