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!

I was thinking a lot about how to make your job easier, and it occurred to me that the place to start would be to tell you some of the things that you should be asking from IT.

Fundamentally, every human being wants similar things—Heck, one of my favorite books on software engineering even refers to Maslow’s hierarchy of needs.    Your sponsorship of this project (done well) should help you feel safe, part of a community, build confidence, and bring satisfaction and growth for those involved.

Being a good leader, to a large degree, is to understand that everyone, (IT, Management and Staff) has these similar needs.

So, keeping with the theme of good communication, let’s set a few expectations with IT.

• The IT Team should become highly familiar with the business problem to be solved or opportunity to be addressed; also, who will use the software, and what those people need to have to feel successful. Ideally, the IT teammates sit with the users for at least a day or so, learn how these do their jobs now, and what tools and procedures are currently in place.  In the process, a good IT teammate gets the opportunity to learn cool stuff, such as making guitar pedals , or what is needed to make a safe, clean industrial boiler.

This effort will probably require people to spend time together “IRL” (In real life), or face to face to get the maximum knowledge transfer.  This is difficult in these virtual days.   Try to make it happen—it is worth it.

• You should ask for a plan from IT, before each effort begins. (Readers!  Would it be helpful to you if we provided you with downloadable templates for these plans? Or a checklist you could use?)  Any plan should cover at least a few points:
  • A description of the problem to be addressed or opportunity to be chased
  • Possible options for the solution. (And don’t just accept one answer)
  • A draft schedule for the phase
  • A draft budget for the phase
  • Identified risks, and what preventions or mitigations could be applied
  • A quality assurance plan
  • Recognition of key Non-Functional Requirements (NFRs)

• Your project manager should schedule regular check ins, such as presentations, demonstrations, budget meetings or Steering committee meetings—Especially, make sure everyone involved knows the “No Surprises Rule” rules.

• Yes, you have a right to access any documents, test results, in progress work or demos whenever you want—BUT—you will get the best results when you avoid mistaking documentation for reality. So, work with IT, so that they can button up loose ends, organize their ideas and not waste your time or theirs.

Now, on to one request I have for you as a Business Sponsor (and there will be a lot of others later)

• I need you to be the one to drive acceptance of the business change. I need you to inspire the organization to embrace the change.  We both know the company must be willing to take the risks and learn from any failures.  We all want to be in the culture of innovation and learning—And this is something we can help with in IT, but you need to be the inspirational leader to help others get there.

# # #

Not to be missed on CIO.com’s CIO Survival Guide: “A CIO primer on addressing perceived AI risks.” It’s Bob Lewis’s take on real and perceived AI risks you probably haven’t read about anyplace else.

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.