Business Analyst Communication Series Part 1

1. BA Communication Lesson 1 Into: indications is one of the most important skills for a business analyst. Tohave. You've got to master communication in order to be able to elicit the requirements that you need from your stakeholders and subject matter experts. All of the documentation that you create as a business analyst is based on those conversations that you have had in those requirements that you've elicited from your stakeholders and subject matter, experts and sponsors. So in order for the documentation to be correct and to be passed on to the rest of the team in order for them to consume it and use it for the activities that they have to dio, you have to ensure you have good communication skills. One of the things that you have to do is a business analyst is lead the conversation. You want to stop the blank stares and meetings and start getting responses in those requirements sessions. And in order to do that, you have to take control of the conversation so you have to lead it. You need to start leading the conversation, and in this training you will learn about verbal communication, skills, listening filters, the process of effective communication, body language and how that affects communications. Thank you for watching and I'll see you in the course 2. BA Communication Lesson 2 What the IIBA Says About Communication: at the time this video was created. The International Institute of Business Analysis, Babak Version three says that effective communication includes adapting communication styles and techniques to the knowledge level and communication styles of recipients. Effective communicators understand how tone, body language and context change the meaning of words. Gaining an understanding of the terms and concepts prior to the exchange can provide fruitful benefits. Planning. Effective communication includes the sender reviewing the information that is known about the receiver. Differences between the centre and the receivers, such as native language, culture, motivations, priorities, communication, learning and thinking styles may call for specific communication methods. Each piece of information must be carefully crafted and packaged to ensure it is clear and understood when planning to communicate information. The following considerations may be helpful. Consider what the receiver knows or does not know. Structure the information in a logical, comprehensible manner. Determine how to best present the information to convey the intended meanings, for example, using visual aids graphs, diagrams or bullet points and understand the expectations of the recipients. Communication skills. Core confidence sees according to the bad Bach include verbal communication, nonverbal communication, written communication and listening business analysts use verbal communication to convey ideas, concepts, facts and opinions to a variety of stakeholders. Nonverbal communication skills enable the effective sending and receiving of messages through, but not limited Teoh body movement posture, facial expressions, gestures and eye contact. Business analysts use written communication to convey ideas, concepts, facts and opinions to a variety of stakeholders. Let's take this information that we've just covered and get into it in detail in the course . 3. BA Communication Lesson 3 Project Teams and Roles: we're going to look at mastering business analysis communications. The first thing that we're going to look at is an overview of projects and project teams, so types of projects that involve business analysis are things like Web development, new application development, new business development software, package selection, business process, engineering data, warehouse implementation and enhancements to any of those areas. Now let's look at what a project life cycle looks like. Every project progresses through several phases of work, and those phases are looked at as the Project life cycle. We would start with planning the project, then move into scoping the project. And then the next one is the area where the business analyst is really spending the bulk of their time on the project. In other words, doing the bulk of their work. And that's in the Elissa analyzing document requirements phase design a solution builder by the solution. Then we would test the solution. Then it would get implemented and we would conduct a post implementation review. So that's really what the Project Life cycle looks like. Now let's take a look at what happens during each one of thes phases of the Project life cycle So when you're planning the project, that phase involves discovery and documenting what the project is about, right? What are the needs of the business? Why are we doing it? And then also assigning resource is so there could be market research done. There can also be alignment with corporate standards and strategic objectives, and also managing and assigning available. Resource is a scoping of the project would include clarifying the purpose and objectives. Identify the organizational units involved with the project identified people and systems interfacing with the project, determining business processes included in and excluded from the project. It's important to not just identify what's included in but specific things that should be excluded from should also be included in that documentation. Also identifying project assumptions and risks and establishing a system for organizing information. So for the life of the project. So all during the life cycle, the various phases of the project, we need to make sure that we have a standard way of organizing the information, a place where we're storing everything together for the project, so that has to be determined up front as to how that's going to be handled. The next phases of course, that Elissa analyzing document requirements phase that I mentioned was so important to the business analyst. This is where you will do the bulk of your work on a project. You will determine where to find requirements. You'll define an approach for a listening requirements. Is a Jad session good one on one interview sessions, group requirement meetings, surveys? What's the best method to get at the requirements that you need to get? So that's what I mean by the approach. Also identifying and prioritizing the requirements. So once you've to find the approach, of course, then you go and actually do those actions. And then documenting the requirements and documenting the requirements means that you'll be creating several different types of documentation. You may produce process flow diagrams, business requirements, documents, use cases, screen mock ups, report, mock ups or various different types of documentation that you may create functional design documents, entity relationship diagrams, data flow diagrams. There are many different types of documentation to use to include in your what we would call your requirements package. After that, the solution would be designed, so that's typically done by the system architect and maybe db A's lead developer might be involved in that. But the design of the solution would come from the technical team, and during that phase of the project, you would be communicating the requirements to them. You may help in recommending solutions or solution alternatives, but you're not defining what that solution is. During the build of the solution or buying of the solution. There is writing new or modified software, So if we're going to build the solution than obviously, some code has to be written in order to do that right and installing any vendor or purchased software and then writing new procedures and assisting with organizational changes. So you as a B A may come into play in that third bullet point there. With the writing new procedures and assisting with organizational changes, I have sometimes actually delivered training. I've also helped create training documentation, job AIDS, things like that in my role as a B A. Testing the solution. So the most important task of the software tester is to test based on the requirements and then also be able to move out of the box to test what isn't in the requirements during that phase. What's happening is that the software is being verified to make sure that it meets the requirements. We will also be verifying the application looks, feels and acts according to the expectations of the business and, of course, get user acceptance, meaning that there's probably going to be some user acceptance testing done where the stakeholders and the subject matter experts, also known as SMEs, are doing some testing to so on top of the queue, a team doing testing you'll have usually some of the business team also doing testing next phase would be implement the solution. So that's where we actually roll it out into the field, right? It's being rolled out to production. If it's an application that's being used, maybe by multiple locations, and there is a pilot or a soft launch or a pre launch or something like that going on, it could be called different things where maybe it gets rolled out to just one location first and they use it, and some of the bugs and kings kind of get worked out of that, and then we roll it out to the other areas that would require rollout plan where we might be rolling the solution out to various locations, but not all the same time. So you can have what's called a big bang implementation, where you just rolled out to everybody at the same time. Or you can have that multi phased approach of rolling it out. And user training is also delivered during the implementation phase, and then the warranty period gets completed during this phase as well. So that's usually where the project team is continuing. Teoh support any issues or things that get identified in production for a certain period of time. You know, typically, when there's a issue that comes up with an application, a user's contacting the help desk and letting them know that there's an issue during the warranty period that still may happen, calls may still get routed through the help desk. But the issues will be getting rounded to the project team and during that warranty period , so that the helped US staff isn't bogged down with trying to research and resolve the issues that come up right after implementation to production. So your warranty period might be a week. Two weeks could even be six weeks. It just depends on the size and criticality of the project. Then there is conducting the post implementation reviews, so that's a phase in and of itself. During that time, we would be assessing the solution and a listening information for enhancements and also really talking about what went well and what could be improved upon in the next release of that application. So now let's take a look at roles of project participants. So every project AVC involves people that have many different skill sets. And one of the things that clients have told me in the past is that there's so many different names for different roles that it can get a little bit confusing. And unfortunately, there's nothing to be done about that it is absolutely true. And there are different names at different organizations for what would essentially be the same role, right? So we're gonna look at some of those names that belong to different areas, different roles. So the management team could include executive sponsors and account manager, a product manager and a project manager. So any or all of those could be on your project. Subject matter experts. I mentioned those earlier also known a SMEs are, of course, also on your project, and they can be people that are business area experts. They could also be customers, and they could be stakeholders project support personnel. So other vital roles to the project outside of that would be our quality assurance analyst for analysts. Depending on how big the project is, feasibility engineers, facilitators, data administrators and technical writers are technical personnel. Would be people like systems analysts, database designers, Web content designers, technical architects, software developers and network administrators. Now let's look at executive sponsors. Executive sponsors will initiate the project. They also provide funding, and resource is for the project. They're going to make high level decisions about project direction. They'll approve the project scope, and they also ensure that the project goals align with the organizational goals. The account manager or product manager, depending on what they're known as in the organization you're at, defines the overall product requirements. They define the marketing approach to the product, and they'll work with the customer to outline requirements. The project manager identifies and staffs appropriate project team members. They create the project plan and schedule. They monitor the project progress and make adjustments as needed. They ensure the project scope continues to reflect the subject matter. Experts objectives, and they address project barriers. They also manage the change control process and the project budget subject matter. Experts can be inside your organization so they could be employees of it, or they can also be outside the organization. And if they're outside their typically customers or maybe vendors that you're working with The SMEs provide the project objectives, problems and risks set the priorities for business requirements. They get information to the B A about their business and the language that they use in their everyday business. They also provide detailed requirements of business and data and make suggestions about possible solutions. Subject matter experts also assist in besides providing you information there, assisting in other areas as well. So they assistant of finding the project scope requirements, discussions that are in focus groups, facilitated sessions, interviews and meetings. They work with other organizational units to come to a consensus on shared requirements. They help with designing user interfaces and screen design. They also assist with user acceptance testing right. They should be the ones that are actually performing the user acceptance testing, but they're not running it. You is thebe A or somebody from the Q A team is typically running the user acceptance testing. They also will assist in updating employed procedure manuals to incorporate the new solutions so that training documentation and job AIDS we mentioned earlier subject matter. Experts are going to review and assess the requirements, documentation and diagrams, the usability of the software interfaces and the viability of the recommended solution. They're going to make timely decisions about requirements and that you will approve the final solution prior to implementation. So your subject matter experts are really key personnel to the Project Project Support Personnel. We mentioned earlier that there were several roles that fell under here. So looking at the quality assurance analyst who's also known as a software tester, they will review requirement documents. They'll write test plans, set up test environments right, test cases, executing, oversee the testing and report and follow up on defects. The business analyst I want Dimension can also fill the role of software tester on projects , and you may be asked to do that. I've done that on several projects that I've worked on the usability engineer or what might be known as you, I designer will design user interfaces, though, assess user interfaces. Four usability and they will also assist with testing. A facilitator prepares for facilitated information gathering sessions. They conduct the sessions. They work with the business analyst to document the results of the session. Now I have to ask you, who do you think is usually the facilitator off those sessions? It's going to be you. I would like to say that it's going to be somebody else, that you'll always have a facilitator. Teoh basically run your meetings for you, but that's not really the case. You is. Thebe Air typically expected to facilitate the requirement meetings and also document the requirements. Take notes during the meetings and stay engaged in the conversation while you're moving the meeting along and progressing it as well. The data administrator will provide enterprise data model information. They'll provide data naming standards and guidelines, though consult on logical data modelling techniques, and they'll review and approve the logical data models. Technical writers create software manuals, user training manuals, and they also will write online help text. The technical personnel on the team determined how the technology can fulfill the business requirements documented by the business analyst So you is the b A. Are looking at more of the what what is needed by the business and the technical personnel are focused on how to implement what is needed. So some examples of tests that they would perform are things like providing details about design constraints and feasibility of the requirements. They'll design system security system architecture, network architecture, interfaces with existing systems, the design and maintain databases, developed software programs, managed software configurations support the help desk with issues that come up and unit test software programs. So any changes that they're making, they need to unit test it before they pass it along to the Q 18 to be tested, so that takes care of our presentation on projects and project team. 4. BA Communication Lesson 4 What Is Expected of You: in this section, we're going to look at verbal communication skills. What's really happening when you're communicating? The biggest problem with communication is theologian that it actually took place. Somebody's talking. Somebody's listening. That doesn't necessarily mean that you're communicating. Let's look at what we can do to improve that Verbal communication skills are necessary as your position as a business analyst or software tester, or really any other role that you may play on a project team during requirement sessions. It's the business analyst job. Do not only capture the requirements being given, but you're also expected to facilitate discussion about those requirements and take the conversation toe a deeper level. Be a czar, the liaison between the business and the technology team, and it's their responsibility to communicate effectively between those two groups. Let's look at what SMEs expect of you in terms of communication. So in your rolls business analyst, what do they expect? They want you to listen. They want you to be flexible. They want you to understand their business. They want you to be a translator. They want you to put their needs first, be their champion and be open to their suggestions and requests. What else can you add to this list based on your experience? Think about that for a moment and jot down other things that you think belong on this list . SMEs. Are your customers right there getting information from you? You're getting information from them. They are, in effect, your customer. This me expects business analysts to use their language right. They want you to use their language coming from their business area. They expect B. A's to ask good questions to learn about their business. They expect business analysts to organize requirements into clear, concise, understandable written documents and diagrams. They expect business analysts to facilitate and lead requirements meetings. They also expect for you as the B A to present them with suggestions for fitting requirements into existing organizational processes. They expect to receive a solution that meets their needs. They expect business analysts to communicate their needs to the technical team, and they expect business analysts to consistently demonstrate leadership, conflict management, problem identification and solution skills. Now let's take a look at what technical teams expect. They expect from you that you will give them clear requirements. They expect details from you detailed information they expect there needs to be met. First, they expect you to understand code. They want answers. They want you to be their champion, and they want you to be able to translate. Does that sound a little bit familiar? Right? Some of those things are also the expectations from the SMEs. Technical teams are also your customer, and they expect B A's to be familiar with their language. They expect them to be familiar with current technology and understand priorities. They expect business analysts to present the user requirements in clear, concise, understandable written documents and diagrams. They expect the A's to be able to answer detailed questions about exception processing and air handling requirements, and they expect the B A to continue to be involved with the project during the design phase . Answering questions of following up with SMEs so they don't expect you to do your work as a be a elicit the requirements, document them and then walk away and not be available to them. As part of that project team, you are expected to be available to the technical team throughout the life of that project . Now let's look at some barriers to listening perfect communication is when the receiver accurately interprets the centre's intended message. And there are several factors that can influence or interrupt that message. So those factors are called barriers. Tow listening. Some of those things are filters when you're filtering out information when you might have a lack of interest in the topic being discussed. When you have preconceived ideas and thoughts around the topic, when you are thinking of responses during the communication process, I will admit that I am guilty of that. When somebody is talking, I sometimes and formulating a response before they've finished talking. So what does that mean? It means I'm not really listening right, because if I'm starting to formulate a response, part of my brain is now focused on that. So I'm not truly listening at that point. And then finishing statements for others is also a barrier tow listening. It 5. BA Communication Lesson 5 Things That Affect Your Ability to Listen: Now let's take a look at listening filters. When we're processing information, our brains process each new piece of information through filters that have developed since childhood. Typically, we're not aware of the influences that personal filters can have unintended messages. In other words, your subconscious is affecting how you process information. Take a look at the following list. Any and all of these things can affect how you process new information. Memories, beliefs, attitudes, strong feeling, expectations, assumptions, values, interests, past experiences, images both past and present images, fiscal, environment and prejudices. To improve your communication skills, recognize your own filters and their effect on your listening. Be aware of the filters of others also, and aware of the impact that that that those filters have on messages. Let's look at a lack of interest. Lack of interest by the listener is interpreted by the speaker as a lack of interest in them. As a person listening is committing, decide you will get something of value out of every conversation. Once you determine why you are not interested, you can correct the problem. So think about a few things. Are you feeling ill or tired? Are you distracted by unrelated personal or work problems. Are you hungry? Those things can make you feel not interested, right? They could be dragging your attention away. And have you focused on other things. Preconceived ideas and thoughts. Preconceived ideas and thoughts are almost always present. When you're dealing with a familiar topic or person, think of anything that is familiar to you. You will not be able to not have a preconceived idea about it, right? If you already have familiarity with it or experience with it, you're going to have preconceived ideas about it. So the tendency is to selectively listen for what you expect to hear. We naturally screen out things that don't meet our expectations, so we don't even realize that we're not hearing it because we're filtering it out without even knowing it. So prior Topic knowledge can have some benefits, and those benefits are things like. It helps you to formulate intelligent questions on the subject, and it also may facilitate communication. If you understand the language of the communicator. However, there are some hindrances to prior topic knowledge as well, and that's that you may not reconfirm specifics that you believe you understand right if you're the listener and you're already familiar with a topic. There may be some things that you're thinking. Yeah, I know how this works or I know this or I know that and because you think you know it, you don't ask about it, and then you may not probe. Define differences between this specific situation and the one in which you're familiar with, right? So there could be some variables, but you won't even be looking for them. Keeping an open mind is critical to eliciting requirements that are clear and complete. You can't let that prior knowledge hinder you from asking questions and being open to new ideas. Thinking of responses during the conversation. An accurate response to a speaker's message is a response to his or her or total communication. A shared or common topic of a discussion may trigger thinking of a response during the conversation. The formulation of that response in your mind causes you to lose the rest of the discussion because you're no longer focused on it. So trying to stay open until you hear the entire thought that's coming from that person and then paraphrase back to them what they said to be sure you heard it all. And if you think that you're having trouble with that, if you know that you were having issues with thinking about responses during conversations , try taking notes whenever you can do that, because taking notes helps to keep you focused on what's being instead. Rather than starting to think of responses, finishing statements for others will diminish their desire to communicate. They don't want to continue to talk to you if you're going to consistently interrupt them and try to answer or try to finish their statements for them. So try these things for breaking that habit. Listen for periods and question marks. Every verbal message contains what we call audible punctuation. So wait for those pauses to compose an appropriate response rather than interrupting them mid sentence. Drink water if your mouth is full. If you're drinking something, then you can't talk right that will help you do not speak up. If you find yourself getting ready to do that, take a drink of water so always keep a bottle or a glass of water with you, count to three. So again you find yourself getting ready to interrupt. Somebody count to three and even after they finished talking count to three. That gives you a chance to make sure that the person is actually finished talking and will allow you to gather your thoughts to formulate a better response as well. Use gestures, eye contact and nodding of your head to help the speaker get to conclusion right. Let them know that you are listening, that you do understand by using those gestures. Are you a good listener? Analysts that are good listeners should demonstrate great flexibility and resolving disagreements and conflicts. Make decisions based on a solid foundation effects and data, and avoid reactionary shoot from the hip conclusions. They should participate intelligently and effectively in conversations, be motivated to learn, practice and reinforce their active listening skills. Display high self confidence and self assurance. By listening effectively, he is focused on their communication partners message as they are on their own. So again really paying attention and listening to what the other person is saying. And you should be able to successfully control those listening barriers that affect your reception of the message that's being told. You also want to make sure that you use first names of people meetings when you're talking to them and make sure that you maintain eye contact. Maintaining eye contact does not mean staring at somebody, right? It's You have eye contact, you look away. You look back again. But also using their name is really powerful in keeping their attention as well. 6. BA Communication Lesson 6 Your Style of Communication: Now let's take a look at the process of effective communication. So the process really consists of three areas. Sending and understanding the message, acknowledgement of the message and then response and feedback. So we're gonna take a little bit of a deeper dive in descending and understanding the message where we look at each of the things that you see here on the screen related to that which is word context words to avoid avoiding provoking words, tone of voice and voice, inflection, eye contact and physical spacing, body language and method of delivery. Then we'll take a look at acknowledgement and then the things related to response and feedback, which are paraphrasing, mirroring open ended questions and empathy statements. So let's start with word context. Speaker selects the words for communicating based on his or her understanding of the specific words and phrases. The meaning of any message is determined solely by the receiver. It is not the actual content of the message that matters. It is what the listener thinks. You said. Some words can have as many as 25 different definitions in the English language. Cultural, religious and regional backgrounds can influence the interpretation of a word. Some words can even stirrup an emotional response. Leading toe a breakdown in communication. There are some red flag words that you should avoid using things like you should or you must. You'll never. Why don't you? You never For you always You're wrong. The words on the left of this table that you're looking at here are ones that can cause a negative response and hinder communication. So look at other words that you can use in place of those so provoking phrase would be camped. An alternative would be can, in other words, talk about the positive thing rather than the negative thing. Instead of saying I'm sorry, I'm sorry or sorry. We can't do that or sorry, but you're not gonna get that starting off. Something was sorry. Instead, you can say something like, I'm not sure we can do that. Instead, we could and then offer up a solution, saying Sorry, but we can't do that. Doesn't really help the person, right. You've got to give them something else to go on. I don't know. Instead of saying that, say I'll find out where it's even, okay? You find yourself saying I don't know just simply say, but I'll be glad to find out. Get back to you. So if you find yourself slipping up in saying the words I don't know followed up with that instead of saying you should have, you can try saying something like, I understand why you didn't think that piece of data was needed. However, now, what did I just dio? I used another bad work, right? If you look at the end of the list here, however, is one of those provoking phrases. So again, how else could we say it? You see how easy it is to kind of fall back on the words that we know in that we're used to that are actually provoking phrases. So instead of saying I understand why you didn't think that piece of data is necessary, however, you could try saying, I completely understand why you didn't think that piece of data was needed for this particular project. I think that and then state why it might be necessary. Just leave the word, however out of it, and it completely changes the tone. Why didn't you? Instead of saying that you can say I can see why you didn't and then do whatever it was that they didn't dio. The only thing we can do is instead of that phrase say, I think the best option is so rather than saying to them, your only option is you can say I think the best option is which makes people feel better about having options. And then we just talked about that, however, things so try not to use, but Or however, and instead you could try using the word and you could try just simply starting this sentence without the word, however, like I did in the example I used. There's different ways that you can change the language so that you're not using a provoking phrase. Tone of voice and voice inflection emphasizing are stressing. A word indicates importance, and it frequently impacts the meaning of the entire message, especially in the technology field. Using the correct words is critical to understanding, and because of that, more emphasis is spent on the content versus how it is said so let's liken example of what I'm talking about here. So if you were to read the following lines out loud, emphasizing the words in italics, you see how the message changes. I did not say he wanted a new report. I did not say he wanted a new report. I did not say he wanted a new report. I did not say he wanted a new report. I did not say he wanted a new report. I did not say he wanted a new report. I did not say he wanted a new report. So you see how when you put the emphasis on different words, it actually changes the meaning, if you will, of what the sentence is saying when I say he did not say he wanted a new report, it's like I am saying, Well, he didn't say it, but it was implied where if you go to number seven, I did not say he wanted a new report that completely changes it. The implication is that I didn't say he wanted a new report, not about whether or not he said he did, but whether or not that is the thing that he wants. So it completely changes it based on where you're emphasizing your words. So you want to make sure you're being conscious of that. We're led to believe that the text or content of a message is the message, but it's not really. There are really three parts to a message with words on Lee making up 7% of that message. Nonverbal cues make up 55% and the tone of voice is 38%. So keep that in mind. When you're practicing your communication skills, let's talk about eye contact and physical space. According to most communication experts, the most appropriate ease of eye contact is to maintain contact for a count of three, look away briefly and then re establish I connection again. So, like I said earlier, don't stare it. Somebody look at them. Look away. Look back again because staring could be regarded as disrespectful. And it can also be intimidating, avoiding eye contact. Those going the opposite direction sends negative messages that makes it look like you might not be interested in what the other person is saying. You may not be being truthful in the moment, and it can also make you look arrogant. Your physical distance and moving during communication tells the other person how interested and involved. You are also there is a kind of common comfort zone for people or what we would call. There's personal space, right? And you want to make sure that you're not kind of leaning into their personal space and making them feel uncomfortable. Think about what that is for you, what your personal space is, how close somebody can get to you before you start getting uncomfortable and it's going to be the same way for other people it. 7. BA Communication Lesson 7 How Body Language Changes Communications : Let's talk about body language. Body language is definitely part of your message. If you remember earlier in the course, we talked about the fact that Onley 7% of the message actually comes from the words body language plays a part in your message delivery as well. And while a lot of times you may be on conference calls and things delivering communication , you will also be delivering communication person. Nobody truly operates on Lee via conference calls, right? Even if the business partners and people that you're working with her and other locations, you're gonna have team members. You're going to have executives, managers, different people that you are dealing with in person. So body language applied to all situations where you're having in person communication and body language is really a very subjective area of communication. Because different people will take things different way. It's right, and it's a little bit more difficulty to say, Hey, you should always do this, or you should always do that because sometimes certain types of body language mean one thing in one culture and something else in another culture, so you've got to be able to read other people and how they're receiving the message that you're sending as well. However, there are some common interpretations of body language, and we're going to go ahead and take a look at those. So some positive gestures are things like nodding, head stroking, chin, counting things off on your fingers, leaning forward, your arms, being in an open position and smiling. So when you're not in your head, it says to the person I see or I understand. Stroking your chin can mean that you are seriously considering what the other person is saying. Coming things off on your fingers can show confidence and that you're being logical. Leaning forward can show intensity and interest. However, I also want to say, Don't lean forward too far. You don't want to get in the other person's personal space. You just want to slightly lean in to show that you are interested in what the person is saying. Having your arms in an open position kind of suggests that you are open to ideas so you're not being closed minded. You're listening to what the person is saying and smiling can sometimes indicate agreement or approval. So one of the things you actually have to be careful about is when you're trying to use positive gestures. If somebody is asking for approval, are asking for permission or something along those lines. Smiling may not necessarily be the right thing to do at that moment, because you don't want to give the impression that you're giving approval for something. So that's just something else to keep in mind about the positive gestures. Now let's look at some negative gestures, rolling eyes that can send a message to the person that you think that what they said was stupid rubbing your eyes, your forehead. Your eyebrows can make someone think that you're rejecting what they're saying or you're suspicious of what they're saying. Clearing your throat can indicate nervousness. Open palm's below. The chest level can sometimes indicate hopelessness or a plea to be understood. Wagging your finger back and forth is never good, and it usually indicates that you think the other person is wrong. Pointing can show aggressiveness chewing on your pencil, your pen or some other object can show that you're nervous or that you're uncertain. Crossing your arms over your chest can say to the person that you don't agree or that you're resisting the message that they're sending deep sighing can mean impatience or boredom, or that you're just not happy, quite frankly, what the person is saying when somebody says something you and you go, then it really does send a negative message. So you want to make sure that you're not doing that, and then smirking can indicate that you feel like you are superior to the person, so you want to make sure that you're paying attention to your facial features as well. The body language thing is really, you know, the last point I want to make on that as it really is very subjective, and you've got to look at the other person's body language, too, and try to make sure that they're not reading your language incorrectly. So be really careful about the gestures that you're using when you are in a in person communication type of setting