Sunday, February 05, 2012
   
TEXT_SIZE

Managing risk in projects: what’s new?

Hits smaller text tool iconmedium text tool iconlarger text tool icon
David_HillsonDSC_0180_optAddressing the gap between theory and practice with Dr David Hillson, The Risk Doctor

Humans have been undertaking projects for millennia, with more or less formality, and with greater or lesser degrees of success. We also have recognised the existence of risk for about the same period of time, understanding that things do not always go according to plan for a range of reasons. In relatively recent times, these two phenomena have coalesced into the formal discipline called project risk management, offering a structured framework for identifying and managing risk within the context of projects.

Given the prevalence and importance of the subject, we may expect that project risk management would be fully mature by now, only requiring occasional minor tweaks and modifications to enhance its efficiency and performance. Surely, there is nothing new to be said about managing risk in projects?

While it is true that there is wide consensus on project risk management basics, the continued failure of projects to deliver consistent benefits suggests that the problem of risk in projects has not been solved completely. Clearly, there must be some mismatch between project risk management theory and practice, or perhaps there are new aspects to be discovered and implemented – otherwise all project risks would be managed effectively and most projects would succeed.

So what could possibly remain to be discovered about this venerable topic? Here are some suggestions for how we may do things differently and better, under four headings:

1. Principles
2. Process
3. People
4. Persistence

Problems with principles

There are two potential shortfalls in the way most project teams understand the concept of risk. It is common for the scope of project risk management processes to be focused on managing possible future events that may pose threats to project cost and schedule. While these are undoubtedly important, they are by no means the full story.

The broad proto-definition of risk as “uncertainty that matters” encompasses the idea that some risks may be positive, with potential upside impacts, mattering because they could enhance performance, save time or money or increase value. And risks to objectives other than cost and schedule are also important and must be managed proactively.

This leads to the use of an integrated project risk process to manage both threats and opportunities alongside each other.

This is more than a theoretical nicety: it maximises a project’s chances of success by intentionally seeking out potential upsides and capturing as many as possible, as well as finding and avoiding downsides.

Another conceptual limitation that is common in the understanding of project risk is to think only about detailed events or conditions within the project when considering risk. This ignores the fact that the project itself poses a risk to the organisation at a higher level, perhaps within a programme or portfolio, or perhaps in terms of delivering strategic value.

The distinction between “overall project risk” and “individual project risks” is important, leading to a recognition that risk exists at various levels, reflecting the context of the project. It is therefore necessary to manage overall project risk (risk of the project) as well as addressing individual risk events and conditions (risks in the project).

This higher level connection often is missing in the way project risk management is understood or implemented, limiting the value that the project risk process can deliver. Setting project risk management in the context of an integrated enterprise risk management approach can remedy this lack.

Problems with process

The project risk process as implemented by many organisations is often flawed in a couple of important respects. The most significant of these is a failure to turn analysis into action, with risk registers and risk reports being produced and filed, but with these having little or no effect on how the project actually is undertaken.

The absence of a formal process step to “implement risk responses” reinforces this failing.

It is also important to make a clear link between the project plan and risk responses that have been agreed and authorised.

Risk responses need to be treated in the same way as all other project tasks, with an agreed owner, a budget and timeline included in the project plan, reported on and reviewed. If risk responses are seen as “optional extras”, they may not receive the degree of attention they deserve.

A second equally vital omission is the lack of a “post-project review” step in most risk processes. This is linked to the wider malaise of failure to identify lessons to be learnt at the end of each project, denying the organisation the opportunity to learn from its experience and improve performance on future projects.

There are many risk-related lessons to be learned in each project, and the inclusion of a formal “post-project risk review” will help to capture these, either as part of a more generic project meeting or as a separate event.

Such lessons include identifying which threats and opportunities arise frequently on typical projects; finding which risk responses work and which do not; and understanding the level of effort typically required to manage risk effectively.

Problems with people

It is common for project risk management to be viewed as a collection of tools and techniques supporting a structured system or a process, with a range of standard reports and outputs that feed into project meetings and reviews. This perspective often takes no account of the human aspects of managing risk.

Risk is managed by people, not by machines, computers, robots, processes or techniques. As a result, we need to recognise the influence of human psychology on the risk process, particularly in the way risk attitudes affect judgement and behaviour.

There are many sources of bias, both outward and hidden, affecting individuals and groups, and these need to be understood and managed proactively where possible.

The use of approaches based on emotional literacy to address the human behavioural aspects of managing risk in projects is in its infancy. However, some good progress has been made in this area, laying out the main principles and boundaries of the topic and developing practical methods for understanding and managing risk attitude.

Without taking this into account, the project risk management process as typically implemented is fatally flawed, relying on judgements made by people who are subject to a wide range of unseen influences, and whose perceptions may be unreliable – with unforeseeable consequences.

Problems with persistence

Even where a project team has a correct concept of risk which includes opportunity and addresses the wider context; and if they ensure that risk responses are implemented effectively and risk-related lessons are learned at the end of their project; and if they take steps to address risk attitudes proactively – it is still possible for the risk process to fail! This is because the risk challenge is dynamic, constantly changing and developing throughout the project.

As a result, project risk management must be an iterative process, requiring ongoing commitment and action from the project team. Without such persistence, project risk exposure will get out of control, the project risk process will become ineffective and the project will have increasing difficulty in reaching its goals.

Insights from the new approach of “risk energetics” suggest that there are key points in the risk process where the energy dedicated by the project team to managing risk can decay or be dampened.

A range of internal and external critical success factors (CSFs) can be deployed to raise and maintain energy levels within the risk process, seeking to promote positive energy and counter energy losses.

Internal CSFs within the control of the project include good risk process design, expert facilitation, and the availability of the required risk resources.

Equally important are external CSFs beyond the project, such as the availability of appropriate infrastructure, a supportive risk-aware organisational culture, and visible senior management support.

So, perhaps there is still something new to be said about managing risk in projects.

Despite our long history in attempting to foresee the future of our projects and address risk proactively, we may do better by extending our concept of risk, addressing weak spots in the risk process, dealing with risk attitudes of both individuals and groups, and taking steps to maintain energy levels for risk management throughout the project.

These simple and practical steps offer achievable ways to enhance the effectiveness of project risk management, and may even assist us to change the course of future history.

[Note: All these issues are addressed in the book Managing Risk in Projects by David Hillson, published in August 2009 by Gower (ISBN 978-0-566-08867-4) as part of the Fundamentals in Project Management series.]

Author details:

Known globally as The Risk Doctor, Dr David Hillson is director of Risk Doctor & Partners (www.risk-doctor.com). He is recognised internationally as a leading thinker and expert practitioner in risk management, and he writes and speaks widely on the topic.

David is active in the Project Management Institute (PMI®) and was a founder member of its Risk Management Specific Interest Group. He received the PMI Distinguished Contribution Award for his work in developing risk management over many years.

He is also an Honorary Fellow of the United Kingdom Association for Project Management, and a Fellow of the Institute of Risk Management, the Royal Society for the Encouragement of Arts, Manufactures & Commerce, and the Chartered Management Institute.
Quote this article on your site

To create link towards this article on your website,
copy and paste the text below in your page.




Preview :


Powered by QuoteThis © 2008

Newer news items:
Older news items:

Add comment


Security code
Refresh