In December 1998, NASA launched the Mars Climate Orbiter into space with the goal of studying the Martian climate. But it never made it, at least not in one piece. The spacecraft’s trajectory took it too close to the planet, and when it passed through the upper atmosphere, it disintegrated.
The problem was that two of the engineering teams working on the project used different units: one used SI units and the other used U.S. customary units. Edward Weiler, NASA Associate Administrator for Space Science, commented: “The problem was not the error due to different units. It was the failure of NASA’s systems engineering, in communicating the processes within our teams, to detect the error. That’s why we lost the spacecraft.”
Developing empathy for stakeholders is crucial.
As a digital product designer, I have mostly been working at start-up companies of 30 to 60 people. The communication between my teammates, colleagues and stakeholders was done either with quick catch ups (we saw each other all day) or with regular meetings, since everyone had time for it — the fewer the people the easier.
For me everything changed when I joined a company of 500+ people! It’s a huge leap both from responsibility and stakeholder standpoint. Pair that with the fact that companies at this size tend to be in their Growth state, like MOO where I currently work. It’s simply not enough for an agile product development organization to have a solid design process, create great code and ship features like a clockwork. You also need a good communication strategy, particularly in the beginning of your agile transition so that you educate about the process and get the buy-in from decision makers — something I consider a critical success factor for creating good products.
And the truth is, at the beginning, I was struggling to keep up with managing my stakeholders.
Many times I felt like a pendulum where I was getting conflicting messages and direction from many people with a lot of opinions about what I was doing and even worse from people who, at the end of the day, weren’t the ones to make the final calls.
I had to do something about it.
Thankfully there are many things one can do in order to expand his/her knowledge. First, I started to pick the brain of people I work with and know are good at stakeholder management. One example is the PM in my crew. We had several chats where she offered her tips and experience about this matter in particular — Thanks Laura! Also, I signed up for product management workshops and I made sure that stakeholder management was part of the agenda — thank you Mind the Product! Lastly, I searched Medium — no brainer I know, where I found some very good posts about how other people have dealt with this issue before.
So, did it work? I hear you ask. Definitely!
After 4 months of chatting, attending workshops and reading about stakeholder management, I’ve found those 2 +1 useful techniques/strategies, a Product Designer can use when dealing with stakeholders:
1 — Establish RACI model in your next project
The RACI model (Responsible, Accountable, Consulted, Informed), is a great way to a) manage the opinions of people in a project, b) set the cadence for a well-orchestrated communication strategy c) prevent role confusion and d) mitigate conflict during a project.
Most of the times a RACI model is created at the beginning of a new project/service or discovery piece you as a Product Designer are working on. It is a living, breathing document and should be updated frequently as the project changes over time.
The acronym RACI stands for:
- Responsible: The person who does the work to achieve the task. They have responsibility for getting the work done or decision made. Usually this is one person; in our case it could be you, the designer or a researcher.
- Accountable: The person who is accountable for the correct and thorough completion of the task. This must be also one person and is often the project executive. They are the deciders who approve the final work. So this person might vary depending on the type of the project. It could be the head of design/ VP of product or the PM of your team.
- Consulted: The people who provide information for the project and with whom there is two-way communication. This is usually several people, often considered experts in the type of project you are working on for example, Customer Success/Customer Support, Marketing, Sales, BI, Developers etc.
- Informed: The people kept informed of progress and with whom there is one-way communication. These are people that are affected by the outcome of the tasks, so need to be kept up-to-date. So for example — an informed stakeholder of yours would get email updates from you, but you are not required to respond to every email from them or consider their feedback as critical.
You can establish RACI and involve stakeholders by either holding a workshop and, as a group activity, assign their own roles and inform them all once it’s finalized or you can jump start and assign the roles your self and validate with stakeholder with individual chats.
2 — Mendelow’s power and interest grid
Like the RACI model, the Mendelow’s power and interest grid will help you, as a Product Designer, establish the frequency of communication with various stakeholders that is aligned to each stakeholder’s focus and concerns. This method, like the previous one can also be done in 2 ways. Either as a workshop exercise with a group of people or jump start it by yourself and validate it with your stakeholders later.
Identifying stakeholder power, and interests in the project you are working is essential. Stakeholders are extremely dynamic and may move all over the grid when their interest/power changes.
So a few words on those two factors — interest and power
The level of interest can usefully be described as how likely it is that a stakeholder will take some sort of action to exercise his or her power.
Not all stakeholders have the time or inclination to follow decisions closely.
The level of power is how much impact the stakeholder has from a decision making standpoint. They usually have a high political interest and are powerful enough to either stop work completely or to move mountains to make your project a success.
- High power, highly interested people (Manage Closely): you must fully engage with these people, and make the greatest efforts to satisfy them. These stakeholders are the major drivers of change and are the ones who make the final calls
- High power, less interested people (Keep Satisfied): put enough work in with these people to keep them satisfied. The key here is to avoid involving them too much to the extent that they gain more interest than they initially had.
- Low power, highly interested people (Keep Informed): you should adequately inform these people, and talk to them to ensure that no major issues are arising. People in this category can often be very helpful with the detail of your project.
- Low power, less interested people (Monitor): in this category, stakeholders need to have a high-level idea of the progress of the project without the need for excessive communication. They are more likely than to accept what they are told and not create friction. The general recommendation is:
As a general recommendation: Stakeholders with low power and low interest, should be monitored with minimal effort. Stakeholders with low power and high interest, should be kept informed constantly. Stakeholders with high power and low interest should be kept satisfied and finally you should work very closely with stakeholders who have a high power over the project and a high interest in it.
3 —(Bonus part) Influence & F*cks given. Aka Mendelow’s power and interest grid
I found this great post from Cassie Slack on Medium where she explains in a much more cooler way the Mendelow’s power and interest grid where the X axis is the amount of influence stakeholder have (aka power) over the project and the Y axis is the amount of f*cks given from stakeholders (aka interest) about this project.
Source link https://uxdesign.cc/product-designers-mind-your-stakeholders-74ea9731657c?source=rss—-138adf9c44c—4