Tuesday, 05 January 2010 12:34

The Business Analyst’s Guide to Dealing with Difficult Sponsors

Written by
Rate this item
(3 votes)

Part of the challenge that the business analyst faces is the reality of having to serve so many different stakeholders and sometimes being pulled in very different directions.  We're often taught that our sponsor is the person who is the champion of the effort.  Indeed, they are often the one we're to seek out for support and issue resolution throughout the project.  But what do you do when your sponsor is the problem???  As I travel the country and beyond to speak to business analysts, project managers, and team leaders about how to best manage problem attendees in their meetings or deal with difficult team members, I am astounded by how often someone raises their hand to ask, "But what do you do if your sponsor is the problem?" I have to admit that that does pose an interesting dilemma, but it's not one void of strategies you can use to address this not too uncommon problem. Let's explore a few different varieties of the difficult sponsor and see how they can be managed for optimum success.

Sponsor Type 1.

I hope you don't mind me intimidating everyone with my overbearing nature at your team meetings...I'm just trying to help you speed things along J.

Sometimes the problem is getting the sponsor to show up for meetings as requested.  On the other hand, sometimes we're sorry they did show because they become our problem participants and that can be difficult to manage.  Try these meeting facilitation techniques:

  • Meet with the sponsor prior to the meeting and specifically discuss what you need from them in the session.  Possibly write out talking points for them - many will appreciate it if it's offered in the spirit of helping take one more thing off their plate (not telling them specifically what to say).  Ask them to withhold their opinion until others have weighed in to avoid tainting others' input.
  • If you sense others may be intimidated by the sponsor's opinion, suggest the group do a round robin and start at the opposite end of the table to the sponsor (so that their opinion comes near the end).
  • Stand up!  Whenever you stand when everyone else is seated, you immediately regain control of the group (temporarily). Thank the sponsor for their input (even note it visibly) and redirect the conversation as needed.
  • Repeat their point and write it down - this may sound counterintuitive, but oftentimes a sponsor will get on their soap box (and not get off it!) because they don't feel heard.  When you repeat the point back to them and then write it down for all to see (on a flip chart or whiteboard), it reassures them that they have indeed been heard and immediately communicates an appreciation for their point.
  • Ask for solutions - sometimes meeting participants (even sponsors) get caught in a cycle of whining and venting about problems.  After agreeing with the issue (if appropriate or not, offering an opinion if you don't agree), simply ask the sponsor to suggest a solution.  Insist that the issue being raised is important enough to warrant devoting some energy to focusing on a solution.

Sponsor Type 2.

I'm not exactly clear on what I'm looking for, but I'll be sure to hold you responsible when I don't get it...

  • Clarify the effort early and often. Identify in scope items and out of scope items (out of scope is critical), tangible deliverables, timing expectations, budget restrictions, roles and responsibilities, known risks, and key stakeholders.
  • Identify their soap box issue early and emphasize WIIFT (What's in it for them). If they don't understand exactly what they want, ask them to explain their motivation/driving factor. Often, execs have a soap box issue, predetermined bias, or hypothesis they want validated. Try to find out what this is as soon as possible.
  • Ask the sponsor to prioritize cost, time, and scope (good, fast, and cheap). Which is most important (relative to the others)? Hint: The answer is not all three. Think McDonald's - their focus is very intentionally fast and cheap. Be clear which constraints are really driving the project.
  • Explicitly ask how they will define success. Always ask the sponsor to finish this sentence...I will consider this project a success if...

Sponsor Type 3.

Would you please boil the ocean? (and solve world peace too while you're at it J)

  • Try to identify the specific mandatory requirements (and separate the "wants" from the "needs"). Sometimes they will ask for a Porsche when a skateboard will do. Also, there may simply be a knowledge gap and they don't realize that there is a quicker, easier way to get them what they really want.
  • Document your risk analysis. Although we know that virtually all projects encounter problems, we usually spend little to no time analyzing risk before the effort starts. Don't make that mistake! Assemble a few key stakeholders, brainstorm a list of potential risks, then estimate the likelihood and impact of each event. For each risk event, multiply the likelihood by the anticipated impact to quantify the severity. Add the severity of all risk events to determine an estimate of risk for the project. Here's an example:

Risk Event    Probability of Occurrence    Anticipated Impact   Severity

Supplier goes out of business    20% $1M                             $200K

Team loses key resource           75%            $100K                          $75K

Inclement weather occurs          50%            $200K                          $100K

Technology fails                          20%            $500K                          $100K

Total Estimated Risk                                                                       $475K

Check with the sponsor to ensure he or she is comfortable with that level of risk (e.g. $475K in the example above). Also, ask the sponsor to help you come up with a back-up plan proactively (e.g. Jim, I know that if we lose our lead system architect, it will severely impact our timeline.  In an effort to be as proactive as possible, I'd like to find out from you what we can do in the unlikely event thatt does happen?) Even if they insist that you proceed, your having documented these risks will be very valuable to you and the team.  If you are proceeding, work with the team to prioritize risks and identify mitigation strategies and/or back-up plans for the most severe risks.

  • Remember the triple constraint - when they change one element, it impacts the others. If there is a reduction in time, emphasize the impact on cost and scope. (e.g. Jim, I understand that you now need to roll out the new release a month earlier than planned and we can do that, but there will be an impact on cost and scope. I can either reduce the scope and hold off on some of the features until the next release or spend about $50K more to expedite things. What is your preference?)
  • Push back if it's not realistic...(e.g. Jim, I would be irresponsible if I didn't tell you that I don't think this can be accomplished with the level of quality we would expect. I know you would prefer that I be very honest now (before any time and money have been invested) rather than hear a laundry list of apologies after an unsuccessful project. I'd really like to be positioned for success, and I honestly have real concerns here).

Sponsors are supposed to be our protectors and oftentimes they are.  Unfortunately, the difficult sponsor can make an already challenging project excruciating!  Admittedly, dealing with a sponsor is a unique challenge due to the political realities, and there are no easy answers.  Sometimes a difficult sponsor does not respond to reason and helps contribute to a very negative experience for the business analyst.  More often than not, the business analyst is too intimidated to deal with the situation at all.  Don't make that mistake.  Proceed with caution, use tact and diplomacy, be strategic, but do address the issue.  The sophisticated business analyst can indeed manage many stakeholders - even the difficult sponsor!

Don't forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. which owns and operates www.meetinggenie.com, an online resource for meeting facilitation tips, training, and instructional DVDs.  Her latest publications are "Are You Running a Meeting or Drowning in Chaos?" and "5 Secrets to Virtually Cut Your Meeting Time in Half!"  She can be reached at dbrownlee@meetinggenie.com.


Read 29461 times


+2 # Jon Borden 2010-01-05 04:03
I have two edicts I follow as a business analyst: 1. I don't read minds. 2. I don't believe in magic. 1. Project teams, need to clearly define exactly what the purpose of the project phase is. Business objectives and scope. It can't be implied, and shouldn't have to be open to interpretation. 2. Project teams need to clearly define a realistic plan with cost, risk, resources, and so on built in. Just setting an end date and a project budget, and expecting the team to pull a rabbit out of the hat, is not good enough.
Reply | Reply with quote | Quote
0 # Paul Mulvey 2010-01-05 04:11
@jborden - I have experienced the team wanting the BA to pull the rabbit out of the hat on some of the projects that I have been on, and then guess who gets the blame when the project doesn't go as planned? I think that the big "take-away" from the article is to plan the risks with the project team prior to the project getting underway. In my opinion, if this is not done on the project by the PM, the BA should initiate it, and gather everyone together to define the risks. Along with that, the costs that the enterprise/proj ect will realize if those risks turn out to be true.
Reply | Reply with quote | Quote
0 # Jon Borden 2010-01-05 04:27
@pmulvey - I agree that risk management is a key element needed to better meet the expectations of Sponsors. I also agree that if the PM (assuming there is one) does not clearing identify project objectives, risks and constraints, that the BA would be well served by calling out and working to define these with the project team...as the PM and BA are most often held accountable for the project success/failure .
Reply | Reply with quote | Quote
-1 # Michael Drezga 2010-01-05 06:59
He he he the comment about setting an end date and a project budget put a nice smile on my face. Everythi ng can be improved with better management hey!? And BAs should, in theory, never be held accountable for a project's failure! Failure to meet a deliverable yes, the success of the project (or not) is in the hands of the PM fairly and squarely - hence why they get paid more. Expectat ion management, time management, requirements management, risk management, change management, process management and the list goes on and on...and why did I decide to take up the role of a BA? ...I must dig a challenge! Goo d article Dana, at the end of the day everything comes down to human behaviour. In other words humans strive to survive and then thrive. Understand that and the rest is just a process. **Dis claimer: all comments are based on the experiences I have had to date - one unique, filtered representation of reality! P.S. This has inspired me to print off Maslow's hierarchy of needs and stick it on my desk! Go Maslow!
Reply | Reply with quote | Quote
0 # Dennis Nelson 2011-10-26 04:29
The article states the obvious: The better that we are at our professions, the better success we will have with our sponsors, and other stakeholders. Our professions include our soft interpersonal skills as well as our hard BABOK and related skills, and our ability to use those skills to translate communications into hard data that demands prioritizations and other hard decisions. Great article.
Reply | Reply with quote | Quote
0 # Shipra 2013-08-09 00:34
its helpful
Reply | Reply with quote | Quote
0 # John 2016-08-26 05:44
The comments on here as just as interesting and helpful as the article itself. One of the best things that has happened to me in recent times is BAtimes.
Thanks for sharing
Reply | Reply with quote | Quote

Add comment

Security code

© BA Times.com 2016

DBC canada 250