A useful website scope is a set of decisions, not a list of requested pages. It tells the team what matters, what is excluded, who can make trade-offs and how the finished work will be accepted. Enterprise projects often span several departments and systems, so assumptions left unspoken at the start can become costly later. Write down what is known, what needs discovery and what would change the plan.
Agree who decides what
Identify a sponsor who owns the outcome, a day-to-day product owner and the people responsible for content, technology, security and regional approval. Record which decisions each can make and how disagreements are resolved. A review group can advise without giving every member a veto on every detail. Set a realistic response time for approvals so delayed decisions appear in the plan rather than silently consuming delivery time.
For example, in a hypothetical multinational organisation, a central team may approve the navigation and design system while regional editors approve their local service content. If a regional request changes a shared template, the product owner decides whether it belongs in the common release or a later phase. That division should be explicit before design begins.
Discover the current estate
Inventory pages, documents, languages, templates, forms, redirects and third-party services. Note who owns each item, whether it is accurate, and whether it should move, merge, be rewritten or be retired. Review search and analytics signals alongside interviews and support inquiries; numbers show behaviour, not necessarily intent. Identify gaps in content production capacity as early as gaps in code.
Write an in-scope and out-of-scope list covering sites, markets, content creation, integrations and post-launch support. “Redesign the website” is too broad to estimate. “Migrate approved service pages for two regions, with three agreed templates; archive unapproved legacy downloads” gives the team something testable. Record open questions rather than treating them as included by default.
Prioritise journeys and acceptance
Choose the most important audience journeys and describe their start, decision points and successful outcome. Rank them by user need, organisational value and delivery risk. For each, specify acceptance criteria in plain language. A hypothetical support journey could require a visitor to find the right regional contact from a product page, use a working form and receive an understandable confirmation. Test that journey on mobile and by keyboard, including a failed submission.
Separate essential launch journeys from enhancements. If a feature is deferred, say what the initial experience will do instead. Avoid calling everything “phase one”: a genuine priority order helps when time or budget changes. Confirm the proposed flows with the people who handle the work today and with representative site visitors where possible.
Expose technical and operational dependencies
For each integration, name the system owner, data direction, authentication approach, environments, test access and failure behaviour. Confirm whether an API exists and who can change it. Specify non-functional requirements as reviewable targets: accessibility checks, supported devices and browsers, performance budgets, availability expectations, security review, privacy handling, monitoring and backup or recovery responsibilities. Involve the responsible specialists; do not assume the website team alone can sign off every requirement.
Include migration rules for old URLs and files, localisation responsibilities, and training for editors who will maintain the new content model. Clarify whether translation and content entry are provided by the project team or the organisation. Define the handover: documentation, permissions, escalation routes and the owner of ongoing updates.
Estimate with uncertainty visible
Record risks and dependencies beside the estimate, not in a separate document nobody reads. Unknown content quality, unavailable API access or delayed approvals can all affect the range. Provide estimate ranges with assumptions and a point at which they will be refined after discovery. Agree a change-control process: describe the new request, its effect on cost and schedule, the decision-maker and what is displaced if the budget stays fixed.
Plan a phased rollout when it reduces risk: a limited set of templates or markets can validate the content process before the full migration. Define what must be true to progress to the next phase, how feedback will be triaged and how a release can be rolled back if necessary. A phased plan still needs a coherent first release, not a collection of unfinished pages.
Scope acceptance checklist
- Are decision rights, reviewers and approval timings recorded?
- Is the content inventory linked to migration and ownership decisions?
- Are boundaries, priority journeys and testable acceptance criteria agreed?
- Does each integration have a named owner and a failure plan?
- Are quality requirements, localisation, editor training and handover included?
- Do estimate ranges state assumptions, risks, change rules and release gates?
Review the scope with the people who will approve, build and operate the site. If they cannot answer these questions consistently, discovery is not finished. A clear scope gives everyone a basis for sensible trade-offs when new information arrives.