Define a verifiable delivery and manage additional requests
A project starts with an apparently clear request, then expectations change. An option becomes necessary, a new version is requested or the delivery is judged “not complete enough”. To keep the discussion concrete, describe what will be delivered, how it will be checked and what changes.
You can apply this method free of charge in a document. It is particularly relevant to freelancers and small teams that want to prepare the acceptance checks for a deliverable without turning every exchange into a matter of interpretation.
Describe the deliverable and its exclusions
Start by naming the deliverable, its intended recipient and its use. Add its format, the expected components and each person’s responsibilities. Specify what the project does not include where ambiguity could arise.
A phrase such as “a complete file” remains too open-ended. Instead, state which documents must be present and which elements the requester must provide. If information is missing, record it rather than silently deciding on their behalf.
Keep a dated initial baseline. It provides a point of comparison for changes; it is not automatic evidence of a contractual agreement.
Turn expectations into verification criteria
For each deliverable, describe an observable criterion and a checking method. “Easy to use” can start a discussion, but it does not explain how the result will be assessed. A more concrete criterion might state that a reader must be able to find information from the table of contents.
Specify who will check the criterion and which references they will consult. Do not enter a favourable result before the check. Evidence still to be supplied must remain marked as missing.
The verification method should remain proportionate to the project. It does not replace the specialist checks required in some fields.
Review each change before incorporating it
When an additional request arrives, describe it separately from the original scope. Record its estimated effects on the work, cost and delivery time, then indicate whether the request is pending, accepted or rejected.
Estimates come from the people concerned. An amount calculated from entered hours and a rate does not demonstrate that the work will actually take that amount of time.
If the change is accepted, update the deliverable and the affected criteria. Recheck previous results when the content changes: approval of an earlier version is not sufficient for a new version.
Fictional example: a communication kit
Imagine a freelancer preparing a kit containing a presentation and three email templates. The requester then adds an English version of the presentation. This request is recorded separately, with the hours and delivery time estimated by the freelancer.
After a decision, the scope is updated. The presentation’s text must be checked again in the new version. The translation is not considered approved simply because the French presentation was approved. This example makes decisions visible; it guarantees neither a deadline nor the absence of disagreement.
Use BriefVerrou to support your tracking
BriefVerrou — DocPilot IA Pro is offered at €29. The local application links deliverables, exclusions, responsibilities, acceptance criteria and changes. It retains versions of the scope and lets you cost changes using the hours, rates and days you enter.
Evidence consists of textual references that you check. Recorded decisions are neither a contract, a signature nor certified evidence. The tool does not attest to the actual quality of a delivery and does not generate an automatic schedule.
After delivery, also prepare a handover the person taking over can actually test.
You can print the report, export it in Markdown or CSV and back up the project in JSON. Backups are manual: keep the downloaded file. Consult the BriefVerrou product page, or browse the DocPilot IA tools.
