pm-lotus by Howard Vaughan

Posts Tagged ‘Planning’

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’:

• Are deliverables defined with clear boundaries?
  • Are there detailed and explicit descriptions of inclusions and exclusions?
• Are completion and acceptance criteria clearly stated for each deliverable?
  • Do we know what “done” looks like for each deliverable?
• Are tasks defined at an appropriate level of detail?
  • Are most tasks in the range of 4-40 hours of duration? (a useful guide for most projects)
• Are task outputs tangible?
  • Have the outputs been agreed upon by their owners and dependents?
• Is progress tracked at task level?
  • Is evidence of progress validated before being reported upward?

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)

PMI gives only scant coverage to interfaces (inter-project or external dependencies) in its Standard for Program Management. However, mis-managed interfaces have the potential to cause days or even weeks of delays and consequently wreak havoc with schedules – and often do.

Effective interface management involves full and complete interface definition. A good list of defining attributes would include the following:

Outputs don't always match input requirements

• Interface name
  (unique naming and identification)
• Interface description
  (nature and purpose of the interface)
• Output source
  (which sub-project supplies the output)
• Output owner
  (who is accountable for the output)
• Input receiver
  (which sub-project is the ‘customer’ for the output)
• Input owner
  (who is accountable for receiving the input)
• Completion criteria
  (what the interface ‘looks like’ when its done)
• Date constraints
  (if applicable)

The completion criteria should be defined as a checklist of requirements from the input owner. He/she will then use these as the basis for full acceptance of the interface as ‘done’ or ‘not done’.

A hammock task can be defined as either a summary task that aggregates a related set of activities, or an actual ongoing activity whose start and finish is driven by other tasks or milestones that may or may not be related. In the first case, summary tasks are easily created using the outline feature in Project of course but the second case can present more of a challenge.

In the simple example below, two non-summary hammock tasks are shown.

Both hammocks reflect ongoing activity from the start to the finish of the project. To create Hammock A:

• Click in the Start cell for the project “Start” milestone and choose the Copy command
• Click the Start cell for “Hammock A” and choose Edit, Paste Special, Paste Link, and click OK
• Click in the Finish cell for the project “Finish” milestone and choose Copy
• Click in the Finish cell for “Hammock A” and paste as a link again

A problem with hammocks is that they may show up as critical items (as here with Hammock A) whereas in reality they do not actually drive the project schedule. Hammock B shows how we can avoid this by linking the finish date to a ‘dummy’ milestone “Finish -1″ that we set to finish just before the project finish (predecessor is Finish milestone SF-1).

Using either approach above will allow the hammock to ‘stretch’ or ‘shrink’ as the durations of the other tasks change, during plan updates for example. If necessary, a manual click on the F9 key will force a correct recalculation of the hammock’s duration.