Search This Blog

Wednesday, November 25, 2015

The Value of Observation

Observation is an information gathering or elicitation technique that is often overlooked by business analysts.  Sometimes it is impossible to observe the workers doing their jobs. There may be security issues, concerns about interfering with the work process, or simply physical limitations in the environment.  However, wherever possible the business analyst should seek out ways of observing the people as they perform the tasks and activities in the problem domain.  . 

The observation provides four beneficial things to the information gathering process:
1.    Observation lets you get an immediate view of, and feeling for, the overall problem domain, especially when you follow the business process from end to end.
2.    Observation gets you closer (and in participation you get all the way) to a shared experience with the people you are going to talk to
3.    Identifies questions that you need to ask
4.    Identifies actions, activities, decision points and processes that are so automatic that the process workers are not aware that they are doing it and would not mention it in an interview or meeting.
There are four types of observation:
·         Passive observation is when you walk through the business unit observing what is going on without any interaction with the workers.  Later you ask questions to clarify what you have observed
·         Active observation is walking through the business unit, but with the ability or permission to ask questions of the workers as you go. 
·         Participative observation is when you actually do the job – take the place of a worker or work side by side with them, taking notes along the way, and asking questions
·         Simulation occurs when there is no other way of observing. The business analyst enters a simulation of the business process.  Examples of simulations include the well-known Flight Simulator and other similar computer renditions.  But also there are usually training materials for new hires that can introduce the business analyst to the business process and some organizations have computer simulations of various user interfaces in the business process for use in training and process improvement that the business analyst can use to become familiar with the business process environment.  

Consider including the practice of observation as one of the elicitation techniques you use regularly in your business analysis process.

Monday, November 9, 2015

Type cast Business Analyst

It is sad that the business analyst has been typecast as solely a definer of requirements and to run interference with the business community. I tend to buy into the business analysts name - someone who analyzes the business to solve business problems.
There are two approaches depending on the business analyst's stance. A deductive or tactical business analyst responds to stated problems from the business. From that perspective, the business analyst would not be involved until someone identifies a problem - the difference between the current situation and what that someone perceives the current situation should be. Then the business analyst steps in to solve the problem and might in the course of defining the solution document some requirements for change.
In the second approach, the business analyst reviews the business process and identifies improvements or problems that could be solved to improve the process without being told there is a business problem to solve. For example, in the situation of a mechanic using a web site to help diagnose a problem with a vehicle (actual situation), the business analyst might suggest reorganizing the web site so that it reflects the natural way the mechanic uses the information instead of the logical flow of data that would be normally defined by a systems analyst or data base designer. The business analyst  observes the way the mechanic uses the website and suggest improvements not in the mechanic's process but in the way the computer system on the web site supports that process. Once the inductive business analyst's suggestion for improvement is adopted, the deductive business analyst (same guy, different hat) steps in to define the solution in a set of requirements that are implemented to improve the process.
Both business analysis approaches are valid and necessary to add value to the organization.