Milestones and risk management

By Eugenio, on July 27th, 2009

Titanic in dock

Thanks Craig. You got right about the need for frequent and more specialized controls.

By the way, originally “milestones” (in the Roman roads) were set every mile (0.91% of the Imperial mile). Every day-long leg (15-18 miles) there were structures serving both passengers (divided by categories) and animals. An interesting point was that all measurements were taken starting from just one point.

In essence, all the territory was divided in smaller units for making possible and easy any comparison.

Milestones and BDUF

In many fields, in order to obtain the needed money, customers want to see “detailed” specification both in time and features.

These types of situations needs that controls are set in two different and complementary ways:

Consider the check point as a tool for setting guidelines (assuming that big projects span over long periods. Therefore, impending modifications are difficult to be avoided).
Once operational details are left to the team, controls have to focus on its capacity to deliver up to the specifications, both in terms of “quality” and “quantity”.

Some organizations, which rely on “functional model”, view in the BDUF a way to reduce risks. This viewpoint obtains a huge increase in threats to the output. A rigid structure is fragile. Titanic offered a terrible example, how a fragile structure was dealing with uncertainties.

For their nature, milestones are there for measuring results.

Any change is a result. Assuming the need for controlling performances for business reasons, there is a list of questions that could help us in the definition of what is measurable (and why):

Who decided and approved what shall be measured?
When controls should be activated? Where a trade-off between frequency and costs has to be struck)
What is the standard value for comparing so different items? For example, analysis and development need different approaches for measuring results. If money, it has to be actualized using parameters that are based on common and shared values)
How can we evaluate the stakeholders’ importance (and priorities)? Either in evaluating results vs. committed efforts.
Which is the reference for measuring the direction (thinking in terms of polar coordinates)

Some technical concerns

Regarding the analysis, controls can easily verify the business area covered.

Whether the outcome complies with developments and then the business viewpoint or not, is a much more difficult task. The evaluation can be done after the successful execution of functional tests.

At a development level, for customers’ viewpoint the GUI offers much more room for appraisal within shorter periods, than an enterprise business logic or databases developments.

When milestones can be conceived?

In my opinion, 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.

Conclusion

I am conscious that the concept of “done” has been left out from this post. It seems easy to establish rules on pure technical matters. However, it cannot be limited to a checkpoint list (although it is necessary). “Done” should be enlarged until it includes the idea of “sold”.

“My life is full of mistakes. They’re like pebbles that make a good road.”

A PM's workshop