Risks found in Shallow Thinking, when Waters are Deep !

Oil-Rig-New-200x300

What a delicate subject to broach. I will be an objective observer and not assign any blame on the gulf spill until the details are available, but I would like to use this tragedy to discuss how it relates to project risk planning.  I am guessing that something was overlooked during the formal risk planning process related to the Deepwater Horizon oil rig drilling into the Gulf of Mexico.

I have been using agile project management methods for 10 years and have attended numerous agile training courses and conferences.  In all of my training and experiences I have never heard anyone discuss formal risk planning as it relates to an agile process.

If you take agile training you will hear folks like me say “agile is continuous risk management”.  This is a true statement.  We take risk out of the requirements by working face to face with the customer.  We take risk out of the build by continuously integrating the code.  We take out the risk of delivering buggy code, or code that goes beyond the need, by using Test Driven Development.  So if we are performing all of these practices do we really need to do any upfront work related to formal risk analysis and planning?  The answer is yes, sometimes it still makes a lot of sense to do formal risk planning.

If you are not familiar with formal risk planning, let me provide a high level synopsis.

First we sit down as a team – executives, managers, business folks, and technology folks.  We discuss everything that could go wrong with the project and create a list of potential risks.  Once the list is complete we talk about the impact if the risk materializes.  In figure 1 you can see an example of a risk assessment.  In this example we note that Risk ID # B1, “incomplete migration”, only scores a 1 on the impact scale, meaning if the risk materializes the impact will be minimal.

Risk Assessment 4

Figure 1

Continuing with our example, Risk ID # B5, “Insufficient resources”, is scored as a 5 on the impact scale, meaning if it happens we are in big trouble.  We probably will not be able to deliver any project value if this risk materializes.
Once the team identifies the impact of a risk, they move to the probability of the risk occurring.  If we stick with our previous two examples, Risk ID # B1 has a .25 (25%) chance of occurring.  Risk ID # B5 has a .75 (75%) chance of occurring.  Since B1 is low risk and low impact, we are going to accept it and not do any contingency planning.

Since B5 is high impact and high probability, we need to lay out our plan for managing this risk throughout the project.

As I mentioned at the start, this exercise makes sense on some agile projects.  I cannot provide specific criteria for you to use, but I can tell you what encourages me to do this exercise at the start of a project:

1) When I am working on a project with high dependency on groups outside of the project team.

2) When a sponsor or business owner has a history of delaying or cancelling projects due to disregard of project risks.

3) When the technical team sees numerous business risks that the business customer cannot see or envision.

4) When I am working on a CYA project.  Agile is all about collaboration and shared ownership, but on occasion you may find yourself managing a project where you need to CYA due to the political environment.

5) Projects with a long period of time for iteration zero work (iteration zero is work needed to establish a foundation before coding begins, such as ordering and installing servers, working through contracts with vendors, and obtaining help from teams outside of your control). In my experience this would be a project with an iteration zero longer than 3 weeks.

6) When the customer wants to.  If your customer enjoys this exercise and it makes them more comfortable on understanding the project risks, do it.

7) When an internal project management governance group requires this process.

8) Whenever you are using technology that has never been used by the team before.

Use your knowledge and experience as a project manager to help the team determine when this exercise provides value.

Lastly, when you do use formal risk planning do not consider it a one-time event.  Find a regular day and time to update the risks and manage them throughout the project.

.Article provided to The Agilista PM by Greg Smith, GS Solutions Group.   Please contact Greg if you would like a copy of his risk assessment template:  greg@gssolutionsgroup.com

* * * * * * * * * * * *

Like what you read? Get hot news on the Agile-Lean community, upcoming webinars, case studies and tools you can use to help you be as Agile-Lean as possible….delivered right to your inbox weekly. No spam or junk mail. You can unsubscribe at any time.

Name
Email

..

Share

.......................