Better Software - March 2009 - (Page 11) Technically Speaking The Missing Measurement by Lee Copeland 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 market Scott Ambler suggests share within two years, limit projects start with an support costs to 1 percent …these types of initial requirements up of revenue, receive no more front (IRUF) phase to than one complaint for every requirements say define the high-level re10,000 transactions, make 22 percent pre-tax profit. quirements represented nothing about whether the Note that none of these busiin user stories or use ness requirements says anycases and the scope organization’s investment thing about the product or and boundary of the was a good the project that will create product represented it. They will, however, let us in a context diagram. financial decision. later evaluate the success of Ambler writes that a this product from a business key goal of the IRUF point of view. phase is to get out of it as quickly as The place to document these business possible and get on to the “real work.” requirements is in the product vision, a Note the lack of any thought of defining document that becomes the foundation business requirements. Ambler is not of all subsequent project work. This alone in this approach—most agilists igdocument has other names including the nore defining business requirements that project charter, business case document, would later make it possible to evaluate and marketing requirements plan. What- whether an organization made good ever its name, it defines a vision of the choices in asset allocation. product, the business requirements, and To my knowledge, in the agile comthe business context including opportu- munity, only Jim Highsmith writes nities, risks, scope, and constraints. about the value of the product vision. One way to define the product suc- In Agile Project Management, he states, cinctly is to use Geoffrey Moore’s tem- “While the details of requirements and plate from Crossing the Chasm: design can be volatile and fuzzy, the overarching business goal and product For [target customer] vision must be clear. Absent a clear viWho [statement of need or opporsion, the exploratory nature of an agile tunity] project will cause it to spin off into endThe [product name] less experimentation. A clear vision must Is [a product category] bound exploration.” That [key benefit, compelling In these times, many of us are being reason to buy or use] told to “do more with less.” Often, this Unlike [primary alternative] meaningless phrase is simply thrown out Our product [statement of prito “motivate” people who are already mary differentiation and advanmaking the best of a bad situation. A tages of new product]. more useful phrase would be “invest our organization’s scarce resources When completed, this simple statement where the return is the greatest.” That will define a high-level vision that will phrase is both meaningful and actionboth guide and bound further product able. Creating better software requires development. us to make better business decisions, and Unfortunately, in our rush to start those should be based on better business projects, many organizations skip the requirements. The product vision is the product vision and jump straight into place to start. {end} defining product requirements. For example, in his book Agile Modeling, www.StickyMinds.com MARCH 2009 BETTER SOFTWARE 11 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.