Almost no design project fails during design. It fails in the gaps — the week between an approved direction and a brief nobody rewrote, the handover where the build quietly drifts from the file, the launch that ships without a single measure of whether it worked. The craft is rarely the problem. The sequence is.
End-to-end project management is simply the discipline of deciding, before the work starts, what each phase produces and who has to agree before the next one begins. Here is the structure we run at Adi Design, with an interactive planner you can set to your own project.
The short version
- Seven phases, each with one named output and one decision gate.
- A phase is not finished when the work looks good. It is finished when the gate is passed by someone who can approve it.
- Scope changes are not the enemy. Unrecorded scope changes are.
- Validation late in the schedule is validation you will be pressured to skip.
- If you did not define a success measure in week one, launch will tell you nothing.
Why design projects actually slip
Three causes account for most of it, and none of them is “the designers were slow”.
The scope was agreed in conversation, not in writing. Everyone leaves the kickoff believing a slightly different project was approved. The difference surfaces in week six as “I assumed that was included”, and whoever is weakest in the room absorbs it.
Nobody identified who can approve. Work is presented to a group that can comment but cannot decide. Comments are gathered, the direction is revised, and three weeks later the person who actually signs off sees it for the first time and has a different view. This single failure costs more time than every other cause combined.
Validation was scheduled last. Testing sits after detailed design, so by the time it happens the budget is spent and the date is close. The test becomes a formality, or it gets cut. Either way the project ships on assumptions.
A phase ends when a decision is made, not when a file looks finished.
The seven phases, and what each one owes the next
Set the planner below to your project type and size. It scales the schedule, and selecting any phase opens what goes in, what comes out, the gate that closes it, and where that phase usually goes wrong.
End-to-end project planner
Pick a project type and a size. Select any phase for its inputs, outputs and decision gate.
Project type
Project size
Phase 1 — Discovery and scoping
Goes in
Comes out
Decision gates do more work than any tool
A gate is one sentence: the question that must be answered yes before the next phase starts, and the name of the person who answers it. That is the entire mechanism, and it fixes most of what goes wrong.
Gate 1. Have we written down what is in scope, what is out, and what success will be measured by — and has the budget holder agreed to it?
Gate 3. Has the person who can say no seen the chosen direction, and said yes to it?
Gate 5. Did people who are not on this team complete the core task without help?
Write the gate questions at kickoff, put the approver’s name against each, and refuse to start the next phase until the gate is cleared in writing. An email saying “approved, go ahead” is enough. The point is not ceremony — it is that the decision exists somewhere outside memory.
If you can only adopt one practice from this article, adopt this one: name the approver for every gate before the project starts. Everything else is optimisation.
Scope changes: record them, don’t resist them
Clients change their minds because they learn things as the project progresses. That is healthy. What damages a project is a change absorbed silently — accepted in a call, built into the work, never reflected in the date or the fee.
Keep a scope ledger: one line per change, with the date, who requested it, the effect in days, and the effect on cost. Share it in every status update, even when nothing has changed. Two things follow. Clients begin to self-regulate, because the cost of a request is visible at the moment they make it. And when the date moves, the conversation is about an agreed record rather than two competing memories.
A communication rhythm that holds
- Weekly written update. Five lines: done, in progress, blocked, decisions needed from you, date status. Sent whether or not anything interesting happened — the one week you skip it is the week trust breaks.
- Demo at the end of every phase. Not a slide summary: the actual artefact. Demos surface misalignment while it is still cheap.
- Decisions log. Date, decision, who made it, what was considered. Three lines each. It ends the “we never agreed to that” conversation permanently.
- One channel for approvals. Feedback can arrive anywhere; approval arrives in one place, in writing.
Where projects break, and what prevents it
| Pattern | Usually shows up as | The prevention |
|---|---|---|
| Verbal scope | “I assumed that was included” in week six | A written scope with an explicit out-of-scope list. |
| Approval by committee | Endless rounds, no decision | One named approver per gate, agreed at kickoff. |
| Late validation | Testing cut for time | Test a rough prototype in phase 3, not a polished one in phase 5. |
| Happy-path design | Developers inventing empty and error states | Every state designed before handoff — loading, empty, error, permission. |
| Handoff as a file drop | Build drifts from the design | Designer stays assigned through build; design review before release. |
| No success measure | Nobody can say whether it worked | Define metrics in phase 1 and instrument them before launch. |
| Silent scope creep | Date slips with no explanation | A scope ledger shared in every weekly update. |
Launch is a phase, not an event
The last phase is the one most often treated as a formality, and it is where the value of the whole project is either captured or lost. Launch properly means: the analytics are in place before release, not after; the success metrics defined in phase 1 are actually being read; someone owns the first two weeks of feedback; and a short retrospective converts what you learned into a backlog rather than a feeling.
A project that ships without measurement has not finished. It has stopped.
Shipping is the midpoint of the project, not the end of it.
A kickoff checklist
- Scope written, including an explicit out-of-scope list
- Success metrics defined and agreed by the budget holder
- One named approver per decision gate
- Phase dates with the gate dates marked, not just the final date
- A decisions log and a scope ledger, both shared
- Validation scheduled early, with participants already being recruited
- Named designer assigned through build, not released at handoff
- Analytics owner identified for launch
How we run projects at Adi Design. Every engagement starts with the seven phases, the gate questions and the named approvers agreed in writing before any design begins. If you have a project in planning and want that structure applied to it, get in touch.
