This article provides the basics of a Risk Management Toolkit For Project Managers. The task of risk management is to manage a project’s exposure to the probability of specific risks occurring and the potential impact if they did occur. A risk is anything that may or may not occur at some point in the future – and if it should occur, will have an impact on the project in some way. Risk can be defined as “Uncertainty of outcome” A simple definition might be: ” a risk is somthing that might happen at some point in the future, and if it does, it will have a negative impact on your project” Don’t confuse risks with “oportunities” which are the exact opposite. And don’t confuse risks with “issues”. An issue is something which has already happened – and must by definition, be a surprise – otherwise it would have been a risk — right? Risks are many and varied, but the major areas of impact usually include:
- Increased cost
- Time delay
- Poor or reduced quality
- Reduced business benefits
- Changes of scope
Assembling a risk management methodology needs key elements to be put in place:
- a clear structure to the risk process
- all risks must be assessed and managed
- management – typically the Project Board, actively supports and promotes risk management
- the achievement of business benefits is seen as a direct consequence of managing risks
- a consistent approach is communicated, used, and embedded in the project management process
- Risk management is used as a key element in decision-making to start, continue, and close the project.
The whole project risk situation must be used at key project milestones, such as end-of-stage reviews, as a basis for proceding or not.
The cycle of risk management consists of risk identification, analysis of each risk, identifying actions and countermeasures, building these into the project plan, and a continuous cycle of regular risk monitoring, controlling and reporting.
Some people say that by the very definition, a project is a risky undertaking, in that, ALL projects have some risk. So what are the main attributes that may cause risk on a project?
1. Most projects are UNIQUE. If you are running a department or group or service – then it is called Operations. If you create the same things every day – then it’s called Manufacturing. But a project is a one-off. Even if it is similar (“we did one just like this last year…”), it will still have some unique aspects – even if it’s just different people working on it.
2. Many projects have CONSTRAINTS. Anything that has a constraint must have a risk in terms of not meeting that constraint. Constraints might be end date, budget, quality, acceptance criteria, compatibility, size, speed, etc. In fact any attribute that may be assigned to a project (usually in terms of its end-product), is constrained. And that my friends, is the Risk.
3. Poor ESTIMATING. Consider you and your family doing the weekly shopping at your local Pricemart supermarket. How many times do you return home having remembered EVERY item? Not often? Well how about how many times do you return because you bought TOO MANY items? Not often? Okay, so how many times do you realize you didn’t buy enough of an item, or you FORGOT an item? What’s That….Speak Up? MOST TIMES you say!!! So when I say Poor Estimating, I mean welcome to the human race… it’s part of our psyche if you will. So what are we up against? Well when you boss asks you “when can I have it?” you may tend to be optimistic when you say “in 2 days time”. Or perhaps it’s the other side of the coin – you think to yourself “I’ll add another day on – just in case”. It’s known as padding. So why do you do this? – To minimize the risk, even though it’s not the best thing to do. Experience will often tell you that management will ask you to get it done quicker, even when you have given a ‘down to the bone’ estimate – so padding can act as a protection. In summary. Whenever you estimate, and hence set expectations, there is some degree of Risk.
4. The REQUIREMENTS Are Not Fully Understood. This often comes in at least two flavors. The first is “we didn’t know what we didn’t know”, and the second is “start the project with what we’ve got, and we’ll refine it later”. Whatever. It’s a Risk. You can minimize it by working with your client to more fully understand the requirement and to ‘flesh out’ any badly defined areas. In my experience, it’s hardly ever “you didn’t deliver against my requirements”, it’s always “you didn’t fully understand my requirements. So the risk is in the gaps of what was originally stated. It rears it’s full ugly head at the end of your project – just when you’re trying to get client sign-off. “but surely you’re going to include training”, or some-such. I call it “Selective Amnesia”
5. CHANGES. From now until you retire, these little babies will be thrust upon the poor little project manager. And that’s YOU! They may occur because of the previous point – little-understood requirements. Or they occur because of:
- customer changes their mind
- the business environment changes
- someone had a better idea
- we can’t give the customer what they wanted
- there’s been a tax hike
- our fiscal budget has been cut
- someone just stole my resource
- In fact just about ANYTHING!
The secret is to set up a system to manage change at the start of the project and get everyone to agree it. Potential changes are Risks – and the best we can do is to minimize the impact or probability of ‘em happening! So they are the major risk areas, what are the major SITUATIONS that point toward Risks on a project? Here’s my take on a low risk example….(but the list is not exhaustive):
- Are you (or a Third Parties’) a full time and experienced project manager? And by that I also mean experienced with this particular ‘type’ of project.
- Does the project team have the right experience and skill mix AND are they full time on the project, AND they are fully available?
- Are the Customers/Users fully committed and involved in the development?
- Is staff turnover (or re-assignment), low?
- The end-product has no significantly unique features AND/OR the scope of the project is similar to previous projects?
- The requirements are well understood, agreed, and not complex?
- Plans and estimates are based on reliable data, in particular, is the schedule realistic?
- We use a standard methodology for our projects?
- We practice “management by exception”
- Suppliers (internal and external) are known and have a good track record?
- When appropriate, are contracts in place with acceptable Terms and Conditions
- Does management allow you to set realistic targets?
- Is collaboration and communication complex?
Final Thoughts. When I was a young boy, my Mom always took good care of me, and ensured I wouldn’t get in harms way. But as I grew up, I took a more mature approach – because life is meant to be lived, and it’s full of risks. The smart way was to go through life one step at a time, consider the risks, determine those that were acceptable – then proceed with care, and those which were unacceptable (do something to make the risk acceptable – or do something else). I don’t think projects are any different – it’s just that there are more stakeholders!