Effective milestones are an important part of a company’s development process, especially in today’s era of team-based sprints and stand-ups. Yet many companies struggle to successfully create and employ milestones; and some don’t even understand their relevance beyond updating senior leadership. In fact, the topic comes up so frequently in my travels that I thought it would be worth a slightly longer discussion than usual.
Well-designed, thoughtful milestones do a great deal more than just mollify senior leaders.
Milestones can and should be like the sheet music that, along with a skilled conductor, aligns and guides your development orchestra. To that end, I’ll share some thoughts on the purpose of milestones, how to create useful ones, and a few tips on holding effective milestone reviews.
Milestone Purpose
Milestones, as the name implies, provide important information to the development team to guide them on their development journey.
1) They provide a reference to determine normal from abnormal conditions: Milestones tell the team if they are on track so that they can decide how best to proceed, like the lines on the floor of an assembly-line workstation. In these stations, a set of yellow lines can indicate the percent of work to be completed at that point in time. If the worker is at the 50 percent line, and only 25 percent of the work is complete, he or she can pull the andon to signal for help. The team leader can then come over to help fix the issue in station without disrupting the rest of the line. Of course this system is worse than useless if the team identifies abnormal conditions but has no signaling mechanism, or if leadership does not provide real help to the team. (One example of leadership help in this regard is the cadenced design reviews discussed in my previous e-letter. However, the goal is ultimately to identify and resolve issues early and effectively – to shorten management cycle time and keep the project on course.)
2) They act as key integration points: Milestones are an important part of synchronizing work across functional groups. They should be designed to recognize key interdependencies between disciplines like software and hardware or design and manufacturing and provide common reconciliation points. To do this effectively you must understand both the tasks, and sequence of tasks, within each functional discipline. This detailed knowledge allows you to sync up work across those functions. This lets you maximize the utility of incomplete but stable data to optimize concurrent work. The better companies get at this, the faster they can go. In fact, this synchronization is far more effective in shortening lead-time than attempting to reduce individual task time.
3) Milestones are a critical component of a company’s development operating system. Senior development leaders typically have many different programs to manage simultaneously.
They must have the ability to recognize issues, respond quickly and effectively to struggling project needs and make adjustments as required in the rest of the development factory.
A project-health dashboard built from milestone feedback can be a powerful tool to enable this work if you have properly designed milestones.
Creating useful milestones
My experience here is that milestones, like most things in life, are just about as effective as you make them – both in terms of design and adherence. I’ve found that useful milestones share these qualities:
1) A real purpose: Start by asking yourself, “Why do we have this milestone?” You need to be able to create a clear, concise, product-oriented purpose statement. If you can’t, you should question the need for the milestone. Another way to think about this is, “What problem are you trying to solve with this milestone?” Milestone purpose statements should optimally be linked to the Chief Engineer Concept Paper and reviewed in the program kickoff event. It is also crucial that you align cross functionally on the milestone purpose statement.
2) Clear Quality of Event Criteria (QECs): Many companies create milestones based on activities or events. While this may be necessary it is not usually sufficient. Just completing an activity does not tell you very much about the program status or health. For example, you may complete an early prototype build event, but have done so with component parts that are not the correct pedigree for design or manufacturing process level, thus rendering subsequent testing and learning spurious. You have not closed the required knowledge gap nor reduced risk to a sufficient degree. However, because the team completed the prescribed activity, they and their leadership might be lulled into a false sense of security. By establishing QEC for the milestone, the team gets a more realistic picture of where they are really at in the development journey.
Four things I like to think about in evaluating QEC: A) The QEC should be the critical few predictors of project success, not a wish list of every possible failure mode you can brainstorm. B) Is the requirement binary? C) If it can’t be binary, is there a quantitative range that can be established and measured, and D) If it can’t be binary or quantitative, is there clarity about who decides?
3) Clear roles and responsibilities: It is important that participants are aligned on who is responsible to do what at each milestone. The time to align on this is at the start – not when you reach the milestone.
4) Scalability: Not all programs are alike. Levels of content, complexity and risk can vary significantly across projects. Well-designed milestones can be reconfigured to best fit the program without losing their basic intent or effectiveness.
Milestone Reviews:
1) The first principle in milestone reviews is to support the team. Updating leadership is important, but the primary intent should be to provide help and guidance as required.
2) It’s okay to be red, but it’s not okay to stay red. “What’s your plan to green?” was a question I first heard from Alan Mulally while I was at Ford. While you want to drive fear out of these reviews, you don’t want to eliminate accountability. The team must deliver on commitments.
3) Define who should attend each milestone review. Some reviews require senior leaders, functional representation or particular specialists – others not. Consider the milestone purpose for guidance here.
4) Milestones are an opportunity for the team to regroup, align and sync up on the way forward.They should energize the team; not demoralize them.
Leaders should look at them as a chance to “turbo charge” the team like the old Hot Wheels spin stations.
The cars come out with much more energy than they came in with.
5) Hold the reviews at the gemba whenever possible.
I hope that you found at least a few of these ideas useful. So at the risk of overextending the orchestra metaphor, even the best musicians can sound like screeching cats if they are not playing from the same score. Can better milestones help your team play sweeter music?
