Author: Mani Ramasarma

The Requirements Process

While it is second nature to many of us I thought it would help to put this up here – the various steps involved in eliciting, documenting and baselining requirements.

Do not be overwhelmed by the number of steps, over time it will all flow in one seamless sequence.

1. Identify stakeholders

Who are the stakeholders? A person or persons with an interest or concern in something. Google and you will find anywhere between 4 and 14 types of stakeholders. I look at stakeholders as project stakeholders, requirements stakeholders, etc. There could be some overlap but not always. For example., a VP could be a project stakeholder but not a requirement stakeholder. Project stakeholders are generally listed in the Project charter/concept document. Requirements stakeholders will be listed in the BRD or any variant of that. Keep the following in mind:

  • These are folks who will be using the system or affected by the system
  • Identify any ongoing projects or upstream/downstream systems that are likely to be impacted
  • Include all people in your list of requirements stakeholders.

2. Do you have a Statement of Work (SOW)?

In case you are buying a COTS product and have released an RFP, it is very likely the RFP contains a SOW that defines the high-level scope of the project. Should there be none start by defining the high level scope. Why? It is easy to define high-level scope and then distill into the detailed requirements. The possibility of getting stuck in the weeds is way too high the other way around.

3. Organize the requirements kick-off session

Here are the things to do:

  1. Invite all stakeholders, project, requirements, etc.
  2. Set the agenda and stick to it
  3. Lead the session
  4. Explain the 5W’s and 1H – who, what where, when, why and how of requirements.
  5. Elaborate the requirements quality – Correct, Unambiguous, Complete, Necessary, Feasible, Verifiable and Traceable
  6. Insist that ‘you’ understand the requirements. Documenting is impossible without a good understanding of the requirements.
  7. Record the session (Announce it at the beginning., not all organizations view this favorably)
  8. Circulate the summary of the discussion and seek feedback on a no-objection basis

Many times the stakeholders are not aware of the aspects and quality standards of the requirements. They also are under the impression that you, the BA, and they are on the same wavelength and understanding. It is better to clear the air upfront.

4. Check and validate AS-IS process

If the organization maintains an updated AS-IS process, I recommend buying a lottery ticket! You may be really lucky. Have the AS-IS process validated by the stakeholders to ensure it is up to date. If you are not lucky, document the AS-IS process. Simultaneously prepare a stakeholder interaction map that represents what transpires between any and all stakeholders. This is important as it can identify stakeholders that were missed in the first step.


5. Document pain points

For each of the AS-IS business process identified above critically evaluate with stakeholders the pain points. One way to do this is to mark the points on the process flows where the stakeholders feel things could be improved. Unless you are re-engineering the whole process, the pain points must be addressed as part of the requirements. On your part identify steps in the process that do not add any value and discuss with stakeholders the alternatives.

6. Identify high-level requirements

SOW/ high-level scope and pain points should serve as a good starting point to come up with high-level requirements. Share the list with the stakeholders and identify any missing ones. Ideally, there should be no more than 8-10 high-level requirements. Provide no more than a few sentence descriptions for each of the high-level requirements.

7. Chose elicitation techniques

There are over 50 of them identified in the BABOK. Not all are relevant for eliciting requirements. Also, each situation may demand using different techniques or a combination of techniques. For example, if requirements are non-existent, use brain storming. If they are nebulous, use questionnaire.

8. Organize elicitation sessions

Have a precise agenda and invite relevant stakeholders. Not all requirement stakeholders need be present in all meetings. It is not a good use of their time. Manage the sessions as things can go off-track very quickly. Record the sessions so that they may play them back if things are not clear. Circulate summary of discussion the same day and seek feedback on a no-objection basis. Give a day’s gap between elicitation sessions for you to document the requirements else you may not remember all that was discussed.

9. Choose the right template

Do not overdo the template. They merely provide a structure to the requirements document. The content is very important. Focus on that. Standard BRD templates have many sections to fill. Discuss with your organization if some of these sections can be left out. Of course, certain sections like an overview, in scope and not in scope items are mandatory. AS-IS process and TO-BE processes can be documented separately and references in the BRD.

10. Document requirements

It’s now time to document the requirements. Keep these in mind:

  1. Quality standards
  2. Do not combine two requirements in a sentence
  3. Use a simple, active voice
  4. Ensure logical flow to requirements. For example., checking user authenticity must precede every other requirement
  5. Re-read the requirements, confirm they make sense and there are no conflicting requirements
  6. Avoid implementation details as part of business requirements. For example., system must support multi-threading or parallel processing or JSP’s or some similar thing.
  7. Don’t let existing system cloud your thoughts
  8. Provide examples and samples where possible. It provides a lot of clarity

11. Define test scenarios

V-model suggests that test scenarios must be created along with business requirements. Not just positive but also negative test scenarios must also be considered. This is one way of identifying missing requirements. The scenarios will be elaborated into test cases at a later stage. Keep the following in mind:

  1. For each requirement identify one or more scenarios
  2. Always include negative scenarios
  3. Role based test scenarios must be considered if they are important
  4. Downstream and/or upstream test scenarios are important if systems are going to be impacted

12. Peer review artifacts

This is absolutely essential. Share the BRD; AS-IS flows, pain points, test scenarios and all other artifacts with a peer or a senior BA. This will ensure the requirements are of quality and every requirement is captured. It also ensures the test scenarios provide complete coverage of all requirements.

13. Request feedback

Seek feedback from business users. Update artifacts based on feedback received. If required organize more elicitation sessions to seek clarity. Test scenarios may have to be changed if requirements undergo a change. This is an iterative process.

14. Conduct sign-off walkthrough with users

This is the comprehensive final walk through with business stakeholders. In other words, it is the final chance for users to make necessary modifications, clarify requirements or add details if required.

15. Conduct walk-through with technical team

In case of in-house development conduct a walkthrough with the technical team. It also applies to COTS products or external vendors. This ensures requirements are technically feasible to implement and may require re-defining of requirements. For COTS products it gives an opportunity for vendors to identify gaps and ways to bridge it. This leads to the design phase in a typical waterfall model.

16. Obtain sign-off from business stakeholders

The final step in the process wherein business stakeholders agree on the requirements. Once done the requirements are ring-fenced and final. Any subsequent changes will result in a change request.

17. Baseline requirements

The signed-off requirements will be officially considered the first version. All changes will be incorporated and updated in this version.

Here is the diagrammatic representation of the process

ramasama 08092018

The B in BA

We began our tour of ‘Business Analysis’ in my last article with a focus on Analysis (the A) since the Business (the B) part still comes secondary in its role as an adjective.

The simple reason for this is that we need to know how to analyze before getting to what to analyze. In “The A in BA” I wrote about the importance of visualization and how it plays a big role in analysis. There is one more method that I normally use to analyze – the building blocks. Let me discuss this before I move into the B in BA.

In contrast to how kids build with blocks (bottoms up!), for this exercise, take heed of this mantra – Always start at the top. In one of my blogs here, I mentioned understanding the forest AND the trees. The building block method starts as a forest and gets to the trees, its branches and ultimately the leaves. Let’s say, for example, we are building the software for an ATM (Automated Teller Machine). This is something most of us are familiar with. Here is the sample ‘forest’ block.

  1. Login
  2. Withdraw cash
  3. Deposit cash
  4. Deposit check or cheque (for the followers of Queen’s English)
  5. Check balances

If you recollect the last time you used an ATM the above, from 2 to 5 is what you may have seen on the screen after you successfully login. But the Login process itself has many ‘trees’, ‘branches’ and ‘leaves’ to contend with. For example, the set of building blocks for Login could be

  1. Login (‘Forest’)
    1. Insert ATM Card (‘Tree’)
    2. Validate PIN

Within the ‘Tree’ you can list the branches, for example

  1. Login (‘Forest’)
    1. Insert ATM Card (‘Tree’)
      1. Customer inserts ATM card the right way (‘Branches’)
        1. If Customer inserts the ATM card in an incorrect way the ATM machine will swallow the card, digest and let out a burp. (‘Leaves’)
      2. ATM prompts the customer to enter the n-digit PIN.

You might notice I followed the forest-tree-branch-leaves path. It is not always necessary to follow this path. Also, a tree can lead to a branch which could then lead into another branch and so on. Depending on the functionality of the process being analyzed, the building blocks can, and most likely will, vary.

Additionally, the required level of granularity in decomposing the process also dictates the path from forest to leaves.

If you notice in the ATM example above, I am discussing B – Business. I am not discussing the technical aspects of the ATM or the usability factors like touch-screen, voice activated etc. The entire focus is on the business needs. For a BA to analyze the business needs he/she must have two things:

  1. Very good understanding of the business and
  2. Creativity

Good understanding of the business

The ATM example is simple, and most of us can relate to as it is something that we use often. How does one gain a good understanding of a business that we are not familiar with, say, for example, structured derivatives? There are BAs who have prior experience versus those that do not. It is easy for the experienced BA to fit in quickly and be productive from the first day. All organizations like business analysts to be productive from day one without spending too much time having to learn the business. (Of course, each day is a learning experience!) It is the inexperienced BAs who have the arduous task of learning the business.

For most the learning curve is long and steep. Now that I have thoroughly scared you off, I am going to answer the question likely in your head right now – how does a BA learn the business?

The process begins even before applying for the job. Before you apply, understand the job requirements. See if knowledge of any business area is essential. If so, research that and try to gain as much knowledge as possible. Some ‘knowledge’ you find in your research might read like rocket science and be impossible to understand in the limited time available – but do not let that be a deterrent to your efforts. You can surprise the interviewer with your freshly acquired knowledge. There may be a few questions in the interview that could be pointers to the areas that you may need to focus on.

Once on the job, get access to any documentation you can lay your hands on. I found the documentation hard to find in some cases. What do you do in such cases? Shadow business users. Talk to them. Ask them to explain things, even those you know well, as they may be used, interpreted or implemented differently. Never assume it is used the way you understand it. A technique I normally adopt is to let the business user assume that I know nothing about what they are about to say, i.e., I am a complete dud. (I had the misfortune of a business user mistaking me to be a real dud until revealed by educational qualifications and experience!!!). This makes the business user generally comfortable, information flows smoothly, and they share a lot more. If you can get access to a test system, do it so that you can play around with it. Document the details in a way you can remember it.

A BA is more employable if he/she is adaptable and can learn the business in the shortest possible time. Never back-off from a business you are not familiar with. Accept the challenge, put in the effort and you shall succeed. In my next blog I will discuss the C in BA. Oh, is that a misrepresentation? Probably not.

The A in BA

According to IIBA, business analysis is defined as “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders”. This is what a BA is and should be. However, in most places the role of a business analyst is confined to just two words in the definition – “defining needs”.

The others are given a short shrift. Whether this is by choice or due to a lack of confidence in the skills of a BA is unknown. Probably we as BA’s are to be blamed partly for this. Many of the candidates I interview for positions in my organization also have a narrow view of what a BA must and should do, and this is confined to eliciting and documenting requirements. Many do not address the most important job of a BA – the “A” in BA. A thorough analysis of a problem statement leads to identification and recommendation of the best solution for an organization, deliver value to stakeholders and thus provide complete justice to the definition of business analysis.

It is extremely difficult to explain analysis in its entirety in this article but let me attempt a synopsis.

{module ad 300×100 Large mobile}

So what is analysis? According to Merriam-Webster dictionary, analysis is “a careful study of something to learn about its parts, what they do, and how they are related to each other”. More importantly the plural of analysis, analyses, is defined as the “separation of a whole into its component parts”.

Now, that looks familiar. As applied to business analysis, it is the separation of requirements into their functional component parts aka functional decomposition. Besides being part of a BA’s job, why is it necessary for us to analyze? Why is it necessary for a BA to break down the requirements into their components?

As the saying goes “the devil is in the details”. Not focusing on the details or focusing too much on narrow details without considering the impact on upstream and downstream systems is a sure-fire recipe for disaster. Many projects fail for one or both reasons. Once the time for analysis has passed it is difficult, nay impossible, to analyze at later stages of the project when the focus must be on DDT – Design, Development, and Testing (not dichlorodiphenyltrichloroethane, it is banned). During such crunch situations, people resort to the ‘next best thing’ – assumptions – and it is downhill from there.

Projects typically require large financial investments, and it is important that we do not miss on the material details that could boomerang in the testing phase and blow up in the face. Whether it is waterfall or agile, analyzing requirements is very important, i.e., breaking down the requirements into their components so that the scope is well defined early on in the project lifecycle. This ultimately reduces the need for (often incorrect) assumptions later. The process of breaking down requirements into functional details is called Functional Decomposition.

As with every other thing in this world, there are people who swear by Functional Decomposition (FD) and there are detractors who feel its value is greatly overstated. To each his opinion. I fall in the first category where I believe that functional decomposition, as applied to business analysis, is a fundamental technique that every analyst must not only be aware of but should also use to varying degrees. It provides a logical sequence and a natural flow from the big picture requirement down to its components.
How to decompose requirements into its functional components?

Related Article: Cooking Up Business Analysis Success

This is a standard interview question. Two important things are required to get FD right – visualization and clarity of thought. This must be followed by validation by the business users. The level of visualization needed is a function of the maturity of the business process – the greater the maturity level of the process, the lesser the need for visualization and vice versa. Why? A matured process defines the minutest of tasks very clearly and unless there is a strong need to change it, visualization plays a minor role. The point to be noted here is that even when the processes are well-defined certain amount of visualization is necessary to identify the impact on other upstream, downstream, and peripheral systems.

What is Visualization?

It is the formation of visual mental images. You may have read about visualization in Wallace Wattle’s book “The Science of Getting Rich.” This is slightly different, at least the goals are. Given a requirement you role-play, mentally, the various tasks that a user can perform. Imagine what the end-system must look like.

Further, imagine that you are the user who will be using the system. It is called Receptive Visualization and is akin to watching a movie in your head. Here is a beautiful article on visualization in Huffington Post. The second type of visualization this article mentions, Process Visualization, is similar to Receptive Visualization. Visualization can also be seen as internal brainstorming. You can visualize jointly with others too – external brainstorming. Visualization requires business, process knowledge, and a lot of creativity. Along with visualization, you need clarity of thought.

What is “clarity of thought”?

Clarity of thought is the ability to perceive, understand, and follow a train of thought. Why is this important? Clarity crystallizes the goals that we wish to achieve. It is like writing the script or dialog for a movie. You don’t want to omit sentences that make the dialog non-sensical.

Lack of clarity often results in re-work, increased cost, delayed project delivery and, if you really make a mess of it, making it to the Gartner and Forrester’s survey of failed projects.

How to achieve clarity?

While visualizing adopt a step-by-step approach. At each step try answering the 4W’s (Who, What, When and Why) and the 1H (How). There are 2 H’s – Business and Technical. Focus on the Business How. ‘Who’ defines the actors, ‘What’ is the outcome expected of the step, ‘When’ refers to the timing and ‘Why’ provides the raison d’etre of the step. ‘How’ is used, for example, as in a calculation or formula. Ask, in your mind, the questions and put it down on paper. Revisit the steps as documented (as in the dialog above) and see if it makes sense. Now, this may seem like a lot of hard work. Initially it is, but as you gain experience it becomes second nature, and you should be able to visualize with clarity, edit mentally, and put it on paper all in one go. As you can see visualization and clarity go hand-in-hand.

In a later article I will explain this in detail.

Is it worth the effort to visualize and come up with all those innovative things? I firmly believe so, as otherwise you end up with a system that will probably be antiquated within a year or two. Of course, visualization and clarity do not come easy, and it takes plenty of experience. It is a skill that can be developed.

Process Approach to Requirements Gathering

This blog was supposed to be on requirements elicitation techniques, but it ended up being an example of what peer review does. I finished my blog and handed it over to my colleague for feedback. He pointed out that I assumed people knew how to gather requirements for them to start using the techniques mentioned in the blog. In other words, the blog on techniques was a step ahead, and I should first explain the approach. Ouch! The bump on my head still hurts. So, here we go.

I interview many candidates. Whenever I ask “How do you approach requirements session?” the answers invariably include something akin to “I use JAD session” or “I shadow users”. JAD (Joint Application Design), shadowing, interviewing, and brainstorming are techniques used AFTER you have an approach. Think of it this way. You decide to go on a vacation. How do you approach it? You don’t start with “I will drive” or “I will fly”. These are ways (techniques) by which you reach the destination. The first thing you need to do is decide where to go, when to go, and how to go (approach). The series of steps you take (approach) has to precede the decision to drive or fly (technique). There is a very fine difference.

So, how do we plan an approach to a requirements gathering session? Do we call for a meeting and ask the business user “ok, so what do you want?” or “I am ready, go ahead and list your requirements?” Don’t be surprised if you get a very lengthy grocery list! To avoid such mishaps here is a process-based approach to requirements gathering.

The first point in my last blog was “Do your homework”. The first step as part of homework is to understand the organization and the unit. This understanding provides the big picture so that the goals of the requirements that are to be gathered align with the goals of the organization and unit. Next is to understand the business under consideration, and the scope of the system being worked upon. There are many avenues to it. One of them is to get hold of an AS-IS process diagram.

Start from a high-level process. Some call it “Level 0” or “L0.” Drill down from here to the lowest level possible – L1, L2, L3 and so on (do not confuse this with support levels). Normally you would achieve this by L3 or L4. If AS-IS diagrams don’t exist, your task is to create them.

A mature organization typically has all the “as is” processes documented. Go over it. Go over any other document related to the system that may be available – business bequirements focuments (BRD), functional specifications documents (FSD), user manuals, data flow diagrams (DFD), entity relationship diagrams (ERD), and DDD (sorry, I just created that one!). Get access to the test system and play around in the sandbox – see what it does, see what it doesn’t do. Talk to the technical people. Sometimes they know more about the business than the business users themselves. Ask for a walk-through by technical and/or business folks. If you have a knowledgeable lead, talk to them. By now you should have a good understanding of the way business is conducted. As you assimilate information, note things that don’t seem right. Always remember your title – Business Analyst – so make sure that you are always trying to analyze as you proceed.

Armed with enough knowledge, proceed to capture the “to be” process. Remember, you are documenting only the “to be” process and not the requirements. A common pitfall is to embed requirements in process documents. Be sure to avoid it.

Make a copy of the “as is” process and mark bottlenecks, pain points, workaround’s, manual processes, and non-value add processes. See if you can measure lead and lag times between points in the process. All the current weaknesses should be resolved in the “to be” process in addition to any new functionality or change in the process itself. Beware not to resolve a process inefficiency by automating it. You will be automating inefficiency.

Again start from Level 0 or L0. Make necessary changes. Each of the tasks define your high-level requirements. Here is an example of a L0 procurement process in a bureaucratic organizationRamasarma May5 IMG001

Use the gathered requirements to prepare your high-level BRD.

Each of the boxes can further be broken down into next level processes. For example, the first task can be decomposed intoRamasarma May5 IMG002

Again, each of the tasks can further be elaborated (here is a buzzword for the interviews – Functional Decomposition). Here is what it may look like, assuming that we go all the way to the lowest level possible (do not magnify the picture. It is there for illustrative purpose only):

Ramasarma May5 IMG003At each level look for opportunities to eliminate both the deficiencies (what is missing) and the inefficiencies (what isn’t needed) in the current process. Keep this maxim in mind while redesigning processes – the shortest distance between two points is a straight line. A straight line is not always practical or feasible, but use it as a guideline to streamline the processes. Even if you manage to eliminate or refine one or two steps, it can result in significant time and cost savings.

The hazy little light blue rectangles in the diagram above specify the system that performs that particular task. The diagram also includes manual tasks, reports, and emails. Check if you can automate manual tasks, and whether consecutive manual tasks can be replaced by a workflow. Again, do not automate inefficient processes. Deal with reports separately. Once the “to be” process is documented, have it validated by the business users. Validation is mandatory. It is so mandatory that I will say it again – it is mandatory to have these “to be” processes validated and approved by the business users. What you are left with is a bunch of tasks at the lowest functional level. It is for these that you need to gather functional requirements.

There is one more step you need to do before diving into the requirements gathering process – organize a requirements elicitation kick-off session. Invite business users and the technical team members. Highlight the importance of requirements, characteristics of a good requirement, what has been achieved so far, next steps, and the need for continued user participation and cooperation. The most important component is listing and explaining a good requirement. What are the characteristics? Here is a website that explains it really well. (The next blog will address this and requirements gathering techniques). There are some good examples on the website of how not to write a requirement, which is equal in importance to how it shall be written (a touch of BA humor there!).

The following diagram summarizes the approachRamasarma May5 IMG004

We are ready to launch into the requirements gathering process. That bump on my head is now better.

Don’t forget to leave your comments below.

Business Analyst Skills – Overview

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.

  • 1
  • 2