Two weeks ago, I was involved in a car accident. Another car “T-boned” into my car at an intersection. The right side of my car was completely damaged, even the tires. Luckily no one was sitting on the passenger side of the vehicle and the damage was limited to just the cars.
I showed the damage to a friend of mine before heading down to a auto body shop for insurance estimate. My friend Jason, who knows cars, took one look and guessed it would cost probably $6500 to repair the car.
Afterwards I went to the shop and had the car photographed for insurance claim. Several days later, the insurance company estimated the repair cost would be $3500. That’s quite a discrepancy!
Once the repair started though, the body shop quickly determined the estimate was way off and filed for supplement claim. The total cost of repair? Between $6000-7000.
Which begs the question: why was the initial insurance estimate so far off? Well, the answer is that the insurance adjuster never saw the car in person; instead, he relied on the photos sent by the body shop. As a result, he missed many parts that could not be repaired and needed replacements. Have we all done this before in our own business?
You betcha. How many times a software development project got out of control from the initial cost and time estimate? I’ve seen lots. Often, the person making the initial estimate relied solely on the product requirement document, without fully understanding the nuances of the underlying business problems. To me, the lesson from the car repair is this: Get as close to the source as possible. Get find hand knowledge of a business problem. Never base your estimate solely on the requirement documents.