We’ve all been there – the huge RFP document, that’s been around the business to several authors, finally being sent out to the chosen suppliers, to then land on the sales persons’ desk with a thump.

Over the course of this year we’ve asked a number of suppliers and customers what their view of the RFP is:

Suppliers view

•      It’s a major effort to prepare a bid response

•      Can be a ‘tick box’ exercise

•      May choose to no-bid as a result

•      Much boilerplate content often requested

Customers view

•      Seen as bureaucratic, red tape, takes too long

•      Is all the effort worth it?

•      Run by the Procurement Department or “because we have to”

•      Many authors encourages evermore questions and requirements = Frankenstein’s monster

•      Best part is seeing vendor’s offerings at the presentations stage

Do all these problems encourage businesses to avoid doing an RFP, and try something else instead?

Here we present what some of those are in practice.

Bad Sourcing – ways not to choose your technology suppliers

It’s quite common / human nature for these to happen (especially the first one)– and there are consequences:

No alt text provided for this image

So if in the past, an RFP has been the favoured way to make an objective selection, Agile sourcing offers an alternative method and avoids all the issues listed above.

What is Agile sourcing?

It’s based around your 10 -15 key business scenarios for what the system / service must do (outcome based), which suppliers then present against in live demonstrations. Each scenario is a carefully formatted one pager document.

No alt text provided for this image

You gain earlier sight of market offerings and see what’s possible.

The process is faster, and shortlists primarily on functional fit, avoiding the overhead of you having to score a large number of huge bid response documents, or generate an RFP document in the first place.

Agile Sourcing vs RFP pro’s and cons


+ Faster start, authoring scenarios is more straightforward for business staff who may be less used to formal requirement documentation

+ Keeps the focus on the key needs, not a 60+ page RFP of every possible requirement

+ Gets you infront of suppliers more quickly, to see what they can do and the art of the possible

+ Live demo’s against your scenarios are more engaging for the team than reading and scoring large bid response documents from vendors

+ Adds momentum – easier to engage your business and IT in writing 1 pagers

+ Vendors prefer it = more bids / fewer no-bids

+ Phase 2 diligence is then focused on the shortlist only – earlier focus on the stronger bidders


– Diary pressure: The scoring team should be consistent, and there for all presentations

– Shortlisting is based on functional performance first, then the technical and commercial in phase 2, need to consider if this could be an issue

– Phase 1 vendor presentations may reveal some aspects of the technical or commercial, care required on if / how these are interpreted by the team, before this is done fully in phase 2

– Rough order of Magnitude (RoM) costs only are presented, rather than a binding and full final cost

What situations suit Agile sourcing?

If you need to select new software, a managed service provider MSP, an SI systems integration partner, or telecoms such as WAN/SD-WAN.

There is a good discipline to only writing your key requirements, into ‘day in the life of a user’ style business scenarios.

(Bear in mind that in phase 2, once you’ve shortlisted, there will be a second round of business requirements, and your technical and commercial requirements.)

We can’t think of too many technology selection where this wouldn’t work.

There are some important principles in how to write the scenarios, including some ways to avoid.

Agile can be incorporated into public procurement and remain compliant.

Where regulatory compliance is key for vendors, this is included early in the process, either at the bidder pre-qual stage, or factored into a scenario.


Here we air some of the questions that commonly come up when considering a switch to agile sourcing:

1.      “What if in phase 2 there’s a technical showstopper that eliminates all the bidders shortlisted on functionality?”

You’ve got to think of the likelihood of this happening, and if high enough, to include any technical must haves in the original bidder pre-qual. (And there’s an art to running pre-qual efficiently, such that it doesn’t turn into a mini RFP process in itself).

2.      “What if the end costs are wildly different to the RoM costs stated in phase 1?”

On bidder costs, you get final costs in phase 2 of the process, after you’ve iterated through and refined what you actually want. At this point costs will be more credible, as we often see RFP bid prices that change drastically from bid to end contract.

3.      “If we miss a key requirement, that could shift the selection decision”

On missing / amending requirements, this is easier to do in the agile approach, as in practice you’re asking vendors just to re-present, rather than re-work an entire RFP response document.

4.      “We’ve heard of some agile sourcing processes where all the bidders contracts are negotiated in parallel in phase1”

Turnstone have a more pragmatic approach to mitigating the risk of unfavourable contractual terms. Our approach avoids the overhead of running parallel / duplicate contract negotiations with multiple bidders, when only one of them will be the winner.


Regarding RFP’s, organisations that are good at them, and regularly and successfully go to market via this route may feel less need to explore the agile alternative.

Regarding agile sourcing, it is gaining traction, as alternative to a full formal RFP, crucially making it easier for most buying organisations to go to market in an objective manner. If this stops even one business falling into the trap of watching vendors presenting to their agenda, then this is a win.

The gamechanger is the faster and easier start, visibility of the market, with full detail / diligence at the back end, focused on fewer bidders.

Care is required with the approach though– in particular it’s easy to get in a muddle around proper scenarios and wording, due to much confusing web based content on agile software development, use cases, epics, themes and more.

Bidders are warming to the process too, getting infront of the client sooner and spending more time in dialogue rather than authoring documents.

We’ve covered the basics in this article, but clearly there’s more to the approach than we can document, so do get in touch if this may be of interest in your organisation.

Telephone: 0207 788 4745

email at