Tag: Business Analysis

In my previous post I promised to list the skills a Business Analyst must have. While there are many qualities/skills required I list only those that are critical. After all, there is no “ideal” BA!! Before I do that let me briefly discuss the types of BA’s as the skills differ slightly for each.

BA’s can be classified into 4 types – Operational, Project, Enterprise, and Strategic. An operational BA is responsible for one or more systems that are currently in use. This person analyzes issues, prioritizes them with business users, coordinates with the technical team and ensures the issue is fixed. The original BRD/FS is appropriately updated. A project BA, as the name suggests, is part of the project team to build or implement a new system. An enterprise BA has a cross-functional view of the organization. A “go-to” person when the project cuts across multiple business units or functions. A strategic BA is more of an advisor/consultant interacting with the business constantly and guiding them in making long-term decisions related to business processes or systems. What skills must a BA in general possess?

Google for BA skills and you will find plenty of them – “4 key skill sets for a seasoned BA”, “8 BA skills for success”, “The Top ten skill sets for a BA” and so on. I listed some of the skills in my previous blog, which I repeat here in greater detail. A few more skills are also added to the list. Again, these are based on my past experience and are common to most situations. Additional skills will be required for different situations.

1. Active listening. It is a communication technique used in counseling, training and conflict resolution, which requires the listener to feed back what they hear to the speaker, by way of re-stating or paraphrasing what they have heard in their own words, to confirm what they have heard and moreover, to confirm the understanding of both parties . Communication is incomplete if the listener does not comprehend what is being said. Re-stating and paraphrasing is an effective way to understand what the other person is saying. While doing so do not miss out on important facts. Watch for body language too. It provides clues to the importance of the requirement as well as UI design. For example, while discussing a requirement the users may gesture a drop down or a click without verbally stating it. Note them down.
2. Patience. It’s a virtue that all BA’s must have. First, not everyone has clarity of thought. Second, business users do their job really well but may not be articulate enough. Third, they may not have the patience to sit and explain fundamental things to you. It’s like being in a relationship. Two impatient people make the situation quite explosive. This attribute is something to be cultivated. If you have not read Dale Carnegie’s book “How to Win Friends and Influence People” please do so. There are many examples in there that show how patience can get what you want.
3. Persistence. You have to strike the right balance. Extreme persistence will annoy people. Extreme non-persistence will result in inadequate requirements. Walk the thin line. Persevere until you get the information required without annoying the business users. Patience and humor are important tools here. Yet another approach is to understand the mental makeup, idiosyncrasies, likes and dislikes, interest, hobbies of the person you will be dealing with. How to get this information? Have an informal chat, coffee, lunch with the person/s before setting off on the formal process of requirements elicitation. Here is a cue from Dale Carnegie – people love to talk about their experience. Once you establish a personal connection, not much of effort is required on the persistence front. Remember, nothing comes easy.
4. Documentation. Translating requirements as communicated by the users and as understood by you into a BRD/FS requires a good command over written English. Ability to document in a lucid way without diluting the essence of the user needs is a necessity every BA must possess. Supporting user needs with examples in a clear, concise manner ensures the business users and the technical team understand the requirements in a consistent fashion. The key word here is “consistent”. Business users and the technical team must comprehend it the same way. Writing need not be Shakespearean. Simple, grammatically correct sentences are good enough. Where do you start?
   1. Review some of the existing documents. Do they appeal to you? Do they grab your attention? How would you revise it to make it more appealing? Are they clear? If not, what is missing? Remember to try to add those missing ingredients to your documents.
   2. Rewrite some of the documents, if not the whole, at least the portion that is dowdy.
   3. Do not use words where the reader has to refer a dictionary (dowdy is a good example, it means dull, unattractive).
   4. Peer review is yet another way to improve your documentation skills. Some people are very good with punctuation (my weak point). Some are good with word choice and some are good with spelling (my strong point). (I had this document peer-reviewed too).
   5. Use Microsoft Word’s built-in, rudimentary spell check and grammar check. You can ward off some of the basic problems.
   6. Some of the fundamental writing mistakes to avoid – mixing up tenses, switching between first, second and third persons, verb-number disagreement.
   7. Write in active tone.
      Keep in mind that a poorly worded document is rarely read to completion. Also keep in mind that a BRD or FS will be a live document as long as the system exists. So, get the documentation right.
5. Analytical skills. The bread and butter of a BA. Ability to dissect a requirement, understand its need, study its impact on upstream and downstream systems, and comprehend its role in the grand scheme of things (seeing the forest AND the trees) is absolutely essential. This website lists areas where analytical skills are required and is not restricted to BA’s. I have seen some amazing young BA’s with excellent analytical skills too as well as some experienced ones with waning analytical abilities. How to improve analytical skills? (the assumption here is you already have a level of analytical skills) There are many tools to help you, like Fishbone diagram, 5-why methodology, and much more. Playing Sudoku (not during office hours) helps a great deal in improving analytical abilities. How much to analyze? Enough to implement the requirement and avoid analysis-paralysis. Here are some points to bear in mind:
   1. Always keep the objective in mind.
   2. Establish a time limit to conclude your analysis process.
   3. Perfection is not the criteria, adequacy is.
   4. Check with a senior colleague.
   5. Go with your gut feel.
6. Conflict management. Conflict is common place in the life of a BA, while gathering requirements, analyzing, communicating to technical team, and testing. Some of the skills mentioned in my earlier blog will definitely help manage these conflicts. Eliyahu Goldratt in his book Theory of Constraints (TOC) provides a methodical way of resolving conflicts. He calls it the “evaporating cloud” . It is a logical and graphical way to resolving conflicts. The diagram must be viewed from right to left (like Arabic). Yet another method is to follow the 2-minute rule. If a resolution is not found within 2 minutes, keep it aside and table it later. Never get into an argument. You may win it but you will lose the goodwill of the person.
   Be aware of the escalation process too. Do not escalate at the drop of a hat. Tact is absolutely essential so as not to mess up the relationship with the business.
7. Communication. Here is a high-level list of things to do:
   1. Have an agenda for each meeting and share it before hand.
   2. Follow up each meeting with a written communication of what was discussed and provide readers with a timeframe by when they should confirm.
   3. Keep the communication channel with the business users open. There is a general tendency to switch it off once requirements are gathered till UAT. In the interim keep the users updated of the progress being made.
   4. Have walk-through sessions with the technical team to explain the requirements.
   5. Document all explanations and clarifications provided. This will help avoid a ‘you-said-she-said’ situation.
   6. Communication must be clear, concise and correct. Use bullets instead of paragraphs where possible.
   7. If you are not sure how your message will be understood, save the communication as draft. Revisit it a day or two later and if it still sounds good send it.
   8. Spell check and grammar check before sending out the communication. When in doubt, ask someone else to read it.

The list is by no means complete. Different situations demand diverse skills. Some can be acquired while others come through experience. In my next blog I will discuss the techniques available to a BA for eliciting requirements but before that let me acquire some more of the below skills myself !!!

Don’t forget to leave your comments below.