The Missing Measurement
The Missing Measurement
In these times, many of us are being told to "do more with less." A more useful approach is "invest our organization's scarce resources where the return is the greatest." To do so, we must define the financial benefits sought when developing a system in addition to its requirements.
When an organization purchases new equipment, it expects that investment will, in some way, improve its products, services, productivity, or quality. If the purchase cost is significant, the organization will first compute the expected return on investment to quantify the monetary gain that will be achieved. If this gain does not exceed a specific threshold (for example, the return that could be achieved simply by investing the cost of the equipment in an interest-bearing account), then the purchase is not economically justified and probably should not be made.
During the life of most software projects, we measure and track schedule, cost, benefits, and quality. These measurements help direct our efforts as the project moves forward toward completion. However, after the project is completed—with the software installed, the most immediate defects removed, and the users busy at their keyboards—we may and, in fact, should ask, “Was this a good investment of our organization’s limited resources? Did we achieve an acceptable return on our investment?”
Unfortunately, many organizations cannot answer this question because they failed to specify the business requirements of the product before the project began. Most organizations define functional and non-functional requirements, user requirements, and business rules. These are vital because they define the product to be created and allow us later to evaluate the product against these specifications. But, these types of requirements say nothing about whether the organization’s investment was a good financial decision.
Business requirements define the high-level business objectives of the organization. They describe the financial, marketplace, and other benefits sought through developing a system and often are phrased in monetary terms (profit, rate of return, market share, etc.). Examples include: Capture 80 percent marketshare within two years, limit support costs to 1 percent of revenue, receive no more than one complaint for every 10,000 transactions, make 22 percent pre-tax profit. Note that none of these business requirements says anything about the product or the project that will create it. They will, however, let us later evaluate the success of this product from a business point of view.
The place to document these business requirements is in the product vision, a document that becomes the foundation of all subsequent project work. This document has other names including the project charter, business case document, and marketing requirements plan. Whatever its name, it defines a vision of the product, the business requirements, and the business context including opportunities, risks, scope, and constraints.
One way to define the product succinctly is to use Geoffrey Moore’s template from Crossing the Chasm:
For [target customer]
Who [statement of need or opportunity]
The [product name]
Is [a product category]
That [key benefit, compelling reason to buy or use]
Unlike [primary alternative]
Our product [statement of primary differentiation and advantages of new product].
When completed, this simple statement will define a high-level vision that will both guide and bound further product development.
Unfortunately, in our rush to start projects, many organizations skip the product vision and jump straight into defining product requirements. For example, in his book Agile Modeling,Scott Ambler suggests projects start with an initial requirements up front (IRUF) phase to define the high-level requirements represented in user stories or use cases and the scope and boundary of the product represented in a context diagram. Ambler writes that a key goal of the IRUF phase is to get out of it as quickly as possible and get on to the “real work.” Note the lack of any thought of defining business requirements. Ambler is not alone in this approach—most agilists ignore defining business requirements that would later make it possible to evaluate whether an organization made good choices in asset allocation.
To my knowledge, in the agile community, only Jim Highsmith writes about the value of the product vision. In Agile Project Management, he states, “While the details of requirements and design can be volatile and fuzzy, the overarching business goal and product vision must be clear. Absent a clear vision, the exploratory nature of an agile project will cause it to spin off into endless experimentation. A clear vision must bound exploration.”
In these times, many of us are being told to “do more with less.” Often, this meaningless phrase is simply thrown out to “motivate” people who are already making the best of a bad situation. A more useful phrase would be “invest our organization’s scarce resources where the return is the greatest.” That phrase is both meaningful and actionable. Creating better software requires us to make better business decisions, and those should be based on better business requirements. The product vision is the place to start.
