Web design project management for a small agency

How does web design project management work?

The project lead sets the scope, splits the build into tasks, gives each task an owner and checks progress every week until launch. The client hears from one person, on a set rhythm.

1. Confirm the scope in writing: the pages, the features and the content the price covers.
2. Split the build into tasks, each with an owner and a due date.

When a task changes hands, it goes with its files, its notes and the name of the next owner, so nobody has to ask where it stands. For how work moves between people and tools, see how a web design workflow runs.

3. Agree how the client sends feedback, and who on their side signs off.
4. Hold a short check-in each week, then send the client an update.

At the check-in, go phase by phase and confirm which tasks are finished and which are stuck, before you write the client's update. For the phase-by-phase tick list, see the website project management checklist.

5. Log every change request before anyone acts on it.
6. Close each stage with the client's yes in writing.

When a build partner does the work, the lead's job leans toward briefing and review. In one partner's published steps, the agency explains the client's needs on a call, approves the design before the build, and reviews the built site with its client before it goes live. Each of those steps is laid out in the website development process.

Who should be on the web design team for each project?

Every build needs a project lead, a designer, a developer, someone who owns the content, a tester and one contact on the client's side. One person can hold two roles, as long as each role has a name next to it.

When several builds run at once, these roles get shared across projects. For running many projects at once, see agency project management.

How should change requests be handled once the build starts?

Log every change request in one place, check it against the agreed scope, and get the client's yes on any added cost or time before work starts. That keeps the scope steady without saying no to every idea.

A simple change request form holds these fields:

• What the client wants changed, in their words
• The page or feature it touches
• Whether it's inside the agreed scope
• The added cost or time, if it's outside the scope
• The client's approval, with the date

Then handle each request the same way:

1. Ask the client to send changes through one channel, such as email or a shared form.
2. Log each request the day it comes in.
3. Sort it: inside the scope or outside it.
4. For a change outside the scope, send a short quote and wait for a written yes.
5. Add each approved change to the task list and the timeline.
6. Tell the client when it's done.

Log the small fixes too. At the end of the build, the log shows how many changes came in and where the time went.