Creating an Evaluation Specification and eventually an RFP (Request for Proposal) requires considerable resources. However, the RFP issuer represents just one side of the coin.

The offerors that receive RFPs and are invited to return an RFP Response make up the other side of the coin. Creating an RFP Response consumes costly resources on a vendor's part. 

Picture yourself for a moment as manager in a software company that receives an RFP containing, let's say, 1,000 requirements. Before you decide to assign human resources for creating an RFP Response, you do some kind of cost-benefit analysis, weighing the prospective contract value against the cost incurred by creating the RFP Response. If there were no 'political' or other considerations that more or less press you to create an RFP Response, you might end up with a decision saying that spending $30,000 (or whatever the real cost would be) is out of proportion. However, if there were 'only' 250 requirements, you might find it worthwhile and economically viable to create an RFP Response.

As a consequence, the challenge is to strike a viable balance between effort and return. It all comes down to: "Try to get by with as few requirements as possible, but cover as much ground as possible". 

In practical terms, our recommendations are: 

• Focus on features at the specification level. For example, asking about compliance with the BPMN (Business Process Modeling Notation) Specification covers business process modeling notation in just one requirement. In contrast, you would need numerous requirements to cover single aspects, let alone every single notation element.
• Focus on critical requirements. It is a good idea to leave requirements with requirement level "may" totally out of your Evaluation Specification, if possible. Just focus on requirements with requirement levels "must" and "must not" first. In a second pass, examine requirements with requirement levels "should" and "should not". 

Not only vendors appreciate compact RFPs. The RFP issuer organization benefits also. It takes less time and effort to 'separate the wheat from the chaff'.

After you have created your vendor shortlist, but before you invite vendors for product presentations etc., you can decide to create an additional Evaluation Specification for internal use. You would include requirements at a more technical level to point the finger to critical areas that were identified while evaluating RFP Responses. 

You can import requirements from the Jenz & Partner Requirements Repository into your Evaluation Specification via drag & drop (Digital Content License is required). This is a flexible, fast and efficient approach to perform a software evaluation at minimum total cost.