Vergelijkbare voorstellen beginnen met een duidelijke opdrachtomschrijving: 12 gegevens die je beter meegeeft

Het huidige Britse Sourcing Playbook stelt dat een duidelijke specificatie voldoende informatie moet geven zodat aanbieders bewust kunnen beslissen of zij een voorstel willen indienen. Het document merkt ook op dat het zonder gedeeld begrip van de eisen moeilijk is om aangeboden prijzen te koppelen aan de verwachte kosten en resultaten van de opdrachtgever. [1]

De Government Commercial Function zegt het nog directer: een goede specificatie moet voldoende informatie bevatten zodat leveranciers correct kunnen begroten en de opdrachtgever voorstellen op een vergelijkbare basis kan beoordelen. [2]

Tegelijk waarschuwt het Britse Digital, Data and Technology Playbook voor het te ver voorschrijven van de oplossing. Het adviseert te focussen op de gebruiker, het probleem en het gewenste resultaat en leveranciers ruimte te geven om een effectieve aanpak voor te stellen. [3]

De conclusie is dus niet "beschrijf alles zo gedetailleerd mogelijk". Een betere regel is:

beschrijf precies wat voor alle voorstellen hetzelfde moet zijn, niet wat een deskundige specialist redelijkerwijs zelf kan ontwerpen.

Twee professionele voorstellen zullen nooit identiek zijn, en dat hoeft ook niet.

Vergelijkbaarheid betekent dat specialisten reageren op hetzelfde probleem met grotendeels dezelfde aannames.

Ze zouden ongeveer hetzelfde beeld moeten hebben van:

• het doel,
• de scope,
• de uitgangssituatie,
• het verwachte resultaat,
• belangrijke beperkingen,
• de planning,
• verantwoordelijkheden van de klant,
• de gewenste prijsopbouw,
• criteria waarop het voorstel wordt beoordeeld.

Ze mogen wel verschillen in bijvoorbeeld:

• voorgestelde aanpak,
• volgorde van activiteiten,
• methode,
• teamsamenstelling,
• hulpmiddelen,
• verdeling in fasen,
• aanpak om risico te beperken.

Juist die verschillen kunnen waardevol zijn en moeten zichtbaar blijven.

Begin met het probleem, niet met een lijst functies.

In plaats van:

"Ik heb een toepassing nodig met dashboard, meldingen en rapporten."

kun je schrijven:

"Vijf mensen beheren het proces nu via spreadsheets en e-mail. Het is moeilijk om de actuele status van een zaak, de verantwoordelijke persoon en de volgende taak te zien. We willen handmatige opvolging verminderen en één plek hebben met de actuele stand."

De tweede beschrijving bepaalt nog niet welke toepassing gebouwd moet worden.

Ze helpt de specialist wel begrijpen waarom het project überhaupt bestaat.

De Federal Acquisition Regulation voor resultaatgerichte diensten adviseert werk vooral te beschrijven aan de hand van vereiste resultaten, in plaats van de uitvoeringswijze of het aantal uren. Een minimale doelomschrijving omvat onder meer doel, scope, achtergrond, vereiste resultaten en operationele beperkingen. [4]

Beschrijf dus wat na afronding mogelijk moet zijn.

Bijvoorbeeld:

• een gebruiker kan zelfstandig een bepaald proces afronden,
• het team kan de actuele status van alle zaken bekijken,
• de klant ontvangt een analyse met prioriteiten,
• het systeem is naar een nieuwe omgeving verplaatst en werkt volgens afgesproken criteria,
• het voorbereide materiaal is klaar voor publicatie in een bepaald kanaal.

Het resultaat moet concreet genoeg zijn zodat beide partijen de richting van het werk begrijpen.

Het hoeft geen garantie te zijn voor een bedrijfsresultaat dat afhangt van markt, gebruikersgedrag of andere factoren buiten de invloed van de leverancier.

Dezelfde eindbehoefte kan heel verschillende inspanning vragen afhankelijk van waar je begint.

Het is nuttig te vermelden:

• wat al bestaat,
• wat werkt en behouden moet blijven,
• wat niet werkt,
• of bronbestanden bestaan,
• of documentatie bestaat,
• of gegevens moeten worden gemigreerd,
• of op een bestaand systeem moet worden gewerkt,
• welke materialen al klaar zijn.

"Een nieuwe website" kan een volledig nieuw project betekenen of een herbouw van een bestaande website met behoud van inhoud, adressen, analyse, integraties en gegevens.

Dat zijn verschillende werkzaamheden, ook als het uiteindelijke uiterlijk vergelijkbaar kan zijn.

De scope mag specialisten niet dwingen te raden welke delen van het probleem zij moeten begroten.

Bijvoorbeeld:

Binnen scope:

• analyse van de huidige oplossing,
• ontwerp van nieuwe schermen,
• implementatie,
• migratie van een bepaald deel van de gegevens.

Buiten scope:

• nieuwe inhoud maken,
• licenties aanschaffen,
• onderhoud na de eerste maand,
• herbouw van het betalingssysteem.

De voorbeeld-Terms of Reference van de Wereldbank benadrukken dat eisen en verwachtingen voor adviesdiensten duidelijk moeten worden geformuleerd en aan het concrete project moeten worden aangepast. [5]

Grenzen zijn vooral belangrijk wanneer twee taken vanzelfsprekend samenhangen en makkelijk kan worden aangenomen dat de ene de andere omvat.

Als je specifieke materialen of resultaten verwacht, benoem die dan.

Dat kan bijvoorbeeld zijn:

• een werkende oplossing,
• bronbestanden,
• een rapport,
• documentatie,
• een visueel ontwerp,
• een pakket materialen,
• configuratie van een omgeving,
• training,
• een opname,
• overdracht van code en toegangen.

Woorden als "ontwerp", "analyse" of "implementatie" kunnen verschillend worden geïnterpreteerd.

Een gemeenschappelijke lijst van belangrijke opleveringen voorkomt dat het ene voorstel veel meer bevat dan het andere terwijl dat verschil achter vergelijkbare benamingen verborgen blijft.

Niet elke beperking is een technisch detail.

Relevant kunnen bijvoorbeeld zijn:

• een verplicht systeem of omgeving,
• noodzakelijke integratie met een bepaalde dienst,
• toegankelijkheidseisen,
• sectorregelgeving,
• beperkingen voor gegevensopslag,
• de noodzaak bestaande infrastructuur te behouden,
• specifieke apparaten of browsers,
• werk binnen bepaalde uren,
• beperkte toegang tot gegevens.

De FAR noemt operationele beperkingen expliciet in een doelomschrijving, terwijl het Britse Digital, Data and Technology Playbook laat zien waarom je geen oplossing moet voorschrijven wanneer er geen echte beperking bestaat. [4] [3]

Een goede regel is:

beschrijf wat de specialist niet kan veranderen, maar verzin geen beperking alleen omdat je gewend bent aan één specifieke oplossing.

De specialist moet weten op welke samenwerking het voorstel kan worden gebaseerd.

Geef aan of je zorgt voor:

• een beslissingsbevoegde persoon,
• toegang tot systemen,
• bestaande materialen,
• gegevens,
• testaccounts,
• informatie van het team,
• toegang tot gebruikers,
• inhoud,
• regelmatige overleggen,
• antwoorden binnen een bepaalde termijn.

Als je nog niet weet wat je kunt leveren, is dat ook nuttige informatie.

Gebrek aan toegang tot gegevens, materialen of mensen kan methode, kosten en planning veranderen. Dit is geen klein administratief detail. Het hoort bij de voorwaarden waarop het voorstel wordt gebouwd.

Niet iedere datum heeft hetzelfde karakter.

Maak onderscheid tussen:

• gewenste startdatum,
• harde deadline,
• een datum die volgt uit een externe gebeurtenis,
• indicatieve datum,
• fasen die in een bepaalde volgorde moeten gebeuren.

Als een deadline echt niet verschoven kan worden, leg uit waarom.

Als er flexibiliteit is, zeg dat ook.

De specialist kan dan een andere scope, volgorde of gefaseerde uitvoering voorstellen in plaats van elke datum als absolute eis te behandelen.

Er is geen algemene regel dat een klant altijd het volledige budget moet bekendmaken.

Afhankelijk van de situatie kun je noemen:

• een maximumbudget,
• een budgetbereik,
• budget voor de eerste fase,
• dat je eerst een scopevoorstel en daarna pas de prijs verwacht,
• de gewenste opbouw van de prijs.

Voor vergelijking is vooral belangrijk dat specialisten kosten in een vergelijkbare structuur presenteren.

Bijvoorbeeld:

"Geef de prijs apart voor analyse, ontwerp, implementatie en maandelijks onderhoud. Benoem ook externe kosten die niet inbegrepen zijn."

Dat is veel makkelijker te vergelijken dan vier totaalbedragen die ieder iets anders omvatten.

Onzekerheid verdwijnt niet doordat je haar niet opschrijft.

Als je niet weet:

• hoeveel gegevens moeten worden gemigreerd,
• of een externe interface de benodigde handeling ondersteunt,
• of alle inhoud op tijd klaar is,
• of de huidige code redelijk kan worden uitgebreid,
• of een vereiste goedkeuring op tijd komt,

zeg dat dan.

De GAO-gids over betrouwbare kostenramingen benadrukt het belang van expliciete aannames en analyse van risico en onzekerheid. [6]

Een goede specialist kan dan:

• een reserve opnemen,
• een verkennende fase voorstellen,
• varianten begroten,
• een voorwaarde noemen die de prijs verandert,
• weigeren een nauwkeurigheid te suggereren die op dit moment niet eerlijk haalbaar is.

Een expliciete onbekende is beter dan een verborgen aanname.

Als je al weet wat belangrijk zal zijn bij de keuze, zeg dat dan voordat voorstellen worden gemaakt.

Je kunt bijvoorbeeld beoordelen:

• passendheid van de voorgestelde aanpak,
• ervaring met vergelijkbare problemen,
• kwaliteit van bewijs uit eerder werk,
• realisme van de planning,
• beschikbaarheid,
• aanpak van risicobeheer,
• vaardigheden van de mensen die werkelijk aan het project werken,
• prijs,
• onderhoudskosten,
• kwaliteit van communicatie.

De huidige richtlijnen van de Wereldbank over Rated Criteria noemen als mogelijke niet-prijscriteria onder meer kwaliteit van methodiek en werkplan, risicobeheer, uitvoeringsvermogen en sleutelpersoneel. Criteria worden aangepast aan de specifieke opdracht en gewogen naar hun relatieve belang. [7]

Dat betekent niet dat een kleine opdracht een formeel puntensysteem nodig heeft.

Het is genoeg als je vóór verzending kunt beantwoorden:

"Wat zou, naast de prijs, het ene voorstel voor mij beter maken dan het andere?"

Als je voorstellen echt wilt vergelijken, vraag iedereen om dezelfde basisvragen te beantwoorden.

Bijvoorbeeld:

1. Hoe begrijp je het probleem en het verwachte resultaat?
2. Welke aanpak stel je voor?
3. Wat bevat je voorstel precies?
4. Wat is uitgesloten?
5. Welke aannames maak je?
6. Hoe ziet de planning eruit?
7. Wat heb je van de klant nodig?
8. Wat zijn de belangrijkste risico’s?
9. Wat is de prijs en wat is precies inbegrepen?
10. Welke vergelijkbare ervaring of bewijs van werk is relevant voor deze opdracht?

In openbare aanbestedingen worden antwoorden, criteria en prijsformaten juist gestandaardiseerd om voorstellen op een gemeenschappelijke basis te kunnen beoordelen. De Government Commercial Function benadrukt dat voldoende informatie nodig is voor correcte begroting en vergelijking op gelijke basis. [2]

Een gemeenschappelijk formaat moet verschillen tussen specialisten niet uitwissen. Het moet ze alleen op dezelfde plaatsen zichtbaar maken.

Dat hangt af van het doel van de aanvraag.

Het budget delen kan helpen wanneer:

• de scope kan worden aangepast aan beschikbare middelen,
• je een aanbeveling wilt voor de beste optie binnen een grens,
• je voorstellen die financieel niet bij het project passen snel wilt uitsluiten.

Niet het volledige budget delen kan zinvol zijn wanneer:

• je eerst een onafhankelijke kijk op de juiste scope wilt,
• je de realistische kosten nog niet kent,
• je verschillende oplossingsmodellen vergelijkt,
• het proces een andere manier van prijsverzameling vereist.

Het slechtste scenario is niet noodzakelijk geen budget noemen, maar niet uitleggen welk soort prijsantwoord je verwacht.

De specialist moet weten of je één bedrag, een bereik, varianten, faseprijzen of aannames voor een nauwkeurigere raming wilt.

Een goede opdrachtomschrijving hoeft niet ieder antwoord al te kennen.

Ze kan eerlijk zeggen:

• "We weten nog niet of het huidige systeem veilig kan worden uitgebreid.",
• "We kennen het exacte aantal te migreren records nog niet.",
• "We hebben nog niet besloten of de tweede taalversie in de eerste fase zit.",
• "We hebben hulp nodig bij het kiezen van de beste optie."

Dat is waardevolle informatie.

Onzekerheid moet invloed hebben op hoe het voorstel wordt voorbereid, niet uit het document verdwijnen.

In sommige situaties is de beste eerste dienst niet de volledige uitvoering maar een korte verkenningsfase die eindigt met een beslissing, een nauwkeurigere scope of een betrouwbaardere raming.

1. Iedere specialist een andere set informatie geven.

2. Functies opsommen zonder probleem en doel uit te leggen.

3. Niet beschrijven wat al bestaat.

4. Beperkingen verbergen die later de manier van uitvoeren veranderen.

5. Eén eindprijs vragen zonder te zeggen wat erin moet zitten.

6. Voorstellen beoordelen met criteria die je zelf vooraf niet had bepaald.

7. Een gedetailleerde probleembeschrijving verwarren met een gedetailleerd voorgeschreven oplossing.

1. Heb ik het probleem duidelijk beschreven, niet alleen mijn eigen bedachte oplossing?
2. Is het gewenste resultaat duidelijk?
3. Begrijpt de specialist de huidige situatie?
4. Is duidelijk wat behouden moet blijven?
5. Zijn de grenzen van de eerste scope duidelijk?
6. Heb ik de belangrijkste opleveringen genoemd?
7. Heb ik echte beperkingen aangegeven?
8. Is duidelijk wat ik aan mijn kant lever?
9. Is de planning samen met de flexibiliteit beschreven?
10. Maakt de prijsopbouw het mogelijk voorstellen te vergelijken?
11. Heb ik de belangrijkste onbekenden openlijk benoemd?
12. Weet ik wat ik naast prijs zal beoordelen?
13. Beantwoorden alle specialisten een vergelijkbare set vragen?
14. Heb ik ruimte gelaten voor een betere oplossing dan degene die ik zelf bedacht?

Een goede opdrachtomschrijving heeft twee doelen die tegenstrijdig lijken.

Ze moet concreet genoeg zijn zodat meerdere specialisten hetzelfde probleem begroten.

Tegelijk moet ze open genoeg zijn zodat ieder een eigen, mogelijk betere aanpak kan voorstellen.

Een nuttige volgorde is:

probleem -> resultaat -> huidige situatie -> scope -> opleveringen -> beperkingen -> verantwoordelijkheden van de klant -> planning -> prijsformat -> onbekenden en risico’s -> keuzecriteria -> gemeenschappelijk antwoordformaat.

Als je na ontvangst ontdekt dat de ene specialist het hele project heeft begroot, een andere alleen de analyse en een derde extra integraties heeft aangenomen, ligt het probleem misschien niet in de offertes.

Mogelijk heeft iedereen een andere opdracht gekregen, ook al is dezelfde tekst verstuurd.

[1] UK Government - The Sourcing Playbook
Bron openen

[2] Government Commercial Function - How to write a procurement specification
Bron openen

[3] UK Government - The Digital, Data and Technology Playbook
Bron openen

[4] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Bron openen

[5] World Bank - Sample Consultants Terms of Reference
Bron openen

[6] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Bron openen

[7] World Bank - Rated Criteria
Bron openen

Methodologische toelichting: de bronnen komen vooral uit openbare aanbesteding en kostenbeheer. Ze worden niet gepresenteerd als directe regels voor een particuliere markt voor specialisten. Het artikel gebruikt alleen principes die zij daadwerkelijk ondersteunen: duidelijke eisen, focus op resultaten, expliciete aannames en risico’s, vergelijkbare prijsinformatie en kwaliteitsbeoordeling met meer criteria dan prijs alleen.