On Mon, Sep 29, 2003 at 10:22:40AM -0500, Sasha Borodin wrote:
> I'm really just trying to understand the per/hour vs. per/project
> difference. But...
>
> -I'm in Dallas, TX
> -I'd be working for myself
> -I've got 3 medium sized projects under my belt with java, much more with
> other web-app technologies.
>
> The problem is that these clients are medium-size businesses; they aren't
> "offering" a rate, it's up to me to tell them how much I charge, what they
> can expect the total to come out to, etc. Being new to *paid* work ;-) I'm
> just trying to understand what's reasonable.
I would recommend two books:
_The Computer Consultant's Guide_ by Janet Ruhl
_The Geek's Guide To Internet Business Success_ by Bob Schmidt
_The Computer Consultant's Guide_ excelled at covering nuts 'n
bolts sorta stuff, where most other consulting books I looked at were
about marketing, sales, business plans and forms. Ruhl's book was a
breath of fresh air.
Ruhl's website is at www.realrates.com, which may also have some
good advice on what the going rate is where you are. A quick skim of
the realrates.com suggests that this book may no longer be available,
but her other stuff is likely to be worth a look.
Bob Schmidt's book is nuts 'n bolts oriented also, but it struck
me as a little more general. It may have been updated since I read it
in 1997 or 1998, back then it was definitely geared towards web
designers. The technology has changed, the types of projects are
vastly different, but most of the business aspects are the same. Even
though this book won't 100% apply to waht you're doing, after you read
it, you'll have much more of a context, a framework to compare and
contrast your own situation against. Odds are, you don't even have
that, right now.
What another poster pointed out is dead on, you're going to have
to deal with all of the killer project planning issues. There are a
zillion books and articles out there on this topic. I can't distill
all that down to a single post, but I can give you a couple of rules
of thumb:
1) when bizguys ask you initial questions about time and costs,
they don't want a detailed, point-by-point estimates. They're usually
so completely in the dark that they don't even know what city they're
in, let alone what ballpark.
I usually lead off all responses to such questions with order of
magnitude (days, weeks, months) and then start to ask qualifying
questions, i.e. "Could be a day or two, could be a couple of weeks,
depending on whether it turns out to be easy or hard."
2) bizguys always seem to remember the lowest/highest number you
give them, no matter what you say first or what you say last, or what
gotchas you warn them about, etc. This is part of why I prefer orders
of magnitude.
Be on guard against this; avoid making offhand comments about
when things will get done, or time estimates. I'm not saying you
should make your relationship with the bizguys adverserial, but they
didn't get to be bizguys by passing up any opportunity. Plus, it's
just human nature on their part, and even on your own. Counteract
this by keeping careful track of your estimates and reiterating them
when appropriate.
3) I try to only give answers when I've already done what they're
asking me for. No matter how close a grasp of the proposed idea you
think you have, unless you've built one before, you don't really know
if it's going to turn out to be that simple.
If I haven't done it in the past, I'll tell them I'll look into
it; if they press me at that point I'll give them a *very* loose order
of magnitude. E.g. if I think it'll probably be days, but I've never
done it before, I'll say weeks, but it might be less after I look into
it. Then I go look into it. Ideally I prototype it as part of my
"looking into it". In other words I get a working example of the most
unknown and important parts of the proposal. If the prototyping goes
well and easily, then I can make a valid guess at what'll be necessary
to do the project.
4) There are many knowns. There are many unknowns. Sit down and
map out the knowns and unknowns. Break down the knowns into as much
detail as you can, put time and cost estimates next to each one. The
process of doing this (and make a habit of doing it, repeatedly, and
of referring back to your notes, correcting any estimates, adding in
any missed items) will help you narrow down the X factors in your
project plan.
I don't know that you should necessarily show the above to the
bizguy - certainly not in the excruciating detail I'm suggesting, that
would lead to them micromanaging you - but it definitely is something
you should have in mind.
Bizguys don't deal well with unknowns (well, actually, they do,
but part of how they do is by avoiding unknowns where at all
possible). They especially don't deal well with big unknown X factors
in the middle of big unknown territories like software development.
You can't make the unknowns go away, but you can at least map them out
for the bizguys.
--
Steven J. Owens
[EMAIL PROTECTED]
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - Me at http://darksleep.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
