This Month’s Pattern *

85 Leakage

Time and money tend to “escape” from closely measured categories into less closely measured categories.

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

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Rome, Mastering Business Analysis
19-Oct-2017 to 20-Oct-2017

James Robertson teaches Mastering Business Analysis. Contact Technology Transfer for details of this course.  

Oslo, Mastering the Requirements Process
6-Nov-2017 to 8-Nov-2017

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Hilversum, Mastering the Requirements Process
7-Nov-2017 to 9-Nov-2017

James Archer teaches Mastering the Requirements Process. For details please contact Adept Events. Dutch description, or in English.

Oslo, Mastering the Requirements Process part 2
9-Nov-2017 to 10-Nov-2017

Suzanne Robertson teaches Mastering the Requirements Process part 2. Details for this advanced class at Den Norske Dataforeningen.

London, Mastering the Requirements Process
14-Nov-2017 to 16-Nov-2017

James Archer teaches Mastering the Requirements Process. For details and registration, please contact IRM UK.

in depth

Business analysis is often seen as a technical skill. But the business analyst has another set of responsibilities -- to dig into what the stakeholder's mind and uncover what is really needed, and not just what they say they want. 

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.