Prev: Managing our data
Next: Field Property Sheet Tabs; don't see
From: Armen Stein on 12 Feb 2010 12:03
On Fri, 12 Feb 2010 08:30:02 -0800, Jerry Whittle
<JerryWhittle(a)discussions.microsoft.com> wrote:

>After having to learn the lesson the hard way, I agree to work by the hour.

As many of us have! And not always in software development. My first
lesson was years before I started my programming career.

I describe that early "education" in my article "Why Fixed Bid
Software Projects Are a Bad Idea" at
http://www.jstreettech.com/newsletters.

Cheers,

Armen Stein
Microsoft Access MVP
www.JStreetTech.com

From: Arvin Meyer [MVP] on 12 Feb 2010 12:16
"Dan Dan the OTTR Man" <maxwell.dan(a)gmail.com> wrote in message
news:deccfd14-bdf1-4ba9-9940-618a4e40d204(a)o3g2000yqb.googlegroups.com...
>I may have an opportunity to do some freelance work on an Access db.
> Has anyone here done this before? I'm wondering what I should charge
> for the service. Do I charge by the hour or by the project? Any
> advice is appreciated.

I will only work by the hour. The way I work is at:

http://www.datastrat.com/DataStratConsultingPractices.html

What you should charge depends upon your experience level and the size of
the job. I typically charge $150 per hour, more if I must work on site, and
less if the job is large enough that I can work continuously for several
weeks or more. I do have 17 years experience with Access though, and more
than a million lines of code in my code library, so what I can do in
minutes, generally will take less experienced developers several hours or
more. I also have a degree in Business Administration and accounting, so I
am very familiar with business problems and how to turn them into business
rules.

My advice is that you first assess the job to see if you think you will be
successful. If you're not sure, don't take the job. Bad advertising is worse
than no advertising. Double the amount of hours that you think it will take,
then add some more. (I add only 5%, because I'm experienced enough to
estimate well). Don't work too cheaply, or you always will. It's hard to get
a client to pay $75 and hour after you've been charging him $30 an hour.

Don't get conned into working by the job, if you think you're not being
efficient, don't charge the client for those hours. For instance I had a
client that required Bates Stamping (stamping of legal documents) I had no
idea how to program that or to work with an existing program. It took me
about 7 hours to find the right program to work with. I charged the client
for 2 hours because someone who knew that already would have taken about
that long to program the connection.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


From: Larry Linson on 12 Feb 2010 23:45

"Dan Dan the OTTR Man" <maxwell.dan(a)gmail.com> wrote

> I may have an opportunity to do some freelance
> work on an Access db. Has anyone here done this
> before? I'm wondering what I should charge for
> the service. Do I charge by the hour or by the
> project? Any advice is appreciated.

You've received good advice. I'll just add my suggestion, also, that you
work by the hour. Unless the contract is something like "teach my existing
introductory class", it is virtually impossible to write a contract with
specific-enough and complete-enough specifications that you aren't
potentially opening yourself up to "a life of involuntary servitude" with a
fixed-price contract... the only worse kind is "best estimate with fixed
upper limit".

I'll also suggest that you insist on doing up-front documentation of the
user's requirements, and design documentation on how you are going to adress
them, and that you do not move on to implementation until the client has
signed off agreeing to both. Yes, you should be paid for this up-front work,
too. And, you should not be surprised or angry if the client uses it to seek
other bids on implementation; after all, you will have been paid for your
interviewing and writing time.

Larry Linson
Microsoft Office Access MVP



From: Paul Shapiro on 13 Feb 2010 08:53
"Larry Linson" <bouncer(a)localhost.not> wrote in message
news:OSJXodGrKHA.4284(a)TK2MSFTNGP04.phx.gbl...
>
> "Dan Dan the OTTR Man" <maxwell.dan(a)gmail.com> wrote
>
> > I may have an opportunity to do some freelance
> > work on an Access db. Has anyone here done this
> > before? I'm wondering what I should charge for
> > the service. Do I charge by the hour or by the
> > project? Any advice is appreciated.
>
> You've received good advice. I'll just add my suggestion, also, that you
> work by the hour. Unless the contract is something like "teach my existing
> introductory class", it is virtually impossible to write a contract with
> specific-enough and complete-enough specifications that you aren't
> potentially opening yourself up to "a life of involuntary servitude" with
> a fixed-price contract... the only worse kind is "best estimate with fixed
> upper limit".
>
> I'll also suggest that you insist on doing up-front documentation of the
> user's requirements, and design documentation on how you are going to
> adress them, and that you do not move on to implementation until the
> client has signed off agreeing to both. Yes, you should be paid for this
> up-front work, too. And, you should not be surprised or angry if the
> client uses it to seek other bids on implementation; after all, you will
> have been paid for your interviewing and writing time.
>
> Larry Linson
> Microsoft Office Access MVP

I agree on a paid first phase for developing specifications and a
preliminary design. I've always told clients they should feel free to
solicit other development and implementation bids based on that document,
but to the best of my knowledge no one ever has.

The very few times I've been "forced" into fixed-price (large jobs at a time
when I could use the work), I made my best estimate, increased it for the
bid, and usually did not make my desired hourly rate. On the other hand, if
I didn't have work at the time, a lower rate was better than none. Most of
the other times fixed-price bids were requested I would either convince the
client it was not in either of our best interests, or double my estimate for
the bid and I never got the job. And I was not disappointed. If you're going
to assume the risk for the client's incomplete knowledge of requirements,
you should be compensated for taking the risk. Even when a contract states
that specification changes are to be negotiated as additional cost items, it
becomes an unpleasant, constantly confrontational situation.

From: David W. Fenton on 13 Feb 2010 17:41
Armen Stein <ArmenStein(a)removethisgmail.com> wrote in
news:8u1bn5p2ba2d9ujs7jk0tribh1hul9ntpo(a)4ax.com:

> I describe that early "education" in my article "Why Fixed Bid
> Software Projects Are a Bad Idea" at
> http://www.jstreettech.com/newsletters.

Good article, but I still think that there's a real issue with
estimating. As you say, you can't really estimate accurately until
you're well into the project. But even with that caveat, it's really
hard for a customer to hear that the cost is going to exceed that
high number they got for the first estimate. Yes, they understand
perfectly well that the new number is based on more information and
perhaps a change of scope, but a good manager wants to have solid
budgets and doesn't want to have an open-ended commitment.

I have always tried to build my projects with milestones such that
there's the initial estimate, a re-estimate at a designated midpoint
and then a final assessment at the end of the project. My main
problem is that the midpoint often gets schedule too early in the
project, and a 2nd "midpoint" needs to be added.

My point is that it's completely reasonable for the client to want
hard numbers -- it's the job of a fiscally responsible manager to
control costs. So, I give my first estimate, and re-estimate as many
times as necessary, but I still keep in mind that I've got a range
for a realistic final cost that has been set up by the original
estimate (you can't estimate $2,000 and then say oh, by the way,
it's going to be $20,000).

It's also a constant struggle in that the managers are seldom
involved in the actual development process so don't understand the
evolution of the project. It's always good to have somebody on the
client end who is deeply involved in the development process who can
explain the issues to the finance department (or whoever has control
of the budget).

I'm lucky on my current active projects to be dealing with
organizations of fewer than 5 people, so I have very little of this
problem. I really prefer these type of clients to larger
organizations because of the direct communication and lack of
bureaucracy. They also pay quicker!

But, yes, it's a good article. I've bookmarked it and may use it
with future potential clients.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Managing our data
Next: Field Property Sheet Tabs; don't see