The RFP has been Procurement's approach to managing complex sourcing for many years, providing comfort that a rigorous and objective process has been run to select a supplier.
Many months of effort on all sides go into writing lengthy sets of requirements, asking and answering questions, crafting beautiful documentation and scoring.
We talk about 'what' we want suppliers to do and 'how' we want them to do it, judging them on how close they come to our singular view of the world.
We rarely provide more than a paragraph of 'why' we need this or what we want to achieve.
But is an RFP the most effective way of choosing the right supplier for the job?
No matter how thorough and well-run a process is, it's still exam questions, written in isolation, on how to solve a problem at a point in time. Rarely do things stop changing for six months so we can run an RFP.
Unfortunately, in this ever changing and complex world, a traditional RFP no longer cuts the mustard. Often the question has changed before we can get to the answer.
The RFP does have some benefits. For me, its the following:
How can we run an exercise that retains and improves on these benefits?
Agile has been popular in IT for many years, as an iterative and collaborative approach to developing software and is now truely mainstream.
Taking the best parts of the tender process and sprinkling some agile magic on it makes sure that we are quickly getting to the right answer.
So what are the stages of an Agile Sourcing project?
In this stage we're forming the team and building the approach - depending on scale this could take a few days or a couple of weeks.
We plan out the stages - or sprints - of our project, agreeing and blocking out the amount of time required from the team. As the process is condensed, the time requirement may seem like more than a usual RFP. Get those who will be responsible for day-to-day management involved as well as senior stakeholders.
An important document for the first stage is the briefing document we send out - this contains our objectives, more on the situation and scope of the exercise, and how the process will run, including principles (or rules). It should be pretty high level in nature - no detailed lists of requirements or jargon.
Next, we must do our research to pick participants, agree the budget and set up the tools we will use. Ask your IT team what they use for agile projects - tools like Miro, Notion, Google Workspace are all great for collaboration and recording the outputs of the interactions.
Arrange briefing sessions with the chosen participants - get someone senior to bring the objective and strategy to life, and someone who understands the day-to-day to talk through the current situation and challenges. Send out the briefing document following the session.
Very quickly we move to hearing how the participants would meet the objective - at a high level. Preplanned workshops should explore this in more detail, providing feedback and iterating on the approach. This should challenge your thinking as much as providing direction to the participant.
Depending on what you are buying, workshops can be with all participants in the room together or separately. Regardless, an approach to share learnings quickly across all participants needs to be put in place. The more you share, the quicker you get to the answer.
You may request options and a rough order of magnitude costing (ROM) to help position the workshops to your budget.
In parallel you can run through supplier due diligence - ideally in the room so any questions that come up can be quickly answered. A legal session to review contracting principles and discover any red-lines early on is also helpful as part of the workshop.
Score the participants - if you feel comfortable, do it with them in the room! This gives immediate and frank feedback on their performance and approach. At this stage, a participant may drop out or be removed from the process. If they are not contributing learning or likely to win it is better to focus effort in the right places.
Review how the sprint went and planning the next sprint are the final steps - get all the stage 3 workshops in the diary. Consider if there are opportunities to accelerate the process now.
Giving participants enough time to pull together a more detailed approach to meeting your objective, another workshop is held to go through the detail.
In this session it is great to get real user feedback on something tangible. A prototype or short proof of concept brings the approach to life.
Continue providing feedback and iterating on the approach.
Pull together the information you have gathered to date, consider key risks and mitigations.
As we know more we can now properly define the success criteria (Definition of Done in agile speak) allowing work to commence on the contract and SOW.
Refine pricing and negotiate collaboratively - how can we make this a win/win? Set the relationship up for success - there's no cost savings in a failed project.
Pick the best placed participant to meet your objective. Consider approach to process, learnings contributed, relationship, innovation etc. as key criteria.
Review how the sprint went and plan the next sprint. Consider if there are opportunities to accelerate the process.
Use this last sprint to finalise and execute contracts.
But remember, this isn't the end of the process - it's the beginning of a new relationship.
Your new supplier should hit the ground running, and a kick-off workshop should be incorporated into this sprint with all the internal team included.
Procurement should not throw the contract over the fence, and involvement in the kick-off makes sure we bring the exercise to a close in the right fashion.
We can also use a joint session to review feedback on the process - again, this can be in the presence of the supplier to gather useful learnings.
Review and revise the approach ready for the next time!
Depending on complexity, an Agile Sourcing programme can be run in 4-8 weeks. If an outcome is worth delivering, it's got to be worth delivering sooner than 6-9 months!
For complex projects, collaboration is key. We learn most when we learn together.
Clearly for requirements of a commodity nature, a detailed RFQ may be still the best approach.
Still not sure? As with anything agile, experimenting, learning and iterating are vital?
What have you got to lose?
