8 Things to Consider When Writing an ECM Request for Proposal (RFP)

An RFP is a tool used to purchase products and services by promoting competitive proposals among vendors. Through this competitive process, vendors offer an array of potential solutions and prices and compete with each other to win your business. Buyers evaluate the many different vendor solutions and pick the one that most closely fits their project requirements and budget.

An RFP is a vehicle that allows both the buyer and the vendor to establish a dialogue and to work from the same set of rules, requirements, schedules, and information. The opportunity to have this dialogue is an important element in the process because requirements are not always clear and the vendor, as the expert in a given technology, is allowed to question and interpret what is being requested by the buyer. Conversely, the buyer has the opportunity to question and clarify issues in vendor proposals to ensure that the product fits the need.

8 Things to Consider When Writing an ECM Request for Proposal (RFP)

1 -- Review and Understand the Technology.

ECM is a diverse set of technologies that can work together but you can also buy and use only one application. ECM – Enterprise Content Management applications can be:

•    Document imaging (scanning)
•    Electronic document management
•    Records management
•    Workflow
•    And other associated complementary technologies like OCR

If you don’t understand the above, your first stop should be www.aiim.org and the Resource Center. Many RFPs specify all technologies but the work is actually limited to an imaging system or a electronic document management system. Requiring technologies that will not be used will up your costs considerably.

2 -- Your Business Needs Should Drive the RFP – Write an RFP Around your Functional Needs, Not the Technology Solution you Think you Need.

Too often an RFP provides the answer and forgets to ask the question. We often get so anxious about the technology that we specify a complete system instead of providing key information such as what business problem am I solving, how many, what type, how long, and what we strategically want from the system – better document control, lower the price of a transaction, records management, etc. Provide the functional requirements and let the vendors “propose” the best solutions.

3 -- Requirements, Requirements, Requirements.

Too often we see RFPs without any functional/business requirements (#2 above) or RFPs with 500 “question” or “statement” requirements taken from a list found on an Internet site or “borrowed” from another RFP. If you don’t do your homework and gather “your” requirements (by interviewing users) vendors will hammer you with questions and you will be forced to do the work anyway. Functional Requirements state a fact or a need such as “ACME has 200 million paper documents with no programmatic way to identify the document type or content of the document and no way to control its life cycle.” A recent government RFP, for a small system, had 4 extensions to the due date and over 140 questions – how much extra work is involved in responding to 140 questions, some of which caused a change in requirements! Do your homework or the vendors will do it for you.

4 -- Tell Vendors How They Must Write Their Proposals.

I can tell you from experience that reading 10 or so proposals that have no common organization is incredibly difficult, time consuming, frustrating, but you get the idea. In your RFP, tell vendors how they must organize their proposals – section by section. This will help you to do a fair apples-to-apples comparison based on your evaluation criteria, which is next. BTW, you can require that proposals only be 50 pages long, forcing the vendors to edit typically overwritten material.

5 -- Establish Evaluation Criteria and Actually Use Them.

If you are new to writing RFPs, think of reading ten 100 page proposals that essentially say the same thing with potentially different technical concepts and vocabulary.  Without evaluation criteria it will be a very difficult task to clearly differentiate each proposal.

6 -- Include a Demonstration and Reference Site Visits or Calls in your RFP Schedule and Timeline.

Even if this is not your first system, include a demonstration and if financially possible, reference site visits or at least calls. In one RFP I managed, we were down to the short list of 2 vendors and our next step was a demonstration. One vendor who was very aggressive in their pricing and their proposal (and attitude), actually failed the demo – they couldn’t finish. While their proposal was a winner, on paper, the reality was they couldn’t use their own system – without a demo, we may have chosen that vendor.

7 -- Establish a Project Budget for Pete’s Sake.

How many times have we seen a project “postponed” when the proposal pricing comes in? Prior to releasing an RFP, work with vendors to get a ballpark idea for project pricing. Key to project budgeting is to understand that there are three basic components:

a.  Vendor software – pricing could be based on number of users, number of servers, both.

b.  Implementation costs -for every dollar spent on software, you may be spending two dollars on implementation.

c.  Your internal costs – you may have to hire or dedicate internal staff to implement and manage the project and may have to bring in replacement staff – this is a real cost to you and should be part of your budget.

Of the above, b and c are more difficult to estimate and b may be a serious cost center. Most system implementations fail because of implementation costs, not because the software application failed.

8 -- Establish a Reasonable Time Line for the Project.

A project timeline starts from, “Hey, could we use an imaging system to do accounts payable?” to “Wow, accounts payable is now automated and it actually works!” Conceptualization, requirements development, RFP/Proposal/Demo time, contract negotiation and award, and implementation could easily be 12 months. I worked with a company that had to stop the purchase of a system after the RFP because another, “more important” project was starting and they could not do both projects at once.

---

Bud Porter-Roth, Porter-Roth Associates, is an independent consultant in the ECM world. He is author of, “Request for Proposal: A Guide to Effective RFP Development,” and “Writing Killer Sales Proposals.”

-----

Do me a favor -- "LIKE" this blog (upper right hand corner) and I'll contribute $1 to the Juvenile Diabetes Research Foundation on behalf of my nephew.

Looking for the latest on SharePoint? Look no further -- get my free SharePoint e-book.