Digital Landfill

Writing proposals is like a love hate relationship, without the love. Many companies do not give proposal writing its due in the organization. Many companies believe that it is the salesman’s personal relationship with the customer that will win the deal, many companies respond to any and all RFPs by throwing together a “boilerplate” proposal with pricing. This is because many companies do not see the value in spending time and resources on proposal writing. This is where your company can be a winner by putting together a well written sales proposal that responds to the RFP requirements. This by itself will guarantee you a spot on the short list.

[Note: Our e-books are free. Check them out HERE. Have you registered for our free Fall ECM Seminars?]

8 Things to Consider When Writing an ECM Proposal

1 -- Read the RFP from cover to cover and annotate it with a highlighter and pen. If it is available in Word or PDF, use the highlight and comments tools.

And you are saying, “Gee Bud, I never thought of that.” And if you were on my end, as someone who writes RFPs, I would say that I can’t count the number of times I’ve referred the vendor back the RFP to answer a question or read proposals that seemed like they were responding to a different RFP. Read and annotate is the key to success.

2 -- Start writing down questions as you read the RFP.

Questions concern things you don’t understand in the RFP or information that is missing in the RFP.  Submit questions as soon as possible so that you don’t do double work when writing the proposal. Questions force you to read the RFP closely.

ECM RFPs can be difficult because the technology is complex and diverse – document imaging, electronic document management, records management, workflow, and all of their supporting technologies like OCR, PDF/PDF-A, storage strategies, etc.  RFPs can be written by people who may not fully understand the ECM technology array and all of its components and so you may get a requirement for workflow where there is none and OCRing of MS Word documents. Don’t be adversarial, be collegial. Keep in mind that you are the expert in imaging, or OCR, or how long it takes to implement workflow.

3 -- Once you have read the RFP and started your list of questions, begin to outline your proposal.

If the RFP gives you a proposal response format, follow it. If there is no outline, follow a general outline such as executive summary, technical section, management section, pricing, appendices. Start matching areas of your outline to the RFP and make writing assignments.

BTW, don’t throw a 27 page technical whitepaper about workflow into the middle your workflow response section – it ruins the natural flow of your response to a requirement. Save the big bulky whitepapers and studies for an appendix. In your outline, establish the appendices right away so that you can refer to them as you write….”As reviewed in Appendix B, OCR Character Analysis.” and “More detail on workflow can be found in Appendix C, Workflow Explained.”

4 -- Find all of the requirements.

This is an area that can be tricky and difficult because you often will not know if something is a requirement or not. Look for statements that have the word “shall,” “will,” “must,” as in “Vendors shall provide document library services,” or “Handprint recognition will be required.” I often built an Excel table of all the requirement statements so that I know that I am responding to each one.

5 -- Start writing as soon as possible once you have the proposal outline developed.

I can’t tell you how important this is because only by writing will you uncover even more important questions and possible issues that you may not have “noticed” just by reading the RFP. Some issues/questions will be internal to your company/solution like a lack of a certain technology or an implementation/management requirement. BTW, watch your use of boilerplate. I’ve seen vendors throw in a complete 2 page datasheet to respond to a requirement that should have taken three good sentences.

6 -- Many RFPs state that “Pricing will only be a factor when two or more proposals have equal technical points.” And this is true.

While some companies will choose the lowest price proposal, most companies want the best solution first and lowest pricing second. This is your chance to show where your product is different technically from all others. By the way, feature/benefit writing goes a long way to helping explain the value of your solution. OCR is a “feature” and “converting a TIF image to text” is a benefit. Feature/benefit selling is basic salesmanship seems to have been lost. Remember, a proposal is a selling document and it may represent your first contact with the customer.

7 -- Make time for a final review of your proposal.

I can’t tell you what it means to an evaluation team to see a proposal with lots of grammar mistakes, misspellings, sentences that are incomplete, sentences that have no context within a paragraph, and a proposal structure that is ill defined. Evaluation teams I have been on have eliminated proposals due to the overall poor quality of writing, organization, lack of effort. If possible, ask another salesman or someone not helping on the proposal to read and comment on the proposal. Some vendors have a “Red Team,” which is a second group of people who can read and evaluate your proposal as if they were the customer.

8 -- Figure out how to make your proposal a winner among all the other proposals – while staying within the framework of the RFP.

In a recent proposal effort I helped on, we determined that key to winning the proposal was the experience of the implementation team. We hammered this point many times throughout our proposal - our implementation team had the most actual experience, had worked in that industry and spoke the language. There would be no “learn on your nickel” time, no fresh-out-of-college people, and we would “hit the field running with a named senior implementation team.” We backed these statements up with solid resumes and references to similar successful implementations. This strategy not only worked, we won, but the customer mentioned this in our first project meeting. BTW, we were not the lowest priced.

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

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.

---

, Porter-Roth Associates, is an independent consultant in the world. He is author of, “,” and “.”

-----

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.