??? 04/03/06 00:25 Read: times |
#113541 - It's like I said last month ... Responding to: ???'s previous message |
Prepare the documentation first!
Then you can agree on the details in the documentation and make that part of your contract. Delivery specifications are always a necessary part of the contract, else, how can you prove beyond a reasonable doubt, that the client is supposed to pay you? You need to end up with a specification that says that you get paid if it does a, b, c, d ... etc. You can only get paid for making something work if you can agree on what "WORK" means. If you want to eat, you have to define what you have to deliver in order to get your bread. If that changes after the contract is signed, you can agree to the changes, but tell your client to "bring money." If he is allowed to change what you're supposed to do, then you should be allowed (1) to collect in full for what you've already done, irrespective of when you do it and how close to functional the work product is, and (2) set a new schedule, and, if appropriate, a new set of charges for the work. If your client isn't clever enough to write down what he wants, then he should pay you starting with a retainer of, say, $100K and you retain that as liquidated damages if he keeps making changes. Put that in your contract. You won't have much work from people who can't write down what they want, but you don't want to work for them anyway. Keep in mind, very minor changes can lead to very MAJOR delays. If his capricious demands cause your schedule to slip, it's not his fault, it's yours. Write the objective specification in great detail, including the precise details of how it is to be tested/verified that you've attained your goal. Set milestones against which you'll be paid along the way. Make it clear that the hardware remains your property until payment is made in full, and, specify exactly what monetary penalties are to be assessed against him for not paying on time, and on you for failing to deliver on time. File suit on the day that he fails to pay on time. Don't wait until the next day. Hire a collection team, with surnames ending in vowels, and first names like Guido and Vinnie. Once they've broken his legs, burned down his house, and flattened his tires, he'll see things your way. You don't want to work for free, do you? Remember, a dead client is better than an empty wallet, and, likewise, having a bankrupt client after the fact is better than being destitute. RE |
Topic | Author | Date |
How do you manage Documentation? | 01/01/70 00:00 | |
As soon as you finish?? | 01/01/70 00:00 | |
User Manual | 01/01/70 00:00 | |
it all is very simple | 01/01/70 00:00 | |
too late and totally wrong | 01/01/70 00:00 | |
you have an easy life won't you | 01/01/70 00:00 | |
Of course, you only have enough informat | 01/01/70 00:00 | |
more on the above, the beauty of the hoo | 01/01/70 00:00 | |
in C? | 01/01/70 00:00 | |
please do not accuse me of unnatural act | 01/01/70 00:00 | |
Design Info | 01/01/70 00:00 | |
viewpoint | 01/01/70 00:00 | |
General Principles | 01/01/70 00:00 | |
the clients... | 01/01/70 00:00 | |
Client Variety | 01/01/70 00:00 | |
It's like I said last month ... | 01/01/70 00:00 | |
Great | 01/01/70 00:00 | |
I, J OK | 01/01/70 00:00 | |
Repetition | 01/01/70 00:00 | |
My old DOS based suite... | 01/01/70 00:00 | |
Two categories | 01/01/70 00:00 | |
MIL498 | 01/01/70 00:00 | |
write the documentation first | 01/01/70 00:00 | |
Good points.. | 01/01/70 00:00 |