Most website delays are not coding problems. They are decision and dependency problems: an unclear requirement, content that has not been written, an integration that was never investigated or late feedback from someone who should have been involved earlier.
Good planning does not mean trying to predict every detail before work begins. It means defining the outcome, exposing the risky parts and agreeing who will make decisions. This gives the project enough structure to move quickly without creating expensive rework later.
A website brief often begins with pages and functions: a homepage, service pages, customer accounts, online payments and a news section. That describes possible outputs, but it does not explain what the website needs to achieve.
Begin with a short statement of purpose. For example:
This distinction matters because the best solution may not be the one originally imagined. GOV.UK guidance on the discovery phase recommends understanding users, constraints and the underlying problem before committing to a build.
Once the purpose is clear, define how success will be measured. Depending on the project, useful measures could include qualified enquiries, completed purchases, account registrations, fewer support calls or successful completion of an important task. Avoid vague targets such as “more engagement”. GOV.UK's guidance on setting performance metrics recommends connecting measurements to the service's purpose and the outcomes it should produce.
A website can involve many contributors, but it needs one accountable project owner. This person does not have to write every page or make every technical choice. Their role is to gather internal views, resolve disagreements and provide the development team with a clear answer.
Without that route for decisions, feedback tends to arrive in fragments. Marketing approves a design, operations requests a different workflow and a director introduces a new objective shortly before launch. Each comment may be reasonable on its own, but together they create uncertainty and rework.
Agree the following before the project gathers pace:
If several departments are involved, create a simple approval map. Legal, compliance, IT and senior management reviews are much easier to manage when they appear in the plan rather than becoming urgent requests immediately before launch.
A useful scope records more than what will be built. It should also identify what is excluded, what remains uncertain and what can wait until a later phase.
Divide requirements into three groups.
These are the capabilities without which the website cannot achieve its main purpose. They might include an enquiry journey, product checkout, secure account access or an integration with an essential business system.
These features would improve the service but should not prevent the first version from launching. Examples could include advanced reporting, secondary content filters or additional account management tools.
These are ideas worth recording without designing the entire project around them. The initial build should leave room for sensible development, but it does not need to solve every possible future requirement.
This approach prevents every suggestion from becoming an immediate commitment. It also supports more honest budgeting. If the project includes unusual workflows, extensive database operations or internal administration tools, discuss whether it is really a standard website or a piece of bespoke software with a public-facing website attached. Recognising that distinction early leads to better technical decisions and fewer surprises.
A page list helps to organise content, but it does not show how the website should work. User journeys reveal the steps people need to take, the decisions they face and the information required at each stage.
Concentrate first on journeys that matter commercially or operationally. For each one, ask:
That final question is easily overlooked. A polished enquiry form is not useful if submissions reach an unattended inbox or create more manual work than the process it replaced.
For an e-commerce website, map more than the checkout. Consider product data, stock, delivery rules, discounts, tax, payment failures, confirmation messages, refunds and how orders reach the people responsible for fulfilling them. Complexity hidden behind the screen still affects the scope, cost and schedule.
Content often delays a website because it appears deceptively simple. A team may expect to copy text from the old website, only to discover that it is out of date, duplicated, poorly structured or based on services that have changed.
Create a content inventory near the start of the project. For every planned page, record its purpose, owner and status. Decide whether existing material will be retained, rewritten, combined or removed.
Apply the same process to:
If something requires permission, professional production or approval from another organisation, give it a named owner and deadline. “The client will supply it” is not a useful project plan unless a particular person has accepted responsibility.
Do not wait for the final design before writing. Draft content helps designers work with realistic headings, calls to action and information priorities. It also exposes gaps in the proposed structure while changes are still relatively straightforward.
A website may need to communicate with payment services, customer relationship management systems, stock databases, booking platforms, email providers or older internal software. Never assume an integration will be straightforward simply because two products advertise an API.
Technical discovery should establish:
GOV.UK's guidance on choosing technology recommends examining existing systems and data sources, then using prototypes to test assumptions, interfaces and technical constraints. A small proof of concept can be much cheaper than discovering during the main build that a critical system cannot supply the expected information.
Access is a dependency too. Gather domain registrar details, hosting credentials, analytics accounts, email settings and supplier contacts well before launch. Finding out who controls an old domain should not become a last-minute investigation.
Accessibility affects colour choices, navigation, forms, keyboard use, content structure, documents and the way editors add material through the content management system. It cannot be dealt with properly as a final automated check.
The Web Accessibility Initiative recommends evaluating accessibility throughout development, when problems are easier to address. It also makes clear that automated tools cannot determine accessibility on their own, so knowledgeable human evaluation remains necessary.
Privacy needs the same early attention. Identify what personal information the website will collect, why it is needed, where it will go, who can access it and how long it should be retained. The Information Commissioner's Office explains that data protection by design and by default means considering these issues during design and throughout the system's lifecycle.
Security requirements should also reflect the risks of the project. Discuss account permissions, authentication, sensitive data, backups, software updates, monitoring and how security problems will be reported and corrected. The National Cyber Security Centre's secure design and development guidance recommends integrating security measures throughout the development lifecycle rather than treating them as a later addition.
More detailed legal or security advice may be appropriate for websites involving customer accounts, uploaded documents, sensitive enquiries, employee information or substantial tracking. The development team still needs clear requirements in order to design and implement the right controls.
“I don't like it” is difficult feedback to act on. So is a collection of contradictory comments forwarded from several email threads.
Ask reviewers to assess work against the agreed goals, requirements and user journeys. Helpful feedback identifies a problem: the priority of the page is unclear, an important question is unanswered or a user may not understand the next step. It should not jump straight to a prescribed solution before the problem has been discussed.
Collect comments in one agreed location and provide one consolidated response to the development team. Set review windows in advance and make it clear that approval closes a stage. Later changes can still be requested, but they may affect the cost or schedule because dependent work has already begun.
Use a simple change process for requests outside the agreed scope:
This is not bureaucracy for its own sake. It protects the project from circular discussions while giving stakeholders a fair opportunity to contribute at the right time.
A realistic schedule distinguishes between work the development team controls and work that depends on the client or a third party. Design, development and internal testing may be relatively predictable. Photography, product data, board approval or access to an external platform may not be.
For each milestone, record:
A target launch date can be useful during early discussions, but it should not become an unconditional promise before the scope and major dependencies have been investigated. If a fixed date is genuinely essential, the scope may need to remain flexible.
Allow time for testing and correction rather than treating launch as the moment development ends. Testing should cover real devices and browsers, content, forms, permissions, integrations, automated emails and important user journeys. For websites expecting high or unpredictable traffic, capacity and performance testing should also form part of the plan. GOV.UK provides further guidance on capacity planning and performance testing.
Launching a replacement website involves more than pressing a publish button. The team may need to coordinate domain settings, hosting, backups, analytics, search tools, form recipients, staff training and a final content freeze.
If page addresses are changing, create a redirect map from old URLs to the most relevant new pages. Avoid sending every old address to the homepage. Google's guidance on website moves with URL changes recommends mapping old and new URLs, testing redirects and monitoring traffic and crawl errors after the move.
A practical launch plan should include:
Agree ongoing ownership before the website goes live. Someone must be responsible for updating content, managing users, monitoring integrations, renewing services and arranging technical maintenance. Appropriate hosting and support should be part of the operational plan, not an afterthought.
The best website plans are clear without pretending that everything is already known. They remove avoidable uncertainty, make risks visible and give the team a reliable way to reach decisions.
Pedwar's customer journey explains how a bespoke project can progress from the initial discussion through planning, design, development and support. If you are preparing a new website or a more complex digital system, you can also discuss the project with Pedwar before committing to a scope or launch date.
We're proud to have been recognised as Wales' Most Trusted Web Design & Development Company for 2025. This award reflects our commitment to delivering exceptional digital solutions and outstanding client service that sets the standard for excellence.
