|
|
|
|
|
||||||||||||||||
|
|
Whenever possible, base the selection of starting material not on similarity of systems, but on similarity of functional requirements. Where previous material has been used or assembled for a new RFP, a technical review is almost always required to obtain a technically correct and coherent scope of work. The more important the project is, the more important it is to verify that the scope of work and requirements information is consistent , complete, appropriate, and unambiguous. Many project problems can be traced back to a failure of an RFP item to meet one or more of these four attributes. A common RFP error is to specify the details of how something should be implemented rather than specifying what functionality or capability is needed. Where a specific implementation is specified, be sure to include the reason why. Failure to do so could mean that better or more cost-effective technology is bypassed in order to "meeting the spec." Is each RFP requirement testable? Will it be possible for independent testing to determine whether or not each requirement has been satisfied?
|
|
|||||||||||||