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.
I was trying to find this thread again by searching “methodology” and it wasn’t found. Not sure how you add that to the keywords for the index.
It does sound like I need to dig out my copy of the Software Requirements Memory jogger and do a little more “jogging” 🙂
Pingback: BA Stories: Business Analysts Plan to Plan (BABOK 2.3) | The Agile Radar
Is there any good websites or books on BA planning?
Great question, Tom. I think just about every book I’ve read approaches the requirements process from a perspective of inherent planning, but does not deal with this as a separate topic in and of itself, like the BABOK does.
Do others find this as to be the case as well? Are there resources out there that help a BA plan the approach for a project? Or is this something we need to create?
I have an advantage and a cause on this one, as a Requirements Consultant with a consulting firm. We obviously have a methodology we use in our engagements, so it is very possible to have to (a) have one, and (b) use it effectively.
I think one point to consider is that selecting the BA approach, and to some extent BA planning in general, is more demanding when one starts an engagement with an organization. The BA approach, and some of the general BA planning, tends to be somewhat similar from project to project WITHIN AN ORGANIZATION. Therefore when one starts working at a new organization more time considering the BA approach and doing BA planning is necessary. After one project (assuming everyone was happy with the outcome) the same approach can be adopted, and much of the planning is probably still relevant (the BABOK incorporates this idea by referencing the Organizational Process Repository).
This doesn’t mean that one should never consider changes to the approach or the BA plans/templates, etc. But once you have determined where an organization sits in relation to their comfort levels with the Plan-driven vs. Change-driven continuum, that won’t change quickly (although it still might vary somewhat from project to project). Also there is a benefit in consistency (using established norms for communicating requirements, or prioritization, etc.) and therefore the BA plan (or BA communication plan) becomes a minor variation on the plan used the last time.
In other words, when you first start at a new organization, there is a lot more planning (and pre-planning) to be done, but after one has some experience at an organization, the planning becomes more like tailoring a defined processes.
In my latest contract, the team is using my projects as a learning to follow a specific approach to business analysis. This means that I am completing the requirements management plan. This document clarifies for the project manager and team members what my role is and my approach to the project.
Even though this is a well defined document, I find that the only one who really looks at it is the project manager. I believe it would be of interest to many members of the team.
My current PM is asking for further clarification in the document – which is really cool – what estimated amount of time do we think requirements gathering will take from each person. Since this is a global project, this is a huge task to put together but very important.
Learning all the time! 🙂