Using observation in project requirement gathering should come fairly early on in the process. By watching stakeholder and end users in action you can gain insight that’s not available from just conversation.
You’re going to want to use observation when your project is changing, adapting, or refining a product or process that’s already in use. If that’s the type of project you’re working on, we’re here to give you a rundown on how observation works.
We’ll cover:
- The projects that require you to make observations
- How to prepare for observation sessions
- The different types of observations
- The pros and cons of using the process
So that you have a thorough understanding of whether you need build observation into your project requirement gathering.
When to use observations
As useful as making direct observations can be, it’s not a good fit for every project. The process requires you to watch a system or product being used; if there isn’t anything at all to start you won’t have much to observe.
Here are the circumstances where making observations are going to be useful:
- When your objective is to make improvements to an existing product or process
- When the stakeholders are struggling to verbalise their requirements fully
- When the process is repetitive in nature
- When the validity of other data may be questionable
It’s also going to give you a taste of the working environment and culture that your end product is going to be used in.
If you’ve planned to use prototyping in your requirement gathering, observation of it in use will be vital.
Planning your observations
Observations need to be directed. Sending an analyst in with a blank notebook will produce piles of data that will take a long time to process.
There are things to have ready in advance to make sure your observations yield useful results:
- Figure out what data to collect, whether it’s looking for events, inputs, pain points, documenting processes; your analyst needs to know what to look for
- Decide how to make observations, whether it be passive or active. We’ll cover this more later
- Choose the best time for observing the process; you’ll probably want to be present at a normal time and at peak operations to understand any stressors
- Pick a method of data collection, such as note taking, voice recording, or taking a video. Which one works best will depend on the process being observed
The data that comes out at the other end of your observations should be quantitative and statistical. You should be looking for information such as frequency of process, the flow, timings, and steps to complete the process.
Types of observations
As we’ve just noted, there are two main categories of observation, passive and active. Which one you choose to use will depend on the project and what stage you choose to use observations in your requirement gathering.
Passive Observations
Standing back, out of the way of the activity, and not engaging in the process would be passive observation. The analyst will just watch and take records without asking any questions to the operator or end users.
This can work well for processes that should be intuitive. You can also use this when raw data is needed like process counts.
Active Observations
When the analyst gets involved in the process in some way, this is active observation. This can be in the form of asking questions between actions or even taking an “apprentice” style role to get inside the action.
Use active observations to really get inside a process. When you stakeholders can’t explain what they’re looking for, it’s best you experience the needs for yourself.
Weighing it up
The benefits of using observations include:
- Getting reliable data and information
- Making a full assessment of the environment
- Reasonably light on costs
- Clear statistical outcomes
Whilst some things to be wary of are:
- Not all exceptions can be captured
- Follow-up interviews will need to be carried out
- There’s a possibility of analyst bias
Conclusion
Your observations can come quite early on as you gather the project requirements. The things that you observe from the outside will feed into the questions you ask in a survey, interview, or during a focus group. It’s also a good starting point for reverse engineering. Observations in project requirement gathering will give objective insight into how your client works. This is invaluable to get your design process working for everyone.
