A while back, I wrote a series of posts regarding three distinct levels of Business Analysis (Strategic, Tactical, and Operational). That was also the topic of my presentation to a couple of IIBA Chapters last year. Since then, I have received a lot of questions about how that breakdown fits into the lean, agile world of software development today. My answer is pretty simple. I think that using 3 separate levels of business analysis is a prerequisite for keeping your requirements processes lean.
Strategic Business Analysis Identifies Lean Initiatives
One of the core principles of Lean Analysis is talking to the right people at the right time. Strategic business analysis is only effective if you have the right level of decision-makers. In a smaller organization, that may include the owner(s) and/or C-level executives. Larger companies can delegate that authority to Directors or Senior Management. Governmental agencies and global corporations need localized strategies to succeed and often allocate the power to the authority closest to the action.
Regardless what titles you have in the group, Lean Strategic Business Analysis identifies the key projects to address current pain points at the lowest cost. Deferring decisions until the “Last Responsible Moment” ensures that the identified projects are the highest priority at the time the decision is made.
Get Results Fast!
call 702-625-0146
Tactical Business Analysis Should Always Be Lean
Once an initiative has been approved, it’s time to seed the product backlog. Assuming your organization has embraced the Agile approach to software development, you will focus on defining the product in terms of User Stories, Epics, Features, and Examples. In a traditional environment (e.g., iterative or waterfall), you are presumably developing stakeholder-level requirements here. In either case, it is crucial to get input from everyone who has the knowledge and authority to define product features. Those are the right people to involve. To avoid waste, this work should only be initiated when project initiation is imminent. Monitoring all of those criteria will keep your Tactical Business Analysis lean.
Targeted (aka Operational) Business Analysis Is By Nature Lean
Targeted Business Analysis is all about building quality in from the outset (another key Lean principle). This is where the Product Owner, Business Analyst, Subject Matter Expert, User Story Author, or whatever role represents the business community must ensure effective communication with the Agile team. Any technique that contributes to the verifiable, common understanding of the product’s features at this level of detail is a lean technique.
Whether you use physical examples, process diagrams, object models, or any other tool depends on the comfort level of all participants. That means both the person expressing the requirements and the one implementing them actually agree up front on what the product will deliver. The common understanding is essential to meeting the lean principle of avoiding rework and increasing value to the end customer.
Targeted business analysis is best done by people who know lean and agile business analysis techniques and when to apply them.
The Ultimate Goal of Lean is Value
The more value you deliver at the lowest consumption of resources (i.e, cost), the more successful your product will be. Allowing lean principles to guide your business analysis activities is the best way we currently have for producing the highest quality outcome at the lowest cost.
By keeping Strategic, Tactical, and Targeted Business Analysis apart, you can contribute by staying focused on delivering your development team the right level of detail at the right time. That is the best way to minimize the effort required to deliver quality business analysis outcomes.
