When working with new and even some very experienced business analysts, I often receive the following questions about the Business Analysis Body of Knowledge® (BABOK®) Guide:
Should we use the BABOK process?
Do I need to understand how to follow the BABOK methodology?
How can we apply the BABOK framework in our organization?
The idea that the Business Analysis Body of Knowledge contains a business analysis or requirements development process is a common misconception. The BABOK professes to do no such thing and we’d make a huge mistake if we use it that way.
The BABOK represents the collection of activities that make up business analysis. It’s the stuff that we BAs do. It’s not a process or a methodology.
At the risk of being self-referential, here’s the BABOK definition of a business process.
A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization.
Here’s a quote right from the master of the BABOK himself, and VP of Professional Development at IIBA, Kevin Brennan:
The Guide to the Business Analysis Body of Knowledge is not a methodology. While it defines the activities, tasks and knowledge that a business analysis professional needs to know, it does not do so from the perspective of prescribing an order or sequence.
While the BABOK is not a process, a careful reading of the BABOK might help you define your business analysis process. Because it collects together the set of activities that make up business analysis, you might find a technique or a way of thinking about a knowledge area that helps you improve your business analysis process. But the decision of what to do when needs to be yours.
The process that works for your organization or your project will be heavily dependent on the following factors:
- How is the BA role defined? And, what are the other roles on the project team?
- What type of project is it?
- Who or what has the knowledge about what needs to change? (This could be in people, such as subject matter experts, or documents, such as regulations.)
- What sorts of decisions about the project need to be made by the project team or organizational heads outside the project team and how will these decisions be made?
- How will the solution be implemented?
This last one might surprise you. While the early requirements documentation to scope the project might not be affected by solution decisions, the detailed documentation to implement the solution will definitely be. For example, you are not going to create a detailed functional specification if you are buying a third-party tool. That would be a ridiculous waste of effort. You would instead focus on your key features, your integration requirements, your customization requirements, and your data migration requirements.
On the other hand, if you are building custom software from scratch, you’ll likely create very detailed functional requirements.
Yes, turn to the BABOK for a list of ideas that you might consider and as a checklist of activities you might do, but don’t let it do your thinking for you. It’s simply not designed to achieve that objective.
Looking for more? I developed a business analysis process based on the principles I’ve found help me be effective as a business analyst.
>> Learn the Business Analysis Process
We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.