milestone: a stage in a child’s development at which they can do a particular thing for the first time

When Thinking in Projects, it becomes tempting to think of the project as a single deliverable: the change which, when dropped, satisfies all the requirements neatly and delights all your stakeholders. Such projects might be called “all-in” projects1: the kind that only yield value after a protracted effort.

My sense is that most projects I’ve worked are not innately structured in this way: rather, they lacked milestones - touchpoints that enabled earlier delivery of value. What that means is context-dependent, but can be any of:

  • Delivering some feature for a subset of potential use cases
  • Hardening the security of some services that are most sensitive
  • A marginal improvement of some frustrating developer experience

Plotted crudely, we can contrast these two different approaches: Alt Text

There’s ample reasons why we want to organise project delivery to be more “B”-shaped than “A”-shaped:

  1. Trust: people believe in your progress updates if they can see them in some means.

    Milestones can be that visual progress.

  2. Progress tracking: if you can state in advance what would have to be true?2 in order for the project to be successful, you can adapt much sooner if any of those conditions ceases to be true.

    Milestones can represent those conditions.

  3. Flexibility: if you are delivering value early, you can also pause the work. You can continually assess if the project remains the most valuable thing to be working on.

    Milestones can provide you with Slack3.

  4. Feedback: the sooner you get software into users’ hands, the sooner you can learn whether this solves their problems, or whether tweaks are needed to the original direction you’d imagined.

    Milestones can create tighter feedback loops.

Some example milestones I’ve used in the past:

  • Dummy data is flowing between every application in a test environment and can be seen in the UI.
  • The user can now have automated validation of uploads of this type, but we must continue to manage that type through a manual process.
  • You can now easily find logs and traces for all HTTP JSON APIs running across our EKS clusters, but cannot do so for GraphQL APIs or lambda functions.

In short: milestones can push your projects from “All-in” towards more flexible, less risky and more easily managed milestone-led projects.

Footnotes

  1. https://docs.google.com/document/d/1XRx4p8cvA7r8RujYQhqFyTBSFAY7L9XJw_sifivRIaY/edit?tab=t.0#heading=h.wbqcefhwz1jf

  2. https://rogermartin.medium.com/what-would-have-to-be-true-83dac5bd2189

  3. https://thezvi.wordpress.com/2017/09/30/slack/