A Project Brief with a Clear Boundary

“Could you make us a welcome pack?” sounds like a small request until people imagine different things inside it. One person pictures a printable sheet. Another expects a website, a map, translated information and a series of social posts. A project brief is an opportunity to discover those differences before the work is treated as agreed.

This short educational handbook follows a fictional brief from the opening request to an accepted result. It concerns ordinary small-project planning, not a substitute contract, engineering certification or guarantee of business success. Existing duties, rights, professional standards and approval processes still apply.

Dina runs an invented small design studio. Hugo coordinates an invented community choir. He asks her for a welcome pack for a Friday open evening. Suri, a volunteer who greets visitors, will help check the information. These people and their project are fictional; no real event or client is being described.

Dina first asks who will use the material and what that person needs to know. Hugo wants a first-time visitor to find the arrival time, the singing time, the venue information and a contact for questions. The visitor may read it before leaving home. The request is about a useful visitor sheet, not a new public identity for the choir.

They agree to one two-page A4 PDF supplied to Hugo. Its purpose is to give those particular details in one document. This does not promise that every visitor will read it, attend or understand every aspect of the choir. It defines a modest output they can inspect rather than an audience outcome Dina cannot guarantee.

For your own project, begin with the intended user and the immediate need. Do not jump from an attractive project name to a list of objects nobody has agreed to make. A short conversation can still leave important questions open; write them as open questions instead of filling them with convenient assumptions.

The brief names the output: one two-page A4 PDF visitor sheet for this open evening. It also names the content to include: the event name, date, arrival and singing times, venue details and the club's verified contact information. Hugo will supply and approve those facts. Dina is not being asked to invent them.

Then they identify what this assignment does not include: printing, a website, social posts, photographs, a new logo, translations or a booking system. The choir may need other things at another time. Naming them here prevents the phrase welcome pack from silently becoming a promise to supply them now.

An exclusion is a description of this work, not a way to remove duties. For example, a brief cannot excuse ignoring applicable accessibility requirements or other obligations. If specialist work or additional formats are necessary, determine how they will be provided before pretending the selected output meets the whole need.

Dina explains that a PDF alone is not every possible means of communicating. Hugo confirms that this sheet is one part of the choir's existing arrangements. He remains responsible for other visitor communication. The brief does not transfer that entire responsibility to a two-page file or certify universal accessibility.

Suri suggests that the two pages should distinguish information needed before arrival from information useful on the evening. This fits the agreed output. It is not an automatic request for an additional document. Dina notes the distinction while keeping the quantity at two pages.

For your brief, keep the edge near the output description. If the intended result needs a separate activity, identify the dependency and its responsible person. Do not hide necessary work in “someone will sort that out,” or write a long list of exclusions that leaves the actual user unable to do the thing the project supposedly supports.

The visitor sheet depends on accurate information. Dina cannot finish a reliable layout merely by waiting for facts to become available. Hugo agrees to provide approved text, the existing logo he is authorised to supply and verified venue and contact details by Tuesday at noon. Suri will review the visitor-facing information, but Hugo will send the consolidated decision.

They set a draft review for Wednesday at noon. Hugo will return one consolidated set of comments by Wednesday at five. The final agreed deadline is Thursday at three in the afternoon, before the Friday evening event. These are the invented project's dates, not recommended universal turnaround times.

Dina checks that those steps are feasible with her other commitments. Hugo checks that he and Suri can review when required. The plan does not quietly reserve their evenings or assume instant replies. If the inputs or decision cannot arrive as agreed, the project needs a fresh discussion of what is realistically possible.

The early request mentions a six o'clock start. Before the brief is approved, Suri clarifies that visitors arrive at six and singing starts at six-thirty. Hugo confirms both times. Dina updates the brief before producing the draft. She does not choose whichever time fits the available space or label an unconfirmed detail as verified.

This is a small example of why inputs deserve names and dates. The content provider, the reviewer and the person who approves the result can be different people. Their work needs to meet in an arrangement the maker can actually use. “Everyone will have a look” does not say who will resolve conflicting comments or return the decision.

Record uncertainties where they belong. An unresolved venue detail is not a design choice for Dina to make secretly. A logo without permission to use it is not a harmless placeholder to publish. The relevant person must confirm the input or the plan must change before it is relied upon.

“Make it clear and welcoming” can express an intention, but it is not enough to check the finished file. Dina and Hugo turn their agreement into a small set of observable checks. The document will be one PDF containing two A4 pages. It will contain the approved event facts, including separate arrival and singing times, and the agreed contact information.

They will open the exported file, inspect both pages and compare the details with the approved text. They will check that no required information is missing or visibly cut off. They will also check a printed copy using the club's existing arrangements, because Hugo expects to print the sheet. This is a check in the fictional case, not a claim that this book supplies a real PDF or print proof.

Suri will read the sheet as somebody greeting a first-time visitor. Can she point to when a visitor should arrive, when singing begins and where a question should go? Her review is useful within this small example. It is not a research trial, a guarantee for all readers or a replacement for any required accessibility review.

The distinction matters: an observed check can support a claim about what was checked. It cannot establish every hoped-for benefit. A file with the right information does not prove that the event will be popular. A reviewer finding the contact does not certify every reader's experience.

Dina and Hugo also agree how completion will be acknowledged. Hugo will compare the final file with the brief and confirm acceptance of that output. Sending a draft will not count as final approval. A friendly comment about colours will not replace the decision on the required content and pages.

For your project, choose checks suited to the actual output and risk. Complex, regulated or safety-related work may need specialist verification. A short brief should point to that requirement, not conceal it under a vague statement that everything will be checked later.

You can organise a small brief under six headings: Purpose and reader; Output and boundary; Inputs and dependencies; People and decisions; Dates; Acceptance and finish. These are an original organising aid for this handbook, not a certified framework, compulsory government form or complete contract.

Dina's first heading says that a first-time visitor needs practical information for the open evening. The second names one two-page A4 PDF and the included facts, alongside the exclusions already discussed. The boundary belongs to this assignment; it does not declare the choir's other responsibilities finished.

Inputs and dependencies names Hugo's approved text, logo and venue and contact details, including the two confirmed times. People and decisions names Dina as maker, Suri as information reviewer and Hugo as the person returning consolidated comments and accepting the output. That prevents three separate conversations from being mistaken for three independent approvals.

Dates records Tuesday noon inputs, Wednesday noon draft, Wednesday five o'clock comments and Thursday three o'clock final deadline. It also records that the event is Friday evening. The schedule is an agreed sequence, not a claim that every other project should use the same intervals.

Acceptance and finish records the two-page file, approved information, inspection of both exported pages, the fictional printed check and Hugo's explicit acceptance. It distinguishes those checks from the bigger hopes of welcoming visitors and running a successful event. The brief does not measure attendance, sell tickets or promise a particular response.

Before work starts, Hugo and Dina read the whole brief together. Suri confirms the visitor facts she reviewed. The brief is then agreed as the basis for this assignment. There is no need to call it a binding legal instrument or copy an entire engineering standard to give this modest agreement a clear boundary.

The agreed inputs arrive by Tuesday noon. Dina produces the two-page draft for Wednesday noon. Suri checks the arrival information and Hugo returns the consolidated comments at four, before the five o'clock review deadline. The comments concern wording and the order of information within the two pages; they do not add a website or another format.

Dina makes the agreed adjustments. She exports the final PDF, opens it, inspects both pages and compares the facts with the approved text. Hugo checks the printed copy through the club's existing arrangement. The two times remain distinct: arrival at six, singing at six-thirty. The selected file contains the two A4 pages, not a hidden extra page or an unfinished draft.

On Thursday at two she supplies the final file. At two-twenty Hugo confirms acceptance after checking it against the brief. That is before the agreed three o'clock deadline. Dina records the file supplied and the acceptance. The fictional project has reached the finish it defined before the first layout was made.

This does not mean the open evening has happened or that every visitor's needs have been demonstrated. The event remains Friday's work. The choir's other communication and responsibilities remain its own. Completing the visitor sheet is a real result in the example, with a boundary around what that result establishes.

Later somebody suggests a poster. It may be a good idea, but it is not work secretly included in the accepted sheet. It needs its own discussion of purpose, inputs, permission, capacity and finish before anyone treats it as promised. No purchase or additional commission is made in this example.

For your own brief, end with an honest account: what output was agreed, what inputs supported it, what checks were completed and who accepted it. Leave wider hoped-for outcomes distinct from the delivered item. A clear boundary is not a smaller vocabulary for disappointment; it is a way to know which useful work you have actually agreed to finish.

Primary institutional guidance checked on 6 November 2026 provides bounded background. GovS 002 discusses defining needs, constraints and success criteria: https://projectdelivery.gov.uk/library-products/government-functional-standard-govs-002-project-delivery/ . This UK government resource is version 2.1, published 1 September 2025; the HTML page lists modification on 29 March 2026. It is not a universal rule for private small businesses.

NASA's engineering checklist discusses clear requirements, stated assumptions and verification: https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/ . Its engineering context is not a requirement that a choir sheet follow a NASA process. Neither source certifies this handbook's original six-part brief or guarantees a project outcome. No whole institutional checklist or formal standard is reproduced.

Dina, Hugo, Suri, the choir, document, times, review, printing and acceptance are invented teaching details. No actual event announcement, PDF, logo licence or accessibility certificate is supplied. The example is not legal advice or a substitute for an agreement appropriate to real work. Necessary duties and specialist requirements cannot be removed by listing them outside a brief.

No earnings, attendance, customer satisfaction, error-free delivery, purchase or payment is promised or performed. This complete short digital handbook and full Bengali, Hindi, Spanish, French and Arabic editions are AI-assisted original writing and translations with editorial review. The English front and back covers are original conceptual illustrations. No independent human authorship, native-human certification, assigned ISBN or print proof is claimed.