Given the complexity of creating RFPs, organisations are not always fully equipped to ask the correct questions, and might even lack the required technical knowledge. This talk will demonstrate the importance of considering input from others when setting up your own RFP as this can save time and money – the risks of not identifying all potential pitfalls at RFP stage can be time- consuming and costly a few years later. This talk will apply to all in the industry, from publishers seeking out new platform providers to libraries sourcing vendors for specific projects. Tracy Gardner, Renew Publishing Consultants Yann Amouroux, Bioscientifica

1. Setting up an effective Request For
Proposal (RFP) and the benefit of using
third-party knowledge
UKSG Annual Conference 2018, Glasgow
Yann Amouroux, Bioscientifica
Tracy Gardner, Renew Publishing Consultants

2. Outline of the session
•Introductions
•Hands up if.....
•In their own words – case study from Bioscientifica
•How to go about writing your RFP
•Choosing a consultant
•Q&A

3. Hands up……

4. Setting the scene

5. Questions time

6. Get real

7. Take stock

8. Costs

9. Choices?

10. Help at hand

11. Putting it all together

12. The finished article

13. Our Conclusions

14. “An RFP is a document commonly written
by an organisation seeking bids from
potential vendors. It serves as a base line
of project or system requirements on
which competing vendors may describe
and price their services”.
So what is an RFP?

15. • Vendor responses can be too vague as not enough questions to respond to/information given
• Decisions are made on insufficient information from the vendor
• Contract is signed, implementation starts, questions are raised, e.g. “what did you mean by?”
• Vendor realises that customer expectations are not in line with vendor assumptions
• Project enters are period of negotiation which should have happened before the contract was signed
• Both vendor and customer become frustrated, relationship suffers
• Customer not happy as system doesn’t meet their needs. Vendor not happy because they haven’t
delivered something the customer is happy with
Allofthiscanbeavoided
withadecentRF
E
a
s
i
l
y
A
v
o
i
d
e
d

16. Allows you to be very clear
about your technical and
business requirements
Gives you an opportunity
to communicate the use
cases of the system
Shows potential vendors
what kind of business you
are
Sets the scene for your
ongoing relationship
Helps you compare apples
with apples
Without a detailed RFP too
much is left to chance
How does it help?

17. Your chance to document what you need
We often hear “but we
just need a journals
platform/peer review
system/ERM system, our
requirements are no
different to anyone else”
Of course they are –
every organisation or
business has a unique set
of objectives,
requirements, success
factors, use cases
So your RFP needs be
very specific and detailed
– you will thank yourself
in the long run
And your (successful)
vendors will thank you
too - the more better
your RFP, the less chance
of difficulties further
down the track

18. Our Approach
We help you articulate:
• the “Why”
• the “What”
• the “How”
We then help you evaluate
the responses and select a
suitable a partner by
providing an evaluation
framework and scoring
system

19. The “Why”
Information gathering
• Marketing
• Production
• Editorial
• Senior management
• Sales
We want to know:
• What you are trying to
achieve as a
business/organisation
• What problem is it you are
specifically trying to fix
• What is working now
• What isn’t working now
• What are the key use cases
By removing
departmental
lines we can get
to the core of the
“why”.
Group
information
sharing helps
everyone get on
board with the
process

20. The “What”- otherwise known as the detail
What
specifically
does the
system need
to do
What
production
processes
are in place
and need to
be
supported
What is your
business
model
How about
industry
standards and
requirements
Who are
your
“customers”
and what do
they need
What
information
do you need
to put in
and get out
of the
system
Defining the
Use Cases
will be a
crucial
success
factor

21. The “how”
You want to ask questions which require the
vendors to answer in a detailed and open way.
• Be Specific
• Be Detailed
• Be Open Ended
Ask the vendor for their approach to solving
your difficult problems

22. Suggested structure
Brief Project Overview
Overview of your organization
Primary objectives
Key Deliverables
Key information about the organisation/business
Detailed requirements and use cases
Migration planning (if moving from one system to another)
Relationship expectations: SLA and relationship managements
Evaluation and selection process
Timeline

23. Evaluation
• Ask the vendor to answer the questions in a specific way that allows you to
compare each response point for point
• Have a scoring system so you can score each requirement
• Have a weighting for each of your requirements so the importance to your
business is taking into account. Not all requirements are created equal.
• Be specific about how you want costs to be defined in the proposal
Have a structure
which allows you to
score responses on
a like for like basis.
• We have seen favoured vendors fall at this stage
• Be specific about what you expect them to do at the presentation
stage and have questions prepared
Invite your favoured
vendors in for a
presentation

24. The Project Team
• The project team needs to include a representative from the key stakeholders and
user groups
• It may be you decide to use a third party consultant to help you. We would
recommend you choose someone:
• Who has domain expertise
• Has knowledge of the type of system you are wishing to purchase
• Is good at asking the right questions and unafraid of challenging your assumptions
• Has proven experience

25. Questions?