GoFuckYourself.com - Adult Webmaster Forum - View Single Post

Tempest · 03-10-2008, 06:34 PM

This seems to always happen in this biz..

A. there needs to be a CLEAR set of features/functionality agreed to at the start.

B. When a programmer gives you a date, multiple it by 1.5 to 2.0.. trust me.. If you know the programmer you can adjust those numbers accordingly, but no one can schedule an unknown accurately and most people are optimistic.

C. Break the payment up into delivered feature sets. Say 4+ deliverables or weekly/biweekly... If the programmer knows that a bit more work will get him more money, he'll do it.. but if things are stretching on for months, it eventually becomes not worth it. Ensure that the existing source code must be delivered for each payment.

D. The programmer needs to make a strong stand on "new" or changed features. i.e. you make it clear that anything new etc. will need to be additional money and will happen AFTER the core deliverables have been completed...

E. EVERYTHING in writing!... i.e you talk about thing on ICQ, then you follow up with an email confirming everything.

F. It's a good idea as well that the programmer keeps a log of what he's been doing and any issues that come up.. As well as a bug database etc. that the client can enter stuff into.

I used to manage both internal and external programming teams/companies.. These are just a few of the things I did and had the programmers set up.

03-10-2008, 06:34 PM
Tempest Too lazy to set a custom title Industry Role: Join Date: May 2004 Location: West Coast, Canada. Posts: 10,217	This seems to always happen in this biz.. A. there needs to be a CLEAR set of features/functionality agreed to at the start. B. When a programmer gives you a date, multiple it by 1.5 to 2.0.. trust me.. If you know the programmer you can adjust those numbers accordingly, but no one can schedule an unknown accurately and most people are optimistic. C. Break the payment up into delivered feature sets. Say 4+ deliverables or weekly/biweekly... If the programmer knows that a bit more work will get him more money, he'll do it.. but if things are stretching on for months, it eventually becomes not worth it. Ensure that the existing source code must be delivered for each payment. D. The programmer needs to make a strong stand on "new" or changed features. i.e. you make it clear that anything new etc. will need to be additional money and will happen AFTER the core deliverables have been completed... E. EVERYTHING in writing!... i.e you talk about thing on ICQ, then you follow up with an email confirming everything. F. It's a good idea as well that the programmer keeps a log of what he's been doing and any issues that come up.. As well as a bug database etc. that the client can enter stuff into. I used to manage both internal and external programming teams/companies.. These are just a few of the things I did and had the programmers set up.