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.

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.

Update on the PBA

I got a few questions lately about the status of the PMI Business Analysis for Practitioners: A Practice Guide which I helped write last year.  The primary question was whether the PMI-PBA exam was now based entirely on the Practice Guide.

The practice guide was released electronically in December 2014 and in print in January 2015. It was available for free download from PMI through June of this year. As far as I know, the guide is still just one of 11 books on which the PMI-PBA exam is based. Although, each of the five writers of the guide, including myself, submitted 50 to 100 questions to be included in the question bank for the exam. So there may be some bias in the questions toward information in the guide. Additionally as we wrote the guide we were aware of the books in the last (for example several of the sections I wrote were based on my book, which is a natural thing to do of course).

I advise anyone taking the exam to read the guide because for the most part it is a very good summation of all of the books. However I don't know whether just reading the guide will be enough for someone without a lot of experience as a business analyst. I have not taken the exam, even though I have the certification. But remember that the exam was given for six months during the pilot before the guide was released so the first set of questions were based solely on the BA reading list.  

In general, after talking to many business analysts who have taken, and passed, the exam, a solid understanding of the general aspects of business analysis will likely suffice although all the books on the list are certainly worth reading even if they weren't part of the PBA exam.

Business analysts in Scrum - one company's view

I am asked continually whether business analysts have a place in agile, and in particular Scrum where there is no explicit role for a business analyst.  I always answer yes and set about to describe the possibilities and how business analysts are being used in Scrum.  
For example, here at a global financial company in New York they are bringing new graduates into the company to be business analysts, and to work in Scrum (their flavor of Scrum).  The business analysts were just told yesterday that their primary duties in Scrum will be to write and decompose user stories, working with both the business people on behalf of product owners and with the developers, and to write test cases and perform testing along side the QA analysts.  However, they are being trained in classic business analysis functions. None of the graduates are IT specialists or programmers.  A couple, for example, have advanced degrees in economics and finance. So they are in fact "business" analysts. And they will be working in Scrum. 

Interviewing for BA communications skills

The other day someone asked me how a manager would be able to tell that a candidate for a business analyst job has communication skills.  Here is my answer:

Instead of engaging in the apparently mandatory Q&A session where the applicant answers fairly rote questions (so rote that there are companies and people who purport to be able to prepare you for the questions you will get in an interview), start a conversation with the applicant. Ask questions that you might ask someone on first meeting them at a party or social get together. 

The answers are unimportant. You are looking for the way that they answer to determine their communications ability and skill.   If the answers are monosyllabic, evasive (a good communicator is willing to state that a particular subject is off limits or they do not wish to talk about it, rather than simply evading the question or providing ambiguous answers), not to the point, or answering in such a way that you are confused about their answer or not answering at all, then the person is demonstrating a lack of communication skills. On the other hand, if the applicant grabs the questions and runs with them, dominating the conversation (and as a good interviewer, you let the behavior run its course) then the applicant is also showing a lack of communication skills. The questions should not be too personal or threatening (hence the cocktail party analogy).  Develop some questions that would typically evoke questions in response.  Listen to how the applicant asks the questions (if the applicant does) and listens to the answers. Again this is a good indication of communication skills. A trick one friend of mine uses is to start the interview with some information about himself or the company and then ask a question later that would tell him whether the applicant was listening well.

Some experts point out that the interview situation is fraught with stress and that generally applicants in that pressure situation will revert to short answers. Ask more open ended questions as a way of getting the applicant more relaxed and responsive. However, if the applicant cannot get over their reticence in the interview they likely will not be able to overcome it when they have to interview a Vice President about a new project.

I would refrain from doing group interviews with the whole team. The concept there is to see how the applicant will fit in with the team. However, such an interview is terribly unrealistic. Unless you are hiring a person who will be making a lot of formal presentations to upper level management and other judgmental panels, This is not common. A better approach is one-on-one interviews with the team. This approach also has the advantage of some OJT training in interviewing for the team members.

As for the skills, my assumption from your post is that the technical skills or experiential skills have been handled through resume screening or a screening interview by HR or something so everyone you might talk to is technically qualified and you are looking for those with the right set of soft skills for a business analyst.

When someone else does our job

The question came up whether you play the role of business analyst differently if you are a project manager or some other position.  The answer is a clear ‘yes”.  This is mostly because as a business analyst you are analyzing the business full time. In some other position the role is an addendum or an incidental part of your full time job. A project manager is paid and rewarded for the success of the project, bringing it in on time, within budget and fully featured (everything done that was promised for that time frame and budget).  So when prioritizing her activities, the emphasis is going to be on tasks that contribute to project success. The business analyst will seek out different ways to solve the business problem and improve the business process while another position might ignore or avoid adding more to the project or other responsibilities. 

Business analysis is a full time concentration. It requires attention to detail and looking at the big picture, sometimes simultaneously.  It requires a specific attitude and approach. It is not an afterthought or simply the recording of what the business might want the computers to do at this moment.

Those who perform business analysis full time as their primary job are going to do it differently than those whose primary focus lies elsewhere.