Category: Deliver projects

Quality checking begins with the agreed result and ends with the actual file, page or system the client will receive. A checklist helps you remember important checks, but the evidence comes from performing them and recording what happened. Different disciplines need different checks; no short list certifies every digital project. This guide develops the checking stage of manage freelance projects.

Turn acceptance conditions into observable checks

Use write project brief acceptance criteria to identify what the deliverable must do. Replace “looks good” with a condition a reviewer can inspect: approved wording appears, the specified format opens, the expected calculation produces the correct result, or a named form completes the agreed path.

For each condition, identify the test object, the method and the expected result. A working file, an export and an uploaded version are different objects. If the client receives the PDF, opening only the design source does not establish that the delivered PDF works. If a website page links to a form, a screenshot of the page does not exercise the form.

Prioritise by the consequences of failure. A wrong event date, inaccessible delivery link or incorrect total can be more consequential than a minor decorative inconsistency. Record unresolved issues openly. Do not average several minor passes into a score that hides one essential failure.

Enlarge visual for reading

Run the checks shared by most digital work

Use a preserved source of truth for factual checks. If the source is itself ambiguous, record the uncertainty and ask the owner. Checking a date against a second unapproved copy does not resolve the ambiguity. Never mark an unknown field as zero, false or complete merely to make the sheet look tidy.

Keep the review proportional. A low-risk caption correction does not need a sprawling test programme, but it does need a check of the corrected caption and affected export. Broaden checks when the change could affect another function or when a previous problem gives you a concrete reason.

Add the checks your discipline requires

For websites, W3C WAI’s Easy Checks provides a preliminary accessibility review and explicitly warns that it is not comprehensive. Passing a few checks does not justify a blanket accessibility-conformance claim. Define the required level of assessment and obtain suitable expertise when the project needs it.

Likewise, the OWASP authorisation guidance is useful when the task involves permissions, but reading a checklist is not a security audit. Be specific about the authorised checks you performed and what remains outside your competence or scope.

Worked example: a date error survives export

Fictional scenario: The approved workshop source says 21 November. A designer corrects the working layout, but the delivery folder still contains an older square export showing 14 November. The print export has the correct date. A review of the source file alone would miss the mismatch.

The correction is to regenerate the square export from the approved working version, open the actual new file, compare its wording and dimensions, and update the delivery note. The graphic shows an illustrative check record; it is not evidence that a real project was tested. In your own work, record the real file identifier, observation and reviewer.

Enlarge visual for reading

Copy a delivery check record

A failed check is useful if it leads to a controlled correction. Preserve enough detail to reproduce the problem without copying unnecessary personal data into the log. After fixing it, recheck the affected result. If the change can affect other relevant outputs, check those too; if it cannot, avoid expanding the exercise just to generate a longer report.

Keep “not tested” separate from “failed.” A feature may be untested because access is unavailable, which is a different decision from observing a defect. Neither status should be presented as a pass. Explain any material remaining limitation before asking the client to accept delivery.

Make a delivery decision with honest limits

Deliver when the agreed conditions are satisfied or when remaining limitations have been explicitly discussed and handled within the appropriate agreement. Do not hide a required failure behind a green summary label. If a critical issue is beyond your ability, preserve the work, explain the effect and seek an authorised way forward.

The ready for paid client work checklist helps assess whether you can reliably perform the specific task and its checks. Once the actual deliverables are ready, use freelance project handover to package files, evidence, instructions and support boundaries. Quality is the relationship between the promise and the inspected result, not the number of checkboxes.

Frequently asked questions

Sources and scope

The worked examples, worksheets and diagrams are original fictional teaching materials. They are not reports of client results. Primary references were checked during preparation; verify current rules and account-specific features before acting.

• W3C WAI: Easy Checks
• OWASP Authorization Cheat Sheet

A clear project update helps the client understand the present state and make the next necessary decision. State what is complete, what evidence is available, what remains uncertain and what action is needed. Avoid percentages that have no defined meaning or reassurances that conceal a blocker. Updates connect the stages of manage freelance projects.

Report the state of the work, not the effort alone

“I worked on this all morning” describes effort but does not tell the client what they can review. “The square announcement draft is ready; the print version still needs the approved venue text” identifies an output and a dependency. Both effort and output can matter, but they answer different questions.

The GOV.UK guidance on measuring and reporting progress connects reporting to the work and evidence produced during delivery. For a small freelance project, a useful adaptation is to link an update to a version, decision or checked result. Do not borrow an elaborate reporting system when a short, accurate note will do.

Agree the channel, recipients and expected rhythm during the client onboarding checklist. A project with frequent decisions may need more contact than a straightforward file preparation task. A material problem should not wait for the next routine update merely because it was not scheduled.

Enlarge visual for reading

Give the reader four things they can use

Use dates or times when they help coordinate an action, and include the relevant timezone when people could interpret them differently. Do not create a false deadline to make the client respond faster. Explain the real dependency: “I need the approved spelling before final captions can be exported.”

Separate status from forecast. A draft ready for review is a current fact if it exists; a final file expected tomorrow is a forecast that may depend on approval. Name the dependency alongside the forecast. If you have not checked something, say “not yet checked” rather than using a broad quality claim.

Example 1: a normal review update

Fictional update draft; not sent: A designer has prepared the agreed square announcement but has not yet produced the print export. The following described work exists only within the teaching scenario.

The square announcement draft, event-square-v2, is ready at the review link. I compared its wording with the approved copy; the printable version is next.

Please send one consolidated set of comments on hierarchy and placement by the agreed review point. The event date and venue wording are already approved, so flag any proposed wording change explicitly. After that review I can prepare the revised square file and the print export.

The version makes the update inspectable. The note describes one specific check without claiming the whole project is finished. The requested review is focused, and the next output is clear. In your real update, include only checks you actually performed and make sure the recipient has access to the review file.

Example 2: a missing input changes the forecast

Fictional update draft: A captioned video needs the approved spelling of a guest’s surname. Editing can continue on unrelated sections, but final captions and export depend on that information.

The first edit is available for review. The guest’s surname at 00:18 is still marked for confirmation, so the captions are not final.

Please ask the programme owner to confirm the spelling in the shared review note. I can continue the other agreed adjustments while waiting. If confirmation arrives after the planned export slot, I will give you a revised delivery time before exporting the final version.

The timestamp points to the actual question. The update identifies the owner and explains which work can proceed. It does not blame the client or conceal the dependency behind “technical issues.” It also avoids promising that a missed input deadline has no effect on delivery.

Enlarge visual for reading

Example 3: your own estimate was wrong

Fictional update draft: A freelancer underestimated the time needed to repair a supplied spreadsheet’s inconsistent date fields. The work is still within the agreed task; the freelancer is responsible for explaining the changed forecast.

I underestimated the time needed to check the mixed date formats. The records marked in the review sheet still need verification, so I will not describe the file as ready today.

I have preserved the original and completed the checked rows identified in the log. My next step is to verify the remaining ambiguous dates against the source. I propose sending the corrected file at the revised time shown in the schedule. If that no longer meets your need, let us decide which bounded output would be useful first.

The message owns the estimation error, identifies the remaining work and proposes a decision. It does not silently narrow the scope or label guessed dates as corrected. The appropriate revised timing depends on the actual work and agreement; the example is not a script for excusing repeated missed commitments.

Copy an update worksheet and check the evidence

Before sending, read the previous update. Explain any change in the forecast or scope instead of leaving the client to reconcile contradictory messages. Keep sensitive details in the appropriate restricted record; the update can identify the issue without reproducing confidential data in a broad email thread.

When a requested action introduces extra work, use the process to handle client revisions scope changes and link to the decision record. A progress message should not smuggle a scope change into a sentence about what happens next. If a conversation resolves the issue verbally, write down the resulting decision where the project record lives.

As delivery approaches, distinguish “ready for checks” from “ready to hand over.” Use the digital project quality checklist to inspect the final output. A well-written update supports reliable delivery; it cannot substitute for the work or evidence it describes.

Frequently asked questions

Sources and scope

The worked examples, worksheets and diagrams are original fictional teaching materials. They are not reports of client results. Primary references were checked during preparation; verify current rules and account-specific features before acting.

• GOV.UK: Measuring and reporting progress
• GOV.UK: Governance principles for agile service delivery

A handover is complete when the intended recipient can identify the agreed deliverables, access them and understand what happens next. Sending a folder link is only one part of that job. Explain files, dependencies, access arrangements and support boundaries, and preserve an accurate record of what was delivered. This closes the delivery process in manage freelance projects.

Build the pack around what the recipient needs

Begin with the digital project quality checklist so the pack contains checked final outputs. Compare the contents with the agreed brief. Source files, alternative formats and setup work should be included when the agreement calls for them, not assumed merely because you happen to possess them.

Use a short README or delivery note that names the project and final version, identifies the files, explains how to open or use them, and lists material limitations. Distinguish an editable source from an export intended for distribution. If the recipient needs a particular application, font or account, identify that dependency rather than letting the first failed opening attempt reveal it.

A useful folder structure mirrors use: final outputs, agreed editable sources, reference or licence notes, and checks or instructions. Avoid a pile of “final-final-new” files. You can preserve working history elsewhere according to the agreed retention process without making the client search through every draft.

Enlarge visual for reading

Separate file delivery from rights and licences

WIPO’s copyright guidance describes rights that depend on the applicable legal framework. Do not assume that sending a file, paying an invoice or commissioning work automatically transfers every relevant right in every jurisdiction. Identify the arrangements in the actual agreement and obtain qualified advice when a specific legal conclusion is needed.

Third-party materials need separate attention. For example, the Creative Commons Attribution 4.0 licence deed includes attribution and other conditions and notes that other rights may still matter. A file being downloadable or included in a project folder does not erase its licence. Check the particular asset, source and permitted use rather than treating all “free” resources as interchangeable.

This record can explain operational dependencies without making legal claims you cannot support. If a font or stock asset cannot be redistributed in the source pack under its terms, identify a permitted route for the client rather than copying it anyway.

Transfer responsibility through the owner’s process

Use the client’s supported account and sharing arrangements. The OWASP least-privilege guidance supports keeping access limited to the task. Confirm the intended owner and named users, and document which access should continue for an agreed support task and which should be reviewed or removed.

Do not hand over passwords in a public README or leave recovery codes in a shared folder. Do not unilaterally delete the client’s account, revoke the wrong collaborator or move a live service to an unverified owner. Use the authorised platform process, preserve an appropriate recovery route and confirm the resulting access with the recipient.

A delivery link should work for the intended recipient without exposing the pack publicly by accident. Check the sharing scope and ask the recipient to confirm access to the files they need. That is different from claiming they have tested every feature or formally accepted the project. Record the actual acknowledgement accurately.

Worked example: an event-design handover

Fictional scenario: A designer has agreed a square event announcement, a print PDF and the editable source. The event uses client-supplied text and logo, plus a third-party font. No attendance or sales result is claimed. The following is an illustrative pack, not a record of files delivered to a real client.

The delivery note explains that the PNG is for the square placement and the PDF is for print. The source may require the agreed application and a correctly licensed font. The recipient should not have to guess whether opening the PDF in an editor will preserve the original layout.

Enlarge visual for reading

Explain what happens after delivery

State the agreed support route, review window where applicable and what it covers. Distinguish a delivery issue from new content, a new format or an ongoing maintenance responsibility. A request to correct a file that differs from the approved text is different from a request for next month’s campaign. The actual agreement and circumstances govern how either is handled.

Do not promise unlimited assistance as a substitute for a clear arrangement. Name response expectations only when you can meet them and the scope is understood. If a live system needs continuing maintenance, identify the owner; silence after handover should not leave both sides assuming the other is monitoring it.

Use write project brief acceptance criteria to resolve any mismatch between the delivery note and the agreed acceptance conditions. If there is a genuine continuing need after handover, the guide to retain freelance clients ongoing services helps discuss an appropriate ongoing service separately.

Copy this handover checklist

Before sending, open the pack from the delivery location rather than relying on your local folder. Check links, file names and the note’s references. A renamed file can break an instruction even when the file itself is correct. Remove unnecessary confidential information from the pack and retain the records needed under the applicable agreement and requirements.

Close with a specific request: confirm that the intended files can be accessed and identify any delivery issue through the agreed channel. Do not describe silence as satisfaction or invent a testimonial from a receipt acknowledgement. A usable handover gives both sides a clear basis for finishing the project.

Frequently asked questions

Sources and scope

The worked examples, worksheets and diagrams are original fictional teaching materials. They are not reports of client results. Primary references were checked during preparation; verify current rules and account-specific features before acting.

• WIPO: Copyright frequently asked questions
• Creative Commons Attribution 4.0 deed
• OWASP Authorization Cheat Sheet

Keep three questions separate: what amount has been billed, what payment has actually arrived, and what records or obligations apply to your situation. An invoice, a payment confirmation and a bank receipt describe related events but are not interchangeable. A simple operational record helps you spot a mismatch before it becomes a larger problem. This is part of manage freelance projects.

Start with the agreed billing arrangement

Confirm the customer or entity to bill, the work reference, the agreed amount and currency, the billing trigger, payment route and due-date arrangement. Use hourly vs fixed price vs retainer for the payment-model decision. Do not invent a deposit requirement, late fee or withholding rule after the engagement has begun.

The operational record should match the brief prepared through write project brief acceptance criteria. A purchase order, approved milestone or other required reference may determine how the client processes an invoice. The UK Small Business Commissioner’s guidance highlights the importance of confirming the actual invoice recipient and relevant references. These practical questions are useful without assuming that its legal context applies everywhere.

Ask whether the project contact and accounts-payable contact are different. Confirm the submission method and what acknowledgement means. A message saying an invoice was received is not proof that the invoice was approved, scheduled or paid. Record the actual state and the next appropriate action.

Enlarge visual for reading

Prepare an invoice that can be matched to the work

Check local official requirements rather than treating this table as a universal compliant invoice. For example, GOV.UK’s invoicing guidance describes UK rules and distinguishes an invoice from a receipt. Whether a particular registration number, tax amount or additional field is required depends on the relevant rules and your circumstances. Obtain suitable accounting or legal help for those determinations.

Use consistent identifiers so a payment can be matched without guessing. If an invoice needs correction, preserve an audit trail and follow the applicable correction process. Do not silently overwrite a previously issued amount and leave the client with two conflicting versions.

Compare payment routes by eligibility and total operation

A provider being well known does not establish that you can use its business services. Stripe’s availability page and Wise’s business eligibility guidance are examples of primary sources to check for current country, entity and activity support. They are not recommendations for a particular reader, and this guide does not assume account approval or international eligibility.

Compare the whole route rather than one advertised fee. A payment may involve processing, conversion or withdrawal costs, and the party responsible for them should be clear. Do not use someone else’s account or misstate your location to bypass an eligibility restriction. Recheck changing provider details before relying on them.

Worked example: a payment is not the net bank deposit

Fictional arithmetic example: An already agreed invoice total is 1,000 monetary units. This illustration makes no tax assumption and uses no real provider rate. The client pays 400 units against it. Under the example’s agreed arrangement, the freelancer bears a 12-unit processing fee, so the bank receives 388 units.

The remaining invoice balance is 600, not 612. The 12-unit cost explains the difference between the client’s payment and the net deposit; it is not automatically a new debt owed by the client. A different agreement or fee structure needs its own treatment. Record the transaction reference, allocation and fee separately so the reconciliation is visible.

Enlarge visual for reading

Keep a small reconciliation trail

Connect the agreed work, invoice, payment reference, fee record and bank receipt. Record dates and currencies accurately. If one payment covers several invoices, show the allocation. If a payment is partial, keep the balance visible rather than marking the whole invoice paid. If money is refunded or disputed, record that event separately.

Store records with access appropriate to their sensitivity and retain them according to the requirements that apply to you. This guide does not prescribe a universal retention period. If payment details change, verify the instruction through an established authorised route rather than treating an unexpected message as sufficient evidence.

Use the records to make the next decision

When payment is late or the records disagree, first check the invoice recipient, due-date arrangement, references, payment allocation and any documented issue. A calm, specific enquiry is more useful than assuming bad intent. Legal remedies, interest and collection steps depend on the applicable agreement and jurisdiction; check official guidance or obtain qualified advice before asserting them.

Use track freelance income costs capacity to connect the records with costs and available time. Billed amounts are not automatically cash in the bank, and cash received is not automatically profit or spendable personal income. Good operational records make those questions easier to discuss with the appropriate adviser.

Frequently asked questions

Sources and scope

The worked examples, worksheets and diagrams are original fictional teaching materials. They are not reports of client results. Primary references were checked during preparation; verify current rules and account-specific features before acting.

• GOV.UK: Invoicing and taking payment from customers
• UK Small Business Commissioner: Getting invoices right
• Stripe global availability
• Wise: Can my business use Wise?
• SBA: Manage your finances

Onboarding turns an agreed project into a workable starting point. Collect the materials you actually need, confirm who can decide, and arrange appropriate access before production. A useful onboarding process reduces avoidable ambiguity without asking the client to hand over every account or complete an oversized form. It is the preparation stage of manage freelance projects.

Separate onboarding from discovery and production

Discovery determines what problem and scope are being considered; onboarding organises the agreed work. If the goal or deliverables remain unclear, return to freelance discovery call questions. Sending an intake form does not resolve a disagreement about what was purchased, and receiving credentials does not authorise every action the account allows.

Begin with the current brief or agreement, not a blank request for information. Identify the approved outputs, input dependencies, review arrangements and any conditions for starting. The client should be able to see why each requested item matters. A small event graphic may need approved text, logo files and export requirements; it does not normally need access to the organisation’s email account.

Use write project brief acceptance criteria to check the acceptance conditions. If the final output will be a PDF, record how it will be used. If the work changes a website, distinguish a draft or staging review from permission to publish. That distinction belongs in the onboarding record before anyone starts making changes.

Enlarge visual for reading

Collect approved materials with a clear owner

List the minimum inputs and name who supplies each one. Include the expected format and the evidence of approval where relevant. “Logo supplied” is incomplete if the file is a low-resolution screenshot and the intended output is a large printed poster. “Copy approved” is incomplete if two attached versions disagree.

Use an agreed shared location and meaningful file names. Record receipt separately from validation: a file can arrive and still be unsuitable. If something is missing, explain which step it blocks and ask the responsible person for the smallest necessary correction. Do not fill gaps with guessed customer data or unapproved wording.

Request task-specific access, not shared passwords

The OWASP Authorization Cheat Sheet describes least privilege: access should be limited to what the task requires. Apply that principle through the client’s authorised invitation or role-based process. A content-editing task should not casually become an administrator account with access to billing, unrelated projects and every customer record.

Record the system, environment, account owner, requested role, purpose and end-of-project access plan. Use a named account where the system supports it and follow the owner’s authentication requirements. Never ask a client to paste a password, recovery code or one-time authentication code into an intake document. If a platform lacks suitable delegation, agree a supported alternative with the owner instead of improvising a shared login.

Check access using the least consequential action that establishes the needed capability. Seeing a draft page does not prove that editing is possible, while having a publish button does not mean publishing is authorised. For changes requiring recovery, confirm the original copy, backup or rollback arrangement and who may use it. If the environment is uncertain, keep the affected work paused while that specific gap is resolved.

Worked example: onboarding a workshop-page update

Fictional scenario: A freelancer will update one draft workshop page for North Lane Studio. The booking service stays unchanged. The client has supplied two documents with different dates and has offered the main account password. The correct response is to resolve the inputs and access route, not to start editing whichever version is easiest.

The freelancer can prepare a checklist and organise the supplied assets while awaiting the two unresolved items. That useful preparation does not justify promising that the content update is already underway. When the owner resolves the date and grants suitable access, record what changed and use the confirmed baseline.

Enlarge visual for reading

Copy this intake form and access register

Keep the form short enough to answer, but specific enough to use. Explain which fields are required and why. For a business contact, request the information needed to coordinate the project, not a private identity dossier. Handle any personal or confidential data according to the applicable requirements and agreed process.

A start gate is a decision about dependencies, not a demand that every conceivable document be complete. If one deliverable can safely begin while another is blocked, record that boundary. For example, approved layout planning may proceed while a missing biography prevents final text placement. Avoid marking the whole project “ready” when the blocked dependency still controls delivery.

Before closing onboarding, give the client a brief summary of what was received, what is still needed and what happens next. This provides a chance to catch an incorrect assumption while the work is still easy to redirect.

Keep the setup current during the project

Onboarding records change when a new approver joins, an input is replaced or the scope changes. Update the relevant entry rather than leaving the original form as a misleading snapshot. Preserve the history of significant decisions so the team can tell which version governs the current work.

Once production begins, use client project update examples to report completed work, dependencies and decisions. At handover, revisit the access register and follow the agreed return, retention and removal process. An invitation should not remain indefinitely merely because nobody remembered why it was granted.

Frequently asked questions

Sources and scope

The worked examples, worksheets and diagrams are original fictional teaching materials. They are not reports of client results. Primary references were checked during preparation; verify current rules and account-specific features before acting.

• OWASP Authorization Cheat Sheet
• GOV.UK: Governance principles for agile service delivery

Client feedback becomes manageable when you compare it with a clear baseline, clarify the requested change and record the decision before altering the work. Some comments identify an error, some choose among agreed options and some introduce a new deliverable. Treat those situations differently while keeping the conversation practical. This is part of manage freelance projects.

Keep the agreed version easy to find

Before classifying a request, locate the brief, acceptance conditions, approved inputs and version under review. Use write project brief acceptance criteria if those are not clear. “That was included” and “that is extra” are difficult claims to assess when each person is remembering a different conversation.

Record a baseline in ordinary language: two event-announcement formats, supplied approved text, one consolidated review stage and the final export requirements. The precise terms should reflect the actual agreement. Do not copy another freelancer’s revision allowance and assume it governs your project. A review stage describes a process; it does not excuse delivery that fails the agreed requirements.

Keep comments attached to a version or identifiable item. “Change the second heading in event-square-v2” is more reliable than “change the bit we discussed.” Preserve the original before a substantial revision so you can compare decisions and recover if necessary. Version history is useful evidence of what changed, not a substitute for deciding what should change.

Enlarge visual for reading

Classify the request before discussing the response

Classification is a reasoned comparison, not a label you apply to win an argument. If the brief is ambiguous, show the relevant wording and explain the uncertainty. It may be sensible to agree a narrow resolution and improve the brief for future work. Do not retrospectively invent a boundary that the client could not have known.

The GOV.UK guidance on deciding priorities recommends decisions informed by evidence and stakeholder input. For a small project, the useful adaptation is to compare the proposed change with the purpose and constraints. A visually exciting extra may be less important than correcting the essential event date.

Turn vague or conflicting comments into a decision

When a comment is vague, ask for the problem behind it. “Make the logo bigger” might mean that the organisation is hard to identify at the intended viewing size. The right response could be a clearer header or more space around the logo, not a proportional enlargement that pushes the venue off the page. Restate the problem and propose a reviewable adjustment.

When comments conflict, identify the exact conflict and ask the agreed decision-maker to choose. Do not silently combine incompatible instructions or ask every stakeholder separately until someone gives the answer you prefer. Consolidated feedback reduces duplication, but it still needs a clear owner who can resolve competing priorities.

Summarise the decision with the affected version and intended check. For example: “Use the shorter venue line approved by the organiser; retain the full address in the footer; check both exports at intended size.” This makes the next review about whether the decision was implemented, rather than repeating the whole discussion.

Worked example: a third event format

Fictional scenario: The agreed package contains a square announcement and a printable version. The first review identifies an incorrect date in the square export and asks for a new landscape banner. The designer separates the correction from the new output; no real project or client result is claimed.

The date must match the approved source across both original deliverables. The landscape banner introduces another layout and export to produce and check. The designer estimates an illustrative two hours for adaptation and half an hour for checking, subject to receiving the final dimensions. Those numbers explain an impact calculation, not a recommended rate or a universal time allowance.

Enlarge visual for reading

The client can approve the addition, replace another deliverable where appropriate, defer it or decline it. Record the chosen option before starting the extra. If the designer elects to include it without an additional charge, still record its scope and timing so that a one-off choice does not silently redefine future work.

Copy the feedback and change log

The log can be a simple table; its value is a traceable decision. Do not mark a change approved because you sent an estimate. Do not mark it complete because a task card moved if the exported result has not been checked. Keep requested, agreed, implemented and verified states distinct.

For the initial boundaries and estimation method, return to estimate freelance project scope. This guide concerns decisions during delivery. If a change alters a legal, security or specialist obligation, obtain the appropriate review rather than treating the log as authority to proceed.

Explain the impact without blame or hidden pressure

Use a short response: “The square and print versions remain in the current scope. The new landscape format adds a separate layout and check. I can prepare it once we confirm dimensions and the revised arrangement. Would you like that option, or should we complete the original two outputs first?” The message identifies the choice and preserves the original work.

If your own mistake caused rework or delay, acknowledge it directly. Explain the correction and the effect on delivery. If a client dependency changes the schedule, describe that dependency without turning the update into an accusation. The aim is a shared decision about the next step.

Use client project update examples to keep the latest decision visible in the next progress update. A concise record makes a changed project easier to deliver; it does not make every disagreement disappear.

Frequently asked questions

Sources and scope

The worked examples, worksheets and diagrams are original fictional teaching materials. They are not reports of client results. Primary references were checked during preparation; verify current rules and account-specific features before acting.

• GOV.UK: Deciding on priorities
• GOV.UK: Governance principles for agile service delivery

A project brief turns a conversation into a shared description of the work. It should explain the problem, deliverables, inputs, constraints and decisions needed to finish. Acceptance criteria make completion inspectable: the people involved can check the same result instead of relying on different meanings of “done.”

The broader guide to manage freelance projects covers delivery. This article focuses on the brief that supports it. The sample is a practical planning document for a fictional page-update project, not a universal legal contract template.

Start with the discovery outcome

Collect the relevant decisions from the discussion: who needs the work, what problem they face, what output is expected and what is outside scope. Use freelance discovery call questions to prepare that conversation. Do not write a confident brief while material questions remain unanswered; mark them and assign an owner.

Separate the purpose from the solution. “Visitors need current workshop dates and a clear request route” is the purpose. “Update three existing information pages” is the proposed deliverable. The purpose helps evaluate a change request; the deliverable defines what the current project actually includes.

Record the source of required content and assets. Identify who approves them and when they must be available. If the project depends on access, a third-party response or another team’s work, make that dependency visible. A date without its conditions can create a promise nobody intended.

Write a brief that another person can use

Enlarge visual for reading

The brief does not need to reproduce every earlier message. It needs a current, consistent version of the decisions that affect delivery. Give the document a version date and identify the person authorised to approve changes. If several people review, specify how conflicting feedback is resolved.

Make acceptance criteria observable

GOV.UK’s user-story guidance describes acceptance criteria as outcomes used to check whether the task has been met. Its guidance on better criteria emphasises language that developers, reviewers and owners can understand. Apply that principle even when the project is not software.

A weak criterion is “The pages look professional.” It can start a design discussion, but it does not identify what to inspect. A stronger criterion is “Each named page shows the approved title, date, location and request instruction, and its request link leads to the owner-approved destination.” The reviewer can compare the output with supplied facts.

Include relevant conditions. Which screen sizes or browsers are in scope? What happens when required content is missing? Does a request action open an existing form or create a new booking? The criterion should fit the agreed deliverable and avoid silently expanding it.

Enlarge visual for reading

Worked example: a small acceptance register

These criteria are proposed examples, not passed checks. The two viewport widths are explicit scope choices for the fictional project; they do not prove compatibility with every device or full accessibility conformance. A real brief should choose appropriate coverage for the actual use and responsibility.

Notice that AC2 asks someone to follow the link. A screenshot of blue underlined text cannot establish its destination. AC3 asks for actual rendered inspection. Source markup alone cannot establish that there is no visual overflow. Match each criterion with evidence that can genuinely support it.

Distinguish defects, missing inputs and changed scope

If a page contains the wrong date compared with the approved copy, that is a mismatch to fix. If the owner has not supplied the date, that is a missing input. If the owner asks for an additional event page after the three-page scope is agreed, that is a possible scope change. These situations need different responses.

Use estimate freelance project scope when estimating the work and its uncertainties. Do not use a revision allowance to hide unlimited new deliverables. A change record should describe the request, its effect on effort and timing, and the decision by the authorised person.

A clear brief can still evolve. Update the controlled version when a change is agreed, then adjust the acceptance register. Otherwise the team may build to one set of requirements while the reviewer checks another.

Copy the practical project-brief template

Use these headings: purpose; intended user or buyer; deliverables; supplied inputs; assumptions; constraints; exclusions; dependencies; acceptance criteria; reviewer and approval owner; review process; schedule conditions; handover; and change process. Add a short unresolved-questions table with an owner and required decision date.

• Can a person unfamiliar with the discussion identify the finished outputs?
• Does each criterion describe an observable result or condition?
• Is the checking method capable of proving that result?
• Are supplied facts and assets linked to an approved version?
• Are missing inputs and exclusions visible?
• Is one person or defined process responsible for accepting the work?
• Does a new request have a clear route for scope and schedule review?

For the fictional project, the practical resource is the completed brief and four-row acceptance register above. Copy them into a document and adapt the values to a real assignment. Remove any criterion you cannot responsibly verify, or arrange appropriate support before promising it.

Use the brief during delivery and handover

At the start, confirm the inputs and unresolved decisions. During work, use the criteria to guide checks and identify changes. At review, record pass, fail or unresolved beside each criterion with the actual evidence. Do not mark a planned check as passed because the implementation looks plausible.

Then use the client onboarding checklist to organise the access, contacts and working arrangements around the brief. At handover, provide the accepted version, relevant checks and maintenance responsibilities. The brief remains useful because it connects the original purpose to the specific work that was delivered.