Dealing with multiple stakeholders can bring unexpected problems. Their opinion about solution might not be unified, their very views on the problem could be different and dealing with all of them at the same time can be a rather messy situation.
Majority of projects I work on have multiple stakeholders. Some projects are simpler, some are more complex. One thing they all have in common is that each has its own traps to look out for.
Complex tools – individual points of view
Huge tools with lots of users and different roles will need to have more features to accommodate all of the tasks needed to be done. It gets even worse when there is tons of bureaucracy involved.
Lets imagine that you need to design a tool for hiring employees in big corporation. Here are the steps in the process that need to be followed:
- Fill a request for a role you need to fill. This is most likely done by very low positioned manager or project manager.
- Superiors need to approve this request.
- HR needs to approve this request.
- Budget must be allocated by finance department.
- Other internal tools must be synced with this tool to reflect the changes.
- Reports from database must be generated for higher positioned managers.
There is quite some steps and many roles involved in the process that this tool needs to follow. There is also possibility that some of the tools cannot be synced together and the data will need to be inputted manually by someone. Now this is horrible situation, but it is not so uncommon in corporations.
If you would have a stakeholder from HR, stakeholder from higher management, stakeholder from finance department and some technical architect acting as another stakeholder then you can be sure each of them will have completely different view on the whole concept.
HR will not care about financing the resource, finance will not care about strategy, management will not care about database size and architect will not care about soft skills and hard skills of new candidate.
Each stakeholder will of course believe that their point of view is the most important one. And yet all of them are important and completely unique. It will be up to you to align all of them and design a solution that would tackle all of them.
Things can get out of hand and there can be more dominant stakeholder overshadowing the others and neglecting to listen to their opinions. In this case you will not only need to listen to them all, you will need to persuade this one to do the same thing – to acknowledge others in the process as equals.
I recommend talking to each of them individually and getting their points of view without others interrupting. Gather everything you learn and then present it to the group. Prepare some solutions and arguments for it. At the end of the day, it will be beneficial for them all, if it is not botched work just because they refuse to play ball with others.
Simple tool – distinct implementations
Even simple tool can create problems when you are dealing with multiple stakeholders. It all depends on dominance of the involved parties. When you are just starting and are not as confident as seniors would be, it is easier for stakeholders to take the lead and start designing your product.
Stakeholders designing a product is bad for multiple reasons. The lack the knowledge needed, they are most likely not the users and they will most likely fight over how to design it if there is more of them.
What I can say is that you should always listen to your stakeholders, but that does not mean you have to implement what they want and how they want it without proper reasoning. That part is your job, your responsibility and eventually can be your problem if done improperly.
Present multiple solutions, discuss with stakeholders, but always keep the lead on the design process. If you are not confident enough, get a mentor, ask project manager to help you during presentation. Always keep your feet on the ground.
Meeting with all stakeholders
Meeting can turn into a war zone if it is not managed and equally balanced. This happened to me once when I was facing about 5 stakeholders completely alone and rather unprepared against so overwhelming odds.
Unless you are an expert, do not go into meeting alone against multiple stakeholders. Always make sure you are or have someone who can moderate the discussion. Balance the amount of people who are involved in the discussion.
If you do not have other option than to go into the meeting alone, make sure you can manage the number of stakeholders that will be present. Meet with only one if you are unsure because if you meet with them all, they will destroy you. They will. They like to do that.
As a matter of fairness I recommend following the same rules in opposite situation. Do not bring your entire team to meeting with just one stakeholder. It will be easy to lose control and start picking on the lonely stakeholder.
Conclusion
Even though the art of dealing with stakeholders is something that needs to be practiced over way longer period of time, here were some basic problems I encountered in my first year when I was dealing with multiple stakeholders.
Try to align their views, keep equality in their opinions and expertise, talk to them in private to get all the individual and unique information from them.
Do not let them hijack your design process and start arguing about how to implement it. That is your job. The implementing part, not the arguing part x) Ask for help if you need it.
Your team and stakeholders can be facing against each other when it comes to design and software development. Even the numbers of attendees for each team to not sparkle a conflict where one side will be overwhelmed by the other.
Keep these in mind and it will be easier to deal with more stakeholders. Just do not forget, there are other problems awaiting. The journey is just beginning.
In a situation like this, Lean Canvas style of sync on the expectations is usually very useful.
ReplyDeleteHowever, you made a fair point not to overwhelm either part of the conversation. In a group of people, the one who had most sugar on breakfast usually wins the debate :)