I put Project Management 2.0 as the title just to give Glen Alleman a moment…
There was a great question last week in the comments of one of my blog posts. The reader asked if agile offered any unique proposals for managing risk on a project? I’ve been blending my traditional background in project management with agile for several years now and sometimes I have to remind myself of what I’ve taken from what sources.
After reviewing the PMBOK section on Project Risk Management, I had to conclude that Agile doesn’t really offer anything new. Surprised? The PMBOK has processes for developing a risk management plan, identifying risks, performing qualitative and quantitative analysis, conducting risk response planning, and monitoring and controlling risks.
You can clearly make the case the agile might take a lighter approach to risk management, maybe rely less on documentation, but fundamentally you are doing many of the same activities on an agile project as you might on a traditional project. Why are agile methodologies so good then at identifying and mitigating risk?
Agile is so effective at managing risk because risk management processes are built into the very fabric of how we run the project.
There is an implicit understanding that risk is EVERYWHERE on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session. Dealing with risk has to be an obsession. Our mitigation strategies don’t live outside the project, but influence the very nature of how we structure and plan our work.
Many project managers take a boiler plate approach to risk management. They deal with the easy stuff, the obvious risks that could be assigned to almost every project. Are we going to run out of money? Are we going to lose a key contributor? What happens if the project is late? While these are all important, they only represent a small slice of the kinds of risk we need to consider.
As project managers, we tend to assume that the business vision is accurate. We assume that if we deliver to the spec we’ll satisfy the market needs. We gloss over technical uncertainty because the technology guys are responsible for making all the code work. More detailed planning and designs do not mitigate risk. The only thing that really mitigates risk is delivering product.
Agile mitigates risk by building project frameworks that encourage frequent delivery, constant inspection and review, and allow us to adapt when things are not going as you expect.
In short, agile is risk management.