Perhaps even more than planning for elicitation, planning the business analysis approach will set a mature business analyst apart from the crowd. The purpose of ‘Plan the Business Analysis Approach’ is to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted and informed of the approach, and the rationale for using it.
Although the BABOK is not a methodology, that doesn’t mean the BA is off the hook for creating a methodology in the context of their project or organization. And this is the task where that methodology, more generally called an approach, is put together.
First, BABOK distinguishes between plan-driven approaches and change-driven approaches, noting that most methodologies are somewhere in the middle. Plan-driven approaches focus on minimizing upfront certainty – we might think of “pure waterfall” (if such a thing even exists anymore) as a pure plan-driven methodology. Change-driven approaches focus on rapid delivery of business value in short iterations. The most visible example of a change-driven approach is agile, though continuous process improvement initiatives such as Six Sigma would fall under this category as well.
An important note is that the BA methodology does not live in isolation – it is either part of or integrated with the methodology for the project, which will cover many other aspects of delivering the project in addition to the requirements development effort. By the time you’ve defined your BA methodology, you’ll have a good idea of the role of the BA for this project, timing of BA work, formality of BA documentation, approach to requirements prioritization, change management process, business analysis planning process, and any requirements management tools you’ll employ.
This is quite a lot of decisions to make! My formal experience in this area is somewhat weak. The reality is that I’ve done individual pieces of BA planning often, such as choosing a prioritization scheme. Others I’ve done informally, such as timing the BA work with the project and choosing a level of formality that suits the project.
Instead of upfront planning to figure this out, I often approach timing and formality through trial and error. Sure, I’ll start by asking about expectations and look for guidance, but instead of starting from scratch, I’ll leverage something from my repository of templates (which I’ve now made available in the BA Template Toolkit), ask for feedback, try something different, rinse and repeat. I have also worked in many smaller environments where we are building the BA practice from scratch and my stakeholders just don’t know what they don’t know about what they want from a BA. So instead of diligent planning, eyes-open trial and error tends to lay out an approach most efficiently.
There is one story I have to share where I truly did complete a much more rigorous plan. I’ve written a few times about my role in helping consolidate technology systems from 5 disparate organizations. In this position, I hired first one BA, then a second to help support the project. With more than one BA on the same project, a defined approach became essential. We developed some common templates and set expectations about the level of granularity of requirements within each template. We defined some common ways of working with a very large stakeholder group and prioritizing requirements. We explored potential tools to store and manage requirements, first using Excel spreadsheets and a SharePoint site, then exploring DOORS and other configuration management tools. This was one area that we iterated through several times throughout the project and modified as plans for delivering the solution changed.
This post is one installment in our Journey Through the BABOK with BA Stories series.
Kick-Start Your BA Methodology
The Business Analyst Template Toolkit includes a set of fully annotated business analysis templates you can use to develop your BA methodology or plan for your next project.