Highlighting some of the less advisable approaches we've come across when selecting data-driven marketing technology and running a request for proposal, our white paper, Worst practices in RFP management, discusses some key issues and resolutions.

1. Worst practices in
Request for Proposal management
How to ensure trouble-‐free business solution procurement
Simon Daniels Geoff Downer

2. 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 Solutions
Suite 27
61 Praed Street
London
W2 1NS
United Kingdom
percassity.com solutions@percassity.com
+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.

3. Worst practices in Request for
Proposal management
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
About the authors their absence, it’s easy to make mistakes when it comes to
compiling and issuing a request for proposal that will compromise
Simon Daniels is the outcome in terms of the solution chosen and its ultimate
Director, Marketing
implementation.
Operations
Consulting at
As such, we wanted to share some thoughts based on our
Percassity
experience of issues that arise in undertaking a request for
Marketing Data
proposal. The second in our Worst Practices series (see Worst
Solutions.
practices in Marketing Operations), we take a slightly ironic look
Simon’s experience spans a number at some of the poorer approaches we see, once again with the
of business-to-business sectors, intention of assisting organisations to learn from the mistakes of
working across Europe, North America others.
and Asia Pacific and he has been
responsible for data strategy How many do you recognise from RFPs you’ve been involved in?
development and implementation at a
number of respected organisations.
Percassity Worst Practice No. 1: Impose very
Associate and
independent tight timelines for discovery,
consultant Geoff documentation and response
Downer is a
senior level Once the decision has been made to undertake a request for
data-driven proposal, everyone is keen to proceed as quickly as possible. We
relationship marketing solutions encounter projects that have been years awaiting the right
specialist. He has more than 25 years sponsorship, at which point pent-up eagerness to proceed is
experience in all aspects of data- unleashed in a flurry of frantic activity. This can result in
driven marketing and marketing compressed and unrealistic timescales to complete the process
automation, across a variety of sectors of scoping, discovery, supplier identification and proposal
in both B2C and B2B. 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.
solutions@percassity.com Page 3 percassity.com

4. 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 Requirements gathering
needs is compiled, covering every The process of collecting Survey/questionnaire Should a
possible eventuality and scenario requirements for inclusion in a large number of individuals need
and pointing to an unrealistic or request for proposal can take to be consulted, a survey or
simply unaffordable solution. many forms. Adopting a range of questionnaire is a good approach.
techniques usually makes sense - Online survey tools can be used
Requirements should be subjected here is a selection: and commonality of requirements
to an initial feasibility filter to ensure quickly established. Care should
the more egregious instances of Interviews Straightforward one- be taken not to “lead”
on-one discussion, examining respondents and allowance made
“just in case” needs are excluded at current activities and processes for less qualitative feedback.
an early stage. Once a robust set of together with future requirements.
requirements has been determined, Prototype Where a brand new
a further priority should be applied Focus groups Similar to an solution is being proposed, there
to help solution providers interview but involving 2-4 may be no frame of reference for
understand how critical each one is. participants and drawing out new requirements. Creating a
This can be expressed in the form multiple viewpoints. Care has to prototype to show to users and
of must/should/could or a numerical be taken though to ensure that obtain feedback and suggestions
those involved have common can help. In a sense a form of
rating, together with the option to
requirements, otherwise the rapid application development,
provide commentary. This way session can turn into several iterations quickly arrive at a final
providers can indicate their ability to individual interviews. solution that solves the business
meet, partially meet or not meet problem.
requirements, creating a more Brainstorming/workshops
nuanced view than a simple yes/no. Involving larger groups, Suggestions and support logs
workshops can kick-start the User feedback regarding an
Potential solutions will have process, especially in a “green existing system may already be
strengths and weaknesses in field” situation. Participants are collected and these suggestions
encouraged to pitch ideas, in turn can form the basis for future
different areas and the rejection of
triggering further suggestions requirements. Similarly, support
a candidate unable to strictly meet from others. Ideas can be requests and problem reports
a given specification might rule out prioritised and worked-up for may also indicate areas for
an otherwise promising option. further assessment subsequently. development or implementation.
Good responses to the request for
proposal will suggest alternative Observation and review Where Use cases Sometimes, the
approaches to solving business an existing system is being easiest way to explain new
issues represented in the replaced, as-is requirements can requirements is by illustrating how
requirements that might not have be uncovered by examining how it a system will be used. Such use
is being used and reviewing cases, essentially stories
been initially considered. Overly
documentation. Care should be describing specific scenarios,
prescriptive requirements risk the provide a user-centric view that
taken though to ensure that future
submission of responses that lack requirements are not omitted – can be converted into
innovation or lateral thinking. see Worst Practice No. 3! requirements.
solutions@percassity.com Page 4 percassity.com

5. Worst practices in Request for Proposal management Percassity Marketing Data Solutions
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.
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
“Once selected, a influencers in all of the areas likely to have a short/medium term future need,
solution is likely to often referred to as “to-be” requirements.
have a life of three
years or more, so must An underlying consideration when developing the to-be scenario is to ensure a
thorough awareness of the different capabilities of the candidate solutions.
support the needs of Solution providers will of course present their view, but will – not unreasonably
the organisation as – emphasise the benefits of their particular solution. Review business
they develop” 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.
solutions@percassity.com Page 5 percassity.com

6. Worst practices in Request for Proposal management Percassity Marketing Data Solutions
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. “Solution providers
may be unwilling to
Where justification is provided, it may be necessary to unravel objective undertake such a
models from the sales pitch aspects of a response, focusing on the key detailed level of
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
response while still on
list”. They may have to judge whether it is worthwhile responding, or if the the long list”
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 “Should the solution
positions in the solution provider landscape in terms of scale, capabilities and provider list start
delivery model, there will be seemingly compelling reasons to include each becoming too long,
one in the final list. Combined with companies favoured by the various
stakeholders involved in the decision or that are currently in vogue with look again at how
relevant industry analysts, the list can become long and unwieldy. closely each one meets
the selection criteria”
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
solutions@percassity.com Page 6 percassity.com

7. Worst practices in Request for Proposal management Percassity Marketing Data Solutions
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!
solutions@percassity.com Page 7 percassity.com

8. percassity.com