I recently watched a group of workmen take down a building safety barrier.

There were five workmen – two had hard hats on (risk management) but they stayed well away from the action (auditors?). The three workmen doing the work had no hard hats.

The safety barrier was about 8 feet tall. The smallest member of the team, about 5’ 6”, was trying to unscrew the barrier with an electric drill in reverse mode.

To enable this activity there was a ladder – which was ignored.

Instead the small team member tried to hang off the top of the barrier with one hand while trying to align the drill and screw heads with the other as he swung to and fro. Occasionally he was successful. Other times he gave up and asked the 6’ 6’ co-worker to do it for him (which he could do just standing on the ground!)

Later it struck me how typical of some projects this episode was.

Risk management was largely ignored – although some were giving it token acknowledgment.

The tools provided (ladder) were ignored – “We know a better way even when it is not working”

A lack of true teamwork. The people with the skills/knowledge (in this case height) saw that it was not their job to unscrew the top screws until it was the only way they were going to get the job done.

A lack of management. Those watching (with their hard hats on) made no move to change what was obviously an inefficient and dangerous activity.

The job was completed in much more time (and, therefore, cost) than necessary and at higher risk, but would be claimed as a success as the barrier came down.

Now how many completed projects do you know that have these attributes???

Post your comments.

© Jed Simms, Australia, 2010

I recently reviewed a $15m project that was struggling. It was already 6 months late and likely to slip another 6 months, yet its risk log contained only three risks, one of which related to delivery. Overall, from a risk perspective, the project was rated ‘Green’.

When we performed our standard delivery risk analysis against the project it came out Amber with spots of Red.

Although the project was 9 months old, its requirements were still not finalized, the design was a moving feast and the cost of failure was escalating due to some of the decisions made to date. Yet it only identified one delivery risk — that the software component, that was on the critical path and had been outsourced to a vendor, may be late.

This missing of the obvious delivery risks is not an isolated case. Frequently our health checks find the root causes of major problems are delivery risks that were never identified and therefore not managed by the project.

‘Laundry lists’ of potential risks don’t help. Relevant risks still get ignored and extraneous, highly unlikely risks can be picked up ‘just in case’.

I’ve also seen several risk scoring approaches that may encourage people to score a risk as high but, as there is no action attached to rating the risk, the risk disappears into the scoring system never to appear again. Worse, the project team believe that they have ‘dealt with that risk’ by scoring it!

In addition, because the realization of benefits is still seen as outside the focus of most projects, risks to the delivery of the benefits and value — the reason why the project was commissioned in the first place — are usually not considered at all.

Why?

One reason for this seems to be that scoring delivery risks can be seen as rating the project team. If you rate, say. requirements risk as “high” (ie unstable) are you saying the project team hasn’t done its job in this area? I remember, when running a team through our standard delivery risk profiling process, the project manager objecting violently when the team wanted to rate requirements as ‘red’. As far as he was concerned they were clear and complete (but he was alone in this view).

Also, when brainstorming sessions or other methods are used to identify potential risks the focus seems to be more on outside factors that can threaten the project (Eg The resources are not made available in time) rather than the internal delivery status and capability risks.

Simple solution

This is why I devised a simple, quick but highly effective Delivery Risk Management process. To get a clear picture of your project’s delivery risks you only need to assess 10 project delivery and 10 benefits delivery risk categories.

In both cases three of these risks are what I call “environmental risks”. These environmental risks are inherent in the way the project has been set up and cannot be mitigated except by changing the project. They provide a context and multiplier on the remaining seven risk categories.

For example, if the risk of failure (an environmental risk) is low, then the potential business impact of unstable requirements is lower than if the risk of failure was high.

Each risk has four risk level options presented to ensure comparability of responses. Teams can score both their current and the targeted risk levels and then plan to manage the risk down to the targeted risk level. This simple process rates the risks, sets target risk outcomes and enables planning to manage the risk down the desired level. In addition, a standard, comparable delivery risk profile can be generated.

Each project’s delivery risk profile can then be compared across the portfolio and analysed at the next layer down to see which risk categories are reoccurring and why. This profile can also be used to progressively track the actual risk reduction achieved against the planned reductions. If a project is not reducing its risk profile to plan, this is an immediate (and early) danger signal.

Effective delivery risk management does not need to be complex or time consuming.

Simple, quick and highly effective — our “How to manage your project’s delivery risks” process Guide is now available at valuedeliverymanagement.com.

PS The Delivery Risk process Guide includes the roles of the project practitioner, business, PMO and governance teams and is fully supported with comprehensive workshop guides, profile generation spreadsheets and other materials to make it simple and easy to implement and use.