A practical approach to reputation risk

Every organization has some desirable public image. Does it want to be perceived as environmentally sound? Family friendly? Political activist? A ‘high roller’? Cutting edge? Traditional? Or, perhaps it simply wants anonymity in the public eye.  Reputation risk results from strategies or actions that conflict with the desired public image.

Rather than wait for reputation risk issues to arise, it is important to be proactive. Let’s take a step back. Organizations are constantly developing strategies at all levels. Whenever someone is assigned a new task or objective, a strategy needs to be developed to accomplish it. The process of selecting or creating a new strategy can include the evaluation of whether that strategy is consistent with the organization’s public image.

In risk management, I use the term “risk attitude” to describe which strategies management would, or would not, feel comfortable with. A “low risk” attitude indicates that management expects assurance that the proper results will be achieved. A “high risk” attitude indicates that management is willing to take its chances and would be comfortable with a strategy that might deliver results ranging anywhere from wild success to total failure. Neither is necessarily good or bad and can vary not only from one objective to the next, but also with different components of a single objective. It’s possible, for instance, to develop a desirable strategy that is high risk in some areas (e.g. financial returns) while low risk in others (e.g. worker safety). But nearly every organization wants very low risk when it comes to protecting its public image. If that’s the case, then it’s reasonable to have a specific question that needs to be answered as part of every new strategy — is it consistent with our public image?

Of course, this assumes one very critical component. The organization needs to define and be able to describe its preferred public image. If that’s not the case, then reputation risk is increased simply because it may be unclear what to embrace or avoid during strategy development. If employees don’t know that the organization is cultivating a worker-friendly image, then a cost reduction initiative may include a strategy that includes massive worker layoffs.

That’s the first part — making sure that the organization understands how to develop appropriate strategies that will, at least initially, be consistent with your public image.

There is another part. An organization needs to be generally perceived as trustworthy and competent. For example, while an organization may not be explicitly cultivating a public reputation for good customer service, excessively poor customer service will still create a public image problem. The same would be true for any normal business activity if it is executed poorly to the level where the public perceives the organization as being incompetent. Even something as mundane as an inability to pay its bills accurately could grow to the extent that it creates a public perception of incompetence.

To avoid this, an organization also needs a general performance and risk management environment where expected performance levels are defined. Performance levels that don’t meet reasonable expectations need to be elevated to management long before such “incompetence” becomes a subject of public discussion.

Please share some stories about how your organization is addressing reputation risk.

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.

Summary

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.

Risk management projects start with describing expectations

Risk management implementation projects are not easy. My own experience (including anecdotal from many professional friends) tells me risk management projects have a great likelihood of failure. Failure, primarily, to live up to expectations … whatever those expectations may be. You can benefit by considering some things to help you get off to a solid start.

A natural temptation might be to name a competent project leader and let them start collecting a list of risks. That, unfortunately, is an excellent way to waste a lot of time and energy. Instead, it’s essential that the three implementation challenges be clarified in at least a preliminary way. That can be done by addressing certain topics prior to rolling out the implementation project. I’ll discuss the first of these in today’s post.

Describe the ultimate deliverable

Most everyone knows what risk management is. Or, at least, they are confident that they know  their view of risk management. To those with an accounting or audit background (like me), risk management can imply an evaluation of internal controls. To investment managers, risk management can imply assuring an acceptable and consistent rate of return. To entrepreneurs, risk management can imply additional insights in order to avoid crippling operating losses. To insurance professionals, risk management can imply assuring sufficient insurance coverage.

Setting agreed-upon expectations is critical. Management should identify what risk management should provide in 1 year and in 5 years. To what extent will it be integrated into the overall management framework? Will risk be a topic that is a natural part of everyday discussions or will be a separate annual review? Who will ‘own’ risk management? How will you assign responsibility for specific risks? To what extent will risk management be analytical and to what extent will it be holistic? How will risk concepts influence business decisions? Is risk management only for executive leadership or is it for everyone?

It may be convenient to think of a risk management environment as consisting of some combination of two essential views. One view is primarily analytical. This view envisions spreadsheets with numeric scales and multiple assessment projects with, perhaps, statistical analysis. A different view envisions a network of interconnectedness – a holistic integration where strategies and risks are tied together in a conceptual model. This model shows how the organization operates and how risks might negatively impact that operation.

In my experience, both types of visions – analytical and holistic – are represented in the senior leadership of virtually every organization. These differing backgrounds and different ways of approaching problems tend to get magnified in a risk management implementation project if they aren’t addressed up-front. Neither vision is wrong. In fact most organizations adopt some combination of these views.

Critical Implementation Requirement #1

Executive leadership must develop and share its initial sense of what risk management will mean to the organization. This must be especially understood by the person who will design and shepherd the actual implementation project. As Stephen Covey said – “Begin with the end in mind.” It is important that executive leadership provides enough vision and guidance so that the project leader and the entire organization have a sense of the ultimate deliverable.

In future posts, I’ll address a few other topics that can help assure that your risk management project starts off on solid footing.

Risk management implementation traps

Risk management isn’t risky … but implementation projects can be.

Risk management concepts can be transformative to an organization. Any organization – whether for-profit or not, whether large or small – can be transformed. When done correctly, risk management concepts can assure that management’s attention is always on the right things, and never on the wrong things. When done correctly, they help assure that everyone has a consistent view of what makes the organization successful and, conversely, where disasters could be lurking. When done correctly, better decisions are made at every level in the organization.

So why hasn’t every organization formally implemented risk management? Here are a few thoughts.

It may not be clear what a risk management project can actually deliver

Projects should not have fuzzy goals. Unfortunately, that’s often exactly the situation for poorly-planned risk management projects. One of the underlying reasons is that risk management, itself, can mean different things to different people. Also, risk management can seem dramatically different from one case study to the next. It is no surprise that most organizations have not invested in risk management considering the difficulty of defining exactly what it can provide.

It may not be clear exactly how to translate risk management theory into practice.

The next stumbling point is implementation. Most people would agree that risk management is, at its core, an essentially intuitive concept. The problem isn’t with the ‘idea’ of risk management. Instead it stems from the supplemental concepts, such as “risk appetite”, that attempt to make risk management more practical. These supplemental concepts might make perfect sense when they are discussed, philosophically, in a meeting room but they often fall apart when they move into the untidy real world. As a result, when organizations take their first stab at risk management, they may get discouraged when the real world creates ambiguities, circular logic, and a notable lack of relevant concrete examples.

It may not be initially clear how risk management can provide long term value.

Thinking forward, how will this initial effort benefit the organization long-term? In some cases executive leadership may initially imagine risk management as a stand-alone activity that’s dusted off and updated every year or two. Understandably, it’s hard to see ongoing value in such an approach. The practical benefit of how it can help the organization achieve its goals better and faster may not be obvious or intuitive. One thing is clear – as long as it’s separate from the normal day-to-day management activity it cannot become transformative.

As you’re considering a risk management implementation project, you must address and resolve these issues to achieve the benefits that risk management can deliver.

There are ways to remove these obstacles. Stay tuned.