Home > The Lean Post> Orchestrating Your Product Development Process with Milestones
The Lean Post
Sharing how the world is making things better through lean.

Orchestrating Your Product Development Process with Milestones

by Jim Morgan
August 25, 2016

Orchestrating Your Product Development Process with Milestones

by Jim Morgan
August 25, 2016 | Comments (4)

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?

The views expressed in this post do not necessarily represent the views or policies of The Lean Enterprise Institute.
Search Posts:
Improvement Kata / Coaching Kata
Elizabeth Carrington, Mike Rother & William Costantino
Lean Product and Process Development, 2nd Edition
By Allen C. Ward and Durward K. Sobek II
Seeing the Whole Value Stream
By Dan Jones and Jim Womack with D. Brunt, M. Lovejoy
Was this post... Click all that apply
18 people say YES
18 people say YES
13 people say YES
11 people say YES
Related Posts
4 Comments | Post a Comment
Suzanne van Egmond August 29, 2016

Hi Jim - Thanks for this excellent compilation of how to do Milestones in a lean way!

While reading it, I notice you do not mention very much the word "deliverable" - and I guess that is for a reason. In many organizations I work with (all within the same company with a very extensive stage gate process) I see often the milestone is seen as a collection of deliverables; and project managers as well as reviewers are chasing those, missing the "real purpose" as you put it.

In lean literature, like Mascitelli, you read about "semi-permeable gates" in order to prevent waiting for all of the deliverables, where some streams could still progress. In this type of literature, the general opinion is that a stage gate process as such is not very lean.

I am interested in your views on these aspects!


Reply »

Jim Morgan August 29, 2016
1 Person AGREES with this reply

Hi Suzanne,

Thanks for your note.  You are correct - I have found "deliverables" to be an over used term.  In fact, some companies chase milestone "deliverables" in a sort of mindless, check the box way in order to receive "approval" without ever really understanding what is critical to the product/project. This approach can seriously undermine the value of milestones and leads many teams to question why they exist.

I am not familiar with Mascitelli, but your description sounds about right.  It is about diffeentiating normal from abnormal condistions to help the team navigate their way forward.  In my experience, there are always problems in development programs.  What matters is the teams ability to identify and resolve issues early and effectively with the full support of the enterprise and milestones should help you do that.  In my view it is not milestones in and of themselves that are "not lean" (in large, complex projects especially they are crucial) - it is how they are created and used by many companies that causes the problem.

By the way, everything I said abour integrating and synchronizing across Functional organizations also applies to your key suppliers.  

Reply »

Suzanne van Egmond September 06, 2016

Thanks Jim, for your reply. Now, I like your article even more! ;)

Do you have any thoughts on how to monitor the Milestone process so that it does not slide into a state of being far from useful focused on checking boxes? I ask this because I think most stage gate systems are actually intended as you sketch it, but apparently over time transform into this unwanted situation.

Reply »

Jim Morgan September 10, 2016


There are a couple of things you might think about:  

1) Review and confirm specific intention of milestones at individual program kick off meetings and reinforce this agreement at subsequent milestone reviews.

2) Clearly identify a development process owner or owning organization who collects capability data over time and across programs, identifies process improvement opportunities, and is the "voice of the (horizontal) process" at review events and elsewhere.  Most development processes are not perfect the first time you roll them out - take a PDCA approach to your development process and plan for a regular improvement cadence.

Beyond these two tactical recommendations, this is a fundamental responsibility of leadership - to support the program teams and keep the organization moving forward in their LPPD improvement journey.

I hope this helps a bit.


Search Posts:
Improvement Kata / Coaching Kata
Elizabeth Carrington, Mike Rother & William Costantino
Lean Product and Process Development, 2nd Edition
By Allen C. Ward and Durward K. Sobek II
Seeing the Whole Value Stream
By Dan Jones and Jim Womack with D. Brunt, M. Lovejoy
Green from the Start
Development is a Team Sport
Please include links as plain text URLs only. Do not copy and paste directly from a web page or other document. Doing so may pick up additional HTML that will not function here.
URLs will be converted to functioning links when your comment is displayed on the site.
Here's an example:
See this article for more details: https://www.lean.org/whatslean