To RFP or Not to RFP: That is the Question

Hamlet might have been contemplating the pain of life versus the fear of death as he said his famous line, “To be, or not to be: that is the question,” but a similar question is at the heart of most companies’ PLM selection processes.  Many companies are afraid of the cost and pain involved in developing a detailed RFP (Request for Proposal), but just as many companies fear equally the ramifications of not precisely defining what they want in an enterprise business system.  With this theatrical analogy now played out (get it “play”ed out), let’s explore RFP’s a bit further.  What should you do in an RFP and what should you skip? 

What are RFPs?

In simplest terms, the RFP is a document produced by an organization detailing the list of requirements for the needs identified within an organization. RFPs originate from the premise that a company can best evaluate the solutions that vendors propose if all vendors are planning to solve the same set of critical business issues.  In other words, if the RFP is detailed enough, the company expects to be able to do an apples-to-apples comparison on the proposals tendered by the responding vendors.

Why Should Buyers Develop RFPs?

  • Having to write the RFP challenges an organization to think hard about needs and benefits (ROI – Return on Investment), before involving vendors. I call it soul-searching. From a PLM standpoint, it could be as straight forward as a need to reduce cost and errors, by avoiding duplicate data entry between the engineering and manufacturing data.
  • Having something written ensures that vendors work with the same set of requirements and aids in the evaluation process – it provides a framework for objective analysis.
  • Being explicit about the requirements driving a business system purchase aligns all of the parties on the scope of the project.  This helps avoid ballooning project budgets, angry executives, frustrated consultants, and disappointed users.

Nowadays, RFP’s are being mandated for many technology purchases due to the nature of the business (risk), and various regulations imposed by management and governing agencies. But done correctly, an RFP can help vendors understand buyer requirements to position the right products and services. It can also provide a framework for helping the buyer understand the solution offerings and capabilities (mapping the vendors’ solutions against the buyer’s requirements).

PLM RFP Dos and Don’ts:

  • DO identify stakeholders for the project and involve the right people within the organization and/or business units.  Misidentifying what the organization needs can sink a project, but often after a lot of time and energy have already been expended.
  • DO consider getting outside (independent) help in writing/developing a PLM RFP.  Individual consumers often engage expert agents when contemplating significant purchases (for example, real estate agents), why wouldn’t companies do the same thing if purchasing a PLM system isn’t something they do every day?
  • DON’T treat the PLM RFP as a commodity buying process. As a buyer, it is important to understand that PLM is a transformational tool. It transforms the way companies think and do business through adoption of best in class business processes.  Requesting an opinion from a PLM vendor on how their solution fits existing, and in many cases “broken”, organizational processes, defeats the whole purpose of making a change.
  • DON’T focus on features and functions (specification of the solution).  Instead, focus on the actual pain points (requirements) that need to be addressed. PLM RFPs should focus mainly on what the system needs to accomplish, and place a secondary emphasis on how the vendor’s solution accomplishes the key goals.
  • DON’T make the RFP any longer than it absolutely needs to be – follow the KISS principle (Keep It Simple and Short).  The true goal of RFPs is to help companies feel confident that they are purchasing the right technology for their needs.  Long and detailed RFPs can eliminate good vendors through attrition.  The idea that “if they want my business bad enough, they’ll fill out a 50 page RFP,” just doesn’t make economic sense – buyers want the right technology, not the vendor with the greatest stamina or the best form filler-outers.
  • DO ask vendors to detail how their solution will address the business challenges defined in the RFP. Describe these challenges as “true” business cases, where an inefficient process needs to be revamped, or a new process needs to be introduced.
  • DO ask vendors to articulate how their solution is intuitive, how it follows best in class industry standards (process and architecture), and how it will save the company time and money in the long run.

For PLM purchases, it is important to remember that PLM changes the way companies do business; it help them be more efficient, drive innovation, be more lean, and reduce operating costs. The focus of the RFP should be to ensure that the proposed PLM system will address whichever objectives are most important to the organization – everything else should be secondary.

In Conclusion

Companies aiming to purchase PLM systems need to buy into the thought that a longer or more detailed RFP is NOT going to yield better results. Following some of the recommendations in this article will help save time on both sides of the table (buyer and vendor). Now if time is money, isn’t that a perfect start for a PLM initiative focused on helping an organization reduce costs?

I hope the article was helpful. Please leave a comment and share your thoughts.

Tags: , , ,

Read more posts by

This entry was posted on Wednesday, April 27th, 2011 at 7:30 am and is filed under Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.
  • Anonymous

    Just checking out the comment system again – not a real comment at all.

  • Ryan M

    Great atricle and good advice. Sure wish I would have read this before I sent my long winded RFP!

  • Jonathan_Scott

    Thanks, Ryan!