What “done” can be defined.

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