« Marketing Your PMO - Positioning Project Management
Project Portfolio Management (PPM) Domains - Part II »

There Is No Such Thing as a Perfect RFP (Request For Proposal)

August 18, 2008 | Author: PM Hut | Filed under: Requirements Management

There Is No Such Thing as a Perfect RFP (Request For Proposal) (#2 in the series Practical Best Practices for Infrastructure Projects)
By Natasha Mocke

Many of my customers create requests for proposals (RFP). Although this is an exciting time in their lives, and involves lots research and due diligence, the actual project delivery that results from the response they choose to ordain fails miserably. Most of the time it’s because of simple things that could easily be corrected in their approach.

Firstly, try to remember that when you are creating an RFP you are asking an external entity to walk down a road with you. In partnering on any project of significant complexity it is better to understand what this might mean.

  • Be realistic with your deadlines. You might believe you can put pressure on external entities to help you deliver on your goals, but if you’re doing so because you didn’t put adequate planning in place or because you procrastinated it is unlikely anyone you partner with is going to be able to deliver in six months what you had to deliver in two years.

  • Give out as much information as possible. Many of my customers host a single RFP briefing session. These are normally one to two hours and they tend to talk through most of them with a bit of lip-service to questions external organizations that are responding may wish to ask. I think the question window needs to be longer. Consider who benefits from that the most. Why would a customer not want an organization to be genuinely interested in getting the best result for them. Clarifying questions are critical to providing a response that meets the actual needs.

  • Be sensitive to competitive advantage. Consulting organizations thrive on their IP. Its the secret sauces that gives them their competitive advantage. Often the very questions that make the most sense to be asked are simply not because the customer that issues the RFP insists on sharing all questions and answers with all parties. I recognize that some questions are obvious, such as, “how many workstations are affected by this project,” and the customer may not want to answer those multiple times, but others are not. Consider that you may want to be engaging with an organization who is really prepared to think through the problems and resolve them, rather than an organization who grabs at IP and provides the cheapest bid. It’s a tough balance to strike, but perhaps consider allowing people to ask questions in a way that they need not worry that their competitive advantage in IP is not thrown out of the window. Perhaps giving them the opportunity to ask up to five questions that will receive confidential answers may help out a bit.

  • Be prepared for detailed discovery. RFP responses only go so far, and they’re only as good as the questions asked and the respondent’s understanding of your organization. They can’t possibly be perfect, and in many instances should not be considered to be binding obligations. At best you’ll have a good feel that their technology will fit and that the chosen organization will walk down the road with you and deliver what you need. Let the chosen respondent do a detailed discovery after they are chosen, in order that they can provide more specifics with a more detailed budget. That way there will be no surprises half way through the project and you’re more likely to succeed.

  • Do a proof-of-concept if you’re battling to choose. Don’t be afraid to request your short-list of companies to do a proof-of-concept (PoC) in your environment. Often the companies that are most likely to deliver will be baying for the opportunity. In doing so you will gain more confidence in choosing the correct supplier. Of course there is a caveat. You will need to plan and budget appropriately for your RFP. There are ‘hidden’ costs to an RFP you may not be thinking about. If a PoC is to be run in your environment you will probably need to have space to do so, connectivity, power and systems in places that can represent your environment to the degree that you can be confident the PoC is not a smoke and mirrors demonstration. If you’re going to do it, do it properly.

  • Price is important, but… don’t expect a Bugatti Veyron for the price of a Volkswagen Golf. Furthermore, don’t expect a Golf to function like a Veyron! Price is always important, but be very conscious of marrying your executives requirements and perceptions with the solution you have chosen. If you promised them the world a few years ago, and then issued an RFP just before your delivery deadline it is highly unlikely you will have the budget or time you had then to deliver the Veyron you’re still selling them now. The best result at the best price only comes from proper planning and a distinct lack of procrastination. You might believe you can put pressure on suppliers, but is unlikely what you get will ever fit one hundred percent.

Natasha is a Pre-Sales Architect for Infrastructure and Business Productivity applications and systems. She has worked at a major software vendor for more than 10 years, in a number of consulting and delivery management positions, including Service Line Architect for a period of 4 years. She has more than 18 years of experience working with her customers to design and implement solutions in these areas and is primarily focussed on security, virtualization, messaging and management architectures. She is a Microsoft Certified Architect: Infrastructure, and was one of the first Microsoft Certified System Engineers in the world.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Monday, August 18th, 2008 and is filed under Requirements Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories