Project management workflow: how to build one for client work

What a project management workflow is

A project management workflow is the sequence of stages a project moves through from request to close, with an owner and an exit point for each stage. It answers one question: what happens next, and who does it.

It is not the project plan, which lists the tasks and dates for one project. It is not project management either, which is the work of running projects: scoping, staffing, chasing and reporting. The workflow is the repeatable route, and each plan is one trip along it. Task management is smaller again, the to-do items inside a single stage.

For a content or video agency the route is largely the same for every client, which is why it pays to write it down once.

Four types of workflow, and the one that fits agency work

Agency client work fits the hybrid type. The project moves through the stages below in order, and the content pieces inside Production run in parallel on their own board.

Project and content workflows work at different levels

A content workflow follows one piece from brief to draft to review to publishing. A client project holds many of those pieces, plus the scope, the budget, the client's assets and the handover. If one board carries both, project questions such as who signed the scope or how many changes were absorbed unpriced get buried among the content cards.

The six stages of a client project

Each stage ends at a gate: an exit criterion you can check without asking anyone how they feel about it.

Three stages need more than the table says.

• Kickoff. This is when the client's dates start to matter, so they go on the plan here, not later.
• Review. Each round ends with an approval or a list of changes, and each change is marked as in scope or as a change request.
• Delivery and close. The retrospective is the last step of this stage, not a separate phase, because it is a short conversation and not a body of work.

The six stages map onto the usual five-phase project lifecycle. Intake is initiation, Scoping and Kickoff are planning, Production is execution, Review is monitoring and controlling, and Delivery and close is closure.

A project management workflow diagram with its two loops

Read the figure left to right. The short loop returns from Review to Production for each revision round. The long loop returns from Review to Scoping when the scope changes, so the change is agreed again before any work on it starts.

Drawing the chart, and what to leave off

A chart is only useful if it stays short enough to read in one look.

1. Write the stages as boxes, left to right, in the order they happen. Keep it to six or seven.
2. Under each box, write its exit criterion in a few words. If you cannot write one, the stage is not defined yet.
3. Mark who owns each stage. Kickoff and Review usually need the client's hands, so show that rather than implying the agency does everything.
4. Draw the loops that really happen, and nothing else.

Those four things, order, gate, owner and loops, answer what a new team member asks: where a project is and what it needs before it can move. Leave the rest off. Individual tasks belong on the board, tool steps such as "send email" are noise, and every status a person can set by hand becomes a box nobody reads. Redraw the chart only when a stage changes, not when a project goes badly.

Mapping the stages to a kanban board

Each stage becomes a column and each client project becomes a card that moves across them. Use the same stage names as the chart, and keep content pieces on their own board so a project card does not fill up with twenty cut versions.

• Split Review into two columns. One for work waiting on you, one for work waiting on the client. A project waiting on approval for six days is not stalled in production, and the board should not make it look that way. A date beside the client column tells you when to chase.
• Limit Production. The Kanban Guide says members must explicitly control the number of work items in a workflow from started to finished. A column without a limit is where projects go to sit unnoticed, and a limit forces a conversation about what to pause.
• Give retainers a cycle card. A retainer never reaches close in the usual sense. Treat each billing period as its own card, close the cycle rather than the client, and reopen from Intake or Kickoff depending on whether the brief changed.

Scope changes need a rule too. Clients ask for one more cut or a new platform while production is underway. Route each request back to Scoping, price it or agree it as a swap, and only then return it to Production. If it is small enough to absorb, absorb it on purpose and write that down.

A worked example: one video project through the six stages

Say a client asks for a product video and three short social cut-downs.

• Intake. You log the request with the client name, a one-sentence brief and the date it arrived.
• Scoping. You agree the four deliverables, two review rounds and the price in writing. The client signs off before anything is filmed or cut.
• Kickoff. The client sends logos, footage and a named approver. You place both review dates in the calendar.
• Production. The main video and the cut-downs become cards on the content board. Production holds them until each is approved.
• Review. The client returns notes on the main video. Round one is within scope. Midway through, they ask for a fifth cut-down for another platform, so you send that back to Scoping, price it and only then return it to Production.
• Delivery and close. The final approval is recorded against a named version, files and publishing are handed over, the invoice goes out and the retro notes are filed.

The example has one revision loop and one scope-change loop, which is the whole shape of the chart.

A stage template you can copy

Copy this table into a sheet or document for each new project and fill in the right-hand column before the project starts.

Three measures, without a dashboard

Rounds used against rounds included, days waiting on the client, and scope changes raised after kickoff cover the main ways a client project goes wrong. A rising number of scope changes means the first agreed scope was not specific enough. You can read all three from dates and a change log you already keep, in a ten-minute weekly check. If you are building a report to track the workflow, the process has become the work.

When a whiteboard or a spreadsheet is enough

With one or two clients, a single queue of work and a team that talks every day, a whiteboard with six columns does the job, and so does a spreadsheet with a tab per project and a stage column. Move to a tool when one client's dates clash with another's, or when a project's files live in three places and nobody can say which holds the approved version. The video production tracker is a practical way to put the stages in a sheet first, and planning calendars across several clients covers the next problem once projects start to collide.

Write the six stages down this week

Draw the chart on paper for the next project that starts and check each gate against what happens. Change it once afterwards if a gate was vague or a loop was missing.

Questions people ask about project management workflows