#NoEstimates? Let’s get real for a moment.

After many years of doing estimates and quotes, I find that a key issue is making a clear distinction between those an estimate and a quote. An estimate is not a quote. A quote must be committed to, while an estimate does not, but if not, there should be good reason, and there are different reasons which should be handled uniquely.

Over time I stopped doing quotes altogether, and make sure to have a clear conversation with potential clients about what an estimate means. This requires feeling them out for their tolerance of overages beyond the estimate, and if that tolerance does not feel high enough, the job is declined or the estimate increased to cover such allowances (although there’s some risk to that approach that should be obvious.)

In the event that I make a mistake in my initial guesswork due to a lack of proper research that leads to overages, I work hard to reduce the price to fit the estimate depending on the cause. The reduction varies; if the causes are entirely new requests completely out of scope, or if they are simply things that took longer than expected due to unforeseeable problems, unforeseen but predictable problems, or inexperience, all unique situations requiring unique analysis and varied compensation.

A strict approach is to simply chalk the entire estimate up as an estimate, and any overage is client-covered, however this is not always fair and does not build trust and loyalty.

Communication is key but it doesn't solve everything. If the clients understood everything going on with regard to programming, they wouldn't need programmers. Since they don’t, explaining everything is not always possible. Still, I don’t hesitate to give estimates — albeit qualified as ONLY an estimate, with an understanding that covers only what is in-scope, and out-of-scope work will be discussed, agreed to before starting, and itemized as such.

Another common problem is that the more accurate the estimate is, the more time it takes to do determine it, and this time is frequently unbilled or considered pre-sales work, and also not interesting to programmers (who can be quite fickle about undertaking uninteresting endeavors). However this is no excuse. A quick estimate of the time necessary to create an estimate must be done in the programmer’s mind prior to starting, and that time needs to be included in the final estimate, because it is work requiring skill and talent and should be compensated. Rushing to provide an estimate due to client demands is unacceptable, as rushing will result in a poor quality estimate that is likely to be exceeded.

In a work for hire situation, overages should be absorbed by the programmer if they are at fault and it could have been prevented or predicted. Genuinely unpredictable problems may be erroneously attributed to a lack of experience, and the programmer should stand up for himself, but also self-evaluate this and offer to cover some of the overage in this case. This brings up a topic recently raised by a client, where they expressed a distaste for “paying for the programmer to learn” — while I feel this is usually a misconception about the nature of programming, it varies by situation — if it’s a genuinely new problem nobody has tackled before, then of course the client should pay you to learn how to figure it out. But if you claim the problem is within your purvue and it exceeds your quote, then you’re partially to blame.

So, estimates are OK, quotes are not, some overages should be covered by the programmer depending on their nature, and communication is important. Few estimates are perfect and clients (or budgets) need to be evaluated for their tolerance to overages. Programmers for hire should absorb some overages but not be pushed over. Generally speaking, I think a lot of this is obvious to honest, experienced work-for-hire programmers. The nuances of in-house corporate jobs require some special treatment since programmers cannot absorb costs, though they often do anyway in the form of overtime. If you don’t like that — well, maybe you should start your own business, but be prepared to eat some overages once in a while! ☺

Erik Knepfler
HaveAByte