Melissa Swartz,  March 26, 2019

Writing an RFP (Request for Proposal) is like a painting project.  The final product is much better if you do the necessary prep work up front.  In fact, for most of the painting projects I have done, it took a while to clean and repair the surface, and remove all of the vents, light switches, and electrical plates, and tape the edges.  When it was finally time to actually apply the paint, that part went fairly quickly.

The same process is necessary when writing an RFP; you need to do the prep work.

Why should you take advice from me?  Well, I’ve written hundreds of RFPs in over 25 years of consulting.  Often, I also handle project management for our clients, so I am able to see not only the RFP process itself, but how it shapes the quality of the actual solution and its implementation. And I’ve learned from every project.

I’ve been involved in projects where the prep work was done, and in projects where it wasn’t.  I know from experience the significant difference that taking some time up front can make.

So what kind of prep work is needed?

  1. Decide what your goals are for the project. This may seem simplistic, but it will help guide later decisions.  There will be a lot of information to absorb and many decisions to be made down the road.  These will be easier if you are clear about what you are trying to accomplish.  Some common goals for a communication technology project are:
    1. Gain new capabilities. This by itself is too generic; you need to list which capabilities you are looking for, such as “mobility for workers”, or “better conferencing or collaboration tools” or “improved reliability”.
    2. Improve disaster recovery and resilience
    3. Better scalability and ease of growth
    4. Flexibility or the ability to change faster
  2. Is your existing infrastructure ready to support VOIP? If it’s not, you must get it ready before you can successfully implement new communication technology, whether cloud or premise. See this article on VOIP infrastructure requirements for more information.
  3. Decide which technology architecture will best meet your needs. Your choices, generally, are:
    1. On-premise
    2. Hosted
    3. Private Cloud
    4. Multi-tenant cloud

See this article on cloud architectures for more information about the options available.

  1. Define your requirements. You must be sure that you don’t take any capabilities away from your users when you move to a new solution. It’s highly probable that some of them have figured out a way to use your current system in a way that is unique to them.  You need to be sure that the new system can meet their needs; this may mean that they achieve the same thing in a different way (the new system may have a way to do the same thing but it may take a different process).  Just be sure that you aren’t taking away capabilities without an alternative.

In addition, you need to understand the needs of your users because it’s likely that the new solution will offer capabilities that will help them.  The older your existing system, the more likely that this is the case.

Either way, this information is essential to helping you write your RFP document and choose your new technology.

Taking time to make these decisions, and gather this information up front will save you a lot of time in the long run.  It could even help you avoid choosing the wrong technology.  And that makes the prep work worthwhile.