Een echte goede en objectieve keuze maken in een RFP-traject is nauwelijks te doen. Hoe kan dat beter?
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.
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
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:
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.
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 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.
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.