The meeting started with a familiar sentence: "We need a dashboard." Nobody said it with bad intent. Support wanted fewer escalations, sales wanted clearer customer status, and management wanted a number they could see every morning. The request sounded concrete enough to become a ticket.
A Lean BA pause changes the room a little. Instead of asking what fields should be on the dashboard, someone asks what decision the dashboard is supposed to improve. Is the real problem slow response time, missing ownership, duplicated data entry, unclear customer segmentation, or a process that no chart can fix?
Source note: This series is based on a local Markdown guide about Lean Business Analysis, which synthesizes ideas from Emrah Yayici, PMI, and Business Analysis For Dummies. I am treating it as working material, not as a replacement for the original books.
Business Analysis Is Not Only a Job Title
One useful reminder from the material is that Business Analysis is a set of activities before it is a job title. A BA may do it formally, but the work can also be shared by a Product Owner, Product Manager, Project Manager, systems analyst, designer, QA, tech lead, or developer when the team needs to understand a business problem before shaping a solution.
That matters because many teams think BA is missing only when there is no person named "Business Analyst" on the org chart. In practice, BA is missing when the team starts building without a shared view of value, stakeholders, constraints, alternatives, and success.
| Weak starting point | Lean BA question | Better artifact |
|---|---|---|
| "Build this report." | What decision will this report change? | Decision statement and success metric |
| "Automate this process." | Where is the waste today? | Current-state process and pain points |
| "The competitor has this feature." | Which customer need does it serve for us? | Problem statement and options |
| "We promised this in Q3." | What risk increases if we do nothing? | Business case and urgency rationale |
Lean BA Starts with Value
Lean Business Analysis keeps asking a simple question: what is valuable enough to justify the next unit of attention? The answer is not always revenue. Value can be reduced operational cost, shorter cycle time, fewer errors, lower compliance risk, higher customer retention, better employee experience, or a clearer strategic position.
This is where the Lean lens helps. It asks the team to remove waste from analysis itself: unnecessary documents, duplicated approvals, premature detail, and long handoff chains. But it does not mean skipping thinking. It means doing the smallest amount of analysis that gives the team enough confidence to take the next responsible step.
For example, imagine a finance team requests an approval workflow for vendor payments. A non-Lean response may document every field, build a form, and route it through five approval levels. A Lean BA response would first check the value stream: how many invoices are delayed, where do mistakes occur, who currently waits for whom, which approvals are legally required, and which approvals exist only because nobody trusts the upstream data.
Sometimes the solution is a workflow. Sometimes it is cleaner master data, a threshold rule, a policy change, or a smaller exception queue.
Needs Assessment Protects the Team from the Wrong Problem
The most expensive requirements are not the ones that take long to implement. The most expensive requirements are the ones that are accurately implemented for the wrong need.
Needs Assessment gives the team a way to slow down at the right point. It usually starts with a problem or opportunity statement, then moves through observation, root cause analysis, gap analysis, feasibility, and a business case. This is not bureaucracy when done well. It is a lightweight insurance policy against confident waste.
A useful pattern is to go to the place where the work happens, often called Gemba in Lean language. Instead of hearing only that "the CRM is slow," watch a sales rep update an opportunity after a customer call. You may find that the page loads acceptably, but the rep has to copy data from an email, search for the right account, ask operations for contract status, and guess which field drives the pipeline report. The word "slow" was true, but not precise enough.
Then use root cause tools without turning them into a workshop performance. The 5 Whys can be enough:
- Why are renewals delayed? Because account managers do not see contract risk early.
- Why do they not see it early? Because risk signals live in support tickets and billing notes.
- Why are those not visible in CRM? Because integrations only sync customer identity and invoice status.
- Why was risk not included? Because the original CRM project focused on sales forecasting, not renewal operations.
- Why did the scope miss renewal operations? Because customer success was not treated as a primary stakeholder.
The requirement may still become a dashboard, but now the dashboard has a sharper purpose: surface renewal risk from support, billing, and usage signals before account review.
Business Case Is a Decision Tool
A business case does not have to be a thick document. Its job is to help decision-makers compare options honestly. The best business case I have seen is often a few pages with enough clarity to say yes, no, or not yet.
At minimum, a practical business case should explain the problem, affected stakeholders, current impact, options considered, expected benefits, costs, risks, constraints, assumptions, and how success will be measured. When the team has several possible solutions, a weighted ranking matrix can make hidden preferences visible.
| Option | Value | Speed | Risk | Maintainability | Comment |
|---|---|---|---|---|---|
| Build custom workflow | High | Medium | Medium | Medium | Fits process, but creates ownership cost |
| Configure existing tool | Medium | High | Low | High | Good first step if process can adapt |
| Buy specialist product | High | Medium | Medium | High | Useful if capability is strategic and recurring |
| Do nothing | Low | High | High | High | Still a choice; risk must be named |
Financial analysis can add discipline: ROI, payback period, NPV, IRR, tangible benefits, intangible benefits, and sunk cost awareness. But the numbers should serve judgment, not replace it. A precise spreadsheet built on weak assumptions can be more dangerous than a rough estimate that clearly says what it does not know.
A Small Checklist Before Requirements
- Can we state the business problem without naming a solution?
- Have we observed the current work, not only heard the complaint?
- Do we know who benefits, who changes behavior, and who may lose something?
- Have we named at least two solution options, including doing nothing?
- Do we know the smallest evidence that would prove this is worth continuing?
The calm habit here is simple: do not let a requirement be the first sentence of the conversation. Start with value, then need, then options. Requirements become much healthier when they arrive after that.