The business need is one of the most fundamental aspects of business analysis. Yet, I know many BAs do not consider themselves part of defining the business need. Today, I’d like to challenge your assumptions.
According to the BABOK, the purpose of defining the business need is to:
Identify and define why a change to an organizational system or capabilities is required.
Ah, yes, the infamous question: “Why?”
There are 3 elements of “why” referenced in the BABOK:
- Business Goals and Objectives – the ends that the organization is seeking to achieve. Goals being longer term and often qualitative statements. Objectives being more granular and objectively measurable statements.
- Business Problem or Opportunity – this is the crux of what we hear about most in BA circles, the problem to be solved. The BABOK empasizes that in order for there to be a business need, there must be an opportunity for improvement if the problem is actually solved. This is something I don’t think about often, because it seems so intuitive, but I suppose you could solve a problem but not really improve anything worthwhile.
- Desired Outcome – specifically “not a solution,” an outcome identifies the benefits resulting from meeting the business need.
All of these elements wrap together to define the business need, which is used as an input by more than 11 tasks in the BABOK. Obviously, discovering the right business need is of the utmost importance.
Do you consider yourself part of defining the business need? Many BAs do not. They might be recipients of the business need, but not active in this aspect of enterprise analysis. Â However, I’ve rarely met a BA that did not ask why (as well as a host of other requirements-related questions) and did not at least clarify the business need or participate in defining lower-level business needs to support larger business objectives.
If you read through the above 3 bullet points carefully, you’ll see that the BABOK is not specific about the scale of the need. A business need could result in millions in revenue or cost-savings or it could save your favorite stakeholder in accounting a frustrating 5 minutes of manual work each week.
One of the best representations of the criticality of the business need, is the syntax of a user story:
As a {user}, I need {to do something} so that {I can achieve some benefit}.
In agile, each and every component of work is tied to a business need. And this enables the team and the product owner to be clear about what success looks like and how to rank individual stories. Say what you will about agile development strategies, in the user story syntax, there is something deeply right going on.
I know when I worked on an agile project, the syntax brought clarity to the rationale behind each and every requirement and this diligence helped us stay focused and on track. Each story met a business need and each of these small benefits wrapped up into the larger business goals of the project. This sort of relationship is something I’ve brought with me from agile even as I tackle projects leveraging different methodologies.
A document full of “system shalls” (without a corresponding column for “benefits”) does not have this same rigor and leads us to think of the business need as something big and complex that lurks behind the conference room walls where only the special people get to understand what’s really going on. And this is sometimes true. Sometimes the goals and objectives behind the big programs and projects are held in secret and, even if public, they are delivered from above and you as the BA on a piece of that project might not have much to do in analyzing or confirming that need. But this does not give you permission to ignore the need or to become loose in your thinking on the more granular aspects of your requirements.
Do you define the business need? If so, at what level? Has this changed throughout your BA career?
This post is one installment in our Journey Through the BABOK with BA Stories series.
>>Â Learn How to Ask the Right Questions to Clarify the Business Need
Interested in receiving a comprehensive set of questions you can ask in almost any project context? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.
Click here to learn more about the Requirements Discovery Checklist Pack
I see that clarifying (or identifying) business needs is critical and of great importance. One critical thing about it is to see if the goals of the particular project are aligned with the organization strategy. As defined by BABOK, business need is a high level requirements of organization’s goals and objectives.
Pingback: Introduction to Lean Six Sigma | Professional Certifications
Pingback: From Programmer to Business Analyst: How to Snap Back from a Layoff after 35 Years with One Company | Learn Project Management
I appreciate the User Story format because it reminds me (and sometimes forces me) to consider the business need and benefit for each piece of the requirements. Sometimes I already understand the need, sometimes I need to clarify it, and sometimes I’ll admit that I get a little annoyed and wish I could just skip it and get to the functional requirements…but in the end, understanding and agreeing to the business need is always of benefit to the project & ultimately the user.
And that is just the perspective I need – for I do not want to just be creating requirements, I want to be a part of solving problems, helping users, and adding value to businesses.
User Stories are my friend. 🙂
In my organisation, the problem hasn’t been the customer failing to identifying a business need, the main problem has been identifying business needS(notice the capital S to make it plural). Most customers I have worked with in the past, come with a “one track mind”, failing to identify other problems or opportunities that easily fall within scope of the proposed project. It is my job as a business analyst to help them identify these further needs. This helps in creating a more comprehensive business case in their quest to justify their project. A proper current state assessment should take care of this.
Laura, that is a great question. We are seeing projects being approved without a full understanding of the business need – which creates more work for the project manager to ensure that the buisness need is clearly defined when the project arrives at their doorstep. If we did not have project managers completing this due diligence then the project would be at high risk of failure.
Not only should the business need be understood, re-visited and re-validated iteratively, it should be communicated to all involved team members to remind and motivate them of the value of their work.
I have encountered far too many staff (IT) who do what they’re told without knowing why or what benefit the project brings to the organization. Try this tactic. Ask an IT member the reason for the project and measure their response against the original business need.
Being kept in the ‘ why ‘ loop serves to gel the team closer and appeals to their inner self to go the extra mile striving for success.
Several companies ago, I was able to define the business need – which was a powerful gift. The entire company ran on the idea that the business people know what they need to change. We were encouraged to identify business needs and projects with the benefits.
I worked on the projects that I identified the business need which was even more satisfying being able to see a project to fruition.
Several companies later, I am able to identify a business need – but no one wants to listen. This company will get there some day, just not right now 🙂
Rooting for you to help this company recognize the importance of the business need, Michelle! In the meantime, what negative consequences are you seeing of the business need not being clearly defined?
In too many government projects the business need is often hidden behind the “system shalls” in a procurement document. As an analyst my job is certainly to clarify these requirements and ask why they need this or that. But often the contract requires us to deliver certain “system shalls” and then its impossible to make bigger changes and difficult to make even smaller ones.
Karl, Thanks for sharing your perspective from a government project. It’s always interesting to learn how other BAs work. It sounds like you are doing the second-best thing, which is to take the time to understand the business need in the context of each requirement, even if your documentation does not support this. Just out of curiosity, do you capture this insight so that you can refer back to it if needed? What kind of changes do you find yourself needing o make that are difficult to impossible because the business need is not incorporated into the procurement document?
Laura
I don’t think that I necessarily define the business need so much as I help to elicit and clarify it. I believe that the analyst has an obligation to ask “Why?” as much as possible to help in the clarification process of stakeholder needs in order to validate them as true needs. This is an important task that occurs early in the project and helps to set the stage for agreed upon work (and what the team should not be working on).
I also think that while the needs are validated after initial documentation early in the project, this is really an ongoing process throughout the life cycle. Continuous validation is necessary to circle back to the original meanings or descriptions as new knowledge is acquired during requirements discovery, and it helps to keep a level eye what was originally understood. Ensuring that this comprehension doesn’t change is important, but identifying a needed change in understanding could be even more critical to a successful project.
Finally, it’s not uncommon to identify new needs as a result of the same knowledge acquisition process. This isn’t to say that we should throw open the doors for scope creep to barge in, but we should evaluate new needs with the same criteria that was originally used and the determine when and how they should be included if necessary.
Thanks!
Doug,
What a great way to clarify the language here. I often find myself in a similar position – clarifying the business need on behalf of the sponsor and user group. Define, on the other hand, seems to indicate that as the BA I own determining what the business need is. I wonder why the BABOK writers chose “define” and if we’re missing a nuance of this task here?