Posts Tagged ‘Estimating’

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.

PostHeaderIcon Credibility requires Detail (the 2nd Law)

Most projects are underplanned. They’re already late before they start. For a host of reasons – the usual suspects include a lack of project management discipline, inadequate tools and training, unclear objectives, top-down influence, overworked and under pressure team members – projects get planned with insufficient detail.

The reality is that detail is the basis for accuracy in all projects. Plans that lack appropriate detail can’t be believed. This is what I call the Second Law of project management.

The consequence of a lack of detail is a project suicide spiral:

Understate what’s needed… Misunderstand what ‘done’ looks like… Miss stuff out… Underestimate time and effort requirements to do the work… Overcommit resources to unrealistic schedules…
Present bad news to customer.

Breakdown Checks

Without a credible plan, a project manager lacks credibility with the team and stakeholders. Only when we get to the detail is the full extent of work revealed, which means developing a great Work Breakdown Structure. Here are a few WBS must-do’s:

  • Ensure tasks are small enough so that-
    • Estimates of effort and duration are as accurate and credible as possible
    • Task durations are typically no greater than the time between progress updates
  • Define explicitly what ‘done’ means-
    • Especially for any task that is unfamiliar, complex or difficult to break down
  • Assign a single owner to each task-
    • Have them verify that the expected workflow minimizes likelihood of any missing tasks
  • Use a checklist of often forgotten tasks-
    • e.g. meetings, defect resolutions, reviews and approval cycles.

They say the devil is in the details – and just looking for a chance to cause trouble. Good process and a little extra planning time will build protection.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)

PostHeaderIcon Ambiguity kills Projects (the 1st Law)

Not so clear

Ambiguity is the enemy of project success. Its one of the first things I instruct new project managers on. I call it the First Law in project management.

Its not hard to find ambiguity in projects. Look closely at the objectives, the requirements, the scope definition and the schedule. Are they each as clear and as accurate as they can be? Most importantly, do we know what “done” really looks like? This is crucial. (Glen Alleman’s prolific and consistently excellent blog at Herding Cats has a host of outstanding posts on this – check it out). Each ambiguity is a potential source of conflict, rework and failure.

Clarity Checks

The antidote to ambiguity is clarity – here are a few items that must be on the ‘Clarity Checklist’:

Leaving ambiguity unchecked simply increases project risk. The pursuit of clarity isn’t always popular because it makes people have to think ahead a little harder. But its necessary. So put on your flak jacket and go on a mission – seek out ambiguity and destroy it… before it does some damage.

(See all 5 Laws summarized in The 5 Laws of Effective Project Management)