The Sarbanes-Oxley lesson: doing it wrong is very expensive

One of the lessons from Sarbanes-Oxley was the sheer waste of time and energy for those organizations that tackled it the wrong way. Admittedly most organizations tried to be thoughtful and creative in addressing SOx. Some recognized that SOx requirements were not significantly different from what they were (should have been) already doing. However, given the relatively small amount of time for implementation and the very large downside, it was often approached as a ‘compliance’ issue rather than a ‘management information’ issue. It should have  been approached as a relatively easy re-design of management reporting to include  existing organizational knowledge about the internal control environment.

Public accountants and other consultants bear substantial blame for this. The CPAs were feeling pressure from their governing bodies to assure ‘compliance’ with SOx. This sometimes meant that they were in a less-than consultative mood with their clients. And third-party consultants, of course, were ready to accept fees and help assure that these public companies satisfied the requirements imposed by their public accountants.

Now let’s move forward a few years.

Many organizations are moving, in some way, into risk management. The reasons can vary … regulators are becoming more insistent, the governing board has indicated that they want it. Or, perhaps, executive leadership is intrigued by what they imagine risk management can provide to help them better run their organization.

One thing that organizations need to avoid is treating risk management implementation like they may have treated  Sarbanes-Oxley implementation. There is a natural temptation to presume that risk management is a side-project that the organization simply must accomplish and move past. There may be a presumption that there is a checklist that, once completed, will provide a risk management environment. In fact, there is … but only at a very high level. There are specific objectives that need to be achieved in order to implement risk management. But each of those objectives needs a strategy that is specific to each organization.

For those organizations considering a more formalized approach to risk management, there are three options:

  1. Spending: Creating a  risk management program that provides little value beyond the fact of its existence.
  2. Waiting: Doing nothing formal and continuing to rely on the management team to manage risk in an ad-hoc manner.
  3. Investing: Thoughtfully design and implement a risk management environment that will continually pay dividends in better organizational information and decision making.

The worst of these options is the first – spending money with little or no payback. The biggest damage is the illusion but no substance of risk management that is often created through a weak program.

The other two options are simple cost/benefit. If management believes that the organization can’t afford to improve its ability to make better decisions and achieve its objectives, it may be better to wait and not invest in risk management. However, if executives believe that the organization needs to perform better and achieve results faster then risk management is definitely a tool that they need to consider.

My advice – executive leadership should firmly reject any weak risk management process. Spending money with no clear payback is irresponsible.

Instead,  executives must consider carefully the cost and benefit of  risk management. Bring in advisers who can guide management in understanding, at a business level, the costs and benefits of risk management. Then make a decision of either waiting or investing.



Risk management implementation projects – what you should expect

Risk management implementation projects can be very challenging. But, when they are done correctly, they deliver results that can raise your organization to an entirely new level of performance.

My prior post discussed some unreasonable expectations for your implementation project. This post talks about the flip side — you need to set high expectations in some areas.

Risk management should provide more than lists and graphs – it should provide organizational insights

Risk management should provide value. The value isn’t necessarily embodied within a particular list that it might generate. Instead, the value is in the overall knowledge that it provides about the organization. The very process of implementing risk management helps drive a thought process that steps away from the day-to-day and focuses on the strategic and the “what-if”.

The risk management process naturally includes a need to understand which goals and risks are more impactful to the organization. Clearly, the most impactful goals and risks should receive a greater share of management’s attention. This process of thinking about goals and risks in this manner leads to the natural process of thinking about which actions, deeper in the organization, directly support these most critical goals. As an example, an organization’s highest goal may be to improve its customer service image. As this goal cascades through the organization, a low level risk of “Customer service representatives fail to reasonably satisfy customer requests” may be seen as one of the most significant risks to the organization – perhaps a much greater risk than those risks that might be attached to other top level strategies.

Limit executive leadership’s involvement to specific points

There are specific points in a risk management implementation project where executive leadership must be involved. This includes establishing the organization’s general approach to risk management, determining the scope of the implementation project, and identifying how the resulting information should be organized to provide practical answers.

However, once these foundational steps are done the project manager, along with the sponsor or liaison, should be able to proceed independently and methodically with gathering knowledge and data. This is done through interviews and discovery at varying levels throughout the organization. Interviews at the top level must, of course, include executive management. However, when the project is proceeding through lower levels of the organization executive management simply needs to monitor the progress (as with any project) and provide periodic insights and feedback.

Expert outsiders can provide immeasurable help

This expert help is seen in a few specific areas.

First and foremost is the value of experience in defining and managing the project.  Someone who has experience can provide options for what risk management realistically can, and cannot, provide to an organization. A third party can also help maintain a focus on the project so that it doesn’t get  buried underneath day-to-day urgencies.

Second, expert outsiders can help identify the risk environment in certain areas of the organization. This is especially true in areas with a specialized knowledge base. It can be very beneficial to have a third party help minimized ‘group-think’ and assure that the total risk environment is being considered.

Collected data can be used in many ways

Risk management expands data about the organization. This new data is necessary to answer questions that could not have been previously answered. It needs to be structured so that new insights (such as those that come along with periodic updates to risk assessments) can be captured over time. But the additional knowledge needed to specifically answer “risk” questions can also be used in other ways.

A critical feature of risk assessment activities is the need to understand which activities and risks have the greatest impact on the organization. As this information is collected, it is typically aggregated according to the unit or person who ”owns” them. This new knowledge about individual goals and activities can be used to enhance an organization’s overall performance management and goal-setting process.

Perhaps the greatest benefit from implementing risk management isn’t “risk management” specifically, but how the data and the knowledge round out the overall management and decision-making capabilities.


Risk management has the ability to deliver profound insights into an organization. Management can use these insights to dramatically improve its ability to achieve its goals. These past few posts have discussed ways to assure that your implementation project has a good chance of successfully adding value and setting a foundation for an effective on-going risk management environment.

Risk management implementation projects – unreasonable expectations

As I discussed in prior posts, risk management implementation projects can be very challenging. The perceived success is often directly related to the expectations for the project. In this post I’ll write about some common, but unreasonable, expectations. My next post will address the  flip side – what you should expect to receive from the project.

Unreasonable — Risk management is a one-time analysis

Everyone recognizes the need to continually update accounting records and periodically produce new balance sheets and income statements. Your risk environment, similarly, is constantly changing and needs to be updated if it’s to provide value. When risk management is treated as a one-and-done activity, it runs into two fundamental problems.

First, the information in the very first risk assessment is, essentially, an unvalidated model of your organization’s risk environment. It’s often unwise to place confidence in an unvalidated model. Instead, this risk model must be revisited from time-to-time and adjusted until the model reflects an ongoing representation of the real world. If a risk management model, 12 months later, indicates that a particular risk is the greatest risk to the organization does that still make practical sense? If not, what assumptions need to be tweaked?

Second, any organization’s real world environment is not static. It changes daily. The greatest benefit of risk management is to capture changing conditions and help identify where and when certain strategies may no longer be optimal and should be revisited. This capability focuses management’s attention on  either mitigating a new emerging risk or taking advantage of a new emerging opportunity. This value is lost if risk management is viewed as a static project.

Unreasonable — Risk management will deliver hard and objective answers about risk

Sorry. Risk management is inherently subjective. The foundation for risk management relies on people’s opinions of how different  activities and risks might impact your organization. Occasionally, in very specific risk areas, there may be  sufficient data such that analytical risk models can be created. But even these apparently objective models are based on historical experience and assumptions about future probability. It’s important to recognize that risk management always relies on opinions and assumptions. The goal is to remove the superficial subjectivity surrounding assumptions, definitions, and personal self-interest. When this superficial subjectivity is removed, it is far easier to discuss, rank, and monitor the impact and likelihood of risks.

Perhaps most important is to simply avoid the illusion of objectivity and openly recognize that periodic ongoing updates to your risk management system fulfill two purposes – i) to recognize changes to your risk environment (i.e., the inputs to your risk management model) and ii) to provide ongoing validation to your organization’s risk management model, itself.

Unreasonable — Management can fully outsource the implementation project

Senior management must remain involved to some level. No one outside of the senior management team can know all of the important strategic and tactical issues within your organization. This means that, except in broad general terms, no single individual can effectively:

  1. Design the ultimate risk management deliverable,
  2. Identify all of the risks,
  3. Determine which risks might be more potentially harmful to the organization,
  4. Determine the likelihood that those risks might actually occur.

Of course, the more time that someone spends inside the organization doing research and  interviews they can become more familiar with the organization. But that’s still no substitute to directly involving the right people at all levels of the organization. It’s the only option if the foundation is to be built on solid, informed opinions rather than uninformed generalities.

Recap: This post addresses some of the unreasonable expectations. You may have additional ones in mind and I would love to hear from you. The next post will flip this over and discuss some very reasonable expectations that management should have.

Risk management implementation projects – the project itself

Risk management implementation projects are not easy. When they are done right, though, they create a new view into your organization. My earlier posts talked about the importance of establishing overall expectations and managing the data that you will be collecting. This post talks about two additional foundation steps to get your implementation project off to a solid start.

Develop reasonable project steps

The project must be divided into manageable steps. It’s not realistic to believe that an organization can identify every risk during a single brainstorming session. The topic is far too broad. Instead, the project must be divided into specific risk assessment areas.

An organization has the option to proceed top-down or bottom-up. There are advantages to both.

A top-down approach consists of identifying high level activities along with their associated risks. These high level activities could be grouped around clearly defined strategic objectives. Alternatively, they could be organized around general categories such as financial reporting activities, legal and regulatory compliance activities, manufacturing activities, etc. In highly diversified organizations, it might make sense to focus on the unique top-level objectives and risks for individual business units.

A bottom-up approach consists of focusing on very specific activities and associated risks at the lowest level of the organization. This can be easier to define because an organization can simply point to a specific department within a specific area or, even, a specific individual in order to identify objectives and associate risks.

Regardless of how you divide the project, the goal is to identify what each particular area is attempting to accomplish and the things that could go wrong (the risks). This consists of interviewing management and consulting other resources to assure that all of the activities and risks are reasonably identified.

Critical Implementation Requirement

Decide on a top-down, bottom-up, or hybrid approach to breaking down activities and identifying risks.

Determine how the implementation project will proceed through the organization

An implementation project could start at a high level, focusing on identifying strategic risks first, or at a lower level focusing on procedural risks, or somewhere in between. The question, now, isn’t where the project starts. Instead, it’s the direction and extent to which the project moves from area to area.

If the project starts at a high level focusing on, say, 8 strategic categories and associated risks, then it might move down into each next-level subsidiary organization and determine how each subsidiary addresses those 8 same strategic categories adding whatever additional associated risks that might uniquely apply.  Or, perhaps the project addresses only a single next-level subsidiary. In turn, the project could then dive deeper into that single subsidiary’s divisions, and departments, to get increasingly specific in terms of the processes and risks that support those strategic categories.

On the other hand, if the project starts at a low level focusing on specific procedures and risks in a single department, it might move to other departments within the same division. This would develop a view of practical risks that eventually encompass a particular business unit. Or, perhaps, the project next moves to a similar function in a different division. With this approach, the project builds a broader sense of risks within a single function (e.g. “cash management”).

Critical Implementation Requirement

Decide how the project should move through the organization. It must be methodical. But by selecting one approach over another, the project will be aggregating its knowledge in different ways throughout all of the interim steps. 

This finishes the discussion of the foundation for a risk management implementation project. Next, I’ll offer what I think are reasonable (and unreasonable) expectations for a risk management implementation project.

Risk management implementation projects – data management

Risk management implementation projects are not easy. When they are done right, though, they create a new view into your organization. My most recent post talked about the importance of establishing overall expectations. This post talks about two additional foundation steps to get your implementation project off to a solid start.

Decide how data will be captured during the project and used in the future

Every implementation project will collect data. At a minimum, it should collect the various objectives throughout the organization along with the associated risks. Why objectives? They are the context for the risks. It is much easier to initially identify these organizational objectives, at whatever level of specificity is appropriate, than to simply start brainstorming risks without a context. They could be strategic objectives, department objectives, individual objectives, or any combination of these. Once the objectives are identified, though, the associated risks are often obvious and intuitive.

As this information is being collected, the project leader must devise a method for organizing it. The identified objectives should be associated with individual units and/or people. Risks should be associated with specific objectives. Beyond that, an implementation project may commonly wish gather and store information relative to:

  • Ranking the relative importance of individual objectives and risks
  • Linking lower level goals to the higher level goals that they support
  • Rolling up information so that managers can see views that incorporate the totality of their responsibilities
  • Ongoing monitoring whether objectives and risks are in line with expectations (key performance indicators and key risk indicators)
  • Identifying processes (internal controls) that help to mitigate specific risks

Tools exist to help manage this data. Some tools are more flexible than others. Problems can arise when a tool is used that is either inflexible or requires a significant learning curve. As always, the tool should match the project, not the other way around. Be cautious of using spreadsheets. They are easy to use initially for capturing data. But, the need to link this data will undoubtedly become increasingly important as management identifies the value that risk management can provide. Spreadsheets are quickly outgrown.

Management should also consider how this data will be updated. Will it be maintained by a wide variety of people throughout the organization or will it be centrally administered? Will some pieces of this data be updated as an integral part of the management process (e.g., in some cases perhaps daily) or will it only be updated as part of a recurring specific project?

Critical Implementation Requirement 

Decide what data will be captured during the implementation project, how much will be captured, and how it will be stored.

Determine how and when risks are to be rated

A common goal for an implementation project is to rate or rank the identified risks. Some organizations choose to rate these items, using a common scale, as they are initially identified. The advantage to this approach is that the conversations that identify the risks are often with the same persons who have the most knowledge to also be able to rate the risks.

There are disadvantages, however, to immediately rating the risks as they are identified. Often, more senior managers are in a better position to apply meaningful ratings than lower level managers who work with these risks day-to-day. At the lower levels of the organization, a risk may seem critical to a person because it is the primary focus of their job. To more senior managers, however, the risk may be of far lesser importance to the organization overall.

It is often more advantageous to ask the person who works with the risk day-to-day to rate the likelihood that the risk might actually occur, but to have more senior people provide the value for the impact of that risk upon the organization.

Critical Implementation Requirement

Determine at what point numbers or other rating scales will be applied to objectives and risks as they are identified in the implementation project.

The next post will talk about the two final implementation project considerations.