- if you don’t know where you go, you don’t know when you get to your destination, and
- if you don’t track your progress, you don’t know which way you are going.
Early ocean goers had no accurate way of locating their position or destination, or even of tracking their progress. This is quite similar to many current software project managers. Yet these ocean voyages had a much higher rate of success (i.e. reaching their destination with most of their goods sellable and most of the crew alive) than current software projects, where it is said that in fewer than half the cases their results are actually used.
Software Project Managers (PMs) can find some very relevant lessons in the experience of early ocean seafarers. I will develop two what I see as the four most important ones in the next paragraphs:
- Know where you want to go.
- Track your progress, estimate where you are.
- Track your speed, estimate where you are going.
- Choose the best route.
I’ll skip for now points 1 and 4, leaving them for a later discussion and focus here on the tracking part of a software project.
Track your progress, estimate your position.
Both the time it took you to reach a certain point, and the location of this point count. Project tracking is naturally about time and expenditures, and number of remaining bugs, but also about delivered results.
As shown in the above screen shot, ISIS encourages the “earned value” tracking method  that gives good location estimates by focusing on what is actually delivered to the customer (the green curve above, top graph) , while the ISIS-required properly filled time-sheets tell the project manager where the effort was spent (the red curve above, top graph) .
Tracking of efforts and actual deliveries give Project Managers an approximate snapshot of the project’s position. Yet PMs typically have a difficult time estimating what work is required to finish. They need to get help from the developers who should report the efforts spent, and what they see as the remaining effort, whether it was planned initially or not (“remains to be done”).
Track your speed, estimate where you’re going.
Project Managers can fairly easily tell their approximate position (based on what deliveries have been accepted by the customer on one hand and the time-sheets on the other); but they usually don’t take trends into account. Back to the initial analogy, being next to a shoal and drifting towards it is very different from being next to a shoal and drifting away from it!
ISIS recommends tracking position over time, e.g. through the integration of successive snapshots. This helps getting an accurate estimate of the delivery speed, thus a good estimate of how long the remaining work in the project will take. This is a much better estimate than using the current position snapshot and betting the house that the rest of the project will go according to some initial plan.
Similarly ISIS recommends tracking the “speed” rather than snapshots of bugs and issues, as this helps predict when a test phase finishes.
The following graph (lifted from the ISIS documentation) gives a hint of how such a dynamic tracking can work:
Using the above graph, with snapshots are taken at each vertical line, a project manager could have a good idea of the overall project effort and duration by the 3rd snapshot, predicting an end of project around the 12th time interval, rather than either the 5th as was the initial prediction, or the 6th as the 3rd snapshot would have.
A future blog will develop the “Track your speed” aspects, and some of their unexpected consequences on effective mechanics of project management. Please send us your comments and suggestions!