Er is veel te doen bij het opzetten van een Europese aanbesteding. Er moet lang nagedacht worden over de gewenste systeem eisen, over de voorwaarden en criteria waar de leverancier aan moet voldoen en de uitwerking van de juridische aspecten. Aan de hand hiervan wordt zware documentatie opgesteld waarin wordt getracht om de genoemde zaken tot op detail niveau te beschrijven. Het aanbestedingsdocument moet volledig en helder en vooral eenduidig beschreven zijn. Het lijkt wel of er bij een Europese aanbesteding wel meer, beter en diepgaandere voorbereiding plaatsvindt dan bij het begin van een regulier ontwikkeltraject.
Tijdens aanbestedingen en het verdere traject komen veel organisaties er achter dat de eisen uit de aanbesteding documentatie toch op verschillende manieren te interpreteren zijn. Dit ondanks de zorgvuldige voorbereidingen. Deze worden dan vaak ook anders geïnterpreteerd door de aanbieder. Dit kan ertoe leiden dat er aanpassingen op de aanbesteding gedaan moeten worden die al gauw als ‘meerwerk' worden gerekend door de aanbieder met de nodige extra kosten. Hierop volgt er vaak een Nadere Overeenkomst (NOK), waarmee dit soort wijzigingen worden ingepast in het project. Dit op eisen die eerst helder leken, waar de aanbieder ‘Ja, dat kunnen wij' op gezegd heeft en uiteindelijk toch anders wordt geleverd. Extra kosten om toch weer op de uiteindelijke eis te komen? Dat is niet de bedoeling, maar gebeurt toch, zeker als een project al loopt en er deadlines gehaald moeten worden.
De laatste situatie zorgt ervoor dat het budget iets omhoog moet, voor iets zonder toegevoegde waarde. Dit is immers een reparatie van een verstoring in de communicatie. Maar dit zal vaak nog niet tot problemen leiden voor de verdere ontwikkeling van het systeem en het project. Pas waar het echt mis gaat als een systeem eigenlijk niet past in je organisatie en je tijdens het project beseft dat het aangekochte systeem eigenlijk helemaal niet voldoet aan je gestelde eisen. Misschien waren de eisen toch niet zo goed opgesteld als gedacht, of heeft de aanbiedende partij hier wel een hele andere interpretatie aan over gehouden, bewust of onbewust. Als je de aanbesteding stopt dan kan dit tot een zeer lastige rechtszaak leiden, waar een aanbiedende partij vaak het voordeel van de twijfel krijgt.
Integreren testtraject
Helemaal voorkomen kan je het niet, maar je kunt er wel voor zorgen dat je de genoemde risico's beperkt door in je aanbesteding een testperiode op te nemen, waar je als organisatie een ‘Aanbesteding Acceptatie Test' of 'Proof of Concept' inbouwt. Pas als deze test geslaagd is dan worden de handtekeningen gezet. Is de test niet geslaagd, dan is de volgende aanbieder in de rij aan de beurt om zich te bewijzen.
Door mijn ervaringen in aanbestedingstrajecten heb ik een lijst samengesteld van aandachtspunten binnen dit soort trajecten.
• Plannen testtraject: Houdt rekening met extra uitzoekwerk. Je weet bij het maken van testgevallen niet welke producten je gaat krijgen en producten kunnen specifieke tests vragen welke je niet van te voren kan voorbereiden.
• Controle van de offerte: Bekijk de offerte van de aanbieders op dezelfde manier als een ontwerp en voer een of meerdere officiële review sessie uit met de opstellers van het aanbieding document. Zo worden onvolkomenheden in de offerte van de aanbieder goed zichtbaar.
• Acceptatie criteria: Omdat je niet al bij één gevonden probleem de leverancier wilt afkeuren, is het verstandig om een bepaalde grenswaarde in te bouwen. Zoiets als: de leverancier mag bevindingen oplossen binnen de testperiode, maar maximaal twee/drie/… bevindingen. Een andere mogelijkheid is het inbouwen van een marge: 90% van de testgevallen moet goed gaan in de acceptatietest. Opgeloste zaken door de leverancier vallen dan binnen de offerte die aangeleverd is. Beschrijf deze procedure wel in het aanbesteding document.
• De basis om te testen: De eisen. Een leverende partij kan alleen beoordeeld worden op de eisen uit het aanbestedingsdocument. Bevindingen die tijdens het testen naar boven komen die niet te relateren zijn aan de eisen kunnen niet meegenomen worden in een beoordeling.
• Juridische elementen en contractafspraken: Betrek de afdeling juridische zaken of een contract beheerder inkoop tijdens het gehele acceptatie traject om het aanbestedingsproces te bewaken op contract- en juridische elementen.
• Communicatie testers naar leverancier: Houdt afstand van de leverancier door alleen via de projectmanager te communiceren. Samenwerken tijdens de testuitvoer is prima, maar communiceer bevindingen- en voortgangsrapportages altijd via de projectmanager. In dit soort trajecten kan verkeerde of zichzelf tegensprekende informatie later juridisch gebruikt worden.
• Samenwerking met leverancier: Tijdens het gehele testtraject kan je ook de samenwerking op de werkvloer, de afspraken die gemaakt worden, het omgaan met bevindingen en de manier waarop de leverancier met het project omgaat bespreken en ook als een " test" beschouwen. Past de aanbieder wel bij jouw organisatie. Als je naast een product ook een service contract voor een paar jaar aanbesteedt is dit punt wel heel belangrijk.
• Testrapport en bevindingen: Goed opletten of er geen tegenstrijdigheden instaan
• Testrapport, duidelijk en juridische controle: Bespreek het rapport en voer review sessies uit met de uiteindelijke ontvangers hiervan. Dit zijn naast je projectleider ook belanghebbende managers, juridische specialisten en contractbeheerders. Maak het rapport op gedurende het gehele traject en stem de testrapportages tijdens het testtraject al goed af met deze belanghebbenden.
Gewoon doen
Het testen van aanbestedingen is niet iets waar veel organisaties aan denken als er een dergelijk project wordt gestart, zeker niet als onderdeel van het proces van goedkeuren van een aanbesteding en het officieel tekenen van de contracten. Als je wel een acceptatie test uitvoert heeft dit aardig wat aandachtspunten omdat je met een niet te wijzigen eisenlijst zit en veel juridische aspecten die om de hoek komen kijken.
Toch is het aan te raden om testen deel te maken van een aanbesteding als je binnen je geschatte budget wilt blijven en het "koren van het kaf wilt scheiden" tussen de diverse aanbieders. Tijdens een testtraject komt de leverancier en je organisatie dicht bij elkaar en kan je naast het bekijken van de kwaliteit (=voldoet product aan alle gestelde eisen) ook de samenwerking en de kwaliteit van de aanbieder valideren. Dit maakt het een waardevolle aanvulling op je aanbesteding.
Rob van Steenbergen, software tester bij Chickenwings Test Consultancy
Een proefperiode voordat de contracten getekend worden is zeker een goed idee. Je stapt ook niet tijdens de eerste date in het huwelijksbootje. De samenwerking moet getest worden. Het is echter een illusie om te denken dat je in een dergelijke proefperiode ook inzicht krijgt in de kwaliteit van het op te leveren product.
De auteur defineert productkwaliteit als de mate waarin het product voldoet aan de gestelde eisen. Eerder geeft hij aan dat het probleem juist is dat deze eisen veranderen met de tijd en op ieder moment voor meerdere uitleg vatbaar zijn. Kwaliteit kan beter gedefinieerd worden als de mate waarin de accepterende partij met het product uit de voeten kan. Dit is niet uit te maken op grond van aantallen opgeloste bevindingen tijdens het testproces of percentages goed verlopende testgevallen.
Het beperken van communicatie over bevindingen en voortgang lijkt me geen verstandig idee. Er is nog tijd genoeg voor geheimzinnigheid als de contracten eenmaal getekend zijn. Voor die tijd hebben openheid en eerlijkheid nog geen juridische gevolgen. Het is beter om tijdens de verloving nog niet aan scheiden te denken.
Het inlassen van een Proof of Concept is een goed idee als onderdeel van de totale kwaliteitsborging in een project. Maar je moet dan wel vooraf goed vastleggen wat je precies wilt opnemen in de POC. Dat lijkt een open deur, maar gaat in de praktijk nogal eens mis. Is de POC om aan te tonen dat het product stabiel is en alle in het ontwerp beschreven veldjes aanklikbaar zijn? Of is het de bedoeling dat daarin wordt aangetoond dat het nieuwe systeem inderdaad 20% minder invoertijd vergt, zoals in het pakket van eisen was beschreven?
Als je dat niet expliciet en het liefst in Jip-en-Janneketaal vastlegt kun je daar achteraf nog wel eens onaangenaam lang over discussiëren. Daarom is het los van de POC bijzonder aan te bevelen om het bouwen van een prototype op te nemen in het project. Wat je daar in het voortraject extra in investeert, verdien je aan de achterkant dubbel en dwars terug in termen van acceptatie en aansluiting op de praktijk.
Het is een optie. maar hoogstwaarschijnlijk niet de sleutel. Maar altijd nog beter dan iets verzinnen als een combinatie van agile en gestructureerd testen en dat ‘stragile testen noemen’. Dan zoek je gewoon naar een gat in de markt dat er niet bestaat.