Project Schedule

The process

Every project moves down these steps in order.

What it records

These fields come with the template. Add your own, rename them, or delete the ones you do not use.

• Project nametext
• Client nametext
• Project leadtext
• Kickoff datedate
• Design complete datedate
• Build complete datedate
• Launch datedate
• Review datedate
• Notestext

Step by step

The documentation below ships with the template. It is what your team reads on the step itself while they are doing the work, not a manual filed somewhere else.

1. 01

   Planning

   Scope, owners, and a confirmed kickoff date.

   Required before the job can move on

   • Project name
   • Project lead
   • Kickoff date

   Also on this step, but optional: Client name.

   Purpose

   Define the project clearly enough that everyone agrees what we're building, who owns it, and when work starts.

   Tasks

   1. Set project_name and the project_lead who owns the project end-to-end.

   2. If the project is for an external customer, fill in client_name.

   3. Agree the kickoff_date with stakeholders — this is when the team actually starts work, not when the contract was signed.

   4. Draft target dates for design, build, launch, and review. You can put placeholders in those fields now — they'll show up on the Timeline as planned dates and update as the project progresses.

   Gate to advance

   project_name, project_lead, and kickoff_date must be set.

   Notes

   Enable the Timeline plugin at /plugins to see every project's milestone dates plotted as a Gantt-style view. Each date-typed field with a value becomes a sticky-note card on the timeline — the more dates you set, the richer the view.

2. 02

   Design

   Architecture, design, and spec work in progress.

   Required before the job can move on

   • Design complete date

   Purpose

   Lock the design before anyone writes production code or commits to a delivery date. Cheap to change here, expensive everywhere later.

   Tasks

   1. Produce the spec, wireframes, or architecture doc appropriate to the project.

   2. Get sign-off from the project_lead and any external stakeholders.

   3. Set design_complete_date to the day the design was approved.

   Gate to advance

   design_complete_date must be set.

   Notes

   If the design is taking materially longer than planned, update design_complete_date to the new target — the Timeline view will reflect the slip automatically.

3. 03

   Build

   Implementation and internal testing.

   Required before the job can move on

   • Build complete date

   Purpose

   Build the thing. Keep the launch date in sight; flag slips early.

   Tasks

   1. Implement against the agreed design.

   2. Run your own QA — don't punt unknowns to launch day.

   3. Set build_complete_date when the build is done and ready for deployment.

   Gate to advance

   build_complete_date must be set.

   Notes

   If scope expands mid-build, push the dates rather than burning the team. Re-plan is normal — slipping silently is not.

4. 04

   Launch

   Going live — deployment, comms, and final checks.

   Required before the job can move on

   • Launch date

   Purpose

   Ship it. Coordinate the launch so the work the team did actually reaches the people who'll use it.

   Tasks

   1. Deploy or release per your project's runbook.

   2. Send launch comms to internal teams and (if relevant) the customer.

   3. Monitor the first hours/days for issues.

   4. Set launch_date to the day of go-live.

   Gate to advance

   launch_date must be set.

   Notes

   If the launch is staged (soft launch, then general availability), use launch_date for the first public release. Note the staged dates in notes for the retro.

5. 05

   Review

   Post-launch retrospective and close-out.

   Required before the job can move on

   • Review date

   Purpose

   Learn from the project before the team moves on. A 30-minute review now saves the same mistakes on the next one.

   Tasks

   1. Hold a short retrospective with the team — what worked, what didn't, what we'd change.

   2. Capture takeaways in notes so they survive the project being archived.

   3. Hand off any ongoing maintenance to the relevant team.

   4. Set review_date when the retro is done.

   Gate to advance

   review_date must be set. Terminal step — archive after.

   Notes

   A good time for the review is 2–4 weeks after launch — far enough out that real usage data has come in, close enough that memories are fresh.