Blog

Working with a web design company goes well when the client owns the business truth, timely decisions, factual approval, and control of critical accounts while the agency owns discovery, professional recommendations, project leadership, design, development, testing, and a usable handoff. Shared decisions—priorities, tradeoffs, scope changes, and launch readiness—need one named final owner. If “everyone” owns an approval, congratulations: nobody does.

TL;DR: Do not arrive with a homemade sitemap, a preselected tech stack, and pixel instructions for a problem nobody has diagnosed. Bring the business facts, customer evidence, proof, access, constraints, and a decision-maker. Require the agency to lead the professional method, document responsibilities, explain tradeoffs, and prove what it delivered. Every dependency needs an owner, an input, a due point, and a stated consequence if it moves.

This guide begins after provider selection. If you are still comparing agencies, use our guide to choosing a web design company without getting trapped. If you are trying to understand the full buying journey, start with how to create a business website without buying the wrong thing.

Reviewed: August 2026. Conceptual review cadence: annually, or sooner if Scope Design changes its delivery process or standard project documents.

“Good collaboration” is too vague to run a website project

Nearly every agency promises collaboration. So do group projects where one person does all the work and four people change the font at the end.

The problem is not whether people are friendly, responsive, or invited to meetings. The problem is whether the next consequential item has a clear owner. Website projects stall when content is “being worked on,” access is “with IT,” approval is “circulating,” and a new feature is “probably included.” Those phrases are project purgatory wearing business casual.

A functioning relationship answers more useful questions:

• Who owns the business decision?
• Who owns the professional recommendation?
• What evidence or access is required?
• Who can approve the answer?
• When is that decision needed?
• What changes if it arrives late?
• How will the team know the work is accepted?

This is not bureaucracy for its own sake. It is how both parties avoid paying for confusion twice.

Use the Scope Design No-Limbo Project Map

The Scope Design No-Limbo Project Map gives every important dependency four fields:

1. Owner: one primary person accountable for moving it.
2. Input: the evidence, access, content, or decision required.
3. Due point: when it must arrive relative to the next dependent task.
4. Consequence: what changes in scope, schedule, cost, or acceptance if it moves.

The key word is primary. Several people may contribute. One person still needs authority to move the item. W3C’s draft Accessibility Roles and Responsibilities Mapping decision tree uses a similar distinction: one primary owner is accountable while secondary owners and contributors support the task. The guidance is specific to accessibility, but the ownership principle travels well.

The map is deliberately not “client owns the what; agency owns the how” in every situation. That shorthand is useful, but reality has seams. A client owns its pricing and legal claims. An agency should still challenge whether the information is clear. The agency owns the interaction design. The client should still flag that a proposed workflow contradicts how customers actually buy. Shared context does not require shared ambiguity.

What should the client prepare before kickoff?

You do not need to do the agency’s job before the agency begins. If you could correctly diagnose the problem, map the experience, write the content, design the interface, select the technology, and test the result alone, hiring the agency would be an oddly expensive social event.

You do need to bring the things only the business can supply.

A business result, not merely a page request

Explain what needs to change in the business and why it matters now. “We need a new homepage” describes a deliverable. “Qualified prospects cannot tell which service fits them, and sales keeps re-explaining the same distinctions” describes a useful problem.

Bring whatever baseline is available:

• current inquiries, sales stages, or booked appointments;
• important entry pages and traffic sources;
• common customer questions and objections;
• services or products the business wants to prioritize;
• operational steps after a visitor acts;
• known technical, legal, timing, or staffing constraints;
• what has already been tried and what happened.

Do not invent precision because the analytics are thin. Five useful sales-call observations can be more honest than a dashboard nobody trusts.

Our constraint-first website strategy guide explains why the requested deliverable is not automatically the real constraint.

Business facts and proof

The agency cannot manufacture the truth of your business. Prepare source material for:

• services, products, pricing context, and geographic availability;
• process, timing, limitations, and right-fit or wrong-fit conditions;
• qualifications, licenses, awards, and affiliations that can be verified;
• case studies, testimonials, outcomes, and permission to use them;
• team, location, contact, support, and policy information;
• existing photography, video, diagrams, documents, and brand assets;
• legal or compliance requirements identified by qualified advisors.

The material does not need to be pretty. It needs to be real. A chaotic folder of source documents can be organized. A beautiful claim with no evidence is just well-dressed bullshit.

An honest inventory of systems and access

List the systems the website touches: domain registrar, DNS, hosting, CMS, email, forms, CRM, scheduling, payments, analytics, search tools, advertising platforms, product data, inventory, customer portals, or legacy databases.

For each system, identify:

• the business owner;
• the current administrator;
• whether access still works;
• what data enters and leaves;
• whether the system must remain, migrate, or retire;
• known vendors, renewals, licenses, and dependencies.

Do not paste a password spreadsheet into ordinary email. Use controlled access, delegated roles, or a secure credential-sharing method appropriate to the system. The client should generally keep ownership of critical accounts while granting the agency the access required to do the work.

One accountable decision-maker

Stakeholders can contribute expertise. They do not all need veto power over every heading, color, and form label.

Choose one person who can:

• consolidate internal feedback;
• distinguish mandatory requirements from preferences;
• resolve contradictory stakeholder requests;
• approve scope, content, direction, and launch;
• understand the effect of a late decision.

The executive who appears for the first time at final review and overturns three months of approved work is not adding strategic oversight. They are becoming an undocumented project dependency with excellent timing.

Real internal capacity

Name the people who will attend discovery, locate records, review content, answer specialist questions, test workflows, and approve milestones. Put that work on their calendars.

The business does not need to be available every hour. It does need to be available when the project reaches a decision only the business can make. A deadline agreed by someone with no internal time is decorative.

What should the web design company own?

Client preparation does not excuse agency passivity. “Send us everything and tell us what you want” is not a professional process. It is order-taking with a mood board.

Diagnose before prescribing

The agency should turn the business problem into a testable project definition. That means examining the audience, offer, evidence, workflows, content, current performance, technical environment, constraints, and post-launch ownership before locking in the solution.

It should be willing to say that the requested feature is not the first thing to build. Our strongest real projects have become clearer when discovery exposed operational dependencies beneath the visible website request. That is not scope inflation. Done responsibly, it is the difference between solving the system and decorating the symptom.

Define deliverables, dependencies, and acceptance

The agency should state:

• what is included and excluded;
• what each phase produces;
• what the client must supply;
• which assumptions affect the estimate;
• how review and approval work;
• what counts as a revision or scope change;
• how delays affect the schedule;
• how the work will be tested;
• what “accepted” means;
• what the client receives at handoff;
• what happens after launch.

The AIGA Standard Form of Agreement for Design Services is useful professional context because it separates proposal-specific terms, client responsibilities, deliverables, reusable designer tools, intellectual-property options, and discipline-specific terms. It is a starting point, not personalized legal advice. Significant agreements deserve review by qualified counsel.

Lead the professional method

The agency should recommend the information structure, user journeys, content approach, visual system, technology, accessibility practices, performance requirements, test plan, and release method appropriate to the approved problem.

It should explain tradeoffs in business language. “We chose this because users need X and the system must support Y” is useful. “This is the trend now” is not a reason; it is a weather report from Dribbble.

Run a visible project

The agency should make the current stage, next decision, open dependencies, and schedule effect understandable. That does not require twenty-seven dashboards. It requires one reliable source of truth and communication people will actually use.

A reasonable process includes:

• a kickoff tied to the signed scope;
• named contacts and decision rights;
• a shared place for approved files and feedback;
• milestone presentations with specific review questions;
• written decisions and changes;
• early warnings when an input threatens the schedule;
• a clear route for urgent issues;
• launch and handoff criteria.

Prove the work before calling it done

The agency should test what it built. The exact plan depends on the site, but it commonly includes responsive layouts, key browsers, navigation, forms, email delivery, integrations, accessibility, search controls, analytics, redirects, content accuracy, performance risks, permissions, backups, and rollback readiness.

W3C’s planning guidance for web accessibility recommends documenting goals, scope, responsibilities, resources, acceptance testing, milestones, and ongoing monitoring. Accessibility is not one line the client can assume the developer “handled.” Its design, content, development, testing, procurement, and ongoing publishing responsibilities need owners.

How should client and agency decisions work together?

Some decisions cannot be thrown over the wall in either direction.

The agency is not entitled to make unapproved business commitments. The client is not entitled to overrule professional decisions without understanding the consequence. Either party can say no. Both should be able to explain why.

How to give design feedback without becoming the designer

Open Brain contains a simple design feedback loop adapted from progressive-design material:

1. Present the work.
2. Gather directed feedback.
3. Interpret what the feedback means.
4. Decide what to change.
5. Iterate.

The crucial distinction is that the client gives business and user feedback. The designer translates that feedback into design decisions.

Describe the problem you see

Useful feedback sounds like:

• “Our highest-margin service feels secondary, but it is the main reason we are investing.”
• “Customers use these two terms interchangeably, so this label may confuse them.”
• “The people approving a purchase need the certification before they will contact us.”
• “Most customers call from the job site; this action needs to work without completing a long form.”

Less useful feedback sounds like:

• “Make it pop.”
• “Can we make the logo bigger?”
• “I don’t like that blue.”
• “Move this three pixels left.”
• “My spouse prefers the competitor’s homepage.”

Preferences are allowed. Just label them as preferences. A personal reaction should not impersonate user research or a business requirement.

Match feedback to the stage

Early concept review should ask whether the team is solving the right problem and exploring the right direction. Wireframe review should focus on hierarchy, content, tasks, and flow. Visual review should evaluate brand fit, clarity, consistency, responsive implications, and accessibility. Functional review should test real tasks and edge cases.

Reopening the entire strategy during final visual polish is expensive. Arguing about button radius during discovery is merely adorable.

Consolidate before sending

The client should resolve internal contradictions before handing feedback to the agency. If sales wants prominent pricing and leadership refuses to discuss price, the designer cannot fix the organizational disagreement with typography.

Send one review containing:

• mandatory factual or legal corrections;
• unmet requirements;
• user or operational evidence;
• business-priority concerns;
• clearly labeled preferences;
• the final decision where stakeholders disagreed.

Explain why

“Change the headline” is an instruction. “The headline implies this is only for enterprise buyers, but most qualified customers are regional owner-led firms” gives the agency a problem it can solve.

The why protects the project from blindly implementing a symptom.

Does all website content need to be finished before design starts?

No. It does need an owner, a production plan, and enough real substance to shape the experience.

Early discovery and structural work can begin before every sentence is polished. The team still needs to understand:

• the main claims and offers;
• the audiences and decisions;
• the content types and approximate volume;
• available proof;
• key actions and workflows;
• required legal or policy material;
• who writes, reviews, and approves each item.

Designing an entire site around lorem ipsum and pouring real content into it at the end is how teams discover that the actual business has inconvenient things such as explanations, tables, exceptions, and customers.

Content responsibility should be explicit:

The business remains accountable for the truth and rights behind what it publishes even when the agency writes or edits the material.

Who should own the domain, hosting, CMS, and source files?

The business should generally control the domain registration and have appropriate ownership or administrative control of hosting, CMS, analytics, search, email, and other critical business accounts. The agency should receive the access needed to perform its work, not become the only human who can reach the fuse box.

Ownership is more specific than “we paid for the website.” Separate:

1. Client materials: the client’s existing brand, copy, photographs, data, trademarks, and supplied assets.
2. Final deliverables: the specific designs, code, content, or configured system the agreement says the client receives.
3. Reusable agency tools: frameworks, libraries, processes, utilities, and pre-existing components that may remain the agency’s intellectual property.
4. Third-party materials: fonts, stock media, plugins, themes, software services, and other items governed by separate licenses.
5. Working or source files: design files, drafts, repositories, raw production assets, and intermediate work that should be named explicitly rather than assumed.

An AIGA Los Angeles source-file explainer makes the practical point: finished work and source files are not automatically the same deliverable, so expectations should be discussed early and written clearly. Again, this is general business context, not a substitute for legal advice.

Our small-business website cost guide explains why ownership and exit terms belong in the cost comparison, not in a surprised email three years later.

What happens when feedback is late or the scope changes?

First: changes happen. Discovery can uncover a requirement nobody knew existed. The business can change priorities. A vendor can alter an integration. A regulator can ruin everyone’s afternoon. The goal is not to pretend change is a moral failure.

The goal is to stop pretending change has no effect.

A late dependency moves dependent work

If approved content is required before page production, a content delay affects page production. If access is required to investigate an integration, the estimate may remain conditional until access exists. If the only decision-maker disappears for three weeks, the project cannot magically preserve the same delivery sequence by glaring at the calendar.

The agency should identify the effect promptly. The client should not expect the agency to hide the delay by compressing QA or displacing other committed work.

A scope change deserves a written decision

A request may be small to say and large to implement. “Can customers just log in?” can introduce account security, password recovery, permissions, privacy, data, email, support, testing, and maintenance. The number of words in the request is not the unit of scope.

For a proposed change, document:

• the new or changed requirement;
• why it is needed;
• effect on current work;
• cost and schedule effect;
• new dependencies or risks;
• what is removed, deferred, or added;
• who approved the change.

No agency should quietly perform substantial unplanned work and unveil the invoice later. No client should expect consequential added work to materialize from the phrase “while you’re in there.”

What should you expect during the website project?

The exact phases vary, but a responsible project usually makes these jobs visible.

Discovery and definition

The team defines the business problem, audiences, evidence, current environment, requirements, constraints, ownership, measurement, and acceptance boundary. The output should be a clearer decision—not just meeting notes and a strangely confident sitemap.

Content and information planning

The team inventories current material, identifies missing proof, maps user questions and tasks, defines content ownership, and creates an information structure based on the real material.

UX and visual direction

The agency develops journeys, wireframes, components, interaction patterns, and a visual system. Reviews use stage-appropriate questions. Approvals are documented before dependent work proceeds.

Development and integration

The agency implements the approved system, migrates or enters scoped content, configures integrations, and tests assumptions against real data and workflows. Newly discovered requirements enter change control rather than sneaking into the build under a trench coat.

Quality assurance and acceptance

The team tests agreed requirements and critical tasks. The agency resolves implementation defects. The client verifies business facts, permissions, operational fit, and acceptance conditions. Testing is not a final scavenger hunt performed the night before launch.

Launch and handoff

The team confirms backups, migration, redirects, forms, notifications, analytics, search controls, accounts, documentation, training, support, and rollback readiness. The client knows who owns post-launch monitoring and maintenance.

To understand all the disciplines a complete build may include, use our guide to what website design actually includes.

Website project kickoff checklist

Use this before work begins. It is a conversation tool, not a substitute for a project-specific scope.

Business and audience

• ☐ The business outcome and current constraint are stated in plain language.
• ☐ Primary audiences, buying context, and critical user tasks are identified.
• ☐ Existing evidence, analytics, sales feedback, and known limitations are available.
• ☐ Success and acceptance are defined without invented precision.

People and decisions

• ☐ One client decision-maker has final approval authority.
• ☐ Specialist reviewers and their review stages are named.
• ☐ Feedback will be consolidated before it reaches the agency.
• ☐ Review windows and delay consequences are understood.

Content and proof

• ☐ Every content type has a writer, source, reviewer, and due point.
• ☐ Claims, testimonials, case studies, and assets have evidence and permission.
• ☐ Content volume and migration assumptions are visible.
• ☐ Legal and regulated material has an appropriate qualified owner.

Technology and access

• ☐ Domains, hosting, CMS, email, analytics, integrations, and data sources are inventoried.
• ☐ The business knows which accounts it owns.
• ☐ Access can be granted securely and removed after the project.
• ☐ Existing data, exports, and representative samples are available where needed.

Scope and delivery

• ☐ Deliverables, exclusions, assumptions, and dependencies are written.
• ☐ Revision rounds and change control are defined.
• ☐ Testing and acceptance responsibilities are clear.
• ☐ Handoff, training, warranty, support, maintenance, and recurring costs are named.

If half this list produces blank stares, pause. A kickoff meeting is not holy water. It will not bless missing ownership into existence.

Frequently asked questions about working with a web design company

What should I prepare before starting with a web design company?

Prepare the business outcome, audience context, customer questions, current evidence, services and pricing facts, proof, brand assets, content sources, system inventory, required access, internal stakeholders, one decision-maker, and realistic availability. Do not predesign the solution unless the agency specifically asks for a bounded input.

Do I need all website copy finished before design starts?

No. Discovery, content strategy, and structural design can begin before every sentence is final. The team still needs the main claims, proof, content types, approximate volume, required functionality, and a clear writing and approval plan. Detailed page design should not proceed indefinitely against imaginary content.

Who should write the website content?

The client, agency, or a specialist can write it. The scope should name who owns strategy, interviews, drafting, editing, SEO research, approvals, CMS entry, and final proofreading. Regardless of who writes, the business must approve factual claims and confirm rights to supplied material.

How involved should a client be in website design?

The client should be deeply involved in business truth, customer context, constraints, evidence, tradeoffs, and approvals. The agency should lead UX, visual, content, and technical methods within its scope. Involvement is valuable; directing every pixel is not the same thing.

How should I give feedback to a web designer?

Describe the business or user problem, provide evidence or context, distinguish requirements from preferences, explain why the issue matters, and consolidate stakeholder input. Let the designer translate the problem into design changes. Match feedback to the stage instead of reopening strategy during final polish.

How many people should approve a website design?

One person should hold final approval authority, even when several specialists contribute. Legal, sales, operations, marketing, accessibility, or executive reviewers may be necessary, but their roles and review stages should be defined. Multiple uncoordinated final approvers create contradictory direction and rework.

What happens if the client misses a feedback deadline?

The dependent work and delivery sequence may move. The scope should explain review windows, hold or rescheduling rules, cost consequences, and how work restarts. The agency should communicate the effect promptly rather than silently compressing testing or other obligations.

What counts as a website scope change?

A scope change alters agreed deliverables, requirements, content volume, pages or templates, functionality, integrations, revision rounds, acceptance criteria, schedule, or responsibilities. The agency should explain the effect and receive written approval before performing consequential added work.

Who should own the domain, hosting, CMS, and analytics accounts?

The business should generally retain ownership or appropriate administrative control of critical accounts. The agency should receive necessary access with sensible security and return or remove that access at handoff. Ownership, billing, renewals, and exit procedures should be documented.

Does paying for a website mean I own every source file and tool?

Not automatically. Client materials, final deliverables, reusable agency tools, third-party licensed components, and working/source files can have different ownership or license terms. The agreement should identify what transfers, what is licensed, what remains with the agency, and what third-party rules apply. Obtain legal advice for consequential agreements.

How many website design revisions are reasonable?

The right number depends on the project’s complexity, review stages, and how clearly decisions are made. Defined rounds with directed, consolidated feedback are usually more useful than “unlimited revisions,” which often leaves the acceptance boundary undefined. The scope should say what a revision includes and what reopens approved work.

What should be included in a website handoff?

Include the deliverables promised in the agreement, account and access status, administrator roles, documentation, training, licenses, third-party dependencies, backups, analytics and search access, source or working files if contracted, known issues, warranty terms, maintenance responsibilities, and a process for removing unnecessary agency access.

How long does a website project take?

It depends on the number of unique decisions, content readiness, stakeholders, integrations, data migration, accessibility and compliance requirements, review cycles, testing, and launch risk. Page count alone is a poor schedule model. The useful timeline identifies dependencies and decision points instead of promising a universal number.

A good web design company should make the relationship clearer

The client should not outsource accountability for its business, claims, decisions, or accounts. The agency should not outsource professional leadership back to the client.

The healthy middle is not mushy “collaboration.” It is explicit ownership with useful communication: the client brings truth, evidence, access, and decisions; the agency brings diagnosis, method, execution, testing, and handoff; both document the tradeoffs that change the project.

That is how you avoid project limbo, committee-designed oatmeal, and the final-week discovery that nobody knows who owns the domain.

If your website project is still a vague pile of pages, features, and stakeholder opinions, talk with Scope Design. We can help diagnose the actual job, define responsibilities, and turn the work into a project someone can responsibly approve and operate.

Website project management is the system that keeps scope, decisions, content, approvals, access, testing, and ownership from dissolving into a swamp of meetings and “I thought they had that” emails. A project is organized when someone who missed every meeting can still reconstruct what the business authorized, what the team agreed to build, who approved it, what changed, what remains unresolved, and who owns the result.

TL;DR: You do not need seventeen dashboards and a ceremonial daily stand-up. You need one reliable source of truth and seven durable records: a project brief, authority map, requirements and acceptance ledger, content and asset register, decision register, change and exception log, and release and handoff package. If an important decision exists only in somebody’s memory or a thumbs-up buried in chat, it is not controlled. It is future archaeology.

This guide is for business owners, marketing leads, internal project owners, and agency teams managing a serious website build or redesign. If you are still deciding how to choose a provider, start with our web design company selection guide. If you already selected one and need to define how client and agency should work together, read how to work with a web design company without derailing the project. This page handles the next problem: preserving the project’s institutional memory.

Reviewed August 2026. We revisit this guide annually and whenever the cited standards or Scope Design project process materially changes.

What is website project management?

Website project management turns a business requirement into a launched, accepted, and supportable website through controlled scope, accountable ownership, documented decisions, measurable acceptance criteria, planned testing, and a complete handoff.

That definition is intentionally less sexy than “unlocking agile collaboration.” Sexy language is how ordinary responsibilities disappear into a fog bank.

A task board tells you what people are doing. Website project governance tells you who had authority to approve the work, what “done” meant, which risks were accepted, and what the business actually received. You need both on a meaningful project, but they are not the same thing.

The project manager’s job is not to make everyone look busy. It is to keep the decision system legible while the work changes shape.

A website project is more than page production

A serious website may involve positioning, information architecture, copy, structured content, design systems, development, integrations, accessibility, analytics, privacy, migration, search, quality assurance, hosting, DNS, training, and ongoing management. That is why website design is a business system rather than a coat of digital paint.

The project plan must connect those disciplines to business outcomes and acceptance evidence. Otherwise the team can complete every ticket while the business still receives the wrong thing.

A project-management tool is not a project-management system

Asana, ClickUp, Notion, Basecamp, Jira, Monday, Trello, spreadsheets, shared drives, client portals, email, and chat can all support a project. None of them can decide what deserves to be recorded.

Buying software before defining the operating rules usually produces a shinier junk drawer. Now the missing approval is in a card instead of an email. Tremendous progress.

Choose tools after answering these questions:

• Where is the approved project baseline?
• Who can approve business, content, design, technical, legal, and launch decisions?
• How does a draft become approved?
• Where are changes assessed and authorized?
• Which records must survive the project?
• Who controls the accounts and final assets?
• What proves the site is accepted and ready to operate?

One small project might answer those questions with a shared document, a task board, and a password manager. A custom operational platform may need requirements management, code repositories, environment controls, test evidence, release records, and formal risk review. Complexity should follow risk, not somebody’s software subscription.

Use the Scope Design Project Memory Stack

The Scope Design Project Memory Stack is a practical website project plan made of seven connected records:

The records do not have to be seven separate documents. They can be views in one project hub. Their jobs must remain distinct, though, because “meeting notes” are not an acceptance ledger and a task marked complete is not proof of approval.

The Scope Design Project Memory Stack: enough project memory to reconstruct the work without preserving every stray conversation.

The reconstruction test is simple:

Can an independent person trace authority -> requirement -> decision -> approval -> exception -> acceptance -> ownership without interrogating the entire team?

If not, the project is not organized. It is temporarily remembered.

1. Write a project brief that controls the job

A project brief is the commercial and operational baseline. It explains the problem, desired result, audience, scope boundary, constraints, and measurement plan before page production starts.

At minimum, record:

• the website’s primary business job;
• the audiences and important arrival intents;
• the result the website can reasonably influence;
• the current constraint or failure being addressed;
• included deliverables and explicit exclusions;
• known integrations, data sources, and operational dependencies;
• legal, accessibility, privacy, security, or procurement requirements that apply;
• budget and schedule constraints;
• the post-launch owner and maintenance assumption;
• the evidence that will count as success.

The brief should not pretend certainty where discovery is incomplete. Label assumptions and open questions. A false answer in a polished brief is more dangerous than an honest blank.

Start with the business constraint, not the requested artifact

A client may request a redesign, landing page, calculator, portal, or ecommerce feature. The request proves dissatisfaction. It does not prove the requested artifact solves the actual problem.

Our Website Solutions pillar explains how to choose the least complex responsible route. The project brief should preserve that diagnosis so the team does not quietly revert to “make pages until the budget runs out.”

2. Map authority before the first disagreement

The authority map identifies who can approve each kind of consequential decision. A stakeholder list is not enough. Fifteen names copied on an email do not create governance; they create an audience.

Map at least:

For each area, name one final approver, a delegate, and a response window. “Marketing” cannot approve anything. A department has no inbox anxiety, vacation, or accountability.

W3C’s current accessibility planning guidance makes the broader principle concrete: assign responsibilities, budget the work, define milestones, monitor findings, and use acceptance testing for agency-delivered websites or components. Accessibility is shared across business, content, design, development, QA, and procurement roles; it is not a magical final scan owned by whoever remembers it at launch. W3C’s planning guidance is accessibility-specific, but the ownership discipline travels well.

3. Pair every requirement with acceptance evidence

A requirement says what the system must do. Acceptance criteria say how the parties will know it does that well enough to approve.

Bad requirement:

Add a flexible events section.

Useful requirement:

An authorized editor can create, update, schedule, and archive events without developer assistance. Each event includes date, time, location, registration link, status, and an accessible public detail page. The client will complete user acceptance testing with two designated editors before launch.

The second version reveals fields, roles, workflow, access, and the acceptance method. It gives design, development, content, training, and QA something testable.

For each material requirement, record:

• unique name or identifier;
• business reason;
• owner;
• priority;
• dependencies;
• acceptance criteria;
• verification method;
• current status;
• evidence or link;
• accepted exceptions.

Acceptance should match the risk. A brochure-page heading may need content and visual approval. A payment, account, application, search, or data-import workflow needs functional testing with realistic conditions and named acceptance responsibility.

“Looks good” is not universal acceptance

Design approval confirms the approved design direction. It does not prove the form delivers email, the data maps correctly, the checkout calculates properly, the page meets agreed accessibility criteria, or the analytics event fires.

One approval cannot silently swallow five disciplines. Record what the approval covers and what it does not.

4. Control content and assets like real dependencies

Content is routinely treated as a decorative substance that will arrive “later.” Then later arrives wearing a launch-day nametag.

The content and asset register should track:

• page, component, product, document, image, video, logo, testimonial, or data item;
• source and current location;
• content owner;
• person authorized to approve factual accuracy;
• rights, license, consent, or attribution status;
• draft, review, approved, scheduled, migrated, or blocked status;
• target page or system destination;
• transformation needed, such as editing, cropping, transcription, migration, or structured import;
• accessibility needs, such as alternative text, captions, transcripts, or document remediation.

Do not accept files named homepage-final-v7-USE-THIS-ONE-really.docx as a version-control philosophy. Use a stable item name and explicit status. The system should show which version is approved without interpreting panic punctuation.

Record ownership and license terms before handoff

Paying for a website does not automatically answer who owns every piece of source material, working file, licensed font, stock image, plugin, third-party service, code library, or agency tool.

The U.S. Copyright Office explains that copyright initially belongs to the author unless an applicable work-made-for-hire rule or transfer changes that result, and a transfer of copyright ownership generally requires a signed writing. Its website-registration guidance specifically notes that a hiring party may need a signed agreement to acquire exclusive rights from an independent contractor. Review the Copyright Office’s ownership and transfer rules and website copyright guidance, then have qualified counsel handle the actual agreement when the stakes justify it.

This is general project-planning information, not legal advice. The useful management move is simple: list the asset categories and write the ownership, license, access, and delivery terms before people start making assumptions.

5. Maintain a decision register, not a transcript landfill

Meeting notes record conversation. A decision register records the durable result.

Each consequential decision should include:

• the decision;
• the problem or tradeoff it resolves;
• options considered when useful;
• rationale;
• named approver;
• date;
• affected requirements, designs, pages, systems, cost, or schedule;
• next action;
• whether it supersedes an earlier decision.

The register prevents three common failures:

1. The same debate restarts because nobody remembers the rationale.
2. A late stakeholder treats an approved direction as an unopened question.
3. The team implements a decision but forgets which other artifacts must change.

You do not need to record whether the hero image moved six pixels during exploration. Record decisions that affect meaning, scope, risk, ownership, cost, acceptance, or downstream work.

Link feedback to the decision it is supposed to improve

Good feedback identifies the audience, business concern, evidence, or failure condition. “I don’t like blue” is a reaction. “This color is too close to the competitor we are trying to differentiate from” is usable context.

Article 58 covers how to give feedback without trying to become the designer. The decision register preserves the approved outcome after that conversation ends.

6. Separate changes, defects, and exceptions

Not every unexpected item is scope creep. Some are defects. Some are clarified requirements. Some are new requests. Some are risks the business knowingly accepts.

Use four buckets:

A change record should state the request, reason, affected work, cost and timing impact, risks, decision, approver, and revised baseline. A chat message saying “can we also” is a request. It is not authorization.

The same discipline applies to risks. NIST Cybersecurity Framework 2.0 introduced a Govern function that emphasizes roles, responsibilities, authorities, policies, and alignment between cybersecurity risk and organizational obligations. NIST describes the framework as adaptable guidance rather than a prescribed checklist. Use its governance model where relevant; do not claim that every small website must implement the entire framework.

“We’ll fix it later” needs an owner and a date

An exception without an owner is not a plan. It is a defect wearing sunglasses.

For any accepted material exception, record:

• what remains unresolved;
• who may accept the risk;
• why launch may proceed;
• business or user consequence;
• mitigation;
• owner;
• target date or review trigger;
• whether customers, staff, or support need to know.

7. Build a release and handoff package before launch day

Launch is a controlled transition, not the moment someone gets brave near the Publish button.

The release and handoff package should include what is proportionate to the project:

• approved release scope and version;
• final requirements status;
• QA and user acceptance results;
• known defects and accepted exceptions;
• redirect and migration verification;
• analytics and conversion-event verification;
• privacy, security, and accessibility evidence where applicable;
• backup and rollback plan;
• launch authorization;
• domain, DNS, hosting, CMS, analytics, tag manager, search, repository, and vendor account ownership;
• administrator list and least-privilege access plan;
• delivered files, documentation, licenses, and credentials;
• training completed and recordings or guides delivered;
• warranty, support, maintenance, escalation, and emergency paths;
• post-launch review date.

The package does not have to be a 200-page binder nobody opens. It must let the operator run the system without keeping the original agency on psychic retainer.

Keep sensitive records deliberately, not forever

Do not turn the project archive into a permanent credential graveyard. Separate durable governance records from secrets and unnecessary personal information.

FTC guidance recommends inventorying sensitive information, keeping only what the business needs, limiting access, and using a written retention policy that states what is retained, how it is secured, how long it is kept, and how it is disposed of. See the FTC’s Protecting Personal Information guide. The correct retention period depends on legal, contractual, regulatory, operational, and litigation-hold requirements; there is no universal “keep website files for seven years” rule.

Organize the project around gates, not arbitrary weeks

The website development process often moves through discovery, strategy, content, design, development, testing, launch, handoff, and ongoing improvement. Scope Design was mapping that full sequence into a visible project system years before every software vendor discovered the word “workflow.”

The phases can overlap. The gates should remain explicit:

Do not force every website into two-week sprints because a methodology diagram looked authoritative. Agile, iterative, sequential, and hybrid delivery can all work. The useful question is whether dependencies and approvals are visible enough to make the next commitment responsibly.

A real project taught the difference between pages and a system

A long-established specialty business approached Scope Design for a new website and new features. Discovery showed that the visible website sat in the middle of legacy software, disconnected data, manual processes, external services, account-access dependencies, content migration, customer-facing failures, and future operational plans.

The project could not be governed as “design eight pages.” It required a prioritized requirements baseline, data and access inputs from the client, explicit content responsibility, phased deliverables, milestone approvals, functional testing, training, and written handling for unplanned work.

The lesson is not that every website needs enterprise bureaucracy. It is that the project record must describe the system being changed. A task board full of page names would have hidden the actual work.

We use this example only in anonymized form. It supports the project-management method, not a performance claim.

How to measure whether the project is healthy

Do not measure project health by task volume or meeting attendance. Useful signals include:

• percentage of material requirements with an owner and acceptance method;
• decisions waiting beyond their agreed response window;
• content dependencies blocked by missing source, owner, rights, or approval;
• unresolved changes without impact decisions;
• rework caused by superseded or undocumented decisions;
• defects by requirement and severity;
• accepted exceptions without owners or review dates;
• launch requirements without evidence;
• accounts or assets without confirmed business ownership;
• handoff items not accepted by the operator.

These are diagnostic measures, not universal benchmarks. A five-page site and an operational platform should not have identical governance overhead. The useful metric exposes the current constraint instead of generating a handsome dashboard for the meeting.

Website project management checklist

Before approving a project plan, confirm that:

• the website’s primary business job is stated;
• scope, exclusions, assumptions, and dependencies are visible;
• one authorized approver exists for each consequential decision area;
• requirements have owners and acceptance methods;
• content, data, and assets have sources, rights, statuses, and destinations;
• important decisions have rationale, approver, date, and affected work;
• changes cannot quietly enter production without an impact decision;
• defects, changes, clarifications, and accepted exceptions are distinguished;
• project phases have meaningful gates rather than decorative dates;
• testing reflects the actual risk of the feature;
• launch authorization includes known exceptions and rollback readiness;
• the business controls critical accounts and receives agreed assets;
• training, support, maintenance, and escalation are defined;
• records containing sensitive information follow a retention and access policy;
• the post-launch operator has accepted the handoff.

If half of those answers live in somebody’s head, do not buy another tool. Fix the project memory.

Frequently asked questions about website project management

What should a website project plan include?

A useful website project plan includes the business objective, scope and exclusions, audiences, requirements, roles and approval authority, content and data dependencies, milestones, acceptance criteria, testing, change control, launch conditions, account ownership, handoff, maintenance, risks, and measurement. The schedule is one part of the plan, not the whole plan.

What are the major stages of a website project?

Most projects move through discovery, structure or information architecture, content, design, development, testing, launch, handoff, and ongoing improvement. The phases may overlap, but each major commitment should have an explicit approval or readiness gate.

Who should own a website project inside the business?

One named product or business owner should be accountable for the result and able to resolve internal priorities. Specialists can approve content, brand, legal, privacy, security, accessibility, or technical matters, but a committee should not become the default final authority for every decision.

What is the difference between a project manager and a product owner?

The product owner represents the business result and prioritizes what the system must achieve. The project manager keeps scope, dependencies, decisions, timing, records, and delivery moving. One person may perform both jobs on a small project, but the responsibilities should not disappear.

What are website acceptance criteria?

Acceptance criteria are observable conditions that prove a requirement is complete enough to approve. They may cover content, user behavior, data, performance, accessibility, integration results, permissions, or operational workflow. “Looks good” is valid only for the visual decision it actually evaluates.

How many people should approve a website?

Use one final approver per decision area and consolidate stakeholder input before it reaches the delivery team. More subject-matter reviewers may be necessary, but several people with equal and undefined veto power produce contradictory feedback and delayed decisions.

What belongs in a website decision log?

Record consequential decisions affecting scope, meaning, risk, ownership, cost, schedule, acceptance, or downstream work. Include the decision, rationale, approver, date, affected artifacts, next action, and any superseded decision.

How should website project files be organized?

Organize files by stable function and status, not by panic-driven filenames. Separate approved baselines from working drafts, use consistent item names, preserve version history, restrict sensitive material, and link files to the requirements or decisions they support. The exact folder structure matters less than making the approved version unmistakable.

What is a website change request?

A change request proposes an alteration outside or materially different from the approved baseline. It becomes authorized work only after the team assesses its effect on scope, cost, timing, dependencies, risk, and acceptance, and an authorized person approves the revised baseline.

What is the difference between a defect and a scope change?

A defect means the delivered behavior fails an approved requirement. A scope change adds or alters the approved requirement. Calling every defect a change unfairly moves delivery responsibility; calling every new idea a defect quietly expands the project.

Should a website project use Agile or Waterfall?

Use the delivery approach that matches uncertainty, dependencies, team capacity, and risk. Iterative design and development often benefit from short feedback loops, while migrations, compliance gates, and launch dependencies may require more sequential control. Most serious website projects are hybrids. Methodology loyalty is not a substitute for clear acceptance and ownership.

What records should the business keep after launch?

Keep the executed agreement and changes, approved requirements, material decisions, rights and licenses, release and acceptance record, known exceptions, delivered assets, account ownership, training and operating documentation, and applicable security, privacy, accessibility, or testing evidence. Apply a written retention policy; do not retain unnecessary secrets or personal information forever.

What should happen when a website project stalls?

Identify the blocked requirement or decision, its owner, the missing input, the date it became blocked, and the consequence. Escalate through the agreed authority map. If the baseline is no longer realistic, formally replan scope, cost, timing, or priority instead of leaving the project in indefinite “almost there” purgatory.

Make the project understandable enough to survive the project

Website project management is not performance art for organized people. It is how a business protects decisions, budget, rights, risk, and operational continuity while a complicated idea becomes a real system.

The best project record is not the one with the most fields. It is the smallest reliable system that lets the next responsible person understand what happened without summoning the original team for a séance.

If your website project is a pile of tabs, unowned approvals, mystery files, and launch anxiety, talk with Scope Design. We can diagnose the actual job, establish the project baseline, and build a delivery system that leaves you with a website you can approve, operate, and own.