The power of milestones

Published on and tagged with project management

If we categorize projects according to the number of defined milestones we get three groups of projects:

  • Projects without any milestones
  • Projects with just one milestone
  • Projects with more than one milestone

Ok, before I go on, I want to define the term “milestone” as it is used in the context of this post:

A milestone defines a date when some predefined goals should be accomplished.

With this definition, it seems at first sight that projects without milestones are like dream projects. There are no deadlines to meet and so you can build the perfect solution. Wow, cool! Well, the reality looks a bit different. It is rather unsatisfying to work on such a project, as you know that the “client” doesn’t really care about the project. And according to Parkinson’s law it takes forever to finish it (if it isn’t canceled before).

Much more common are projects with one milestone, i.e. the project end is predefined. That works fine for smaller projects with a duration of 2-4 weeks. But if you use that approach for longer projects, you usually will see the following effect: at the beginning you take it easy as the project end is far away, but towards the end of the project it becomes stressful and you have to do overtime. Something I don’t like ;-)

So to avoid, or at least to reduce, such stressful times it helps to define several (realistic) milestones. How many milestones you should define depends on your personal preferences. Personally, I define a (mini) milestone at the end of each week. That allows me to have an evenly distributed workload with almost no peaks :)

2 comments baked

  • Ben

    Or, you can go a slightly different route and define a milestone by features. When the features are done, the milestone has been reached – time taken be damned.

    Obviously not the best for a commercial project, but not too bad for free open-source projects.

  • cakebaker

    @Ben: Thanks for your comment. Yes, I agree, that’s probably the way chosen by most open-source projects.

Bake a comment




(for code please use <code>...</code> [no escaping necessary])

© daniel hofstetter. Licensed under a Creative Commons License