Project Estimation Geometry
How do I handle estimates? I want to do them, always. At a project's inception, I guess at how complex a problem is. Then, I compare it to projects I have done before. Next, I chunk the project into macro-sized elements and estimate these. The chunks include tangible parts of every project, such as designing, programming, and testing. Then, I determine the design and implementation chunks based on a loose assemblage of all of the pieces, like building a database, writing stored procedures, coding, unit testing, GUI design, more testing, sanity testing of requirements, and deployment. Finally, I add up all the bits and multiply by 2.6. That last part, if spoken out loud, will get you into trouble. If ignored, it will surely lead to a very late project and probably get you into one kind of trouble or another.
Your actual multiplier may be more or less, but here are the factors that are always present:
- Every team overestimates their capability. It's true. (If any person on your team says "I have never failed" and it's a death march, put that person in charge and sell popcorn at the firing squad.)
- Productivity is not uniformly sustainable at eight hours per day. Only people in third-world countries can chop off arms and put them in tar, but hovering over and bullying in the real world, one is just killing the will to live of someone's baby.
- Everyone always underestimates how long debugging and testing will take, but debugging, testing, and fixing always take a significant time. I plan for 1.5 times the coding time. (Overestimating is the opposite of adding too much salt to food. Salt you can't take out, but time you can put back. This never happens.)
- The intangibles add up and take the willing and unwilling along for the ride, unwillingly.
- And, change is a constant and bugs are ever present.
In short, accounting for a third of every day as actual forward movement is the only reliable bet. The most important thing is that developers have to be given enough time to do a good job. My third-of-the-day productivity number is not an arbitrary number, and it does not leave room for loafing off. Every bit of the total estimate, including my 2.6 scalar will be needed just to get the job done.
Note: Last year, one other programmer and I wrote 65,000 lines of code in production in eight months. This year, I wrote 18,500 lines in three months. This is hand-written code, and these are darn good numbers, so my scalar personal scalar is not based on slow coding. It is based on 20 years of my experience of the intangible.
Here is the rub. A conscientious manager will never ever give you 2.6 times your original estimate up front. However, an insightful manager knows instinctively that some padding is needed but will likely provide a significantly smaller number. However, a very insightful manager will let the practitioners come up with their own estimates and trust that a genuine effort will be made to meet their estimates. The very insightful, experienced manager will anticipate that the estimates will still be off to some extent. The predicament is that trust takes a long time to build and teams are so fluid that successful practitioners often move on to higher-paying jobs just as that trust has been established and unsuccessful ones have often been terminated; hence, the trust-building must ensue anew.
An Estimating Process We Can Sell
To tackle the dynamics of trust and transition, you have to have an estimating process you can sell. This process has to begin establishing trust on both sides early. This process must include sufficient time to ultimately succeed. The process must not depend on superheroes—single-handed miracles—as these are not sustainable or reliable, and the estimates must come from the practitioners.
Here is such a process from the perspective of a practitioner:
- Let three of your most reliable developers independently provide an initial estimate.
- Take the average of all three estimates with the caveat that a finite amount of time be permitted for the initial estimate.
- Know that the first averaged-estimate must be re-estimated after all of the requirements are complete and a rudimentary design has been defined.
- Anticipate change and the unknown.
- Continually track initial estimates against actual times during the project, noting whose estimates need adjusting, and encourage everyone to account for these adjustments in future estimates within this project. (Don't punish here. Encourage.)
- If the schedule is the most important thing, be aggressive about trimming features, while encouraging practitioners to adhere to the most important features first and sticking to actual requirements. (Written requirements are harder to fudge around with "features".)
- Finally, finish the project no matter what it takes and wrap up with a post mortem to see how everyone did relative to their estimates and use this knowledge on the next project to improve the estimating process.
The implication here is that the current project estimates may be significantly different than the actual results, but if your best estimators are used on future projects, the estimating reliability will improve unless your whole team changes at once. However, even if your whole team changes at once, you will still have some baseline information, which is better than starting from scratch.
Estimating has to go on throughout a project's lifecycle, and tracking estimates to actual results has to span projects.
Managers should never estimate. Any manager six months out of a meaningful project will lose the ability to estimate any better than even the greenest of newbies, unless the manager is hiring chuckleheads. (In that case, his or her estimates will still be bad.) More importantly, when a manager estimates or overrides the developers' estimates, he is signaling that he doesn't trust his developers' estimates (or he thinks they are chuckleheads). Finally, Manager estimates are mandates that lead to burned-out superheroes and death marches. Managers are trying to obtain aggressive resource allocations to look good for their bosses, their constituency. Practitioners are trying to build good software for the customer, the real constituency. The software is the only goal that counts right now. Ultimately, everyone will be happy when projects succeed, money comes in, and estimates become more reliable.
Anticipate that more time will be needed for the intangibles than the tangibles, but that most conscientious practitioners are asking for time to do a good job and would gladly beat their own estimates. Arbitrarily huge over-estimates only come from sub-contractors padding their sales figures, but a practice of having fine-grained milestones and watching milestones closely and tracking estimates to actuals will tell you whether you have good contractors or not. Everyone knows what to do with the latter.
Finally, tracking estimates to actuals continually in the spirit of collaboratively improving (rather than punishing) will help everyone get better at estimating. In the absence of empirical numbers now, trust those who have successfully delivered in the past and start tracking estimates now. (To managers: If you don't know how or why your projects are succeeding, you have a problem, not the worst kind of problem but a problem nonetheless.)
If your software gets done, your customers are happy, and your best programmers haven't left in frustration, say a prayer of thanks but start tracking estimates.
About the Author
Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Look for his upcoming book LINQ Unleashed for C# from Sams. Paul is a software architect for Tri-State Hospital Supply Corporation. You may contact him for technology questions at email@example.com.
If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org. Glugnet has two groups in Michigan, Glugnet in East Lansing and Glugnet-Flint (in Flint, of course) and some of the best sponsors (and some of the best companies) in the free world. If you are interested in attending, check out the www.glugnet.org web site for updates or contact me.
Copyright © 2007 by Paul T. Kimmel. All Rights Reserved.
Page 2 of 2