How should you scope a website project before approving it?

To scope a website project before approval, turn each important customer task into a counted deliverable with an owner, dependency, exclusion and acceptance test. Agree those records alongside the content inventory and budget limits. This is how to scope a website project around observable work, rather than promises such as “a modern catalogue” or “full integration”.

Start with customer tasks, not a feature wish list

Name the people using the website and rank what they need to accomplish. A procurement manager might need to find a suitable product, check dimensions and request a quotation. Mark assumptions about devices, languages and buying behaviour for validation. “Increase sales” is a business ambition; delivering an agreed catalogue and working enquiry route is something a supplier can control.

1. Rank tasks: identify the three to five journeys that matter most.
2. Define delivery: name the pages, content and interactions each journey requires.
3. Assign responsibility: choose an accountable owner and approver.
4. Expose dependencies: record required content, decisions and account access.
5. Set boundaries: state exclusions and the evidence needed for acceptance.

Count deliverables and copy a reusable scope record

Count layouts separately from populated pages. A template is a reusable layout; a product record is the information placed into it. Also count downloads, forms and languages. Replace “build a product catalogue” with “deliver one catalogue listing and one product-detail template populated with 12 approved products, each with one supplied PDF”. State whether writing, image preparation and upload are included.

Separate content preparation, approval and maintenance

“Client supplies content” leaves too many gaps. Name who prepares it, checks claims, uploads it and maintains it afterwards. In the example, the agency formats approved material but does not invent technical specifications. Buying copywriting can reduce internal work, but technical approval still needs a business owner. Supplied PDFs also need their own accessibility decision.

Define editing tasks instead of promising that anyone can change everything. For this example, a named editor must update product descriptions and replace PDFs without administrator help. WordPress distinguishes editing, publishing and administrative permissions through roles and capabilities.[1] Demonstrate the actual agreed workflow at handover, including any product-specific permissions.

Draw the integration boundary before estimating

“Connect the website to our sales system” is not a bounded requirement. HubSpot documents embedding its forms on external websites, with form-editing permission and external-domain configuration requirements.[2] For this example, choose its native embed and standard form-editor styling. Confirm account permissions and available fields before committing to the affected work.

• Source and destination: the Enquiry page sends submitted information to the supplier’s HubSpot account.
• Method and trigger: one native embedded form sends information when the visitor submits it.
• Fields: name, work email, company-name text, phone, product code, quantity and message; agree required fields.
• Access owner: the sales manager supplies permissions and approves the production domain configuration.
• Failure handling: test validation and confirmation, provide visible phone/email alternatives, and assign submission issues to a named owner.
• Evidence and exclusions: verify a unique test submission and its field values; exclude company-record creation, associations, automatic routing and quotations.

Capturing a company name as text does not promise creation of a separate company record. The narrow embed scope leaves the sales manager reviewing enquiries manually, but avoids bundling unagreed follow-up behaviour into the website build. Treat richer connections as separately specified work, not an implied part of “integration”.

Close constraints and dependencies before approval

• Commercial limits: record the budget ceiling, purchase authority and approver for recurring hosting, domain and software costs.
• Readiness: name owners and milestones for copy, photographs, PDFs, account access and domain decisions.
• Feedback: nominate one consolidating approver, response deadlines and a process for conflicting comments.
• Coverage: list supported browsers, device sizes, languages and the agreed accessibility target.
• Performance: attach named pages, test conditions, numeric thresholds and retest rules before approval.
• Schedule: record which dates depend on each input and how missed dependencies trigger a revised plan.

When a fixed deadline conflicts with unfinished content, choose between reducing launch scope, adding approved resources or moving the date. Do not silently replace missing content with permanent placeholders. For the fictional supplier, exclusions also include customer accounts, payments, live stock availability, extra languages and ongoing marketing. Read Understand what shapes a business website estimate when assessing the commercial effect.

Define acceptance evidence before building

Acceptance criteria describe the evidence that demonstrates an agreed requirement works. Give each test an ID, steps, expected result, tester and approver. Keep screenshots, inventory checks or submission records with the result. The example below covers essential journeys; the full matrix must also cover the agreed browser, accessibility and performance requirements.

W3C recommends planning accessibility responsibilities and measurable milestones.[3] Assign content checks, implementation and testing separately, including the embedded form. If you promise WCAG 2.2 Level AA, scope evaluation of the relevant full pages and complete processes. A few keyboard checks or an automated report alone do not establish conformance.[4]

MDN describes performance budgets as limits that help prevent regressions.[5] Agree thresholds alongside tool version, device, connection, cache state and repeated runs. Web Vitals guidance distinguishes laboratory tests from real-user measurements; a simulated Lighthouse page load cannot measure INP, a responsiveness metric.[6] Separate launch testing from post-launch monitoring rather than promising field performance from a staging score.

Approve the baseline and handle changes fairly

Approve the scope records, inventory, constraints and acceptance matrix as one dated baseline: the reference agreement for delivery. Log later requests against requirement IDs. Record who can approve changes and how they affect cost, dependencies and dates. Flexibility works best when both sides can see what is changing.

• Defect: an uploaded dimension differs from the approved spreadsheet; correct it against the original requirement.
• Clarification: resolve wording without changing the agreed output or test.
• Substitution: exchange an agreed deliverable for another after assessing effort and dependencies.
• Addition: another language creates new content, approval, navigation and testing work.

For example, deferring the download section might release effort towards another language, but the exchange is not automatically equal. Confirm translation ownership, revise quantities, update cost and dates, and replace the affected acceptance tests before approval. Never leave the old and new versions competing as the delivery reference.

Questions to settle before requesting estimates

This research-assisted guide uses the primary sources linked above. Examples are illustrative unless explicitly identified otherwise. Check original documentation when implementing changes.