PostHeaderIcon Completion Criteria Ensure Done Means Done

How do you know for sure when something is declared “Done”, that it really is? By defining completion criteria. These little nuggets are one of the single most important – yet frequently overlooked – aspects of project planning.

Completion criteria root out ambiguity (see The First Law). They align stakeholders, team members and the customer on the conditions for acceptance and validation of the project outputs. And they improve estimating quality by enhancing understanding of the desired work result.

Its a Binary Thing – “done” or “not done”

Completion criteria should be defined first for the project deliverables, which in doing so will actually help identify tasks for the WBS, and second for (ideally) each task in the WBS itself. Well-written criteria:

  • Are defined by the deliverable or task owner
  • Clearly state the characteristics and attributes of the output  – “what done looks like”
  • May include the measurement and validation requirement – e.g. “who reviews what”
  • Are defined in a binary way (i.e. totally unambiguous).

Can we really do this for every task? You decide – it’s a tradeoff between increased planning effort vs. increased risk. But consider that while this may initially seem onerous, the reality is that it does not take much more effort to write a statement or a couple of bullets specifying what ‘complete’ means (for example in the Notes field in Microsoft Project). Put in the context of the project overall, it’s a seriously small price to pay for dramatically increased clarity and reduced risk of misunderstandings.

  • Delicious
  • Facebook
  • Twitter
  • LinkedIn
  • Digg
  • Google
  • Reddit
  • StumbleUpon
  • Technorati
  • RSS Feed

2 Responses to “Completion Criteria Ensure Done Means Done”

Leave a Reply