- 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
Having determined it is advisable to invest in a product, you must now make the same decision about whether you will invest in gathering requirements for that product. Given that requirements accelerate the delivery of the product, the answer is generally yes, but there are degrees of requirements gathering. The effort you put into your requirements activity, and the formality of the requirements specification, should be varied to suit the project.
Figure 2.4 looks at the probability of success for your project measured against the effort put into requirements. No successful projects result from activity in which no effort was devoted to requirements, so we start at zero effort/zero chance of success. After that the probability of success rises as the requirements effort increases. However, at some point extra effort brings less incremental improvement in the success probability. The inference of this is that the requirements effort to be expended in the project is not automatically the maximum, but should be selected by considering the project's variables.
)
Figure 2.4 If you invest zero effort in requirements, your chance of success is also zero. Probability of suc cess rises as you invest more and more in requirements. The maximum amount you can invest is close to half of your project budget.
For large projects, the decision is always to invest in requirements and to budget for an extensive requirements activity. The magnitude of the requirements effort usually depresses project managers, but the ROI is huge. Without a proper requirements activity, likelihood of failure is high, and cost of failure is also very high. Large projects always make the headlines by cancelling when it becomes obvious to all concerned the project cannot deliver. And almost always, at the time of cancellation, too much code exists and too few requirements.
Conversely, if your product is very small, a better chance exists for developers to successfully guess some of the requirements. The cost of failure here is not too large, as requirements errors can be corrected relatively cheaply.
Similarly, for an infrastructure product, the requirements are better known to the analysts and the developers, and subsequently a less for mal requirements effort is needed. The ROI for requirements for an infrastructure product is less than on strategic products, but still significant.
The worth of the work area also comes into consideration. For high-worth work areas, the cost of failure is high, usually because of lost opportunities to that work area. The cost of lost opportunities alone makes it worthwhile investing in requirements.
For strategic products, always invest in the requirements. The risks of a strategic product are far higher; in some cases organizations are betting their future on the success of the project. The cost of failure is thus extremely high, and the likelihood of failure without good requirements is also very high.
We always advise our clients, before deciding to invest, to take into consideration the value of the resources that the project will use. If the project uses valuable resources (assuming all resources are not equal) then failure is expensive as these resources can be used elsewhere.
The final consideration whether to invest in requirements is the inevitable question of how close is the deadline? Apart from trivial products, delivery is always fastest when developers have an intimate knowledge of the requirements. Always.