First it must be said and it must be acknowledged that estimating time in software projects is a black art. I have never seen anyone do it well and to pretend otherwise is pure folly.

One of the big mistakes I see all the time is the failure to tailor methodology, metrics and PM to the scope of the project at hand. I don't know how many times I've seen teams working on relatively small line-of-business apps that have been treated as though they were working on *creating* the next version of the .NET framework rather than merely *using* the current one. What happens is that layers and layers of abstraction and administration are put in place that are not and will not ever be used for anything because the underlying business process is static.

The related mistake is that more often than not all of these abstraction layers are poorly documented, if documented at all, with the result that a simple project (allegedly) designed for ease of maintenance is virtually impossible to maintain; when new developers come in, ramp-up times for them are extremely long, frustration levels high and, if they are sufficiently aggressive, calls for large-scale rewrites become the order of the day.