« Managing Project Issues
Project Managers Are Rubbish »

Project Risk - Is It All Bad?

January 27, 2010 | Author: PM Hut | Filed under: Risk Management

Project Risk - Is It All Bad?
By Paul Slater

No-one would disagree that managing risk within a project is not a good idea. Risk Management is an essential part of any programme or project and can vastly contribute to successful delivery. Where it can and does go wrong is when there is an over-reliance on the risk aspects of the project and they in themselves start driving the way the project moves forward. The management of risk is part and parcel of project management but is not the be all and end all of it as it sometimes becomes in more risk averse organizational cultures.

To help understand how risk within projects can be better managed it is worth considering a number of aspects of the risk identification and mitigation processes involved.

Appropriate monitoring and mitigation

The most important aspect here is the word ‘appropriate’. For large, complex programmes covering numerous disciplines, say construction, software, and telecommunications and running for a number of years it is entirely appropriate to have a risk set-up that matches that complexity. Matches and is appropriate, a set-up that identifies risks in the disparate areas of the programme and allows judgments to be made across the programme as a whole. There may well be a Risk Manager and team to assist that individual in collating the requisite management information. The difficulties arise however when the scale of programme or project is much reduced but the risk processes of large complex programmes are applied. When this happens, the risk process starts to drive the programme and stops providing a benefit.

Record once not in multiple related projects

Far too often the same risks are identified across multiple related projects or within a programme of projects. Even with sophisticated risk software the potential for confusion is great with different scores being applied to probabilities and impacts. Make sure you identify the one true risk and record it and track it within the correct project. If other projects or a higher level programme need to be aware of it that is fine, make them aware of it but make sure you don’t start double or triple scoring the same risk.

The more risks are recorded, the longer the project will take

Strange but true. The more risks you identify and manage within a project the greater the chance that the project might not come in on time. The reason for this? Well, think about it, it’s very easy to identify lots of risks for any project but it’s how far you go that really matters. Get right down ‘in the weeds’ and you will still have to identify risk owners and people to investigate mitigation strategies etc. etc. All this takes valuable time and effort away from the main job of project delivery itself. So, make sure you have the important risks identified and managed and keep reviewing to ensure your list is up to date.

Accept the risk as is

Once you have identified your set of appropriate risks for your project you need to decide what to do about each and every one of them. Putting in place some form of mitigation may be necessary and add cost to the budget but that’s just the way it is. Having said this there could well be risks that you decide simply to accept as they are because either the probability of them occurring is so low and/or the cost of putting in place some mitigation is so high. You aren’t ignoring the risk you are making a conscious decision to accept that it may happen.

Opportunities arise

Risks happen in any project and some may have been predicted and planned for while others may not have been. The project is the project with its set requirements, that’s what everyone accepts as the truth. But what if a risk occurs which starts to make you think seriously about the validity of the project or the direction in which it’s going? When reviewing the project risks and looking at those that have occurred ask yourself the question “Does this project still need to go in this direction or should we consider altering it?” Of course, the ultimate might mean cancelling the project altogether, never an easy decision for anyone.

So, are all risks bad? Of course not. Make sure you are managing the risks that are appropriate to the project and make related programmes and projects aware of them and you are most of the way there. Opportunities can be anywhere within a project space but just remember to think about them as you go through the risks – it starts to make that risk review meeting far more meaningful.

Paul Slater owns Mushcado Consulting and is based in Gloucestershire, United Kingdom. He offers consulting services to private and public sector businesses and specialise in facilitating change, reviewing projects and delivering training that really makes a difference.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Wednesday, January 27th, 2010 and is filed under Risk Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 people have left comments

Paul your article is very helpful. My experience suggests one of the primary reasons for these continued poor results is the lack of formal, aggressive IT project complexity and risk assessment and management – a responsibility of the IT project sponsor and project manager.

Software development is a process – a process with varying degrees of complexity. A process’s complexity, therefore, defines, qualitatively and quantitatively, the relative difficulty, time consumption, resource requirements and skill requirements necessary to successfully complete. The more complex the process – the more difficult, time consuming, resources intensive and more experienced skills are required. Many project managers use complexity and risk synonymously – but they are not. Project risks are qualitative and quantitative issues or events which could lead to negative consequences. Risks can be prevented, repaired if they become an issue or mitigated. Complexity is not an event and is harder or impossible to prevent, repair or mitigate once the IT project begins.

So why do most IT sponsors and project managers do a lousy job of complexity and risk assessment and management? A few reasons are:

1.Lack of skills – training and/or experience
2.Internal politics
3.Lack of formal assessment and management process that is consistent and repeatable
4.Lack of assessment, management and reporting tools
5.Lack of emphasis in CMM, ITIL and other methodologies

Project risks are not necessarly to be avoided, but they do need to be managed.

Ross Holman wrote on January 29, 2010 - 2:36 pm | Visit Link

Ross,

Thanks you for your kind words on my article - I’m so sorry it’s taken me this long to respond.

I find project complexity an issue that is poorly understood by many people and not just those in the IT field. Projects that encompass a number of different disciplines which have to come together to deliver overall success are particularly difficult, even more so when there are differing ‘themes’ of project management at play in the different areas. This is when the experience of the project manager and their team really comes into play.

Paul

Paul Slater wrote on May 27, 2010 - 7:14 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories