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.