No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Is the RFP Process a Waste of Time?

portableA recent article by Kevin Kieller took a look at problems that can emerge with an RFP (Request for Proposal) that is not well thought out in advance. He advises that before issuing an RFP, organizations should make some key decisions and have specific requirements agreed upon.

This is excellent advice.

The question is, how can an organization make all of these decisions in advance unless they know what options are available to them? Many of my clients are organizations with a slim staff that is focused on day-to-day operations, making it difficult to find the time for education on all available options. And very few have experience in the art of describing specific requirements in an RFP format.

Without outside expertise such as that provided by consultants, many organizations create RFPs full of "requirements" that sound useful but are impossible to quantify, such as "mobile integration." This results in proposals for systems that are "capable" of "mobile integration," but who knows what capabilities are actually included in the system as proposed?

Given these constraints, are there any benefits to the RFP process?

I would argue that RFPs are effective when they are done correctly.

There is a process that generally occurs as companies make the journey to new communications technology:

  1. Awareness of need to change
  2. Investigation of available options
  3. Determination of strategic direction
  4. Agreement on specific requirements and evaluation criteria (also known as Needs Analysis)
  5. Creation of RFP
  6. Proposal evaluation and demonstrations
  7. Solution selection

Problems occur when the RFP is created too early in the process. Many companies use an RFP to perform step 2 -- Investigation of available options. This can result in a lot of extra work for everyone involved and is often the reason that RFPs are perceived by some as a waste of time.

Without a strategic direction (step 3) and a thorough needs analysis (step 4), an RFP cannot reflect an organization's requirements. Here are 5 tips for conducting an effective needs analysis that uncovers the information necessary to make the RFP process worthwhile:

  1. Talk to both the technical team and business users. They have different perspectives on what capabilities a new system should provide and both sides have valuable insights. Industry watchers are predicting that marketing and other line-of-business units will increasingly become larger purchasers of technology.
  2. Take time to understand current frustrations. Often it is easier for people to tell you what obstacles they face than for them to describe new capabilities they need.
  3. Learn about how key departments work. This will allow you to determine whether new capabilities would be valuable to them. Alternately, it will allow you to describe the problem and ask respondents to the RFP to craft a solution, if appropriate.
  4. Evaluate the capabilities of the IT team that will be supporting the new technology in terms of technical expertise and availability. A highly skilled and capable team will be able to support more complex solutions, if they have the time available to do so. A less sophisticated team may mean that you should include requirements for additional support and diagnostic tools, or consider a hosted or managed services solution.
  5. Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

"SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

  • Awareness of need to change
  • Investigation of available options
  • Determination of strategic direction
  • Agreement on specific requirements and evaluation criteria (also known as Needs Analysis)
  • Creation of RFP
  • Proposal evaluation and demonstrations
  • Solution selection

    Problems occur when the RFP is created too early in the process. Many companies use an RFP to perform step 2 -- Investigation of available options. This can result in a lot of extra work for everyone involved and is often the reason that RFPs are perceived by some as a waste of time.

    Without a strategic direction (step 3) and a thorough needs analysis (step 4), an RFP cannot reflect an organization's requirements. Here are 5 tips for conducting an effective needs analysis that uncovers the information necessary to make the RFP process worthwhile:

    1. Talk to both the technical team and business users. They have different perspectives on what capabilities a new system should provide and both sides have valuable insights. Industry watchers are predicting that marketing and other line-of-business units will increasingly become larger purchasers of technology.
    2. Take time to understand current frustrations. Often it is easier for people to tell you what obstacles they face than for them to describe new capabilities they need.
    3. Learn about how key departments work. This will allow you to determine whether new capabilities would be valuable to them. Alternately, it will allow you to describe the problem and ask respondents to the RFP to craft a solution, if appropriate.
    4. Evaluate the capabilities of the IT team that will be supporting the new technology in terms of technical expertise and availability. A highly skilled and capable team will be able to support more complex solutions, if they have the time available to do so. A less sophisticated team may mean that you should include requirements for additional support and diagnostic tools, or consider a hosted or managed services solution.
    5. Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

    Problems occur when the RFP is created too early in the process. Many companies use an RFP to perform step 2 -- Investigation of available options. This can result in a lot of extra work for everyone involved and is often the reason that RFPs are perceived by some as a waste of time.

    Without a strategic direction (step 3) and a thorough needs analysis (step 4), an RFP cannot reflect an organization's requirements. Here are 5 tips for conducting an effective needs analysis that uncovers the information necessary to make the RFP process worthwhile:

    1. Talk to both the technical team and business users. They have different perspectives on what capabilities a new system should provide and both sides have valuable insights. Industry watchers are predicting that marketing and other line-of-business units will increasingly become larger purchasers of technology.
    2. Take time to understand current frustrations. Often it is easier for people to tell you what obstacles they face than for them to describe new capabilities they need.
    3. Learn about how key departments work. This will allow you to determine whether new capabilities would be valuable to them. Alternately, it will allow you to describe the problem and ask respondents to the RFP to craft a solution, if appropriate.
    4. Evaluate the capabilities of the IT team that will be supporting the new technology in terms of technical expertise and availability. A highly skilled and capable team will be able to support more complex solutions, if they have the time available to do so. A less sophisticated team may mean that you should include requirements for additional support and diagnostic tools, or consider a hosted or managed services solution.
    5. Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

  • Talk to both the technical team and business users. They have different perspectives on what capabilities a new system should provide and both sides have valuable insights. Industry watchers are predicting that marketing and other line-of-business units will increasingly become larger purchasers of technology.
  • Take time to understand current frustrations. Often it is easier for people to tell you what obstacles they face than for them to describe new capabilities they need.
  • Learn about how key departments work. This will allow you to determine whether new capabilities would be valuable to them. Alternately, it will allow you to describe the problem and ask respondents to the RFP to craft a solution, if appropriate.
  • Evaluate the capabilities of the IT team that will be supporting the new technology in terms of technical expertise and availability. A highly skilled and capable team will be able to support more complex solutions, if they have the time available to do so. A less sophisticated team may mean that you should include requirements for additional support and diagnostic tools, or consider a hosted or managed services solution.
  • Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

  • Take time to understand current frustrations. Often it is easier for people to tell you what obstacles they face than for them to describe new capabilities they need.
  • Learn about how key departments work. This will allow you to determine whether new capabilities would be valuable to them. Alternately, it will allow you to describe the problem and ask respondents to the RFP to craft a solution, if appropriate.
  • Evaluate the capabilities of the IT team that will be supporting the new technology in terms of technical expertise and availability. A highly skilled and capable team will be able to support more complex solutions, if they have the time available to do so. A less sophisticated team may mean that you should include requirements for additional support and diagnostic tools, or consider a hosted or managed services solution.
  • Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

  • Learn about how key departments work. This will allow you to determine whether new capabilities would be valuable to them. Alternately, it will allow you to describe the problem and ask respondents to the RFP to craft a solution, if appropriate.
  • Evaluate the capabilities of the IT team that will be supporting the new technology in terms of technical expertise and availability. A highly skilled and capable team will be able to support more complex solutions, if they have the time available to do so. A less sophisticated team may mean that you should include requirements for additional support and diagnostic tools, or consider a hosted or managed services solution.
  • Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

  • Evaluate the capabilities of the IT team that will be supporting the new technology in terms of technical expertise and availability. A highly skilled and capable team will be able to support more complex solutions, if they have the time available to do so. A less sophisticated team may mean that you should include requirements for additional support and diagnostic tools, or consider a hosted or managed services solution.
  • Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

  • Evaluate the data network that will support the new solution if your current technology is not VOIP. Upgrades to the infrastructure can result in unanticipated costs and add additional time to the implementation.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.

    Once the needs are identified, it is imperative that they are conveyed precisely. Rather than using generic terms such as "mobile integration" it is better to describe exactly what you are looking for. A paragraph that describes the specific performance expected will help everyone involved to better understand the requirements. For example, should a mobile phone ring at the same time as a desk phone? If a call is not answered, what voice mail system (corporate or mobile) should the caller go to? What caller ID should be displayed? Should the mobile phone be able to display presence information for other users? Is IM required? By describing your needs at this level of detail, it will be much easier to evaluate whether the proposed systems will meet your requirements.

    If you aren't sure if a requirement is specific enough, ask yourself this question: Could an uninvolved third party see the system operate and confirm that the requirement was met?

    The RFP process itself is not a flawed concept. There are many examples of poor RFPs that have resulted in poor results, but that's just a reflection of the "Garbage In, Garbage Out" concept. A well-executed RFP is a valuable tool to assist organizations in finding the solution that is best for them.

    "SCTC Perspectives" is written by members of the Society of Communications Technology Consultants, an international organization of independent information and communication technology professionals serving clients in all business sectors and government worldwide.