Lexicon Systems, LLC Blog

lex'•i•con: the vocabulary of a branch of knowledge. Thoughts on environment, health & safety (EHS), sustainability and information technology to support them.


Leave a comment

Good RFPs lead to better proposals

white arrows painted on ashpalt

Get all suppliers headed in the same direction.

Is a Request for Proposal (RFP) or Request for Quote (RFQ) in your future? To make sure that your RFP does not become a “Request for Problems,” consider the following advice:

  1. Engage the right team. Include a cross-section of stakeholders to develop the RFP and to evaluate proposals. 
  2. Send the RFP only to 2-3 qualified parties. By the time you reach the RFP stage, you should have a good idea of which suppliers can best meet your needs. Do not waste the supplier’s or your time just to get pricing information.
  3. State the evaluation criteria up front. Share the “high level” criteria such as fit with business needs, ease of use, supplier qualifications, etc. Spare the details.
  4. Provide project background information. This sets the stage and gives the supplier a reference point.
  5. Provide a proposal outline or response template. This  permits you to compare proposals on a level playing field. A clear outline will elicit better responses and a template should make responses easier to evaluate.  Limit the response length in certain areas as you see fit.
  6. Make it easy for the supplier to respond. Be specific with your request for information.  Avoid asking for superfluous information, and instruct the supplier to be brief.
  7. Provide a single point of contact. Typically, Supply Chain or Procurement is the contact. The single contact will ask the end-user of the product/service for help in answering questions in their domain. This levels the playing field and keeps politics out of the equation as much as possible.
  8. Request customer references–and check them! Assume that suppliers give only positive references. If you have contacts within other organization, then call them as well. Ask the same questions of each reference, including questions like, “Would you choose this supplier if you had to do it again?”
  9. Impose a “quiet period” from the RFP issue date through supplier selection.
  10. Provide feedback to ALL suppliers. After selecting a supplier, remember to give feedback to those who did not win the bid. Surprising, many organizations forget this common courtesy.

See the IT Insight archives for further reading on this and other topics related to software evaluation, selection and life cycle management

© 2013 Lexicon Systems, LLC.

Advertisements

Fresh off two software selection projects, I am reminded that software should benefit its users, not the IT group. A well-designed software application–or commercial software implementation–starts with documenting clear, solid business requirements.

Solid requirements (prioritized business needs) are critical to success. Good business requirements, coupled with objective evaluation criteria, can help a company to identify a short list of vendors and select a solution that best meets their needs, fits the company’s IT maturity and culture, and that users will adopt.

what happens in vagueness stays in vagueness

Business requirements must be clear, not ambiguous, to both users and IT.

Consider the following tips when developing business requirements. When eliciting requirements, the business analyst should:

  • be clear, not ambiguous.
  • document business needs in terms familiar to the users–not IT terms.
  • help stakeholders reach a consensus on needs (“what” the software does).
  • help the stakeholders to develop standardized business process work flows that are simple enough to use day in and day out. The software implementation will reflect these work flows, which “behind the scenes” are well thought out and can handle exceptions with built in “business rules.”

When eliciting requirements, the business analyst should not:

  • document “molecular” requirements; each should be “atomic” and describe a specific need.
  • discuss the software features or look and feel (“how” the software does it) This will happen after software selection, during design.
  • allow certain stakeholder’s opinions to override what is best for the group as a whole.
  • help stakeholders to develop different work flows for different locations. Use “business rules” to address differences and to allow consistent, enterprise-wide data roll-up and reporting.

Read more about an approach to well-designed software.

Click here for a wealth of articles on software business requirements, evaluation and selection, and managing the IT systems life cycle.