Often when a business analyst is assigned to a project, they are presented with information about the project. Typically, they are given a product concept and perhaps some product features and qualities already defined. A few success metrics may exist, such as the product launch date. From here, the business analyst is expected to carry on and define the rest of the requirements necessary.
And while this approach realistically will not change, why not back up a bit and try to understand what problem the product is trying to solve? Businesses start IT projects because they are trying to solve a problem. Those problems are generally related to revenue, costs or compliance.
- Business problems related to revenue generally revolve around the need to make more money.
- Those business problems around costs relate to costs being too high, and the desire to lower operating costs of the organization.
- Compliance problems arise when the business has a regulatory or compliance issue that they must address or follow.
On the surface, it might seem that the Business Objective for a particular problem is to solve that problem. However, Business Problems rarely articulate the specific metrics that a business is trying to achieve. It’s the metrics that help us measure whether or not the problem has been addressed.
Defining Business Objectives
It can be difficult to get the business users and stakeholders to articulate the business objectives. Many times, they may feel that IT does not need to know why a project needs to be done; they just need to follow orders and do it. Other times, the stakeholders do not want to be measured. And sometimes, the various stakeholders do not agree on the business objectives. This is an opportunity for a BA to use their leadership skills and powers of persuasion to get the business stakeholders and users to understand the importance of business objectives.
So how do you get the business objective? Start by ensuring you understand what the business problem is by asking, “What is the business problem that you are trying to solve?” Keep asking, “Why is that a problem?” until you get to the money, cost or the regulatory answer. Once you get an answer that involves money, costs or compliance, you have the business problem.
Now that the business problem has been articulated, ask, “What metrics can we use to determine that we have solved the business problem?” While this sounds like an easy question to ask, it is not an easy question to answer. The metrics need to be as specific as possible. For example, “increase levels of customer service” is not a good metric because it does not define how much the levels are to be increased. Further, if customer service is increased by 1%, does that solve the business problem? Probably not. You need to push the business stakeholders and users to be as specific as possible when it comes to defining the metrics for the business objective.
Here are some examples of business problems and their objectives:
Moving from Business Objectives to Strategies, Success Metrics and Guidelines
After measurable business objectives have been defined, then determine what strategies could be used to achieve the objective. There may only be one strategy, but often there are multiple ones. Once a strategy has been chosen, develop a clear product concept. The product concept is the proposed solution to accomplish one or more business objectives. The product concept may or may not be the same as the original product concept, but at least you will be confident that the product concept will help achieve the business objectives.
Success metrics should also be defined. Now that you have a product concept (and a project), how will you know that the project is a success? Success metrics are statements about the specific desired outcomes to meet the business objectives.
Guiding Principles are the guidelines that the stakeholders want or need BAs to follow. For example, the training manager may wish to minimize the amount of changes that the training materials will need to undergo, and thus asks that the general workflow for the system be kept the same. This is something that needs to be considered early in the project, especially if it conflicts with one of the business objectives. But isn’t it best to discover such conflicts early in the project, so they can be sorted out then and not after the product has been developed and tested?
Using Business Objectives to Control Scope
After defining measurable business objectives, determining strategies, defining success metrics and establishing guiding principles, the features for the product or solution are addressed. The features start to describe what the product should be able to do. As a general rule, features:
- Provide a specific piece of functionality to the user
- Can be linked to a measureable business objective
- Can to a limited extent be analyzed independently of other features
If a feature cannot be linked to a measureable business objective, then the feature should not be included in the product. Many times a feature will be added at the request of a stakeholder of the project because it is “cool” or “slick.” But if it cannot be linked back to a business objective, it is out of scope. In this way, business objectives give you an objective way to say “no” and to control scope.
While features describe what a piece of software is supposed to do, Product Qualities provide information about attributes that we want to see in the software that are independent of the specific functionality of the system. Most of these Qualities map to particular types of non-functional requirements. For example, requirements that discuss the scalability of the software or the speed of the software are non-functional requirements that describe Product Qualities.
From the features, the functional requirements are defined; from product qualities come the non-functional requirements. As all requirements are being defined, they must be tied back to a business objective via the features and product qualities. If the requirement does not tie back, then it is out of scope for the project, and the BA team can kill those that do not tie back.
Don’t forget to leave your comments below.
Betsy Stockdale is a requirements architect for Seilevel, a professional services firm that specializes in helping Fortune 1000 clients redefine the way they create software requirements, in order to enhance their business outcomes.
Powered by Facebook Comments