If you work as a Business Analyst for any length of time, it won’t be long before you encounter stakeholder problems.
First, a quick review on what stakeholders are: individuals or groups who have some kind of stake in (or are affected by) a business solution you’re working on. Stakes are often financial in nature–someone stands to make or lose money from the project. But business objectives, reputations, and technical infrastructure can also be at stake, increasing the number of people at the table.
Given the combination of project complexities and the potential number of stakeholders, problems are bound to arise. The following five stakeholder problems are among the most common you will encounter. I also offer some ideas for solving each problem.
Stakeholder Problem #1: The client whose vision far exceeds his budget
One of the most vexing stakeholder problems a Business Analyst faces is the inevitable client who has big dreams but doesn’t have the money to pay for it all. He wants to implement a major business solution with a lot of features, and can’t understand why the project costs so much. He may try to to negotiate with you to “convince” you that the project can be implemented more cheaply. This client wants it faster, cheaper, and always at a high level of quality.
Don’t let the client negotiate you down. Stick to your guns. One of the most powerful techniques to use in this situation is to identify other projects with similar functionality that your organization implemented previously, and use its actual project cost numbers as a baseline. It becomes much harder for your client to argue with you about numbers when you can show solid evidence that similar features previously cost X amount of money.
Another alternative is to bring technical staff into the discussion to explain to the client why the functionality he is requesting is so difficult to implement. Ultimately the stakeholder must understand that he can’t have it all for the money he has, and must make concessions somewhere.
Stakeholder Problem #2: The client who is never satisfied
You may write perfect requirements and ensure that the development team understands them exactly. You may work long hours to ensure that the project gets delivered on time and on budget. None of it matters for the perpetually unsatisfied client. She will always find something to gripe about. When the developers show her a prototype, she claims it doesn’t have all the features she wants even though they’re not in the current requirements. (She would say the additional features were implied in the requirements even if they don’t state the features explicitly.) Or when you show her the requirements, there’s always something missing. She doesn’t like your time and budget estimates.
Whatever it is, there is a breakdown in the relationship somewhere that the Business Analyst must address.
The first solution to these kinds of stakeholder problems is to try to get into your client’s mind and figure out what’s really bothering her. Often, her gripes really aren’t about you or the development work. Instead, they may be about other hidden pressures she may feel. Does she feel time or resource constrained? Does she feel like the organization doesn’t prioritize her projects? Is her business unit under pressure by the marketplace? Try to figure it out. Once you do, you can focus your energies on directly addressing the underlying pain point rather than put band-aids on the symptoms.
The second solution is to identify whether channels of communication have broken down or aren’t working properly, and fix them. Sometimes a client may just feel that you don’t communicate with her enough, or in the right way. She may feel you are not hearing her, so she vents that in frustration. Every client has a favorite way to communicate; it may be by email, by phone, in person, or something else. Whatever her preferred mode is, make sure you use it. When you do, make sure you squarely address whatever issues she has previously raised with you, as clearly as possible.
Stakeholder Problem #3: Executives that ignore your budget and time estimates
Executives are under a lot of pressure. The buck stops with them when it comes to a business unit’s performance. When an executive says to jump, the expected response is “how high?!”
That’s what makes things so difficult when an executive rejects your budget and time estimates for a project. He may simply disagree with you based on his expertise or that of his senior staff. Or the numbers you provide may just be “inconvenient” for the organization and its strategic plan.
Whatever the case may be, you have one of the most serious stakeholder problems on your hands. This is especially true when the executive is in your chain of command, making escalation to a “higher power” unfeasible. The danger here is that the organization puts the project on an unreasonable timeline and/or on an insufficient budget. If left unaddressed, an “explosion” of non-performance may occur somewhere down the line that can put jobs and reputations on the line.
This problem frankly defies easy solutions, but here are some tips.
First, as in Problem #2, it’s helpful to know the pressures the executives are under. That can help you fashion a compromise solution that may be pared back but still addresses the core need. You can’t say “no” in this situation, but you can say “yes, if…” Often, the 80/20 rule works with software development as it does elsewhere: you can meet 80% of the need with 20% of the work. Executives are pragmatic people, and if you offer them something along those lines it may solve the problem.
Second, try to get more advocates on your side. The more of a chorus an executive hears, the more likely he may agree to a compromise approach. If you have a boss between you and the executive, your boss can be an extra powerful ally.
Third, just accept there are things you cannot change. Instead, document your concerns and recommendations in writing. Depending on the nature of your relationships, you might send that to your boss or to the executive himself. If not, just keep a log for yourself of what you told to whom, when. If something blows up later, you’ll be glad for the extra documentation.
Stakeholder Problem #4: Disagreement about project requirements
Having a disagreement about project requirements is probably the most common of stakeholder problems. Business solutions are often complex things. You may have five, ten, twenty, or more stakeholders depending on how far the solution reaches. They all play different roles in the organization. When you have so many people involved, often with strong egos and different opinions, it can lead to a bit of a circus when it comes to requirements.
Bring your best soft skills to the table. The Business Analyst as negotiator, as mediator, as facilitator, is what is needed to get everyone on the same page. In fact, it’s in this kind of situation where a good Business Analyst can really shine.
Make ample use of stakeholder meetings with carefully crafted agendas. Get everyone who needs to have a voice to the table to hash it out. Point out concerns and inconsistencies that arise in the course of your analysis. Keep everyone on track, and prevent discussions from devolving into arguments that waste time. Take things “offline” (meaning outside of the meeting) when they’re only tangential to the main discussion.
Stakeholder Problem #5: The client with ever-expanding scope ambitions
This is a client who starts small with what he wants. Then, as a result of changing market conditions or increased understanding of the project’s potential, the client starts to want more and more. Features that the client never even thought about suddenly become a top priority. The client may or may not have the money to pay for the additional features, but the real issue here is one of time. If the project has already committed to providing a certain functionality, adding more features can endanger the entire project because of its increasing complexity.
I have previously written about strategies for dealing with scope creep, which you can find here.
How you deal with scope creep may well depend on what kind of software development environment your organization uses. If you are in an Agile environment, then it’s expected that additional requirements and features will pop up over the life of the project. Those features are simply added to the prioritized backlog so that the team can schedule implementation in a future Agile iteration. If you work in a Waterfall environment, however, scope creep that happens after requirements sign off can seriously impact or derail a project, requiring you to move aggressively to contain it.
What do you consider to be the most vexing stakeholder problems a Business Analyst encounters, and how would you deal with them? Leave your thoughts in the comments!