Ook agile project heeft contract nodig

Het Agile Manifesto heeft gelijk dat er niet onderhandeld moet worden over de details van een oplossing. Maar dat wil niet zeggen dat een agile project geen contract nodig heeft. Met een goed contract, zegt Marianne Korpershoek, zijn de gevolgen van een mislukking beter beheersbaar.

Heeft een agile project een contract nodig? De derde hoofdregel van het Agile Manifesto luidt: ‘Samenwerking met de klant boven contractonderhandelingen.’ Als dat zo is, is het dan nog wel nodig om een contract te sluiten en is het dan niet beter je de juristerij van contractonderhandelingen te besparen? Maar geen contract sluiten is ook een contract. Vaak gelden toch de inkoopvoorwaarden van de afnemer of de verkoopvoorwaarden van de leverancier. En als er helemaal niets wordt ­afgesproken gelden toch de regels van het ­Burgerlijk Wetboek of de Auteurswet. Passen die voorwaarden of wettelijke regels wel zo goed bij een agile project? Of zorgen zij ervoor dat ze het project meer kwaad dan goed doen. Daarom is het raadzaam een goed contract uit te onderhandelen zonder dat dat in strijd is met de basisprincipes van agile.

 

Twee zaken

Om een agile project goed af te ronden is het belangrijk om twee zaken te onderscheiden. In een klassiek automatiseringscontract voor de ontwikkeling van een systeem of een applicatie wordt er in een contract tot in detail geregeld hoe de oplossing er uit moet zien. Verder worden in het contract de randvoorwaarden van de samenwerking geregeld (zie schema). In de kern van het contract worden de afspraken neergelegd over de hoofdverplichtingen van de leverancier en afnemer. Voor een agile project is dat dus niet een gedetailleerde beschrijving van de oplossing. Wel moeten er in zo’n contract belangrijke zaken aan de orde komen zoals budget, einddatum, kwaliteit van teams, beschrijving van het op te lossen probleem en inzet van mensen en middelen (van beide kanten). Het Agile Manifesto heeft dus gelijk als het stelt dat er niet onderhandeld moet worden over de details van de oplossing, dat gebeurt immers al werkend. Dat neemt niet weg dat beide partijen zich duidelijk moeten uitspreken over wat zij kunnen bieden om het probleem van de afnemer op te lossen.

 

Randvoorwaarden

Naast de kern van een ontwikkelovereenkomst moet er ook nog aan allerlei randvoorwaarden worden voldaan. In dit deel van de overeenkomst worden vaak risico’s afgedekt. Hoe wordt de aansprakelijkheid verdeeld? Is de leverancier verzekerd? Hoe wordt het project gefinancierd ofwel wanneer gaat de opdrachtgever betalen? Verder kunnen er in de randvoorwaarden van het contract afspraken worden gemaakt die te maken hebben met de randvoorwaarden voor een succesvol agile project. Rini van Solingen heeft deze randvoorwaarden al uitgebreid besproken in zijn artikel in de Automatisering Gids van 7 mei jl. (‘Hoe verloopt een agile aanbesteding?’). Hij noemt onder andere de ‘Definition of Done’, waarin de eisen aan bijvoorbeeld de kwaliteit van software, documentatie en testen worden vastgelegd, de methode waarmee wordt gewerkt – in Nederland is dat vaak Scrum, maar er zijn ook andere agile methodes – de eisen aan het Scrum-team, toetsingscenario’s, KPI’s, de ­governance van het project, bonus-malussystemen voor extra incentives, eisen aan de ­resultaten van de sprints, scopewijzigingen et cetera.

Daarnaast dient een contract ook om afspraken over het intellectuele eigendom te maken. Mag er bijvoorbeeld opensourcesoftware gebruikt worden voor de oplossing? Hoe zit het met de implementatie van standaardsoftware en met de licenties daarvan? En verder moeten er natuurlijk nog afspraken worden gemaakt over het eigendom op de software die ontwikkeld wordt in het kader van het agile project.

Ten slotte is het ook belangrijk dat er afspraken worden gemaakt over stopcriteria en exit. Maak een contract zo dat beide partijen gemakkelijk en tijdig uit elkaar kunnen op het moment dat de samenwerking niet leidt tot wat partijen voor ogen hadden bij het begin van het project. Op die manier voorkom je dat de spanningen oplopen, de belangen groter worden en men tegenover elkaar komt te staan.

 

Transparantie

In tegenstelling tot wat veel mensen denken, kan een goed contract bijdragen aan de transparantie van de belangen van beide partijen. Te vaak probeert de machtigste partij de risico’s zoveel mogelijk bij de andere partij te leggen, de belangen worden versluierd en er wordt een lock-in gecreëerd. Deze contracten zorgen ­ervoor dat de afspraken in beton worden gegoten. De wendbaarheid die nodig is om een agile project tot een goed einde te brengen, komt in gevaar.

Onderhandelingen die duidelijk zijn over de belangen van de leverancier, kunnen ook duidelijk maken dat de wensen van de afnemer in relatie tot zijn budget of planning te hoog gegrepen zijn of dat de capaciteit van de leverancier juist niet voldoende is. Dat is dan een reden om de afspraken te wijzigen of zelfs om afscheid van elkaar te nemen (voor het te laat is). Uiteraard kan iedere samenwerking mislopen, maar als het goed is, zijn met een goed contract de gevolgen daarvan voor beide partijen beheersbaarder.

Marianne Korpershoek(korpershoek@louwersadvocaten.nl) is advocaat bij Louwers IP|Technology ­Advocaten.Partijen moeten gemakkelijk uit elkaar kunnen.

 

Contract als reddingsboei

In 2009 sluiten de Hanze Hogeschool Groningen en Cordys na een aanbesteding een contract voor de ontwikkeling en levering van standaardsoftware voor een Student Informatie Systeem (SIS). De maatwerksoftware wordt volgens de agile methode ontwikkeld. Verder wordt er afgesproken dat het nieuwe systeem – met tussenstappen – op 1 januari 2011 operationeel is, zodat het oude systeem uitgefaseerd kan worden. Dat moet ook, want dan lopen de licenties met de oude leverancier af. Vlak na de zomer van 2009 blijkt dat de planning niet gehaald kan worden en worden er nieuwe afspraken gemaakt over de planning. Verder stelt Cordys zich op het standpunt dat een deel van de eisen en wensen van de user stories meerwerk zou zijn. Uiteindelijk blijkt in februari 2011 dat Cordys nog vrijwel niets heeft geleverd. Het staat ook vast dat de planning niet gehaald gaat worden. Uiteindelijk ontbindt de Hanze Hogeschool het contract in maart 2011. In een procedure voor de rechter vordert Hanze Hogeschool terugbetaling van de facturen van Cordys van ruim anderhalve ton en een volledige schadevergoeding op grond van het feit dat Cordys wist dat zij de leveringsovereenkomst niet zonder ernstige gebreken zou kunnen nakomen. Dit is onrechtmatig en kan er voor zorgen dat een rechter een aansprakelijkheidsbeperking in een overeenkomst terzijde schuift omdat een beroep op zo’n exoneratie in dat geval in strijd is met de redelijkheid en billijkheid. Cordys heeft in het begin van de onderhandelingen op vragen van de Hanze ­Hogeschool over de in de aanbesteding ­gevraagde planning, geantwoord dat dit geen enkel probleem zou zijn. Hetzelfde gold voor de complexiteit van de opdracht, ook daarvoor had Cordys aangegeven dat dat geen probleem zou zijn. De rechter komt in haar vonnis tot de conclusie dat Cordys bij inschrijving op de aanbesteding wist dat zij voor de ontwikkeling van het SIS eerder jaren dan maanden nodig zou hebben. Toch heeft Cordys inschreven en ze heeft zelfs uitdrukkelijk verklaard bij de verificatievergadering dat ze tijdig zou kunnen leveren. Dat rekent de rechter Cordys zwaar aan. Zij vindt dat Cordys toerekenbaar tekort is geschoten in de nakoming en komt tot de conclusie dat de Hanze Hogeschool de overeenkomst terecht heeft ontbonden. Omdat Cordys de gang van zaken te rooskleurig heeft voorgespiegeld waardoor Hanze ­Hogeschool in zee is gegaan met Cordys, kent de rechter Hanze Hogeschool ook nog een volledige schadev

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag