[thelist] contract vs. requirements doc

[Martin Burns]

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/