« When Does It Make Sense To Create A Project Management Office?
PMI Project Life Cycle (PLC) - Introduction »

Agile Risk Management

September 29, 2008 | Author: PM Hut | Filed under: Agile Project Management, Risk Management

Agile Risk Management
By Mike Griffiths

Risk Management processes may have the air of a traditional, process-driven project management activity. However, agile methods are great risk reduction vehicles, and are actually very well aligned for rapid risk identification and reduction.

What is a Risk?

A risk is some event or circumstance that could transpire and impact the project. The PMBOK talks about good risks (opportunities), but most risk literature focuses on events with potential for negative impacts (project risks).

The risk management process outlined in the PMBOK is shown below:

Risk Management Process

Risk Management Process

Where’s the “Risk Response Doing” Step?

One step absent from this process is a “Risk Response Doing” step that focuses on executing the actions identified in the risk mitigation plan. In the defense of the PMBOK, these activities get moved to the project plan and scheduled with the regular work activities.

However the apparent lack of a doing step mirrors a problem seen on many projects. Namely, that risk management is undertaken as a separate (sometimes once only) passive activity that does not drive enough action on the project to prevent the risk happening. As a result we see risks occurring and can point to the risk list to where it was identified, yet not enough was done to prevent it happening.

Agile Risk Reduction

The iterative nature of agile projects allow us to tackle high risk areas of the project sooner rather than later. This gets problems out in the open while there is still plenty of time and budget to work on them and reduces the effort invested in work that needs scrapping.

Risk Tasks in Iteration

Risk Tasks in an Iteration

Agile projects are said to be business value and risk driven. This means that we choose practical bundles of work based on priority assigned by the business and tackling the remaining high risk items left in the prioritized feature list (Product Backlog). So if we have stories with residual risk we would want to move that up the queue and undertake it as soon as possible.

Making this balance tradeoff between business value and risk mitigation value requires some smart planning ahead. Both can be attributed a dollar value for objective comparison, but most project teams perform a subjective comparison based on discussions and trade-offs.

Agile Risk Management Steps

The process for finding, sifting, sorting and creating resolution plans for risks on agile projects remains close to those of traditional projects. The traditional steps of assigning Probability and Impact scores to risks and then calculating Severity as their product should still be undertaken. However, while the basic mechanics are the same, how the process integrates into the lifecycle and the frequency of running the process varies considerably.

Agile Risk Management Process

Agile Risk Management Process

Repeat Every Iteration

The risk management process is repeated every iteration. As part of the iteration retrospective the remaining risks can be reviewed and the probabilities and impacts validated. The team can be asked to identify new risks and remaining features that still carry risk identified for selection in the next iteration.

Listen for Potential Risks at the Stand-Up
Daily stand-up meeting are an excellent source for potential risks identification. Today’s issues and blockers could become tomorrow’s risks and problems for the project. So it is important to pay attention to the issues being raised and transfer any appropriate issues to the risk list and undertake the necessary risk assessment steps.

Agile Risk Management Strategies

Actively attack the risks before they can impact the project. – Look for remaining risks and find ways to mitigate them in the next iteration. Think beyond just technical risks and consider the business and HR based risks too. For instance: “Not sure if the sponsor is committed to the project? Try ordering that expensive kit you need and see if they approve it” Or “Not sure if the DBA group is on board with working with an agile team? Then move up your database work and try some, see if there really are problems.” Be careful; use your common sense, but look beyond just technical risks.

Maintain a risk burn down graph – Track progress on risk reduction via a risk burn down graph. These useful graphs summarize the risk profile for the entire project and can be used to illustrate new and escalating risks. They are also useful for showing the progress made in early iterations where more work was done on architectural risk reduction rather than purely delivering business functionality.

Risk Profile Graph

Risk Profile Graph

Conclusion

Agile methods are adaptive; they have checkpoints and review questions hard-wired into their processes to allow us change the project approach to fit our evolving environment. We can also use these checkpoints to manage and reduce project risk. With an awareness of the risks as we continually re-plan the project we can adapt the plan to also incorporate risk reduction activities.

Mike Griffiths is an independent consultant specializing in effective project management. Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum, FDD, XP, DSDM) for the last 13 years. He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN). He maintains a leadership and agile project management blog at http://www.LeadingAnswers.com

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

Related Articles

This entry was posted on Monday, September 29th, 2008 and is filed under Agile Project Management, 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.

1 person has left a comment

Your view the PMBOK risk management processes don’t include the treatment of risk could not be more wrong! What the PMBOK dose not assume is a bunch of people sitting a meeting doing ‘risk management’ can change the project.

The outputs from ‘Plan Risk Responses’ (PMBOK® Guide 4th Edition) are updates to the project procurement process to deal with any contract related changes to manage risk and updates to virtually every section of the project management plan to change the future shape of the project to minimise threats and maximise opportunities.

Having a bright idea in a risk management meeting to do something is of absolutely no value unless the idea is translated in to action via the project plans and become budget line items and schedule tasks for people to perform.

Similarly your view that PMBOK risk management is a ‘one off’ is completely wrong. Risk management is an iterative process in the PMBOK as much as in your Agile scenario above.

Patrick Weaver wrote on March 7, 2009 - 6:01 pm | 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