16. Incrementalism for Risk Mitigation

Risk mitigation comprises the full set of early actions you can take to make it possible later on to deal effectively (quickly, cheaply) with a risk, should it materialize.

All mitigation incurs cost and delay in the present in order to cope with possible risk manifestations later. It makes the rosy scenario somewhat less rosy, since if the risk fails to materialize, the mitigation cost might seem to have been wasted.

A bang-per-buck analysis of various risk mitigation strategies would go like this: Your bang is some weighted assessment of reduced cost and delay in coping with likely risk manifestations, and your buck is the cost and delay associated with mitigation itself. The best bang-per-buck risk mitigation strategy we know is incremental delivery.

The many benefits of incremental delivery have been noted often and documented by ourselves and other authors (see the References). There are a few additional reasons why incrementalism makes particular sense to the risk manager:

• It can confirm or refute project plan hypotheses.

• It forces rank-order prioritization of system components.

• It can be used to optimize the benefit of partial deliverables (which is particularly nice if the project runs out of time and/or money).

• It provides feedback about true development efficiency.

• It positions the project for relatively painless cancellation, should that prove necessary.

As a side benefit, incremental delivery facilitates collection of the EVR metric and its objective assurance of progress.

Reactive incrementalism works like this: A project manager does some cursory hand-waving about incremental delivery but leaves the choices about subsets to the programmers. There are versions—and they are cumulative—but they’re formed absent any management judgment about priorities. There is usually no published incremental delivery plan. The selection of versions is made to suit the convenience of the implementers: “Hey, these three thingamabobs all live together, so let’s include them as a lump and call it Version 1.” While there are versions and builds, none are ever delivered to a user. The implementers have a host of reasons for keeping the versions private—most importantly, that the versions they select tend to have no meaning to users.

All this changes when the project runs out of time. At that point, management announces that instead of delivering the whole system on the agreed date, there will be a phased delivery. The Phase One deliverable will be passed over to the new owners on the original date, but the full system will not be completed until Phase Four or Phase Nine or whatever, months or years later. This announcement is intended to allay some of the pain of lateness because the project is at least able to deliver something on the original date. But what is that something?

Because undeniable lateness tends to rear its head fairly late in the original schedule, this kind of reactive incrementalism assures that the selection of components for the initial delivery is also made late. At that point, the question, “What shall we include in the Phase One deliverable?” is somewhat bogus, since the only possible answer is, “With the delivery date so close, the Phase One deliverable has to be the stuff we’ve already got running.”

This reactive approach has none of incrementalism’s purported benefits.

• value delivered to the stakeholder

• confirmation of risk hypotheses

This forces a rank-order prioritization of system components.

Rank-ordering of all functions and features is the cure for two ugly project maladies: The first is the assumption that all parts of the product are equally important. This fiction is preserved on many projects because it assures that no one has to confront the stakeholders who have added their favorite bells and whistles as a price for their cooperation. The same fiction facilitates the second malady, piling on, in which features are added with the intention of overloading the project and making it fail, a favorite tactic of those who oppose the project in the first place but find it convenient to present themselves as enthusiastic project champions rather than as project adversaries.

Prioritization gives the lie to the fiction of uniform value. It facilitates an incremental cost-benefit analysis to justify early or late inclusion.

Note that value to the stakeholder is not the only basis for early inclusion. The risk-aware manager will want to force the portions involving serious technical risk into the early versions. This makes perfect sense, but it goes against the grain of most managers since it exposes their weakest hypotheses early in the game. You can understand why such managers would prefer to hold back these ticklish matters for as long as possible.

TDM:    As a novice bridge player watching one of my fraternity brothers play, I was amazed to see him lead a very weak card from his hand, which was full of high cards and trumps. I asked him about it later. He told me, “Tom, always take your losers early. Sure, I could have handily won the first six or eight tricks, but what then? With all the trumps out, if I then lose a trick, the other side gains control. I could end up sluffing off all my remaining good cards while they lead from a suit of their own choosing.”

In project work, too, it makes sense to take your losses early. When you do that, you give up control, letting events have their way with you (that’s what makes it so hard). But by doing it early, you preserve your strength to come back and regain control.

Those parts of the system that depend on pulling off technical wonders should be pushed into the early versions. That way, if the wonders don’t get pulled off, you maximize your options for fallback. If you do this early enough, you may be able to suffer the loss in relative private, whereas the same defeat late in the project would be immediately apparent to everyone.

Our colleague Tom Gilb takes an extreme view of this matter: “It’s as though I as a project manager weren’t allowed to know the project’s end date until the date arrived. The only instruction I’d get in advance would be to ‘be ready to pack up whatever you’ve got any given morning and deliver it by close of day.’ Of course that forces me to build in lots of versions (so the time between versions is relatively small) and to make sure that all the good stuff is in the early ones.”¹

¹ This comment was made privately to Tom DeMarco by Tom Gilb during a meeting in Monterey, California, in 1987. You can find a more formal statement of the same ideas in Gilb’s Principles of Software Engineering Management, ed. Susannah Finzi (Wokingham, England: Addison-Wesley, 1988).

• the design blueprint: a graphic showing the lowest level of modules or classes to be implemented, and their interrelationships

• the work breakdown structure (WBS): the network of tasks to be completed, and their dependencies

• the set of version acceptance tests: the final acceptance tests for the product, broken down by version, showing which tests can be applied to which of the interim builds produced

The design blueprint is typically presented in the form of a module or class hierarchy:

(Here, we’ve concocted an abstraction of the blueprint rather than imply a preference for any particular design representation.)

Each version or increment to be produced can be portrayed as a subset of the design blueprint. Since each increment contains the ones before it, these subsets make up an onionskin partitioning of the design:

Here, Versions V1 and V2 (as well as others to come) are contained by successively larger onionskins.

Most of the tasks on the work breakdown structure can be mapped to one, and only one, version. There will always be some tasks that transcend the versions, but most will be version-specific. We associate tasks with versions based on the answer to this question:

These are the tasks that can be mapped to Version n.

Similarly, each version maps to one and only one version acceptance test.

With this much groundwork laid, the correlation that is the heart of the incremental delivery plan can be shown in one fairly straightforward graphic:

The process, in recap, follows:

• The version is identified by subsetting the design blueprint.

• The tasks associated with that version are those whose completeness is demonstrated by acceptance of the version.

• The version acceptance test for each version is the set of criteria that must be met in order to declare that version complete.

The completed incremental delivery plan can be thought of as a table with one row per version. Each row will contain, at a minimum, the following entries:

• version number

• concise statement of features and functions included, hopefully with reference to elemental requirement components contained in the specification

• pointer to version acceptance test

• expected date the version will be demonstrated complete (VAT passed)

• actual date of demonstrated completeness (to be filled in later)

• list of all tasks in the WBS proved complete by the completion of the version

• EVR of the version (discussed in the next section)

We need to place two constraints on the incremental delivery plan and its associated artifacts: First of all, the incremental approach allows for considerable time overlap among the tasks associated with the various versions, but it does not presume overlap between the task of developing the plan itself (or of the design blueprint, which precedes it) and the implementation of the versions. For this approach to work, the blueprint and incremental delivery plan must be complete before the overlapping of tasks begins.

The second constraint is that the design blueprint must show the entirety of the design partitioning, down to the lowest level. It’s common practice to do some hand-waving at what seems to be an upper-level design, declare the design complete, and leave the rest of the design partitioning to be done as a by-product of coding. When this happens, all the advantages of the closure metrics derived from the incremental delivery plan are lost.

Earned value running is the cost of the work that is demonstrably complete and running in the current version. EVR is expressed as a percentage of the whole budget. The budgeted effort for each task in the WBS should similarly be expressed as a percentage of the whole. The EVR for Version n can now be calculated by adding up the contributions for all the tasks that are demonstrated complete by passing VAT n.

Consider the following simple example, a project with ten tasks in its WBS, one hundred person-weeks of scheduled effort, and an incremental delivery plan for five increments:

The full project is complete when Version 5 has passed its acceptance test, VAT5 (since V5 is the final version, VAT5 is the full product acceptance test). At that point, 100 percent of the value is said to be earned and running. The EVR associated with passing each of the VATs is

VAT1: 30%

VAT2: 49%

VAT3: 69%

VAT4: 78%

VAT5: 100%

The graph of actual EVR demonstrated as a function of time looks like this:

The amount of EVR demonstrated complete per unit of time establishes a glide path for the project. This glide path is the strongest possible indicator of the approach to project completion. Deviations of the glide path from the expected path are a sure sign of risk manifestation, and they serve as a call to action to put into place planned risk containment strategies.

EVR tracking is the principal source of feedback about risk from the project midpoint (or even slightly earlier) all the way to completion. EVR provides a voice-of-the-product metric while imposing only small additional cost on the project.

So far, we’ve called out only the risk-related benefits of an incremental approach. For the record, there are other benefits as well, including

1. more closure to keep project staff motivated

2. more visibility

3. more user involvement in the project, from midpoint to end

4. possibility of eliminating the tail end of the project upon realizing that it mostly consists of bells and whistles (the low-benefit portions of the product)

Incrementalism is a good idea for all projects . . . and a must when risks are high.