Business Analyst Technique: Observation (Free session template)

What Is the Observation Technique in Business Analysis?

Observation is a business analysis elicitation technique that gathers requirements by watching activities and their real-world context as they actually happen. Rather than asking stakeholders to describe a process from memory, the analyst sees it performed firsthand.

This technique is especially valuable when developing solutions for environments involving physical operations — such as a factory floor, a warehouse, or any workplace where work is done with hands, machines, or physical movement rather than purely on a screen. Watching the real workflow surfaces details that interviews and workshops often miss.

Quick Answer: What Are the Two Types of Observation?

There are two core types of observation a business analyst can use:

• Active / Noticeable observation — The analyst asks questions during the process. This interrupts the workflow but helps build a quick understanding of what's happening and why.
• Passive / Unnoticeable observation — The analyst asks questions at the end of the session, without interrupting the work in progress.

Choosing between the two depends on how disruptive interruptions would be to the process being studied and how quickly the analyst needs answers.

Variations of the Observation Technique

Beyond the active/passive distinction, observation can be carried out in several different ways:

• Ask the actor to perform a specific task, so the analyst can watch a particular scenario play out on demand.
• Do the actual work to get a hands-on feel — this should be limited to activities appropriate for a non-expert to perform, and whose results won't negatively impact the business.
• Become a temporary apprentice, working alongside the person being observed over a longer stretch of time.
• Record video and review it with the observed person afterward to capture further details that might be missed in real time.

Steps for Conducting an Observation

1. Have a Clear and Specific Objective

Before anything else, define exactly what you want to learn from the observation. A vague goal produces vague results.

2. Prepare for Observation

• Determine which activities you'll observe.
• Identify sample users to observe — for example, a mix of experts and novices, or experts only, depending on what you need to learn.
• Prepare your observation questions in advance.

3. Conduct the Observation Session

• Explain the reason for the observation, and assure participants that the sole purpose is to gather requirements and study the process — not to evaluate their performance.
• Let users know they can ask you to stop the observation if it interferes with their work.
• Attentively watch the activity as it unfolds.
• Record what you see: time taken, quality of work, process anomalies, and anything unexpected.
• Ask questions either while the work is being performed or after the session, depending on whether you're using active or passive observation.

4. Confirm Observation Results

• Review your notes and any recorded data.
• Follow up with participants to get further clarification where needed.
• Share your notes and data with participants to ease any concerns they may have about how the information will be used.
• Collate validated notes and data with other related observations.
• Summarize and analyze findings, and communicate improvement opportunities to stakeholders.

Why Use Observation? Strengths

Observation offers several advantages that other elicitation techniques can't match:

• Documents details about current processes with a level of accuracy that's hard to get from interviews alone.
• Ideal when the project's objective is to enhance or change a current process — you need to understand the "as-is" state deeply before redesigning it.
• Effective when stakeholders are unable to express requirements well, whether due to the complexity of the task or because certain steps have become second nature to them.
• Provides realistic, practical insight into how business processes actually work — not how people believe or claim they work.
• Enables direct comparison of productivity against standards or performance metrics.
• Uncovers non-documented informal tasks or workarounds that never made it into official process documentation.
• Grounds recommendations in evidence, since improvement suggestions are based on what was actually observed.

Limitations of the Observation Technique

Observation isn't the right fit for every situation:

• Only works for existing processes. You can't observe a process that doesn't exist yet.
• Time-consuming and potentially disruptive to the people and workflows being observed.
• Participants may alter their work practices simply because they know they're being watched (a version of the observer effect).
• Can't evaluate knowledge-based activities — observation works well for physical, visible tasks, but it struggles to capture purely mental or cognitive work.

Free Downloadable Template: Observation Session Planner

To make this technique easier to apply on your next project, we've put together a ready-to-use Observation Session Template. It includes sections for:

• Session objective and scope
• Activities and sample users to observe
• Pre-session observation questions
• A structured notes log (time, activity, quality, anomalies)
• A findings and follow-up summary section

👉 Download the template below and adapt it to your next elicitation session.

Frequently Asked Questions

What is the observation technique in business analysis? It's an elicitation technique where a business analyst gathers requirements by directly watching activities and their context, rather than relying solely on what stakeholders say about a process.

When should a business analyst use observation instead of interviews? Observation is most useful when a project involves physical operations, when stakeholders struggle to articulate their own processes, or when the goal is to improve or change an existing process and an accurate "as-is" picture is needed first.

What's the difference between active and passive observation? Active (noticeable) observation involves asking questions during the process, which can interrupt the workflow but speeds up understanding. Passive (unnoticeable) observation saves questions for the end, avoiding interruptions to the work.

What are the main limitations of observation as a technique? It only applies to processes that already exist, it can be time-consuming and disruptive, people may change their behavior when watched, and it can't effectively evaluate purely knowledge-based or mental activities.

Can observation be used for digital or software-based processes? Observation works best for visible, physical activities. For knowledge-based or purely cognitive work — such as decision-making that happens mentally — other techniques like interviews or protocol analysis are generally more effective.

Key Takeaway

Observation gives business analysts something no interview or document review can fully replicate: a first-hand, evidence-based view of how work actually happens. Used at the right moments — especially for physical or process-heavy environments — it produces realistic insights and uncovers the informal workarounds that formal documentation misses. Plan it well, respect participants throughout, and pair it with follow-up validation to get the most reliable results.

Worked Out Example

Governance, Risk and Compliance (GRC) management system is developed for the IT and ITES domain. The primary objective of GRC management system is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated manner. It has various features, one of which is to plan and track projects and programs using standards such as CMMI, ISO 9001, ISO 27001 etc.

As part of the compliance requirements, organizations need to take stock of their IT assets. The narration provided here is an observation of the IT Asset Reconciliation process that the BA had along with the inventory team. The objective of this process is to periodically conduct a complete count of the inventory. This is usually carried out at the end of a month, quarter, or year, to coincide with the end of a reporting period. Considering the effort spent on counting and obtaining accurate data of the assets, the number of times this process is carried out is limited in a year.

On 1^st of May, 10:00 am, James, the stock control auditor provided me a brief explanation of the objective of the process and some of the activities which are typically carried out prior to the actual day of counting. He told me that the whole process would take 4 days to complete with few days gap in between.

Around 10:30 am, James ordered sufficient number of two-part count tags for the amount of inventory expected to be counted and numbered them sequentially in order to track them individually as part of the counting process.

On 8^th May, 10 am, James and his assistant Robert reviewed the inventory prior to the scheduled inventory count date. James asked the warehouse staff to make necessary corrections for those items for which the parts were missing and were not properly boxed/ bagged.

Around 2 pm, James and Robert started pre-counting the inventory. They counted the items which could be placed in sealed containers, after which they sealed them in the containers and marked the quantity on the sealing tape.

James informed me that this activity made the counting task much easier during the actual count. If a seal was broken, then they would know that they had to re-count the contents of the container.

This task got over around 4 pm.

On 9^th May, 10 am, James completed pending data entry transactions. This included transactions for issuances from the warehouse, returns to the warehouse, and transfers between bin locations within the warehouse.

Around 12 pm, James notified the outside storage locations holding the company inventory on consignment to count their inventory on hand as of the official count date which would be 12^th May. He also told them to forward this information to the warehouse manager.

Around 4 pm, James instructed the warehouse to freeze their activities. He informed the warehouse manager to stop all deliveries from the warehouse, and also segregate all newly-received goods where they will not be counted.

When I asked him why the warehouse activities were frozen, he informed me that if this activity was not done, the inventory records would be in a state of flux during the inventory count and would not be entirely reliable.

On 12^th May, 10 am – the day of inventory counting, James formed two-person counting teams and instructed them on their counting duties. These duties involved having one person count inventory while the other person mark down the information on a count tag. One copy of the tag was affixed to the inventory, while the team retained the other copy.

Around 10:15 am, James issued blocks of count tags to the count teams. Each team was responsible for returning a specific numeric range of count tags, whether or not the tags were used.

James told me that maintaining control over all count tags would ensure that lost tags would be investigated promptly.

After this, each count team were assigned a specific range of bins and James highlighted those locations on a map of the warehouse. He also maintained a master list of which areas of the warehouse have been counted, and which teams have been assigned to each area.

I also observed that one person on each team counted a specific item within a bin location, and the other person marked the bin location, item description, part number, quantity, and unit of measure on a count tag. The team then affixed the original copy of the tag to the inventory item and retained the copy.

Upon completion of a count area, each count team returned to James, who verified that all tags were returned. He also checked the map to see whether there were other areas of the warehouse which had to be counted and assigned the teams to the new areas and issued them new blocks of count tags as necessary.

James then entered the tag information into an online data entry form. Upon completing the data entry, he printed a report showing all tag numbers entered, sorted by tag number, and looked for any gaps in the numbers. He investigated any numbering gaps that he came across and ensured that all count tags issued were included in the file.

The day came to a close at 6 pm. James informed me that he would investigate a few unusual results that he came across the following day.

I thanked James for taking me through the entire process of counting inventory. I was glad that observing the entire process had given me a good idea of how the asset management module of the Governance, Risk and Compliance (GRC) management system should be developed.