As a Business Analyst, I often find myself caught in a cycle of endless revisions for requirements documents. I want to use Lean principles to "Lean out" our BA process. Would a SIPOC diagram (Supplier, Input, Process, Output, Customer) be useful for mapping our internal stakeholder requirements? Also, how can we use the concept of "Just-in-Time" (JIT) for documenting user stories so we don't spend months detailing features that might get de-prioritized later?
3 answers
A SIPOC diagram is a fantastic "High-Level" Lean tool for BAs to define the boundaries of a project and identify exactly who provides the requirements (Suppliers) and who consumes the final product (Customers). To address your revision problem, focus on "Just-in-Time" (JIT) requirements. In a Lean BA workflow, you only document the high-level "Epic" early on. Detailed "User Stories" and "Acceptance Criteria" are only written just before the development team is ready to pull the work into a sprint. This prevents the "Waste of Inventory"—which in your case is a stack of detailed documents that become obsolete before they are ever used.
Are you currently facilitating "Gemba Walks" to actually see how the end-users interact with the current system before you start writing your new requirements?
Use the "5 Whys" during your elicitation sessions. It’s the simplest Lean tool to get past the symptoms and find the actual business problem that needs solving.
Exactly, Cynthia. Most stakeholders ask for a "Solution" when they should be describing a "Problem." The 5 Whys is the best way for a BA to bridge that gap.
Robert, I started doing "Virtual Gemba Walks" by watching recorded user sessions. It was an eye-opener! I saw users struggling with "Workarounds" that they never mentioned in our formal interviews. This Lean approach allowed me to identify the "Real" pain points (The Gemba) rather than just documenting what people said they wanted. By combining this with a SIPOC, I could clearly show the stakeholders how the current "Process" was failing the "Customer." It reduced my rework because the requirements were based on observed reality, making them much harder for stakeholders to dispute later on.