

Want to up your consulting rate? Try overwhelming force. - loquace
http://30sleeps.com/blog/2010/09/10/playing-the-numbers-game/

======
patio11
While trying 80 people and picking the best observation from the distribution
is going to help a little, how about shifting the distribution first:

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.]

~~~
kranner
>> ... RentAResource.com? ... most dehumanizing website name I've ever heard
...

I drew this comic once, to express my annoyance with the same thing:

[http://blog.codeboff.in/2010/07/13/programmers-and-
recruiter...](http://blog.codeboff.in/2010/07/13/programmers-and-recruiters-
are-from-different-planets-2/)

(It's been on HN before)

------
davepeck
I've run a software consultancy for the past few years and wish to reiterate
one of his key points: never accept a fixed-bid contract. Such contracts are
incompatible with the creative and unpredictable forces of software
development.

~~~
jacquesm
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 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.

~~~
patio11
So my first consulting contract ended up taking 5 months (calendar time, not
near 100% utilization) where I thought it would take about 1, due to a
combination of "consulting learning curve", scheduling conflicts, and scope
creep.

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.

~~~
jacquesm
But you learned a lot, and I'll bet your next estimate will be a lot closer to
the mark. A lot of this stuff is experience, both technical knowledge and
knowing how to interview your customer to get as much as possible on the same
page with respect to what's going to be built.

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.

------
blackguardx
I think this is linked to the wrong blog post.
<http://30sleeps.com/blog/2007/09/27/set-your-hourly-rate/> goes better with
the title.

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.

~~~
jacquesm
I wrote this a while ago, maybe it is of help to you:

[http://jacquesmattheij.com/How+to+get+better+at+estimating+s...](http://jacquesmattheij.com/How+to+get+better+at+estimating+software+projects%2C+for+freelancers+and+teams)

Good luck, it's pretty hard to get it just right.

------
chrisbennet
I can see doing fixed price contracts if you are doing yet another version of
something you've done before. Most of my projects are something that is half
research, half implementation. I'd lose my shirt if I did those projects for a
fixed price.

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>)

------
tocomment
Where did he send 80 CV's in two weeks to find high paying consulting gigs? I
haven't ever found such a place.

------
devmonk
This is incredibly smart, concise, and funny. Good work.

------
Spechal
:)

------
rman666
And, I really like the tag line: "Open Source Personal Development". I gots to
get me some of that :-)

