Tips voor een goed (agile) contract
| Sieuwert van Otterloo |
Agile
Contracten
Begin 2014 hebben we een onderzoek gedaan naar het onderwerp agile en contracten. De aanleiding voor het onderzoek was dat er vaak gedacht wordt, met name door IT-ers, dat agile en contracten niet goed samengaan. Uit het onderzoek onder IT-juristen bleek gelukkig dat zij hier anders over dachten: een goed contract kan men maken en is zinvol in zowel agile en niet-agile projecten. Hieronder staan de tips uit het onderzoek voor een goed (agile)-contract.
Voor het onderzoek naar agile contracten, waarvan de onderzoek agile IT-contracten, is gesproken met meer dan 20 IT-juristen. De meesten hiervan hadden weinig ervaring maar wel voldoende kennis van agile en konden tips geven hoe zij tot een goed contract komen, ook als er agile wordt ontwikkeld. Deze tips zijn hieronder verzameld.
Checklist ontwikkelcontract
De volgende checklist geldt voor bijna ieder contract:
- Scope: wat wordt er ontwikkeld?
- Kwaliteit: aan welke normen moet het eindresultaat voldoen?
- Tijd: welke mijlpalen moeten wanneer worden bereikt?
- Kosten: Hoeveel en wanneer wordt er betaald?
- Proces: Hoe wordt er gewerkt en vooral ook gestuurd?
Het contract moet op al deze punten zo precies mogelijk weergeven wat er is afgesproken, om misverstanden te vermijden. De volgende aanbevelingen helpen om dit goed te doen:
- Maak een kort en leesbaar contract, dat voor ook voor niet-juristen begrijpelijk is. Liever twee tot vijf dan twintig tot vijftig pagina’s
- Neem belangrijke inhoudelijke stukken zoals projectplannen, use cases, product backlogs en ontwerpen expliciet op als bijlage, zodat later duidelijk is welke versie bedoeld wordt.
- Organiseer als jurist eventueel een uitlegsessie na sluiten van het contract om degenen die het werk echt moeten uitvoeren uit te leggen wat afgesproken is
- Maak concrete afspraken over het proces tijdens het project. Spreek bijvoorbeeld af hoe vaak en wat voor overleg er is, wie er besluiten neemt over wijzigingen, en wie van de opdrachtgever op de hoogte gehouden wordt.
- Zorg ervoor dat betalingen gekoppeld zijn aan mijlpalen, zodat er alleen betaald wordt als er daadwerkelijk iets is geleverd.
- Wees als opdrachtgever betrokken bij de voortgang, en bezoek het ontwikkelteam minimaal om de week.
- Spreek af hoe de leverancier kan escaleren als er niet voldoende betrokkenheid van de opdrachtgever is.
- Doe aan contract-onderhoud: controleer geregeld welke aanvullende afspraken gemaakt zijn of gemaakt moeten worden en voeg deze toe aan het contract. Spreek bijvoorbeeld af om elke 3 maanden het contract bij te stellen.
- Denk na over beëindigings-scenario’s van de overeenkomst. Hoe kan men uit elkaar gaan als één van de partijen niet tevreden is of er onverwachte ontwikkelingen zijn? Zorg ervoor dat het contract duidelijk beschrijft wanneer en hoe men uit elkaar gaat.
Agile aanbevelingen
Naast deze algemene tips, zijn er de volgende specifieke agile aanbevelingen:
- Leg een concrete methode vast. Gebruikelijk in Nederland is om te kiezen voor scrum.
- Leg expliciet vast wie de scrumrollen inneemt (scrum master en product owner) en welke ‘stakeholders’ bij de demonstratie moeten zijn.
- Zorg aan de opdrachtgevende kant voor de best mogelijke ‘product owner’: iemand met mandaat die drie tot vijf dagen per week vrijgemaakt is en minimaal drie keer per week naar het ontwikkelteam gaat om de voortgang te bekijken en feedback te geven op de reeds gerealiseerde elementen.
- Zorg voor opleiding. Zowel voor de mensen ingezet door de leverancier en voor de betrokkenen aan de kant van de opdrachtgever. Er zijn goede en goedkope scrum-opleidingen van 1 of 2 dagen die ook op locatie kunnen worden gegeven.
- Leg bij een vaste-prijs contract goed vast of en door wie de scope van het project mag worden aangepast. In principe mag bij agile de scope wijzigen op grond van nieuwe inzichten. Wie als opdrachtgever wil dat er zo min mogelijk verandert, zal zelf betrokken moeten zijn om zo te weten wat er gebeurt.
- Zorg ervoor dat er binnen de opdrachtgevende organisatie goed gecommuniceerd wordt over de doelen van het project en de eisen aan het systeem. Het is met name bij agile gevaarlijk als betrokkenen van de opdrachtgever verschillende kanten op sturen.
- Overleg aan het begin van het project ook over niet-functionele eisen, zoals aantallen gebruikers, snelheid en beveiliging. Bespreek niet alleen wat de eisen zijn maar ook hoe deze gedemonstreerd kunnen worden tijdens het project.
Dr. Sieuwert van Otterloo (CISA, CIPP/E) is IT-deskundige met kennis van ISO 27001, NEN 7510, software-kwaliteit, projectmanagement, privacy, en verantwoord gebruik van AI. Hij geeft les aan de VU, doet onderzoek aan de HU en geeft advies en doet reviews bij organisaties door heel Nederland. Hij oprichter en directeur van ICT Institute.