12 Principles of Risk Management (PMBOK – with an Agile slant)
The Project Management Body of Knowledge (“PMBOK”) describes 12 Principles of Risk Management. I’ve taken the headings and summarised the main messages from an Agile perspective.
1 ) Organisational Context
There’s no ‘one-size-fits-all’ when it comes to Risk Management. Each organisation will be affected by different Political, Economic, Societal, Technological, Legal and Environmental factors (“PESTLE“).
It’s also worth pointing out (the obvious) that each organisation will have different internal cultures, communication channels, levels of agile-adoption and existing risk management processes.
2 ) Stakeholder Involvement
Involve your stakeholders wherever possible. Keep them informed and understand the role they can/could play at each stage in the Risk Management process > Identify, Assess, Respond, Review.
3 ) Organisational Objectives
When assessing and responding to a risk, be sure to keep the overal organisational objectives in mind – see the bigger picture.
When considering a Task-level risk, look at the role it plays towards delivering a User Story. If you’re concerned about a User Story, consider the impact it has on delivering your Sprint Objective or the relevant Epic. If you’re concerned about a particular Epic, then look at the relevant Theme or the Programme of works.
Keep things in perspective and don’t lose sight of your end-goal.
4 ) Management of Risk Approach (N/A)
This particular principle is less applicable as it refers specifically to the PMBOK Risk Management processes, however the message basically stresses the importance of following best practice guidelines and learning from the mistakes of others.
5 ) Reporting
Keep people informed – ensure transparency and visibility. Communication is key!
6 ) Roles & Responsibilities
Make sure that everyone understands the role they play at each stage of the Risk Management Life cycle i.e. > Identify, Assess, Respond, Review. Ensure that all bases are covered by someone.
7 ) Support Structure
Ensure that everyone understands how risk is managed through the Risk Management Life cycle and who to go to if they have any questions.
For example:
- How are risks identified (e.g. via Daily Scrum)
- How and when are risks escalated?
- Where and in what format are risks documented?
- How and when are risks reviewed (e.g. Retrospective)
- etc.
8 ) Early Warning Indicators
Give yourself the best chance of forecasting/anticipating the transition of a Risk to an active Issue. Ensure that everyone is communicating and that any potential issues are highlighted in the Daily Scrum.
It’s also important to know how you should react in the event a risk does or is about to be realised e.g. who needs to know and how will you inform them – in the Daily Scrum also? Or, maybe in the Scrum of Scrums? Or, maybe you’ll just walk over and tell them.
9 ) Review Cycle
Make sure that your Risk Board is visible and that you’re regularly reviewing it – you could do this via the Retrospective and as an extension to the Daily Scrum by adding a 4th question:
- What did you do since the last sprint?
- What will do you today?
- Is there anything blocking you at the moment?
- Any changes to the risk board?
10 ) Overcoming Barriers to the Management of Risk
Ensure you’re doing everything you can to give you the best chance of successfully assessing the risk and responding to the risk.
Some common barriers include:
- Established roles, responsibilities, accountability and ownership.
- An appropriate budget for embedding approach and carrying out activities.
- Adequate and accessible training, tools and techniques.
- Risk management orientation, induction and training processes.
- Irregular assessment of Management of Risk approach (including all of the above issues).
11 ) Supportive Culture
Make sure that everyone on the team feels comfortable raising, discussing and managing risks.
12 ) Continual Improvement
Use the Retrospective to review the way you manage risk and to assess ongoing risks. Learn from your mistakes.
Read more about Risks and Issues
Subscribe to the to be notified when I upload new Articles, Videos, Templates and Tips!
I actually was able in my SDLC processes to marry the Waterfall with Scrum and Agile and it is working ...
I experienced that using story points based on complexity has brought the team disagreement in assigning points. We still ...
Hi, in addition to your article, you can view this list as well on my website in a more clear ...
Good article, and I STRONGLY ENCOURAGE everyone to read Andy Bruce's earlier response. Andy has nailed the often missed point ...
You have completely demonstrated the whole scheme of software development within the above diagram on such a fine way. Truly ...
What an interesting idea! I’m learning all about PMBOK and I have to say that, IMHO, Risk Mgmt with PM (with all that implies) really doesn’t fit the PMBOK model.
Not that I’m dissing Agile (I work in a true PMO environment and the amount of time spent on artifact management is staggering). Both Waterfall (and, let me just say it, PMBOK is Waterfall as a deluge) and Agile want to do the right things: deliver a quality product. Risk management is key to both: Waterfall by careful planning and eliminating surprise, Agile by realizing that for SW dev in particular you really “don’t know what you don’t know” so you have *trust* and work *closely* with your sponsor.
It’s just that PMBOK and Agile define “Quality” fundamentally differently: PMBOK says “conformance to requirements” and Agile says “meets users real needs” (especially where those needs aren’t known, hence “we welcome change” in Agile which is *absolutely not* the approach and methodology under PMBOK).
Waterfall is great for building roads, not so good for building software.
Agile doesn’t work well in firm-fixed price (read: all Gov’t work) except where you have a lot of trust and little need for auditable documentation artifacts.
good article, articulate and precise enough for starters.
Good article, and I STRONGLY ENCOURAGE everyone to read Andy Bruce’s earlier response. Andy has nailed the often missed point – the PMBOK approach is based on the Waterfall Method; and to me, as important, the Agile Method is best used in Gov’t work where the PMO is “hands off” (that takes a lot of trust in the Development Team) and doesn’t need documentation for long-term support of the software (maintenance, compatibility, training, etc). IMHO, this article is a good “first step” at trying to “bridge the gap” between the Waterfall and Agile methods within the PMBOK Risk Management construct.