Notes: Tools for the Business Analyst


Surveys 

Notes are from here. 

To ask the right questions, par them down to be comprehensible to an eight-year-old.

Avoid acronyms or industry jargons. 

Common way to gather requirements from stakeholders is to send a list of general topic of survey questions. These should lead towards more detailed, specific questions.  

Options/choices on how to respond within surveys will affect the data gathered.

Answer ranges can skew a survey. People who don't fill out forms for exemplary service doesn't imply that there were none. In some local grocery and department stores, they now have "Outstanding Service" forms you can fill out to honor anyone who has gone out of their way to provide exemplary service for you. No mention of where to enter complaints.


Interviews

Notes are from here

Interviews are preferable to surveys as they allow for follow ups and clarification. 

Three phases involved: Preparation, Conduct, and Follow UP

There are two types of interview: structured and unstructured. The former is better for eliciting specific information as opposed to gathering broad subjects or issues.

Interviews are not intended to validate requirements. 

Has some inherent risks such as being costly, skewed results to interviewer's bias, both parties need to be knowledgeable, etc

Tips

- Start with general questions 

- Avoid taking up the conversation but be persistent

- Paraphrase 

- Don't ask leading questions (questions with a restricted answer set)


Observation (Job Shadowing)

Notes from here. 

Methods: 

- Active: BA asks question while observing. (Risks breaking natural flow of procedures)

- Passive: BA simply observes. Questions at the end

- Apprenticing: BA becomes apprentice for the job

- Protocol Analysis: Person being observed gives a rundown of their processes

- Strobe: STructured Observation of the Business Environment (STROBE)

               BA gathers raw metrics 


Observation helps uncover information the worker unconsciously knows. 

To prepare, figure out logistics on when/where/who to capture widest array of information. Familiarize yourself with context. 

While observing, make sure they are comfortable so the data accurately reflects. Let them know the observation can stop at any time and assure that their work will not be questioned in any way. 

Afterwards, review your notes, follow up with any questions, and make sure to repeat protocol exactly with next observation for consistency in data. 

Observation helps capture real data and processes outside of documentation, allows for realization of shortcuts/redundancy by workers, and identifies things stakeholders do not notice. 

Disadvantages include being time-consuming, Hawthorne effect (observed person changes conduct during observation), mental work and processes unable to be captured, and inability to encapture complete sample size. 


Document Analysis

Notes from here. 

A core function for the Business Analyst. It is useful in gathering details of existing solutions, eliciting requirements, learning the business, learning the project, and learning the system.


Preparation -- 

1.  Determining what documentation is available 

2. Determining which of the available documentation is relevant 

3. Out of the relevant documents, which are the most appropriate for study given the objectives you are trying to achieve (this is especially true if there is a large amount of documentation available). 


Review -- 

1. This involves studying the documentation you have chosen as the most relevant in order to: 

2. Extract information that meets your needs or may be valuable later 

3.Taking note of questions that the documentation raises so that you can follow-up with SME’s later. Look for references to other documentation that you may not have come across in your initial search that may be relevant to your effort. 


Wrap-Up--  

1. Organizing and analyzing the information you extracted from the documents. This may include restating the information in the form of preliminary requirements for later review. 

2. Following-up on any appropriate document references you came across to continue the document analysis process. 

3. Review any questions you captured with the appropriate subject-matter experts in order to elicit answers and identify further questions.


DA may be extremely time consuming and documents may be dated. 




Comments

Post a Comment

Popular posts from this blog

XP: Card, Conversation, Confirmation - The three C's

Image
  This is a technique lifted from XP (Extreme Programming).  Card On each card is enough text that identifies a requirement. Notes of priority and cost are written on it as well. They serve as tokens for requirements and are handed to developers during implementation and returned to customers when completed. Conversation  Conversations are collectively exchanges of thought between customers and programmers. It is largely verbal, but may be communicated with supplemental examples. Confirmation Confirmation, in other words, acceptance tests, are defined at the start with the customer and shown to customer at the end of the iteration to confirm the story's completion. Note that extra documentation, while seemingly helpful, hardly "confirms" anything and cannot replace acceptance tests. 
Read more

Notes: 10 Knowledge Areas of Project Management (PMBOK 6)

Image
 Notes from here  There are 10 knowledge areas, as outlined in PMBOK 6, that are to be remembered sequentially. It is presented in logical order (with exception to Stakeholders which is tacked on at the end).  Integration: In other words, you can’t ‘do’ schedule management and ignore what the impacts of that might be on people, risk, communications, cost and the rest. Scope: Knowing what the project will deliver Schedule: all about making a detailed plan to tell everyone when the project will deliver what is in the requirements. Cost: Managing project fund Quality: Although quality varies project to project and many aren't as regimented, it is important to be aware and use appropriately Resource: Working out the resources needed to get the project done Communication: Creating a communication plan and monitoring for adjustments Risk: Covers an adequate overview of managing risks  Procurement: Depending on any purchases involved, there is a lot of contracting and negotiation Stakehol
Read more

RACI Definitions

Image
Notes from site RACI is a matrix to properly organize and define stakeholders' responsibilities in the project. While there are many methods in creating these organizations, this is just one method. Definitions should be kept nearby and the charts should be clear.  Responsible: This team member does the work to complete the task. Every task needs at least one Responsible party, but it’s okay to assign more. Accountable: This person delegates work and is the last one to review the task or deliverable before it’s deemed complete. On some tasks, the Responsible party may also serve as the Accountable one. Just be sure you only have one Accountable person assigned to each task or deliverable. (Note: It might not be your PM!) Consulted: Every deliverable is strengthened by review and consultation from more than one team member. Consulted parties are typically the people who provide input based on either how it will impact their future project work or their domain of expertise on the del
Read more