<Contract Template> Date: <current date> Name/Address: <customer> Project: <short description> Details: <long description> Estimated length: <X days> Completion by: <date> Price: <$X> Requirements: <eg access to source, persons> Customer <X> hereafter referred to as 'The customer' .. Standard business conditions: 1. Completed work produced in the project remains the property of the +customer, unless otherwise negoiated. 1a. The use of other, freely available software modules is allowed (th +ese will not be the property of the customer, but remain the property + of the community). 1b. Any existing or newly created generic reusable software modules wi +ll remain the property of the contractor. 2. Estimated time and price include the following: 2a. Creation of software to fulfill the project goals. 2b. Documentation of software, both user and admin manuals, unless sta +ted otherwise. 2c. Clearly defined milestones (project tasks), and up-to-date informa +tionabout the progress of each task. 2d. Meeting/Discussion time to clarify project goals. Using Instant Me +ssaging / EMail methods. Email and IM exchanges will be retained for +reference, with 'meeting minutes' summary docments created as appropr +iate. 2e. Installation and user support for 14 days after completion of proj +ect. 2f. Project testing in an environment as near to the deployment enviro +nment as possible. Test results will be available. 2g. Defect fixing after installation. (Subject to defect being confirm +ed as such by the development team) 3. Estimates do *not* include: 3a. Change requests - wanted features which are outside the scope of t +he original project specification, after the specification has been a +greed upon and signed. These will be evaluated and added as appendice +s to the specification, with new deadline and price estimates. 3b. Cost for changes: See hourly/daily rates. 4. Requirements: 4a. Appropriate access to any existing solution with which the project + solution must work. 4b. Access to persons needed to clarify any goals etc. Delays in this access will result in delays to the completion of the p +roject. 4c. Project specification detailing exactly which deliverables will re +sult from the project and what they will do. 4c. Project specification must be agreed and signed by the customer be +fore development can commence. 4d. Specific details to be set down in the Specification, of the envir +onment in which the project will be used. (To ease local testing). #5. We will not be liable for any disruption of work or loss of income + due to #the use or installation of the completed solution. #5a. The customer will help in defining tests to prove the solution wo +rks as #requested, and will sign off the project upon completion. 5. Tests, work completion document 5a. A set of tests to prove the software works as required will be def +ined. 5b. The customer will help design and approve the test suite. 5c. When the software has been tested according to the predefined test +s, and the results are deamed a pass, a document will be signed by th +e customer to acknowledge that the work is complete and functional. 6. Current specifics: 6a. Specification documentation will be delivered in MS Word format. 6b. User documentation will be delivered as HTML. 6c. Milestone reporting: Depends on project length, at least daily. 6d. Response time to problems with the installed solution: 'Urgent' pr +oblems occuring within 14 days of installation, 2 hours, daytimes(8:0 +0-22:00 CET timezone). 6e. Problems occuring after 14 days will be treated as change requests +, see above.
I should probably also note that it's only seen service once so far.. No doubt others have more experience.
C.
In reply to Re: Custom perl programming contract
by castaway
in thread Custom perl programming contract
by raymor
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |