In my post, following a thread created by Craig Brown and developed by Glen Allen, I closed it confessing my difficult to offer a clean definition of what can be defined as “done”. In my mind there is the “Prince2” definition that sounds:

“Everything that has passed the tests based on stately accepted [...]]]>

Where to cut

In my post, following a thread created by Craig Brown and developed by Glen Allen, I closed it confessing my difficult to offer a clean definition of what can be defined as “done”. In my mind there is the “Prince2” definition that sounds:

“Everything that has passed the tests based on stately accepted criteria”.

However, this leaves some room for the human factor. It is true, especially the perception from stakeholders about what can be accepted. Many stakeholders’ categories (graph) have different viewpoints on both terms of features and quality. In particular about:

1. What can be delivered (developers)?
2. What can be accepted (customers)?

The answers could be found in the Glen’s questions and my answers:

1. Can we state clearly and concisely what “done” looks like? Can we state the intermediate versions of “done?” Can we state this in some units of measure meaningful to all the stakeholders?
   • It can be carried through the completion of all required operations, followed by the functional testing of the output. The results, expressed in percentage, state the readiness of the product. In this way all stakeholders can find a common ground.
2. Do we know what it will cost to get to “done” or any smaller version of “done” along the way? This cost is usually measured in money. But people and other resources are part of the answer as well.
   • EVM (properly managed) could measure the ratios between efforts (monetized resources) and results (passed functional tests).
3. Do we know the date of when we’ll see “done” or any part of “done?” What the variance on this date? If we don’t know the date of the final “done,” how about a “date for the date?”
   • At work-package level (team) these evaluations shall be done frequently and openly (involving the customers in clear and friendly terms). At a “higher” level, the “IMS” (major plan) should be based on precise dates (including tolerances).These will supply (together with the WBS and then Product Backlog) the criteria for shaping the gateway destined to evaluate progresses. The terms and conditions each of these processes shall be verified (and confirmed) at each level. In my previous post were described the risks implicit in setting a rigid structure up.
4. Do we know how we will measure progress along the way? How will we have confidence that progress is actually being made? What are the units of measure for this progress?
   • Planning (at project level, leaving details for the work-packages) shall include Risk Management and Test. The definition of capabilities (features) cannot be done without stating clearly what has to be used for measuring them.
5. Can we see what is going to impede our progress toward “done?” Do we have any way to remove these impediments so we can get to “done?”
   • Only if the product is clearly described (at various levels and times) it is possible to manage the production and consequently the outcome.

Conclusion

“You can manage only what you can measure”. This notwistanding the article of his father (DeMarco).

D/load PDF version

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 [...]]]>

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:

1. 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).
2. 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):

1. Who decided and approved what shall be measured?
2. When controls should be activated? Where a trade-off between frequency and costs has to be struck)
3. 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)
4. How can we evaluate the stakeholders’ importance (and priorities)? Either in evaluating results vs. committed efforts.
5. 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.”

More readings

http://svprojectmanagement.com/are-you-organized-for-success

Photo from http://www.nordikfolk.com-a.googlepages.com atitanicstorybymike&ernstulrikpersson  May 4, 2008