The converse – not knowing as much about the customer’s requirements – can also lead to the response:
“It’s just what I asked for, but it’s not what I want!”
Truth is, sometimes customers don’t know what they want until they see.
Also, dont forget feature creep. The longer you spend on the initial spec the less chance you have of coming across creep. You (or the client) will always forget/overlook something, those text fields could use some validation or there needs to be confirmation dialogues here and there. All small things, but they all add up and add time. As others have said, experience and practice is the only way to work things out. If you have neither, then spec something up in your own time and build it as if you were the client. See where your pitfalls were/are and learn from the experience.
Since we usually have a good idea on the number of windows in a project I list them out and then think of how long it will take (in hours) assuming I know everything. So a window with under 10 controls might be .5 hours. A window with 100 controls might be 4 hours.
In my second column I have a multiplier that is based on complexity of the window. The simple window would get a 1.0 while the more complex window might get a 3.
The third column multiply these together.
Add all those up. Add 20% on top of that for unknowns. Add some time for testing and bug fixing and a little scope creep.
Estimating projects is part science but mostly art form that you get better at as you gain experience.
But that’s what we do. Since we use ActiveRecord (our product) and Shorts (our product) and have 17 years of creating our own kit so we have a lot of built-in shortcuts.
Above all, I would suggest being very liberal with your estimates. We, as humans, are generally very bad at estimating how long it will take to complete projects. The larger the project the harder it is.
AMEN!
On that note, make sure your contract is very clear on what the user is buying and if its sourcecode and there are licenses of other products needed to maintain their sourcecode, that theyre itemized and included in the price as well… and if theyre not perpetual licenses, mention that there may be an ongoing renewal fee.
When I had a programming business, our lawyer explained it like this:
Theres a difference between the customer buying a bundle of sticks dipped in amber which provide a particular function as a whole and a bundle wrapped in string where the customer can untie the string and access each individual part.
The point is that most customers think theyre getting the latter (full sourcecode to do with as they please) whereas most people quoting jobs are thinking of the former. There can be a huge price difference between the two and it should be spelled out up front especially so if theres trouble later you can point to it and say this is the contract you signed, if you want more itll cost more.
Oh and make sure you include a note that says that anything not explicitly specified in the signed spec is subject to your hourly rate and that a change order may be required… even if it has no money attached to it, its a record that the customer asked for a change and signed off on how you were going to fix it.
Of course. I was simplifying the process. Our contract goes into detail on what the client gets and what parts they get non-exclusive rights to and what they can claim as their. This most often comes up with someone that wants to sell their software at some later point. After 17 years we’ve been through the legal ringer a few times on this stuff.