Sep 212010

The worst mistake is not telling the boss.

Or so said an article a few years ago in the Washington Post about the importance of immediately disclosing problems or mistakes to your boss.1

I am a great believer in this idea as well, which is part of what the late management theorist and practitioner Peter Drucker called “information responsibility.” Without knowing the true state of play, it is pretty difficult to manage enterprise risk effectively.2

This Washington Post article came to mind again as I read a Bloomberg News article last week dealing with the roots of the financial meltdown,3 as well as from a recent coincidental conversation I had with a friend of mine responsible for helping organizations role out enterprise risk management (ERM).

The Bloomberg article described US Federal Reserve Chairman Ben Bernanke’s error of omission regarding whether the Federal Reserve had the power to save Lehman Brothers from collapse in 2008. Lehman’s collapse helped intensify the financial panic then occurring, and the Fed’s role at the time has been controversial ever since.

Chairman Bernanke admitted in front of the Financial Crisis Inquiry Commission panel investigating the root causes of the financial meltdown that he wasn’t “straightforward” in his testimony in front of Congress in 2008 by implying that the Fed could have saved Lehman but decided not to because other investors were looking to intercede. When these investors didn’t save Lehman from bankruptcy, well, it was just too late for the Fed to do anything more.

The actual truth was that the Fed had no powers to intervene directly on behalf of Lehman Brothers even if it had wanted to; that it, the Treasury, and investors it had contacted had decided long before Bernanke’s testimony that there was no way Lehman Brothers could be saved, and that the truth was “modulated,” as one observer put it, by Bernanke to reduce stirring up even greater financial panic.

Commission members basically gave Bernanke a pass on his error of omission because by shading the truth, they said, he was trying to “achieve a better outcome.” In other words, the ends justified the means.

This brings up an interesting issue. Why it is wrong for employees not to tell their bosses of the risks they are encountering, but it is OK for their bosses to “modulate” the truth about risks if doing so serves to “achieve a better outcome”?

For instance, on a project where the risks to success are starting to increase, should the project manager acknowledge the situation to his or her team, or continue to tell them that everything is OK?

In other words, does disclosing the risks put the project at further risk by sowing fear, uncertainty, and doubt (FUD, as it often known), thereby possibly creating a self-fulfilling and self-defeating prophecy? Is it better to put up an optimistic front to keep everyone focused on the job at hand?

But that said, why should the project manager disclose the risks to his or her bosses, for fear of undercutting their support for the project?

These questions were at the root of a recent conversation I had with a friend. He was telling me that a very large organization had decided about six months before to invest heavily in an ERM product his company offered and roll it out across the corporation. However, his client was now telling my friend that instead of rolling it out across the enterprise, ERM was going to be used only by senior executive management.

Ignoring the obvious question about how such an approach could possibly be considered enterprise risk management, I asked what had happened.

It turns out that once people started to see that risk information from the bottom of the organization was going to be visible to the top, and vice versa, management at all levels started to think that transparency might not be a good idea. Everyone, it seems, was worried that the risk information would be “misinterpreted” by those who saw it and cause more harm than good.

My friend wouldn’t say so directly, but from what I could glean, one of the (ironic) reasons the corporation had decided to invest in ERM in the first place was because management was being surprised too often by projects and product developments that were green one day, and red the next.

I guess getting surprised is less painful than seeing failure creep up on you.

What I suspect is that the corporation my friend was involved in has what I call a “culture of optimism,” where truth isn’t always rewarded, and non-truths often are. ERM was being used in a way to change that organizational culture, but it is likely “optimism” is so deeply embedded at all levels, that ERM was seen as a threat to personal paths to success.

I don’t have any easy answers to the question about the benefits (or not) of disclosing risks. For me, I don’t like sugarcoated project status reports: such reports just get in the way of doing what needs to be done. And I like to share risk information with teams I work with for the same reason: what you know can’t hurt you.

Other project and senior managers I have dealt with like to follow the politician’s credo: it is OK to lie to the people as long as you do not lie to yourself. By keeping an optimistic front at all times, these managers believe that their people will continue to work hard to create success, rather than worry about possibly failing.

Sometimes, in special circumstances, that approach may be appropriate. Maybe Bernanke was correct to try to stem a panic. The only trouble is that his credibility on other issues has been questioned ever since, which also has consequences.

I would be very interested in hearing from Cutter readers on this topic, especially in regard to whether ERM is possible where risks are not fully disclosed either by project managers to senior managers or by senior managers to project managers. When is it OK to “modulate” risk information, and when is it not (if ever)?

I welcome your comments about this Advisor and encourage you to send your insights on the enterprise risk management and governance market in general to me at

Robert N. Charette, Fellow and Director, Enterprise Risk Management & Governance Practice, Cutter Consortium


1 Joyce, Amy. “The Worst Mistake Is Not Telling the Boss,” Washington Post, 21 January 2007.

2 Charette, Robert. “Information Responsibility.” BI Review Magazine, 3 March 2006.

3 Lanman, Scott. “Bernanke Says He Wasn’t ‘Straightforward’ on Lehman,” Bloomberg News, 2 September 2010.


  3 Responses to “Truth and Consequences: A Balancing Act in Disclosing Risk”

  1. avatar


    It is not only advisable to disclose risk to our managers but to all in a company. You see, the same goes with ideas and opportunities. Great ideas tend to die because you just tell your boss and it depends on his/her vision to assess the benefit. The same goes with risk, your boss will assess the damage. So the best advice is to disclose ideas and risks to all in the organization. The team dynamics will work wonders to steer the organization in the best possible route for it.

    Unfortunately, we live in hierarchical organizations and this is the root of the issues you talk about. And really hierarchical structures blend to create countless issues of communications and affect decisions directly with most of the time causing a bad effect. But this is a larger discussion.

    Anyway, ideas always have 2 sides: and opportunity and a risk. And risk or issues have always 2 sides: A risk and an opportunity. So you see both go hand in hand and that is what we call innovation.

    Risk management and Innovation management therefore need to be managed in a similar way. In a few broad words the process goes like this:

    · Ideas and risks are brought up to anyone in the organization to a neutral forum, where everyone has access to it. And everyone can create either of them, even anonymously.
    · An initial assessment for completeness is made by a moderator. This is not to assess the idea/risk, just to make sure it has the enough information.
    · A forum of people from all hierarchical silos assesses the risk/opportunity and the decision is recorded and kept in history for future reference.
    · Status of the idea/risk is kept up to date to assess its current validity.

    We already do similar processes for change management, projects, etc. But when it comes to ideas and risk, everyone is so hush about them.

  2. avatar

    A very realistic and though provoking article on risk disclosure. My opinion on this topic is that it does not matter whether we disclose or share the risk information. We could find several case studies where projects were successful in either case. My view on risk management is that risk management needs to adapt keeping in perspective of today’s VUCA world. We can no longer rely on status reports portraying the accurate status of projects. Senior management is incapable of extracting accurate information out of these well formatted reports. I propose a three-point strategy to tackle risk management.

    1) Remove layers of bureaucracy in the enterprise to enable filter-free risk information flow from bottom to top but also ensure that a proper access level mechanism is in place for the authorized stakeholders to get level of details on the risk to avoid unnecessary risk spreading.

    2) Senior management should try and gain insight into day-to-day activities of the project and also develop deep understanding of how project is being executed. We need leader who understand the big picture and small details.

    3) Ask good questions. Do not believe in what is stated in the status reports but dive deep into how the conclusion was derived. Tune the enterprise processes to provide supporting evidence on the status reports.

    Gaurav Goyal

  3. avatar

    An interesting article! My thought on this is disclosing the risk should not be viewed as the pessimistic approach. You can disclose the risk, have the risk management strategies in place and be optimistic about the strategies to manage the risks if they occur.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>