Dealing with Tough Stakeholders as a Business Analyst

When it comes to stakeholders, there is an endless list of different personalities, from the ones who are chirpy and enthusiastic to the shifty types who are unwilling to commit to any actions. 

In this article, I will share my experience and tips on stakeholder identification and analysis, and how I have approached various types of stakeholders.  My experience are derived from various scenarios, from smaller scale Agile projects to large and complex programmes that had found itself overrunning in terms of time and resources.  As one would imagine, organisation-wide morale were low, there were a few ‘know it all’s and individuals working within the organisation with a low penchant for changes seeing that many approaches had been attempted and failed in the past.

The Power of Observation and Finding Common Ground  

As a Business Analyst who just stepped into a complex program, the first step is to examine myself in this context. I applied my usual demeanor of being diplomatic and approachable, performing my usual document analysis and introducing myself to my stakeholders as I mapped out my stakeholder requirements for my exercise.  As I immerse myself into the organization, observing how activities were performed and the conversations that goes on between the individuals, I began to understand the reasons behind negative perceptions on the program.  I started to empathize their circumstances and the challenges they are facing which later became a valuable weapon as a Business Analyst.  Getting into the underbelly of problems helps when one is directly involved in remedying it later on. On occasions where I was a new starter in the program, I saw myself as being in the best position to remove these negative emotions, and this was done by remaining impartial, carefully listening to what the stakeholders had to say and find some common ground in their opinions. 

Using the Relevant Stakeholder Identification and Analysis Tools

Setting foot into a new program environment can be a daunting experience, especially those consisting of multiple vendors and customers.  As a Business Analyst, knowing who I will be interacting with, their roles and vested interests are paramount.  To this end, stakeholder analysis tools such as a stakeholder matrices, registers and the onion diagram are often regarded as frequently used staples in the Business Analysis domain.  This section highlights these commonly used tools that I have used as a Business Analyst to manage stakeholders.

1. Power/Interest Stakeholder Matrix

The famous power/ interest stakeholder matrix is used to examine stakeholders’ specific roles to map the type of engagement requirements which will then help to drive the stakeholder communication approaches.  Stakeholders in this matrix would fall under four quadrants, namely keep satisfied, monitor, keep informed and manage closely.

2. Stakeholder Register

A stakeholder register would provide a more detailed list of names, with their respective roles, positions, organisations (if external to the organisation), requirements, expectations, influence and classification of importance. This tool is the most comprehensive out of the three listed in this article, and would require active management to maintain its relevance.  When kept accurate, I have found this to be an invaluable reference artefact to myself and those joining projects/programs at later stages.  

3. Onion Diagram

Thirdly, another commonly used means of identifying stakeholders in my toolkit is the onion diagram.  A stakeholder onion diagram provides a simple visualisation of stakeholders and their relationship to a project goal  This type of diagram is made of four layers, representing the product/solution, the business system, the business and the environment.

Although this can be applied in any type of projects or programmes, in my experience I found this to be most effective as a standalone tool in an Agile environment, as the teams are often smaller the simplicity of its concept is particularly relevant when focusing on small projects’ goals or sprints. 

The critical success factor in successful stakeholder identification hinges on the level of understanding a Business Analyst has on the project or program environment and knowing which tools to that is best suited to it, as well as using the artifacts in conjunction to others in order to generate some foresight of potential conflicts that may be around the horizon. Any of the tools mentioned above can either be used individually or in conjunction with each other, depending on the complexity of the environment or deliverables.  In more complex scenarios, I saw the need to adopt multiple stakeholder identification tools for a single Business Analysis deliverable. 

Internal vs External Stakeholders

As part of my observations whilst settling into a new program environment, the level of formality and protocols around communications are also taken into account. Lines of communications are typically more direct and less formal when reaching out to internal stakeholders compared to external stakeholders, who may take the form of suppliers, customers, intermediaries, government bodies or the wider public with an interest in output of the program.      

For example, suppliers of the same program may choose to initiate dialogues through the use of defects or requirements management tools to focus communications on specific items and provides a clear communications audit trail, only communicating through emails to request clarification of ambiguities.  Business Analysts can often identify such unwritten protocols through passive observations or by speaking to other internal stakeholders. Recognizing and respecting such protocols tends to be useful during the start of a Business Analysts’ journey in a new program, as this provides an indication of one’s understanding of program-specific conventions.  Depending on the level of rapport between Business Analysts and external stakeholders at later stages of projects or programs, such conventions may change.  By causing disruption to the communications protocols from the get-go may cause resistance and resentment early on in a Business Analyst’s journey under a new environment.

Are Stakeholders Truly ‘Difficult’?

I then started asking why a stakeholder might be called ‘difficult’.  Of course, some just have difficult personalities but others might be acting this way because they feel unheard.  Detective work can only go so far.  Since I was a fresh face in the program, I used the opportunity to be open and hear what the stakeholders have to say, ask the stakeholders questions and even for advice.  A combination of views were heard, from the lack of clarity over expectations, tasks to coordination issues.  I realized that this was all down to the lack of a robust stakeholder engagement strategy, and subsequently a stakeholder engagement plan.  A key stakeholder must be kept in the loop because they need to feel as if they are part of the team.  Many a times due to budget constraints, senior management may not allow the go-ahead for requirements to be implemented as planned.  A stakeholder might not be aware of such situations.  They need to know why a particular requirement is not delivered, or their hostility will heighten.  By establishing a stakeholder engagement plan that provides insights to deliverables, it became noticeable that the mood had shifted. Stakeholders began to understand the rationale of why things are happening and how this impacts the direction of the program.  Some even became more proactive and suggested innovative ideas to cater to constraints.

Escalating Issues through Formal Protocols

For those stakeholders who acted irrationally or point-blank refused to participate, the best course of action was to escalate to their respective managers, whose role consists of evaluating and making decisions on whom will be best suited to participate in the program.  Admittedly,  I have encountered a number of such stakeholders over the years and it is easy to get frustrated.  However, the main takeaway from my experience was to not take this personally. Our roles as Business Analysts consists of identifying specific stakeholder types, not deciding on which particular individual should be on the program. Therefore, if an individual is intentionally not cooperating and bringing negativity into the team, I have learnt to record specific incidents where the issues had arisen and raise these with the relevant individual’s manager in an objective manner. It is the role of the managers to then make the decision on the individual’s future involvement in the program. On some occasions, managers may choose to assign a different individual who may see their new tasks as a new challenge and therefore approach the tasks at hand with a more positive attitude.

Inclusivity and Recognition

Working with stakeholders with positive attitudes makes a significant difference to the morale and overall momentum.  This can be done by fostering an inclusive environment that allows for total open-door communications, therefore allowing for transparency and innovative ideas to materialise. Also, providing as much visibility as possible to my stakeholders assures them that I have captured their inputs into the program artifacts demonstrates that their voices are heard, and the issues will be addressed through the agreed communication channels.  

Celebrating mini-milestones together is a great way to express that stakeholders are appreciated and that we were all working under the same team as opposed to a toxic ‘us versus them’ culture. When solutions are identified and achieved, I had also learned that it was imperative to make the stakeholders feel good about the achievements by explaining how their efforts had contributed in the grand scheme of a large and complex program.   

Celebrating Success Stories and Understanding Common Goals

As programs take more momentum, it became inevitable that certain business functions or work-streams would have fared better than others.  Through holding lessons learned sessions, I was able to identify approaches, tools or techniques that could apply to my other stakeholders.  Creating success stories from the top performers meant that I was able to sell the benefits of a change to the more resistant departments with the help of my stakeholder champions, who were able to offer their own accounts of their customer journey, challenges faced and what approaches were applied to overcome them.  Where there were genuine questions or concerns that no one was able to address, I provided honest answers and held myself accountable for the follow ups. 

The most important thing to remember is that, despite the challenges that they bring, stakeholders also want the program to succeed.  By spending time with each individual, I learned their unique range of emotions benefitted from active learning and coaching to help them reach their own optimal mindset for tackling the challenges at hand.   Projects and programs, regardless of its complexity, can be become successful when everyone is on board and on the same page!