Gathering and documenting requirements to develop software is often seen by business analysts as their core task. Actually, they are there to deliver value to the business—everything else is secondary.
One of the first things I ask aspiring business analysts is how they see their role. Invariably, the answer is “to gather and document the requirements”. If questioned further, they will add “to develop the software”.
Sure, these tasks are important but they are really just mechanisms for fulfilling the real purpose of business analysis: to deliver value to the business. I was really pleased to note that this orientation away from the mechanics of what we do (requirements gathering and software development) to the desired end goal (value) is highlighted in the latest version of A Guide to the Business Analysis Body of Knowledge, usually known as BABOK.
BABOK’s focus on value as the key deliverable of business analysis is evident in their list of Business Analysis Core Concepts (page 24). This is a new concept and, incidentally, a new acronym to add to your collection: BACCM. These core concepts are:
Change: The act of transformation in response to a need.
Need: A problem or opportunity to be addressed.
Solution: A specific way of satisfying one or more needs in a context.
Stakeholder: A group or individual with a relationship to the change, the need, or the solution.
Value: The worth, importance, or usefulness of something to a stakeholder within a context.
Context: The circumstances that influence, are influenced by, and provide understanding of the change.
Please note that there is no mention of requirements at all!
All these concepts are important, of course, but I thought it would be useful to expand a little on the three that speak to this concept of value.
Need. I always tell business analysts that they first need to understand why they are doing what they are doing—and then never forget that everything they do has to satisfy that need. Not knowing where you are going is a sure guarantee of ending up in the wrong place—see my article “Projects and the taxi ride”. The definition of these objectives should always pass the SMART test: specific, measurable, achievable, relevant and time-bounded.
Value. The notion of value adds what I always thought was SMART’s missing element. Value is, after all, a fundamental business concept, and yet I could count on the fingers of one hand the number of business analysts who do a proper cost/ benefit analysis before embarking on a project, even it’s a large and costly one. I cannot understand how it’s possible to invest large amounts of the company’s money without a clear understanding of what the return on that investment will be.
Even those business analysts that do a cost/ benefit analysis seldom revisit the assumptions made to check they are still valid. We should constantly test our core concepts to ensure that if our assumptions we made about them still hold true. (As BABOK puts it: “If any of the core concepts experience a change, it should cause us to re-evaluate these core concepts and their relationships to value delivery.”)
One new technique introduced in this version of BABIK is Estimation, and it can be used to help keep an eye on the cost/ benefit of the project during the early stages of the project, before a decision is taken to go ahead or not. Early estimates are based on projected costs—the term used is “rough order of magnitude”. Rough really is the word, because this estimation’s is only expected to be within 50 percent of the actual cost—a substantial margin especially on a large project. The point is that as the project-scoping work advances, it is important to refine these estimates so it’s possible to answer the question, “Is this still worth doing?”
Estimation will help to avoid those projects that run over budget and time. One study, reported in the Harvard Business Review, found that one in six projects surveyed had a cost overrun of 200 percent and went over deadline by 70 percent.
Solution. Selecting the right solution is one of the main drivers for ensuring that business value is delivered, but all too often the business analyst is only introduced onto the project once the solution has been decided. It might be a new piece of software, or customization of an off-the-shelf application.
BABOK tries to avoid this happening by including a task called “Define the future state”. It requires the team to look more broadly at the issue, and explicitly sees software as only one element of the potential solution. For example, changing certain procedures or improving user training might be all that is necessary in order to reach the desired future state.
If, indeed, there is a requirement for new or customized software, then the business analyst has to go ahead and elicit the full set of Business and Stakeholder Requirements, in BABOK-speak. Only then can he or she confirm that the future state and its anticipated value can be delivered.
In summary: we business analysts have to understand that our role goes further than just gathering the requirements for a software development project. Following BABOK, we need constantly to keep our eye on all the core concepts, and if they change we need to highlight the impact of that change to the business—all with the aim of delivering a solution that delivers the expected value.
In a word, business analysis is all about value—nothing else really matters.
** A Guide to the Business Analysis Body of Knowledge and BABOK are trademarks of the International Institute of Business Analysis.
This article was published on ModernAnalyst.com http://modernanalyst.com/Resources/Articles/tabid/115/ID/3489/Get-with-the-BABOK.aspx