I always looked at risk management activities using the event-driven risk approach offered by the current project management traditions.Perhaps because of this, I've never paid so much attention on this topic before, as I am doing now. 

Flying back to Brazil from the conference in Miami, I had the opportunity to read the amazing piece of text that David Anderson wrote about Risk Management on the proceeding book of the conference. After that, I've started to think about risks in a different dimension. Now, I’m diving on this conclusion:

Mutual Trust Relationships can be sustained by intrinsic risk management mechanisms.

There is definitely something more in dealing with risks than just trying to create mitigation and contingency plans up-front.  

To be relevant, risk management has to be merged into the system to orchestrate his behavior.

I have this feeling today that any decision point in a process should be oriented by some risk analysis approach. I’m not talking about a plan for risk mitigation here; I’m talking about a process for continuous risk mitigation. Is that possible?

In David's article, he describes a technique that uses Classes of Service (CoS) as an instrument to make the system works oriented to risk decisions according Cost of Delay. So, before you inject new work into the system you are conditioned to think about risks, once you have to classify each work item by doing an analysis of the associated Cost of Delay. The type of risk is going to influence behavior by the application of different contextual policies. Pure System Thinking!

Labeling work items is a interesting mechanism to influence system behavior. If you use an e-mail system like Gmail you can see that in practice. When you decide to tag messages by some form of classification, you define a visual agreement mechanism that is able to influence your behavior. You are going to act differently when you see a message with a special tag type. 

What David is proposing is labeling work items by risk criteria, which is going to subordinate the system to be risk-oriented, a fundamental part of self-sustainable processes. So that's why David's article got my attention in the conference book. Explicit Risk Management is missing in our process. We have to figure it out how to apply this knowledge on it.

In our process, we have a different use for Classes of Services.

Instead of thinking about the risk, we are thinking about Value mapped to agreements that we need to respect as we interact with our customers. 

We talk to them in these terms:

“You (the customer) should trust us (the vendor) as we will try very hard to keep your business up and running by solving any problem (1) that you have or by helping you in any operation (2) that you need assistance from us; we also are going to sustain your processes by doing improvements and adaptations (3) as your business evolve and, while we do that, we are constantly trying to deliver new features and capabilities in our software to create new business opportunities (4) that generates value for you in your market share.” 

This “Agreement Statement” maps to our Classes of Services (CoS):

1 - Problem solving
2 - Support and Operations
3 - Improvements for sustainability
4 - New Value

The intention of our "Agreement Statement" is to create a Mutual Trust Relationship with them by being flexible with their needs and getting flexibility from them for our needs (which are mainly estimation, prioritization, error tolerance, and others). So, all units of work derived from this CoS have Value for the customer. But the lack of any of this agreement can make the long term relationship that we aim becomes unstable.

We need to create balance by delivering units of work observing the system against this "Agreement Statement". During this observation we have to consider each individual customer and the whole system to make right decisions.

We have an assumption here which is based on the fact that we have different entities of our system competing by the same (and limited) resource. So they have to trust us that we are going to take the best decision considering this "invisible" competition that is happening in background. This decision process is all about "risk analysis.” 

So, Risk Management is an important activity to create effectiveness on this decision process. An effective decision process creates trust, and high levels of efficiency on risk control leads to high levels of trust on this relationship.

Using CoS as David suggests seems to be a quite reasonable approach, once CoS is the primary way to classify units of work in Kanban Systems. But, I’ve realized an underlying model for managing risks here, which are leading us to the definition of a new orthogonal ax in our system for risk-oriented work items classification and also for risk-oriented policies. Merging risk analysis into our system to influence its behaviors is going to be my next challenge for now.

 


Posted by: alisson.vale
Posted on: 5/12/2009 at 4:58 PM
Tags: , ,
Categories: Management
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (2) | Post RSSRSS comment feed
 
 

Comments (2) -

Rob Hathaway United Kingdom

Monday, May 18, 2009 2:10 AM

Rob Hathaway

Hi Alisson,

Could you ever forsee a time where you prioritise a story/mmf from your #4 CoS (New Value) higher than something on your #1 CoS?

My worry with these CoS is they become a fixed rule for the team and emerging opportunies that could yield an overall higher value for the company than even solving an existing high priority problem might be missed.

It may well be that you're only using CoS as a guide but my reading of the article is that its something more rigid. I'm really interested in this topic because all of the Kanban teams I've coached over the last 9 months don't have explicit CoS and instead have these discussions within a more flexible framework. Interested to see how this scheme is working out for you.

Rob

alisson.vale Brazil

Monday, May 18, 2009 1:40 PM

alisson.vale

Hi Rob,

It´s great to have you here ;)

> Could you ever forsee a time where you prioritise a story/mmf from your #4 CoS (New Value) higher than something on your #1 CoS?

It happens but not because there is some kind of policy or rule for prioritisation between CoS. In fact, we don't use CoS as a prioritisation element in our process. We use other types of information to define priority. CoS is usually not one of them. For us, CoS just keep our eyes looking at the relationship between value and waste (in terms of value and failure demand).

This sentence on my post is key to understand our reason on doing this: "We have an assumption here which is based on the fact that we have different entities of our system competing by the same (and limited) resource."

What we try to do is keep the system sustaining a pre-defined level of capacity for each CoS. So, we try to regulate system capacity by CoS using current business conditions. Today this regulation is defined by a leadership rule, but I´m pretty sure that the creation of a self-regulated system on this concern is possible.

CoS is rigid for us, because it classifies the demand in a higher level and because it points to failure demand levels. But prioritisation is very flexible and contextual.  

Alisson

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading