1. Clarify shared goals face to face.
Sitting down with your stakeholders, asking them four basic questions, then documenting their answers is your best defense against scope creep and conflicting priorities.
Sure this seems basic, but fundamentals sometimes get overlooked when you’re getting a lot of conflicting information from various stakeholders who are ostensibly part of a product team. Sitting down with your stakeholders, asking them four basic questions, then documenting their answers is your best defense against scope creep and conflicting priorities. Ask stakeholders the following questions:
- What is the purpose of the product?
- Who is the product for?
- What is the desired outcome of the project?
- Who is responsible for that outcome?
2. Make sure you have a well-defined project scope.
There are times when work is coming at you so fast that you simply cannot produce a requirements document that fully defines scope in a timely manner and get stakeholders to quickly sign off on it. In such cases, you should consider turning feature requests into agile user stories. Alternatively, when you’re really in a crunch, write a brief email message to stakeholders making a request, restating their requests and communicating how you’ll resolve them.
More than anything else, having a well-defined scope is a great shield against take-charge stakeholders who might swoop in at the last minute and disrupt the team’s work by asking for more. Participating in scoping is also a good way for less assertive personalities to learn to push back when requests come in that are unreasonable or would be disruptive to a project. In my experience, just saying something is out of scope is like putting up a brick wall and forces all stakeholders to chill out and negotiate.
3. Stack-rank responsibilities to avoid conflicts.
It is always good to document who is the most important stakeholder at a given point in a project and for what purpose—both so you and your team know who to report to and so you can deflect responsibility for things that are not part of your job description. I prefer the RACI method of identifying roles and responsibilities. This method is very simple and flexible and lets you group stakeholders by whether they are:
- Responsible—The stakeholders who own and must take action to solve a problem.
- Accountable—The single stakeholder who has approval or veto authority and is answerable for the outcome of a project.
- Consulted—Stakeholders who are subject-matter experts and hold information that is essential to the completion of the work.
- Informed—Stakeholders who you must notify once you’ve made a decision or taken action.
There are numerous RACI resources online, so I refer you to them for more in-depth knowledge about this method. However, by understanding the shifting pecking order for a project, you can better anticipate where conflicts may occur and get yourself out of the line of fire.
4. Make sure white elephants are part of the requirements.
White elephants are more strategic requirements that could be costly for you to take on—or even intended to take you down. In any case, handling them requires some advance planning. Sometimes, for the good of the project—and your team’s mental health—you may need to misdirect a demanding, take-charge stakeholder--to prevent him or her from burdening you with a white elephant.
If you are scoping a project and want to be proactive about limiting such a stakeholder’s negative impact on a project, you can create a line item in the requirements that you know the team will take out later—or plan to add a requirement later. This approach can be either additive—adding something that will go into the final product, but isn’t consequential to the overall business goals—or subtractive—planning to take something out of the final product.
5. Take advantage of user stories for stakeholder management.
Working from agile user stories can be a hassle for UX designers if it feels more like you’re designing for the developers than for your users. But they are also fantastic for achieving transparency with stakeholders and for serving as a barrier against too many ad hoc requests. For maximum efficiency, set a reasonable number of user stories to tackle, then post them publicly, along with a progress indicator. I prefer displaying them on a Kanban board, which tends to be both intuitive and informative. But there are a couple of things you should be aware of if you and your UX team go the agile route.
First, if you follow my advice, but you’re still just designing in response to stories, that is symptomatic of over-ambitious expectations or an unrealistic timeline. If either of those things is the case, it is incumbent on you, the UX designer, to put your foot down and renegotiate the backlog deliverables. You also need to know the magic number of stories you can execute during any one sprint. If it’s one story for each of the next two sprints, be upfront about it. Agile focuses on deliverables, not arbitrary deadlines, so take advantage of that!
Second, you will have an easier time of managing stakeholders if you designate time for co-design during at least a couple of early sprints. By designing with other stakeholders, you’ll help build empathy among team members, as well as give them a better understanding of the design process. This will also give more peripheral stakeholders a stake in what is happening right now and encourage the team to execute your designs properly.
6. Never withhold or hoard knowledge.
UX design requires transparency, and transparency starts with you. As a UX professional, you should never withhold any knowledge from your stakeholders. (Of course, this advice applies to more than just stakeholder management.) In the context of this article, I’m referring specifically to the problem of keeping user-research findings in the head of a single researcher who represents the user during team discussions. In his article “7 Deadly Sins of User Research”, Dr. David Travis refers to this issue of hoarding research findings as obscurantism.
The solution is very simple. As soon as you have learnings to present to the team, present them. Even if you just give your team a status update, this will provide an indicator of your progress to the appropriate stakeholders. My personal rule of thumb: if there isn’t anything scheduled on my calendar and it feels like it’s been awhile since I’ve shared learnings with my team, it probably has been.
As I mentioned earlier, I’ve found the techniques that I’ve described here to be extremely useful in getting work done that meets or exceeds my stakeholders’ expectations—as well as in building great relationships with stakeholders.
Of course, you don’t need to use all of these techniques at once. The stage of your work is a major factor in deciding which techniques to employ and which to leave on the table. Please employ these techniques in the ethical spirit I’ve intended.