Toolkit: Social Software RFP Requirements

Authors: Jim Lundy, Mike Anderson
Date: July 31, 2012
Topic: Social Software
Research Note Number: 2012-T2

Issues:  What are the best practices for leveraging social software to gain a competitive advantage?

Summary: Do you need to send a request for proposal (RFP) to all the potential bidders on your social software project? The bidders may not request one, but both you and they will benefit if you do. When an RFP starts the procurement negotiations, you have far greater control over how well the system you buy will meet your needs. An RFP also gives you better leverage to enforce your requirements if the system fails to meet them. 

In our inaugural Aragon Globe we evaluated the vendors who provide enterprise social software. Here, we outline the elements of an RFP that will get bids from them.

Contents

0.0 Introduction (to the Buyer)

1.0 Instructions to the Bidder

2.0 Technical Specifications

2.1 Core ESS Functions

2.2 Additional Requirements

3.0 Delivery and Execution

4.0 Maintenance and Support

5.0 Vendor Information

6.0 Additional Submission

7.0 Price Proposals

0.0      Introduction (to the Buyer)

0.1      Guaranteeing Responsive Bids

When writing a request for proposals (RFP) it is essential to clearly convey your requirements. However, it is also important to write them in a way that elicits accurate and effective responses. Avoid ambiguous statements, and keep language and definitions clear. Be careful not to “over-specify” by demanding more than the bidders can deliver; make sure that optional items are clearly labeled as such. The more mandatory requirements you include, the more likely it will be that some potentially qualified vendors may decide not to respond.

To avoid protests from losing bidders, be sure that the language, content and expectations defined by the RFP allow any vendor who can meet your needs to win the bid. Don’t micromanage the bids. If the RFP is clear, open in allowing and enabling responses, and balances mandatory requirements with flexibility for bidders to meet them, you can be confident that bidders have understood your requirements and you can evaluate the proposals on their merits.

0.2      Structuring the RFP 

An RFP for enterprise social software (ESS) should address the following key areas:

• Technical specifications
• Delivery and execution
• Maintenance and support
• Vendor information
• Pricing

The technical specifications will form the bulk of the RFP effort, and thus are the focus of this note. While these categories are applicable to most software procurements, your RFP should address the specifics of the social software domain, with a minimum of generic “boilerplate.” Bidders recognize boilerplate and will treat it as such.

In the rest of this Toolkit, material in italics is directed to the writer of the RFP – you, the buyer. All other text is addressed to the bidder. You can include this material in an RFP with the appropriate customization to fit your circumstances.

Note: This is part of Aragon’s archived research. Please visit our Coverage Areas page to view our most recent content.

Copyright © 2012 Aragon Research Inc. and or its affiliates. All rights reserved.