- An Investment Story
- Investing in Requirements
- Return on Investment
- Investment Risks
- What to Invest In?
- To Invest or Not to Invest
- Investing in Requirements
- Size of Requirements
- The Value of Requirements
- Reusing Requirements
- What Do I Do Right Now?
- What's the Least I Can Get Away With?
- Additional References for Requirements Value
This chapter is from the book
This chapter is from the book
This chapter is from the book
Investing in Requirements
Let's return to the allegory of Amelia and her camera shop. She has several investment choices. The first is business as usual. The parallel for you is continuing to do whatever you are doing in the requirements field today. Nothing ventured, and nothing will be gained.
Her second choice is to invest in the store, bring it up to date, install modern equipment and sell modern cameras. This might cost her some money but is probably the best way for her to make money in the long run. For your project environment, the analogy is to invest time and effort in improving the way you discover and communicate requirements and reaping the reward of better products and cheaper delivery.
Amelia has two other options. She can tinker with the store. A minimal "Band-Aid" approach might be acceptable if she thinks the store is in capable of producing more value. However, it will probably not yield much. Nor can you expect a "Band-Aid" approach in project development work to yield substantial returns.
Her final choice is to walk away. For Amelia, walking away may be the right choice depending on the business climate for camera stores. In your case, however, given the increasing evidence of the positive effect of good requirements on project success, this is the equivalent of management's head in the sand.
In this chapter we give you some ways of justifying, determining, and managing your investment in requirements. You can, and should, look at your investment in requirements as you would look at any other investment.
- How much are you willing to invest?
- What is the ROI?
- What is the time for ROI?
- What are the risks?
- Should you invest at all?
The last question is perhaps the most pertinent for requirements. In our experience, several reasons exist for investing in requirements.
- To build the right product.
- To shorten the delivery time.
- To find the right product for the long-term operational or sales success.
- To take advantage of the products of requirements engineering to help guide the project by making more informed decisions.
- To discover a better product.
We address each of these reasons in this chapter, but first let's consider the least-cited reason for investing in requirements:
- To discover a better product.
Investing in requirements means investing the time, effort, and skills to discover the requirements correctly. The careful gathering of requirements always results in an inspirational leap forward for the product. The collective effort of the interested stakeholders produces the "killer requirement," something considerably more than routine automation of an existing task.
These killer requirements turn out to be wonderful business assets and produce a huge return on their investment. For example, requirements that enabled customers at Amazon.com to write their own reviews gave customers a feeling of participation and belonging to the site; people kept coming back for more. Another great Amazon requirement was to make ordering as simple as possible. When requirements analysts had defined "as simple as possible," Amazon invented 1-Click and customers loved it.
Federal Express, UPS, DHL, and others invested in a requirement they discovered from their customers. Customers wanted to track their shipments online. The couriers spent millions to satisfy this requirement, and so far it is proving to be a very good investment. FedEx calculates each telephoned tracking request costs FedEx about $2.30. FedEx receives about 100,000 calls per day. The Internet alternative is far cheaper and has produced some stunning savings in ongoing operational costs.
" On FedEx.com we're averaging more than 2.4 million tracks per day and each one of those transactions aver ages just under a nickel. We're saving about $25 million a month."
—Robert Carter, CIO of Federal Express, Fast Company, April 2003
As another example, FedEx has recently added InSight to its ser vices, which enables customers to track inbound shipments without needing to know who is sending them. Nor do they need to know the tracking number. So far, InSight is proving popular with clients who wish to plan their production for incoming shipments of materials.
Building the Right Product
Building the right product means finding what is really needed, and not just what people say they want. It also means getting it right the first time, and not having to drag through the long repair activity that many projects suffer. Requirements gathering is about finding this right product and specifying it unambiguously to the developers.
Shorten Delivery Time
Shortening delivery time might seem at first glance to be a surprising reason to invest in requirements. However, our clients consistently find that by including a thorough requirements activity in their development cycles, they deliver the right product sooner. Requirements have value because they enable the builders to concentrate on developing the product instead of guessing about missing or ambiguous requirements, then having to retrace their steps and undo incorrect interpretations. When the builders do not receive the correct specification, programmers spend at least half the project budget in post-implementation correction. This is not only expensive but very frustrating to the client and business users waiting to deploy the finished product.
Linking Requirements to Managing
Requirements activity includes several deliverables we have found invaluable in the management of projects. For example, it includes building a context model. From the context model, we count function points to accurately measure the size of the work to be studied. We also advocate you use the context model to identify business use cases. Then use these as a collection unit for gathering requirements.
We know plenty of managers who use the status of business use cases as their way of measuring progress. The identification of stakeholders gives you a way of assessing the willingness of the people whose participation you need. This alone can serve as a reliable indicator of whether or not to proceed.