The Cost

An ROI assessment must be done for some fixed period of time; both the cost and the benefits must be calculated for the same fixed period. The costs presented here reflect those about 1.5 years into the rollout of a new requirements management process and tool.

Cost of Tools, Training, Consulting, and Rollout Team

The most obvious cost of any IT rollout such as this is the cost of the software, hardware, cost of outside consultants, plus the impact to your staff in terms of training classes, staff dedicated to the rollout, and so on.

Figure 7.3 shows the calculation of the cost of the tool and process rollout.^[3]

^[3] This is not meant to be an exhaustive list, but rather an example of the types of things you need to account for.

Figure 7.3. Cost of software, training, consulting, and rollout team.

Item Consulting refers to on-site support beyond classes: additional support needed to aid in the rollout of the tool and process. Item Rollout Team Time refers to a core set of staff that spends a portion of its working time in support of the process and tool rollout.

Cost of Tool Use Overhead

Another cost accounted for in the model is tool use overhead (see Figure 7.4). Just as the proper entry of a defect into a defect-tracking tool requires some time, the proper entry of use cases into a requirements management tool requires more time than, say, a capture on the back of a napkin or Excel spreadsheet. As noted above, gray cells are ones where the values entered are highly subjective, tool use overhead certainly being one.

Figure 7.4. Cost of tool use overhead.

An objective approach for determining a number such as this is to perform usability studies. This was not done in this case, however, and I suspect that most software development organizations don't have the staff, facilities, or inclination to do such a study.

In this particular caseas with many of the subjective parts of the modelI found that a straightforward approach was to poll staff that were using the tool and ask them how much additional time they felt they spent due to tool use overhead. After talking with a number of people, a good average number will hopefully emerge.^[4]

^[4] Additional suggestions on dealing with these subjective values are given at the end of this chapter.

Cost of Added Review and Rigor

Finally, we account for the added review and "rigor" in use case management that we are asking teams to effect (see Figure 7.5). For example, use cases that would otherwise be recorded on a white board in an office or someone's laptop are now entered into a public repository. This increase in easy-to-access use cases leads to additional review, discussion, test planning, change control, and so on.^[5] The cost of doing the job right is, nevertheless, a cost, and is captured in the ROI model here.

^[5] Note that the model assumes that use cases are being written somewhere one way or another, so the cost being estimated here is not that of writing a use case, but rather the cost of the increased activity that surrounds a use case because it is now publicly available.

Figure 7.5. Cost of added review and rigor.

Again, this is a very subjective value. How can we hope to get a ballpark number for the additional time that is being spent by staff because use cases are now publicly accessible?

In Ed Weller's "Calculating the Economics of Inspections," he states that the recommended rate for preparation for and actual inspection of a requirements specification is about seven pages an hour.^[6] This seems a reasonable heuristic for estimating the average cost of additional review and rigor on use cases that were actually implemented.

^[6] This is not the writing of the document. "Preparation" here refers to the time spent by the team before the actual inspection begins (e.g., reading the document and recording questions and issues).

The model divides the use cases into those that were implemented and those not yet implemented. For those implemented, let's assume that one use case is, on average, equivalent to about five pages of text.^[7] Of the use cases not yet implemented, many are likely to be much shorter, some similar in length to Extreme Programming (XP) stories (an XP story is supposed to fit on an index card). For these, we'll assume that a use case is on average about two pages. Additionally, the use cases that were entered, but not implemented, receive much less scrutiny (they are on the backburner, so to speak). We'll model these as receiving one-tenth of the effort, or a factor of 10 increase in speed at which they are reviewed.

^[7] IBM Rational's RUP Director Per Kroll as "Dr. Process" fields various questions put to him on the IBM Rational Web site. In response to the question "How long should a use case description be?" Dr. Process responds, "…a use case description that covers all the alternative flows of events typically ends up being two to five pages long…". My personal experience backs this up as a good average, but ultimately for this model you need to use a number that works for your company.