Milestones: Love Them or Hate Them


I just love milestones. I just love milestones when I take a cross-country trip. I just love milestones when I drive from Boston to Cape Cod. I just love milestones when I walk our three dogs. I just love milestones when I run or jog. I just love watching the milestones on the inflight TV when flying from London to Boston.

I just hate milestones as a measurement for project progress. To me, milestones are a useless measurement for software projects. To me, milestones provide false comfort during a software project. To me, milestones furnish a misleading indication of progress on a software project. I just hate milestones.

In a project postmortem session a few years ago, we asked one of the delegates how far the project got with the previous effort and the reply was, "We got to about 90 percent completion." Astonished by this revelation, we followed up with the obvious question, "Then why did you cancel the project?" The retort was, "Because we had 90 percent left to go!" In tracking software project requirements, milestones can be misleading, and they are false indicators of progress; they are false metrics. Missing a milestone can be bad news. Missing a single milestone can cause the project to lose the support of the executive sponsors, stakeholders, users and finance. Missing more than one can and maybe should result in the cancelation of the project.

Many organizations try to define the content of the milestones objectively, but most often they are not well understood. The process is arbitrary and error-prone. Milestone creation can be influenced by many factors. We find that very often the milestone is made to fit into the budget and time frame without fully understanding the tasks or effort required. It is very difficult to create the level of granularity by which milestones are set. It takes lots of effort to create and measure milestones when the objectives are foggy. The cost and effort just do not have value—and the pain is hardly worth it.

Milestones are the purest example of everything wrong with how we currently manage software projects. Milestones are linear measurements, but building software is a logical task.

Think about how you would cross a stream. You step on one stone and then look for the next logical or potential stone. We think you should replace milestones with steppingstones. A steppingstone is like a milestone, but it is a firm deliverable. Steppingstones allow you to make progress based on logical deliverables. The promise of a steppingstone is that you will deliver a small, quality product and the stakeholders can see it, touch it, accept it or reject it. Based on the current steppingstone you can see the next opportunity or logical step. Each steppingstone brings you closer to completion and to obtaining value.

Don’t know how to create steppingstones? Call us. The Standish Group can help to move your organization in this direction with our Value Portfolio Optimization and Management Service

  |     |     |     |     |  

Subject Matter

Project Management Expertise

About the Author:


Jim Johnson

Jim Johnson is chairman of The Standish Group. He has been professionally involved in the computer industry for over 40 years and has a long list of published books, papers, articles and speeches. He has a combination of technical, marketing, and research achievements focused on mission-critical applications and technology. He is best known for his research on project performance and early recognizing technology trends. Jim is a pioneer of modern research techniques and continues to advance in the research industry through case-based analytical technology.

The Standish Group
Jim JohnsonJim
Jim CrearJim
David JohnsonDavid
Hans MulderHans
Jan PoortJan

The Standish Group News

The Standish Group Events


CHAOS Tuesday Podcast

The Dezider