Practical guide
A vague goal and an unclear definition of done can let a project expand without an agreed decision. Use the four document structures below to state the problem, plan the work, specify outputs and check completion. They make assumptions and changes visible; the team still has to do the work.
Use the four outlines Read the manual it comes from
The problem you actually have
“Fix onboarding” or “rebuild reporting” may be a useful starting question. It is not yet a shared description of the work. Before committing the team, agree what needs investigation, what should be produced and who can accept it.
The outlines help you prepare that conversation internally or with an outside contributor. They do not replace expertise or establish how long scoping will take. An unclear cause may require an investigation before anyone can define the solution.
If nobody can say what done means, every extra request can sound reasonable.
The four outlines are followed by a progress review and a closeout check. Use them to compare what was agreed with what happened, including any approved changes.
Who it is for, and who it is not
You sponsor or lead internal projects with real budget and real stakes. You have watched one drift past its deadline with no clean way to say it was done. You need a usable brief whether the work stays inside the company or involves an outside contributor.
Why this, and not a project plan template
Task lists and schedules show activities and dates. A brief and completion checks add the reason for the work and the evidence needed to accept it. Use them together.
Return to the brief when new facts change the work. Scoping informs the outcome; it does not guarantee it.
Difference 01
One artifact is nothing but the conditions that, if met, mean the project is finished. Written before kickoff, agreed by the sponsor. Without it, "done" is whatever everyone is too tired to argue about, and scope creep has no wall to hit. Use it to assess additions and record approved changes.
Difference 02
Keep the purpose and the proposed method distinguishable: the brief is the problem and the outcome, the workplan is the path. Keeping them apart is what lets you change the how without quietly drifting the why, which is where scope creep actually hides.
Difference 03
Every week you check progress against the original brief and test-of-done, not against last week's tasks. Compare activity with the intended result, including evidence that the original plan needs to change.
What is inside
One folder per project. Four documents you write before kickoff, a short weekly review note, and a closeout you hold against the test-of-done at the end. You write them in order, because each one constrains the next, which is the whole point.
project/ brief # the problem and the outcome. why this project exists workplan # the path. phases, owners, dates. the how, kept separate from the why deliverable-spec # exactly what gets produced, in what shape, to what standard test-of-done # the conditions that mean finished. agreed before kickoff weekly-review # short note, measured against the brief, not the task list closeout # held against the test-of-done. proves done, or names the gap
Prepare the four outlines before committing to delivery. Use review and closeout notes to record what changes and what remains unfinished.
The problem in plain language and the outcome that would mean it is solved. No solution yet. If the cause is uncertain, make investigation part of the brief rather than presenting a proposed fix as an established answer.
The path from here to the outcome: phases, owners, dates, the fully-loaded cost. Separate from the brief on purpose, so when the plan changes, and it will, you can see whether the change still serves the original problem or has quietly become a different project.
Exactly what the project produces, in what form, to what standard. The thing you can hold at the end and check. Vague deliverables are how a project ends with everyone busy and nothing finished. The spec makes "produced" mean something specific.
The conditions under which the project is over, agreed by the sponsor before kickoff. Assess new requests against those conditions. If new evidence makes a change necessary, agree the revised scope, cost and completion check with the sponsor.
Use an agreed review time to compare progress with the brief and completion checks. Ask what moved, what is blocked and what changed. The task list supplies evidence; it is not the only measure of progress.
At the end, you hold the result against the test-of-done you wrote at the start. Record which conditions are met, who accepts the work and what remains open. Hand over responsibility for use and maintenance; do not treat a completed checklist as proof of a lasting business outcome.
Illustrative onboarding example
Imagine a project to help new hires become productive sooner. The figures and events below are fictional planning inputs, not an account of a client result.
The team does not yet know whether slow progress comes from training, recruitment, manager availability or another cause. The first task is to examine that evidence before choosing the intervention.
Suppose the current measure is 90 days and the sponsor proposes a target of 45 days across two cohorts. Agree what productivity means, how to measure it and whether the target is realistic. Treat those numbers as assumptions to test, not an expected result from using this pack.
Suppose someone proposes rebuilding the onboarding portal. Ask what evidence connects that work to the delay. If access to training is the obstacle, a portal change may belong in the project. If not, park it or scope it separately. Record the sponsor's decision and its effect on time and cost.
At review, compare the actual cohort records with the agreed measure. If the target is met, check quality and other agreed conditions before accepting the work. If it is not, identify the gap and decide whether to revise, continue or stop. No achieved result is assumed in this example.
The useful difference is an inspectable decision: what was proposed, what the evidence showed, what changed and who accepted the result. The documents cannot establish savings that were never measured.
What you walk away with
Retain the brief, approved changes and closeout together. The next sponsor can see which assumptions held, where the work changed and what required outside expertise. Reuse what fits; do not assume the same plan or cost applies to every project.
Separate the observed problem from the proposed answer. State what evidence would justify proceeding or choosing a different assignment.
Agreed completion checks give the sponsor a basis for accepting the work or identifying what is still missing.
Give prospective contributors the same brief and ask them to state assumptions, exclusions and acceptance checks. That helps you compare proposals; it does not promise a lower price.
How you grow it
Next project
Do not adopt the whole pack at once. On your next project, write only the brief and the test-of-done before kickoff. Use those two to test whether the team has a shared understanding of the assignment.
Project after
Once the first two earn their place, run the full four plus the weekly review measured against the brief. Agree the review cadence and time around the project.
Across the org
Set the rule that no project gets funded without a brief and a test-of-done. Allow a bounded investigation when the requirements are not yet known.
When you outgrow it
When a project genuinely needs a firm, turn the scoped artifacts into the RFP. The brief, constraints, decision rights, and test-of-done give each firm the same job to price.
Use it now
Use the page to build the four artifacts before the project receives time, money, or a team. Keep the brief and completion checks current: changed evidence may justify a change, but record who agreed it and why.
Write the brief, workplan, deliverable specification and completion checks from the structures on this page. Review them against the brief each week, then close the project against the test you set at the start.
Use the page for the artifacts. Discuss an agreed engagement when the difficult part is whether the project should exist, who owns the call, or what done must mean.
What this is not
The outlines help organise the work; they do not supply specialist expertise or delivery capacity. Use a qualified contributor where the project needs it. An uncertain problem can itself be a consulting assignment, with investigation and outputs agreed in the scope.
Back to the manual →When the work is live
Stan reviews each request for fit. All corporate work starts with an inquiry and is quoted separately. Stan confirms the people, stakes, scope, and fee in writing before work starts. Use the page independently; any project engagement has its own agreed scope.
Discuss the projectOne-to-one business work: $1,500/month. Project work scoped separately. · Request scope
