Start with the problem, not a list of features
A website project often begins with requests such as “make it look modern” or “add an events page.” Those ideas may be useful, but they do not yet explain what the organization needs to accomplish. Start by asking what is difficult today. Are visitors unable to find service details? Is staff time spent answering questions the site could address? Is an important enquiry form hard to use? A clear scope links the work to problems the team can recognize and check later.
Write a short project brief that names the organization’s goals, its main audiences and any constraints already known. For a community organization, one goal might be to help people understand who can use its services and how to get in touch. A constraint might be that one staff member has limited time to maintain the site. This brief gives the team a basis for choosing what belongs in the project.
Translate goals into visitor tasks
Next, describe what people come to the website to do. Use plain statements: “A first-time visitor can find eligibility information,” or “A potential volunteer can learn what is involved and submit an enquiry.” Include the needs of people using phones, keyboards or assistive technology. These tasks are more useful for planning than a long list of page names because they reveal the information and interactions each page must support.
Choose a small number of priority tasks and map each one to a likely route through the site. For example, someone seeking a service may need a clear entry point, a description of what is offered, practical details and a contact option. If the organization does not have those details written down, content preparation becomes part of the project. This exercise also exposes unnecessary features: a complex account system may not help visitors whose main task is simply to find accurate contact information.
Define what will be delivered
Turn the priority tasks into a deliverables list that another person could understand. Instead of “improve content,” specify which pages will be written or revised, who supplies the facts and who approves the wording. Instead of “make the site accessible,” describe the planned checks, such as reviewing heading structure, keyboard navigation, form labels and text alternatives for meaningful images. These details do not guarantee a perfect result, but they make the expected work clearer.
Record what is outside the project as well. A scope might include reorganizing the main navigation and updating ten core pages, while excluding a new booking system and a full archive migration. Document known dependencies, such as access to the existing website, brand assets or decisions about service names. If an estimate or schedule depends on those inputs, say so. An explicit boundary helps a small team avoid treating every good idea as an immediate requirement.
Agree on responsibilities and decisions
Website work can stall even when the deliverables are clear if nobody owns the decisions behind them. Name a project lead, a person who can approve content and design, and the people who will provide specialist information. Decide how feedback will be collected and when it is due. For a small team, one shared feedback document and a single decision-maker may be easier to manage than separate comments arriving by email.
Build review points into the workflow. The team might first approve the page list and content priorities, then review sample layouts, then check the working site against agreed visitor tasks. At each point, ask whether the work serves the original goals, not only whether everyone likes how it looks. Keep a brief record of decisions so that new participants can see why a choice was made.
Plan for change and for life after launch
A scope should be firm enough to guide the project but flexible enough to handle discoveries. Agree on a simple change process: describe the new request, explain why it matters, assess its effect on time and effort, then decide whether to add it, exchange it for another task or leave it for a later phase. This keeps the conversation focused on priorities rather than on whether a request is a good idea in isolation.
Finally, define what “done” means. Before launch, check that priority tasks work on common screen sizes, content has been approved, forms reach the right people and the team knows how to make routine updates. Decide who will maintain key pages and how often their details should be reviewed. A website project is better scoped when it includes a workable handover, not just a launch day.
