Pricing for a specific project

[jrp]

I've read through this forum, and have appreciated the info - thanks to everyone.

I've been a full-time Mac consultant for nearly 7 years, and am trying to shift into Filemaker Solutions development - been tooling around with it for years, finally got some good scripting training, and have now landed (almost) my first major project. I'm still a little panicky about pricing issues - hoping that a specific question will bring more specific answers. I'd be very grateful for any help you pros can offer.

My client wants two very limited-use databases for tracking the processes and schedules of a particular project, these two DBs will be related to two others, a contact file and a title file, both very simple, and all will be related with various user levels and reports, etc. With the scripting and calculations involved, and with my own self-education-process, and including implementation & training, I'm estimating this may take me around 40 hours. (But really not at all sure.)

Since this is my first major project, and work has been slow anyway since September, I'm happy for it to take a bit longer than estimated, but certainly don't want to completely screw myself...nor do I want to over-quote and scare my client away.

At NYC market rates, this ends up being around $5000 - is that way too much for a project this scale? Way too little?

Again, many thanks for all your help!

[BobWeaver]

The problem is often a communications gap. What the client thinks he is getting is not what you think he wants. I have never yet done a project where the requirements didn't change (or at least become better defined) part way through. That can make a huge difference between making a nice profit, and losing your shirt.

You don't necessarily have to bill all of your hours if you feel that some of your time was not efficiently spent. Nothing makes a customer happier than finding out that he's getting a break on billing.

[Kurt Knippel]

quote:

---

Originally posted by jrp:

Hmmm...billing per hour is how I've always worked, but until now I've never actually "created" anything, just fixed problems. It seems like since I'm delivering a product, they ought to know what they'll pay for that product...maybe I'm wrong.

---

Are they buying this off the shelf? Will you be selling this to anyone else? If not, then they are not buying a "product", they are buying your time.

quote:

---

Also, since I'm still learning (obviously not telling them that) should I be billing them for the time it takes me to figure out how a calculation is going to work?

---

Are they buying this off the shelf? Will you be selling this to anyone else? If not, then they are not buying a "product", they are buying your time.

quote:

---

Anyway, based on the (limited) info of the project I described, how long might it take you? Wildly approximated, I know.

---

I could not even begin to answer this question effectively, without much more information that only meeting with the client could provide.

[jrp]

Cool. Thank you both for your time & brains - you've been really helpful.

Much appreciated.

[DykstrL]

Three other questions you MUST answer:

1. Who will own the code of the finished product?

2. Will you be providing Technical Support?

3. Who will provide training?

These issues - if not dealt with correctly - will cause you some never ending problems and will even cost you money. I guarantee that they will assume that you will provide training and technical support. At what price? Is it included? Is it hourly rate? If you are going to provide training, who provides the class room? training materials? equipment?

If your client is going to own the code, I would provide them with 3 set prices: one price for the product, one price for training (they provide class rooms, equipment, and pay for training materials separate), and one fixed price for say 2 years technical support and tweaks, with an annual renewable price. Modifications after implementation should be an hourly rate.

If you are providing technical support for a fixed price or it is part of the product price, DO NOT give them the master password(s). You should NOT let them be able to modify layouts, fields or scripts - inevitably someone will get in there and muck up a layout or trash some calculations and want you to come back a fix it - at your expense.

If they insist on having the master passwords, then your technical support should be ONLY on an hourly rate. and I would charge at least double your normal rate for fixing these kind of problems.

Hope this helps

[jrp]

Thanks for your ideas - from the advise here, and some discussion with another colleague, I'm beginning to see the wisdom in continuing my standard practice of billing per hour (taking into account the variance between the actual time it takes to do something and the time it ought to take). I'm including a time estimate for implementation and training, and one initial revision. In these beginning phases, I plan to be very generous with time tracking. After that, all support & functionality changes will be more rigorously tracked and billed per hour.

My contract states that I retain rights to the "code" and that I am licensing my client this individualized solution...that had already been decided - again thanks in part to the discussion in this forum.

A more esoteric question: much as I like the way I currently earn my living, I'm certainly not planning on doing this forever...if I retain the master password on clients' mission-critical databases, and they need changes after I've moved onto other things, they're stuck...is that entirely ethical?

*Hoping one day I can be an experienced and successful advise-giver to others*

[ November 29, 2001: Message edited by: jrp ]

[Kurt Knippel]

First do NOT ever bid by the project, you will almost always lose your shirt. Bid and bill by the hour. Giving estimates is fine, but price based upon the estimated hours.

I always bid and bill based upon an hourly rate that is acceptable for me, all I then need to worry about is filling my time with billable hours and in collecting on the invoices.

I generally invoice every two weeks with payment "due upon reciept" and I stop working as soon as any of the invoices are 30 days past due. I do not start on the client again until they are caught up on payment.

If your hourly rate is too much or too little will depend upon you and what your market will bear. Only experience will tell you if your estimate for time was accurate or not.

[jrp]

Hmmm...billing per hour is how I've always worked, but until now I've never actually "created" anything, just fixed problems. It seems like since I'm delivering a product, they ought to know what they'll pay for that product...maybe I'm wrong.

Also, since I'm still learning (obviously not telling them that) should I be billing them for the time it takes me to figure out how a calculation is going to work?

Anyway, based on the (limited) info of the project I described, how long might it take you? Wildly approximated, I know.

Again, many many thanks!

[DykstrL]

As long as you are providing the technical support, either by the hour or as part of a fixed price, I would not advocate giving the master passwords. If there is an IT person in the company you can trust, or maybe even someone who knows enough about FileMaker, you could give the passwords to him or her with a proviso that they not be used to alter or modify the files.

When there comes a time that you will no longer be providing support, or are moving on to greener pastures, then you could provide the passwords to the CIO along with notification that you will no longer be available.

[LiveOak]

Remember, this depends upon how the rights to the software are assigned in your contract. If you perform the job as "work for hire" and assign rights to the customer, you can't legally withhold the passwords, even for non-payment in some circumstances. Having said that, it isn't the same thing as being required to immediately deliver them until you are asked.

I personally work by the hour and assign rights to my clients. Most of the software I develop for them is highly specialized and ownership of the rights is of little benefit to me. However, telling a client who will contract to pay me $100,000 over the course of a contract that they own no rights to the work product will kill most large deals. Also not having an agreement not do similar work for their competitors usually kills the deal. My contract does exclude basic technology developed from these limitations. Lasting relationships with clients are based upon trust. Beating up the client too much in the initial contract is a poor way to start out. Earned loyalty through service is a much more effective way to retain clients and secure follow-on business and referrals than all the puntative legal restriction a team of lawyers can write into a contract!

-bd

[Fitch]

Well, if 40 hrs = $5000, I've got to raise my rates!

It's hard to say for sure, but the time sounds -about- right, and if that's the going rate, then I guess it's the right price too. To me, the price seems a little steep for a "simple" project -- although earlier you said it was a "major" one.

One thing you might think about is whether you are giving the client a firm quote/bid or an estimate. If the former, then double it! If the latter, pad it a little. Then you look good if you come in under, and if you go over it won't be so bad.

It's very hard to know if you're going to price yourself out of a job. Sometimes you have to be blunt and just ask, "What's your budget for this?" Even so, they are likely to give you a low number. How much lower than what they are willing to pay, tricky question. Take a secretary or techie from your prospective client to lunch, maybe you can get the scoop!

[danjacoby]

I've learned that professionals should charge what they feel they're worth, and if the client isn't willing to pay it, then either you don't need that client, or you have an overinflated sense of your worth.

Any time you compromise your price, you compromise your professional standing, and you will lose out. You will not only cost yourself money, but you won't be treated with respect; the client will think of you as a "cut rate" person.

If you're good enough at a job to charge good rates, charge 'em. Don't worry about the clients you don't get; there are plenty of others.