Een goede briefing voor een softwareproject beschrijft het probleem, de gebruikers, de betrokken systemen en hoe succes eruitziet, en laat de oplossing open voor de voorstellen van partners. Stuur elke partner dezelfde briefing met een budgetbandbreedte en een duidelijke lijst van wat vastligt, en de voorstellen die je terugkrijgt, zijn nauwkeurig genoeg om te vergelijken.
Een briefing is er om antwoorden vergelijkbaar te maken
Een projectbriefing heeft één taak: meerdere partners je probleem goed genoeg laten begrijpen om een oplossing voor te stellen, met een schatting die je kunt vertrouwen. Vult elke partner de gaten met eigen aannames, dan verschillen de voorstellen in scope in plaats van in kwaliteit, en het goedkoopste is vaak het voorstel dat het minst heeft aangenomen.
Wees in de briefing dus precies over het probleem en bescheiden over de oplossing. Beschrijf wat er moet kloppen als het project klaar is, en laat de partners uitleggen hoe ze daar zouden komen. Hun antwoorden op dat open deel zijn het nuttigste wat je te lezen krijgt.
Begin met het zakelijke probleem en hoe je succes beoordeelt
Open met de reden waarom het project bestaat: wat vandaag niet werkt, wie er last van heeft en wat het je kost om het zo te laten. Zeggen dat je operationele team elke bestelling uit de e-mail overtypt in het ERP, vertelt een partner veel meer dan vragen om een portaal voor orderbeheer.
Zeg daarna hoe je succes beoordeelt. Kies een paar resultaten die je kunt waarnemen, zoals tijdwinst per bestelling, fouten die klanten niet meer bereiken, of een datum waarop een oud systeem kan worden uitgezet. Deze criteria worden later de acceptatiecriteria voor de mijlpalen, dus formuleer ze zo dat iemand ze kan controleren.
Beschrijf gebruikers, systemen en data vóór de functies
Integratie- en datawerk worden makkelijk onderschat als een partner ze niet kan zien. Beschrijf voordat je functies opsomt wie de software gaat gebruiken, met welke systemen ze moet samenwerken en welke data ze verwerkt. Gaten in dit deel komen later terug als wijzigingsverzoeken.
- Gebruikers: wie ze zijn, ongeveer hoeveel, en waar en op welke apparaten ze werken.
- Bestaande systemen: wat ze zijn, wie de eigenaar is, en of ze een gedocumenteerde API hebben of alleen een database en bestandsexports.
- Data: wat persoonlijk, vertrouwelijk of gereguleerd is, waar het nu staat en hoeveel ervan moet worden gemigreerd.
- Beheer: wie de software na de lancering beheert, en welke regels je bedrijf al heeft voor hosting of cloud.
- Randvoorwaarden: talen, eisen voor toegankelijkheid, beveiligingsstandaarden en elke deadline die niet kan verschuiven, met de reden ervoor.
Deel een budgetbandbreedte en de deadline die er echt toe doet
Veel kopers houden het budget achter om te zien wat partners voorstellen. Het gevolg zijn voorstellen voor verschillende projecten: de ene partner ontwerpt voor het minimum, de andere voor alles wat je hebt genoemd. Een bandbreedte, ook een ruime, laat elke partner het beste project voorstellen dat erin past, en eerlijk zeggen als het niet past.
Doe hetzelfde met tijd. Zeg welke datum vastligt en waarom, zoals een contract dat afloopt of een wettelijke deadline, en welke datums alleen voorkeuren zijn. Een partner kan pas rond een harde datum plannen als hij weet welke dat is.
Geef aan wat vastligt en laat de rest open
Label elke eis als vast, voorkeur of open. Vast betekent dat een voorstel zonder die eis niet geldig is, zoals hosting in de EU of inloggen via je bestaande identiteitsprovider. Voorkeur betekent dat je een reden hebt, maar een alternatief zou overwegen. Open betekent dat je de aanbeveling van de partner wilt.
Laat de technologie open, tenzij je een echte reden hebt om haar vast te leggen, zoals een eigen team dat de code gaat onderhouden of een platform waarop je bedrijf heeft gestandaardiseerd. Leg je een keuze wél vast, zeg dan waarom, zodat partners hun voorstel niet besteden aan argumenten ertegen.
Vraag ten slotte elke partner om in dezelfde structuur te antwoorden: hun begrip van het probleem, de aanpak, fasen en mijlpalen, aannames, risico's, het team en het commerciële model. Een gemeenschappelijke structuur maakt de voorstellen in de praktijk vergelijkbaar.
Fouten die voorstellen onvergelijkbaar maken
Veel onbruikbare voorstellen zijn antwoorden op een briefing die erom vroeg. Haal deze patronen weg voordat je de jouwe verstuurt.
- Een lijst met functies zonder probleemstelling, zodat elke partner naar je prioriteiten moet raden.
- Een lange specificatie die de oplossing vastlegt voordat iemand het probleem heeft onderzocht.
- Geen woord over bestaande systemen of datamigratie, die daarna terugkomen als wijzigingsverzoeken.
- Extra details die in gesprekken aan sommige partners worden gegeven, zodat hun voorstellen andere vragen beantwoorden.
- Woorden als ‘eenvoudig’, ‘standaard’ of ‘zoals een bekende app’, die voor elke lezer iets anders betekenen.
- Geen deadline voor vragen, of antwoorden die alleen worden gedeeld met de partner die de vraag stelde.
Nodig uit tot vragen en lees ze als onderdeel van de beoordeling
Geef partners een vaste periode om vragen te stellen, antwoord schriftelijk en stuur elk antwoord naar iedereen. De vragen zeggen op zich al iets: een partner die vraagt naar je data, je gebruikers en je acceptatiecriteria, denkt al na over de oplevering.
Is het probleem nog te onzeker om goed te beschrijven, zeg dat dan en vraag om een korte, betaalde verkenningsfase in plaats van een volledig voorstel. Een vaste offerte die op gissingen is gebouwd, verstopt de onbekenden in haar risicomarge; een verkenningsfase vervangt de gissingen door feiten. Wil je dat engineers je briefing lezen, of erop antwoorden, dan kun je hem sturen via ons formulier ‘Start een project’.
De kern
- Beschrijf het probleem, de gebruikers en hoe succes eruitziet, en laat de oplossing open.
- Integratie- en datawerk worden makkelijk onderschat, dus noem elk betrokken systeem en elke dataset.
- Deel een budgetbandbreedte en zeg welke deadline vastligt en waarom.
- Label elke eis als vast, voorkeur of open, en vraag om voorstellen in één gemeenschappelijke structuur.
- Beantwoord vragen schriftelijk en deel elk antwoord met elke partner.
Veelgestelde vragen
Hoe lang moet een briefing voor een softwareproject zijn?
Lang genoeg om het probleem, de gebruikers, systemen, data, randvoorwaarden, budgetbandbreedte en planning te dekken, en dat past voor de meeste projecten op een paar pagina's. Wordt ze veel langer, dan beschrijft ze waarschijnlijk de oplossing in plaats van het probleem.
Deel je je budget met softwarepartners?
Ja, als bandbreedte. Zonder bandbreedte stellen partners projecten van heel verschillende omvang voor en kun je ze niet vergelijken. Een bandbreedte laat elke partner zien wat hij daarbinnen zou doen, en eerlijk zeggen als het niet genoeg is.
Vraag je in een briefing om een vaste prijs?
Alleen als de briefing het werk gedetailleerd genoeg beschrijft om het te schatten. Staan er nog belangrijke vragen open, vraag dan om een verkenningsfase tegen een vaste prijs of om een schatting als bandbreedte met vermelde aannames, en leg de prijs van de bouw vast zodra de onbekenden zijn opgelost.