By the ProofCohort team. Questions or corrections? Contact our team.
Free editable text file (.md). Open it in any text editor or copy it into your document. No account needed.
What does a useful project brief contain?
A project brief defines the problem, who the work is for, what you will deliver, and how someone can check it. Start with one outcome you can demonstrate. ‘Improve a business’ is too broad; ‘compare two check-in processes using the same sample arrivals’ gives you a decision, an artifact, and a way to test your reasoning. Use this free template for independent practice or adapt it to your assigned program task. Reading or completing this resource does not enroll you in a program or award a credential.
Fill in these eight fields before starting
Write the brief in plain language. A reviewer should be able to understand it without already knowing your tools or the project history.
- Problem and audience: who needs what, and what evidence or assumption supports the problem?
- Outcome: what should someone be able to do, decide, or inspect when the project is complete?
- Scope: list the included deliverables and explicitly exclude work you will not attempt.
- Inputs: name the files, permitted datasets, research, brand material, or other sources you will use.
- Constraints: record available time, tools, access, privacy requirements, and any budget assumption.
- Deliverables: name the concrete outputs and the format in which a reviewer will receive them.
- Acceptance checks: describe the conditions that each deliverable must satisfy and how you will check them.
- Evidence and review: link the artifacts, state your contribution, record feedback, and identify remaining limitations.
One scenario, six different project briefs
Consider a fictional community workshop that needs a clearer registration and arrival experience. The following are optional practice examples across ProofCohort's six career areas, not advertised enrollments, client commissions, or learner results. Pick one area and complete its deliverables before expanding the scope.
- Technology — Build a registration prototype using synthetic entries. Deliver the implementation and instructions; check required fields, invalid input, duplicate submissions, and the confirmation state. Exclude real payments and real personal data.
- Design & Product — Map the registration journey and prototype two flows. Deliver the problem framing, wireframes, a chosen flow, and the rationale. Check that a user can find event details, correct an error, and understand confirmation; label assumptions and report only tests actually conducted.
- Business & Growth — Compare two ways to organize the workshop. Deliver an assumptions sheet, a cost-and-capacity comparison, and a recommendation. Check arithmetic and explain how the recommendation changes when attendance or cost assumptions change.
- Data & AI — Analyze a synthetic registration and arrival dataset. Deliver a data dictionary, cleaning steps, charts, and reproducible calculations. Check missing records, duplicate IDs, and consistent denominators. If using a predictive model, separate training and evaluation data and compare with a simple baseline.
- Marketing — Develop a campaign proposal for one defined audience. Deliver a messaging brief, two sample assets, a channel schedule, and a measurement plan. Check consistent event information and explain how each metric would be collected. Forecasts remain forecasts until a real campaign is run.
- Operations — Design the arrival and check-in process. Deliver a process map, a responsibility checklist, and an exception log for missing names, late arrivals, and capacity limits. Walk through sample scenarios and record where the process fails or needs a decision.
How do I make acceptance checks specific?
Replace ‘looks professional’ with an observable condition. For a design, check whether the prototype includes both an error state and a successful completion. For an analysis, verify that a second person can reproduce the totals from the supplied inputs. For a budget, compare the base case with a clearly stated alternative. For operations, walk through an exception rather than testing only the ideal process. These checks help you review practice work; they do not replace an enrolled program's assessment criteria.
How can a team use the same brief?
Assign an owner to each deliverable and document the handoffs. For the workshop example, the marketing proposal needs agreed event information, the design needs the registration requirements, and operations needs a list of exception rules. Keep one version of the brief and record decisions when scope changes. In a portfolio, explain your own contribution alongside the team's work so reviewers can distinguish what you personally demonstrated.
What should I share after completing the project?
Publish the brief, the permitted final artifacts, the checks you ran, and a short explanation of decisions and limitations. Keep private research, real participant details, and credentials out of public files. A useful case study connects the original requirement to the evidence and the revision made after feedback. You may copy and adapt the blank template for your own work or teaching; no account is needed to download it.
How does this connect to a ProofCohort program?
Use the published catalog to find the programs currently available, then read the actual prerequisites and weekly syllabus. Enrolled learners follow their assigned tasks and submit the requested evidence for assessment. Independent practice with this template is separate from admission, mentoring, and certificate eligibility. Program participation is free; optional purchases and their conditions are explained on the fees page.