Prev: Access 2007 appcrash during compile
Next: Warehouse templates
From: Mario Fucsi on 22 Mar 2010 21:46
I've got 20 Excel tables, one with 700 records, one with 300 records,
4 with 200 records and the remaining ones with 10-20 records each.
These tables contain the data of what will be an Access database with
(more or less) 20 between custom masks and queries.

I am the man who is gonna make the database, the customer is a
freelancer that will use it to organize his business (i.e. customers,
contracts, etc)

How much money can I ask for a job like this? I have no idea. I don't
want to work for too little money, but I don't want to ask too much
neither.
Any advice?

Thanks to everybody that will answer.
From: Tom van Stiphout on 23 Mar 2010 00:32
On Mon, 22 Mar 2010 18:46:54 -0700 (PDT), Mario Fucsi
<mfucsi(a)googlemail.com> wrote:

Too many variables.

-Tom.
Microsoft Access MVP


>I've got 20 Excel tables, one with 700 records, one with 300 records,
>4 with 200 records and the remaining ones with 10-20 records each.
>These tables contain the data of what will be an Access database with
>(more or less) 20 between custom masks and queries.
>
>I am the man who is gonna make the database, the customer is a
>freelancer that will use it to organize his business (i.e. customers,
>contracts, etc)
>
>How much money can I ask for a job like this? I have no idea. I don't
>want to work for too little money, but I don't want to ask too much
>neither.
>Any advice?
>
>Thanks to everybody that will answer.
From: The Frog on 23 Mar 2010 06:13
Your tables dont seem to be the issue, rather capturing the business
logic and forms coding that will probably eat your time - and hence
cost the customer. A contact management application can be simple or
complex depending on the demands of the customer, and logically the
more complex the longer it takes to produce.

If I were in your shoes I would try and take an educated guess at how
long it will take you to build the appication, in hours. I would then
double that number because I always find things take longer than they
should, or I am over-estimating my speed of production. Then figure
out what you think you are worth per hour, how much do you reasonybly
want to make per hour. Remember that tax must come out of this as well
as bills and the like (eg/ electricity, paper, ink for the printer,
and so on...).

So now you have an idea of what the app will 'cost' you to build, and
also what you think you are worth. The rest is a matter of negotiation
either by yourself or with the customer as to how much you can or will
make from the job. If you decide it isnt worth it then dont do it
unless you are feeling charitable of course.

I know this isnt a simple 'This application is worth $X', but at least
you can consider what it could be worth and go from there.

Cheers

The Frog
From: David W. Fenton on 23 Mar 2010 16:59
Mario Fucsi <mfucsi(a)googlemail.com> wrote in
news:0d079363-599a-4a31-9c8a-e9257565d678(a)b7g2000yqd.googlegroups.com
:

> How much money can I ask for a job like this? I have no idea. I
> don't want to work for too little money, but I don't want to ask
> too much neither.
> Any advice?

You've only described on tiny part of the project. Most of the time
in developing an Access application goes into user interface and
reports, and stitching those together in a manner that reflects the
appropriate workflow.

Something I used to do explicitly back when I was doing
semi-fixed-price projects (an explicit $$ amount that represents X
number of hours with a margin of what it covers and multiple
renegotiation points at predetermined milestones) was my private
"Access Price List":

http://dfenton.com/DFA/download/Access/AccessPriceList.pdf

That's dated 1997 (and I really don't know at this point what the
difference is between Price1 and Price2), and back then my wholesale
hourly rate was $45/hour and my retail rate was $60/hour
("wholesale" means I'm subcontracting to serve somebody else's
client, "retail" means it's my client). You could do the math to
convert the prices there to your own based on your desired (or
realistic) hourly rate.

The point is that you have to have a pretty firm idea of the design
the application in order to be able to calculate a reasonable
estimate.

You can quibble with what things I price out, relative weights and
so forth, but the idea is sound -- decide what objects you'll likely
have in the application and then figure out how long it normally
takes to build those kinds of objects. From there, you'll want to
build in a "fudge factor" for the estimate you present to the client
because you can never foresee everything. I normally do estimates
with large modules as main headings, and subsets of features within
each module priced out with an hourly range.

I don't know of any other way to get any kind of accurate estimate,
and when I use this method, it always ends up with a price tag that
is frightening. That tends to indicate either that I overestimate
the value of my work, or that I'm underpaid!

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
 | 
Pages: 1
Prev: Access 2007 appcrash during compile
Next: Warehouse templates