Worst practices in RFP management

Worst practices in Request for Proposal management

How to ensure trouble-‐free business solution procurement

Simon Daniels Geoff Downer

Percassity Marketing Data Solutions is a marketing data strategy and marketing operations consultancy. Adopting advisory and implementation roles, Percassity works with clients to identify, assess and implement data-‐driven marketing technology solutions that meet their specific needs. As an independent consultancy, Percassity is in a position to make completely objective recommendations regarding the best and most appropriate solution to clients’ requirements.

Find more request for proposal information and resources at percassity.com/rfp

Percassity Marketing Data SolutionsSuite 2761 Praed StreetLondonW2 1NSUnited Kingdom

percassity.com [email protected]+44 (0) 20 7193 7682 +1 917 720 3582

© 2012 Percassity Marketing Data Solutions Ltd.

This document may be distributed, in this format and with this message only.

Worst practices in Request for

Proposal management

[email protected] Page 3 percassity.com

Simon Daniels and Geoff Downer | Percassity Marketing Data Solutions

Organisations have been issuing and responding to Requests for Proposals for as long as they have been buying from each other, and the need for astute RFP management has certainly not diminished. Establishing clear objectives, controlling costs, choosing the right solution first time and ensuring a well prepared solution provider are all crucial to the procurement process in the current economic and business environment. At the same time, involvement in substantial purchasing decisions, with price tags running into six or seven figures, is often not a routine undertaking. Even with dedicated procurement support, the specifics of determining requirements, available solutions and organisational fit requires experience

and subject matter expertise that may not be readily available. In their absence, it’s easy to make mistakes when it comes to compiling and issuing a request for proposal that will compromise the outcome in terms of the solution chosen and its ultimate implementation. As such, we wanted to share some thoughts based on our experience of issues that arise in undertaking a request for proposal. The second in our Worst Practices series (see Worst practices in Marketing Operations), we take a slightly ironic look at some of the poorer approaches we see, once again with the intention of assisting organisations to learn from the mistakes of others. How many do you recognise from RFPs you’ve been involved in?

Worst Practice No. 1: Impose very tight timelines for discovery, documentation and response Once the decision has been made to undertake a request for proposal, everyone is keen to proceed as quickly as possible. We encounter projects that have been years awaiting the right sponsorship, at which point pent-up eagerness to proceed is unleashed in a flurry of frantic activity. This can result in compressed and unrealistic timescales to complete the process of scoping, discovery, supplier identification and proposal submission, compromising the final outcome. Regardless of the circumstances, a reasonable schedule should

be adopted for all the steps of the request for proposal. This doesn’t mean proceeding at a languorous pace, but time should be allowed for additional interviews, obtaining clarifications and the inevitable rescheduling of planned sessions. Solution providers too should be allowed time to review the RFP documentation, prepare queries for clarification and compile their response. Foreshortening the time available will only compromise the quality of the final responses or even result in providers declining to bid; this might elicit a shrug of the shoulders and the retort that “it’s their loss”, but it could well be yours if a promising solution provider is not among the final proposals. Having been included in the RFP candidate list, it makes little sense not to obtain a response.

About the authors

Simon Daniels is Director, Marketing Operations Consulting at Percassity Marketing Data Solutions.

Simon’s experience spans a number of business-to-business sectors, working across Europe, North America and Asia Pacific and he has been responsible for data strategy development and implementation at a number of respected organisations. Percassity Associate and independent consultant Geoff Downer is a senior level data-driven relationship marketing solutions specialist. He has more than 25 years experience in all aspects of data-driven marketing and marketing automation, across a variety of sectors in both B2C and B2B.

Worst practices in Request for Proposal management Percassity Marketing Data Solutions


Check points: ! Allow sufficient time for every step of the request for proposal process,

including internal activities as well as solution provider response preparation.

! Build-in time for re-scheduling discovery sessions that might have to be postponed due to interviewee availability and for handling additional queries that arise.

! Remember that the quality of the responses and ultimate selection of the best solution are reliant on allowing sufficient time.

Worst Practice No. 2: Create requirements with no indication of priority Ideally, the scoping and discovery process that determines core requirements for the request for proposal will encompass everyone in the organisation with an interest in the resulting solution. The danger though is that an elongated “wish list” of perceived needs is compiled, covering every possible eventuality and scenario and pointing to an unrealistic or simply unaffordable solution. Requirements should be subjected to an initial feasibility filter to ensure the more egregious instances of “just in case” needs are excluded at an early stage. Once a robust set of requirements has been determined, a further priority should be applied to help solution providers understand how critical each one is. This can be expressed in the form of must/should/could or a numerical rating, together with the option to provide commentary. This way providers can indicate their ability to meet, partially meet or not meet requirements, creating a more nuanced view than a simple yes/no. Potential solutions will have strengths and weaknesses in different areas and the rejection of a candidate unable to strictly meet a given specification might rule out an otherwise promising option. Good responses to the request for proposal will suggest alternative approaches to solving business issues represented in the requirements that might not have been initially considered. Overly prescriptive requirements risk the submission of responses that lack innovation or lateral thinking.

Requirements gathering The process of collecting requirements for inclusion in a request for proposal can take many forms. Adopting a range of techniques usually makes sense - here is a selection: Interviews Straightforward one-on-one discussion, examining current activities and processes together with future requirements. Focus groups Similar to an interview but involving 2-4 participants and drawing out multiple viewpoints. Care has to be taken though to ensure that those involved have common requirements, otherwise the session can turn into several individual interviews. Brainstorming/workshops Involving larger groups, workshops can kick-start the process, especially in a “green field” situation. Participants are encouraged to pitch ideas, in turn triggering further suggestions from others. Ideas can be prioritised and worked-up for further assessment subsequently. Observation and review Where an existing system is being replaced, as-is requirements can be uncovered by examining how it is being used and reviewing documentation. Care should be taken though to ensure that future requirements are not omitted – see Worst Practice No. 3!

Survey/questionnaire Should a large number of individuals need to be consulted, a survey or questionnaire is a good approach. Online survey tools can be used and commonality of requirements quickly established. Care should be taken not to “lead” respondents and allowance made for less qualitative feedback. Prototype Where a brand new solution is being proposed, there may be no frame of reference for new requirements. Creating a prototype to show to users and obtain feedback and suggestions can help. In a sense a form of rapid application development, iterations quickly arrive at a final solution that solves the business problem. Suggestions and support logs User feedback regarding an existing system may already be collected and these suggestions can form the basis for future requirements. Similarly, support requests and problem reports may also indicate areas for development or implementation. Use cases Sometimes, the easiest way to explain new requirements is by illustrating how a system will be used. Such use cases, essentially stories describing specific scenarios, provide a user-centric view that can be converted into requirements.



Worst Practice No. 3: Define requirements solely on current practices Requirements discovery always starts of course with gaining a thorough understanding, and ensuring rigorous capture, of the current business processes and activities that are tried, tested and accepted across the organisation. The chosen technology solution will have to be able to reproduce or support this “as-is” situation unless there is the unlikely opportunity to perform a complete business process re-engineering initiative. Future needs must be kept in mind as well though. Once selected, a solution is likely to have a life of three years or more, so must support the needs of the organisation as they develop over that period. There must be a vision to ensure that the chosen solution will not become redundant simply through being unable to support activities as they evolve over time. Requirements gathering should be sufficiently widely spread to include decision makers and influencers in all of the areas likely to have a short/medium term future need, often referred to as “to-be” requirements. An underlying consideration when developing the to-be scenario is to ensure a thorough awareness of the different capabilities of the candidate solutions. Solution providers will of course present their view, but will – not unreasonably – emphasise the benefits of their particular solution. Review business objectives and solution specifications carefully to help understand the options available and the key characteristics that will best support your business model. Ultimately this will help to develop and extend the to-be model and ensure the greatest value from the chosen solution.

Check points:

! Capture existing or “as-is” requirements that reflect current business processes so that potential solutions can be matched to them, avoiding the need for extensive alteration to existing practices.

! Ensure future or “to-be” requirements are also identified, ensuring the chosen solution will have an acceptable lifespan and grow with the organisation.

! Thoroughly determine the capabilities of potential solutions and consider them against all requirements, maintaining a healthy credulity over solution provider claims.

Check points:

! Guard against creating a requirements set contributed from across the organisation that encompasses every conceivable eventuality. Consulting widely is important to achieving comprehensive requirements that are well supported, but focus on the core business issue must be maintained.

! Prioritise requirements with a suitable mechanism so that solution providers can indicate full or partial compliance. Solutions that don’t meet every requirement often turn out to be strong contenders when the ability to present a novel approach is available.

! Allow and encourage providers to include narrative with their proposals (within tight length limits) so that alternative approaches can be outlined in more detail. These can be followed-up in any presentation that a provider is invited to deliver.

“Once selected, a solution is likely to have a life of three

years or more, so must support the needs of the organisation as

they develop”



Worst Practice No. 4: Expect unrealistically detailed business case input We’ve seen a number of situations where a request for proposal has been issued, quite often lacking in detail itself, with the expectation of a full response including business case and return on investment model. It’s attractive to ask solution providers to undertake additional work in this way, but is invariably counterproductive and won’t result in the desired outcome. Providers are unlikely, especially in an initial response, to have attained sufficient knowledge about organisational specifics to be able to provide any meaningful assessment. Where justification is provided, it may be necessary to unravel objective models from the sales pitch aspects of a response, focusing on the key elements that the solution does well. In addition, solution providers may be unwilling to undertake such a detailed level of response while still on the “long list”. They may have to judge whether it is worthwhile responding, or if the RFP is just “fishing” for free ideas that can then be used elsewhere. It is common to ask shortlisted providers, and certainly the one finally selected, for more detailed information that will help to illustrate a business case, but by this stage in the relationship the process should be much more collaborative. Discussions should be taking place around a table, rather than interviews across a table, at which point they are more likely to value the co-operation.

Check points:

! Avoid setting unreasonable expectations regarding the detail in RFP responses relating to business case and return on investment justification, especially if background detail in the request is lacking.

! Keep in mind that any contribution around return on investment may be coloured by specific strengths of the solution provider itself. Be objective when assessing these aspects of a response and draw from multiple sources wherever possible.

! Work with the solution provider ultimately selected (or at least the final candidate) to obtain any further detail necessary to contribute to the business case, drawing on specifics of their solution.

Worst Practice No. 5: Send the RFP to a long list of solution providers “just to see what they come back with” Inevitably, there will be many different providers of systems and services that could be invited to respond to a request for proposal. Representing different positions in the solution provider landscape in terms of scale, capabilities and delivery model, there will be seemingly compelling reasons to include each one in the final list. Combined with companies favoured by the various stakeholders involved in the decision or that are currently in vogue with relevant industry analysts, the list can become long and unwieldy. Avoid succumbing to temptation though, and ensure that the RFP is issued to as tight a selection of solution providers possible so that the process remains manageable and thorough. Keep in mind that every additional solution provider represents another proposal that will need to be reviewed and scored, as well as managed through the overall process. On the other side of

“Should the solution provider list start becoming too long, look again at how closely each one meets the selection criteria”

“Solution providers may be unwilling to undertake such a detailed level of response while still on the long list”



the equation, responding to an RFP, especially a more complex one, can be a significant investment that providers would rather not make if it’s just for the basis of comparison. Certainly, it’s important to ensure that a suitable cross-section of available providers is invited to submit proposals. We’ve seen successful bidders proposing an unanticipated approach or deployment model that actually turns out to represent the best fit. Equally, as well as alternative solution proposals, a range of responses allows representative pricing options to be obtained that might also turn up unexpected options. Should the solution provider list start becoming too long, look again at how closely each one meets the selection criteria and if there is any overlap between them. A disciplined approach at this point will pay dividends later on.

Check points:

! Restrict the number of solution providers invited to submit proposals as far as possible. Ensure they are chosen on the basis of their ability to meet the selection criteria and avoid adding providers that don’t have realistic prospects of success.

! Ensure though that providers selected do represent a cross-section of possible deployment models and cost levels so that an informed comparison can be made.

! When choosing the final list, consider that every proposal will need to be reviewed and how long it will take to assess a large number of responses.

Conclusion The worst practices discussed here are just a selection of the traps in which it is all too easy to become ensnared in the process of undertaking a request for proposal. The challenges and potential pitfalls though shouldn’t be used as justification for failing to take a rigorous approach or indeed avoiding the need to undertake change altogether. Embarking on an RFP in a considered and methodical way will help to ensure the solution best meeting the needs of the organisation is selected, the provider is well prepared for its implementation, costs are kept under control and that decisions can be justified to stakeholders and boards. As is often the case, a little investment upfront in planning and commitment will lead to rewards later on as the process runs smoothly and on time. Regardless of the size and nature of the organisation, the type of solution being sought and the characteristics of the solution provider, a well-managed RFP could be the difference between success and failure of the entire initiative. A positive outcome for everyone involved is only a few steps away. Good luck!

percassity.com

Documents

Worst practices in RFP management