ProjectFlightDeck

Concept: When work is done out of sequence, knowledge gaps are inevitable. To bridge the gaps, performers must make assumptions about missing inputs. At some point, the missing information becomes available, and when it does, it often differs from the assumptions. That means what has already been done must be reworked.

Rework is doubly wasteful. First, and obviously, re-doing what has already been done is lost time and money—time that could be spent completing new deliverables. Second, and less obviously, the time spent making the assumptions is also lost time and money—it too could have been spent on completing new deliverables. In both cases, performers feel frustration with a work process that is the exact opposite of “one and done”. They want to stop wasting time.

Knowing rework will be required and even knowing which tasks are likely to cause rework are important but only part of what you need to know to stop losing time.  What’s lacking is a fix on the impact of rework.

Figure 1

Practice: Assessing the impact of rework starts with identifying the amount of rework that's at stake. The identification of that amount is an exercise in applied math. On the plus side, that makes it a refreshing change from the story-telling that substitutes for reasoning in most project management books (and business books in general). [1]   On the minus side, it makes the technique inaccessible for many PMs, among whom arithmophobia seems rampant.

In this post, I walk through Walt Lipke’s derivation of Rework, unpacking his condensed logic and explaining unfamiliar concepts in accessible terms. It’s still math but a bit easier to follow. (You can always skip the explanation and jump to the next post when it's ready at the end of October. It describes how to apply Rework in your project.)

The derivation starts with some theorems, moves to a couple of mathematical models, and ends with a cost forecast that is the most useful feature of Rework.

Theorem 1: The total accrued Earned Value = sum of the sum of values earned as of the Actual Time (EV_i@AT) = sum of the values planned as of the Earned Schedule time (PV_k@ES). [2]

Expressed formally, Theorem 1 amounts to the following:

Equation 1

…where EV denotes the value earned as of the Actual Time, PV denotes the value planned as of the ES time, and, most important, the subscripts “i” and “k” denote the target tasks. The target tasks for the PV are the set of tasks scheduled (S) for delivery (in full or in part) as of the ES Time. The target tasks for EV are a subset (“i”) of the “k” tasks, specifically, just the “k” tasks that have delivered value aligned (A) with the PVk as of the ES Time. [3]

Theorem 1 follows from Earned Schedule’s definition: ES is the time at which the value currently earned should have been earned. The dotted arrow in Figure 1 illustrates the relationship.

Theorem 2 follows from Theorem 1 and the P-Factor definition. First, the P-Factor definition (for details on the P-Factor calculation click here):

Equation 2

…where EV denotes the value earned, PV denotes the value planned, and, most important, the subscript “k” denotes the target tasks. For simplification, the target tasks for EV and PV are assumed to be identical. [4]

Now, multiply both sides of the definition by PV_k:

Equation 3

Cancel like terms to get:

Equation 4

Then, substitute for PV_k using Theorem 1:

Equation 5

Expressed intuitively, this amounts to the following:

Theorem 2: the value earned according to the schedule = EV(p) = sum of EV_k@AT = P * EV.

…where the “k” subset is limited by the value of PV_k, i.e., the subset covers all and only the tasks aligned with the schedule. Also, EV refers to EV_i@AT, i.e., all tasks that have earned value by the Actual Time. Intuitively, the value earned according to the schedule equals the fraction that’s aligned (P) times the total earned (EV).

Theorem 3 is derived from the first two. Given that Theorem 1 expresses the total value earned and Theorem 2 expresses the value earned in alignment with the schedule, the difference between the two expresses the value earned that is not aligned with the schedule.

Theorem 3: The earned value not aligned with the schedule, EV(r), is the difference between the total value earned, EV_i (from Theorem 1), and the value earned in alignment with the schedule, EV_k (from Theorem 2).

Expressed formally, Theorem 3 is the following:

Equation 6

Expanding terms and using Theorem 2 to substitute for EV_k, we have:

Equation 7

Factoring out EV_i yields the following form of Theorem 3:

Equation 8

The earned value not aligned with the schedule comes from two sources: tasks that are impeded/constrained and tasks that require rework. The former tasks are typically late, whereas the latter are early. A portion of the value, specifically from the rework tasks, is not usable. Call that fraction f(r). It is expressed as follows:

Equation 9

…where “-r” represents the unusable portion of the total unaligned amount, EV(r).

In contrast, the usable portion, f(p), is represented as follows:

Equation 10

From the definition of the terms, it follows that:

Equation 11

and

Equation 12

So, the amount of rework (R) can be computed as follows. From the definition of f(r), we infer:

Equation 13

Then, from Equations 8 and 13 it follows that:

Equation 14

The total earned value as of the Actual Time (i.e., EVi) and the P-Factor  (i.e., P) are known quantities. The only unknown in Equation 14 is the fraction requiring rework, f(r).

To represent the fraction mathematically, we first need to understand its behaviour. At the start of a project, the knowledge gap is large, and the opportunity for rework is also large—so large that the starting point for the fraction is 1. At the end, the knowledge gap has shrunk to nothing, and there is no opportunity for rework—the fraction is 0. In between, the knowledge gap decreases, and so does the opportunity for rework. The decline speeds up as the amount of work dwindles.

A line tracing the fraction on a graph would curve from 1 to 0, dropping off more sharply at the end. Such a graph is familiar to mathematicians. Historically, it is tied to the number “e”. That number is special, like pi. A brief diversion helps clarify what’s going on here.

Recall that pi stands for “3.14…”. It enables us to calculate the area of a circle (3.14 * the radius squared), the volume of a cylinder (3.14 * the height of the cylinder * the radius squared), and so on. We can take a ruler and measure the radius and multiply it by itself to get the square. But, then, simply multiplying the result by 3.14 gives us the area. There are explanations for why this works, but I still find the fact that it works surprising. [5]

Another of those powerful numbers is “e”. It was discovered more recently than pi. Most accounts peg its discovery in the 17^th century and tie it to money. As the use of compound interest became acceptable in Europe, its study revealed a surprising fact. With compound interest, money doesn’t just double, it goes up by (roughly) 2.72. More surprising, the same amount of change was found for populations, crystals, radioactive decay, and so forth. In fact, wherever there is growth (or decline) that is smooth and continuous, e seems to be involved. [6]

In applying e, keep in mind that although growth can look like addition, it is really multiplication. So, when we use e, we need to frame it with exponents (repeated multiplication). The exponents for e are typically rate and time: e^rate*time. That is to say, interest on your money goes up by multiples of "e" at a given rate over a given period of time.

Now, we can assemble a representation of f(r). First, the fraction of rework depends on how close the project is to the end. As the end represents 100% completion, 1.0 minus the fraction complete (C) stands for the fraction of time remaining. Second, the fraction of rework needs to reflect the drop in rework over the remaining time. How much decline is to be expected?

That’s where the number e comes into play. As just explained, it’s e^rate*time, where the rate is –m (the minus sign indicates decline), and the time (specifically the fraction of time remaining) is again expressed as 1.0 minus C. Formally, this yields the following expression:

Equation 15

The equation gives the amount of rework at each point in time. So, over the project’s timeline, it yields a curve.  Adjusting the variables in the formula changes the shape of the curve.  

The increments of C (e.g., units of .25 or .1 or some other period) affect the slope of the line by changing its “run” (horizontal change). Manipulating n simulates a smaller or larger fraction complete and therefore a larger or smaller fraction remaining. The value of m (e.g., 0, .5, 1, etc.) affects the amount of curve in the line.

To keep things simple, Walt suggests using n = 1 and m = 0.5. Setting n at 1 represents the actual fraction complete, rather than simulating a compressed or expanded fraction. Setting the value of m to 0.5 produces a relatively flat curve. It falls between the straight line of m = 0 and the “rainbow” of m = 1.

As Walt notes, further research will determine the best value for m in practice.

Given that we know f(r), we can say that the amount of Rework (R) equals the following:

Equation 16

It took a while to get to R. Ultimately, it will be worth the effort, but first I need to pull the rug from under your feet: the derivation of R is an interesting exercise in applied math, but R is not useful for managing a project. "Why not?", you say.

The P-Factor increases over the course of a project and ends at 1.0. That makes P increasingly insensitive to efforts for improvement: regardless of what steps are taken, P ends up at a perfect 1.0. That’s neither a good indicator of what improves performance nor a sound basis for forecasting rework caused by poor schedule adherence.

Fortunately, there’s a way to address both of these concerns. It leads to a new adherence indicator that can, in turn, be used to generate a forecast of rework costs. With the forecast, we have, at last, a way to manage schedule adherence systematically throughout a project’s life cycle.

Explanations of the indicator, the rework forecast, and their use in practice follow in the next post.

References:

Lipke, W. (2012). Schedule Adherence and Rework. CrossTalk, November-December.

Lipke, W. (2011b) Schedule Adherence and Rework. PM World Today, July.

Lipke, W. (2011a) Schedule Adherence and Rework. The Measurable News, Issue 1 (corrected
version).

Notes: