Stakeholder Management

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.

But What If You’re Not Working in an Agile Shop?

For those of you who are not working in an agile organization, the same principles still apply. You can duplicate this approach with just some minor adjustments. First, I recommend your using some type of tool to track and broadcast your progress. Both Asana and Trello are really good options.

Second, you need to have a basic process that you can reliably replicate to prevent your constantly reinventing the wheel. Treating each situation as completely novel and unique impairs transparency with stakeholders. This would cause them to question the validity of your work—and, in turn, significantly affect both your professional credibility and your ability to advocate effectively for User Experience on your team—and will, ultimately, stress you out!

The solution is to employ Lean UX methods for research, design, and validation. As a designer, if you are not practicing agile UX, learning to employ Lean UX methods is essential. I recommend that you buy the book Lean UX: Designing Great Products with Agile Teams, by Jeff Gothelf and Josh Seiden. (I am not in any way affiliated with Gothelf or Seiden. I simply think that the authors provide one of the most concise, easy-to-follow roadmaps for you to start quickly employing Lean methods.)

Having a solid process in place that UX professionals on your team can follow makes your work infinitely easier once you get the hang of it. I think you’ll find that it’s the difference between being a cog in a machine and providing leadership by example.

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.

Conclusion

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.

I hope you’ll share your thoughts in the comments! Especially if something I’ve suggested hasn’t worked for you, let me know. Maybe we can help each other to think it through.