Client Delivery Template

Why most client delivery templates stop being trustworthy

Once scope is agreed, the risk shifts from "what are we building" to "will it land by the date the client was told." That's a narrower, more time-pressured problem than the engagement as a whole, and it fails in its own specific ways.

Delivery dates live in the SOW or an email, not on the board. The board tracks what's being worked on, but the date it's due against sits in a different document, so a slipping deliverable isn't visible until the day it's actually late.

There's no forecast, only a deadline. Nobody can say two weeks out whether a deliverable is genuinely on track. The team finds out the same day the client does, when it's too late to do anything but apologize.

Client review time looks identical to stalled work. A card that hasn't moved in four days might be sitting with the client waiting on feedback, or it might be genuinely stuck, and from the board alone, there's no way to tell which.

Scope questions get answered mid-delivery instead of before it. Without a board that draws a line between "what was agreed" and "what's being asked for now," a client's new request gets folded into an in-flight deliverable, and the original due date stops meaning anything.

Each of these traces back to the same root cause: the board was built to show what's being worked on, not whether it's going to land on time. Those are different questions, and a template answering only the first one will always be a step behind the client asking the second.

What a slipping deliverable looks like on the board

Two weeks before a homepage redesign is due, the forecast, recalculated from the last few completed cards rather than the estimate from kickoff, shows it landing three days late. Nothing has visibly gone wrong yet; the card is still moving, hours are still being logged against it. But the forecast slipping is the signal, and it's a decision point rather than a fire: bring in another pair of hands, trim scope, or tell the client now while three days is still a manageable conversation. Compare that to the same deliverable on a board with no forecast, where the first sign of trouble is the card still sitting in progress on the morning it was due, by which point the only options left are apologizing and re-negotiating a deadline that's already passed. The difference is entirely in when the slip became visible, not in whether it happened. That's really the whole case for running a delivery forecast off measured velocity instead of a static estimate: it buys the team the two weeks it needs to actually do something about a problem, rather than just narrate it.

How to use it

1. 01Only bring a deliverable onto this board once scope and a due date are agreed. Earlier-stage scoping belongs on the wider engagement board, not here.
2. 02Cap in-progress low. Two or three is usually right for a small team against a hard date, enough to keep moving, not so much that everything's half-done.
3. 03Move a card to client review deliberately, and treat time there as waiting on the client. It changes what a status update should say and stops the team chasing itself for a delay that isn't theirs.
4. 04Watch the forecast, not just the deadline. A forecast sliding past the due date two weeks out is a decision point; a deadline missed on the day is a fire that arrived too late to fix.
5. 05Route anything beyond agreed scope as a new card with its own date, priced and agreed before work on it starts.
6. 06Log hours as the deliverable moves, not retroactively. The forecast is only as good as the velocity feeding it, and velocity is only as good as hours logged close to when the work actually happened.

The scoped-to-delivered flow isn't proprietary; you could run it in any tool with column limits and velocity tracking. It's written down here because the forecast, not the deadline, is the part most delivery boards never build at all, even though it's the part that actually buys time to react.