What to charge?

  • Thread starter Thread starter Dan Dan the OTTR Man
  • Start date Start date
D

Dan Dan the OTTR Man

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.
 
What's the going rate in your area?

Does your customer have access to and/or the stomach to seek out off-shore
resources?

Can you point to/demo a history of doing what your customer is seeking?

What level of experience/expertise are you bringing?

If you decide to bid this as a fix-price job, be aware that the
user/customer rarely identifies (or even knows) what s/he wants ... be sure
to include a cushion for yourself when s/he says "oh by the way..."

If you bid this on an hourly basis, are your hours any better/worse than
your potential competitors (that is, can you get it done in fewer hours ...
assuming you already know exactly what's to be done <g>).

A third approach is to offer an hourly rate and a series of successive
approximations. By chunking the job into smaller pieces, and offering
something of value to the customer at the end of each chunk, the customer
has something s/he can use and you get paid. And you both get to decide
whether to take on the next chunk.

Good luck

(and in case I didn't make it clear, my answer is "it depends...<g>" -- too
many factors to offer a pat answer).

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentioned in
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.
 
What's the going rate in your area?

Does your customer have access to and/or the stomach to seek out off-shore
resources?

Can you point to/demo a history of doing what your customer is seeking?

What level of experience/expertise are you bringing?

If you decide to bid this as a fix-price job, be aware that the
user/customer rarely identifies (or even knows) what s/he wants ... be sure
to include a cushion for yourself when s/he says "oh by the way..."

If you bid this on an hourly basis, are your hours any better/worse than
your potential competitors (that is, can you get it done in fewer hours ....
assuming you already know exactly what's to be done <g>).

A third approach is to offer an hourly rate and a series of successive
approximations.  By chunking the job into smaller pieces, and offering
something of value to the customer at the end of each chunk, the customer
has something s/he can use and you get paid.  And you both get to decide
whether to take on the next chunk.

Good luck

(and in case I didn't make it clear, my answer is "it depends...<g>" -- too
many factors to offer a pat answer).

--

Regards

Jeff Boyce
Microsoft Access MVP

Disclaimer: This author may have received products and services mentionedin
this post. Mention and/or description of a product or service herein does
not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.





- Show quoted text -
Click to expand...

Thanks for the advice!
 
1) Charge by the hour. The only time to charge by the project is if you have
a very detailed specification of what is wanted and you can make a good
estimate based on the specification of how long the job will take. Even then
you are at risk if you guess wrong, the customer wants to amend the
specification but not change the cost.

2) What hourly rate depends on a number of factors.
-- What is your skill level? I am expensive by the hour, but I can sometimes
do in 30 minutes what someone else will take 8 hours to do.
-- How badly do you want the job?
-- What is the approximate range of rates in your locale?

John Spencer
Access MVP 2002-2005, 2007-2010
The Hilltop Institute
University of Maryland Baltimore County
 
After having to learn the lesson the hard way, I agree to work by the hour.

Assuming that you are in the USA, you will probably be working as a 1099
Independent Contractor. They will give you a 1099 tax form, probably at the
end of the year. YOU will have to pay all the taxes on your wages. That could
mean that the money actually staying in your pocket could be as little as
half of what you charge. You also want to make quarterly payments to the IRS
or you could have a very sad surprise come April 15th, 2011.
 
Dan Dan the OTTR Man said:
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.
Click to expand...

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.
 
Dan Dan the OTTR Man said:
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.
Click to expand...

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
 
Larry Linson said:
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
Click to expand...

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.
 
I describe that early "education" in my article "Why Fixed Bid
Software Projects Are a Bad Idea" at
http://www.jstreettech.com/newsletters.
Click to expand...

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.
 
Good article, but I still think that there's a real issue with
estimating.
Click to expand...

When I do presentations on managing software projects, I like to say
that writing software is easy. Estimating how long it will take is
hard.
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.
Click to expand...

We estimate after we get a general idea of the requirements, which
might be after a free consultation or a 30-hour Phase 0 - it depends
on the scope of the project. This is a "top down" estimate with hours
for just the various stages (design, construction, conversion,
testing, etc.)

Then we estimate the whole thing again after we've designed the
database and sketched all the screens, reports, web pages, functions,
etc. This is the "roll up" estimate. It usually occurs about 1/3 of
the way through the budget (for Access projects). This is also where
we add a contingency, because it's much more likely that we've missed
something than counted it twice. :)
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).
Click to expand...

True. Well, not many times and keep your business going, anyway.
That's why a reasonable accurate initial estimate is so important.
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).
Click to expand...

Yes, this is our point person, or project "champion". They have true
ownership of the project design from the client's perspective. If we
don't have a champion, or if they leave part way through, the project
will be much more difficult to deliver.
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!
Click to expand...

Definitely! Smaller clients & projects are really nice. But the
bigger ones keep more people on my team busier for a longer period of
time, so they are welcome as part of the mix.
But, yes, it's a good article. I've bookmarked it and may use it
with future potential clients.
Click to expand...

Thanks David, I appreciate your comments.

Armen Stein
Microsoft Access MVP
www.JStreetTech.com
 
When I do presentations on managing software projects, I like to
say that writing software is easy. Estimating how long it will
take is hard.
Click to expand...

I have always said that the only time I can give an estimate that's
within 10% of accurate is 6 months after the project is
complete...and sometimes I'm not even sure about that!
We estimate after we get a general idea of the requirements, which
might be after a free consultation or a 30-hour Phase 0 - it
depends on the scope of the project. This is a "top down"
estimate with hours for just the various stages (design,
construction, conversion, testing, etc.)

Then we estimate the whole thing again after we've designed the
database and sketched all the screens, reports, web pages,
functions, etc.
Click to expand...

I haven't had a bottom-up app design in years. I'm usually brought
in to take over an old Access app that needs to be enhanced, fixed,
brought up to date and expanded. My newest project has data back to
1993, though I think it only started in Access with A97. My previous
big project (which lasted from May through Sept.) was an app that
was started in Access 2 in 1996, and upgraded along the way but
NEVER SIGNIFICANTLY ENHANCED over that whole time. There was a huge
backlog of needs, and the client had gotten estimates of $25k-30K to
rebuild the whole thing in some different platform (nobody wanted to
touch the Access app). I brought the project in at under $6K, and
exceeded the original conception of the project by the clients about
about 1/3 functionality and features.

It wasn't all that hard, either.

But it was one of those great projects where I was working with
really smart people who understood a lot already and had clear ideas
of what they needed and wanted, and were also allowed by their boss
to take the time necessary to work with me to get it right.

It was really a great project, and I look forward to returning to it
for a third round of smaller enhancements in the next few months (we
already did a second round in December).

So, these things are much harder to estimate, as you have to figure
out how to fix what's already there without breaking daily
functionality. I often tell clients that it's easier to build a new
house than to remodel an old one, but that doesn't mean we tear down
all the old houses and build new ones.
This is the "roll up" estimate. It usually occurs about 1/3 of
the way through the budget (for Access projects). This is also
where we add a contingency, because it's much more likely that
we've missed something than counted it twice. :)
Click to expand...

I adjust as I go, breaking the project down into 10-20 blocks so
there's almost never any chance of any one part getting too far out
of hand. That is, there's an overall first estimate, a pilot project
to implement some new desired feature set, and then the experience
with that is used to reality-check the original high-level estimate.
It's also at that point that I have delved into the guts of the
existing app and have a pretty good idea of how rotten the plumbing
is! From then on, I find it pretty easy to accurately estimate each
of the 10-20 hour blocks, and it's only when I'm implementing
something new that I miss the mark (that happened only once in the
summer project, and I caught it early and the client decided to go
ahead and invest the extra time, because it was a high-value
feature).

It really does require incredible cooperation with the users/testers
for all of that to work, though. You know, the kind of people who
will laugh when I tell them "Attached find a zipped up database
update with an entirely new set of bugs for you to enjoy..." instead
of getting mad at me!
True. Well, not many times and keep your business going, anyway.
That's why a reasonable accurate initial estimate is so important.
Click to expand...

I stress that early on, I don't have enough information to be very
accurate, so the error bars are much larger. As I learn more about
their apps and about the specifics of what they need and how their
organization works, I'm able to narrow those error bars. And I've
found the easiest way to keep things accurate is to break things
down into the smallest chunks possible. This often has the result
that you're giving a menu of modular choices that also help the
client budget (or feel like they have control over the budget), and
I've never had a client who didn't respond well to this once they
got into the swing of it.
Yes, this is our point person, or project "champion". They have
true ownership of the project design from the client's
perspective. If we don't have a champion, or if they leave part
way through, the project will be much more difficult to deliver.
Click to expand...

I had a terrible situation a few years about where a $15K project
was 2/3s paid for, and 90% complete when the project lead became
ill, went into the hospital, and never returned to work, retiring
instead. The project died with his departure, and I never got the
last payment (though my price structure was such on that project
that I didn't lose money).

I've also had a fairly large project where I'd hired outside help
and paid them out of my own pocket before getting paid, and then the
project gets killed after a management change. That was a bad time,
but at least I was making enough money that it didn't kill me. It
would definitely be a bad problem these days as I don't have that
kind of project load any longer (in the last 10 years there's been
huge downward pressure in the NYC area on hourly rates for what I
do, and I've barely managed to stay even in nominal $$, which means
I'm making less).
Definitely! Smaller clients & projects are really nice. But the
bigger ones keep more people on my team busier for a longer period
of time, so they are welcome as part of the mix.
Click to expand...

I'm a lone wolf and prefer it that way. Every time I've found
someone really stellar to work with, they've ended up getting a
full-time job and then couldn't work with me any longer! So I've
decided to only pursue projects that I can do on my own. This has
worked out pretty well, as it also means I've got nobody else
depending on me and no overhead. I would not have made it through
the last five years had I not decided to operate in that way.
 
I think that it is immoral to charge for any work using Jet.

it's a worthless database format.

move to SQL Server / Access Data Projects if you really want to give
the best solution to your clients
 
I think that it is immoral to charge for any work using Jet.

it's a worthless database format.

move to SQL Server / Access Data Projects if you really want to give
the best solution to your clients
Click to expand...

ADPs have their place as a solution. As does Jet.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
Jet has no place anywhere.

Jet doesn't support _RAM_ it doesn't support _X64_ it doesn't support
multi-core processors.

-Aaron
 
message
I think that it is immoral to charge for any work using Jet.

it's a worthless database format.

move to SQL Server / Access Data Projects if you really want to give
the best solution to your clients
 
Back
Top