ProjectFlightDeck

Concept: Previous posts described how to use ES metrics to manage schedule performance on Agile projects. The metrics covered were: ES, SPIt, and EACt. The ES and SPIt are descriptive metrics—they quantify past performance. The EACt is predictive—given past performance, it estimates how long the project will take to finish.  Beyond the basic metrics, there are additional measures that enhance assessment of schedule performance (Step 5) and planning for the next Sprint (Step 6). One such measure is the To-Complete Schedule Performance Index (TSPI). The TSPI is prescriptive:  given past performance, it dictates the future performance level required to achieve the target duration.

Practice: To calculate the TSPI, divide the Planned Duration less the Earned Schedule by the Planned Duration less the Actual Time, i.e., (PD – ES) / (PD-AT). [1] The Planned Duration is the number of Sprints from the first planned Sprint to the last planned Sprint, including Contingency but excluding Reserve. That means the Planned Duration expresses the baseline.

Keep in mind that a Sprint is defined as a time-boxed unit of delivery. All Sprints in a project have the same duration. Although some projects use a month as the duration, at ProjectFlightDeck we use either one week or two weeks as the time unit for our Sprints. Calculating ES metrics in terms of Sprints is, therefore, equivalent to calculating it in units of time.

The TSPI tells us how well the schedule must perform to achieve the Planned Duration. Here is how we use it to manage schedule performance.

First, we assume that the nominal future performance level is 1.0, i.e., the project will earn schedule at the planned rate. Then, if the TSPI is less than or equal to 1.0, the Planned Duration is deemed achievable because the required future performance needs to reach, at most, the nominal rate.

On the other hand, if the TSPI is greater than 1.1, the level of performance required to meet the Planned Duration rises rapidly to unrealistic heights. As Walt Lipke puts it, “the project is very rapidly becoming ‘out of control’”. [2]

At the opposite extreme, if the TSPI falls below .9, there might be equally serious problems with the schedule. It might be that the original estimates were low-balled, i.e., the estimated velocity was set well below what was realistically achievable.

In between 1.00 and 1.10, caution is warranted, especially if the index is trending higher.  

The TSPI is often used in conjunction with other ES metrics to assess schedule performance. A recent project illustrates the approach.

In that project, the SPIt was, for a long time, above the .9-threshold, indicating good schedule performance (see Figure 1). [3] Toward the end of the time frame shown, the SPIt began to slip. In January, 2015, it dropped below the threshold for good performance altogether.

Figure 1

Given that the project had shown good schedule performance for a long time, had only recently dropped below that threshold, and had a long way to go (Figure 1 only shows the timeline to the end of 2015--in fact, the plan went another 18 months), you might think that the situation warranted concern but had not reached a critical point. After all, we had begun root cause analysis and incremental remediation once the SPIt started its gradual decline. Wasn’t that enough?

When we cross-checked the SPIt with the TSPI, we learned that the stepwise remediation wasn’t sufficent.

Figure 2

The TSPI had been gradually climbing toward the 1.1 threshold. In September, 2014, it edged into the interval between 1.0 and 1.1, sounding a note of caution. Then, in February, 2015, it breached the 1.1 threshold—from that point, we risked it spinning out of control. We had, indeed, reached a critical stage. Dramatic corrective action was required.

Even though ES metrics are all rooted in the same starting point, they provide different perspectives on schedule performance. The different views support a balanced assessment within the ES framework.

Notes: