I used to make a living building software for fixed prices. To make a profit, I had to prevent scope creep.
My most effective scheduling tool was a list of proposed features, each with an attached estimate. The client suggested features, I estimated them, and the client chose the order of implementation.
If the client wanted to add, remove, or reorder features, great! We'd get out the list and make new estimates. The schedule and cost would change based on those estimates. By making the schedule highly "visible", and working to update it with the client, I gave them what they wanted (fine-grained control over "what" and "when" and "how much") without trying to stuff 6 weeks of features into 2 weeks. And if I estimated something incorrectly, I didn't charge for the extra work.
I can remember only one client who liked to bully his contractors. (He was also bad about paying his bills.) I wrapped up that project quickly, and politely refused any further work, even when he offered me a small fortune.
That's a fantastic way to do it. The clarity you built in to your approach is exactly the way to resolve this sort of issue, as soon as stuff is left 'up in the air' or is not made explicit the stage is set for some kind of conflict or disappointment.
By doing it your way instead of presenting the client/your boss/whoever pays your bills with a binary choice (this or that) you present them with a menu of items with an associated cost. They know their budget and you give them the freedom to expend it the way they think is best.
> And if I estimated something incorrectly, I didn't charge for the extra work.
Very honourable, and a really good way to show your customers you are confident and willing to eat your mistakes. Things like that will create a bond of trust between a supplier and a customer in a very short time, and you probably have sold to the same customers several times if that was your attitude.
>> And if I estimated something incorrectly, I didn't charge for the extra work.
> Very honourable, and a really good way to show your customers you are confident and willing to eat your mistakes. Things like that will create a bond of trust between a supplier and a customer in a very short time...
Things like that will create a systematic overpricing of contracts. That's not a criticism of the GP, by the way, just of fixed price contracts in general.
One alternative I have heard of is to present a list of estimates along with their uncertainties and possible risks. Keep the client up to date as any risks come to pass or are eliminated. That should also help to build trust between the client and supplier.
Also, you wouldn't want to turn a scope document into one containing mathematical equations and Heisenberg's uncertainty principle.
If there is no trust, no amount of documentation will help you. So unless you're Google suing Apple, clients that don't respect or appreciate your work are better addressed as ex-clients.
Not at all. If you shift all the risk from the client to the supplier then the price will go up. There's no free lunch.
Of course you could be the client who strikes the jackpot because the supplier underestimated the job - in which case you probably won't get a great result.
I agree that this is a very good way of doing things. And when you are a freelancer you should manage your clients and take care of things like this.
What bothers me though is when this happens (and at least for me it always does) in a corporate environment, where this is clearly managing and therefor the job of the manager.
I don't mind helping with management as well as doing the actual coding, but then I'd like this added responsibility to be acknowledged so that time can be allocated for this, and that my salary can be adjusted to be closer that of a manager.
Unfortunately at many workplaces I've seen management are mostly playing politics amongst themselves, and then occasionally bully developers into taking over full management responsibility when some developing is to be done.
A very similar idea underlies the Scrum framework (and probably some other similar) - an explicit product backlog with estimates from which the product owner chooses what to implement next.
My most effective scheduling tool was a list of proposed features, each with an attached estimate. The client suggested features, I estimated them, and the client chose the order of implementation.
If the client wanted to add, remove, or reorder features, great! We'd get out the list and make new estimates. The schedule and cost would change based on those estimates. By making the schedule highly "visible", and working to update it with the client, I gave them what they wanted (fine-grained control over "what" and "when" and "how much") without trying to stuff 6 weeks of features into 2 weeks. And if I estimated something incorrectly, I didn't charge for the extra work.
I can remember only one client who liked to bully his contractors. (He was also bad about paying his bills.) I wrapped up that project quickly, and politely refused any further work, even when he offered me a small fortune.