20. Sensitivity Analysis
,The delicate matter at the heart of this chapter is increased stakeholder accountability. We’ve already proposed the necessity of thrusting responsibility for value projection and measurement of realized value onto a system’s users and stakeholders (to the same precision as cost estimates and actuals). Now we would have you make the case for some incrementalism in this value accounting. This is delicate because you can’t simply oblige your clients to be that accountable. You have to wheedle and persuade and call in favors. Do you really want to spend whatever political capital you may have on these seemingly abstruse matters? In this chapter, we are going to try to persuade you that you do.
If This Is the Solution, What Is the Problem?
The problem we take aim at here is the package-deal nature of most system projects. A project gets funding based on some value—either expressly quantified or not—that the resulting product will deliver. Now it’s worth asking several questions: Where is that value in the product? Is it uniformly distributed around all the system’s components? Is there an equal proportion of value in this 100-line edit as in that 100-line module over there that reconfigures after a power failure?
Don’t bet on it. Our experience (and yours, admit it) suggests that value is very unevenly distributed over a system. The system’s real money proposition lies in certain core functions performed at or near the product’s heart.
Sometimes, this heart-of-the-value region constitutes no more than 10 percent of the code. The rest is . . . well, what is it? Sometimes, it’s necessary infrastructural support; other times, it’s pure bells and whistles, masquerading as necessary infrastructure. Cutting through this little deception is what sensitivity analysis is all about.
Incremental Value/Cost Analysis
Once we divide a system up into pieces (say, the functions at spec time or the modules at design time), it’s possible and sensible to allocate projected cost on the map of that partitioning. So, a portion of the system costed out at about $235,000 might have a cost map that looks like this:
Now, if the stakeholders could be persuaded to distribute over the same map their assessment of the value that the system is expected to deliver, we would have both a cost and a value figure for each component. We could compute a value/cost ratio for each piece.
We know, we know—you’re never going to be able to pull this off. But just imagine that you could. What would you do with the incremental value/cost figures? That’s an easy one. You’d use them to separate core functionality from necessary infrastructure from bells and whistles. You’d do this without ever having to pronounce loaded words like “bells and whistles.” The stakeholders’ own value assessments would give the lie to the presumption of value uniformity across the whole system.
Some of the components would have high value/cost ratios, and those would be candidates for early delivery. You’d formulate your version plan to pick up the highest-ratio components in early versions. With Version n delivered, all or most participants may discover that the average value/cost ratio of the not-yetimplemented portions was poor. This might well cause a groundswell of consensus to end the project, call it a grand success, and go on to other things. All without you ever having to take the unpopular position that so-and-so’s favorite function was a pure sop to his ego and had damn little contribution to the overall value proposition.
Economies and Diseconomies of Scale
The news that value is not uniform over a system suggests a useful tactical tool for the IT manager. System projects are known to exhibit diseconomy-of-scale characteristics: Doubling the size of a system should be expected to more than double the effort required to build it. This nonlinearity of effort with respect to system size has been well documented by Boehm and others:
1 Barry W. Boehm, Software Engineering Economics (Englewood Cliffs, N.J.: Prentice-Hall, 1981), p. 76. Reprinted by permission of Pearson Education, Inc., Upper Saddle River, N.J.
If increasing the size of a product exposes you to more-than-proportional increases in cost, then decreasing product size offers the possibility of more-than-proportional savings. Eliminating those portions of the system where the value/cost ratio is low is probably the easiest and best way to relax constraints on time and budget. It’s odd that software builders should come to believe that “build less software” ought to be part of their mantra, but the advantages are apparent.
Back to the Real World
Okay, let’s face facts: Getting your stakeholders to do incremental value projections is going to be like pulling teeth. It’s a nontrivial amount of work, it opens the door for an additional level of accountability, and it has no obvious payback for the people sticking their necks out and doing the quantification. If there are bells and whistles lurking among the useful functions, the very people who have to do the quantification may be the ones likely to lose favorite features. You can expect almost any stake-holder to object strenuously to the effort and to assure you in the most earnest tones that “It’s all necessary to support core functionality. Honest.” This is the same tired, old value-is-equally-distributed line, but don’t expect to convince them of that.
Maybe you don’t have to. The payoff of incremental value/cost data is that it allows you to rank-order components for inclusion in the versions. The actual ratios would be nice, but if you couldn’t have them, wouldn’t you settle for the rank-ordering, instead?
The very fact that you will be implementing incrementally gives you a lever for extracting rank-ordering instructions from even the most unwilling stakeholders. After all, some parts of the system will necessarily have to be implemented after some others. Some pieces will be first and some will be last. If you throw that back in your stakeholders’ laps, they will leap to tell you about order of implementation. Everybody knows that sometimes systems come in late and that portions implemented early are likely to be available by the original date while late-implemented portions are not. It would be a rare user who failed to take advantage of this additional level of control, even though availing himself or herself of it would be an effective admission of uneven concentration of value in various portions of the system.