Does Risk Management have a place in an Agile Lifecycle webinar

Today I listened to the PMI Agile CoP webinar called Does Risk Management have a place in an Agile Lifecycle.

 They introduced agile risk management as an alternative to "traditional" risk management.  They reviewed the "traditional" approach and then the Agile approach. 

Traditional approach:

• Identify the risks
• Estimate the Impact
• Estimate the likelihood
• Calculate the risk rating = impact * likelihood
• Categorize
• Decide on how to react to the risk
• Done once in a project.  Really?  Look at their slide 17 for more pearls like this one.

The Agile approach:

• Same beginning.
• Do life risk management throughout the project.  Now that is new!
• Be collaborative. Newer!!
• Involve the client.  Newest!!!

The lady presenter backtracked a little when she said that there is bad and good "traditional" but then continued without saying there can be good and bad Agile too.  Is Agile perfect?  There are no crappy Agile risk management.  I say BS.

The guy presenter go to taking about percent complete and risk.  Agile is a binary thing; done or not.  None of that 99% done and the 1% takes forever.  Who works like that in "traditional" project management and gets results?  I do % complete on a macro level; for example, my project is 53% done, at 50% of its budget.  Clients love that while they usually don't care about individual tasks (nor should they).

The guy presenter then goes on to say that you should do "traditional" risk management when there are big upfront risks because the project is very innovative, experimental, or you're out of your comfort zone.  I don't know, but I don't start a project for making chocolate chip cookies.  My clients do not hire me to do what they could do themselves with their eyes closed and their hands tied behind their backs.

I'm an old ape.  When someone states the obvious and what a good project manager would do on projects and tells me its new, I think they think I am a fool.  Maybe I should rename this blog "The Agile Hard-nosed Project Manager".  Same old, same old but it would appear to be new and shiny.  As a plus I'd get to make even more borderline pronouncements...

Good thing that the webinar format used did not allow live interactions.  There would have been a hell of a shouting match I think.  The webinar finished 7 minutes early.  Thank God!

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network.

Comments

[Shim Marom]

Hi Pat, sounds like a serious waste of time and I can't imagine how the PMI have allowed for such silliness to be presented under their banner.

This is not the first time (and unlikely to be the last) where Agile is taking the credit for methods and processes that have been in place for years - long before the Manifesto became into existence. I come across such comments in the workforce and usually, though not always, made by people who have no other experience accept for Agile.

So it is about time we draw the battle lines and call things using their true name:

1. Agile is NOT a project management 'thing'.
2. Even in Agile, normal project management practices need to apply - and to be successful they certainly do get applied.
3. Being arrogant does not make you right.

End of rant...

[Patrick Richard]

Hey Shim,

I think it is a waste of time if someone is trying to find Agile content. However, if you manage to mentally block every mention of the word Agile, it makes for a pretty good 50,000 feet look at risk management.

It is interesting indeed that Agile practitioners fail to recognize that they are rebranding something that already exists, typically that happens out of lack of experience although the lady presenter claimed 25 years of experience (her blog claims 20+). She should know better.

What is very sad is that camps have formed almost like religions. That is not good because people become entrenched in their particular belief system and stop innovating. For example the waterfall approach implemented rigidly for a whole project does not make sense. Whether you replace the immovable schedule by iterations or scrums does not matter, it going to work better because it is more flexible.

I agree with your points 1 and 2 and especially about number 3. Arrogance does not make you right and that is even more true when it is “youthful” arrogance.