| Thanks for the advice, Thomas! Short answer: by turning down projects that are below your threshold I'm slowly getting to the stage where I can afford this, but I've only built up about 6 months of runway, and it seems nobody starts projects in winter, which meant I came this >< close to running out of cash in February. I'm trying to avoid a repeat performance. Is it adviseable to turn down below-threshold projects purely for reputation's sake? No matter how your SOW/MSA is structured, don't quote prices in terms of $/hour. Easier said than done. I keep doing this dance where I'm avoiding giving an hourly figure, but end up going nowhere. Do you have a more specific suggestion for how to go about doing this? Also, what does 'MSA' stand for in this context? Too many meanings for google to be useful. When you get rate pushback, follow up with a bid for a smaller or more constrained project. Slip scope. Thanks, that's useful. Thinking back, that's happened by accident a few times, but I'll consciously encourage this in future. Some customers seem to fear this though: it seems they're afraid I'll build something only I can maintain and then charge them crazy money later. Maybe this happens. I don't know. Never slip your rate. You'll never get it back. Yep. I expected that, had to do it once or twice anyway. No fun at all. Include a support retainer or annual/quarterly maintenance price, instead of giving that away for free. So far, I've just billed individually for any but the most trivial maintenance. (e.g. 15-minute fixes to bugs that were blatantly my fault) How do I avoid scope creep on flat fees without it seeming like a raw deal to the customer? |
If your BATNA is "lose house, live in box", the bill rate discussion is academic. Steadily raise your rate with new clients. Many consultants will advise you to build a steady pipeline and then raise your rates until you're turning away enough work to be 50+(Nx10)% utilized.
You can quote prices in fixed project dollar amounts (or by the milestone), and then cap your hours in an SOW. If you're working with procurements departments, it doesn't matter, since they're doing the math automatically. But don't offer up a $/hour amount.
I have less development consulting experience than many of the other commenters here do, but what I'd probaby do with regards to bugfix support is:
* Have a formal acceptance process, at the end of which the customer is responsible for signing off on the deliverable. Most large projects I've worked on are QA'd by the customer as well as the vendor.
* Have an escalation ladder for bugs, from cosmetic to data-loss, and have SLA time frames for free fixes on anything other than "cosmetic".
* Offer an up-front retainer contract for rapid (=better than SLA) bugfixes, changes, or feature requests, pointing out that if the customer does not opt for the retainer, feature additions and subsequent revisions will be full-on new projects subject to whatever your current rate and scheduling terms are.
Something I've learned in the past 4 years: scheduling risk is something many customers will pay to mitigate.