Vaguely how long?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Do any of you have any idea what a vague average number of hours it would
take to build a sales/service database?
It is a database for a service company that repairs and sells electronics.
It involves a sales form and a service form, from queries to tables for
customers, employees and terms.
It also involves about 15 reports.

I need just an average? I understand charges are from $40 to $100, but how
long does it take....maybe from 10 to 100 hours?

Any kind of average would help.
Thank you in advance.
Gee
 
Completely depends upon the scope of features and business rules that you
must include in the database. I have a point-of-sale database that I've been
building on a part-time basis for the past 3 years, and it's not done yet
with all the "bells and whistles" that people are requesting be added to it.

I doubt anyone can give you a "firm" estimate without knowing a lot more
than you've posted. One word of advice -- whatever time you think it will
take, multiply that by at least 2 or 3 to account for the unforeseen things
.... this by the way does not include the "oh by the way could you add this
and could the database do that" items that you're likely to get from your
client.
 
Completely depends upon the scope of features and business rules that you
must include in the database. I have a point-of-sale database that I've been
building on a part-time basis for the past 3 years, and it's not done yet
with all the "bells and whistles" that people are requesting be added to it.

I doubt anyone can give you a "firm" estimate without knowing a lot more
than you've posted. One word of advice -- whatever time you think it will
take, multiply that by at least 2 or 3 to account for the unforeseen things
... this by the way does not include the "oh by the way could you add this
and could the database do that" items that you're likely to get from your
client.

....not to mention:

-how "bomb-proof" does it need to be (error-handling, security, etc.)?
-how many users?
-does it need to work across WAN or wireless connections?
-have they given you a company style book or will you have to do
multiple redesigns of the forms and reports until the client is
satisfied with their appearance?
-does it need to integrate with their existing systems (accounting, HR,
purchasing...)
-and so on.
 
Forever.
I have a db that I started 6 years ago for my own company use. I have been
using/adding to it ever since.
Every time a customer requests something new or different ("Oh, I need space
for two reference numbers now") or even if I decide
that something should be different or if an employee suggests something
could
be different. I have to go in and change it to satisfy their/my needs.
Keep in mind that this is *my* db that I use in *my* everyday business.
I know from my own experience once someone sees a functioning db they're
going to say it would be better to do it this other way or can we add this
one little feature.

For a beginning db I have to agree with Ken and John. It just depends on how
much
functionality the customer needs.

Mike
 
1. If there is a commercial product out there that meets your needs, it will
probably be cheaper and faster.

2. To answer your question you will need to sit down and completely define
the requirements and needs of the database. What will go in and what is
expected out. Analogy: Without knowing where you are going on vacation, you
can not have much of an idea of how long it will take to get there. Even then
there might be side trips and detours.

I will not quote a customer a firm price and time unless they give me
complete requirements. Further I let them know that any changes to the
requirements will take more time and money. Often I build databases in stages
and the first stage is just to gather requirements. Often the requirements
stage takes abut 30 percent of the entire project time and effort.
 
Since I can't say how long I will say your pricing may be incorrect. It
may be true in your area but the prices you are quoting are probably more
for straight VB programing. Since this is an Access forum I am assuming you
want this done that way.
Reading into your description a little more than what the other have I
would hazzard a guess that I could do it for the $40 and hour for 60-80
hours. Since I am not self employed, do this as my main job task and would
feel guilty about the $40/hr I would have to negotiate a lower rate.

Email me if you would like to discuss this.

Craig Hornish
(e-mail address removed)
 
Gee... said:
Do any of you have any idea what a vague average number of hours it would
take to build a sales/service database?
It is a database for a service company that repairs and sells electronics.
It involves a sales form and a service form, from queries to tables for
customers, employees and terms.
It also involves about 15 reports.

I need just an average? I understand charges are from $40 to $100, but
how
long does it take....maybe from 10 to 100 hours?

I suspect the range is more like $12 - $300 per hour. That's from "starving
student working part time" to "internationally-known authority on Access."

You _want_ some guidelines, but you don't even begin to have enough
requirement detail to guess at a total. It's possible your guess is good,
depending on the details, but it could also be off by a factor of 10 or
greater.

The traditional way would be to gather and document requirements, design and
document the design of the database, then implement, test, and deploy...
estimating and agreeing on the next step only after completing the previous
one.

A more "contemporary" approach would be to agree on some minimal
functionality, implement what is necessary to provide that, then demonstrate
and modify to suit the user, then take a next similar step, and repeat until
done, working on a time and materials rate.

I've done both at different times, and both approaches worked. I think the
latter may have cost my clients a little more, because they were more likely
to change their minds after seeing what they'd asked for -- but I think the
end product was exactly what they wanted, which was not always the case with
the traditional method in the "olden days."

Larry Linson
Microsoft Access MVP
 
Back
Top