When to use this

• When you need a lightweight project planning process
• When you want a process optimized for engineers, only plain text
• When the effort estimate is 4+ weeks

When to not use this

• If you have 10+ teams to coordinate, you're better off with a Technical Program Manager.
• If you have several parallel projects, this may not be practical.

Why to use this

• When you want to de-risk the project by reducing unknowns early in the project process, like
  Tracer Bullet Development
• When you are dependent on other teams, and you want to make sure that you are following up with partner teams on what needs to be done by when

Notes on the template below

• MMM DD is the date of the start of the week, i.e. Monday.
• Dependencies can include the meetings you want to schedule with partner teams for alignment on the timeline and tasks, and later follow-ups on integration
• Milestones can include initiatives to be launched as part of OKRs
• Tasks are specific next action items with the task owner listed, usually related to the milestones above
• "Highlight of the week" and "Lowlight of the week" is to track the wins and challenges, for sharing with teammates and management, as well as for later inclusion in your self-eval perf review doc.
• The goal is to have a realistic plan, so account for on-call weeks, etc. in the plan itself.
• If you want to use this, fill this out before the project kicks off, because it's not going to happen later, you'll be busy in the details.
• Looks to reduce unknowns in the early weeks with spike work
• Add weeks, in correct sequence, for company processes like arch review, ops review, security review, deploy process, staging process, integration testing, sandbox for customer success and sales engineer, etc.
• Usage of this template is successful when engineers can work autonomously during dev phase, there are no surprises or delays (exceptions should be rare), no "rush" phases, no weekend work, there is room for experimentation, progress is easy to track, easy to spot if someone is stuck, easy to gauge if we underestimated effort or did not foresee something (useful knowledge for the next project).

Template

# Week 1 - MMM DD

- Dependencies
    - Who: What
- Milestones
    - M1:
- Tasks
    - Who: What
- Highlight of the week
- Lowlight of the week

# Week 2 - MMM DD

- Dependencies
    - Who: What
- Milestones
    - M1:
    - Demo (ideally every 2 weeks)
- Tasks
    - Who: What
- Highlight of the week
- Lowlight of the week

... _repeats_

Appendix: Why this follows

Modern Agile

1. Make People Awesome
• This is a tool for you
• Goal is for you to be awesome at planning and delivering projects
• We will take the learnings from the experience to do better job of estimation and planning for the next project
2. Make Safety a Prerequisite
• This is only to be discussed within the team, in a shared google doc
• This is not for showing anybody outside the team
• It is expected that you will keep changing & updating the list
3. Experiment & Learn Rapidly
• Reduce unknowns early in the process, in the first few weeks
• Budget time for learning new things, such as new codebase, new library, new concepts, etc.
4. Delivery Value Continuously
• Milestones should be demoable and concrete
• First milestone should be end-to-end, i.e. cover the breadth
• Subsequent milestones should be about depth in one or few areas
• Last few milestones should be available to PM and partner teams to play with
• Last milestone should be available as sandbox for everyone in the company to play with