Sunday, February 1, 2015

Designing a Requests For Proposal

I like to investigate and understand business requirements, that's one of the reasons I have enjoyed participating in the design of RFPs, as well as why I like developing solutions and services.  Both provide an opportunity to understand business processes from end-to-end, and to look for ways to optimize and improve them as part of any new technology undertaking.

Well, it's been a couple of years since I started this post, and I said I'd add more details when I originally penned this article.  I'm back at it... so I'm revising this post from 2013.

So, you're part of a team that's been tasked to find the best technology solution for a problem, and you're not sure where to start.  How do you know that you've found the best option for your organization?  In this post, I'll start the walk-through process for designing a successful RFP.  You may have to read this a few times to understand it. If I get chance, I'll post an example with vendor identifiable data redacted, as well  the final scores. (update - I've added more details, I still owe the redacted examples...)

Although I've put together several large RFP's over the past twenty five years, there's always more to learn.  I've been involved in two types of proposals... one method uses a minimalist approach (just the drop dead functionality), and at the other side of the spectrum casts a wide net of requirements to find the optimal solution.

The largest effort I've led spanned multiple companies in North America, and was the most complex of my endeavors because it crossed country borders.  Topics such as regional taxation, language translation, local vendor support, country specific requirements, legal, and reporting requirements increase complexity.  In these cases, you need an active RFP working group to assist with project that is knowledgeable and can coordinate capturing the requirements.  You also need to identify qualified vendors to participate.  In our case, this included SAP, Oracle, JD Edwards, and others that had deep functionality, and could provide support in multiple languages, and cover the country requirements.

I've been involved several in other efforts, which were for mid-size manufacturers -- and have covered differing manufacturing disciplines from discrete, to process, to mixed-mode and engineer-to-order .  Of course most of these included the full suite of financials, so it's important to include someone who understands the financial transaction flow processes, and how integrated software functions, including accruals between modules.

To round out my RFP experience, I've also helped assemble an RFP for a Learning Management System replacement in Higher Education.  Here's it's not about optimizing manufacturing efficiency, its more about having the tools available to offer a rich interactive experience for students and faculty that can help facilitate the learning process.  Instead of a general ledger, there's a gradebook.  There's a slightly different take on quality control, which includes using student metrics to enhance learning, maintain engagement, and improve retention.  There are the normal interactive tools that empower the learning experience, discussion forums, activity tracking, calendars, assignment uploads, assessments, and many others that must be compared across solutions. The vendors in this market are quite different from manufacturing - and includes companies such as Blackboard Learn, Instructure, Moodle, and Desire2Learn, in no specific order.

Developing an RFP involves a number of steps.

  1. Develop a timeline and milestones for your RFP, such as when the RFP will be released, what the vendor question period will be,  when vendor responses are due, time for vendor demonstrations, evaluation complete date, when finalists will be identified, dates for the conference room pilot, negotiations period, and final contract award.
  2. Make sure that you layout the timeline and requirements clearly both internally and externally. 
  3. To avoid confusion, and potential collusion, channel all communications during the RFP process through a central common resource that collects questions, and distributes each question and response at the same time to all participants.
  4. Require the inclusion of the RFP as part of the final contract.
  5. Provide some background on your business and project, including your timeline in an introductory section.
  6. Identify and research some of you potential vendors and solutions, so you're more acquainted with industry and vendor terminology.
  7. Identify your categories for the RFP.  These could be functional areas (Marketing, Sales, Finance, etc.), technical areas (Networking, Storage, Scalability, etc.), Disaster Recovery & Business Continuity,, Student Engagement, or any of a host of topic specific areas.
  8. Expand on your categories.  Brainstorm... if there's a valid reason to ask for something, then include it.  Don't add fluff.  However, be thorough and do not stifle others ideas or requests.
  9. Scale each of your questions based on how important they are... and be consistent.  For example, you may want to weight quest that's extremely critical with 10 points, and one that's important with 5 points, and nice to have with 1 point.  If there are "deal breakers".. those where you'd walk away from the project if it didn't have that functionality as either an extremely high score (500 points), or just discard vendors who can't achieve that functionality.
  10. Don't forget to include any relevant information such as volume of documents produced over a year, users, number of miles driven, or whatever is relevant for the proposal requested.
  11. If you know someone that's strong with Excel, you can create a spreadsheet to send out for the vendors to answer, then import this back to a master scoring sheet that contains all of the related weights.
  12. Determine how... and if you're going to weight potential changes the vendor would make... and score those as well.  Be careful in this area, especially with software... you need to ensure that each vendor understands the scope and requirements.
  13. Decide how you're going to weight each category.  What's more important to you? For example, if you're evaluating software, is it the Production Scheduling, or Invoicing modules?
  14. Don't forget the intrinsic factors... add categories for customer references and weight them appropriately... check the Dunn & Bradstreet listings for relative business strength, including the Paydex ratings (payment history).
  15. Once you're comfortable with your weightings and your team agrees, then it's time to review and score the vendors.
  16. Pick a few top vendors, and send them "test scenarios" with your data, and have them demonstrate how their solution handles these.  For example, if you require a custom order configuration engine with options that generates a dynamic bill of materials, then have them demonstrate that functionality as part of the review process.
  17. Visit customers, and see how happy they are, and watch for non-verbals to see if they are really happy.  Ask some questions, and don't be afraid to probe for potential strengths and weaknesses.
  18. Make sure you work with the vendor, and know that they understand your requirements for important questions.  If there's a disconnect, there could be some issues if you cannot get confirmation that you've both got the same understanding of expectations.
  19. Negotiate life-cycle costs.  These costs include things like maintenance, annual increases, billable rates, travel and expense reimbursement rates, implementation fees, etc.
  20. Don't pick the cheapest, or most expensive solution.  Pick the most cost effective solution that meets your requirements, and that you can afford.

Make sure your requirements are concise.... don't let things up for interpretation.  For example -

Supports payroll interfaces - a very poorly question open to interpretation... what type of interfaces?  General ledger, payroll, taxes, electronic reporting, direct deposit, timecard, what?  If I'm a vendor, and I support any interface, or remotely create an interface - Yes, it's a resounding YES, I have this!

Be clear!
  • Supports real-time payroll interface to general ledger for all associated module entries, distributed by department.
  • Supports real-time payroll interface to Kronos time-card system for weekly, bi-weekly, and monthly payroll periods.
I'll try to post some examples of solid RFP questions and evaluations in a future iteration.  Where possible, do this electronically to make it easier on your vendor, and your review team.

Here's the index from the most North American RFP I led... with some generalizations...
  • Instructions - for completing and submitting the proposal, or escalations\ questions.
  • Quotation - defines how you want this proposal quoted, options, terms, etc.
  • Company Introduction - provides an overview of the company, locations, size, etc.
  • Subject Matter / Modules:
    • Purchasing Section
    • Accounts Payable Section
    • General Ledger Section
    • Accounts Receivable and Credit Management Section
    • Invoicing Section
    • Distribution & Warehousing Section
    • Quality Control Section
    • Process Manufacturing Section
    • Inventory Control Section
    • Cost Accounting Section
    • Marketing Section
    • Sales Order Entry Section
    • Shipping Section
    • Environmental Section
    • General Section
  • External Interfaces - do you have other systems to interface, or specifications you need tools providers to follow for industry standard interfaces?
  • Vendor Background - support hours, languages, response times, etc.
  • Document Volumes - scale, availability requirements so the system can be properly sized.
  • Vendor Comments - an area for a vendor to highlight specific strengths that set them apart.

No vendor can do everything, I'd suggest following some process like below... and have them select from one of the following for each item, with appropriate costs or caveats.  (Remember, your questions are CLEAR, so caveats are probably a partial meets.)
  • X - Existing functionality - as stated in the question.
  • R - Available using an end-user report writer requiring no programming.
  • C - Customization available through programming (cost estimate should be included).
  • U - Unavailable functionality.
  • F - Pending Future release, due within 12 months, with estimated release date.

So you get your RFP's back... what do you do?

If you've worked ahead, either while you were assembling the RFP, or while you're waiting for Vendor Responses, you you've had time to weight each of the questions by importance, as well as created weights for the sections, including proposal total and life-cycle cost, and intrinsic attributes of the vendor.

For the most part, it's now simple algebra... you take the question weight * the points for the vendor response (below)  to develop a mathematical model of how well each solution fits your business.  You do the same with each section to equalize this so sections are rated on importance to the project, not the number of questions in the section.

For example, you may want to give the vendors the following points based on their responses...
  • (10) - Existing
  • ( 5) - Reporting
  • ( 2) - Future
  • ( 1) - Custom
  • ( 0) - Unavailable
Someone with strong Excel skills can do develop the models and formulas, then just cut and paste the vendor responses to automatically score them and quickly adjust category weights.  That's the process I've taken historically.  To avoid bias, or any impression of impropriety, it's critical to have your question and category weights finalized before you start to evaluate the responses.  Make sure that you read the RFP responses thoroughly, and get clarifications on questions that were answered ambiguously.

Make sure you do proof of concepts for your critical functions as part of the review process, and plan to implement and evaluate a pilot process (if applicable) as a contingency to the contract.  Don't be afraid to include the RFP or key sections in the final contract.  Finally, get everything clarified and in writing - it'll lead to a more successful implementation and a a better long-term partnership.

Good Luck!  Used correctly, the RFP is a great tool to ensure that you're getting the best value.

Reposted from Aug 24, 2013 blog entry.