One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements. His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…”
What you call your requirements is less important than how you communicate them.
Labels
I’ve worked with a lot of companies that use different labels to describe their descriptions of the problems that need to be solved. This is not another article about requirements versus specification (specification = design constraint, btw).
If you’re not a long time reader who’s followed the debates and discussions on this topic in the past, check out these articles and comments, where we’ve had some great discussions on that topic – with particular thanks to Roger Cauvin for keeping the debate front and center.
The central theme is that the debate about “what versus why” centers around differences in people’s perspective on the problem.
This challenge is not really about that (but it makes for good background). The complaint my colleague received was really a critique of the way that the why of a set of requests was communicated and labeled.
Actionable Goals
Companies have strategic goals (increase shareholder value, gain market share, etc) that serve to guide the investments and activities of the organization. However, for the teams that are creating products, those goals are too vague to be actionable. I guess this is where my set of labels comes in. I don’t think the labeling of a goal as a goal (versus labeling it as a requirement) is abstractly important, however, when people value making a distinction, here’s how I do it.
A goal is something your business (or user) is trying to achieve. It is too abstract to have a single valid solution approach. Once your business stakeholder(s) decide on a strategy by which they will achieve that goal, the business will define requirements for the actionable project(s) that execute this strategy. This is an ideation step that lives inside the “why” box from a business analyst’s perspective. Here’s an example:
Warehouse Manager
You’re in the IT department of a large company. You’ve been assigned to support the warehouse manager (or COO, or vice president of order fulfillment or whatever). Your warehouse manager is responsible for procuring the products that your company sells, keeping inventory on hand, and delivering those products to customers when they have been purchased.
Your warehouse manager is measured (or promoted) based on her performance relative to the following:
- The time that a customer has to wait between placing an order and receiving the product.
- The cost impact of warehouse operations on the products.
Your warehouse manager focuses on these two metrics because of your company’s goals – provide good customer service, be profitable, and grow revenue. Those abstract goals influence product pricing – it must be low enough to grow revenue in the target markets, and be high enough to be profitable. Since market pressures drive pricing decisions, typically a profitability target will then create cost-reduction pressures (profitability also influences pricing decisions, selection of markets, positioning within that market, etc). A customer service strategy can also include a “you get your product quickly” component – as it does in this example.
Your warehouse manager now comes to you and says “I have an initiative to lower costs.”
Is this a goal or is it a business requirement?
Ultimately, it doesn’t matter what you call it, but for you to actually do something you need to know more. That’s why my approach is to call it a goal. Your warehouse manager’s problem is to lower costs. You need to decompose that problem to understand how you (and your team) can do something to help her achieve that goal. The reason you have to do that is that you need a problem statement at the right level of abstraction.
In elicitation conversations with your warehouse manager, you learn that all of the costs of operating the warehouse are allocated to the different business units, who operate as profit centers. The warehouse operates as a cost center. The warehouse manager treats each business unit as a customer, and provides a service of “fulfilling product orders” in exchange for funds that cover the costs of operation. The allocation of costs is done per product that appears in the warehouse. Since allocation is per product, it could be something like $1.30 per product in “warehouse costs.” There are multiple sources of those costs (that are then allocated per product), and there are multiple ways to approach reducing the cost per product.
Your warehouse manager develops a strategy (probably a “mini-strategy” from the company’s perspective) to lowering costs. She rules out “sell more products” as an approach, because she can’t control that. She also can not affect her fixed costs (rent, depreciation, labor).
Eventually you discover that there is another cost hidden in the provisioning model – products are purchased, they sit in the warehouse for a while, then they are sold and delivered, and eventually money is collected from customers to pay for the products. Your company has to pay in advance for the products, and doesn’t get their money back until funds are collected from the customers. That money is “tied up in inventory” when it could have been invested otherwise – so there is a cost associated with high inventory levels, that directly correlates with the amount of inventory in stock. When a new version / revision of a product is introduced, your inventory may become obsolete (it is definitely devalued). And since markets are moving targets, your prospects of selling a product change over time – a risk that you will not be able to sell all of your inventory.
At the end of the day, the amount of inventory you have on hand has a cost. The more you have, the more it costs. A rule of thumb I heard 20 years ago was that inventory costs could be as high as 1/3 of the cost of the product for each year you keep it around. If that is true, that is something like 0.5% added cost for every week the product is in inventory. Here’s something the warehouse manager can potentially control.
Currently, your warehouse manager has 8 weeks of inventory on hand (on average) for products, which allows her to ship quickly. She realizes she is adding 4% to the cost of the product. She decides that if she can cut those costs in half, she will be a heroine.
Her business requirement is to reduce inventory levels from 8 weeks (on average) to 4 weeks (on average). She also has a constraint that no more than 1% of orders be delayed by more than a day (due to running out of inventory).
Now you have requirements that are unambiguous and measurable.
Conclusion
Don’t trap yourself in worrying about the labeling of goals / requirements, but if you have to work with someone who does find that really important, before you call it a requirement, make sure it is at the right level of abstraction. And of course, make sure you follow the rules of writing requirements.
I think the simplest way to make this distinction is internal vs. external.
A business objective or goal is internal. It may even be possible to achieve it without building or selling a product, or without affecting customers one bit. It addresses a problem that exists from the perspective someone within the company selling the product (e.g. “our market share is too low”).
In most cases, a requirement is external. It addresses problems that prospective or existing customers face. There may be exceptions, such as when an internal department places a constraint on the product, but these constraints are on functionality that affects external stakeholders.
Now, this distinction becomes a little confusing when the “customer” is internal. But the point remains that it’s all about defining who are the “buyers” and “users” of the product, and who is trying to achieve goals by “selling” it.