[thelist] contract vs. requirements doc
Martin Burns
martin at easyweb.co.uk
Sun Apr 18 03:06:26 CDT 2010
On 14 Apr 2010, at 14:55, Matt Warden wrote:
> On Wed, Apr 14, 2010 at 9:38 AM, Bob Meetin <bobm at dottedi.biz> wrote:
>> I'm reviewing a contract this AM. As a technician, web technologist, I work
>> best when I have a reasonably defined list of functional requirements in
>> front of me. With this client we've reviewed the functional requirements
>> several times and agreed upon deliverables.
>>
>> What is an acceptable way in this industry to refer to the requirements but
>> not include them in a contract? Or is it really up to the parties involved?
>> Including these details makes for a lengthy document.
>
> Do you have formal sign off from the client on the requirements
> documentation? If so, I would simply refer to the mutually agreed-upon
> requirements documented in $name_of_document and signed off by both
> parties on $date. Personally, I would also attach the document as an
> appendix.
Yep - that second document sounds awfully like a Quality Plan, which should also define
1) each deliverable's acceptance criteria
2) each deliverable's due date
3) and *how* you're going to get them reviewed and accepted (and what you do if the client doesn't play - tardiness in review/acceptance is endemic among clients)
Quite often, if you're producing deliverables through the life of the contract (fairly common - you might have requirements docs, designs, actual code etc), you'll set up payment milestones linked to acceptance key ones or sets.
Cheers
Martin
(previously Quality Manager on a team of 100+, 2 year long programme, with hundreds of contractual deliverables, where the client really, really didn't want to accept anything)
--
> Spammers: Send me email -> yumyum at easyweb.co.uk to train my filter
> http://dspam.nuclearelephant.com/
More information about the thelist
mailing list