Feeding Portfolio, Program, and Resource Management

Summarizing the TimeLine technique:

  • Cutting what we think we have to do into up to some 20 chunks (packages, activities) and estimating these chunks. Adding up the estimates usually provides sufficient evidence that we need more time than we have available. At this point, most projects decide that they simply need more time, or complain that management is imposing impossible deadlines.
  • With Evolutionary Planning, however, we don't stop here, but think of alternative strategies of doing things, doing different things or doing things differently. We estimate the impact on the result and choose the optimum strategy. Now we have well-founded arguments to explain management why things will take as much as they still will do.
  • 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.

  • Now the chosen strategy is planned focused on the optimum order of implementing the optimum solution, still being aware that "optimum" gradually may change by advancing understanding. It's of no use continuing an initial plan once we see that it should be changed. That's why we have to continuously keep using the Plan-Do-Check-Act technique, with the Business Case as a reference.
  • Now we can start predicting what will be done when, based on the estimations and subsequent calibration to reality. This provides the business with quite reliable predictions, allowing them to provide reliable predictions to their customers.

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
  • The TimeLine technique doesn't solve our problems
  • It helps to expose the real status early and continuously
  • Instead of accepting the undesired outcome, we do something about it
  • The earlier we know, the more we can do about it
  • We start saving time from the very beginning
  • We can save a lot of time in any project, while producing a better outcome
  • If, and only if, we are serious about time!