In my career in IT, the major issues leading to not bringing in a project on time and on budget are:
1. Broad finish dates driven by upper management, often management that is not in IT or does not have an IT background.
2. Failure of management to take the council of experienced IT professionals who do have experience in providing estimates. Often I have seen that given a set of broad requirements and a rough estimate that states “We estimate we can complete this project in x months”, management will state “That’s great. You will need to get this project done in 1/2 that time or 2/3 that time.
3. Poor requirements.
4. Scope creep, which quite often is driven from point 2.
5. Once it becomes obvious a project is in the ditch and will not come in on time, adding inexperienced resources in an attempt to cut the time to deliver. Adding these resources results in time wasted due to training new resources and rework.
I do find that developers often do underestimate the time needed to complete a task, but by the time a project is at the point of individual estimates for specific sets of work, the failure of a project has already been set in motion by factors far above estimates from a developer.
The article is interesting, but seems rather academic and not based upon the realities in business.
How well defined are the tasks? Are the tasks defined in user speak, or table names and fields. Someone other than the programmers needs to have a working knowledge of the tables, schema's and object models at a workable level.
100% accurate.
Plus, actual Programmers, as opposed to coders are fairly scarce as a percentage of the population in question.
Programming is part art, part science.