Why website projects blow out: seven decisions to resolve before design begins

Website projects are often described as though design and development consume all of the time and money. In practice, many overruns begin earlier.

The business has not agreed what success means. Nobody owns the content. A “simple CRM connection” has not been examined. Stakeholders enter after wireframes are approved. A launch date is fixed before the current URL estate is understood. Each gap appears manageable in isolation.

Then later work depends on the answer.

A change to audience priority alters the sitemap. A new business rule changes forms and integration logic. Late content exposes a missing page type. An unplanned redirect program affects launch. The team does not only make the decision; it reopens work built on the earlier assumption.

Unmade decisions do not disappear. They become change, delay, compromise or rework later.

The goal is not to eliminate every unknown before the project begins. It is to identify the decisions that could materially change the solution and resolve them at the least expensive responsible point.

The short answer: resolve seven decisions

Before design begins, clarify:

• The outcome and scope boundary
• Content responsibility and readiness
• Functionality, integrations and technical dependencies
• Stakeholders and decision rights
• Approval, revision and change control
• Migration, search and launch transition
• Operational ownership after launch

A controlled project does not require perfect certainty. It requires enough evidence, ownership and agreement for design to proceed without pretending consequential questions are only details.

Why the timing of a decision matters

An early decision usually changes documents. A late decision can change documents, interfaces, code, data, tests, training and launch plans.

Consider a trade enquiry form. During planning, deciding that enquiries must be routed by region and product category may take one workshop and a data-flow note. During wireframing, it may require a journey update. After design, new fields and states must be redrawn. After development, the team may need to alter validation, CRM mapping, notifications, permissions, test cases and analytics.

The business requirement did not become more valuable because it arrived later. Its change surface became larger.

This is why good planning is not administrative overhead. It protects work from being built on assumptions that the organisation could have tested earlier.

The Australian Government’s Discovery-stage guidance expresses the principle clearly: understand users and what the service needs to do before prototyping and building. A commercial website project may use a lighter process, but the dependency remains.

Detail, uncertainty and risk are not the same

Not every unanswered question deserves paid Discovery.

The final wording of a standard button is a detail. The question of whether that button creates an ecommerce order, a quotation, a CRM case or an approval workflow is consequential.

Use three tests:

• Impact: could the answer change architecture, scope, effort, content, risk or viability?
• Evidence: can the answer be confirmed through a brief and focused conversation, or does it require research, workshops, system access or technical validation?
• Reversibility: would a wrong assumption be easy to change later, or would it invalidate dependent work?

Low-impact gaps can remain in an ordinary action list. High-impact, low-evidence and hard-to-reverse questions need explicit resolution before implementation commitments are made.

That resolution can occur through a stronger brief, targeted technical validation or paid Discovery, depending on the number and consequence of the unknowns.

Decision 1: what outcome and scope boundary are being approved?

“Build a new website” does not define a project.

Start with the website’s business responsibility:

• Strengthen credibility
• Generate qualified enquiries
• Support transactions
• Provide self-service
• Serve locations, members or partners
• Connect operational systems
• Replace a risky or unsupported platform

Then define the boundaries.

Audiences and journeys

Identify priority audiences and what each must accomplish. More audiences do not automatically mean greater technical complexity, but competing journeys affect architecture and content.

Pages, content types and functions

List the known page templates and structured content types, such as services, locations, people, resources, products or projects. Record functions separately: forms, search, filters, accounts, payments, calculators and integrations.

Included and excluded work

State whether content writing, content entry, photography, SEO migration, accessibility evaluation, third-party fees and ongoing support are included, optional or client-owned.

Measures of success

Choose measures the website can credibly influence: qualified enquiries, completed transactions, task completion, appointment bookings, content findability or operational efficiency. Do not promise a commercial result that depends on media, price, sales capacity or other factors outside the build.

A scope boundary is not a refusal to adapt. It is the baseline from which change can be discussed transparently.

Decision 2: who will create, approve and enter the content?

Content is not a box filled after design. It determines hierarchy, component needs, page length, search relevance and trust.

Before wireframes, decide:

• What content exists and what condition it is in
• What will be retained, rewritten, merged or removed
• Which new content is required
• Who writes and fact-checks it
• Who approves brand, legal and technical claims
• Who supplies and licenses imagery
• Who enters content into the CMS
• Which date each content set must be ready

“The client will supply content” is not a complete plan. Does that mean final approved copy for every template before design, or raw source material that the agency will structure and edit? Does the client have the internal time and authority?

Late content often exposes false assumptions. A short placeholder hides that the real service page needs comparison tables, proof, related resources, an FAQ and a detailed form. The layout then changes after component decisions have been approved.

Use representative real content during wireframing and design. Prioritise the pages that test the system: the longest service, the most complex product, the location with unusual details and the resource with several media types.

For a large estate, content inventory and migration may be a workstream in its own right.

Decision 3: what must the website do, and which systems does it depend on?

Functionality should be described as business behaviour, not feature labels.

“CRM integration” needs answers:

• Which records are created or updated?
• Which system owns each field?
• What triggers the exchange?
• Is the flow one-way or two-way?
• How are identity, duplicates and consent handled?
• What happens when the CRM is unavailable?
• Who monitors and supports it?

The same applies to ERP, product, warehouse, payment, booking, authentication and marketing systems.

Map rules and exceptions. A product configurator is not only a sequence of screens. It may contain compatibility logic, pricing, exclusions, regional availability, quotation rules, administration and data dependencies.

Obtain current vendor documentation and appropriate access before promising feasibility. Existing integrations may rely on undocumented manual steps or a vendor-specific extension that does not support the new requirement.

Security, privacy, accessibility, performance and availability also belong here. Australia’s Secure by Design guidance treats security as a lifecycle responsibility. Adding it at final testing is too late to influence architecture, permissions and data handling.

If the functionality and systems are well documented, they may fit a defined implementation. If business rules, APIs, data ownership or failure handling remain material unknowns, paid Discovery is the responsible next step.

Decision 4: who represents the users and who can decide?

Stakeholder participation and decision authority are related but different.

The project may need input from marketing, sales, service, operations, technology, security, privacy, content owners, locations and executive sponsors. Not everyone should approve every detail.

Define:

• Project sponsor
• Day-to-day project owner
• User and operational representatives
• Technical and compliance reviewers
• Content owners
• Stage approvers
• Final escalation authority

Bring essential stakeholders in at the stage where their knowledge can change the decision. Inviting the integration owner after design creates avoidable risk. Asking every executive to comment on every component creates avoidable delay.

A RACI or similar responsibility model can help, but the document is not the outcome. People must understand their role, attend required sessions and respect the agreed decision process.

Also plan for absence and turnover. A single approver who is unavailable for three weeks can stop a project even when the agency work is ready.

Decision 5: how will approvals, revisions and change work?

Projects need a visible path from feedback to decision.

For each stage, confirm:

• What is being approved
• Who consolidates feedback
• How many review rounds are included
• When feedback is due
• What acceptance means for dependent work
• How reopened decisions are handled
• What constitutes an adjustment or scope change
• Who can approve budget and timetable changes

Consolidated feedback matters. Ten comments from ten people may conflict. The client project owner should reconcile them before they become agency direction.

Set a change process before the first change occurs. A useful change note records the request, reason, affected deliverables, cost or capacity, timetable, risk and approver. This gives the sponsor a real choice: approve, defer, replace another requirement or reject.

Avoid treating every change as failure. Learning is expected in digital work. The purpose of change control is to make the consequence visible, not to prevent improvement.

Stage approval should also be meaningful. Approving a sitemap while reserving the right to add entire audiences later is not approval. Record assumptions and open issues explicitly.

Decision 6: what must migrate, and how will launch be protected?

A website replacement changes more than screens.

Inventory what must move or remain available:

• Pages, posts and documents
• Products, categories and media
• Users, accounts and permissions
• Customer or member data
• Orders, bookings or records
• URLs, metadata and redirects
• Analytics and consent configurations
• Domains, DNS and certificates
• Integrations and scheduled processes

Quantities and data quality matter. Migrating 500 clean, structured products differs from reconciling 500 products with inconsistent identifiers and duplicate imagery.

Search transition requires early decisions. Google’s site-move guidance recommends creating old-to-new URL mapping, implementing redirects, testing and monitoring. Those tasks need the final information architecture and a current-site inventory; they cannot be invented safely on launch day.

Build a transition plan covering content freeze, final data sync, acceptance, deployment sequence, DNS responsibility, validation, rollback decision, communications and post-launch monitoring.

Emote may advise on hosting requirements, coordinate with a suitable hosting partner or work with the client’s appropriate host. Emote does not sell or directly provide hosting infrastructure. The production environment, credentials, access and support responsibility should be confirmed before launch planning.

Decision 7: who owns the website after go-live?

Launch transfers the platform into an operating environment. Decide how it will be managed before delivery finishes.

Confirm ownership for:

• Content publishing and governance
• User access and permissions
• Platform, plugin and extension updates
• Security patching and incident coordination
• Backups, monitoring and recovery
• Domain, DNS and hosting relationships
• Integration failures
• Analytics and consent configuration
• Search and content optimisation
• Enhancements and roadmap
• Vendor licences and renewals

Separate the after-launch categories. A short functional warranty corrects eligible delivery defects. Maintenance covers routine platform care. Support addresses operational requests and troubleshooting. Enhancements add or change capability. They are not one unlimited obligation.

The operating model should match business criticality. A brochure website updated quarterly has different needs from an ecommerce platform processing daily revenue or a portal supporting customer operations.

If nobody owns continuous improvement, the website begins ageing on launch day.

Make decisions visible in one register

Meetings do not guarantee decisions. Use a decision register throughout planning and delivery.

For every consequential item, record:

• The decision required
• Current evidence
• Options or recommendation
• Accountable owner
• Deadline based on dependent work
• Consequence if unresolved
• Status and approval record

Separate decisions from risks and actions. “Confirm CRM data owner” is an action. “CRM is the source of truth for contact status” is a decision. “CRM API access may not be available for testing” is a risk.

Review the register at every governance meeting. Escalate decisions before they block production, not after the delivery date moves.

Give each decision a latest safe date, not an arbitrary meeting date. The deadline should be based on the first dependent activity that would otherwise proceed on an assumption. A navigation decision may be needed before wireframes; a payment-flow decision before interface design; production access before release rehearsal. If the date passes, the sponsor should choose among three explicit responses: accept the documented assumption, move the dependent work or change scope. That makes the schedule consequence visible and prevents a quiet placeholder from becoming an accidental commitment. Superseded decisions should remain in the history so later teams can understand why related work changed.

When a brief is enough and when Discovery is warranted

A strong brief can support a template-led or focused custom proposal when:

• Outcomes and audiences are clear
• Functionality is standard or well understood
• Content and migration are manageable
• Integrations are absent, standard or documented
• Decision-makers are aligned
• Non-functional requirements are proportionate

Paid Discovery becomes credible when several consequential decisions require evidence and cross-functional agreement, such as portals, complex ecommerce, custom workflows, multiple integrations, large migrations, multisite architecture or formal security and compliance obligations.

Discovery should not merely produce more documents. It should reduce decision risk and create a decision-ready blueprint: requirements, journeys, technical direction, content and migration plan, governance, risks, implementation pathway and indicative programme.

The public Primary Dental case study illustrates this kind of interconnected complexity: more than 60 locations, content consistency, multiple integrations, search migration, transition and security advisory. It should not be treated as proof that every multi-location website needs the same process.

Frequently asked questions

Can a website project ever begin with uncertainty?

Yes. Every project contains uncertainty. The requirement is to identify which unknowns are material, assign owners and resolve them before dependent commitments become unsafe.

Is scope change always the client’s fault?

No. Change can result from learning, market events, agency misunderstanding, vendor changes or client decisions. Clear assumptions, evidence and governance help the parties respond fairly.

Should design wait until every word is final?

Not always. Design can progress with representative approved content and a reliable content model. Critical pages, lengths, media and responsibilities should be understood before the system is fixed.

Do all integrations require paid Discovery?

No. A standard, documented, low-risk integration may fit defined scope. Discovery is appropriate when data, rules, security, access or failure handling could materially change the solution.

How many stakeholders should approve the website?

Use the smallest credible approval group, supported by input from necessary subject-matter representatives. Decision rights should be explicit.

Can good project management prevent every blowout?

No. External events and genuine discovery can change a project. Good governance makes the change visible early and supports an informed response.

Resolve the expensive questions while they are still decisions

Website projects do not need perfect certainty. They need deliberate uncertainty management.

Agree the outcome and boundary. Give content an owner. Define functionality and dependencies. Involve the right stakeholders. Establish approvals and change control. Plan migration and transition. Assign operational ownership.

When those decisions are visible early, design can solve the right problem and development can build against agreed rules. When they remain hidden, later phases carry the cost.

Explore Emote’s Digital Transformation and Websites and eCommerce capabilities.

If your website project contains material unknowns that cannot be resolved through the brief, book an initial meeting with Emote. Emote will help identify whether targeted clarification, a defined implementation or paid Discovery is the smallest credible next step.