How to Manage a Website Project (From the Client Side)

Summarize with:
Author
Alexa G.
Date
Jul 16, 2026
Category
Accessibility
Read time
12 min

How to run a website project from the client side. What a project plan needs, why content is always the critical path, and how to stop a six-month build turning into eighteen.

Website projects don't usually fail on design or code. They fail on decisions.

This is written for the person inside the organization who's been handed the website project, probably alongside their actual job.

The two things that decide everything

Who decides? One person, with real authority, who can say yes without a committee.

Projects die when work gets approved by whoever's in the meeting, then goes to a director, then goes to a board, and comes back changed. Every one of those loops costs weeks and reopens settled decisions. If your board has final say on design, get the board involved early or accept that every milestone has a hidden month attached.

Who writes the content? Name them now. This is the answer to most schedule questions before anyone asks.

Content is the critical path

Every time.

Design finishes on schedule. Development finishes on schedule. Then the project sits for four months because nobody wrote the About page, and the About page needs a decision from someone who's travelling.

What actually happens with content:

  • It takes three times longer than anyone estimates
  • It's not writing, it's decision-making, and decisions need people who are busy
  • Nobody wants to cut anything, so the site keeps every page from 2011
  • The person who knows what the programs actually do isn't the person assigned to write about them

Start content at the same time as design. Not after. Give every page an owner and a date. Then assume the dates will slip and build that in.

What the plan needs

Phases with dates. Discovery, design, build, content, testing, launch. Each with a start and an end.

A named approver per phase. Not a committee. A person.

A content plan. Page by page, owner by owner, date by date. This is the document that saves the project.

A technical scope. What integrates with what. Where the data lives. Who has the credentials for the domain, and yes, actually check, because the person who registered it in 2009 may not work there.

A testing window. Real time, not the two days before launch. Include accessibility testing, and include an actual keyboard-and-screen-reader pass, not just a scan.

A launch sequence. Who does what, in what order, and who can roll it back.

Post-launch monitoring. Eight weeks. Someone's job.

How long it takes

  • Small site: eight to twelve weeks
  • Mid-size non-profit or association redesign: four to six months
  • Complex, with integrations: longer, and the integration is what makes it longer

Those assume decisions land on time and content arrives. Most overruns are client-side. That's not a criticism, it's just where the time goes, and planning for it is more useful than being surprised by it.

Where projects go wrong

Feedback arrives in pieces. Three people send conflicting notes over two weeks. Consolidate feedback into one document, from one person, per round. Agree the number of rounds up front.

Scope grows quietly. "Could we just add" is how a twelve-week project becomes a six-month one. Every addition is fine. The problem is when nobody tracks that there were nineteen of them.

Nobody scoped the migration. If you have an existing site, moving the content and preserving the URLs is real work and it's frequently missing from the estimate entirely.

No budget after launch. The grant covers the build. Nothing covers the person who keeps it current. Two years on, the site is stale and someone proposes another redesign, and the cycle repeats.

Questions worth asking your agency

  • What do you need from us, and when? Get this in writing on day one.
  • What happens if content is late? A good answer is honest about cost and schedule.
  • How many review rounds are included?
  • What's the accessibility approach, and is it manual testing or a scan?
  • Who owns the accounts and the code at the end?
  • What does maintenance cost after launch?

That last one gets skipped and it's the one that determines whether the site still works in three years.

The honest summary

Your agency can control design and code. They can't control your decisions or write your content for you, and those are the two things that set the schedule.

Name the decider. Start the content now. Everything else is manageable.

Pragmatica has been running website projects for Canadian non-profits, charities, and associations since 2004. If you're planning one, get in touch.

Frequently Asked Questions

Answers, Simplified.

Find clear answers to common questions about our creative process, services, and working with Pragmatica.

Clients Trust Our Creative Vision

I'm the Content Management Lead at Pragmatica. I lead editorial strategy, content production, and AI search optimisation work for the Canadian nonprofits, healthcare providers, and purpose-led businesses we serve from our Vancouver and Toronto studios. After 20 years in Canadian web, what I care about most is content that actually helps the reader and shows up when they need it — in Google, in Bing, and in the AI tools that increasingly answer their questions.

Facebook - Website Design - PragmaticaTwitter - Branding X Webflow TemplateInstagram - Website Design - PragmaticaLinkedIn - Website Design - PragmaticaYouTube - Branding Website Design - Pragmatica
Alexa G.
Content Management Lead
, Pragmatica
image of author at writing desk