|
PureBytes Links
Trading Reference Links
|
> -----Original Message-----
> From: Jerry War [mailto:drwar@xxxxxxxxx]
> Sent: Monday, November 11, 2002 9:46 AM
> To: DH; Omega List
> Subject: Re: software contract doc
>
>
> Why should someone be paid to Start Work. I will pay on
> delivery/completion
> of partial work. Paying for work before it is done
> is why so many people get burned by contractors.
This depends somewhat upon the extent and duration of the project, and the
degree to which the contractor may have to hire others, buy materials, etc.
However, unless your consultant is either independently wealthy, or
unemployed and willing to work on any terms, he or she will generally want
to have something to live off of until the first milestone is met. The
contractor will also perceive some risk of your default, and would prefer to
have something in his/her pocket before beginning the work. Certainly,
placing the money in escrow will minimize those concerns. However, consider
the following: the contractor hits the early milestone and delivers
something that he/she believes meets the spec, but needs some work to bring
it up to production level. At this point the client might do several things
including: disputing the milestone is complete, or saying that's fine, I'll
pay for this but have decided not to go to the production milestone. Who
resolves the dispute? An attorney who has no understanding of technology?
Things can become contentious in a hurry.
My recommendation is that you try an incremental approach. After you've
talked to a few contractors, and checked their references, and done a little
more due dilligence, give the contractor a very short term contract: maybe a
one/two week effort. Use a minimal amount of paperwork, be willing to pay
1/3 up front and 2/3's on delivery. Take a look at the result, and focus on
documentation supplied, reliability, useability and the degree to which the
contractor communciates with you to make sure that you're getting what you
want. If you like the result, let him try his hand at the larger project,
but interpose more formailty and definition in the agreement, and focus on
documentation delivered, and objective criteria for measuring
completeness/correctness at each milestone.
PS: I've never seen the escrow approach used in a software contracting
setting, but it has some merits.
|