Want to up your consulting rate? Try overwhelming force.
30sleeps.com
30sleeps.com
a) Do something measurable. "Rails programming" is not measurable. "Rails programming... where I directly contributed two million dollars of yearly revenue attributable to a 3 week engagement" is measurable.
b) Do it for rich people. (Sam Walton proves there is money to be made on selling stuff to poor people -- like, say, a ramen profitable startup -- but as a service provider, rich people are a much better market.)
They can pay your rates, and a 1% improvement in their income is much more likely to be motivating to them than a 1% improvement for a poor person, startup, etc. Take a look at your friendly neighborhood lawyers, accountants, investment advisors, etc: transactional revenue on a small number of rich people means you command rates most programmers scarcely dream of.
I mean, if a Rails consultant told you he charged what a first year associate lawyer did, many people would scoff at him. "Think you're some kind of hotshot? Sure, 15 years of experience programming, deep domain expertise, wrote book on Rails in X context, whatever. What makes you think that is worth $300 an hour!? RentAResource.com only charges $30 an hour, and I can get top flight Rails consultants for $50."
Oh, bonus points: many rich people do not perceive the difference between $50 and $300 an hour like many people here do.
3) Blog about your demonstrable ability to solve problems like X for firms like Y with results like Oh My Goodness We'd Be A Fool Not To Hire Him.
[Edit: Someone actually uses RentAResource.com? a) I'm sorry, I didn't mean to pick on them specifically but b) that is the most dehumanizing website name I've ever heard of outside of the porn industry.]
I drew this comic once, to express my annoyance with the same thing:
http://blog.codeboff.in/2010/07/13/programmers-and-recruiter...
(It's been on HN before)
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 contract and what is not, you really have to know your stuff (no training on the job!), and how you'll deal with being compensated for stuff done 'out of scope'.
You may have to re-negotiate a new fixed price based on the increased scope of the project, or you might tack on a per-hour bill for work done out-of-scope, depending on the size of the additional work relative to the original.
Good luck bidding for a consultancy job when someone else is able to offer a fixed price bid, especially if they deliver, they'll be preferred supplier for a long time to come afterwards.
Case in point, the OP writes that he took on a contract for writing a package based on a platform he had no experience with. If you do that 'fixed price' you're going to get burned, if you do it on a per-hour rate then you're screwing the customer.
Both my client and I are pretty happy with how it worked out. I charged him an hourly rate and quoted my rough estimate for how long the work originally in scope would take. When I ended up spinning my wheels because of technical issues ("First production Heroku project") or wet-behind-the-ears consultant issues ("Invoices? Is that like an internal monologue?"), I charged off most of the time wasted to goodwill. The original scope of the project got done over-schedule but roughly on-budget, and when he asked to expand scope, I told him "No problem, but the meter is running."
Towards the end of the project, where a) the client was happy since I kept delivering incremental value and b) I had hit my stride, I was not charging nearly as much to goodwill. This is effectively the same as, hmm, roughly tripling my rates over a four month period, but it didn't compromise my client's sense of my worth or trustworthiness. Plus, I didn't get left holding the bag on the scope creep.
I think that alone is a source of a large part of the trouble, customers and suppliers talking at cross purposes during the negotiation phase.
I've mostly done 'fixed price' work, and I like it a lot because both the customer and you know what is going to happen and when a job will be done. It also sets a very good barrier against scope creep, because it means they'll have to go back to get approval again, whereas if they stick to the deal as made it'll be delivered on time and within their original budget. On metered time there is no such barrier.
Fixed price is good, if you only do hourly jobs try doing a bunch of smaller jobs on a fixed price basis to get more experience with estimating and negotiating.
Not being able to do fixed bid work basically says
"I'm bad at estimating and don't know how to control
scope creep".
Many consultants are not, and are better off not getting a job than getting a job that will end up monopolizing their time for grossly insufficient money.
If you are good at these things then fixed bids can be golden. You know what you're going to make, you know the time allotted, and surprises are few. But you better be sure about this.
Hourly contracts do not preclude careful up-front estimates and clear statements of work. Fixed-bid contracts are no different in this regard.
That said, the industry as a whole is bad at estimating and controlling scope creep. The best of best practices (which we follow) and years of industry experience (which we have) don't always save you. We resolve this with our clients by noting that in the world of fixed bid contracts, unless the estimates are precisely correct, someone will come up short. In the world of hourly contracts, so long as initial estimates are in the ballpark, everyone gets good value. Our clients agree and come back time and again; we've been chosen over fixed bids on many occasions.
(Random aside: I imagine, but have no data to demonstrate, that in the world of fixed bid contracts there is effectively a normal distribution of "who won" vs "who lost." Outliers are probably dishonest or incompetent companies or consultants.)
In my experience, those that do fixed bids and suck at estimating will build in unrealistic reserves to avoid getting burned.
If you are good enough to get as close as you describe it then you could simply underbid by a bit and feel good anyway, after all it's just a small percentage of the total amount that you're risking.
If you've built up a relationship using this model then I can see how you would win against fixed bids, does that happen as well when both you and the fixed bidder are in the same pricerange and the quality of the presentations are comparable?
We often work with early stage startups, where uncertainty is a fact of life. In these cases, both parties agree that hourly is preferable.
For mid-size companies, there is certainly less distinction. We generally give a bracket (+/- 7%) outside of which further discussion is automatically triggered.
> does that happen as well when both you and the fixed bidder are in the same pricerange and the quality of the presentations are comparable?
A great question, but unfortunately it's unknowable except through backchannel heresy. I like to believe our bids are simply always better. :-)
Ah, yes I can see that, that was not clear from your initial statements, I thought you meant under 'ordinary' conditions as in when working with established companies.
> We generally give a bracket (+/- 7%) outside of which further discussion is automatically triggered.
How did you arrive at the 7%? Gut feeling or some kind of formula? (It's a funny number to pick, why not 5 or 10?)
> I like to believe our bids are simply always better.
Hehe, don't we all :)
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.
Approximately how much time do you spend in this planning phase? As for the specification, what kind of things do you include in it?
There is a middle ground here; bill in person/weeks instead of by the hour (which, by the way, is probably an amateur signal), and structure your projects in terms of milestones that have economic value to your client.
This "consulting hack" I picked up from Thomas a few months back helped land a lucrative and mutually rewarding engagement, by the way. Relatedly, it helped me give the client a menu of options: here's what you get for one week (A), for two weeks (A + B), for three weeks (A + B + C).
It gave the client easy options to adjust scope to adjust the final bill (rather than negotiating on my rate), which suits me fine, and given that I've got built-in milestones where I'll be able to demonstrate significant value to the client, possibilities for extending the contract/relationship abound. ("Things are going pretty well -- want another week out of me? I've knocked A and B out of the park, can I interest you in getting C as well, or do you want to do that some time later after I've raised my rates?")
But in general, fixed bid contracts are difficult. They incentivize the parties to spend time talking about what the agreed-to scope was, rather than spending time fixing things to however we NOW want it to work.
As someone who was just asked to bid on a fixed price contract, I agree with his comments. It is really unnerving to estimate exactly how much time it will take, especially if it is something you have never done before.
Tripling your estimate is a great strategy, but you also don't want to price yourself out of the contract (at least I don't). Work hasn't exactly been pouring in lately.
http://jacquesmattheij.com/How+to+get+better+at+estimating+s...
Good luck, it's pretty hard to get it just right.
There is a video that has great reasons for not using contracts, fixed prices or functional specs. Google "All Roads Lead to Rails" (http://unspace.ca/innovation/speak)