Timeline and Milestone Language

Timeline language in an SOW is where confident writing most often turns into overcommitment. The impulse is understandable: clients want certainty, so you write with certainty. "Phase 1 will be complete by April 15." The problem is that April 15 is a function of a dozen assumptions that are not stated anywhere near the date, and when one of them fails, the date fails without explanation.

The alternative is not vague language — it is explicit assumptions alongside specific dates. The commitment is real. The dependencies are visible.

1. Distinguish Milestones from Dependencies A milestone is an outcome you control. A dependency is a precondition you do not. "VENDOR delivers the initial architecture document by Week 3" is a milestone — VENDOR controls it. "Client provides API credentials by Week 1" is a dependency — client controls it. Both belong in the timeline, clearly labeled. When a dependency slips, the downstream milestone slips with it, and the SOW language makes this consequence explicit rather than a subject of dispute.
2. Write Dates as Elapsed Time, Not Calendar Dates Calendar dates in an SOW become wrong the moment the project starts later than planned — which is most projects. Elapsed time ("Week 3 after project kickoff," "within 10 business days of contract execution") stays accurate regardless of the start date. Exception: regulatory or fiscal-year deadlines that are genuinely fixed should be stated as calendar dates, with a note that the project schedule assumes a start date of [X] to meet this deadline.
3. Define What Happens When Timelines Slip The SOW should specify the process for handling timeline slippage before it happens. Who notifies whom, within what timeframe, when a milestone is at risk? What constitutes a delay that requires a formal change order versus a delay that is absorbed within the original engagement? These are uncomfortable conversations to have during an active project. They are simple conversations to have when writing the SOW, because neither party is yet invested in being right.

## Project Timeline

All dates are calculated from the project kickoff date, which is
defined as the first day of the first scheduled kickoff meeting.
This timeline assumes all client dependencies are met as specified.

Week 1–2: Discovery
  Milestone: VENDOR delivers discovery findings document
  Client dependency: Client designates 3 subject-matter experts
    available for up to 4 hours of interviews in Week 1

Week 3: Architecture Design
  Milestone: VENDOR delivers draft architecture document
  Client dependency: Client provides API documentation for all
    in-scope systems by end of Week 2

  [NOTE: If API documentation is received after end of Week 2,
  the architecture milestone shifts by the same number of
  business days as the delay, without change order.]

Week 4: Client Review
  Client dependency: Client returns written feedback on architecture
    document within 5 business days of delivery

Week 5–6: Implementation (Phase 1)
  Milestone: Phase 1 features available in staging environment
  Client dependency: Client provides staging environment access
    by start of Week 5

Week 7: Integration Testing
  Milestone: Signed test results document from both parties