Request for Proposal (RFP) binnen productontwikkeling

Als product owner of leidinggevende van product owners heb je vast en zeker van de term Request for Proposal (RFP) gehoord. Het is onderdeel van inkooptrajecten en wordt in de IT vaak gebruikt als een uitnodiging aan leveranciers om offertes in te dienen voor een nieuwe digitale tool (of onderdeel daarvan), zoals een website, app, portal, integratie of andere software oplossing. Vooral in de ICT-sector is een RFP een veelgebruikte manier van het selecteren van de partijen waarmee je gaat samenwerken. De ontwikkeling van IT-producten vraagt namelijk vaker dan gemiddeld om flexibiliteit, specifieke eisen en maatwerkoplossingen. Tegelijkertijd zit het vol van de afhankelijkheden en vakjargon, waardoor je van zeer goede huize moet komen om bij al die offertes appels met appels te gaan vergelijken.

In deze blog gaan we in op wat een RFP is, hoe het zich verhoudt tot een Request for Information (RFI) en Request for Quotation (RFQ), uit welke onderdelen een RFP doorgaans bestaat, hoe je een effectieve RFP opstelt en hoe je leveranciers begeleidt en beoordeelt in dit proces. Natuurlijk bespreken we de belangrijke rol van de product owner binnen dit proces, waarom deze een sleutelpositie inneemt en hoe hij of zij bijdraagt aan het succes van een RFP-traject.

Een Request for Proposal (RFP) is een formele uitnodiging die bedrijven uitsturen naar externe leveranciers om offertes te ontvangen voor een specifiek project of dienst. Een RFP stelt je als organisatie in staat om een weloverwogen keuze te maken welke leverancier het beste past bij de behoeften van jou, je team, je organisatie en je gebruikers. De RFP bevat het liefst zo gedetailleerd mogelijke eisen en specificaties, zodat leveranciers kunnen uitleggen hoe zij het project zouden aanpakken en wat de kosten en voorwaarden zijn.

Een voorbeeld is wanneer een product owner werkt bij een e-commerce bedrijf dat een nieuw betalingssysteem wil integreren. De product owner stelt in overleg met zijn/haar omgeving een RFP op waarin requirements worden beschreven zoals integratie met bestaande systemen, ondersteuning voor meerdere valuta’s en een naadloze gebruikerservaring. Softwareleveranciers dienen vervolgens voorstellen in met hun oplossingen en kostenramingen, wat vervolgens de product owner en zijn/haar stakeholders helpt de beste keuze te maken tussen de verschillende leveranciers.

RFI (Request for Information) wordt in een vroeg stadium gebruikt om informatie van leveranciers in te winnen over mogelijke oplossingen. Het helpt om de opties te verkennen voordat je concrete stappen neemt richting de selectie van een leverancier of oplossing. Het helpt je – plat gezegd – om betere vragen te gaan stellen in een RFP.

RFP (Request for Proposal) is een formeel verzoek aan leveranciers om een gedetailleerd voorstel in te dienen voor een project. Dit voorstel bevat de aanpak, kosten en voorwaarden. Een RFP wordt gebruikt wanneer de eisen helder zijn, maar je nog verschillende leveranciers wilt vergelijken op basis van hun aanpak en aanbod.

RFQ (Request for Quotation) richt zich specifiek op prijs. Wanneer de oplossing en specificaties al vastliggen, kun je met een RFQ de leveranciers vergelijken puur op basis van de kosten die zij bieden. In ICT trajecten is dit wat minder voorkomend, omdat er vaak veel verschillende oplossingen te bedenken zijn voor één probleem of uitvraag.

Deze drie verzoeken worden vaak in volgorde gebruikt: een RFI om informatie te verzamelen, een RFP om de beste leverancier te selecteren, en een RFQ om prijzen te vergelijken zodra de oplossing is bepaald.

Er is geen vaste methode voor het opstellen van een RFP binnen de productontwikkeling. Toch zien wij in de hoofdlijnen enkele belangrijke elementen die we aanraden altijd mee te nemen binnen het RFP om succes te garanderen

Een algemene beschrijving van jouw organisatie, het product of project, de gebruikers, het probleem en eventuele andere relevante context. Welk probleem wil je waarom oplossen voor wie?

Een overzicht van de technische specificaties (zoals software, hardware, en integraties) en functionele vereisten (zoals wat het moet kunnen doen). Dit helpt leveranciers om te begrijpen wat er van de oplossing wordt verwacht. Een prioritering van die specificaties en vereisten toont aan dat je er goed over na hebt gedacht en leveranciers zullen hierdoor beter kunnen bepalen waar ze de nadruk leggen in hun beantwoording van jouw RFP.

Dit deel beschrijft de afbakening van de werkzaamheden die uitgevoerd moeten worden, inclusief belangrijke mijlpalen, deadlines en de verantwoordelijkheden van alle partijen. Hiermee wordt duidelijk wat er binnen en buiten de projectgrenzen valt. Scope is – zo weten we uit ervaring – vaak een heikel discussiepunt richting de opleveringsdatum van een project. We raden aan om hier zo compleet mogelijk te zijn, zodat jij en je toekomstige partner niet voor verrassingen komen te staan.

Een indicatie van het beschikbare budget voor en de verwachte tijdslijnen. Dit kan gaan over deadlines voor de verschillende product- of projectfases, evenals de verwachte go-live datum. Vergeet niet om lange termijn kosten zoals onderhoud en hosting uit te vragen.

Duidelijke richtlijnen over hoe en wanneer de voorstellen moeten worden ingediend, inclusief deadlines, gewenste documentatie, en contactpersonen voor vragen. Ook is het wel zo netjes om te laten weten wat je er precies mee gaat doen na het inleveren en wanneer je verwacht iets terug te gaan koppelen.

De criteria waarop de ontvangen voorstellen worden beoordeeld. Dit kan variëren van prijs en kwaliteit tot ervaring, overdraagbaarheid en referenties. Het maakt duidelijk wat zwaar weegt in de beslissing.

Extra tips:

• Het draait om het vinden van de juiste balans. Je wil aanbieders voldoende informatie geven, maar niet te veel. Te weinig informatie kan leiden tot de verkeerde keuze en verspilde tijd, terwijl te veel details juist voor verwarring kunnen zorgen. Door goede en duidelijke eisen te stellen zorg je ervoor dat de voorstellen die je gaat ontvangen onderling te vergelijken zijn voor jou als product owner.
• De personen waarmee je in het voortraject spreekt gaan waarschijnlijk niet het ontwikkel- en testwerk doen. Daarom is het goed om te bedenken of het OK is dat de voertaal van het project Engels wordt. Immers, ruim ⅓ van alle bedrijven werken tegenwoordige met niet-Nederlandse software ontwikkelaars.
• Als je bij een (semi) overheidsorganisatie werkt, dan gelden er wetten en regels voor het uitschrijven van een RFP. Zo is er bijvoorbeeld een drempelbedrag van iets boven de €200.000, waarna je moet gaan Europees aanbesteden. Je volgt dan dezelfde stappen, maar het proces wordt formeler en intensiever. Twijfel je of je moet voldoen aan de Europese aanbestedingsrichtlijnen? Neem dan contact op met je eigen inkoopafdeling of met ons.

Het opstellen van een Request for Proposal (RFP) is geen eenmanswerk; we willen dat echt ten sterkste afraden. Het vereist namelijk input van het team en de stakeholders en het moet daarnaast op de juiste manier afgestemd worden met de omgeving. Diversiteit in de groep mensen die je hierbij betrekt is een grote pré. Te veel mensen maakt het echter weer omslachtig. Bij twijfel; mik op maximaal 5 mensen die naast een mening ook echt een stem hebben in wat er in de RFP zal komen te staan. Toch is het belangrijk dat één persoon de eindverantwoordelijkheid draagt om het proces te stroomlijnen. Deze rol wordt vaak vervuld door een product owner of projectmanager.

De product owner als eindverantwoordelijke is hierbij een verstandige keuze. Een product owner is namelijk al bekwaam in de bruggen slaan tussen de requirements en de strategische doelen. En als het goed is, is stakeholder management ook geen vreemd gebied voor de product owner. Een goede product owner kan ownership nemen over dit traject, waardoor jij je kan focussen op andere belangrijke zaken.

Wil je meer weten over de mogelijkheden van een interim product owner? Lees hier meer hoe een product owner kan helpen bij jouw RFP-proces. en mocht je andere vragen hebben, neem dan gewoon even contact met ons op