Agile Risk Management

Danger Today’s evaluation of one of our projects was a tough one. It seemed like nothing had gone right. The customer had signed the contract far too late, which meant that resource management had to switch to another (inexperienced) team, because the original team was already booked for other projects; the platform to be used turned out to be much older than anticipated; the customer singlehandedly decided on a live release date, and forgot to inform anybody else on the team about it; half of the requirements turned out never to have reached the proper team members, due to some stupidly bad communication; and beta testing was a nightmare because the customer hired a third-party service organization, and the development team was not allowed access to the beta testing environment.


Needless to say, the first release of the project was bad. Really bad.


Could we have prevented our problems?
Of course!


Do the agile methods have anything to say about such problems?
(In our case) nothing useful!


Can we solve these problems by adding more processes?
Absolutely not!



Sometimes, unexpectedly, you have to work with a bad environment as it is handed to you. You can jump high and low, you can cry, you can shout, and you can kick the customer in the groin (I often do all of that, just to let off some steam), but it’s not going to change anything. You will simply have to work with what you got.


Processes (including best practices promoted by agile methods) can only deal with known environments. (In fact, agile methods usually define their boundary conditions, like “customer on site” and “colocated team members”.) But if you don’t know the environment for a process, then you cannot define the process! That’s why software development methods always tell you to A) change the environment to better fit the process; or B) change the process to better fit the environment. However, every problem we faced in our little-project-from-hell had its origin in unforeseen circumstances.


Standard processes, by definition, cannot deal with unforeseen circumstances.
Only intelligent people can.


That’s where the concept of Risk Management comes in. Risk Management is part of Prince2, part of PMBOK, and part of the CMMI, but you don’t often see it addressed explicitly in books on agile methods. I think that’s strange, because Risk Management is nothing more than a simple approach of managing potential problems that are not addressed by the standard processes, and that usually find their roots in unforeseen circumstances. Risk Management is a 100% human activity concerning problem-solving. It is self-organization on the supra-project level.


So, how do we implement Agile Risk Management?


Easy! Make somebody directly responsible for keeping track of projects, their deviations from their expected courses and environments, and any measures to be taken to avert uncommon pitfalls. Prince2, PMBOK and CMMI tell you that this is the project manager’s job. But in practice the project manager has often dug himself so deep into the project that he is unable take a “10,000 feet view” of the environment he’s working in. That’s why Risk Management is often forgotten. Project managers cannot do it themselves!


Do we rely on the bus driver to watch out for the thunderstorm?


I think most bus drivers already have enough on their mind simply to deliver their customers to the next stop. Likewise, project managers need to keep their eyes on the road. And they need other people and mechanisms to tell them that they might be approaching danger.


Well, these are just my thoughts. I think our industry needs to flesh this out some more…

3 thoughts on “Agile Risk Management”

  1. Two things in your blog caught my attention.

    The first was the way the customer was very irresponsible and blind-sided you with some big problems. I wouldn’t call these problems unforseen. The customer saw them. They didn’t care about the problems they caused for you.

    The second problem with your scenario is that your project manager was working at too low of a level. I wonder if he/she was micro-managing.

    What is missing in your scenario is managing the customer and the customer’s expectations. Perhaps it is customer management, rather than risk management, that you need most.

  2. Dean, I think you have a point. However, depending on the type of organization, customer management is not always within the span of control of the project manager. For example, many project manager only come into play after a project has been signed. They haven’t been part of the initiation phase, because the resources were still not known at the time.

    Also, I think customer management is just one part of the problem. It’s also organizational management, and portfolio/program management. Likewise, these are usually outside the boundaries of many project managers. Therefore I think risk management (which comprises risks on all levels) might have to be addressed by someone else.

  3. Maybe the adoption of Risk Management by Agile Projects can indicate a kind of “upfront planning”. But, in the other hand, a well-developed Risk Plan can avoid most of the problems that you described. I think that one have to decide the best approach for each project, but i prefer to be prepared for deal with problems before they happens.

Leave a Reply

Your email address will not be published. Required fields are marked *