Line Activity Estim
Spent Still to
to do
Date done
(now is
29 Mar 2009)
1 Activity 1 2 2 0 1.0      
2 Activity 2 5 5 1 1.2 1 1 30 Mar 2009
3 Activity 3 1 3 0 3.0      
4 Activity 4 2 3 2 2.5 1 2 1 Apr 2009
5 Activity 5 5 4 1 1.0 1 1 2 Apr 2009
6 Activity 6 3       1.4 4.2 9 Apr 2009
7 Activity 7 1       1.4 1.4 10 Apr 2009
8 Activity 8 3       1.4 4.2 16 Apr 2009
 ↓   ↓              
16 Activity 16 4       1.4 5.6 2 Jun 2009
17 Activity 17 5       1.4 7.0 11 Jun 2009
18 Activity 18 7       1.4 9.8 25 Jun 2009

Table: Simplified TimeLine sheet, indicating what will be done when based
on estimations and a calibrated future. It also shows what will not be done
at a certain date, giving us early warnings: on 5 June, Activities 17 and 18
won't be done. The earlier we get a warning, the more time we have to do
something about it. Some notes: In this table we don't calibrate Still to Spend
(by using calibration factor 1), because of assumed improved insight.
Activities not yet started are calibrated by the ratio of Spent plus Still to Spend
and the original estimates. Apparently, this is a snapshot of 29 March.

Feeding Portfolio, Program, and Resource Management

Summarizing the TimeLine technique:

The Table shows a simplified example of a TimeLine table, stating the Activity-description, the estimate, the time already spent and the time still to spend, the ratio of real and estimated time, the calibration factor (ratio of total real time (Spent + Still to Spend) and estimated time during a past period), the resulting calibrated ("real") time still to spend and the resulting dates. If in this example the project has to be concluded on 5 June, we now can say that Activities 17 and 18 won't be done at that deadline, unless we do something differently. This way, we can very early in a project predict what will be done when and take the consequence of the prediction, rather than sticking our head in the sand until reality hits us somewhere. The biggest hurdle is that most project managers have trouble finding out which activities have to be done, causing starting up this technique to take some time. Once this hurdle is taken, however, it hardly takes time to keep the TimeLine up to date, giving real control over the further prediction and the progression of the project.

Traditionally, Program/Portfolio/Resource Management (PPRM) is based on hope. After all, if most projects are late, planning based on assumed deadlines which are not kept is more a game than management. Once the projects have learnt to sufficiently reliably predict what can be done when, PPRM can finally start really managing. This is what we see happening once this process is in place and projects begin to supply data they can live up to...

The Ratio real/estimated proved also to be an interesting indicator: an organization outsourcing refactoring and design of software, found that the supplier was quite good in refactoring and debugging, with a ratio slightly less than 1, meaning always done within the estimated time. When they saw ratios of 4 and 6, they checked the type of activities and found that these were all design activities. Apparently this supplier wasn't good at design (yet?), or at least at estimating design time.

Figure: The problems are not the real problem, after all we're very good at
solving problems. The real problem is we're not doing something about it.

Conclusion of the TimeLine technique