Give Your RFP a Makeover to Improve Results

RFP, makeover, improve, results.The Request for Proposal (RFP) has long been the key tool for IT leaders to ensure they obtain what they deem necessary to solve a specific technical problem or need.  But this traditional approach is looking rather worn and tired, limiting businesses to potential unseen benefits.

It’s time to makeover your RFP process.

With margin pressures and on-going competitive threats, no organization can afford to continue with just business as usual.  This is especially true when making decisions for high profile or Greenfield projects that are essential to achieving key business objectives. In the past, CIOs focused on IT problems and procuring specific solutions with traditional RFPs ensuring the provider could meet the functionality requirements to solve the problem.  But today’s CIOs have moved beyond their IT focus and are now taking a prominent role in architecting solutions to complex business problems.  This new business orientation demands a new look at how to acquire solutions.

Altering your sourcing approach from the traditional RFP to a Request for Solution (RFS) can help unlock new value, especially for problems that are transformative or ambiguous.  The RFS approach offers a more open ended, flexible approach that can give your organization the competitive advantage it needs to achieve aggressive business objectives.

Why Change?

Sourcing has become more complicated.  Legacy IT environments, mobility, cloud computing, user generated content and application development tools are just a few of the technological advancements creating complexity.  Answers to this complex agenda often come through open ended discussions with innovative third parties.  In fact, some IT teams may not know the right questions to ask.  By using the RFS model, which allows for an “outside-in” view, CIOs can discover options never considered.

Another area to consider for testing this approach is for Greenfield opportunities or areas where you are not locked into specific technology.  By allowing providers a more open ended approach to present their alternatives, options that may not have been considered viable early on can prove feasible.  Take the case from a recent transportation system being built in the Middle East.  By adopting a modified RFS approach, a development branch for the capital city decided to outsource its entire Public Relations and related IT function to jump start a more citizen-oriented program for its train and bus transit system to be built over the next 4-5 years.

There may also be a cost advantage.  An ISG Survey of service providers found that prices were 10 percent higher for responses to complex RFPs.  Through conversations up front during the pre-sales cycle with the RFS, providers bring more cost-efficient, economical solutions to the table.

Characteristics of the RFS

The most significant change in the RFS is the focus on describing rather than dictating.  For many, the RFP has become a checklist of “must-haves.”  If you’ve let this approach take over your RFP agenda, consider the following analogy.  Remember the last time you visited your doctor.  Did you walk in proclaiming you knew the diagnosis before seeing the doctor?  If so, you risked being misdiagnosed.  By allowing the doctor to conduct a proper examination, including testing and consulting with specialists, you can expect better results and feel more confident in your diagnosis and options for your cure.

The same idea applies to sourcing.  By describing your situation, business challenges and other key factors, you shift the dynamics from telling providers what you need to asking the opinion of experts who can bring an “outside-in” view.  This may bring fresh insights to the table and shift the focus during procurement to developing solutions rather than documenting responses.

Additionally, rather than pre-selecting or vetting a few providers, the RFS approach allows for open discussions upfront before solutions are solidified.  Many innovative providers may not have the financial resources to pursue deals through the traditional RFP process but by lowering the cost of entry, they can participate and offer original ideas and approaches.

How to Get Started   

The best place to begin the RFS process is with a discrete project where no clear solution exists or where there is a problem with several viable options, such as a cloud-based solution or outsourcing alternative.

Once you’ve selected the project, follow these steps to solution implementation.

  1. Environmental Description (1-2 weeks). Gather pertinent information on the business landscape including financials, resources, consumption levels, existing SLAs and quality metrics.  There’s no need to rewrite or formalize the information.  Consider organizing information that can assist in describing the specific business problem for which you are seeking solutions.
  2. Develop a Solution Engagement Package rather than RFP (6-8 weeks). Outline specific goals and objectives rather than detailed functionality requirements and invite providers to discuss solutions.  During collaborative solution discussions you should be able to drill down to solution development and select a smaller set of possible providers.  Solution and pricing evaluation are also key functions during this step.
  3. Due Diligence (6-8 weeks).  This step narrows the solution discussion down to 2-3 providers and should produce a concrete transformation plan with detailed pricing.
  4. Contract (5-6 weeks). Based on the due diligence step, you should be ready to select your preferred solution provider and complete contract negotiations.

Today’s business leaders are continually challenged to meet or exceed objectives.  Don’t let traditional sourcing approaches hold you back from a makeover of your RFP process. By applying the RFS model, you can shift your focus from overseeing service delivery to adopting innovative solutions.




Post a Comment

Your email address will not be published.

( required )

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