Entries for Symbian’s 2008 Student Essay Contest have just closed. The deadline for submission of entries was midnight (GMT) on 30 September 2008.
The contest has been advertised since June. What proportion of all the entries do you suppose were submitted in the final six hours before the deadline expired? (Bear in mind that, out of a total competition duration of more than three months, six hours is about 1/400 of the available time.)
I’ll give the answer at the end of this article. It surprised me – though I ought to have anticipated the outcome. After all, for many years I’ve been telling people about “The Student Syndrome”.
I became familiar with the concept of the student syndrome some years ago, while reading Eliyahu Goldratt’s fine business-oriented novel “The Critical Chain“:
Like all Goldratt’s novels, Critical Chain mixes human interest with some intriguing ways of analysing business-critical topics. The ideas in these books had a big influence on the evolution of my own views about how to incorporate responsiveness and agility into large software projects where customers are heavily reliant on the software being delivered at pre-agreed dates.
Here’s what I said on the topic of “variable task estimates” in the chapter “Managing plans and change” in my own 2005 book “Symbian for software leaders“:
A smartphone project plan is made up from a large number of estimates for how long it will take to complete individual tasks. If the task involves novel work, or novel circumstances, or a novel integration environment, you can have a wide range of estimates for the length of time required. It’s similar to estimating how long you will take to complete an unfamiliar journey in a busy city with potentially unreliable transport infrastructure. Let’s say that, if you are lucky, you might complete the journey in just 20 minutes. Perhaps 30 minutes is the most likely time duration. But in view of potential traffic hold-ups or train delays, you could take as long as one hour, or (in case of underground train derailments) even two hours or longer. So there’s a range of estimates, with the distribution curve having a long tail on the right hand side: there’s a non-negligible probability that the task will take at least twice as long as the individual most likely outcome. It’s often the same with estimating the length of time for a task within a project plan.
Now imagine that the company culture puts a strong emphasis on fulfilling commitments, and never missing deadlines. If developers are asked to state a length of time in which they have (say) 95% confidence they will finish the task, they are likely to give an answer that is at least twice as long as the individual most likely outcome. They do so because:
Ironically, even though such estimates are designed to be fulfilled around 95% of the time, they typically end up being fulfilled only around 50% of the time. This fact deserves some careful reflection. Even though the estimates were generous, it seems (at first sight) that they were not generous enough. In fact, here’s what happens: In conclusion, in a company whose culture puts a strong emphasis upon fulfilling commitments and never missing deadlines, the agreed schedules are built from estimations up to twice as long as the individually most likely outcome, and even so, they often miss even these extended deadlines…
This line of analysis is one I’ve run through scores of times, in discussions with people, in the last four or five years. It feeds into the argument that the best way to ensure customer satisfaction and predictable delivery, is, counter-intuitively, to focus more on software quality, interim customer feedback, agile project management, self-motivated teams, and general principles of excellence in software development, than on schedule management itself.
It’s in line with what Steve McConnell says,
- IBM discovered 20 years ago that projects that focused on attaining the shortest schedules had high frequencies of cost and schedule overruns;
- Projects that focused on achieving high quality had the best schedules and the highest productivities.
Symbian’s experience over many years bears out the same conclusion. The more we’ve focused on achieving high quality, the better we’ve become with both schedule management and internal developer productivity.
As for the results of the student syndrome applied to the Symbian Essay Contest:
- 54% of the essays submitted to the competition were received in the final six hours (approximately the final 1/400 of the time available)
- Indeed, 16% of the essays submitted were received in the final 60 minutes.
That’s an impressively asymmetric distribution! (It also means that the competition judges will have to work harder than they had been expecting, right up to the penultimate day of the contest…)
