Let's take a look at written communication skills. Excellent writing skills are necessary to be successful in your role as a business analysts. The essential written communication skills needed are things like excellent grammar. If you struggle in this area, be sure to use the tools available to you. You have spellcheck and all of the word processing applications of course dictionaries, you may consider having someone review your communications prior to sending them out until your skills are sufficient in that area. So if you know that you have problems with grammar, sentence structure, things like that, then have somebody do a check.

Have them review it before you send it out. It does not foster confidence if your written communications are poorly written or grammatically incorrect meeting minutes. When you're taking meeting minutes. There are two things that you should remember to always document capture out action items and follow up items and capture the name of the person speaking. The reason you want to do this is because you want to be able to go back to them to get more information if you need to. So when I'm taking notes, even in a requirement session, so not necessarily meeting minutes, but my documentation, the requirements that are coming out of a session, I write down the name of the person that gave me the requirement.

So that if I have to go back later and ask a clarifying point or ask more information, I can say, hey, Jane, in the meeting, you told me, blah, blah, blah. And I need to get, you know, some more information on this. So that way, you know that Jane gave you that requirement, you know who to go back to. Obviously, if you're only having a one on one session, then, you know, you don't have to write their name down by every requirement because you know, they're the only ones that gave it to you. But if you have more than one person in the room, write the name down. emails, memos, and status reports.

Once you write the communication, you should review it and take out any unnecessary information. Use bullet points when possible, avoid long paragraphs people do not like to read. And when they see a lot in one paragraph, they generally tend to skip it or skip most of it, they might read the first sentence and then skip the rest of it. stick to the facts, do not inject opinion unless it's actually called for in the document. Also make sure that you're keeping emotion out of it, only stick to the facts, right? That way, you will have less of a tendency to stir up any emotions, when they're reviewing your documentation, if it's the type of documentation that can cause that, for example, if you were doing some software testing as part of your DBA role, if you're reviewing changes that were made, and you're checking to see if they're the same as what you asked for in the requirements and you find a defect.

When you're reporting that defect, you want to stick to the facts. You don't want to be emotional about it you don't want to cause the developer that wrote the code to be emotional about it. I always say that code is to a developer what a baby is to their mother. They don't want their babies called ugly and developers don't want their code called ugly, right? So you want to make sure that you are keeping the emotion out of it and sticking to the facts.