Tuesday, April 25, 2017

How to ensure a good Document Management RFP?


Many companies face having to launch a Document Management RFP (Request for Proposal). Some have RFP templates they re-use, while others start from scratch.

Whichever method you choose, launching an RFP involves a lot of work:

  • Before drawing up the RFP
  • While drawing up the RFP
  • During the selection of the successful company


With technical and business teams facing such a large volume of work, you would at least hope this work bears fruit and leads to the selection of the tool that best satisfies the needs that have led to the undertaking of a Document Management System RFP.

Nevertheless, many companies fail when trying to find a provider that will present them with the greatest possible benefit from an acceptable investment. Why? I think it's because they fail to share their true business needs with providers.

Many companies fail when trying to find a supplier that will present them with the greatest possible benefit from an acceptable investment. Why? I think it's because they fail to share their true business needs with providers.

When I looked into this issue, I found interesting articles, such as Carrie Hane's, which highlights the 5 reasons your RFP sucks:
  1. It doesn't focus on a problem to be solved
  2. It is a list of requirements
  3. It is sent out blindly
  4. What you want doesn't match your budget
  5. It asks for innovative ideas, added value, etc.


When reading this list, it feels like Hane works in sales and has had to deal with quite a few RFPs. In my opinion, the first 3 are clearly the ones that determine whether a tender succeeds or fails.

I want this to be a positive post, so, instead of telling you what not to do, I am going to talk about the 3 things that, in my experience, all teams should do to ensure a good Document Management RFP.


1. Find out and write down why you need a document management system


You don't or shouldn't buy/hire a document management system because all companies need to manage documents and that's it.

A project based on criteria like this one is destined to be sidelined every time a more urgent need arises within the company.

Document management software is acquired because there is a specific need:


  • Legal, audits, quality (compliance).
  • A process in which money is being lost or where there is a clear margin for optimisation and cost savings.
  • We already have a document manager that is about to collapse.
  • Information security is at risk.

This need must be well defined and justified, but not only in terms of defending the project internally. If the project remains unclear and we fail to convey it to those invited to take part in the RFP, the providers will not be able to help us solve our problem.

If the requirement that leads us to draw up an RFP is not clear and we fail to convey it to those invited to take part in the RFP, the providers will not be able to help us solve our problem.
Most teams focus on searching for specific functions. I recommend you focus on looking at how a tool can solve your problem.


2. Become an informed shopper

Some decisions are made based on feelings: I buy a Coke because I'm thirsty and I would like to have a Coke. A Coke will cost €3 at the most (at an airport), so not stopping and thinking whether buying a Coke is a good decision is a risk we can take.

Nevertheless, when we launch a Document Management RFP, we are usually talking about budgets of more than €50,000. That's 17,000 Cokes. It is therefore worth finding out what we want to buy and what is on offer before launching the RFP.


Some things you can do:

  1. Search for price comparisons
  2. Look at public pricing
  3. Request quotes
  4. Read articles from Document Management experts
  5. Talk to companies from the industry or from other industries that have already gone through a document management selection process.
  6. Test product demos or request demonstrations.

The idea is that, before launching the RFP, you know:

  • What your price range is
  • Who you would like to invite or what products you like or are a good fit.

3. Instead of a list of requirements, make a list of use cases



80% of functions requested in an RFP are not critical for users.
Eighty per cent of functions requested in an RFP are not critical for users. There is also a problem with functionality being defined in a single line, with each party interpreting that line as well as they can or wish. This especially happens when the list of requirements comes in an Excel. In this case, not even providers have enough space to explain our interpretation of the function, so neither client nor provider is sure they understand each other.

I recommend explaining specific use cases: "We need to gather documentation and information about Money Laundering Prevention from possible purchasers. We need to know at all times what we are waiting to receive, in order to ensure the documentation is complete. We receive documents via email."

This is a clearly very short case study, but it will give the provider a clear idea of your needs. It is the provider's job to explain to you how their tool can help you solve this technical challenge.


4. Ask the provider to help you see how some of their other clients have solved problems like yours

One of the biggest challenges being faced by those undertaking an RFP is that they do not know how they can solve their specific problems using a tool.

One of the biggest challenges being faced by those undertaking an RFP is that they do not know how they can solve their specific problems using a tool.


They do not know what the tool can do or whether what they are considering is feasible.

In this situation, the best thing to do is explain the problem to the provider and ask: Do you have a client with a problem like ours that you helped solve?


References are normally requested in order to evaluate how serious and reliable the provider is. I suggest you ask for references in order to understand how a tool can solve a specific problem.

I hope this post has been clear and interesting.

See you soon! Download this case study Share

No comments:

Post a Comment

AddThis