Join Haydn Thomas for an in-depth discussion in this video Observing a job to gather requirements, part of Business Analysis Foundations.
- I started a new role with an electronic payments company back in my mid 20s. My boss at the time asked that I do nothing for the first six weeks other than spend time in all areas of the business and watch what they did. I thought he was crazy. Little did I know, this would be one of the best lessons a budding business analyst could learn. Using observation techniques are best applied where a current process is to be monitored, the objective is to improve a process, stakeholders find it hard to explain what they do or what their requirements are, processes are highly repeatable, example manufacturing, and the validity of data collected through other means is in question.
Assessing a process or system from a user's interaction perspective is an instant way to elicit requirements. Assessing the actions undertaking a stakeholder's work environment enables you to watch them perform their work in order to understand the flow and sequence of the activities. Processes are used to create outputs, and a system's just a collection of like processes. Each process takes inputs, performs activities, and creates outputs.
These outputs become inputs to the next step of the process and so on and so on, until the final deliverable is achieved. Observing these processes can be performed passively through job shadowing where you capture the steps and work routines being undertaken. And the observer waits until the end to ask any clarifying or qualifying questions. Or actively, engaging with the stakeholder throughout the performance of the work, and capturing why things are being done and why are they done that way.
Regardless of the approach you choose, prior preparation and reassuring the stakeholder as to why you're doing this is needed. Capturing the activities, steps, and decisions being made can be best documented through the use of individual process flow charts or activity diagrams, commonly known as swimlane diagrams. Process modeling is a visual representation of the sequential flow and control logic for a set of related activities and actions. Swimlane diagrams show these activities and captures who performs them.
Each role or actor has their own lane, so when a flow of work crosses the lane, the responsibility for that work passes to another person, functional area, or organization. Both methods are effective at showing how to handle a large number of basic, alternate, and exception scenarios. These diagrammatic tools are a great way to capture the current as-is state. By the end of my six weeks of watching, I was painting a picture in understanding how the organizational groups and process came together, how the products were developed, how they were manufactured, how they were configured, how they were shipped, how we serviced them, and how we could do these things a whole lot better.
Quite by surprise, I had a large list of suggestive improvements which we now know as requirements. After capturing the current as-is state processes, it is time to turn our attention to designing requirements for the future state. There are a number of factors to consider in this phase to find the best conceptual design while staying within the project's scope and fulfilling the business and users' needs. Applying the KRAC approach assists in starting to design the future to-be state.
Review each step of the process and determine what is working and what they want to keep and what is obsolete and need to remove, what is missing and need to add, and finally, what is not working and needs to change. With these four things in mind and all the information we have gathered during initiation and analysis, verifying them with the people you have been observing, this creates a good start in determining the future to-be state. To this very day, I'm extremely grateful to my old boss' crazy approaches as they continue to help me in being more professional and rounded business analyst that truly understands the value of watching people and processes in action.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.