In the 30s of the last century, the Lisboa-Porto line was never on time. Though users kept complaining about delays, the train records kept logging no such delays, and both train and station managers stood by those logs.
Something was terribly wrong, so the train company's president himself decided to take a train to sort it out. For each and every station the train arrived later and later, and for each and every station the train and station managers logged it as being on time. It was quite amusing, being as late as 30 minutes and hearing the station's manager screaming "On table!!!".
The president confronted the data with the train and station managers, and they finally told him what was wrong: it was impossible to keep the proposed timetable, so they opted to fake the logs. The president took two obvious measures: updated the timetable and fired those who faked the logs.
Why am I talking about trains on what should be a geek's blog? Because in a way we also suffer from this problem. As we presently are still unable to predict correctly our project's effort we keep getting late on our timetables. And for the same strange reason as with the train people, some people don't report the delay as soon as we should, not leaving too much track to recover from.
Right now we have no way to anticipate correctly our timetables. But once our train starts, we can measure our effective speed and measure where we are against these timetables. Though our project management practices already enforce these measures, they are only as accurate as the information they receive, so the teams should be trained to log delays as soon as possible. I'm talking about intra-task delays and that gut feeling only the team can sense as that all the estimation is going down after just a week's work.
And finally, as timetables are presently hard to do accurately, we should do something about it: better effort history management, and sharing the timetable's risk with our client. At least until our project's effective speed is taken.
