It’s All About Changing Behaviors

When first approached to contribute a newsletter article on risk in projects (and in general), I was both flattered and enthused.  Subsequent reflection did nothing to decrease the feeling of flattery, but my enthusiasm was damped by the sheer preponderance of messages to be delivered.  

It was clear that anything resembling a credible job could only be done through a series of articles.  So, here's the first one which will focus on behavioral change.  Some of you might be looking for the conveyance of risk-related technical practices in these notes.  You won't be disappointed - such techniques will be addressed in future articles.

Where to begin?  Given that I will be discussing the many facets of risk, it seemed prudent to first define the term - "risk," that is.

In business, if you ask N people for their definition of risk, you likely will get N unique responses.  Within any corporation, each discipline views risk through a colloquial lens.  For example, the Health & Safety department typically will define risks as threats to be rooted out and eradicated.  Denizens of the Finance department, however, view risk as a positive thing.  They seek and embrace risk (hopefully, not more than they can handle) because their job is to maximize return - low risk, low return; higher risk, higher reward.  To them risk is an opportunity.

So, the definition that I propose for "risk" is:
    A pertinent event for which there is a textual description

The "pertinent" term indicates that a risk is something that has a material impact - either positive or negative - on, for example, project value.  Therefore, I refer to risks as either threats or opportunities.  A risk is an event. That is, it is something that might happen.  This event can be textually described (you can tell someone what it is).

Associated with each risk are at least two other parameters:  probability and consequence (or impact).  About both probability and consequence, we can be sure or uncertain.  To learn more about this, I refer you to the books listed at the end of this article.

After many years in the academic, government, and corporate arenas - and even in spite of my 20-some-odd years of research experience - I have come to realize that implementation of practical, relevant, and effective risk-assessment/risk-management (RA/RM) practices is not mainly about new technologies etc. - it is primarily about changing behaviors.  Changing behaviors, in turn, is mainly dependent on the reward system.

Well, with regard to implementing RA/RM practices in project teams, just what are we (those of us who promote these things) proposing project teams do?  A basic set of recommended processes would include:

  • Hold a facilitated early-in-the-project risk-identification event.
  • Record risks and other information in a risk register.
  • Regularly review existing risks and identify new risks.
  • Take a holistic approach - that is, risks identified should include those from health & safety, security, medical, legal, logistic, engineering, scientific, country, financial, commercial, and other areas.
  • Record in the risk register mitigation-of-threat/capture-of-opportunities actions. The term "mitigation" in this context no longer relates to "firefighting" (what to do if the risk occurs) but, rather, refers to actions to be taken early with the aim of preventing the threat from ever materializing, or, to attempt to ensure capture of the opportunity.
  • Assign a risk-process proponent (a person) who will shepherd the RA/RM processes throughout the life of the project.


So, if you were a project team leader, why would you want to do this?  Given the typical reward system, you are rewarded for successfully launching a project, but not necessarily for launching a successful project.  In addition, you are in competition with other project leaders for monetary and human resources.  Why would you want to identify most of the risks for your project (shine a bright light on your project's warts) when the other guy is not doing this?  

In addition, what could compel you to spend money now to mitigate a threat, for example, (and remember, "mitigate" means taking steps to prevent the threat from materializing) that might or might not happen?  Even though later "fixing" the impact of the risk will undoubtedly cost more money than the preventative-action will cost now, why should you not just take the chance that the risk will not happen?  After all, you get rewarded for saving money and you likely will have moved on by the time the risk might materialize.

So, as the risk-process proponent, what argument/proof would you offer to cause a project team to WANT to implement this process?  After all, in the past you have had project-team leaders wag their fingers in your face and say: "Had you not chased me around with all this risk stuff, I would have been in a better place faster and cheaper - all you did was waste my time, money, and effort!"  And, by the way, "Well, oh yeah?" is not an appropriate response.  On projects that take years to go from inception to fruition, what case can you make that might convince any project team that implementation of a cogent RA/RM process is well worth their while?  In spite of the existing reward system, what can you do or say that will change their behaviors?

Risk Note #2 - Some first steps to take to begin to change behaviors.

By:  Glenn R. Koller

References:
Koller, G.R., Modern Corporate Risk Management - A Blueprint for Positive Change and Effectiveness, J. Ross Publishing, Ft. Lauderdale, FL, 2007.

Koller, G. R., Risk Assessment and Decision Making in Business and Industry, A Practical Guide:  2nd Edition, Chapman & Hall/CRC Press, Boca Raton, FL, 2005.

Koller, G. R., Risk Modeling for Determining Value and Decision Making, Chapman & Hall/CRC Press, Boca Raton, FL, 2000.

Comments

There are no comments for this entry yet.

Commenting is not available in this section entry.
Member Login