Het projectdoel vertalen naar toetsbare resultaten
Beschrijf eerst welk bedrijfsprobleem de oplossing moet verhelpen. Minder handmatige invoer is bijvoorbeeld een doel, maar nog geen acceptatiecriterium. Benoem welke gegevens automatisch worden overgenomen, welke uitzonderingen handmatig worden afgehandeld en welke gebruikers daarbij betrokken zijn. Voeg voorbeelden toe van processen die na oplevering moeten werken.
Leg vast welke documenten de afgesproken specificatie vormen. Een offerte, presentatie en projectbord kunnen onderling verschillen. Bepaal daarom hoe versies worden vastgesteld en wie wijzigingen mag goedkeuren. Maak ook expliciet welke onderdelen buiten het project vallen. Dat is geen uitnodiging voor een lange standaarduitsluitingslijst, maar een manier om concrete verwachtingen over de gekozen oplossing te begrenzen.
Ontwikkelwerk en afhankelijkheden gezamenlijk plannen
De leverancier kan afhankelijk zijn van testgegevens, toegang tot een bestaande omgeving of keuzes van de opdrachtgever. Benoem deze bijdragen met een verantwoordelijke en benodigd moment. Geef aan wat er gebeurt wanneer een bijdrage uitblijft. Een vertraging mag niet automatisch aan één partij worden toegerekend zonder te onderzoeken wat werkelijk de voortgang heeft geblokkeerd.
Bij koppelingen met andere leveranciers moet duidelijk zijn wie het contact onderhoudt en welke technische documentatie beschikbaar is. Onderzoek eventuele kosten of beperkingen van externe systemen. Een werkende testkoppeling bewijst niet altijd dat productiegebruik is toegestaan. Behandel die toestemming daarom als een eigen afhankelijkheid in de planning, met een duidelijk controlepunt vóór ingebruikname.
Acceptatie van een magazijnkoppeling ontwerpen
Een fictieve groothandel laat bestellingen uit een verkoopportaal doorzetten naar het magazijn. Het testplan moet zowel de normale bestelling als uitzonderingen bevatten. Anders kan een korte demonstratie de indruk geven dat de hele oplossing gereed is.
Leg per test vast welke afwijking blokkering van acceptatie rechtvaardigt en welke kleinere tekortkoming later mag worden hersteld. De beoordeling moet herhaalbaar zijn, ook wanneer een andere medewerker het resultaat controleert.
| Testsituatie | Verwachte uitkomst | Wie controleert? |
|---|---|---|
| Volledig beschikbare bestelling | Eén correcte pickopdracht met herkenbaar ordernummer | Magazijncoördinator |
| Dezelfde order tweemaal aangeboden | Geen onbedoelde dubbele uitlevering | Technisch tester met procesverantwoordelijke |
| Artikel tijdelijk niet leverbaar | Afgesproken terugmelding en herkenbare wachtstatus | Verkoopmedewerker |
| Verbinding valt weg tijdens verzending | Herstel zonder verloren of dubbel verwerkte bestelling | Beide leveranciers gezamenlijk |
Meerwerk via een beslisbare wijziging behandelen
Een nieuwe wens kan waardevol zijn zonder onderdeel van de oorspronkelijke prijs te zijn. Spreek af hoe een wijzigingsvoorstel wordt beschreven: gewenste uitkomst, gevolgen voor bestaande onderdelen, kosten en planning. Laat de bevoegde opdrachtgever daarover besluiten voordat uitvoering begint, behalve waar een specifiek afgesproken spoedproces geldt.
Onderscheid uitbreiding van herstel van een afgesproken functie. Wanneer een koppeling verkeerd rekent, is dat iets anders dan een verzoek om een nieuw verkoopkanaal toe te voegen. Bewaar de oorspronkelijke eis en het testresultaat bij de discussie. Zo kan worden beoordeeld of werkelijk meerwerk ontstaat of dat een bestaande verplichting nog niet is nagekomen.
Rechten en onderhoud niet tot de laatste factuur uitstellen
Bepaal welke rechten de opdrachtgever krijgt op maatwerk, documentatie en configuratie. Betaling alleen maakt hem niet automatisch eigenaar van alle intellectuele rechten. De leverancier kan bestaande onderdelen of software van derden gebruiken. Leg daarom vast wat overdraagbaar is, welke licenties gelden en wat nodig is om een andere partij onderhoud te laten uitvoeren.
Regel ook de overgang van project naar beheer. Wie verhelpt een fout die kort na acceptatie zichtbaar wordt? Welke updates zijn inbegrepen en welke responstijd geldt bij een storing? Een ontwikkelovereenkomst en een onderhoudsafspraak beantwoorden verschillende vragen. De pagina over een service level agreement helpt om meetbare dienstverlening na oplevering afzonderlijk te beschrijven.
De oplevering als overdracht van verantwoordelijkheid zien
Maak een lijst van wat naast werkende software moet worden overgedragen: beheerdersrechten, instructies, configuratiegegevens en relevante licentie-informatie. Gebruik veilige kanalen voor toegangsmiddelen. Controleer dat de opdrachtgever de oplossing daadwerkelijk kan beheren en niet uitsluitend via het persoonlijke account van een vertrokken ontwikkelaar.
Voor het opstellen van de overeenkomst zijn een procesbeschrijving, conceptplanning en overzicht van betrokken systemen het nuttigst. Vermeld de beslissingen die nog openstaan. Het contract kan dan onderscheid maken tussen vaste resultaten, onderzoeksvragen en later te bestellen uitbreiding. Daarmee wordt het project bestuurbaar zonder te doen alsof iedere technische uitkomst vooraf al volledig bekend is.
Bronnen bij dit onderwerp
- Europese Commissie — Data Act uitgelegdGeraadpleegd op 2026-09-12
- KVK — Algemene voorwaarden en geschillen voorkomenGeraadpleegd op 2026-09-11