How to create a project timeline for client work

A timeline shows when work can realistically happen

To create a project timeline, start with the agreed outputs, list the work needed to produce them, then sequence that work around dependencies and available people. Include client input, review windows and contingency before promising a completion date. A list of deadlines alone does not explain whether the plan is achievable.

Atlassian describes a timeline as a chronological view of tasks, milestones, dependencies and dates. For a freelancer, a simple shared document or spreadsheet can communicate this clearly. A detailed schedule holds individual assignments; the client-facing timeline can show the main stages without exposing every internal task.

Separate the timeline from the scope and deliverables

The scope defines the boundaries of the engagement. A deliverable is an output, such as a final presentation deck. A task is work, such as laying out its slides. A milestone is a checkpoint, such as the client accepting the deck. The timeline connects those elements to dates; it does not replace the agreement.

Begin with an already-agreed deliverable list rather than using scheduling to quietly add promises. If the scope says one review round, schedule one review round. If someone requests a second round while reviewing dates, resolve the commercial change before treating it as included work.

Build the schedule in dependency order

Estimate effort and elapsed time separately. Six hours of design may need two working days if other commitments leave only three hours each day. A two-day client review uses little of your production time but still occupies two days in the dependency chain.

A dependency means something must happen before another activity can proceed. Final copy may block layout; approved layout may block development. Parallel work only shortens the schedule when its inputs are ready and the people doing it actually have capacity.

1. List each agreed deliverable and the tasks needed to prepare, check and hand it over.
2. Give every task an owner and estimate its working duration using actual availability.
3. Record prerequisites, including client assets, access, decisions and third-party responses.
4. Place tasks in dependency order, then add review, revision and final acceptance windows.
5. Mark important checkpoints and reserve contingency for identified uncertainty.
6. Check holidays, absences and competing commitments with everyone whose work affects the finish.

Worked example: a freelance landing-page design

This fictional example concerns design files only, not a built website. Nia is designing one landing page for a small studio. Day numbers below are working days, with no holidays or absences. The client must provide approved copy and brand assets before day 1; otherwise this baseline needs revisiting.

Days 1–2: Nia reviews the supplied content and prepares a wireframe. Days 3–4: the client reviews it and returns one consolidated response. Days 5–7: Nia creates the visual design after wireframe approval. Days 8–9: the client reviews that design. Days 10–11: Nia makes the agreed revisions and checks the files.

Day 12 is reserved for final client acceptance. Days 13–14 are a visible contingency allowance for a small correction or delayed response. Day 15 is the planned final file handoff. This sequence totals 15 working days: 2 + 2 + 3 + 2 + 2 + 1 + 2 + 1. It is not a claim that Nia performs 15 days of production.

Wireframe approval at the end of day 4 and final acceptance on day 12 are milestones, not extra days of work. The client can see exactly which reviews protect the next stage. Implementation, extra concepts and additional review rounds remain outside this example.

Make review time and contingency explicit

Name one person who consolidates client feedback and confirm when that person is available. Define whether a review ends with feedback, approval or a decision to revise. Sending a draft is not the same event as obtaining permission to continue.

Contingency is reserved schedule capacity for uncertainty, not an automatic allowance for extra scope. Choose it based on the risks you can identify rather than applying an unexplained universal percentage. In the fictional plan, two days could absorb a short review delay; they cannot absorb an entirely new page.

If a launch date is fixed, work backward to test feasibility, then compare that result with your forward dependency plan. When the two do not fit, agree a smaller deliverable, additional available resources or a different deadline. Do not erase review time to make the dates appear compatible.

Use a copyable timeline handoff checklist

Keep a dated baseline so changes remain understandable. Replace the illustrative day numbers with actual dates only after checking the working calendar. Include a time zone for time-sensitive approvals.

Copyable wording: “This timeline assumes approved copy and assets before the start date, consolidated feedback within each review window, and the agreed revision round. If an input or decision is late, we will identify affected tasks and confirm a revised forecast before committing to new dates.”

1. Show the deliverable, owner, planned start, planned finish and prerequisite for each stage.
2. Name the client reviewer and the decision expected at each review checkpoint.
3. State working days, known absences and which deadline is fixed rather than forecast.
4. Identify contingency separately from production and review time.
5. Agree who communicates changes and where the latest dated timeline can be found.

Update forecasts without rewriting what was agreed

A common failure is moving the final date without showing what caused the movement. Keep the original baseline alongside the current forecast and actual completion dates. A weekly update can simply state the next checkpoint, its forecast date, the blocking decision and the action owner.

If client feedback is three working days late, inspect the affected dependency chain and remaining contingency. Do not automatically add three days to everything: independent work might continue, while a contractor booking might create a longer delay. Explain the actual consequence and agree the response.

Avoid scheduling one person on two full-time tasks at once, marking unfinished work complete to protect a milestone, or quietly spending the buffer on additions. Those choices hide the problem instead of helping the client make a decision.

Start with the next real decision

For your next project, identify the first output that needs client review, the input it depends on and the person authorized to decide. Build the rest of the timeline outward from that chain. Use the related milestone and deliverable guides when the labels are unclear.

Moolamochi keeps commercial agreement, delivery acceptance and payment as separate records. That distinction matters even when your timeline lives in a separate planning document: a scheduled review is not an approval, and an invoice is not proof of delivery. New access is currently waitlist-only.