My friend(and really, its a friend and not me ;-)) has a web development consultancy. It's a relatively new company with recent college graduates as interns and a couple of friends the only employees. He's burnt his hand enough with the per hour payment model that he has followed till now for each project that he takes up. The estimates are generally wrong and the interns usually give enthusiastic and unrealistic estimates. He's looking for alternate strategies so that he can devote more time on development. What pricing strategies have worked/not worked for you? Can you suggest some other models that have worked for you?<p>Just to clarify this pricing strategy is for per project. Currently he gives an estimate in hours for each project and charges them the per hour rate.
><i>"It's a relatively new company with recent college graduates as interns"</i><p>Making accurate estimates takes experience - and the only way to get it is to pay the dumb tax -- make your estimates, land the job, and complete the work. Of course a person can reduce the dumb tax by analyzing billing against the estimate and the more fine grained by task the estimate and time tracking are, the less dumb tax you will pay.<p>"Hourly not to exceed" is a model I have used in my work - which is not programming. Again breaking down the contracted fees into tasks helps because I can know if I am falling behind in the early stages and cap the blood loss. Of course, I have also used flat fee and straight hourly as well.<p>In my experience fee structure should be based in part on the client's needs not yours. A client who drops the spec on your desk can handle a flat fee. The person who is going to throw wrenches in the works, gets hourly.<p>Lastly, fee structure is a way of selecting the right clients at the right price. Hourly weeds out exploitive clients. Fixed fee allows "buying the job" when you need cash or when the client relationship is desirable.
If you use an agile model you will develop the most important features first. What this does is every week keeps you focused on the top priority and ensures that when the budget runs out, the most important features will be done.<p>The reality is that if there are 100 units of work and only 80 units are possible based on the budget, either the client will be unhappy because you told him 100 units were possible or you will be unhappy because you did 100 units of work for 80 units worth of pay.<p>It is much better to just do the highest priority 80 units first and then see if the last 20 units are really necessary. When they actually have a working product in front of them, often times clients will realize it isnt worth delaying to get the last few bits.
Don't let interns establish quotes, they're not sales people.<p>The CEO should own the revenue stream, make him approve any quote (or at least anything spanning more than 1 days worth of work).