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:

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.

When caught by a fire or other urgent situations it is useful to have emergency equipment on hand and know how to use it.  The same goes for Project Exception Processes, if something untoward happens then that is not the best time to be creating new processes to deal with the event and explaining how to use them. Emotions are high, people respond to bad news differently, and it is better to practice an agreed to procedure than figure out new rules.

Project tolerances and exception plans provide an agreed to emergency plan for when bad stuff happens to good projects. They act as guardrails to help prevent us going off track and provide a mutually understood and agreed to resolution process. So, just as during an emergency is not the best time to collaborate on improvising a rope ladder, nor is during a major project scope change the best time to define a resolution process between project stakeholders.

We will look at the two components (Tolerances and Exception Plans) individually and then examine how they work together. Project tolerances are the guardrails, the upper and lower boundaries the project stakeholders are willing to tolerate for a given project metric. Another way to think of it is how much slack rope we have as a project team to do our own thing (or hang our selves with). Tolerances can be set on a variety of metrics and the degree of variation will depend upon the individual risk tolerances of the collective stakeholders. Some projects might be very time critical, others more concerned with budget, or user satisfaction.

Last night I gave a talk on “Agile Project Leadership” at the Calgary Agile Methods User Group (CAMUG). I like giving these because the questions raised make me re-examine elements of leadership and last night was no exception.

One question raised was basically “We hear about these ideas and they sound good, but in our projects the same old stuff keeps happening. How do we get real results?” I responded with some explanation about encouraging servant leadership, but in retrospect I think the underlying question was more about making the switch to authentic leadership rather than shallow imitations that bring poor results.

Some subsequent discussions with a couple of attendees have helped me straighten out my thoughts on the issue further. “Cargo cults” is the term used to explain the phenomenon of blindly replicating outward behaviour with the hope that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the war time aircraft runways, control towers, and radios out of wood in the belief that they would bring back the cargo planes that brought Western goods during the war.

The equivalent cargo cult leadership pattern would be to practice techniques like team recognition in the hope that it improves morale and productivity without understanding the work undertaken, or by presenting phony “well done’s” and insincere praise. People have excellent BS radars and phony praise is quickly recognized as attempts at manipulation and has the opposite effect as desired. Likewise mechanical-only attempts at creating a common vision, challenging the process, or creating empowered teams will fall short too. These activities require deep conviction or else they will falter and fade, making genuine attempts harder to introduce later as an “antibody effect” of mistrust develops in the team.