SNIP// So that leaves hourly or by the project (not mentioned). Personally, I like to do it by the project, although I am probably a minority in my preference. By the project gives the client a nice set price. However, the scope has to be extremely well defined. It should be anyway, but more so if charging by the project. I then charge by the hour for requests outside the original scope, which happens all the time. It also keeps them in check on their requests. Depending on the client, I require a third or half up front for a project. //snip Ditto, Ditto and Ditto
Bret Find a contractor or find a contract at Tech-Temp.com ----- Original Message ----- From: "Chris Wesley" <[EMAIL PROTECTED]> To: "php-gen" <[EMAIL PROTECTED]> Cc: "Gerard Samuel" <[EMAIL PROTECTED]> Sent: Thursday, July 25, 2002 12:45 PM Subject: Re: [PHP] Paying Job... > On Thu, 25 Jul 2002, Gerard Samuel wrote: > > > Do you charge by the page, script or by the hour (that would be nice). > > It's a tough thing to do, but consider charging by the project. You'll > find a most equitable payment/compensation when you establish up front how > valuable the project is to the client, and how valuable your time and > services are. I find this is the best way to put a client at ease [(s)he > knows what (s)he's paying ... no surprises, unless they're > client-inspired], and you can concentrate on the project instead of how to > make the site fit into X pages or how to justify or fit the project into Y > hours. > > Get a couple small projects under your belt, just for the learning > experience, and you'll get a good feel for a process that suits your > needs. > > Things I did to get become acquainted with a good process: > - did small projects for free, just to prove (to the client and myself) > that my code and I can survive > - did small projects for an undervalued price to get my foot in the door > of potential future paying clients, to build a decent portfolio, and to > assemble a good list references > - did projects just because I love to code and solve problems, not for the > cash. (YMMV. There are a myriad of reasons I employ this philosophy, > that I won't preach about here.) > > Typically what I try to establish up front: > - the total project specs > - terms on deliverable(s) (how many stages a project is divided into) > - a reasonable estimated time of delivery for each stage, and the project > as a whole > - documentation requirements > - feature-creep clauses (it's such a pain to have the project change > in mid-development ... you have to watch your own back for this.) > - maintenance requirements (to fix bugs for X number of days/months after > delivery ... NOT FOR ADDING FEATURES: do that in separate projects) > - compensation/fees > - payment terms (25% upon delivery of stage1, 100% by stage3, etc.) > > For FREE projects ... just leave off the last two points. Even though a > project may be done pro bono, it should still be relatively chaos-free. > A chaotic project done for free will probably just end up being a waste of > time for your client, and mostly for you. > > g.luck, > ~Chris > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
