Skip to main content

Tag: Communication

Lost in Translation: The Perils of Ambiguity in Business Communication

In recent years, I’ve traveled a lot less than I did before the pandemic. One thing this has led to is me seeing processes and practices with fresh eyes. When you travel regularly, the novelty wears off and a sort of ‘autopilot’ kicks in, and a period of not traveling means that everything is less familiar and more open to scrutiny.

I was recently thinking about the questions that are commonly asked when checking in bags before a flight. I can’t even remember if these questions are asked verbally any more, or if there’s some sort of sign or declaration, but there certainly used to be questions such as:

 

  • “Have you left the bag unattended at any time?”
  • “Did you pack the bag yourself?”

 

I suspect, like many people, if you were asked these questions a semi-autopilot would kick in and you’d say ‘no’ without thinking. After all, presumably these questions are aimed at catching smugglers or criminals of some other type. The questions almost seem redundant for ‘normal’ people.

Let’s examine one of the questions, as I think some of the patterns here are important for business and business analysis more generally….

 

What does “unattended” mean?

Let’s take the first question (“have you left the bag unattended?”).  This question is, upon examination, really quite vague.  In fact, I’m pretty sure the actual question airport staff is more specific, but humor me and let’s imagine they ask it in this way.

A first challenge is what the word ‘unattended’ means to one person might be quite different to another.  Take the following situations, do you consider them to mean that the baggage has been left ‘unattended’?

 

  • You’ve just taken a connecting flight and have had to re-check your bags. Your bags have been handled by baggage handlers, and have been left unattended in the hold of the plane
  • You traveled to the airport by bus. The bags were in the baggage compartment of the bus and you didn’t have access to them during the three hour bus ride. There were several stops along the way where passenger bags were loaded/unloaded. Anyone could have accessed your bag at those times.
  • You drove to the airport. It was a long drive so you stopped for gas and a meal. Your car was parked in a car park for over an hour
  • You traveled as a group in two taxis. Your bag was in the other taxi, accompanied by your friends but not you

 

It’s tricky, isn’t it? Technically, if you’ve checked your bags into a previous flight, they have been unattended for a period of time. Yet, you’d likely say ‘no’ to this question… because you know that this isn’t a circumstance that actually counts as ‘unattended’.  I suppose as travelers we intuitively know what’s being asked and what matters. Or at least we think we do…

After all, if we were to literally interpret the question “have you left your bag unattended at any time?” then there is no way that ‘no’ would be a valid answer. Of course it’s been left unattended at some times… when it’s in the closet not being used!

 

Advertisement

 

Beyond Airports: Why Definitions Matter

You probably don’t work in an airport, so might be wondering why I’m obsessing over the wording of a check-in question. This pattern of ambiguity potentially leading to misunderstandings, confusion or (more usually) people making assumptions is rife in organizations and projects too.

Much like the term ‘unattended’ has ambiguity attached, other seemingly ‘obvious’ terms can be problematic. Take the word ‘customer’, it sounds clear, doesn’t it? Perhaps you’ve even written a requirement or user story which articulates what a customer can do.  Yet even such a simple-sounding word leaves room for ambiguity. For example:

 

  • Does someone have to have already bought something to be considered a ‘customer’? Or does the term ‘customer’ include prospects/people in the buying pipeline too? Or do there need to be two terms, ‘prospect’ and ‘customer’?
  • If the person paying for a product/service is different from the person using/benefiting from it, which one is the customer? Are they both customers?
  • Is the term used to mean internal as well as external customers?
  • Are there different customer types? Does a requirement or story apply to all types or only some types of customer?

 

Things can get even more complicated than this. Who is the ‘customer’ of the judicial system, the prison service, and so on. It very much depends on who you ask, which is why it is important to actually ask the question!

 

Definitions Make For Concise Requirements And Stories

This comes back to a key point that is (sadly) often overlooked: definitions matter. A glossary might not be considered a new or exciting artifact, but it can really help ensure people are on the same page. With a clear and shared understanding of key terms, requirements and stories can be more concise.

A small investment in a shared glossary can save lots of time in the long run. Starting early is the most effective way of doing this. And believe me, if you don’t create one, there will come a point in time where you wish you had!

 

 

 

 

Always Ask Why: A Practical Example

I don’t know about you, but I find that I can’t turn my business analysis brain off. I find myself wanting to improve just about every process that I experience, and I often find myself conducting business analysis on the processes that I experience as a customer.

This happened to me recently when a company asked me for a physical ‘wet signature’ on a form. This wouldn’t be unusual if I was in the same physical location as the person requesting the signature, but I wasn’t—they were literally going to email me a PDF form for me to print out, sign, scan in and email back.  Even though Adobe PDF has a signature function (and I have a graphics tablet, so I can literally do the same signature electronically), this wasn’t good enough. It had to be old-school pen on paper. I eventually complied, deciding that I’d rationalize it by calling the process “retro” and “vintage”…

 

Advertisement

 

Badly “Improved” Processes Might Be MORE Risky:

In situations like this, I always want to ask ‘why’ to understand the underlying reasons that things work in a particular way. In this case, if we were to ask why I suspect the underlying answer would be that an old paper process had been replaced, with each step being recreated electronically.  In this context, ultimately, a signature acts as a way of authorizing something to happen.

You can almost imagine the conversation with a group of Subject Matter Experts (SMEs). One of them is adamant that we couldn’t possibly accept electronic signatures. The legal & compliance SME says that electronic signatures are completely valid, but there is reluctance from other stakeholders for other reasons. Perhaps there’s a perception that by getting a physical signature there is less risk… or perhaps there are other reservations.  Some might be genuine, others might be founded on unsubstantiated fears or assumptions.

Left unchecked, there is a risk that ‘we’ll do things the way we’ve always done them, just in an electronic format’.  This can lead to the worst of both worlds where risk is increased and customers are inconvenienced:

 

  • Alternation: I could have altered the PDF before I printed it and signed it (it’s relatively easy to edit a PDF). Unless they check it word-for-word they’ll never know, and since it’s scanned, auto-comparing will be difficult.
  • Verification: They didn’t actually have my signature on file. If they weren’t comparing it against anything, then really what is the point? I could have scrawled any old signature and it probably would have been accepted.
  • Security: Unencrypted email isn’t a secure transmission format. Even though it was relatively low-risk mundane information, it’s liable to interception en route. Plus emails can be spoofed so there’s a risk of a customer being impersonated.
  • Scanners: How many customers have scanners? What about people who just take photos on their phone, will that be sufficient?

 

These are just four examples, but they illustrate a key point: The process probably isn’t achieving what it actually set out to do. Yes, you are getting a physical signature. But if the aim is to get a secure, authenticated nonreputable authorisation for something… then the process is failing!

 

Always Ask Why: “Good” Questions Make A Difference

The key to avoiding situations like this is to ask why, in varied ways, lots of times. Do this and you’ll get to the core purpose of a process, or process step.  In their book “Mastering the Requirements Process: Getting The Requirements Right”, James & Suzanne Robertson call this “The Essence”.  In this example ‘getting physical signature’ might be the current step, but the essence is ‘authorize transaction’ (or whatever).A key point here is that if you understand the essence, you can question any underlying assumptions or business rules. It’s possible to ask “how else might we be able to do this”. If the aim is to ‘authorize transaction’ then there are countless other ways of doing this that are more secure and verifiable than a scanned PDF in an email.  You could even use the Brown Cow model to question any underlying assumptions that have been made.

 

Asking these questions will help encourage stakeholders to think about the true essence of the process, and about how it might change in the future. A half hour discussion now might save tens of thousands of processing time later, once the process is implemented.

This is yet another area where BAs add significant value by helping to ensure things improve in a way that maximizes the benefits that will be delivered both to the organization, and to its customers.

The Art of Communication

Gone are the days when being a brilliant business analyst meant you could hide in a dark room crunching numbers and never utter a single word to another human being. In the realm of business analysis, interpersonal skills have grown to be as crucial as a hot cup of coffee on Monday mornings, and the spotlight is shining brightly on communication prowess.

In today’s dynamic and information-driven business world, effective communication plays a pivotal role in driving success and achieving desired outcomes. For a business analyst, possessing strong communication skills is not merely an option — it is a necessity. As the liaison between stakeholders, technical teams, and project managers, business analysts play a crucial role in ensuring the success of a project.

 

Why Communication Skills Matter for Business Analysts

Effective communication is the foundation of successful business analysis. It enables business analysts to articulate complex ideas and concepts concisely and clearly. By communicating effectively, business analysts can ensure that requirements are accurately captured and understood by all stakeholders, minimizing the risk of misinterpretation, and avoiding costly project delays or failures.

Effective communication helps business analysts build trust and credibility with stakeholders. By clearly articulating ideas, presenting data-driven insights, and actively engaging stakeholders in the decision-making process, business analysts can instil confidence and foster a collaborative and conducive working environment for open dialogue.

Moreover, business analysts often serve as mediators between different stakeholders who may have conflicting priorities or perspectives. In these situations, effective communication becomes even more critical as it helps productive discussions and find mutually beneficial solutions. By creating an inclusive and collaborative environment, business analysts can promote teamwork, consensus building, and efficient decision-making, thereby contributing to the success of projects and initiatives.

Business analysts must also be skilled in active listening, empathy, and building rapport and fostering strong relationships with stakeholders. This helps them gain a deeper understanding of the stakeholders’ perspectives, and uncover implicit needs and concerns, which in turn, allows them to tailor their communication and recommendations that address the underlying issues and drive positive change within the organization.

 

The Spectrum of Communication Skills

Communication skills encompass various dimensions, including verbal communication, written communication, non-verbal communication, and emotional intelligence. Each of these dimensions plays a critical role in the day-to-day activities of a business analyst.

 

Verbal Communication Skills

Verbal communication involves speaking and listening. These skills are essential for conducting interviews, facilitating meetings, and delivering presentations. Proficient verbal communication allows business analysts to articulate ideas clearly, ask relevant questions, and actively listen to gather valuable insights and ensure a complete understanding of the stakeholders’ perspectives.

When it comes to verbal communication, it is not just about the words spoken but also the tone, pace, and clarity of speech. The way information is conveyed can greatly impact how it is received by stakeholders. Effective verbal communication also involves the ability to adapt to different audiences and situations. A skilled business analyst can tailor the language and approach based on the stakeholders they are communicating with, ensuring that the message is understood and well-received.

 

Written Communication Skills

Written communication is equally important for business analysts. Business analysts with exceptional written communication skills possess the ability to organize their thoughts in a logical and coherent manner. It involves creating detailed documents, such as requirement specifications, business process flows, project reports and communicating project updates. Additionally, attention to detail is crucial to ensure that there are no errors or ambiguities in the documentation.

Strong written communication skills enable business analysts to convey complex information accurately and concisely and ensure that all stakeholders are on the same page.

Moreover, effective written communication involves the ability to adapt the style and tone of the message to the intended audience. Different stakeholders may have varying levels of technical expertise or familiarity with the subject matter. By tailoring the communication to suit the needs of each stakeholder, business analysts can ensure that the information is accessible and meaningful to all.

 

Non-Verbal Communication Skills

Non-verbal communication includes body language, facial expressions, and gestures. While often overlooked, non-verbal communication can convey important messages and influence how stakeholders perceive information.

When engaging in non-verbal communication, business analysts must be mindful of their own body language the non-verbal cues. Maintaining eye contact, using appropriate facial expressions, and having an open and relaxed body posture can all contribute to effective non-verbal communication.

These skills are particularly important when conducting interviews or facilitating workshops as being aware of non-verbal cues enables business analysts to detect subtle signs of agreement or disagreement. For example, a nod of agreement or a smile can signal understanding and support. On the other hand, crossed arms or a furrowed brow may indicate scepticism or disagreement. By aligning the non-verbal cues with the verbal messages, business analysts can adjust the communication approach, accordingly, fostering a more collaborative and productive environment.

Furthermore, cultural awareness is an important aspect of non-verbal communication. Different cultures may have different norms and interpretations of non-verbal cues. Business analysts must be sensitive to these cultural differences and adapt their non-verbal communication accordingly to avoid misunderstandings or misinterpretations.

 

Emotional Intelligence

Emotional intelligence is a critical aspect of communication for business analysts. Understanding and managing emotions, both their own and those of others, allows business analysts to navigate conflicts, handle difficult conversations, and build strong relationships. Emotional intelligence helps business analysts adapt their communication style to different stakeholders, fostering a positive and collaborative work environment.

 

Advertisement

 

Mastering Communication Skills as a Business Analyst

While some individuals may possess natural communication abilities, it is a skill that can be continually developed and refined with dedication, deliberate practice, and continuous improvement. Here are some strategies to develop and strengthen the communication abilities as a business analyst:

 

Active Listening Techniques

Active listening goes beyond merely hearing what someone says. It involves fully engaging with the speaker, understanding the message and intentions, and providing appropriate feedback. Practice active listening by providing undivided attention to the speaker, maintaining eye contact, and demonstrating empathy. By practicing active listening techniques, business analysts can ensure an accurate and complete understanding of stakeholders’ needs and requirements.

 

Practice Empathy

Develop your emotional intelligence by actively practicing empathy. Empathizing with stakeholders and understanding their challenges can significantly enhance communication. Understand other’s perspectives and emotions by putting yourself in their shoes, business analysts can anticipate concerns, build stronger connections and offer tailored solutions.

 

Polishing Written Communication

Business analysts often produce detailed reports, requirements documents, and emails. Improving writing skills is crucial to convey ideas clearly and professionally. Avoid jargon and fancy words; use plain language to ensure everyone can comprehend the content.

 

Enhancing Presentation Skills

To deliver impactful presentations, business analysts should focus on structuring the content, maintaining a confident and engaging presence, and utilizing visual aids to support their message. Practice presenting in front of a mirror before presenting it to a larger audience. This technique will help to adapt the communication style to suit the needs and preferences of different stakeholders. Simplify complex technical concepts for non-technical audiences or emphasise key benefits and outcomes for executive-level stakeholders. Tailor the presentations, to resonate the message with the audience and to convey the desired information effectively.

Develop data visualization and storytelling skills to effectively communicate complex ideas and facilitate decision-making.

 

Utilize Technology

Leveraging communication tools and technology can greatly enhance effectiveness as a business analyst. Get familiar with collaboration platforms, project management software, and communication tools to streamline communication processes and ensure efficient information sharing.

 

Engage in Cross-Functional Collaboration

Collaborate with professionals from various disciplines to gain exposure to different communication styles and approaches. This experience will help to adapt the communication strategies to diverse audiences.

 

Be Flexible! Seek Feedback, Learn and Adapt

Interaction with stakeholders from diverse backgrounds and cultures is business as usual for a business analyst. Adapting the communication style to suit different individuals and situations is crucial for effective collaboration. Understand and respect cultural differences, adjust the language and approach, and actively seek feedback from colleagues, stakeholders, and mentors to identify areas for improvement and understand how your communication style is perceived. Flexibility in communication ensures that you can connect with stakeholders on their terms, fostering a more inclusive and productive working environment.

 

The Growing Importance of Interpersonal Skills in Business Analysis

In the evolving world of business analysis, effective communication skills are indispensable for the success of business analysts. By honing the ability to listen actively, articulate clearly, and adapt to different stakeholders, business analysts can be established as an indispensable asset to any organization. As the business landscape continues to evolve, those who master the art of communication will navigate challenges with finesse and lead projects towards triumph. Effective communication is not just about conveying information — it’s about building relationships, understanding needs, and fostering collaboration.

The ability to communicate effectively is the key to unlocking new opportunities and driving positive change in the dynamic world of business analysis.

Remember, even in the world of business analysis, laughter is the best medicine — just make sure you’re laughing with your stakeholders, not at them.

 

Happy communicating 🙂

Best of BATimes: Business Analyst Role in COTS Projects

Many tech companies offer commercial off-the-shelf (COTS) products.

 

Such products allow to meet their clients’ business needs relatively fast, comparing to the development of the new IT solutions from scratch. However, a COTS product for a complex solution such as ERP, CRM, laboratory or hospital information systems requires considerable time and effort to be invested into the configuration. Hence organizations usually involve a separate implementation team of professionals familiar with the COTS product to adapt it for the company’s needs.

COTS vendors normally provide the implementation service to their clients. This can vary from company to company, but oftentimes it includes discovery phase, configuration or customization of the system according to the business needs, user training and making sure the project goes live.

This article describes the BA role in the implementation of the COTS projects and cooperation between a COTS product team and BA from an implementation team.

 

BA in Implementation Project

One might say that COTS projects do not require business analysis since there seem to be no significant development activities. However, COTS projects could vary from completely out-of-the-box to complex solutions with lots of configuration and additional customization (codding) involved. In the latter case we can and shall involve the standard business analysis activities:

  1. Plan your business analysis work. Ask yourself what is your business analysis approach (adaptive vs predictive)? Who are your stakeholders? Do you have a requirements governance process in place?
  2. Requirements elicitation and analysis. This covers discovering the current and desirable states, conducting workshops and interviews, document analysis, etc. Don’t forget to elicit and document any gaps if a COTS solution is not capable to meet some of the business needs.
  3. Requirements modeling. COTS projects normally do not require the complete functional specification since the solution is predefined already. However, there are many other requirement views which can be useful for the configuration project. We will discuss that in the section that follows.
  4. Solution evaluation. Define your KPI and measure if they improved compared to the legacy solution.
  5. Configuration. System configuration is normally out of business analysis scope, but some companies tend to involve business analysts in such activities. In any case, the BA should know how the system works and understand the solution limitations.

 

Requirements Modeling

As mentioned before, it might not be required to document all the functional requirements for the already predefined solution like COTS product. However, not documenting requirements at all could result in certain drawbacks:

  1. Apparently, external stakeholders, like end users, and internal stakeholders, like testing or support teams, will need at least some documentation that describes how the system behaves.
  2. Without modeled requirements, there is no way to validate the requirements before they are actually implemented and the system is demoed for users. What if you only validate your assumptions by demoing already configured piece of functionality? That is right, you will most likely need to reconfigure the system again once you receive the feedback, and then again and again. Nevertheless, you still can present out-of-the-box functionality which doesn’t require any configuration efforts and use it as a starting point to collect the initial feedback from your users.
  3. The change management process can suffer. Imagine that you documented the requirements for the billing module in the bunch of meeting notes, and now 4 weeks after the requirements were implemented the clients insists that some of the billing transactions are not calculated correctly. Would it be easier to refer to the SRS part where all business rules are documented, or try to find the relevant emails?

 

Advertisement

 

To address the above issues, the BA can use a variety of the business analysis techniques which will be applicable for the project and audience. For example:

  1. Roles and Permission Matrix: most of the COTS solutions allow roles configuration and assigning permissions. Start with defining and documenting user roles and their permissions. The organization chart can come in handy to define the roles.
  2. Process Modeling: you can elicit and model the current processes using either the standard notations such as BPMN, UML or come up with a simple drawing which doesn’t follow any notation standard but clear for the audience. The next step will be to review the models with stakeholders, define if anything should be changed in the process and update the model. Once done, you can supplement the model with the additional requirements view, e.g. use cases.
  3. Gap Analysis: as the BA on the implementation project you need to identify the areas in your client’s business which are not covered by the COTS package and address it to the product team. Bear in mind that it is always a good idea to think about the potential workarounds you can offer to the client, before escalating the gap to the product team. That way the client can access the desired functionality earlier, the product backlog will not be overloaded and there will be no need to overengineer the product with the functionality potentially used by only 1 client. So at first always assess if it is possible to configure the system in an alternative way or if the client can agree to do certain steps manually.
  4. User Stories: this is a simple and popular way of specifying the requirements, especially if you follow the agile approach and need to deploy the COTS solution incrementally. It is also quite convenient to prioritize the requirements using the user story form.
  5. Use Case and Scenarios: you can document each separate business flow in the use case. Use cases can easily be converted into the test scripts and serve for validation purposes.
  6. Business Rules Analysis: it is always a good idea to elicit and document business rules. Make sure you have a process in place to update business rules due to external or internal changes.
  7. Interface Analysis: your COTS product will most likely not be used as a standalone solution and will communicate with other components. Define and document interfaces specific to your client.
  8. Data requirements: usually a COTS solution replaces an outdated legacy solution and you need to take care of the historical data. And it is better to define data requirements upfront before you realize you cannot import 256 characters long text into the address column for one of the top customer’s client. Ask yourself the following questions: do you need to import the historical data into your brand new COTS solution? will the legacy data fit the new system? how will you handle the cases when the data doesn’t fit the new COTS product?

 

Provide Feedback to your Product Team

A good way to improve the product is to listen to your user’s feedback. And when it comes to COTS project who is the best candidate to elicit, analyze and document all the client’s concerns and frustrations? Yes, you’ve got it right! It is the implementation BA or anyone else who fulfills this role in an organization. And thus the BA is the one who should establish a process to communicate all business concerns and client gaps to COTS product team.

For example, the BA can create a separate Wiki page per a client where they can list all gaps discovered during the project and communicate them to the product team. The product team can then collect the feedback from all clients, prioritize the gaps for the future releases and share the roadmap with the implementation team.

 

Conclusion

COTS implementation projects can be a challenge for the BA as they differ from the traditional IT development projects. However, with the right attitude and a bit of creative thinking, we can adopt the BA techniques and establish the process which will bring value to the implementation projects and help improve the COTS product.

 

 

 

Published: 2019/08/08

Don’t Deliver a Donkey instead of a Horse

All of us at some point in our life have heard of the children’s game called Telephone Game or Broken Telephone. In this game, Players form a line or circle, and the first player comes up with a message and whispers it to the ear of the second person in the line. The second player repeats the message to the third player, and so on. When the last player is reached, they announce the message they just heard, to the entire group. Very often, the message that comes out at the end is quite different from what the first player had whispered, and this creates a lot of amusement.

Now imagine that same game being played when a project is initiated. In this case, the project sponsor or sponsors may request for a given deliverables at the onset of the project based on business needs. However, after the message gets filtered through many teams, the outcome may not match what was asked for in this first place resulting in a number of unhappy customers or stakeholders. This can be considered as delivering a Donkey when asked for a Horse. The moral of this story is that if there was proper end to end communication, the result would have been much closer to what the sponsor asked for in the first place. Effective Communication is considered as one of the most important aspects of both personal and work life.

 

Business analysts need to effectively gather and convey information between stakeholders, team members, and other parties involved in a project. Clear and concise communication ensures that requirements are accurately understood, objectives are aligned, and expectations are managed. Effective communication fosters collaboration helps in resolving conflicts and ensures that the project stays on track. Some of the key techniques or aspects of communication within the business analysis domain are discussed below. All of them are equally important and need to be considered during any engagement and can be improved through training and constant practise.

 

  1. Active Listening.

Active listening plays a crucial role in business analysis. It involves fully engaging with stakeholders, understanding their needs, concerns, and requirements. This helps the BA to gather accurate and detailed requirement related information, which is essential for making informed decisions and developing effective solutions. Active listening improves collaboration, builds rapport, and ensures that project goals align with stakeholders’ expectations.

 

  1. Interpersonal Communication

Interpersonal communication skills are vital in business analysis because they involve interactions with various stakeholders, each with their own perspectives and needs. Along with the Active Listening mentioned above, building rapport, and empathising with the viewpoint of the stakeholders are crucial for establishing trust and understanding. These skills help business analysts navigate conversations, gather requirements, and address concerns effectively. Related techniques such as Collaborative problem-solving, negotiation, and conflict resolution also rely heavily on strong interpersonal communication. By fostering positive relationships and adapting their communication style, business analysts can facilitate smoother interactions and achieve better outcomes throughout the project lifecycle.

 

  1. Stakeholder Management

Stakeholder management is a critical aspect of business analysis that involves identifying, engaging, and effectively communicating with all parties impacted by a project. Business analysts need to understand stakeholders’ interests, expectations, and concerns. By building relationships and maintaining a clearly defined two-way lines of communication, the Business Analyst can ensure that stakeholder needs are considered throughout the project lifecycle. Effective stakeholder management involves involving the right people, keeping them informed, addressing their feedback, and managing conflicts when they arise. Successful stakeholder management contributes to project success by aligning goals, managing expectations, and fostering collaboration

 

Within stakeholder management, a crucial element to consider is Communication strategy. This has a number of components of its own including  identifying the audience for each message,  understanding the environment or business situation  under which the given project has been initiated, getting a clear understanding of the sponsor vision or objectives , being able to define  what needs to be said to whom and when,  and knowing what are the various ways in which the message can be delivered and feedback received.

 

Advertisement

 

  1. Facilitation

Facilitation is an important technique in business analysis that involves guiding discussions and workshops to achieve productive outcomes. By facilitating meetings, workshops, and brainstorming sessions as per the needs of the project, business analysts can encourage participation, manage conflicts, and ensure viewpoints from all the stakeholders or impacted parties are heard. Facilitation helps in eliciting requirements, prioritizing features and functionality, and fostering collaboration among stakeholders. It also aids in reaching a collective understanding and agreement of the objectives and making informed decisions, leading to more successful project outcomes

 

  1. Business Writing

Strong writing skills are crucial for business analysts as they are responsible for documenting and communicating various aspects of their work. Clear and concise writing is essential for creating requirements documents, project plans, reports, and other forms of documentation. Effective writing ensures that complex deliverables or impacts are accurately and clearly represented to stakeholders, team members, and decision-makers. It also helps in avoiding misunderstandings and serves as a reference for project progress and decisions. Well-written documentation contributes to effective communication, reduces ambiguity, and supports the overall success of business analysis efforts.

 

  1. Presentation Skills

Visual and presentation skills are essential for effective communication in business analysis. They help convey complex ideas, data, and information to stakeholders in a clear and understandable manner. Business analysts often use visual aids like diagrams, charts, and models to represent processes, workflows, and requirements visually. Strong presentation skills enable them to deliver findings, recommendations, and project updates to diverse audiences, ensuring engagement and comprehension. These skills enhance collaboration, facilitate decision-making, and contribute to the overall success of projects.

 

  1. Nonverbal communication

It is often mentioned that over 70 percent of face-to-face communication is Non-Verbal. Nonverbal behavior, such as body language, facial expressions, and gestures, plays a significant role in business analysis. It helps convey emotions, attitudes, and intentions that words alone might not capture. Observing nonverbal cues during meetings and interactions with stakeholders can provide valuable insights into their reactions, level of engagement, and concerns. Being attuned to nonverbal behavior allows business analysts to adapt their communication style, build rapport, and ensure effective collaboration. It also helps in detecting potential misunderstandings and addressing them promptly.

By considering and effectively executing all the above techniques, the Business Analyst is certain to have a much higher success rate in delivering and meeting the needs of the stakeholders

 

  1. Communication Strategy

This can be considered as the overarching technique or approach that is used and includes elements or all the above techniques.