Een echte goede en objectieve keuze maken in een RFP-traject is nauwelijks te doen. Hoe kan dat beter?
Herkenbaar?
Heb je wel eens een RFP-traject uitgezet? Je had een wens om een digitaal product te laten ontwikkelen en aangezien het fors wat werk met zich meebracht wilde je een uitgebreide selectie van IT leveranciers doen. Om de gewenste kwaliteit te selecteren, maar zeker ook om financieel verantwoorde keuzes te kunnen maken.
Een RFP-traject start je niet onvoorbereid. Om leveranciers duidelijkheid te geven over het te ontwikkelen product is het nodig om veel informatie te verzamelen. Vaak zijn dit de eisen en wensen van de organisatie. Soms ga je wat verder en haal je wensen uit de markt op. En gelukkig besteden enkele organisaties ook aandacht aan de beoogde gebruikers.
Even uitzoomen
Als je met de goede intenties een RFP-traject uit aan het voeren bent, dan heb je nu verzameld wat je door de IT leverancier wilt laten ontwikkelen. Maar niemand weet nog hoe de oplossing eruit moet gaan zien
De aanbiedingen
Je hebt het RFP-proces gevolgd en de vragen liggen bij de IT leveranciers. Gelukkig heb je wat tijd ingeruimd voor aanbiedende partijen om kennis te maken en wat meer individueel in te gaan op vragen en mogelijkheden (best een pijnpunt bij aanbestedingstrajecten). Waar nodig heb je vragen met de andere aanbieders gedeeld, zodat iedereen zoveel mogelijk dezelfde informatie heeft. Je deelt de vragen met de andere aanbieders zodat iedereen zoveel mogelijk over dezelfde informatie beschikt.
Op de uiterste inzenddatum krijg je vijf aanbiedingen. Vijf IT leveranciers hebben veel tijd en aandacht besteed aan het zo goed mogelijk reageren op je RFP. Vier van hen ga je teleurstellen en bedanken voor die effort. Maar wie ga je nu wel selecteren?
De verliezers besteden soms weken aan inzet aan het beantwoorden van een RFP. En die tijd krijgen ze nooit meer terug.
Waarschijnlijk gebeurt er nu 1 van de 3 dingen:
- Er is één partij die duidelijk de goedkoopste is. Je kiest voor die partij, omdat er best wat financiële ruimte zit tussen hen en de nummer 2. Je bedenkt je dat er nog wel wat marge is, mocht er toch nog meerwerk komen. Deze partij heeft zich waarschijnlijk ingekocht. Tijdens het traject besteed je veel tijd aan (afleidende) gesprekken over meerwerk. De uiteindelijke prijs ligt waarschijnlijk hoger dan de prijzen die andere partijen hadden ingediend.
- Met alles wat je terugkrijgt heb je moeite om goed te kunnen vergelijken. De makkelijke keuze baart je zorgen, dus je gaat extra stappen inbouwen in het selectietraject. Met 2 of 3 partijen ga je nog verder de diepte in. Je traject wordt een stuk complexer en duurt een stuk langer dan je oorspronkelijk had bedacht.
- Er is best veel verschil in prijs, maar er is ook een duidelijk verschil in kwaliteit. Een goede, ervaren partij heeft gereageerd maar is ook de duurste. Misschien ook wel duurder dan oorspronkelijk was gebudgetteerd. Dat komt omdat deze partij snapt dat er nog heel veel niet bekend is en dat een onzekerheidsmarge/risico-opslag geen overbodige luxe is. Omdat jij over je begroting gaat moet je op zoek naar meer budget.
Even uitzoomen
De meeste IT leveranciers werken (met goeie reden) agile. En het is niet duidelijk hoe de oplossing er precies uit moet zien. Logisch dat er nog veel onzekerheid is! Niet alleen bij de leveranciers. Jij hebt dezelfde zorgen: met al dat geld dat ik ga uitgeven, heb ik aan het einde dan ook wel wat ik wilde hebben?
Vergeet de verborgen kosten niet. De consultant die je bij het proces hebt betrokken die nu meerdere maanden langer aan de RFP besteedt. Je eigen collega's die nog betrokken moeten worden om de RFP tot een goed einde te brengen. Het verlies aan tijd, waardoor je time to market (en dus de gewenste waarde die je wilde realiseren) maar uitgesteld blijft worden.
Start van het project
De selectie is achter de rug! De IT leverancier kan aan de gang. Hij start met een uitgebreide analysefase, omdat hij nog heel veel niet weet. Hij wil een goed beeld van de bestaande IT architectuur krijgen en hij maakt stappen om te komen tot een oplossing die past op alle eisen en wensen.
Daar komt dan de "Hoe" om de hoek kijken. Hoe zit het product nou eigenlijk in elkaar? Wat is het concept erachter? We weten misschien wel welke functionaliteiten nodig zijn, maar hoe werken die precies? Omdat de oplossing nog op 100 manieren kan worden uitgewerkt is het van belang om zo snel mogelijk die ene gewenste manier te vinden.
In veel gevallen zitten IT mensen hier aan het roer. De leverancier gebruikt een voorkeurstechnologie en die zal dan ook veel bepalen van hoe het product eruit komt te zien. Veel zal naar die technologie toe worden geredeneerd. Helemaal valide. Maar is dat ook de beste oplossing?
Wat nou als..
Wat nou als je de start van het project, waar je helder krijgt hoe de IT architectuur eruit ziet, maar vooral ook hoe de gewenste oplossing eruit ziet, wat nou als je die naar voren haalt?
Wat nou als je die analyse en de vertaling naar de oplossing laat doen onder regie van jouw business (waar die hoort) en onafhankelijk van de te kiezen technologie? Natuurlijk moeten er geen dingen bedacht worden die niet gebouwd kunnen worden, maar de technologie hoort niet leidend te zijn.
Als je de analyse en vertaling naar voren haalt, zet je een deel van het project vóór de RFP. En die laat je uitvoeren door professionals die veel ervaring met conceptontwerp hebben, aangevuld met een IT architect die de huidige IT architectuur in kaart brengt.
In de agile manier van werken heb je daar zelfs al een middel voor: de Discovery fase. Waar die door IT leveranciers vaak wordt ingezet om alle technische informatie naar boven te krijgen, kan een Discovery fase ook heel goed worden ingezet om het te ontwikkelen product veel helderder te krijgen.
Wat heb je dan?
Door een stap in het proces naar voren te halen heb je nu veel meer informatie over wat de beoogde oplossing is voordat je de RFP uitzet. En waar de uitdagingen liggen op ontwikkelgebied. Want die beoogde oplossing kan worden aangehouden tegen de bestaande IT architectuur.
Het gevolg is dat er veel minder onzekerheid is in het project. Dat betekent lagere aanbiedingen, maar ook aanbiedingen waar veel minder ruimte nodig is voor onvoorzien meerwerk.
Bovendien is in de meeste gevallen de kwaliteit van het eindproduct een stuk hoger. Omdat IT leveranciers heel goed zijn in ontwikkelen, maar niet altijd in het bedenken van een oplossing aan de hand van eisen en wensen.
