Re: starting freelance
- From: Lynn Allen <lynn@xxxxxxxxxxxxxxxxx>
- Date: Wed, 24 Sep 2008 19:20:28 -0700
On 2008-09-24 16:26:09 -0700, dardub@xxxxxxxxx said:
Thanks for the reply and information. I wasn't asking for a quote
based on the information I gave. But if someone has advice for
estimating the time required after I actually find out more about the
databases. In the past I just rebuilt the databases fresh like you
said you have done. I figured it would be faster to convert to 9 and
then import the files into the databases as separate tables however.
So maybe I should suggest starting fresh.
The problem I am facing is like you said it could take 6 hours to 50
for each file. My client would like an estimate on how long it will
take so that he knows what kind of budget is needed.
Maybe you have advice on how to estimate time spent for creating the
database from scratch. I understand that you are probably much faster
than I. I would just like to estimate how long it SHOULD take.
I assumed there are people out there who have done this conversion
process many times, and their history on time spent might be helpful
to my dilemma.
Thanks, I appreciate any helpful information.
Of course your client wants a price. Unfortunately, they're asking for hard numbers for a fuzzy deliverable. It's like standing in front of a truckload of fruit. They want you to give them a price for it, but they can't tell you how MUCH fruit it is, if there is rotten stuff hidden beneath the surface or if there are dead bodies, rampaging monsters, or a big void underneath there.
Once again, It Depends. There are factors like:
1. Complexity of business rules. Custom software-using businesses choose that path for a reason. Their processes just won't fit the usual boxed-software capabilities to run out of Quickbooks or MYOB.
2. Ignorance of their own processes and rules. Unless the customers are really savvy, they have no idea how complex their processes are, and how many exceptions they permit, and how to articulate that in a form a developer can codify into software. You can end up rebuilding structures over and over because the customer "forgot" to tell you about some huge exception or odd rule until the day before you go live. No matter how many times you ask. I once asked a customer four different times if they ever put product back into inventory, to be told every time "no." Then when asked what happens if the customer can't write a check when the delivery truck arrived, they said, "Oh, we put it back in inventory." :/
3. Number of different experience levels of users, requiring complex security and permissions design. This can also cause lots of work in interface to manage the user experience, lots of error checking for data entry, and locking down much of the solution. More experienced, or more responsible users can allow a more open, less programmed solution, using more native FM controls.
4. Interconnectivity with other data sources. If you have to grab data from a SQL system, output formatted Excel documents, push data into an accounting system, and query .asp pages, you're going to do a lot more testing and configuring than a strictly LAN-restricted solution.
5. Number of functions and entities contained in the solution. A little db that keeps track of a list of projects and personnel assigned to them is one thing. A solution that tracks an entire production process, or goes from estimate to invoice is another.
6. Number of screens & reports. Some people just grab a number out of the air for the number of tables at X hours per table, then add Y hours per layout and Z hours per report. They figure that it will all even out when some of these take only a few minutes. I don't like it because it doesn't account for the complex solution, so if you use it, based on past experience of what it takes you to do a layout or a report (don't forget the scripting!) add a LOT of padding, like 200%.
There's a whole bunch of other factors, too, but I'm hungry and it's dinnertime. ;)
Here's what I would tell your prospective client:
"I cannot determine, yet, what this project will take. To do a fair estimate, I propose we take 25-30 hours to evaluate your needs, your current solution, what your wish list is (no client I know of is ever entirely satisfied with what they have) and where we need to go. The cost for this will be $X per hour. At the end, you'll have a complete scope of work document listing all the structures and functions you want to have or need to have incorporated in your solution. This will allow me to give you an estimate based on knowledge rather than a guess."
(BTW, this evaluation work is usually billed higher than programming. Analyzing, designing and documenting is always harder than gruntwork.)
Then contract for a per-hour contract, billed every two weeks or so, based on an hourly estimate for the total job, emphasizing it's an *estimate* not a "fixedprice-imate." If it goes over, it goes over. They still pay, unless they're dissatisfied with your progress.
I'm working this way with a current client and we're both happy. I've met with them at least once every two weeks so they see constant progress, and my work and their payments go hand-in-hand.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
.
- References:
- starting freelance
- From: dardub
- Re: starting freelance
- From: Lynn Allen
- Re: starting freelance
- From: dardub
- starting freelance
- Prev by Date: space problem
- Next by Date: Re: space problem
- Previous by thread: Re: starting freelance
- Next by thread: Re: starting freelance
- Index(es):
Relevant Pages
|
