Oh, That's Easy -- Part 2

"Oh, that's easy."

As a project manager I hated those words, particularly if they were coming from my technical team. The more technically adept a person is the more inaccurate the person is at coming up with estimates. Yes, there are exceptions, but they are few and far between and should not be counted on at all times.

Someone who is familiar with the technology and lives and breathes the code is someone who is going to be horrible at coming up with estimates for other people. Heck, they are even horrible at coming up with estimates for themselves. I have had the privilege of working with some very talented people over the past 25 years (damn, there's that age thing again) and with the rare exceptional circumstance, every single one of those people has problems with estimates.

So, how do you compensate? First of all you need to ensure that the developer has thought of everything. Most of the time an estimate only includes the raw time to develop the code, but not to test it, document it and ensure that any technological innovations are compatible with the existing environments. You need to keep track of this persons estimates and use previous estimates in guiding your decision about current estimates.

No, don't create the estimate for the developer as you probably don't know the technology. (See yesterday's note.) Understand, however, that the developer is going to be optimistic about his part of the solution so you need to take his estimate, inflate it, and come up with something that is realistic for the project. And, the most important point of all, keep track of previous estimates and how they matched reality. As mutual funds state "Past performance is not an indication of future results", but they're probably darn close.