Dear readers—Please forward this to the business sponsor of the projects you might be working on. Ask them to subscribe as well!

Hi Business Sponsor!

You haven’t been my sponsor before, so I figured we should make sure we’re thinking about the role the same way.

Starting with this: I know you still have your “regular” job too. And now, as sponsor, you’re also setting the course for changing your job and others. You’ll be doing this by using some sort of technology, which is why you’re the business sponsor and why we’re working together. Your responsibilities are greater, and this effort is going to be more work for you until the project is launched and accepted by your staff, peers, and other stakeholders. Then it will continue to be more work for you until the project wraps up and the intended business change becomes reality.

You are feeling some sort of pressure to make this change, and this isn’t comfortable for you or the project’s other stakeholders. We are all dealing with a lot of change right now, and part of your role, is to be the person who makes intentional change happen for the organization. Undoubtedly, there is a lot riding on this project.

If the project goes well, you may get a promotion, save the business, or have engaging, congratulatory conversations with everyone involved. If there are rocky moments, people will be looking to you, and hoping that you have good answers and a calm demeanor. Let’s try to help you have more of the first kind of encounters, and fewer of the second kind.

This week, let’s start with your initial communication with IT, whether IT is internal, consultants, or any sort of hybrid). As business sponsor it’s up to you to set the tone in the relationship, just as you should be the one who sets the ground rules and expectations for open, trusted, clear communication.

From previous work in this column, here is a cheat sheet of questions that you should have an answer for and communicate with your IT team.

  • What, when it is all said and done, is the point of the project?
  • Who in authority wants it to succeed?
  • Who has the authority to define success?
  • Who has the authority to make decisions, resolve issues, and delegate authority?

How you present this to the IT team is up to you—Slides, a written doc, or working on a whiteboard are all good tools. But the trick isn’t in your answers—it is to make sure that your teammates heard you, and that you understand each other.

Enter an old tool from my Army days—The Back Brief.

Somewhere in the history of really tired people doing dangerous things, it became apparent that just because one person gives instructions doesn’t mean that the other person has heard the instructions, let alone has understood them.  Out of this, the Back Brief was born. (Actually, I don’t know exactly where this tool originated—but I first learned about it from leaders that I worked for in the Army.)

The simplest version of this is to ask the other person (IT, in this case) to take a few minutes, read their notes from your communication, and then tell you their understanding of the same four questions that you gave your answers to previously. You give your thoughts, IT digests these questions and answers, and presents their understanding back to you.

You ask questions and give feedback until all parties agree on their mutual understanding of the goals.

After this discussion, you will notice a few things:

  • You will feel like you have alignment with IT, and your stress level will go down significantly.
  • IT will be able to better give you choices and time/budget estimates, much earlier.
  • You and IT will catch major flaws in the charter far earlier.

This tool, used effectively at the beginning, saves you a lot of headaches later. We’ll introduce other tools that make your day better as a business sponsor in upcoming columns.

Let’s clear something up: Submitting a ManagementSpeak to KJR isn’t whistleblowing. What the two have in common: If the manager you’re quoting catches on and figures out you were the source, you might be in for some personal discomfort.

What they don’t have in common: Congress has passed no laws protecting ManagementSpeak submitters from retaliation.

Send in what you hear anyway.

Speaking of whistleblowers, the estimable Randy Cassingham, who also writes and publishes This is Truea weekly compendium of strange happenings from headlines around the world — told of the recently deceased Shuping Wang in his Honorary Unsubscribe.

In the 1990s, Wang discovered that the Chinese government’s methods for managing its blood supply promoted the spread of blood-borne pathogens; her tests showed contamination rates of 83% for Hepatitis C alone.

Wang attempted to bring the problem to the attention of her management, and when that had no impact tried jumping a level, with predictable results: Dr. Wang’s research was stopped and one official bashed both her and her equipment with a club.

If you’re interested in the full story I encourage you to click the link. If you’re interested in how it relates to you and the organization you work in, read on.

In your career, you’ll run across all sorts of, shall we say, opportunities to improve how things get done around here. Not improving how you and your organization do things, but how other managers and their organizations do whatever they do to accomplish whatever they’re supposed to accomplish.

Some of these will be true opportunities. But some might be opportunities in the sense of the drivelous “there’s no such thing as a problem, only an opportunity.”

The problems probably won’t be as dire as actively spreading fatal diseases. So let’s be less dramatic about it and imagine you’ve discovered a data breach. It hasn’t exposed millions of customers’ credit card information yet … just a few thousand thus far … but the risk of larger losses is, in your estimation, quite real.

You figure your employer will want to eliminate this risk, so you send an email to the managers in the company’s org chart most likely to be in a position to do so, explaining the breach, its root cause, and suggestions as to what a solution might look like.

And … nothing happens, other than your receiving a pro forma email thanking you for being so conscientious.

The question: Why do organizations as diverse as the Chinese government and sadly not atypical large corporations do their best to ignore problems like these instead of fixing them?

Start here: Organizations don’t “ignore” problems, any more than they might be “greedy” or “evil.”

Ascribing these behaviors and motivations to the organization means something quite different from ascribing them to, say, human beings of the Homo sapiens persuasion.

Humans might and often do ignore problems and act greedily. Depending on how a person’s attitudes and behavior stack up against your moral code you might run across the occasional evil villain as well.

But an organization isn’t just like a human being only bigger. It’s different. If an organization appears to ignore a problem, what this means is that its systems and practices aren’t designed to accommodate reporting problems and fixing them.

In many cases organizations are inadvertently (?) designed to conceal, compartmentalize, and in some cases cause problems, as when fixing one would cause a manager’s P&L to go negative, creating one would make it shine, and everyone from the top on down manages to the numbers.

Compounding the metaphorical felony is that someone’s name is on the problem and the practices that led to it. If fixing it would be embarrassing and expensive, well, raises, bonuses, and promotions don’t go to managers who own embarrassing and expensive situations, so relying on luck can be quite appealing.

That’s especially true in the many organizations that consider identifying whose name is on a problem and “holding them accountable” (ManagementSpeak for “punishing them”) to be the essence of root cause analysis.

While it might seem logical that the company would want to fix a problem while it’s still small and manageable, companies don’t want anything. What’s good for the organization doesn’t matter unless it’s good for someone important in the organization.

So when something needs fixing, the first step is asking who, if anyone, will benefit from fixing it.