Milestone and date

I was reviewing a project plan with a team member today, when we discussed how to define milestones and give them dates. A lot of engineers will define milestones like 1. Collect requirements - 1 week 2. Write design doc - 1 week 3. Complete coding - 2 weeks … It is a plan. That is better than not having a plan at all. However these milestones and dates don’t mean a thing to stakeholders. First, stakeholders want to see something that give them values, or at least on track to give them values. “Complete coding” does not deliver any values to stakeholders. If the code is deployed to Production system and customers can benefit from the change, that is value. If the code is deployed to preproduction system, going through integration, alpha, beta and gamma testing, at least stakeholders know the change may deliver value to customers soon. The milestone statement could be “Deploy the change under feature flag to region xxx”. That is so much better! Because someone will be able to use the feature for real, within the safety guardrail. Second, “code completion” is not a measurable goal, or you can say not a SMART goal to stakeholders: Specific, Measurable, Achievable, Relevant and Time bounded. Code completion might be measurable by engineers, but it means very little to product management. It is not measurable to business stakeholders or customers. Similarly, “Write design document” is not measurable either. “Have a design document signed off by paterner teams” is measurable. “Collect requirements” is also not measurable. “Have a PR/FAQ doc agreed by Production Management” is measurable. Third, the way we express time in milestones should be meaningful to stakeholders. X weeks, Y sprints are not meaningful to a General Manager (GM). Should we expect the GM to count when this milestone will be done by their fingers? If you require your stakeholders to do these kind of mental acrobats when reading your project plan, you’ve lost. Give the date you plan to complete the milestone. And don’t make it a weekend or holiday please. If your completion date is 1/1/2023, well, do you really plan to work on the New Year’s Day? The most important thing for a project plan, or any documents for communication purposes, is that they should be written for the readers - the stakeholders. Your readers are your customers. So be obsessed on how they read your project plan - what should they get out of the plan? What is relevant to them? Cut down all the unnecessary stuff. Know who are your stakeholders: your milestones and dates should be for them. You use the milestones and dates to keep your stakeholders on the same page, all the time. If you are going to miss the date for the incoming milestone - it happens to any non trivial projects - communicate early, give stakeholders alternatives, how you will get back on track. Customer Obsession - Amazon’s No.1 leadership principle!