As a business analyst, you need to work with multiple parties on a day-to-day basis. For me, as a business analyst who is exposed to the complete SDLC (Software Development Life Cycle), I work with the product owner, development team, UX team, quality assurance, sales, and customer support team. Then there are the customers of the product that we are building. Most of these involved parties normally fall under the category called stakeholders. Like in any business the stakeholders are highly important in software development environments as well.

Who is a stakeholder

Well if you have studied any business management-related course in the past few decades you must have already heard this definition. This is the definition that I remember from my university days.

A stakeholder is a party that has an interest in a company and can either affect or be affected by the business

This definition was formed more from a pure strategic management perspective and before software development projects were mainstream. When it comes to software development and information technology-related projects the definition is more or less remains the same.

Types of stakeholders

A stakeholder can be anyone who is interested in the software product that is built from within the organization or outside the organization. And there are many different ways of looking at them.

Some look at types of stakeholders in a software development project can be direct users ( those who use the software product being built), principals ( those who fund the software product that is built), internal team (the immediate team that builds the system/ software and partners ( those who enable the system to work in production ex. Dev-ops, operations, legal team, server and hosting services etc.)

This is just one way out of very many ways of looking at stakeholders in a software development environment. There is no right or wrong way of identifying and categorizing stakeholders. But I wouldn’t also go into depth about that, as that’s not my focus here.

For me as a business analyst, the real deal was learning to interact and manage stakeholders.

I would say none of the theories learned in university or other courses didn’t prepare me for that. Initially, I was in an organization where I mostly interacted with the internal team as there were multiple support lines before us and these front lines in most of the cases handled direct users and their issues and passed on the complicated problems which require changes in the core product to the team I was working with. I wouldn’t really see the impact of what was built on direct users immediately as we worked in a lengthy release cycle

But as my role evolved and I came to the phase where my interaction with stakeholders expanded. That was one of the perks of working in a startup culture which I’m grateful for. Even my interactions with internal stakeholders gave me better learning opportunities. I’ve managed to learn heaps and bounds and come across problems ( which can be stressful and annoying then) which helped me to grow.

These are the few things I realized by actually going through situations related to handling stakeholders

Why stakeholder management can be “difficult” sometimes

Before even I begin do let me state that this is not intended in a derogatory manner to anyone. What I try to refer to as “difficult” here would be rather the situation than any person involved. To me, there are few reasons that I personally feel where stakeholders management can get difficult.

Because situations and facts are ever-changing

This is something that comes with the nature of software development projects themselves. Sometimes what you present today to a stakeholder might not be applicable the next day. As you analyze, investigate, develop more and more facts are thrown at you. What you thought was the solution to the problem yesterday might not be a solution at all today.

As a business analyst total new information is thrown at you on a day-to-day basis and communicating this ever-changing flow of information can be difficult.

The most important fact here would be understanding which information is important for whom. And which stakeholders should be involved and exposed to this information. Sometimes if you expose information to the irrelevant stakeholder it can be difficult for both you and the stakeholder at the end.

Because it’s human nature to misunderstand

Different stakeholders can come from different backgrounds. Some might be very much technical and tech-savvy and others can have expertise in different domains. Sometimes they come from different cultural backgrounds and can have linguistic differences. When something has presented the level of understanding that each person will have on the same fact can vary drastically from person to person. Fun fact, when I first moved to Singapore I found it difficult to understand what other person was saying because I was not used to the accent even though the other person spoke to me in English.

When you are a Business Analyst working with all these stakeholders sometimes you might need to first look at your audience and think of the message that you want to deliver and find ways so that you will be clear as possible to everyone in your audience.

I personally find this bit tricky especially when different stakeholders sit in the same meeting. If you go too simple it becomes boring to certain stakeholders who are very technical. If you go too technical some might not get the full picture and it can get uncomfortable later when there repeated discussions on a given topic. When you add language difference on top of this it can become even more complicated.

One way to go about this would be plan ahead based on audience and try to come up with creative ways to present facts.

But this can be tricky and can require investment from the business analyst’s side more. For me, I try to use images a lot in my acceptance criteria and user stories so that I can become clear to the stakeholders to which I’d be presenting in any meeting.

Because feeling important or needed is a basic human need

When certain requirements are analyzed the most recent users of that particular process are mostly involved in requirement gathering and validation sessions. Sometimes there could be secondary users who are not as much as directly involved in elicitation and validation sessions who might feel that they should be more involved. Sometimes these feelings can bottle up and come out later.

It’s always good to understand the history or background of a particular flow before trying to automate the same process using an information system.

This would uncover if there are any resources to be reached within elicitations and validation sessions even though they might not be the direct users of the system once it’s implemented.

But business analyst should be careful enough to cieve and gather what’s relevant and what’s important

While sometimes these secondary users can be hidden gems that can impart the wisdom that can save weeks worth of analysis and development. At the same time, these secondary users can provide outdated misleading information which might derail the progress and create a disconnect from how a process is performed at the moment.

Because it’s natural for us to repel the change

A new system, a new technology introduced can look as if something that’s out to replace you and your job. Also, some users find it a challenge when they have to change the way they performed a certain task for 20 years because a new system came in. Then they repel or become fearful of what’s new and unknown.

But something that I’ve seen is unless it’s very repititive sceario (which are very rare in my opinion) a system can’t completely replace humans.

Rather when the humans work in unison with a system they can add the human touch and provide a superior execution to any task they are assigned with. If users are given a proper interface with the system, it can provide structure and help the lives easier and convenient for the current stakeholders ( given that the system is tailored to the needs of a particular user).

The solution or relevant actions to mitigate this fear I feel depends on many other factors that may or may not be within the control of the business analyst. It depends on the end-users company culture and intentions (which the Business analyst will not have any control over).

But all a business analyst can do in this situation is to interface with the stakeholders better, understand their needs and thinking and make the interfacing with the system as comfortable as possible.

If the interaction between the end-users and system is as streamlined as possible it will be easier to train the users and show them how much can be achieved to make their routines better using the technology involved.

What else can you as Business Analyst do to manage your stakeholders better?

1. Always listen.

Every person has a story, has an opinion. You might not have time to listen to almost every stakeholder. I’m not asking either. but make sure that you identify and narrow down the most important stakeholders depending on the influence they have on your project and listen to them.

If you have a lot of stakeholders around you and if you are confused about whom you should listen to, you can even try to use a stakeholder analysis. This will help you to identify key stakeholders, gain alignment among plans of these stakeholders, and will help address conflict early on.

Stakeholder analysis:https://www.henricodolfing.com/2018/03/a-step-by-step-stakeholder-mapping-guide.html

2. Always understand why.

I personally think no situation has to be difficult. No interaction needs to be conflicting. Sometimes things happen and rather than responding aggressively try to understand where it’s coming from or rather why it happened. This was one of the advices or recommendations given to me when I was starting as a Business analyst, by one of the most senior colleagues that I look up to.

The same can be applied to stakeholder management and business analyst can always try to narrow down or identify the true cause of the true trigger of any conflicts that arise when managing difficult stakeholders.

3. Take time to study the background

Before handling/ managing stakeholders you should try to do your homework as a business analyst. You can try to learn the history of the process/ business, collect reports and data about processes that you are analyzing so that you won’t be just someone coming in from outside trying to change/ disturb the way of working that stakeholders maintained for years.

Change is not something easy for you or me or anyone. But it’s inevitable. And when you change maker and what you do brings changes to many people, knowing the complete picture can help you better to make the change smoothers for your stakeholders and manage them better.