Working with "Crazy" Stakeholders

We've all been there. You come out of a meeting, walk straight into your colleague's office and say, “Wow, that stakeholder is cray-cray.” Given the number of crazy individuals in the workplace, it's amazing that anything gets done.

But the vast majority of them don't fit any clinical definition of crazy. We have to assume that our stakeholders are mostly rational. So what's the problem?

Problem #1: We don't understand their priorities

The most common of the problems is a lack of understanding of the stakeholder's needs and interests. We Business Analysts are well-versed in our organization's needs, and we're dedicated to finding solutions to them. But how well do we understand the stakeholders themselves? Since any organization can be viewed as a collection of the individuals that participate in it, the better we understand those individuals and their motivations, the better we'll be able to drive change in our organizations.

So how do you overcome this issue? Put in the work required to understand them. Ask them questions and really pay attention to the answers. Some good questions include:

“What are your priorities for the project?”

“What happens if these priorities aren't achieved?”

“What if we achieved [x], but not [y]?”

But they won't tell you everything. People often have motivations that they don't want to voice or that they might not even be conscious of. So pay attention to their actions and their decision-making process. People's actions are generally more informative (and honest and dependable) than their words. Keep an eye on the whole picture, not just what comes across in a conference call or e-mail.

Problem #2: Their needs are in conflict with those of other stakeholders

Another common problem is when you have a stakeholder (or group of them) that has a requirement that conflicts with other stakeholders’ needs, and they simply won’t budge. Their stubbornness can seem irrational or obstructionist, but it’s not – it’s their job to champion the requirements of their function or product, and those needs are important to your organization.

Hands down, the best solution I’ve found is to articulate the conflicting needs in a Stakeholder Needs Analysis. From there, brainstorming and creativity will help you find a solution. The Stakeholder Needs Analysis simply consists of four questions:

1. What does each party say they want?
2. Why do they want that?
3. What is the priority of the need in the mind of the stakeholder?
4. What are the stakeholder’s assumptions, and are they valid?

Usually, in the course of answering these questions, solutions will just occur to you. Be sure to write those down, but also elicit input from other colleagues to make sure you’re creating a good list of alternative solutions. Creative thinking can often get you out of a difficult situation.

Problem #3: They have unrealistic expectations

Unrealistic expectations are one of the more commonly complained-about issues with stakeholders, and there is good reason for that. Stakeholders often don’t understand technical matters, or that features cost money and take time to develop, or that we have to actually test products before we give them to our customers, or that they have to get involved in requirements prioritization, or any of a million other things. I’ll propose a three-point approach to overcoming the dilemma of unrealistic stakeholder expectations.

First, understand them. Expectations come from somewhere. Has the stakeholder's expectation been met by a past employer or another consulting firm? Or does it just seem reasonable to the stakeholder because they don't understand what's involved? Gaining an understanding of the source of the expectation can help you deal with it.

Second, educate them. Sometimes, they just aren't aware that their expectation can't be met within the constraints of the project. This type of education should be given with respect for your stakeholders and their opinions. Convey that their expectation is understandable but infeasible. And let them know that you have an open mind to accomplishing their expectation if you can find a way (and make sure you actually have an open mind, by the way).

Finally, question your own assumptions. Do you believe their expectation is unreasonable because it's always been done another way? Or perhaps because their expectation hasn't been achieved in the past? It’s too easy for us to get stuck in institutional boxes. Before you decide that an expectation is unrealistic, ask yourself why you think so. Is there a technical constraint? Perhaps it can be overcome. Can their feature not be implemented within the project budget? Perhaps they can find additional funding. Is their request outside an appropriate definition of solution scope? Perhaps there is a different project that can better accommodate the organizational need. There is almost always a way of constructively meeting the needs of our stakeholders.

Case Study

To tie this all together, I’ll offer an example from my own (early) career.

One of the smoother projects I ran was for the Marketing team at an investment bank. This was the second project I had run for them, so I thought that I understood them well enough. Nonetheless, I wanted to conduct what I considered to be an experiment at the time: Let’s get them to spell out their priorities and let those priorities drive our decision-making.

I set up a meeting with the project sponsor and her team to discuss priorities for the project. At the start of that meeting, I described the scheduling, funding and scope constraints that we were under and told them I wanted to understand their priorities to help my decision-making process. They had never had a discussion like this before, so I had to guide them each step of the way. I asked them what their priorities were and also asked them to consider things they didn’t mention like software quality and performance.

But what made this a really productive discussion was the very specific line of questioning: “What if we get toward the end of development, and there isn’t time to develop this feature? Would you rather extend the project by a month or go to market without it?” This type of situational questioning helped the Marketing team clearly and accurately articulate their priorities, which we documented and used as fundamental direction for the rest of the project. It also helped them understand that this wasn’t an academic exercise that we were engaged in, that our mutual understanding of priorities would have real implications for the project.

At this point in the project, everyone was happy. But an issue arose during the analysis phase. When we showed them our mock-ups, they disagreed with many graphic design elements and showed us examples of sites that were more in line with their desires. This was great feedback, but the challenge was that the look-and-feel was mandated by the bank’s branding team and wasn’t up for negotiation.

We nonetheless performed a Stakeholder Needs Assessment in lieu of just telling them it couldn’t be done. When we got to the rationale part of the analysis, we realized that we didn’t have one and then asked the sponsor. She said that it needed to be “sexy” before we could put it in front of clients. Since this was to be an internal-only solution, we readily overcame this concern. Problem solved, and everyone was happy again.

That lasted approximately four hours. The sponsor’s boss demanded that the solution be released at the end of the month (within about three weeks instead of seven). We certainly saw this demand as unreasonable, but there was no political appetite to either educate the sponsor’s boss or to push back against him. The sponsor now had a new top priority: meeting her boss’ demand.

So we got back together to talk about what could be done, and we kept the discussion framed around the priorities that we had determined at the beginning of the project. We moved the release date up to number one priority. A couple features dropped dramatically in priority, and we agreed to accept some risk on the solution’s quality (with an agreement for a subsequent release for bug fixes). And then we got on with the project.

And you know what? Everything was fine. We cut out some features that the users didn’t miss. There were bugs, but nothing critical, and we fixed them within a month. What did the sponsor (and her boss) think? They saw us as supremely professional and adaptive. The project was a win for everyone.

So the next time you start to think that your stakeholder is crazy, ask yourself why. Chances are, there is a rational rationale, and it will be up to you to come up with a solution that meets the needs of your organization and your stakeholders.

Subscribe