When I was but a young engineer, I was developing an embedded product for a small organization whose product line went all over the world.  Partially through the development of the product, a new permutation became needed. The owner of the company, also an Engineer that at one time did work for NASA, asked me to make an iteration of the product that would fulfill this newly identified need.  I went through a breakdown of what it would require to hit the objective.  In small organization’s the employee is required to wear a number of hats so I knew of the implications of the scope of the change on the product.  It is funny, I knew nothing of the concept of Work Breakdown Structures, but I did know that to estimate effectively, you must know what will be required to reach the goal.

After my breakdown, I estimated the amount of time to achieve each element and responded back to the owner with my estimate. He did not like my answer and said “why does it take so long?”  I told him, there were specification changes, hardware changes, software changes and testing and corrective action activities.  Still, I went back and reworked my estimates to come up with another number. He once again chided “why does it take so long?”  In the end I asked him when he would like the product completed. I now knew his ideal date, and also knew that would not be possible.  I told him why his date would not be very likely and if it did happen would likely be fraught with quality problems.  I did not (could not) commit to the target date that was not possible.  Eventually, the time for the work was closer to my original estimate.