New editorial guide, published 17 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
An assignment for five pages can become difficult even when everyone agrees on the fee and the deadline. One person expects finished copy in a document; another expects it entered into a website, checked on mobile and approved by several departments. The disagreement is about the work, not the number five. A useful scope makes those decisions explicit before the project begins. This article proposes a practical project-planning method using an invented small website assignment. It is not a contract template, a statement about legal rights or evidence that any particular workflow guarantees payment or client satisfaction.
Describe the deliverable at the point of handover
Start with what the recipient will actually receive. Five edited page drafts in one versioned document is different from five published pages. Name the format, the approximate content boundaries, the required supporting material and the handover location. If titles, navigation labels, image captions and error messages are included, say so. If they are not, do not rely on the client noticing their absence. Small pieces of interface copy can take substantial thought because they depend on product behaviour that a page writer may not control or even have permission to inspect.
Define a unit of work with an example. A service page might include a headline, introduction, process explanation, eligibility information and one next-step link. The scope can then identify which of those pieces need factual input. An approximate word range may help with layout, but it is not a complete description of the job. A concise page based on uncertain product information may require more investigation than a longer article with a settled brief. Make the effort drivers visible instead of treating every word as an interchangeable unit.
Name the inputs and the people who supply them
List the information needed to begin: approved product descriptions, audience questions, existing page addresses, accessibility constraints and any required terminology. Give each input an owner and a needed-by date. An owner is the person expected to supply or confirm the information, not necessarily the person whose name appears on the final page. When an input is missing, record its effect. A draft may proceed with an explicit placeholder, but a claim about an unavailable feature should not quietly become final copy because the review meeting is approaching.
Also identify access boundaries. A writer may be able to view a demonstration but not enter the production system. They may receive aggregated customer questions but not raw support records. Those limits should shape the work plan. Ask for the minimum material needed to answer the editorial question, and keep confidential details out of illustrative drafts when they are unnecessary. If access changes halfway through the project, update the scope and timetable. An assumption that was sensible at the start can become false without anyone acting in bad faith.
Separate revisions from a changed assignment
A revision improves an agreed deliverable within its original purpose. A changed assignment alters that purpose, adds new outputs or introduces a substantially different factual basis. Replacing an unclear sentence is a revision. Rewriting a page for a new product may be new work. Some cases sit between those examples, so describe how you will decide rather than relying on a universal definition. Specify a practical review unit, such as one consolidated round covering all five pages, instead of an ambiguous promise to make reasonable changes until everyone is happy.
Use a small change record with the request, reason, affected output, additional information required and effect on timing. For example, adding a comparison page may require a new brief and evidence checks, not just more drafting time. Discuss those dependencies before accepting a delivery date. Do not turn the record into a weapon for every small clarification. Its purpose is to make a meaningful change visible while there is still room to choose: reduce another part of scope, extend the schedule or treat the addition as a separate assignment.
Make acceptance reviewable
Acceptance criteria should describe qualities that can be checked in the delivered work. The pages use the agreed terminology, factual placeholders are resolved, links point to their intended destinations and the copy fits the specified fields. These are more workable than a demand to increase sales or receive no criticism. A freelancer cannot control every outcome after publication. Equally, a client needs more than a declaration that the writer has spent the allocated hours. Describe the output and the review questions that establish whether the agreed task has been completed.
Decide who consolidates feedback and who confirms the final version. If several people comment independently, ask them to resolve contradictory factual directions before the next drafting pass. Keep the distinction between editorial preference and a failed criterion. A reviewer may prefer a different opening even when the existing one meets the brief. That preference can still be discussed, but it should not be mislabelled as proof that the work is incomplete. Clear categories allow people to negotiate an improvement without rewriting the history of the assignment.
Plan for waiting as well as writing
A schedule needs both active work and review time. Suppose drafting takes place in the first week and the factual reviewer is unavailable until the third. A second-week publication date is not realistic unless the scope permits a different review path. Put dependencies on the calendar, including the time needed to incorporate feedback and check the result. Record dates as working assumptions until the people responsible confirm them. A timeline copied from a proposal is not evidence that all the required participants have reserved time or supplied the promised inputs.
Define what happens when a dependency slips. The appropriate response might be to pause the affected page while continuing independent work. It might be to publish a smaller agreed set later, or to remove an unsupported statement. Make that choice explicitly. Repeated reminders cannot manufacture missing evidence. A short status note can say what is complete, what is waiting, who can unblock it and when the next decision is needed. That note is more useful than a percentage-complete figure that hides the one unresolved input preventing the entire handover.
Finish with a usable record
At handover, provide the final files, their version identifiers, a list of unresolved items and the agreed next owner. If publication is outside scope, say that the copy is approved for implementation rather than already live. If a later check is included, describe its boundary and date. W3C’s provenance primer distinguishes things such as documents from the activities that create or revise them. A small freelance project does not need to implement that model, but the distinction is useful: the draft, the review and the published page are not the same object.
Keep a concise close-out note explaining what was delivered against the agreed scope and which changes were approved during the project. Save only the materials you have a reason and permission to retain. Review the project internally for better future estimates: which assumptions held, which inputs arrived late and which criteria caused confusion? Avoid drawing a grand conclusion from one assignment. The practical benefit is narrower and more dependable: the next project can begin with a clearer description of the work, its dependencies and the point at which responsibility changes hands.
References & further reading
From the recovered archive
- 10 Strategies For Freelancers: Increase Productivity And Optimize Time · captured 16 June 2021
- How to Become a Freelancer and Live a Life of Freedom · captured 1 August 2021