Is your organisation ready for a website redevelopment? An internal readiness checklist

A website redevelopment often begins with a deadline: a rebrand, an expiring platform, a campaign, a leadership commitment or a growing list of customer complaints. The urgency may be entirely legitimate. It does not necessarily mean the organisation is ready to make a credible delivery commitment.

Readiness is not about having every answer before speaking to an agency. It is about knowing which decisions are settled, which internal actions have owners and which consequential unknowns need to be resolved before scope, price or timing can be fixed. A readiness check makes those conditions visible.

The strongest website projects treat the organisation as part of the delivery system. Agencies can research, design and build, but they cannot replace executive decisions, provide missing source-of-truth content, approve legal positions or create unlimited stakeholder capacity. Those dependencies need the same attention as the platform and design.

The short answer: use four readiness states

Assess each dimension as ready, action required or resolve through Discovery. Ready means the evidence and owner are clear enough to proceed. Action required means the organisation can complete a known task, such as appointing an approver or gathering existing documentation. Resolve through Discovery means the answer is not yet known and could materially change users, content, architecture, data, integrations, security, governance, scope or cost. If the underlying need is still uncertain, first decide whether to rebuild, redesign or optimise.

The objective is not a perfect green score. It is a realistic plan. A low-risk content task can continue while a technical dependency is investigated. A major launch date should not be promised if the source system, approval pathway or migration volume remains unknown.

• Ready: evidence, owner and decision are clear enough for the next gate
• Action required: a known internal task needs an owner and date
• Discovery required: a material unknown needs structured investigation
• Blocked: a dependency is unavailable and the affected commitment must be resequenced

A project can be ready in some dimensions and exposed in others.

Use four readiness states consistently

• Ready: sufficient evidence, ownership and access exist to proceed.
• Internal action required: a known task needs an owner and decision date.
• Resolve through Focused or Full Website Discovery: a consequential question needs structured investigation.
• Blocked or resequence: an unavailable dependency makes the current commitment unsafe.

Do not enter a fixed implementation commitment until the sponsor, accountable owner, representative content, critical system access, approval path and material unknowns are visible.

1. Confirm the sponsor, owner and decision rights

A website project needs an executive sponsor who can protect its priority, resolve major conflicts and approve the business direction. It also needs a day-to-day owner with enough time and authority to coordinate stakeholders, evidence, reviews and decisions. These roles may be held by the same person in a smaller organisation, but the responsibilities should still be explicit.

Map who advises, recommends, approves and is informed across brand, content, marketing, technology, privacy, security, legal, accessibility, sales, service delivery and operations. Then nominate the final decision-maker for each major area. A broad steering group can advise, but it cannot be the answer to every approval question.

Set response expectations before design begins. If a review needs five business days, place that dependency in the plan. Define what happens when feedback conflicts, when an approver is unavailable or when a decision misses its date. Silent decision processes become visible schedule risk later.

2. Define the problem, audiences and success evidence

A readiness check should be able to state what the current website prevents people or the organisation from doing. Poor visual appeal may be part of the problem, but it is rarely the complete business case. Consider difficulty finding services, low-quality enquiries, inaccessible interactions, fragmented content, slow publishing, broken system handovers or operational workarounds.

Identify priority audiences through their needs and tasks, not only broad demographic labels. Include people who use assistive technology, have limited digital confidence, access the site on constrained devices or complete infrequent but high-consequence tasks. The Australian Government Digital Service Standard emphasises understanding users, inclusion and measurable service improvement. Its formal requirements apply within its stated government scope, but the underlying planning principles are useful more broadly.

Gather available baseline evidence, such as analytics, search data, enquiry quality, call-centre themes, customer feedback, publishing effort and accessibility findings. Note the limitations of each source. Agree which signals would indicate improvement, without pretending that one headline metric represents the whole experience.

3. Assess content readiness and ownership

Content is often the largest client-side workstream. Before committing to delivery, understand the approximate estate: pages, files, forms, media, product or service data, people, locations, resources, policies and other structured information. Identify what is duplicated, obsolete, legally sensitive or owned outside the project team.

Nominate content owners and approval paths. Decide which source is authoritative when several documents disagree. Estimate the work to retain, improve, combine, create, migrate or retire content. Final copy does not need to exist before every design activity, but representative real content, content types, likely volumes and approval responsibilities need to be known before layouts and migration assumptions harden.

Protect content time in the project plan. Subject-matter experts need notice, context and realistic review windows. Copywriting, data preparation, media rights, alternative text, document remediation, content entry and migration quality assurance are different activities. Grouping them under a single line called content can hide substantial effort.

4. Make technology and data dependencies visible

Create a current-state register at the appropriate level. Include the CMS, domains, DNS, hosting provider, forms, CRM, analytics, consent tools, identity services, search, ecommerce, booking, payment, email, product data, ERP or other systems connected to the website. Record the internal owner, external supplier, available documentation and access status for each.

The purpose is not to design the future architecture during a readiness workshop. It is to identify dependencies and uncertainty. An integration being described as available does not prove that the required data, permissions, limits, environments and failure handling are understood. A content export existing does not prove that relationships, media and metadata will migrate cleanly.

Route consequential unknowns into Full Website Discovery where they involve ecommerce, subscriptions, portals, authentication, complex data, integrations, significant migration, multi-region delivery, regulated workflows or material security and governance. A single straightforward public corporate or lead-generation site may suit a more focused pathway when all relevant boundaries fit.

5. Confirm risk, accessibility and specialist responsibilities

Identify the obligations and organisational standards that affect the website: privacy, information security, records, brand, accessibility, consumer or industry requirements, and any contractual controls. Name the qualified person who can interpret and approve each area. Do not ask the web project manager or agency to invent a legal position by default.

W3C guidance recommends integrating accessibility throughout planning, production and ongoing operation, with assigned responsibilities and resources. Automated tools can support evaluation, but they do not provide complete accessibility assurance. Similarly, a security scan or privacy checklist cannot replace the relevant specialist’s judgement about the organisation’s circumstances.

Define review gates and evidence. Will a specialist review requirements, designs, components, content, testing or release? Who owns remediation decisions? What must be complete before launch? Clarity here prevents non-functional requirements being discovered as late-stage surprises.

The consequence of the unknown determines the response.

6. Test capacity, budget and timing honestly

The external implementation fee is only one part of readiness. Allow for internal project ownership, stakeholder reviews, content, data work, photography or video, licences, specialist advice, training, accessibility activity, migration, third-party services and post-launch operation. Hosting infrastructure is contracted and paid directly by the client to an appropriate provider; Emote may advise and coordinate but does not sell or resell it. Unresolved ownership and dependencies are common reasons website projects blow out.

Check actual stakeholder availability, not nominal job descriptions. Can product owners provide rules? Can legal reviewers meet the planned dates? Can IT create access and environments? Can the content team produce and approve the required material while running normal operations? A schedule based on unavailable people is not a schedule.

Map major external dependencies such as a rebrand, system replacement, campaign, regulatory date, contract expiry or data clean-up. Decide whether they should precede, overlap with or follow the website work. Stacking every initiative behind one immovable launch date increases coordination risk and can force weak decisions.

7. Plan how the website will operate after launch

A redevelopment is not ready if no one owns the website after it goes live. Name the service owner, content governance roles, technical contacts and suppliers. Define who can publish, approve, create new content types, manage users, respond to issues and prioritise improvements.

Separate the standard functional warranty from ongoing support, maintenance, optimisation and enhancements. A launch correction period does not fund continuous improvement. Likewise, a support arrangement does not automatically include strategy, content production, analytics or experimentation unless those services are expressly scoped.

Identify the operating budget, account ownership and documentation required for continuity. Domains, analytics, advertising, platform, app, licence and other critical accounts should be held or controlled under suitable client governance. Exit and handover requirements should be considered before supplier relationships change.

8. Turn gaps into a readiness action plan

Record each gap with an owner, evidence needed, decision date, consequence and next gate. Keep the plan at the level needed to govern readiness. A site-specific content strategy, architecture, migration plan, research programme or detailed roadmap is professional project work and should be scoped accordingly.

Proceed with known, reversible work where it does not prejudge material decisions. For example, securing system access, appointing owners and collecting existing research can begin early. Hold commitments that depend on unresolved architecture, data or governance. This protects momentum without turning optimism into scope.

• Name the gap and affected decision
• Classify it as internal action, a Focused or Full Website Discovery pathway, or external dependency
• Assign an accountable owner
• Define the evidence or approval needed
• Set a realistic decision date
• Record what cannot be committed until the gap closes

Assemble a minimum readiness evidence pack

A readiness pack should be compact enough to use and specific enough to reduce repeated questions. Include the approved problem statement, priority audiences and tasks, current sitemap or content inventory if available, brand guidance, known platform and integration register, analytics access, relevant research, specialist requirements, decision matrix and key dates. Label the owner, date and confidence of each item.

Do not wait for a perfect repository before beginning. Record where evidence is missing, stale or disputed. A clearly labelled gap is useful because it can be assigned and sequenced. An old spreadsheet presented as current truth is more dangerous because it encourages design and estimation against an assumption nobody has validated.

Control access appropriately. Security diagrams, customer data, contracts and supplier details may need restricted distribution or confidentiality arrangements. Provide agencies only the information needed at each procurement or Discovery stage, while ensuring shortlisted teams receive equivalent material for a fair comparison.

Pressure-test the launch date against internal work

A launch date becomes credible only when it includes client-side decisions and content, not only agency production. Work backwards through acceptance testing, content freeze, migration rehearsal, training, specialist approval, analytics validation and domain or infrastructure change. Identify the latest safe decision date for each critical dependency. Compare the plan with a realistic custom website timeline.

Separate a desired public date from a technical release date where that reduces risk. A controlled production launch can allow verification before a campaign announcement, provided the plan addresses search, redirects, data, integrations and stakeholder communication. The correct sequence depends on the project and should not be improvised in the final week.

Define what can be reduced, phased or held if evidence arrives late. Removing low-priority content or deferring a contained enhancement can protect quality. Compressing accessibility, security, migration or acceptance work to preserve the original date usually transfers risk to users and operations. Agree which controls are non-negotiable before pressure builds.

Recognise readiness warning signs

Several patterns deserve attention: no final approver, a deadline without a dependency plan, a platform selected before requirements, content described as a later task, integrations owned by unnamed suppliers, inaccessible source systems, legal review expected after build and no post-launch owner. None automatically stops the project, but each needs an action or decision gate.

Another warning sign is false agreement. Stakeholders may all support a redevelopment while holding different views of its purpose. Ask each decision-maker to state the priority audience, principal business outcome and most important constraint. Material differences should be resolved or explicitly recorded before they appear as contradictory design feedback.

Finally, test whether the organisation can say no. If every requested feature, audience and stakeholder preference must be included, priorities are not yet real. A ready governance model can make trade-offs, document them and protect the experience from unmanaged accumulation.

Review readiness again at major gates. New evidence, staff changes or supplier constraints can alter a previously sound assumption. A short, recorded reassessment before design approval and launch preparation keeps the plan current without reopening every settled decision.

Role titles vary, but ownership cannot remain collective and implicit.

Frequently asked questions

Do we need every piece of content finished before starting?

No. Design can begin once priority content types, representative real examples, likely volumes, owners and approval paths are credible. Final copy can progress in parallel when dependencies are explicit and managed.

Can urgency make an organisation ready?

Urgency can increase priority and justify faster decisions. It cannot create missing evidence, system access, approvals or stakeholder capacity. Use it to focus the readiness plan rather than to ignore dependencies.

Who should own a website redevelopment internally?

A day-to-day owner needs authority, time and access across the organisation. An executive sponsor should protect the business priority and resolve major conflicts. Content, technology and specialist responsibilities also need named owners.

Does a readiness checklist replace Discovery?

No. It identifies what is known, what the organisation can resolve and what requires structured investigation. Focused or Full Website Discovery is appropriate when the unresolved answer materially changes the solution, risk or commitment.

Should we choose the platform before checking readiness?

Usually not. Platform choice should follow the users, content, workflows, integrations, governance and operating model. A fixed organisational constraint may narrow the choice, but its effect should still be understood.

What if the organisation is not ready in every area?

Perfect readiness is not required. Separate low-risk actions that can proceed from material unknowns that block commitments. Assign owners, sequence the work and use an appropriate paid definition pathway where needed.

How Emote can help

Emote can help identify whether a redevelopment has enough evidence, ownership and internal capacity to proceed responsibly, and which uncertainties still affect the decision.

A contained project may move to a defined proposal. A straightforward site with material questions may suit Focused Website Discovery, while complex content, ecommerce, portals, integrations, data or governance may require Full Website Discovery.

If you are deciding whether your organisation is ready to proceed, book an initial meeting with Emote.