The Road to Success

Well, in almost all of the past articles of this series of 10, I have focused primarily upon the problems, hurdles, and challenges associated with implementing a risk-based process in any organization.  In this 9th article, I will stress 5 steps to success that I deem to be essential.


1 - Make sure they get it!

In article #8, I stressed that the support of upper management for the risk-based effort is absolutely critical.  I will add here, that such support has to be genuine.  I have many times experienced upper management "support" with said management believing that the changes necessitated by embracing a risk-based business process would impact those personnel "down the ladder" and would not make meaningful differences in their everyday responsibilities.  This very-wrong interpretation typically accounts for their quick agreement to support the effort ("Great, as long as it is for everyone else and it does not impact me!).  

I experienced this situation first hand in Egypt years ago (one of many such experiences).  The "Big Manager" on location had called us to Egypt to bring risk-based processes to his exploration/production effort and made, while we were present, great pontifications to the gathered employees regarding just how important it was to embrace the new risk-based process.  Of course, probabilistic analysis results, usually, in results expressed as ranges and probabilities (a typical cumulative frequency curve, for example).  Later, when speaking with one of the "Big Manager's" direct reports, that person indicated that when bringing information to the "Big Manager," you had better not show up with a range of answers - he wanted THE number!  Just another example of saying one thing but meaning another.  This subject is expanded upon greatly in the book Risk Assessment and Decision Making in Business and Industry - A Practical Guide, 2nd Edition.

The lesson here is that management has to be prepared regarding the impact that a switch to risk-based processes will actually have on them and the way they do business.  This leads me to the education aspect of this article.  


2 - Education at 3 levels (at least)

This educational aspect is part of the "chicken and egg" nature of implementing risk-based processes in any organization.  Preparing classes/seminars for multiple-levels of corporate personnel can be time consuming.  Your management - those paying for the risk-based-process implementation - have to be prepared to spend considerable resources in preparation.  Generating targeted classes/seminars are part of that preliminary preparedness.  

First, you have to do much homework regarding the businesses to be addressed.  Presenting generic examples in class regarding risk-process implementation will not "cut it."  Risk-based examples absolutely need to be taken from the business being addressed and couched in their terminology.  This can mean quite a bit of investigation on your part so that a credible set of examples can be created.

In addition, courses should be prepared for three separate audiences.  These are:

  • Top Business Management. For these few folks, a relatively short and to-the-point less-than-one-day presentation should be created. It should include:

1.    What will be the benefits to their business from implementing the risk-based approach;
2.    What their personnel will be using as input to the risk-based system and what the output means;
3.    What this effort will cost in terms of time, human resources, and money.

  • Business Unit Management. These are the individuals who will deal directly with the output from the risk-based system, and, will have to make smart business decisions in the new risk-based world. These folks will also be directly responsible for those personnel who are actually generating, running, and producing results from risk-based processes. A course for these managers should include:

1.    What will be the benefits to their business from implementing the risk-based approach;
2.    What their personnel will be using as input to the risk-based system and what the output means;
3.    What this effort will cost in terms of time, human resources, and money;
4.    What the output from the risk-based processes really means and how they can use such output to advantage in their business - this is very important and should be illustrated with real examples;
5.    How to present this new output and information to their managers and partners.

  • Personnel who will actually run/use the risk-based applications. These are the individuals who will deal directly with the output from the risk-based system, and, will have to make smart business decisions in the new risk-based world. These folks will also be directly responsible for those personnel who are actually generating, running, and producing results from risk-based processes. A course for these managers should include:

1.    What will be the benefits to their business from implementing the risk-based approach;
2.    What this effort will cost in terms of time, human resources, and money;
3.    Exactly what information and type of information (ranges, for example) are required;
4.    Exactly what happens to those data when processed by the risk-based systems (remove the "black-box effect);
5.    Extensive hands-on training with each risk-based system using examples and data that relate to their jobs;
6.    What the output from the risk-based processes really means and how they can use such output to advantage in their business - this is very important and should be illustrated with real examples;
7.    How to present this new output and information to their managers.


3 - Survey the risk landscape

As mentioned in previous articles, the risk-based process being discussed in these articles is one that is holistic.  That is, it encompasses and integrates risks from almost all pertinent disciplines such as technical, legal, engineering, commercial, financial, construction, security, health and safety, environmental, logistic, and many others.  There is no question that within an existing organization there exist several organizations that believe they already make use of a risk-based system and that their system is all-encompassing.  

For example, it is not unusual to find an Audit group or a Health and Safety group that use risk-based processes.  These processes can be quite comprehensive within their specific area.  Personnel within these specific disciplines typically cannot imagine a more sophisticated or holistic approach.  They are correct, usually, if the scope of risk is limited to their area, but your charge is to integrate the data/process used by their discipline with risk-based processes and data from all other disciplines.  This, they (the Health and Safety folks, for example) will not understand.  Managers and personnel within these disciplines can be significant sources of resistance to your more comprehensive effort because they believe "they have it covered" and very much feel threatened by your much more broad-spectrum approach.  Examples of how differently disparate groups can view the subject of risk are given in the book Risk Modeling for Determining Value and Decision Making.

So, before attempting to run roughshod over the already-existing risk processes, make sure that you make considerable effort to learn about those existing processes and to take plenty of time to meet and communicate with these disciplines.  Personnel using existing, but colloquial, risk-based systems need to know that they are NOT threatened by the new comprehensive process and, in fact, the input from their existing system will be a critical part of the new effort.  This, of course, has to be true.  So many comprehensive and holistic risk-based processes are killed before they get established due to internal sabotage emanating from already-existing entities that feel threatened.


4 - The common language thing again

I have addressed this aspect of risk-process implementation in several of the past 8 articles.  It keeps coming up because it is of such salient importance.

Miscommunication is the bane of any universal effort, and this is especially true for risk-based initiatives.  In previous articles I have described in detail the setbacks that can be expected when and if various parts of the organization utilize colloquial verbiage with regard to risk.  Typically, these cul-de-sacs communicate about risk only within their discipline and have little opportunity to attempt to communicate across disciplines.  For example, the risk folks in the Audit function might never sit down with individuals from Law to discuss how their risk perceptions and terms and definitions compare.  When a comprehensive risk-based approach is implemented, suddenly the definitions of terms matters.  Without some annealing effort, miscommunication is assured.

I have related in an earlier article that it is folly to believe that you will change, for example, the way Health and Safety folks view and talk about risk.  You should not waste your time in an attempt to cause them to modify their ways.  I have suggested the 'High German" approach to this problem.  That is, don't attempt to change the local dialects, but create a set of agreed-to terms and definitions that, when used for universal communiqués, will be understood by all - even though none of the disciplines might adhere to those terms and definitions within their particular disciplines (nobody actually speaks "High German" but all people speaking all dialects can read the same newspaper articles written in High German).  In this way, various independent entities can clearly communicate across boundaries.  This works!  Do not forget to address the communication issue!


5 - The reward system

I have saved the most important aspect for last.   As mentioned briefly in articles #1 and #6  of this series and as delineated at length in my latest book:  Modern Corporate Risk Management - A Blueprint for Positive Change and Effectiveness, regarding project teams, it is mainly true that:  We get rewarded for successfully launching a project, but not necessarily for launching a successful project.

This concept, and the inadvertent implications of most incentive systems, has so many facets and aspects that it's just a bit silly to try to adequately recount it in this article.  The reader is referred to the aforementioned text for more detail.  However, a few of the major "fixes" for the dark-side symptoms of the reward system can be described here in at least a cursory manner.

It is not uncommon to run across incentive systems based on "saving."  That is, rewards are distributed for "saving" money or "saving" time, etc.  In a project system that is stage-gate driven, or, in a system in which a project, during its lifetime, is passed from one corporate entity to the next (for example, from the negotiators to the commercial arm to the design department to the engineering department to the construction department...) incentives based on "saving" typically result in poor project results.  If corporate-entity #1 is rewarded for saving money, then it might be true that when corporate-entity #2 inherits the project, will receive a less-than-optimally-prepared project.  In the end, the operators of this project typically pay a high price for attempting to operate and maintain a facility, for example, built on "the cheap."

The lesson to be learned here is to design the reward system with the end-game in mind.  If the corporation actually wishes that the project process result in a well-conceived, adequately-designed, and decently-built entity, then incentive systems should be put in place that reward the quality of the end result and that do not reward intermediate constructs.  This, of course, might mean delaying the reward for those involved early on, requires a good "corporate memory" (who did what, when"), and can mean that groups that did an exemplary job in the early stages can get robbed of their reward by subsequent groups that "dropped the ball."  One way to attempt to ensure that the quality of the project is at least adequate at the hand-off from one group to another is to employ a qualified but disinterested party to pass judgment on the adequacy of the work being passed along.

Just one more of a long string of reward-system foibles relates to the practice of employees tying their sense of job security to the success of the project.  In article #2 I relate a story about assembly-line workers, but I actually prefer the "ugly baby" scenario.  If you ask the grandparent if the baby is cute, what response do you suppose you will get (even if the child is a bit frightening!)?  So it can be with project-team members.

I have had the experience of traveling to a foreign country to perform a risk assessment on a project.  The team members have moved to the country, moved their families, put their children in schools there, have purchased real estate, and so on.  I do not intimate here that these folks are dishonest, however, there is no question that their view and expressed opinions about the project are tainted by the fact that they tie, rightly or wrongly, their job security to the success of the project.  When interviewing these folks regarding critical data to be input to the risk analysis, it can be a supreme challenge to obtain objective information.

One "fix" for this syndrome is to disassociate most of the project personnel from the project's success.  For example, rather than sending a construction engineer to the foreign country on a permanent basis, such talented individuals can be seconded to the project from a central pool of engineers.  These folks will be in part reviewed by local in-country management, but their promotions etc. can be actually controlled by the central-engineering organization.  Such personnel can be rewarded for "calling 'em like they see 'em" with regard to problems on any given project - although, not to the extent that people are rewarded for making-up problems!

Overcoming the challenges of the reward system can be daunting.  However, just like curing a disease, the first step is to recognize and admit that you have a problem.  The reward system is always a problem and the preceding paragraphs outline only a few of the suggested steps that might be taken to resolve just a few of the most critical aspects.

In the next, 10th, and last article in this series I will attempt to encapsulate and summarize the highlights from all of the preceding articles.  Stay tuned for the last of the installations.

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