85 Leakage

Now here’s a dilemma: You’re busy perfecting some server-side code to enliven a small piece of the interface to your company’s new portal. You’ve just spent fifteen more hours on the damn thing, and it still isn’t right. As you’re puzzling over the code, a guy from the Program Management Office stops by, to bug you about your time sheet for the week: “Please log onto the PMO system immediately and fill in the numbers.” When you do, you realize that the activity you’ve been billing your time to for this work, “5321: Implement-Dynamic-Portal-Interface,” is almost full. Another fifteen hours will exhaust the time allocated for the task and unleash the inevitable question, “Well, is it done?” Of course it’s not done. Frowns all around, and the next question is sure to be, “Well, when will it be done?” Shudder. You don’t want to go there.

Fortunately, there is a task on the work breakdown structure with no time yet logged against it: “5977: Tune-For-Response-Time.” Now that you look back at what you’ve been doing for the last fifteen hours (you don’t have to look too critically), doesn’t it seem as much like tuning for response time as implementing a dynamic portal interface?

Sure, close enough. You plunk down the fifteen hours against task 5977. Most task breakdown structures are vague enough to allow for some leeway in how time is reported.

The task that’s almost full is being watched closely by management because when its allocated time is exhausted, the work is supposed to be complete. Nobody’s got an eye on the other task because it is off beyond mañana.* Your innocent little diversion of fifteen hours from one task to the other is what we call leakage.

There are two different types of leakage on most projects: either work that is miscategorized when it is done, as in the example above; or work that is partially deferred to a later task. Type 2 leakage is impossible if task descriptions are really tight, but there is usually enough leeway for at least some work to be deferred from early to late tasks. Both leakage types have the same effect: They introduce invisible slip into the project. Either they add work to or remove allocation from late project activities, thus making them harder to complete on-time.

Consider these common examples of leakage:

  • Activities whose time or manpower is almost used up are more closely watched than those with remaining allocation, so work leaks from the former to the latter. (This is Type 1 leakage: miscategorization.)
  • Activities that are due for completion in the near term are more closely watched than those due at a later date, so some leakage tends to occur, shifting work into the later tasks. (This is Type 2 leakage, since some of the work is deferred.)
  • Work leaks out of requirements activities to be handled on-the-fly, as part of coding or testing. (Type 2.)
  • Since planned innovation activities tend to be vaguely defined, they sometimes end up as slush buckets. (Type 1, again.)
  • Easy work tends to get done before difficult work. This is a form of work leakage from the closely followed meta-category Look How Much We’ve Already Done to the slightly more amorphous What Remains Left To Do.
  • Work leaks out of the project entirely and into the post-project maintenance activity.
    * See Pattern 7, “Mañana.”

You might think leakage is purely an accounting matter, of interest only to those who are trying to compile a usable historical profile of project work. But the effect of leakage on the project can be more insidious: It can lead to a partial or sometimes total loss of control. When work leaks out of the project entirely, the result is a shoddy product that needs to be fixed and refixed after delivery; management has thus lost control over product quality. And when difficult work leaks out of early activities (so they can be completed on-time), the density of difficulty is increased over time, leading to that old cliché of projects stalled at 95 percent done for a lot more than 5 percent of the time.

    “Most people understand the time value of money, but not the money value of time.”
    —Steve McMenamin