26 July 2009

Milestones / Signs

Eugenio highlights the fact that milestones are waymarkers, and that in fact it's the work between the milestones that builds our solutions.  That's true. 

Milestones are a point where you can reflect on where you have been and where you are going.  Are you still heading in the right direction?  Are you as far down he road as you expected to be?  What's happenned on the road so far, and what lessons can we learn from our experiences?

In my post the other day I talked about how you can break large tasks down into smaller tasks to the degree that they become a repeatable process.

An example; instead of spending 2-3 months going through a requirements elicitation and definition phase you can break this down to an ongoing process, say of a regular weekly meeting throughout the project lifecycle.

You can still have milestones, and the opportunity to plan milestones around the completion of certain groupings of fucntionality or releases remains. 

What might change is that the milestone becomes less of a marker of what has been completed (say as a percetage of total work, or schedule) and becomes more of a reflection of where you have been and where you are heading.  Maybe it makes for a more eflective session?

1 comment:

  1. ...they should be produced by a “logical system”, either during the issuing of WBS or Product Backlog. It will be the project’s nature to dictate the frequency and type of milestones. The concept of making them repeatable is a huge bonus. A partial solution could be finding in the automation of the data collection, the rest remains up to each project manager’s ability to deal with stakeholders.