Earlier quoted context omitted.
If you can't accept fixed bid contracts you won't be doing much work in quite a few places. Fixed bid contracts are the way vast segments of the industry work. Not being able to do fixed bid work basically says "I'm bad at estimating and don't know how to control scope creep". Of course you can do fixed bid contracts. But you'll have to make an ironclad arrangement about what is to be done within the scope of the con…
Out of curiosity, how do you define a solid scope ahead of time? What kind of details do you go into? What if the client asks you to tweak a feature that's within the scope, but ends up taking up significant amount time?
For me the most important bits are:
- does all this fall within my current competence (in other words, do I have to learn something new or not)
- is the project comparable to something I've done before or is it virgin territory
- how clear is the customer able to communicate their vision of the things they want from me
- do they already have artwork / wireframes or is it that I'm supposed to be the 'main contractor' contracting out those aspects that I can not do myself
- are all the interfaces the system has to the outside world clearly defined and documented and/or accessible through existing apis?
- is there a realistic expectation as to the amount of work that we are talking about and the amount of time alloted for documenting, coding, testing & debugging
- are there hard deadlines associated with the project or not
- what do they expect in terms of after-sales when the project has been delivered (do their people take over?, do they help with building?)
- can we agree on a rough block diagram of how the system will be put together and do I feel confident about each of those blocks in terms of complexity and an estimate as to how much time it will take to realize that block
For me the 'deal breakers' if the customer wants fixed price are mostly their vision, communications issues and the knowledge about external hook-ups. If any one of those gives me a bad vibe then I'll probably either refuse the job or I'll tell the customer that it is not possible to execute this job fixed price unless they come up with solutions for those issues.
> What if the client asks you to tweak a feature that's within the scope, but ends up taking up significant amount time?
That is a very tricky situation. I think that both parties are somewhat to blame if such a situation arises, if it is 'within scope' then a tweak should not end up costing significant amounts of time that indicates a less than general attitude towards coding things, on the other hand there should be some penalty for changing the design after it has been nailed down and agreed on, even if it is within the scope since it will require re-work of at least some portion of the design.
I'd probably negotiate a reasonable adjustment of the price in that case (also to dissuade from further tweaks, or to get paid for them), and a note to the effect that the deadlines will be pushed back as a direct consequence of this.
I'd also want that documented in email with the consequences clearly stipulated.