The Business Analyst role in its simplest form is that of an intermediary who uses their mediation skills to secure agreements from two or more parties that would otherwise not collaborate or work together.
Business Analysts will capture end user requirements, review them, and relay them to software developers so that they can turn those requirements into functional software products.
This process has the potential of requirements getting “lost in translation” and the delivery of a product far removed from what end users ordered. This is not as far-fetched an idea as it seems.
How do Business Analysts inoculate themselves from such monumental mishaps? Part of that answer comes down to the use of interpersonal skills as Business Analysts play the intermediary role in the course of their assignments.
Requirements scoping
Interactions with technical teams
Interactions with project stakeholders (end users and project sponsors)
Situations requiring negotiation, persuasion, and influencing
Relationship-Building Skills
The Business Analyst as an intermediary has to be capable of cultivating and maintaining relationships between different project actors. Broken relationships are more damaging than helpful to project delivery.
Emotional Intelligence
This refers to the management of a Business Analyst’s emotions as well as those of other project actors. Thrown into this mix is how Business Analysts manage project actors with empathy, understanding, and intelligence.
Ego Management
Egos are innate to humans, and that’s acceptable. Egos, however, cross into unacceptable territory when they run out of control and and start to pose real harm to the process of project delivery.
Negotiation and Persuasion
An intermediary such as a Business Analyst is not there to play nice; they are there to keep different actors in sync and deliver what is expected of them. This requires a healthy dose of negotiation and persuasive skills.
Collaboration
Software project delivery relies on the different skillsets and expertise of different actors to bring a project across the finishing line; this objective cannot be accomplished by solo actors. Business Analysts need skills that grow and enhance the collaborative ethic required during the project delivery process.
Conflict Management
Given the competing interests, visions, objectives, personalities, and egos on a project, conflicts are inevitable. This is when conflict management skills help with defusing these situations.
Relationship-Building Skills
In order for Business Analysts to achieve goals that involve changing mind-sets or when they undertake wide-ranging business process changes, they need to build healthy relationships with end users, stakeholders, and project team members.
The setup and expectations of software development projects make it virtually impossible to deliver without closely working with end users, stakeholders, and project team members.
Because Business Analysts interact with the same faces for a number of months, there is an acceptance that they have to get to know as well as get along with these same project actors. Anything less than this makes the work of project delivery a long experience in pain management for Business Analysts.
The Importance of Building Relationships
The following are the reasons why building relationships is important for successful project delivery.
Amiable Work Relations
It seems fairly obvious, but we all want to work with people who respect us and who we get along with, and Business Analysts are no different.
Business Analysts who conduct themselves professionally and treat team members, end users, and stakeholders respectfully will find that building amiable relations with these actors comes easily. When Business Analysts create amiable relationships, then the hard work of influencing and changing minds becomes much more manageable.
Situations Requiring Negotiation and Persuasion
Negotiations and persuasion are more difficult and imperiled in situations where relationships are weak or strained between Business Analysts and stakeholders, end users, and project team members.
It may seem counterintuitive, but end users and stakeholders are not always in alignment with Business Analysts where requirements and final product delivery are concerned. In instances where Business Analysts need the buy-in and cooperation of intransigent end users and stakeholders, it helps if the Business Analyst has established some sort of working relationship with these actors.
Business Analysts find it very difficult to deliver these objectives if they have strained working relationships with end users and stakeholders that usually stems from inadequate relationship-building efforts.
Conflict Resolution
Investing in building a healthy relationship will be fully paid back when conflict resolution time comes around. Because a Business Analyst has conducted themselves professionally and depicted positive social behaviors, they can step into conflict situations and defuse them.
They can resolve conflicts because they have healthy working relationships with the conflicting parties, the absence of which makes it a much harder task to achieve.
How Can Business Analysts Build and Maintain Relationships?
Active Listening
A Business Analyst with a known penchant for not listening or ignoring those speaking to him/her will encounter serious difficulties with building relationships.
Championing Stakeholder Needs
This does not mean that all end user requirements will be considered; for instance, it just means that a Business Analyst is genuinely interested in their pain points. Getting pain points and eliciting requirements from end users and stakeholders calls for genuinely and actively listening to them.
When stakeholders and end users are of the opinion that the Business Analyst is working on resolving their problems, then that Business Analyst will have an easy time building relationships with them.
Usually this opinion does not come out of the blue; end users and stakeholders will have seen firsthand the efforts undertaken by the Business Analysts to bring a resolution to their pain points.
Helping end users and stakeholders is not to be conflated with agreeing to their every whim and demand. Business Analysts can respectfully and professionally shelve some requests which garners the admiration and trust of end users and stakeholders that are essential to relationship building.
Professionalism
Treating stakeholders, end users, and project team members with respect and professionalism during moments of disagreements or during the discussion of contentious issues helps build or maintain relationships in project settings. It is the knowledge when to tactfully disagree with stakeholders, end users, and project team members in a way that does not leave them feeling belittled or disrespected.
A common scenario is end users who keep churning out requirements (scope creep). A good response is not to shut them down by saying “Forget it; we are not adding any more requirements” but by letting them know they have been heard and these requirements will be reviewed by the wider team at the appropriate time.
This response engenders respect for the Business Analyst and maintains a healthy rapport with end users instead of leaving them dissatisfied and disrespected at the same time.
Willingness to Learn
Showing vulnerability and a willingness to learn the business and processes of end users and stakeholders softens the barriers to relationship building. Conversely, a Business Analyst who comes off as a “knows it all” to end users and stakeholders is going to have a hard time building relationships with them.
Business Analysts who exhibit “know-it-all attitudes” run the risk of being seen as disrespectful and unwilling to learn so that they can help end users and stakeholders banish their problems.
It’s also probably the worst way a Business Analyst could start off any relationship with end users or stakeholders on projects.
Communication
Keeping everyone in the information loop whether it is good or bad news that they need to know is a good way to build and maintain relationships. As a Business Analyst, eliminating surprises especially preventable ones is guaranteed to build stronger relationships.
It confers an aura of openness and transparency upon a Business Analyst which aids relationship building efforts.
Positive Attitudes
Staying positive even in dark times is a good cultivator of relationships. A negative person with a “the sky is falling” attitude will not win over many stakeholders, end users, and project team members.
It is more useful to fashion practical solutions that help stabilize the project than dabbling in fear mongering and general negativity.
The Business Analyst is there to generate solutions not compound problems, and most end users, stakeholders, and project team members are easier to build relationships with by displaying a positive disposition.
Deliver on Commitments
Business Analysts who deliver on what they commit to will build stronger relationships with stakeholders, end users, and project team members.
The flip side is Business Analysts who fall behind on their commitments or don’t keep their promises engender mistrust, a lack of credibility, and eventually broken relationships.
Emotional Intelligence
How does a Business Analyst respond when a stakeholder or end user says something so untrue or so grossly taken out of context it ends up throwing serious shade at him/her and their requirements?
Chances are they will be outraged, seething, and in the mood to strangle the speaker. How do they respond to this situation? Do they rescue their shredded reputation by immediately putting up a spirited defense of themselves? Assuming that is the chosen path, is there a guarantee that they will decouple their emotions from that defense and maintain the professional demeanor and intelligent response that the moment requires?
That is unlikely.
More likely their defense and emotions will be fused, and what their audience is likely to see is an angry emotive response. Never mind that what appears as an emotive response actually addresses some legitimate points.
There is a second way.
The Business Analyst can wait until their anger has dissipated then offer a response or rebuttal of the factually inaccurate information presented by the stakeholder. For some people, that cooling-down period can be a few minutes, while others may need a few hours to compose themselves and come up with a response.
Guess which approach appears more professional, restrained, calm, and confers admiration upon the Business Analyst in this situation?
The second way is the clear winner here, and it is the essence of emotional intelligence which is defined as the ability to manage one’s emotions as well as handling other people’s emotions and situations empathetically.
Emotional intelligence has upsides like the creation of collaborative spaces that contribute to successful project delivery. On the flip side, actors exhibiting negative emotional intelligence foster a non-collaborative project atmosphere that sooner rather than later jams the wheels of successful project delivery.
Business Analysts who consistently deliver successful projects tend to have high emotional intelligence skills. At the end of the spectrum low emotional intelligence Business Analysts struggle with project delivery especially when it comes to managing and relating with other actors on project teams.
This is how both high and low emotional intelligence is manifested.
Signs of High Emotional Intelligence and Its Impacts
Possessing an abundance of emotional intelligence skills is more than a cherry on the pie for Business Analysts for they manage people better especially during crisis situations. These are the signs of a Business Analyst rich in emotional intelligence.
Self-Awareness and Self-Control
High emotional intelligence Business Analysts are aware of their emotions and know when to restrain themselves. In the above scenario, the Business Analyst would hold eye contact with the stakeholder and let them speak to the end.
They realize that anger or defensiveness (in the moment) will detract from the speaker’s content. That content however ill-conceived still needs to be heard.
Empathy
Business Analysts rich in empathy mentally engage in role-play which is putting themselves in the “shoes” of an actor like a stakeholder. When a stakeholder expresses frustration with, for instance, the requirements scoping process, the Business Analyst actively listens not because the stakeholder is correct but because role-playing enables the Business Analyst to understand the stakeholder’s frustrations.
Perspective and Insight
Allied to empathy is the ability to use deeper perspectives and insights that shine a different light on intractable problems.
That developer who won’t undertake a requirement because it requires learning a new programming language is not afraid of the new language; they are just twitchy about learning and delivering the requirement at the same time. It turns out to be more of a time management issue than an issue about the developer’s abilities. This is the kind of perspective that high emotional intelligence enables.
Curious and Open Minded
Closely tied to the ability to embrace change is the ability to be curious and stay open minded about problems and solutions alike.
Project team members may offer impractical solutions, but high emotional intelligence Business Analysts are curious to hear how the solution will work as opposed to shutting down the discussion saying; “I have heard that before, and it does not work.”
In this instance the proposed solution may not be applicable, but it could be applicable for another problem elsewhere or at another time.
Social Skills
Emotionally intelligent Business Analysts prize social skills because they are the glue that builds relationships and enables them to understand the different dispositions of project team members, end users, and stakeholders.
Positive with a Sunny Disposition
The challenges on projects especially those with tight deadlines, grumpy actors, and fluid requirements to mention a few can dampen the moods of even the most positive project team member.
However, Business Analysts cannot fall prey to this “sky is falling” syndrome which is interpreted as the project will fail regardless of what the project team does.
In a way Business Analysts are the troop leaders, and they cannot manifest a defeatist mentality to other project actors or else those project actors start to exhibit the same defeatist mentalities in their project assignments.
Granted, there will be multiple challenges on a project, but the best Business Analysts know that this is just “another day at the office” and that they will succeed as long as they are focused on resolving the challenges.
The high emotional intelligence Business Analyst also understands that change is a constant and they embrace the changes or enable the changes to be successfully implemented. They prepare for the changes the best they can, keep adjusting, and stay positive despite the challenges.
They keep their eyes on the prize regardless of the storms around them.
Confident and Self-Assured
In addition to a positive disposition, the best Business Analysts are also confident and self-assured about themselves.
They know they will occasionally make mistakes, but they don’t let those mishaps define them. To them it’s just another bad day as long as they do better the following day.
In league with self-assuredness is not holding on to grudges. This is especially relevant in those instances where they have to work with feisty and abrasive stakeholders or end users. Sometimes encounters with these stakeholders go very badly, and Business Analyst may want to “red flag” such actors which eventually harms the relationships.
Ace Business Analysts focus on working with these actors, building functional relationships with them, and learning to treat their prickly personalities as side shows.
Signs of Low Emotional Intelligence and Its Impacts
As humans we don’t always have the right sets of emotional intelligence skills, and the paucity of these skills can make for a bumpy project delivery process. These are the instances of low emotional intelligence in Business Analysts and how they impact the project delivery process.
Poor or Inadequate Emotional Control
We all know folks who lose control, and Business Analysts are no different as sometimes stakeholders and end users can be so irritating that a Business Analyst who loses their cool can be empathized with.
Unfortunately, such irritating moments are not the place nor timing for a Business Analyst to lose control.
Lack of Self-Awareness, Empathy, and Tone Deafness
A lack of self-awareness by a Business Analyst certainly signals low emotional intelligence.
A Business Analyst who has difficulty accepting negative feedback, does not gauge nonverbal cues, and is mainly interested in their opinions is suffering from a serious lack of self-awareness.
Then there are Business Analysts who value efficiency over empathy and will not, for example, hesitate to shut down an end user discussion because the Business Analyst believes the discussion is a waste of time.
This attitude only engenders mistrust, anger, and frustration with the Business Analyst and which in due course damages the collaborative ethic of a project as well as the relationships critical to project success. It’s true that stakeholder discussions may sometimes be repetitive and a waste of time, but there are emotionally intelligent ways of managing this discussion other than just shutting it down in the name of efficiency and time management.
Poor Relationship Management Skills
Like in other aspects of our lives, relationships are cultivated and maintained when we manage them by being emotionally intelligent. A lack of empathy or respect toward stakeholders and project team members for instance is not going to help a Business Analyst build the type of relationships that are essential for collaboration and successful project delivery.
Importance of Emotional Intelligence
Having the right set of emotional intelligence skills is important on software development projects for it helps with effectively managing project actors and crisis situations better which leads to better project delivery outcomes. This is why Business Analysts need emotional intelligence skills.
Builds Resilience
Emotional intelligence helps Business Analysts build resilience that can mitigate and prevent Business Analysts from going into meltdown modes. Resilient Business Analysts know that their requirements will be scrutinized to the point of the scrutiny taking on the appearance of the personal. To them this is just “another day at the office” and not worth having a meltdown over.
Needless to say, episodes that demonstrate a lack of emotional control also demonstrate an unprofessional Business Analyst.
Enhances Nuanced Perspectives
Emotional intelligence equips Business Analysts with nuanced perspectives that are essential in gaining “behind the scenes” insights into challenges that may arise during project delivery.
End users who are not using a newly deployed application are not just rebellious; they are probably skeptical that it will make their work simpler, or maybe they need more training to give them the confidence required for adoption.
Without a nuanced perspective borne of emotional intelligence that considers the end user’s side of the story, the Business Analyst is likely to conclude that the end users are merely rebellious holdouts.
Challenges are seen as opportunities to address underlying problems by, for example, asking if the issue is one of mind-sets, resources, stakeholder support, project scope, or even external factors.
There is usually more than meets the eye with these challenges, and it requires emotional intelligence to understand what’s going on.
Enhances Learning Opportunities from Problems
Emotionally intelligent Business Analysts use challenges as learning opportunities, and they know if they look deeper, they are going to learn why their project has to contend with a stream of never-ending challenges.
Business Analysts focusing on the drama arising from these situations will miss these learning opportunities.
Less Focus on Personal Frustrations
Emotionally intelligent Business Analysts resist the temptation to focus on their feelings of frustration and negativity when the list of obstacles arraigned against a project seem to be never-ending.
Focusing on the negativity produced by constant firefighting is human, but sadly it takes the focus away from the problems and more importantly the required solutions.
Improves Interpretation of Situations and Actions
Business Analysts are no different from us when they handle particularly irritating end users, and some Business Analysts’ default positions may be to mentally and physically shut down such infuriating end users.
While it may be convenient in the moment, shutting down the discussion does not remove the reason why they are irritating in the first place.
High–emotional intelligence Business Analysts “get” that these end users are irritating for a reason. They may a have pain point so bad that being irritating is perhaps the only way of getting a quick resolution.
A healthy dose of emotional intelligence equips Business Analysts to see these situations for what they are: cries for help.
Builds Better Relationships
Another one that does not need to be stated but which will be stated, nonetheless.
Emotional intelligence builds self-awareness which equips Business Analysts with the knowledge they need to cultivate relationships with different project actors.
With this knowledge Business Analysts know which behaviors they need to tamp down or which ones they need to express more as they seek the attention or cooperation of end users, stakeholders, and project team members.
Being emotionally intelligent gives Business Analysts the skills they need to gauge project situations and how to navigate them. Stakeholders being difficult? Maybe it’s best to socialize with them on issues other than just project work.
Perhaps end users and stakeholders share the same hobbies or the same interests as the Business Analyst. These shared experiences create the foundation for building relationships that engender collaboration during project delivery.
Conflict Management and Collaboration Enhancement
This seems obvious but still needs to be stated; low emotional intelligence Business Analysts are likely to engender even more conflicts on project teams by their lack of self-awareness and general lack of empathy.
It’s only natural that a Business Analyst lacking in self-awareness of their destructive personality will find resistance instead of collaboration.
Business Analysts who are emotionally intelligent also take the time to study who they are working with as well as gain social insights into different project actors. They understand what makes some team members produce their best work and what does not and adjust accordingly. This cannot be done without generous doses of self-awareness and empathy.
Enhances Communication and Openness
High emotional intelligence Business Analysts are self-assured of their abilities and understand that what is important is not necessarily their feelings but achieving the wider project objectives.
To that end they prize open communications even when those communications sometimes don’t bring good news. Emotionally intelligent Business Analysts take the perspective that while they may look “bad” in the moment, this is what needs to be done. This attitude builds credibility and trust with different actors on projects.
Helps with Influencing and Persuasion
Ever tried influencing a person who just saw you have an angry meltdown or someone you humiliated in the past but because you were deficient in self-awareness did not even realize what you had done?
Those negotiations will be dead in the water.
Low emotional intelligence Business Analysts have a hard time trying to influence, negotiate with, or persuade other project actors especially if their personalities create avoidable conflicts or damage relationships.
When people are belittled, humiliated, or disrespected, they tend to remember those moments when Business Analysts need their assistance the most.
Helps with Decision-Making
High emotional intelligence Business Analysts remove their emotions when making critical decisions. A Business Analyst who is convinced a stakeholder does not like him or her personally since that stakeholder was asking “embarrassing or difficult” questions is not in the right state of mind to make impartial decisions related to that stakeholder.
Is there a guarantee that this Business Analyst will keep their emotions or “hurt” feelings out of those types of decisions? Of course not.
High emotional intelligence Business Analysts understand that these kinds of decisions are best made by removing emotions from the decision-making process . Bringing that baggage into a decision-making process is unlikely to lead to good decisions.
Recognition of Power Politics
Business Analysts need to be well-equipped with emotional intelligence so that they can discern the “hidden” meanings of project actor actions.
There will be instances when the actions of project actors are meant to “play to the gallery,” engage in power struggles, seek to impress other actors, show who is boss, play “smarty pants,” or generally just being a jerk.
Emotional intelligence is what clues Business Analysts onto these distractions and more importantly gives them the ammunition they need to neutralize them.
The flip side is that a Business Analyst lacking the nuances of emotional intelligence can easily fall for these sideshows and exacerbate their impacts instead of mitigating them.
How Business Analysts Can Improve Their Emotional Intelligence Skills
Emotional intelligence has lately garnered a lot of attention in the business press, and there are countless reference sources that can help Business Analysts improve their emotional intelligence abilities. Nonetheless here are a few tried and tested methods that can just as ably improve emotional intelligence for Business Analysts.
Practicing Role-Play
This is not an easy one, but taking a step back and using role-play or stepping into the “shoes” of end users, stakeholders, and project team members improves the ability to view a situation as someone else. This ability is central to building empathetic abilities, and Business Analysts will be well-served by role-playing as a way of improving emotional intelligence.
Know Thyself
As humans we come equipped with both good and bad personalities, and some of these personality traits are injurious to project collaboration as well as being offensive to end users, stakeholders, and project team members.
Can we avoid being frustrated, angry, or being irritable? Of course not.
The key is being cognizant of the triggers of these behaviors and figuring out remedial measures that temper our darker impulses especially during critical interactions with end users, stakeholders, and project team members.
A Business Analyst feeling flustered and irritated during a meeting with a stakeholder can stay calm and let the stakeholder do the talking as their feelings of irritability subside. By doing this they can respond at precisely the time they are calm while making intelligent and reasoned rejoinders as opposed to responding while carrying the baggage of irritability.
Accountability
Sometimes project situations are so dire that Business Analysts cannot avoid lapsing into low emotional intelligence territory. When that happens the best course of action is for Business Analysts to own it, be accountable for what happened, and endeavor not to have repeat behaviors in the future.
Avoiding accountability and not learning from these experiences virtually guarantees that these behaviors will recur; after all the Business Analyst did not consider what happened worth atoning for.
Active Listening
Business Analysts in the market for improved emotional intelligence abilities ought to start with the low technology and frequently disregarded skill of active listening.
All it takes is to actively listen and leverage role-play to understand the thinking processes of end users, stakeholders, and project team members.
Leverage Social Skills and Self-Awareness
This entails using social skills to understand end users, stakeholders, and project team members, what they like and dislike, or what brings out their best and what doesn’t. It’s all about using self-awareness and social skills to improve emotional intelligence with regard to the actors a Business Analyst frequently interacts with on a project.
Ego Management
Managing egos is a key issue for Business Analysts, stakeholders, end users, and project team members as it can stifle project progress if it isn’t nipped in the bud early.
Ego plays are not to be conflated with the intellectual abilities of any of these actors as these are two different concepts.
Egoism on project settings is essentially putting individual self-centered needs before project objectives, and this is how out of control egos are manifested on projects.
How Are Egos Manifested on Projects?
Denial of Reality
This is when a Business Analyst has difficulty accepting that they are using flawed logic or assumptions during requirements scoping, for instance. They insist on using the same logic even when they have been shown the flaws in this logic.
Hogging the Limelight
Those situations when Business Analysts do all the talking and the audience especially stakeholders or end users are not given the opportunity to meaningfully contribute to discussions.
It is also manifested when Business Analysts want to have a say on every topic of discussion even when they have nothing of substance to contribute to the discussion.
This situation is by no means specific to Business Analysts, and stakeholders are just as guilty of hogging the limelight. For stakeholders it is made worse when they carry the attitude that they are the only ones who can authoritatively discuss requirements or insisting on having all their requirements reviewed whether they are important or not.
Impervious to Change
This is when Business Analysts show themselves incapable or unwilling to learn concepts that will make them change their views or be accepting of new viewpoints. They are inflexible in their viewpoints even when they are presented with new ideas or alternative perspectives.
Having the “Last Word” Syndrome
Business Analysts who want to be right all the time and have the urge to always have the last word on a discussion. This may be further manifested by Business Analysts who are patronizing toward end users and stakeholders working on the notion that the Business Analyst understands end user requirements better than stakeholders.
Lack of Self Awareness
This is when Business Analysts lack the self-awareness that recognizes how their behavior or conduct is inconveniencing or downright discomforting to others in their midst.
Consider a situation where a Business Analyst follows a line of argument during a meeting that everyone can see is flawed. This is a distraction from the purpose of the meeting, and it prevents meaningful discussions from taking place as a result of the Business Analyst’s lack of self-awareness. This is not unique to Business Analysts as stakeholders are just as guilty of this type of egoism.
Personalization of Issues
This is when Business Analysts or stakeholders consider a rebuttal of their ideas or requirements as a personal attack on them.
Self-Centered Stakeholders
This is usually the case when stakeholders treat software products, processes, or applications as their turf and are not fully cooperative or receptive when changes are proposed.
Obviously, this is harmful to project collaboration efforts not to mention that it puts the project at risk of not meeting its objectives.
Effects of Egoism on Projects
Managing egos on a project may be thought of as an insignificant issue, but too many out of control egos on a project can slow down project delivery and here’s how.
Impedes Project Progress
Let’s review a scenario where a Business Analyst is informed that they missed a couple of requirements and that they need to add these requirements to the scope. Alternatively, consider a stakeholder who refuses to sign off requirements that will change their processes because they still believe in the adequacy of the current processes and don’t appreciate the need to change them.
These sound like straightforward scenarios, but in both the egos of both actors have taken center stage, and project progress is stalled because the actors either believe they will “look bad” or they don’t want to give the impression that their processes are inefficient.
Suffocates Communication
Because project actors want to dominate meetings and presentations, the intention of communicating important content is frustrated. This is because the egoists do most of the talking with limited active listening on their part meaning that the audience is given minimal or zero opportunities to meaningfully contribute to the dialogue. These actions inevitably result in a cycle of never-ending meetings seeking this information.
Damages Collaboration
Egoists hell-bent on defending their “turf” or whatever they consider a cause worth defending end up suffocating the spirit of project collaboration, which is essential for project delivery. Who wants to work on requirements that won’t be signed off by an aggrieved stakeholder? Business Analysts certainly don’t relish working with such stakeholders.
Not to mention that these ego turf wars are likely to exacerbate conflicts, create mistrust, and generally poison the spirit of collaboration on projects.
How Can Business Analysts Get a Handle on Egos?
This is how a Business Analyst can control their own ego as well as manage the egos of project stakeholders, end users, and other project team members
For Business Analysts
Openness to New Ideas, Concepts, and Perspectives
Ace Business Analysts understand that they don’t always have the best ideas and usually don’t suffer from “smartest person in the room” syndrome. They recognize that being receptive to other ideas, concepts, and perspectives places them in a better position to understand end user pain points.
Don’t Treat Criticism As Personal
Unless the rebuttal of a Business Analyst’s ideas is directed at them personally or their personal shortcomings, there is no reason a rebuttal or critique of their ideas should be treated as an affront to their person.
While Business Analysts may have difficulty with scrutiny of requirements that dings their egos, this process is necessary to improve requirements and close information gaps.
Self-Awareness
Growing in self-awareness is harder than it sounds but not impossible to achieve. Self-awareness allows Business Analysts to be cognizant of the impact of their actions on their audiences.
Self-awareness can be improved by getting honest feedback from project team members, for example, on how Business Analysts conduct meetings or presentations.
Using Communication Skills
Business Analysts can get a handle on their personal egos by looking out for body language signals during interactions with audiences.
Is the audience bored in meetings? Possibly so and that could be because the Business Analyst is the only one doing the talking. They could be bored because the meeting has turned into a sermon instead of a discussion. Are the audiences tuning out the Business Analyst? Maybe. This could be arising from a Business Analyst high on “smartest person in the room” syndrome.
For Stakeholders, End Users, and Project Team Members
Provide Genuine Feedback
Business Analysts ought to give feedback through Project Managers or Project Sponsors about stakeholders, end users, and project team members with out of control egos. The feedback should be professional and focused on how the egos are impeding the project or stifling collaboration.
Role-Play
As a Business Analyst, dealing with ocean-sized egos can feel insurmountable, but a bit of role-play—putting yourself in the egoist’s “shoes”—can provide insights on why the egoists are exhibiting these behaviors. These insights can then provide avenues of resolving the egoist’s pain points.
Imagine a stakeholder in the grip of “smartest person in the room” syndrome; they have all the answers, and they feel they are the only ones who can discuss a given subject authoritatively. A Business Analyst could ask themselves what the point of all this showboating is. Maybe the stakeholder is seeking public recognition or adulation of their knowledge, or its probable they want to catch the attention of other senior stakeholders.
The Business Analyst can channel this ego to efforts that actually help the project (if it’s within their authority). The egomaniac can, for example, be given an assignment to detail application entity relationship diagrams and thereafter deliver a presentation about their assignment.
This is a win-win situation; the egoist gets to flaunt their ego (plus deep expertise), and the project team members get to benefit from the delivery of new information.
Flag As a Risk
If decisions are being stifled due to egoistical tuff wars, then this needs to be flagged as a project risk. Flagging it as a risk gives the issue visibility and creates opportunities for the turf wars to be resolved in concert with other team members and stakeholders.
Escalation
If end users and stakeholders are the ones exhibiting destructive egoistical behaviors and engaging in territorialism, a Business Analyst has few tools for resolution short of diplomatically escalating the issue to project leadership or organizational management.
Emphasize Project Team Collaboration
Emphasizing the value of collaborative efforts on a project team may not eliminate egoistical behaviors, but it sends the message that “we are in this together.”
It’s a given that project actors will have egos, some more destructive than others, but it’s important to send out the message that the team will deliver results due to collaboration not in spite of it.
It’s OK to have larger than life egos, but they have to check their egos at the door every morning for the good of the project.
Communication Skills and Tools
Active listening, body language cues, and meeting management skills can be used by Business Analysts to rein in destructive egos. By, for instance, setting ground rules for meetings, egos can be controlled, and everyone gets the opportunity to be heard.
When Business Analysts facilitate meetings, they can use nonverbal cues to sense when an audience is out of sync with an egotistical presenter and step in to reset the meeting in real time.
Negotiation and Persuasion
Business Analysts encounter many challenges during the life span of a project that are resolved largely by the use of negotiations and persuasive abilities. These abilities, however, work in tandem with technical skills as well as communication and problem-solving skills to deliver the outcomes that Business Analysts seek.
For the purposes of this book, the skills and powers of negotiation, persuasion, and influencing will be considered as one skill as they achieve the same result: changing the minds and actions of end users, stakeholders, and project team members.
Take a case where end users request a software product but for reasons like budget, time, resourcing, or other unplanned events, a “lite” version of the product is what will be delivered. The delivered product works, but it’s not exactly what the end users requested.
Another variation of this scenario is when Business Analysts scope requirements and ask the technical team to review the requirements. Upon review it turns out that while the product will be delivered eventually, it will be a very complex delivery and will likely be delivered outside the original timelines.
The Business Analyst therefore has to persuade both sets of parties to accept outcomes they had not planned for or envisaged. In the first scenario, the Business Analyst will have to negotiate with end users and stakeholders to accept the delivery of a software product that is different from the one envisioned by the requirements scoping process. In the second scenario, the negotiations undertaken by the Business Analyst will likely center around extending the project timeline so as to deliver the complex product. Obviously, this involves the sticky point of cost implications, and the negotiations have to be done in concert with project leadership.
How Can Business Analysts Master the Negotiation Game?
Prioritizing End User Needs and Requirements
By putting end user needs front and center of the negotiation pitch, Business Analysts put themselves in a better position to have successful negotiations. The Business Analyst can show end users how a product different from what was requested in the requirements will fulfill their requirements and the work-arounds that can be used to meet unfulfilled requirements. This attitude indicates to end users that the Business Analyst literally has their back and they are generally more inclined to go along with the proposals on the table.
Conversely if end users get the impression that the Business Analyst has not given deep thought to how this alternative product will deliver their requirements, those negotiations are going to be difficult if not a downright failure.
End users and stakeholders are usually fearful (and with good reason) of the risks inherent in accepting a product that is different from what they requested. Will their processes become even more broken? Are they getting the efficiencies they need to stay competitive? These are some of the questions that indicate the fears end users and stakeholders have toward what the Business Analyst is selling. It is important for Business Analysts to think through these risks and develop mitigation work-arounds if they are going to have successful negotiations.
Using Trust and Credibility
Would you be persuaded by someone you do not trust? How about conducting negotiations with someone who is not exactly credible based on past interactions with them? Negotiations that Business Analysts have to engage in with end users and stakeholders are no different. Business Analysts who have shown themselves unable to meet their commitments in the past with end users are going to have a hard time during negotiations with them. The negotiations are difficult for the simple reason that end users and stakeholders don’t know if they can trust the Business Analyst given what they already know about him or her.
Moral of the story: keeping commitments and delivering end user needs are what build trust and credibility, and that currency is very vital during negotiations.
Figuring Out Influential Actors
It’s not difficult to figure out who wields the most influence or clout on a team of end users or stakeholders. While it is important to conduct negotiations with teams of end users or stakeholders, it is vital to figure out the person on those teams with the most influence—that person whose “yes” or “no” has the most clout. If the Business Analyst can identify this person of influence and genuinely seek to build a rapport with them, they have an opportunity to turn difficult negotiations into manageable ones. Usually this person of influence can convince the holdouts on the team to accept the Business Analysts’ negotiation points. Think of it as a domino effect: persuade the key players, and they will persuade the other members of their teams.
Preparation for Negotiations
I have observed Business Analysts who prepare for negotiations as if they were preparing battle plans. They anticipate points of contention, possible flash points, feisty or spiky stakeholders, flawed arguments, historical precedents, and many other such morsels of information. It’s not that Business Analysts love the minutiae of who knifed the negotiations last time around; they just want to cover as many of their bases as they can and not leave themselves exposed. This homework is helpful as not only can it get difficult negotiations out of jail but it can also soften stakeholders who can see that the Business Analyst has “thought this thing through.” When a Business Analyst is well-prepared, even stakeholders and end users who are perpetual naysayers find it difficult to turn down well-crafted arguments and counterarguments—unless there are other issues at play behind the scenes.
Product and Solution Confidence
Closely following on preparation is confidence in what the Business Analyst is selling and their knowledge about the product. A car salesman who cannot tell you the mileage per gallon of a car they are selling is either a poor salesman or is uninterested in selling the car or both. It’s the same analogy with a Business Analyst who negotiates with end users or stakeholders who will naturally want to know about the products on the negotiation table. Take, for example, a Business Analyst who tells end users they cannot get their application with five functions, but they will get it with two. As might be expected, end users want to know what the latter option will do for them and more importantly which requirements it will fulfill or not fulfill. This is when it’s not just general product knowledge that is important but knowledge of the proposed solution and the conviction that it is well-suited to the requirements of the moment that is even more important. End users won’t sign off these negotiations if they detect hesitation or a lack of confidence in the product or solution being sold by the Business Analyst.
Communication Best Practices
Difficult and “not going anywhere” negotiations can be turned into success stories by the style of communication. Are stakeholders having a hard time internalizing a 50-page document? How about visualizing parts of that information by using process maps, charts, and diagrams? Is the language too technical? Then the communication needs to be tailored to the audience. Is the Business Analyst doing all the talking and very little listening leading to the audience tuning out the Business Analyst? It’s time to take a back seat and do some active listening. A negotiation pitch ought to follow communication best practices if the Business Analyst is going to get their message through. Keep it simple, stupid (KISS) works wonders in negotiations: keep things simple, no fluff, jargon, or gimmickry.
Enlist the Experts and Pros
It can be tempting to go solo when negotiating with stakeholders given that there is always the payoff of the glory that comes with individually putting difficult negotiations to bed. That said, this is a dangerous strategy that can backfire spectacularly.
Relying on project team members with deeper expertise is a more prudent way to get intransigent end users and stakeholders to accept what the Business Analyst is selling. End users and stakeholders asking painful and unexpected questions can be taken care of by the intellectual heavyweights that have accompanied the Business Analyst to the negotiation table. That’s precisely why the Business Analyst brought them—to bat away those painful questions. The other point is that stakeholders seeing the intellectual muscle arraigned before them get the impression that the Business Analyst takes their business seriously and wants to see them succeed. The experts on a project team can also be called on to validate and check the negotiation proposal before the Business Analysts presents it before stakeholders.
This scenario also works for negotiation scenarios where the project timeline has to be extended which means the stakeholders are likely to fork over more money for the project. In those instances, it’s advisable to bring in the project managers or project sponsors to do the heavy lifting as they have a bigger picture view of project budgets and expenditures, while Business Analyst handle the tactical issues of the negotiations.
The wider point here is for the Business Analyst to know where the negotiation and persuasion efforts are jammed and which expertise to bring in to break the deadlock.
Avoid the Hard Sell
The other temptress that Business Analysts fall for is to try and go for the hard sell; they go into a negotiation room with the intention of leaving the room with pen put to paper—they intend to close the negotiation come hell or high water.
Business Analysts in this situation can be empathized with when schedules are tight and milestones need to be signed off as completed. In such situations, going for the hard sell maybe the only realistic way to get compliance. However, this is usually counterproductive as stakeholders tend to view the hard sell as a sign of Business Analyst or project desperation. They also interpret the effort to get the sign off via the hard sell as overriding their concerns.
If anything, the hard sell is likely to make difficult negotiations even more difficult. In those catch-22 situations, its best for Business Analysts to just lay out the facts, arguments, case studies, best practices, and best of both worlds scenarios and give stakeholders time to make the right call.
If All Else Fails
Sometimes none of these strategies will work however hard or astutely a Business Analyst deploys them, and the only option left is to wheel out the Gatling guns. At this point, the project managers or project champions need to step in and break the deadlock maybe by making a few concessions that are within their remit. However, this is a last resort measure, and it’s best deployed when the Business Analyst has practically tried everything under the sun as well as documented why those actions did not work.
Collaboration
Software product development is centered on self-organizing and matrixed teams that largely rely on collaboration to deliver software products.
If you think this is hyperbole, try envisioning a situation where a Business Analyst delivers a requirement from start to finish without the intervention of developers or test engineers. You don’t have to go far into this mental exercise to see that its impractical simply because it goes against the rationale of using project teams for product development. That rationale is to leverage the different functional roles, skillsets, expertise, and personalities on a project within a collaborative setting to efficiently deliver functional software products to end users.
The teams are matrixed because different roles bring a diversity of skillsets and abilities to a project team. As an example, in addition to the usual crew of developers, architects, and Business Analysts, a project team is reliant on Subject Matter Experts sourced from different departments of the organization to provide expertise toward the project.
Once they are thrown together on a project, the team members have to develop a collaborative ethos that brings out the best in them. Think of it as a pooling of talents, skills, and expertise to serve the wider objective of project deliverables.
Without this collaborative ethos, a project team is made up of individuals who individually cannot deliver project objectives. This collaborative ethic binds the team together, and, in that way, they are an insurmountable force that not only delivers project objectives but also overcomes the usual obstacles and challenges along the way.
It may be tempting to think of building a team collaboration ethic as the responsibility of the Project Matter, but that is a superficial assessment, and Business Analysts are just as responsible for fostering collaboration as Project Managers.
Why Is Collaboration Important for Project Teams?
Problem-Solving Capabilities
Teams in collaborative settings are better suited to confront the myriad challenges that project teams encounter in the software development process. The different skillsets and functional roles can be leveraged to creatively solve problems and sustain project momentum. However, for this to happen, that team has to have already attained a collaborative and cohesive structure. It is difficult to consistently solve problems and remove blockers when team members do not collaborate or where there is zero sense of shared purpose.
Product Delivery
Guess who coined this saying, “Talent wins games but teamwork and intelligence win championships”?1 I will save you the bother; the answer is in the footnote. This sage knows a thing or two about team collaboration and its impact on delivering big prizes. Building a collaborative and cohesive project team is a better vehicle for software product delivery than instructing one person to see the process through from start to finish. Building a collaboration ethic then focuses the team on the bigger picture which is delivering a functional product to end users.
How Can Business Analysts Improve Collaboration on Project Teams?
The spirit of team collaboration and cohesion is compromised where the following behaviors are exhibited by Business Analysts on project teams. The end result is that some team members and stakeholders view themselves as “outside” the project team and don’t see the value of aligning themselves to the mission of the project.
Team Player Leading from the Front
Business Analysts come into this role fully aware that a lot of their work is going to be delivered through teamwork and collaborative efforts. The Business Analyst has to lead from the front by demonstrating that they are team players and that they work collaboratively. If they ask team members to work as a team but they are personally not invested in working with other team members, then the collaborative ethic on that project is weakened. It reminds me of a Business Analyst I worked with once who was quick to bask in the limelight when the project was doing alright but equally quick to blame individual team members anytime things were going sideways. Your guess is as good as mine as to what happened to the collaboration ethic on that team.
Information Sharing
Selective sharing of information harms the collaborative ethic of software project delivery. Business Analysts who provide information to perceived “buddies” while excluding other project team members from this information loop do a major disservice to collaboration on project teams. If there is information concerning project progress, then Business Analysts ought to share it with the project team, and if they must share information selectively, then they have to be open about who will receive what information and why.
If selective sharing of information is not handled this way, the team members who eventually find that information on the “grapevine” will feel like they are not valued members of the team. This is no way to improve collaboration on project teams.
Partiality
Business Analysts will occasionally have to resolve conflicts or disagreements on teams, but they cannot achieve this objective when they take sides. Partiality or its appearance especially during conflict resolution can seriously damage the spirit of collaboration on a project team.
Some project team members interpret partiality as exclusion or favoritism with the end result that they are not invested in the objectives of the project.
Flexibility and Compromise
If a Business Analyst is uncompromising and inflexible in what they demand from team members, they will likely break the collaborative spirit of that team. Life “happens” to team members; they fall ill, go on vacations, or have to provide care for family members. These unforeseen situations put a lot of stress on team members in addition to their project deliverables. A Business Analyst who demands without compromise that an assignment be achieved come hell or high water is setting themselves up as the destroyer of team collaboration.
What should they do in such instances? Seeking solutions with the Project Manager and the concerned team members would be a good first start; riding roughshod over them though harms team collaboration.
Communication Skills
Actively listening to the concerns of team members is a great start just as ignoring them or partially listening to them will not endear those team members to the Business Analyst or the project objectives.
The same goes for nonverbal cues. Business Analysts who miss body language signals from team members signal a lack of interest in what the team members are communicating nonverbally. To other team members, it may signal a lack of self-awareness, empathy, or interest on the part of the Business Analyst in other project team members, all of which damages the collaborative ethic on the project team.
Conflict Management
Conflict on software development projects is generally considered a dirty word with negative connotations. This may be true depending on where you stand but at its heart if it refers to two or more parties who cannot agree on a position in order to move forward with the process of project delivery. Conflicts arise when project actors cannot agree on project strategy, project objectives, problem definition, solutions, budgets, timelines, end user requirements, and project leadership among a host of many other issues that become flash points for conflicts.
Just like in real life, it’s perfectly fine to disagree over issues, and project environments are no different. However, these disagreements become full-blown conflicts when project actors represent entrenched inflexible positions that require intermediaries like Business Analysts to step into and resolve.
The first chapter of this book pointed out that the role of the Business Analyst is that of an intermediary, and conflict management is where this role gets to be played at a deeper level. Business Analysts are largely facilitators in the conflict resolution space during project delivery. Does that mean that Business Analyst don’t get into conflicting positions with other project actors? Of course not. They do have conflicts with other project actors, and those methods in use to triage conflicts between different project actors can also be used to triage conflicts that Business Analysts will be involved in.
Why Conflicts Need to Be Brought Under Control on Projects
Stifles Engagement with Project Goals
Project actors fixated on their conflicts and how to win the next round or stalemate the conflict eventually detract from the goals and objectives of the project. Their conflicts take center stage, and project deliverables take a miserable second place (or worse) in the overall scheme of things.
Slows Project Momentum and Erodes Collaboration
Unresolved conflicts damage the spirit and ethic of collaboration during project delivery. End users and stakeholders start to view each other as contestants instead of collaborators, and without collaboration project momentum starts to stall. Project actors also become defined by the conflicts they are engaged in and start to view other project actors with disdain and mistrust. Under these circumstances, it becomes difficult to decide or support a solution without some project actors viewing it through the lens of the conflict they are engaged in.
Entrenches Positions and Opinions
Much like untreated wounds, conflicts will fester and get worse if not brought under control. Conflicting stakeholders or project team members that don’t see eye to eye harden their positions or opinions, and unless a resource like a Business Analyst steps in to defuse the conflict, the hardened positions become more entrenched and disruptive
How Conflict Resolution Works and What Business Analysts Can Do to Improve This Skill
It’s not something you would wish for your worst enemy, but the more conflicts Business Analysts defuse, the more expertise they garner in the conflict management and resolution space. This is one muscle that mostly grows by application and experience. While other interpersonal skills have clearly laid out avenues by which they can be improved, conflict management is largely improved by taking on and resolving more conflicts. Here’s how Business Analysts simultaneously resolve conflicts and grow their conflict resolution muscles as well.
Knowledge of the Issues Causing the Conflict
While Business Analysts are largely facilitators during episodes of conflict resolution, they have to equip themselves with at least some passing knowledge of the issues that project actors are fighting over. Business Analysts can review who the main actors in the conflict are, what they are conflicted about, for how long it has been going on, and whether there have been similar conflicts in the past about the same issues.
Investigating Underlying Issues
A lot of times, the conflicts between stakeholders or those that exist between stakeholders and projects are signs of deeper underlying issues that may even be unrelated to the project. Maybe the end users feel that new processes will displace them and leave them jobless, they may be scared of learning new skills, or they don’t believe the project will fix their broken processes or systems. In other instances, the feuds are really about departmental control of resources, influence, and power. For Business Analysts looking to step into conflict resolution, the first touch point is checking what the underlying and unsaid issues are and how long they have been at play. Gaining these deeper insights into the causes of conflict puts the Business Analyst in a better position to get a handle on the conflict and resolve it with finality.
Clarifying Implications of Non-negotiable Positions
During the requiring scoping process or even later stages of the project cycle, conflicts will arise when some project components are considered nonnegotiable.
Take the case of a stakeholder who insists they would like all the data in an older application to be migrated to a new application before the new application can be launched to end users. They go so far as to say that this position is nonnegotiable and demand that the project expressly commits to getting this done. This type of demand has the potential to become an intractable conflict and savvy Business Analysts resolve these types of issues by helping the stakeholder understand their demands and the implications. The Business Analyst could, for example, point out the extra costs involved in migrating and managing more data than is necessary or pointing out how fast the application works when it stores only a few years’ worth of data.
Focus on Similarities Instead of Differences
While it may not be prudent to lecture end users and stakeholders about the importance of “oneness” or working together as a team, there are subtle methods that Business Analysts can use that reduce or eliminate siloed thinking. Those same approaches can be applied where “us vs. them” mindsets persist on projects.
As long as the parties in conflict still share the objectives of delivering a functional product, then the conflicts are really about methods and tactics. In a sense they already have more in common than they realize. In the end one product will be delivered, and while there is disagreement on the methods and tactics to get there, it does not mean that the conflicting parties are as different as their conflicts would have them believe.
By focusing on shared objectives, common goals, and points of similarity despite the differences, Business Analysts can reduce demonization of the “other” and create mutual trust, respect, and an understanding of each other’s interests. Focusing on similarities rather than differences—even when they genuinely exist—is a more productive conflict management tool over the life span of the project.
Demystifying Sacred Cows
Conflicts by their nature are tinged with egocentrism or self-centeredness . We tend to think we are right, and the other side has no idea what they are doing, and yet they could just as easily say the same thing about us.
One of the key roles of a Business Analyst in a conflict resolution role is to help show the warring parties each other’s point of view as well as showing them the upsides and downsides of both sets of views. Demonstrating the strengths and weaknesses of entrenched positions tones down what the parties previously viewed as nonnegotiable sacred cows. This action reduces the aura of self-assuredness and self-centeredness that was the key ingredient in fomenting the conflict in the first place.
While it’s difficult to neutralize the egocentrism and self-assuredness that exacerbates conflicts, Business Analysts can demystify these positions and create openings to resolve intractable conflicts by putting the ideas and positions of the egoists under the microscope. The emphasis is to be placed on evaluating the ideas on their own merits with little consideration of how loudly or aggressively an end user or stakeholder pushes those ideas .
Communication Skills
It’s pointless for a Business Analysts to step into a conflict resolution role and then not actively listen to the conflicting parties. It’s the first stop for a Business Analyst looking to get a grasp of both the underlying and surface issues that are brewing conflicts between different project actors.
In the same boat is the application of role-play borne out of emotional intelligence that allows a Business Analyst to get a feel of how both actors view their side of the conflict.
Equally important is for a Business Analyst to successfully facilitate a safe space so that the conflicting actors can have a meaningful dialogue about the issues roiling them and how they can triage them and move forward with project delivery.
Very early in my Business Analyst career, one of my mentors remarked that the Business Analyst practice was more of people management than actual Business Analysis work. At the time I thought it was a sweeping statement that was probably off the mark. Looking back and based on what I have seen, he wasn’t far off the mark, and the need for interpersonal skills demonstrates that point. Without interpersonal skills the management of end users, stakeholders, and project team members is going to difficult, and it eventually impacts that other aspects of a Business Analysts assignments.
Interpersonal skills are a wide subject, and this chapter references those skills that Business Analyst practitioners rely on the most. There are more skills that Business Analysts need to excel at their craft, and one of the key ones is creativity, problem-solving, and analytical thinking to which we turn to next.