pm-lotus by Howard Vaughan

Archive for the ‘Planning’ Category

Of all the processes within project management, it would seem that risk management is the one that most often turns into a paper exercise. Lots of projects have lists of identified risks, some have plans to manage those risks but only a few properly integrate risk responses into the overall project plan.

A Small but Crucial Step

Creating risk logs and defining response strategies is a ‘non-productive use of valuable time’ if performed merely to satisfy management, increase comfort levels or just conform to company policy. Those documents will gather plenty of dust. What’s needed is for that information to become an essential component of the detailed schedule. This is a small but crucial step – and often missed.

Here’s how to do it-

1. Once the project risks are identified, define clear mitigation strategies – i.e. specific actions to proactively (a) reduce probability or (b) minimize or alter the impact of the risk occurrence.
2. These actions can then easily be defined as “tasks” in a verb/noun format – which means they can, and should, be added to the project Work Breakdown Structure (WBS).

In the example above, a section for Risk Management has been added to the end of the WBS task list in the Microsoft Project plan. Each of the tasks within that section is an explicit risk response activity. Each task will therefore be assigned an owner, linked into the schedule with appropriate duration and resource estimates, and then executed and tracked in just the same way as any other task in the schedule.

Now, we have made risk management real. Its an integral component of the execution plan – not a paper exercise. Remember – if its not in the WBS, its not in the project.

An important aspect of the project manager’s role is the appropriate balancing of trade-offs among the primary project constraints. In most cases this means determining priorities among schedule, scope and resources. The relative importance of these should be defined unambiguously by the project sponsor and then reflected by the PM in a matrix:

Forcing clarity on project constraints and priorities

In the example above, schedule is deemed to have the least flexibility, meaning that everything possible shall be done to meet the target completion date, even if scope has to be compromised in some way, or more preferably, by adding resources to expedite the schedule. It is important to state WHY a particular constraint is either least, moderately, or most flexible, according to the sponsor’s priorities, with guidance on the relative limits of flexibility (so no blank cheques).

This little tool is invaluable to the project manager during both planning (in ensuring the right focus in optimizing the project plan before baselining) and execution (in guiding both the tracking effort and corrective action in the event the project deviates from the plan).

While the relative priorities can be changed by management as desired, a simple rule must be followed to prevent insistence that everything be least flexible – only ONE check allowed per column and ONE check allowed per row.

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.