IT transparency is good. But how transparent should you be?

A few years back, I had an extremely surprising and unpleasant experience as CTO. The director of my Program Management Office ran a weekly status meeting for project stakeholders, where we’d all methodically go through the current project portfolio, in order to communicate on issues, gather necessary feedback, and align everyone’s expectations. I typically attended in order to provide input and executive-level decision participation, but left it to the director to actually run the meeting and present the topics.

Unfortunately, immediately before one of these weekly meetings, that director was given bad news (in a brief hallway conversation, no less) about a major bug that had just been discovered in the software for our highest profile project, which was currently in testing and due to launch in just a couple of weeks.  This project, with its strategic and revenue-enhancing potential, was foremost in the minds of everyone in the company.  Stakes were high, in other words.

Without conferring with me or anyone else, the director announced to the entire group of assembled stakeholders that the project had hit an insurmountable snag in terms of our target launch date, and that it would be delayed potentially by weeks. No further information was available on specifics, and people’s concerned questions went unanswered. You could feel the anxiety spread through the room. I actually had to truncate the meeting abruptly and promise to reassemble the group when we knew more.

My director was quite upset with me. Rather than having my action be understood as a necessary attempt to prevent panic until we could get some real facts, I suddenly realized that I was being accused of wanting to “hide information” from the stakeholders. The director even told me, “Well, I like to be honest and tell it like it is, but that obviously just isn’t what is wanted here.” I was stunned. Here was a person who had the wrong idea of transparency, and astonishingly for their position, a warped idea of what project management is all about.

As most experienced project managers know, it makes utterly no sense to drag stakeholders through the entrails of every back-and-forth readjustment that is discussed and worked through in the course of a project’s lifetime.  To do so lowers stakeholder confidence, unnecessarily in many instances.  In this case, the director somehow wanted to be a kind of Paul Revere, forewarning the stakeholders, but instead came off as Chicken Little. Transparency can’t be an act of individual heroism; it needs to be a concerted, institutionalized, collaborative philosophy and approach.

Moreover, good project management isn’t about making everything go smoothly. There’s probably no project plan in the history of the world that has gone completely smoothly from beginning to end.  Instead, project management is about responding appropriately when it doesn’t, and recalibrating to keep everything still on track. In fact, it should be expected that not everything will go as planned, and your whole team should be prepared to take some bumps and glitches in stride without panicking.

It’s not hiding anything to hold back on discussing, in a public forum, a problem that has just been discovered, the ripple effects of which initially can only be guessed at.  When you promulgate potential bad news prematurely, it puts you into the position of trotting out the absolute worst case, before you really have any idea whether that worst case is likely or even plausible. In fact, it’s a fundamentally selfish act: it takes your own personal panic and extends it to as many people as possible.  And if there’s one thing we know about panic, it’s that it’s contagious.

You need to shoot for judicious and organized transparency. That’s where you plan on regular status communications, and you methodically, soberly assemble the facts in a structured manner before you make those announcements. Most of all, you collaborate internally: before you bleat about a potential crisis to the stakeholders, you bring in the rest of your team to talk through the possibilities and “degrees of freedom” in how you’ll act with respect to that crisis. Otherwise, you may think you’re nobly playing Paul Revere, but instead of imparting critical facts, you’re shouting “The British might be coming!”  And that’s not transparency, that’s mere alarmism.  Remember that especially during the dog days of a stressful IT system development effort, what often seems like a dire setback, upon careful and collaborative examination in the light of day, turns out to be merely a minor speed bump that is easily overcome.

Is it “controlling the message” to be cautious about spreading the alarm? You bet it is. And doing that is in everyone’s interest. Remember my adage: show that you’re in control. Your job as project manager (and, by extension, the job of the Director of the PMO, and the CIO) is to be in control and to demonstrate to the users that you’re in control.  That doesn’t mean that you “hide” anything; it does mean that you deliver bad news broadly only when you’re sure of your ground, have weighed the options for how to cope with that bad news, and are ready to present those options soberly instead of in a flailing manner.

Adhering to a philosophy of transparency is a far cry from shouting every blip or misgiving about the project from the rafters. This is particularly so if you’re in a leadership position. You want your communication to be transparent, yes. But without appropriate structure and caution, transparency can be the height of irresponsibility. In those cases, in fact, you’re just building a slightly more institutionalized rumor mill.

Lagniappe:

Comments

  1. I think “judicious and organized transparency” nails it. The Chicken Little approach is counter productive to the organization as well as creates unneeded stress on you (as Director in this case) to have to quiet the masses at the same time address the crisis. “The sky is falling” doesn’t help anyone. “We just got word that the sky might be falling. Before anyone panics, we are going to dig in, understand the scope of the falling sky and present some options to keep the sky up where it is supposed to be. We’ll report back by close of business on the status of the possible falling sky.” Or some other permutation that conveys the notion that “stuff” will happen, but there is a plan and options on the table to address the “stuff” … as Peter says: “show you are in control”

    Great post!

  2. Steve Romero, IT Governance Evangelist says:

    Nice post Peter. It does a great job of showing the downside of transparency.

    I follow a short list of rules when it comes to transparency:
    – Information is used for one thing – to make decisions
    – Information should be fact-based
    – Information not based on fact should be clearly labeled (conjecture, assumption, estimation, gut-feeling, etc.)
    – Information must be provided to the folks accountable for making decisions associated with the information

    As if you couldn’t guess, this is the essence of governance (the processes and relationships that lead to reasoned decision-making). It all starts with understanding what decisions need to be made, knowing who is accountable for making given decisions, and collecting, integrating, analyzing and disseminating the information required to make those decisions.

    Sounds simple, but it requires a level of governance and process sophistication few companies possess. This leaves the door open to either no transparency, or the transparency-gone-wild that you describe.

    Steve Romero, IT Governance Evangelist
    http://community.ca.com/blogs/theitgovernanceevangelist/

  3. Great article. Having been through these situations myself I can echo your guidance. Everyone NEEDS you to demonstrate a steady hand and be the North Star they can set their internal compass by. The alternative as you aptly describe is a contagious panic.
    The flip side is equally bad. All items on all status report being green with no own issues is lighting the fuse on the bomb which will inevitably go off as implementation date draws near. Usually very avoidable with a modicum of awareness and comfort with the measured assessment and response to issues as they arise.
    … Great post. I look forward to reading what you write.

  4. As is often the case, Peter, the thing that makes what you’re advocating difficult is that it requires judgement and a relatively fine touch. A lot of people want absolutes; but “tell all and let the chips fall where they may” is not much better than “control for favorable impressions at any cost.”

    Yeah. Being a manager is hard. Any formula that purports to make all decisions for you is a poor formula.

    Complicating this is the fact that many IT directors work in adversarial environments where honest transparency exposes you to an unacceptable level of vulnerability.

  5. Thanks for commenting, Mark, and you’re certainly right about how some people want “absolutes”.

    I guess I didn’t view what I was advocating as really all that difficult: it’s asking people not to spew bad news unless/until there’s been an opportunity to talk through the implications of the news with the team at large. Lots of times, the bad news turns out to be nowhere nearly as catastrophic as it seems at first glance, so it’s important not to go off half-cocked, in some well-meaning push for alleged transparency. Otherwise, I’m actually a huge advocate of transparency; see the post I linked to on why the CIO needs to air the dirty laundry, for example.

  6. Hmmm. Seems to me that this story is told from one particular view point and doesn’t give the PMO director a chance to put their case. For example, we don’t know what information the PMO dir. was given about the issue before the meeting.

    Was the normal practice to check everything out with you (as CTO) before hand ? Or could he have believed he had the delegated authority ? Where did the “wrong idea of transparency” and the “warped idea of what project management is all about” come from ? Surely there should have been a discussion about processes, communication, transarency, values etc as part of their induction to the company and role ?

    I don’t disagree with the points you make based on this story, but perhaps the transparency needed to start between you and the PMO director ? Then maybe he would have been less upset, you less stunned, and neither of you would have been accusing each other of anything ?

  7. I’m thinking (like cvb) that there is another perspective on this. It also seems that this belies some “old-thinking” about the role of IT. Having been a CIO and CTO I understand that I am the steward of technology and business partner, not the owner. Technology only exists to enable the business strategy and capabilities … my customers are the business owners first and their customers second. IT should not control information and frankly should not control projects it doesn’t really “own”.

  8. cvb and TB,
    I appreciate your posting, especially with dissenting opinions.

    That said, I think my post already answers your points quite clearly. And I learned quite early in my career (sometimes the hard way) that executives typically don’t react well when someone comes to them a) in a panic; b) not in possession of all the facts; and c) unable to outline potential approaches/solutions. The director failed on all three counts in this instance, AND was addressing the stakeholders to boot.

    cvb, the background on the individual and their previous behavior and/or discussions on these matters is really more an HR issue, and is a sidebar to my main thrust in this post: as I wrote, “It’s not hiding anything to hold back on discussing, in a public forum, a problem that has just been discovered, the ripple effects of which initially can only be guessed at. ” TB, you’re simply not doing your business owner customers any favors by allowing unprepared, reactive statements to be made in a meeting with respect to a just-unveiled potential crisis. That’s not transparency, it’s panic; and the issue has nothing to do with project “control” or ownership. It’s simply good business practice on dealing with crises.

  9. Peter, that’s fine. For “I don’t disagree” you can read “I agree” with the point(s) you were making. But it did seem there was some broader learning to maybe explore as well.

    I don’t find “the sky is falling” terribly useful either. It isn’t really *information* at that stage.

Trackbacks

  1. […] IT transparency is good. But how transparent should you be? by Peter Kretzman on CTO/CIO perspectives […]

  2. […] IT transparency is good. But how transparent should you be? No TweetBacks yet. (Be the first to Tweet this post) […]

Speak Your Mind

*