Ontwikkeling van software
Hoewel we steeds meer zien dat partijen kiezen voor zoveel mogelijk standaardisering in hun software, gebeurt het natuurlijk geregeld dat er maatwerk software wordt geleverd. Welke gevolgen heeft dat voor het contract? Voor de ontwikkeling van maatwerk is een groot aantal ontwikkelmethoden beschikbaar. Iedere ontwikkelmethode heeft parameters om op te sturen. Dit zijn functionaliteit, budget en tijd. In sommige gevallen wordt daar de parameter kwaliteit aan toegevoegd. Ongeacht de gekozen ontwikkelmethode, zullen over alle parameters afspraken moeten worden gemaakt. De gekozen ontwikkelmethode bepaalt op welke parameter tijdens het ontwikkeltraject het meest wordt gestuurd. De keuze van de ontwikkelmethode is afhankelijk van de voorkeuren van de organisatie, de ICT-leverancier, de projectleider en het op te leveren product. De ‘standaard’ methode is het lineaire model, ook wel waterval genoemd. Steeds meer ontwikkelaars geven echter de voorkeur aan een iteratieve methode (Agile, zoals bijvoorbeeld Scrum). Omdat Agile ontwikkeling nogal wat ‘open eindjes’ heeft, vraagt het wat creativiteit om dit juridisch op een goede manier vast te leggen.
Waterval (lineair)
Bij ontwikkeling volgens de watervalmethode doorloopt de ontwikkeling een aantal fasen: Analyse van systeem en functionaliteit, basisontwerp, technisch ontwerp, bouw, testen, correcties en de operationele fase. Per fase is vrij duidelijk wat de verantwoordelijkheden van de betrokken partijen zijn, en wat er aan het eind van een fase wordt opgeleverd. De volgende fase begint pas als de vorige fase is afgerond. Aanpassingen gedurende het traject hebben gevolgen voor de opleveringstermijn en de kosten. De onderwerpen die voor deze wijze ontwikkelmethode moeten worden vastgelegd zijn vrij duidelijk: Wat wordt er ontwikkeld, wat gaat dat kosten en wanneer is dat klaar? Nu komt het met grote regelmaat voor dat een dergelijk contract gedurende de ontwikkeltermijn toch weer wordt aangepast, maar de parameters zijn duidelijk. En als de ene parameter wordt aangepast, heeft dat ook gevolgen voor de andere parameters.
Agile methode
Een andere methode voor softwareontwikkeling is Agile. Agile kent vele vormen, waarvan Scrum een hele bekende is. In de Agile methode is de relatie tussen de opdrachtgever en de ontwikkelaar van groot belang. De ontwikkeling in Agile start met het uitzetten van enkele grote lijnen voor het project. Daarna begint het team meteen met ontwikkelen. Dat gebeurt in korte overzichtelijke perioden van enkele dagen tot weken (iteraties of sprints genoemd). Elke sprint wordt een afgebakend stukje functionaliteit geleverd. Het werk wordt verricht door multidisciplinaire teams, bestaande uit medewerkers van zowel opdrachtgever als de softwareontwikkelaar. Alle teamleden zijn heel nauw betrokken bij de ontwikkeling. Per sprint ligt de focus op één of meerdere functionaliteiten die aan het begin van het traject zijn geïnventariseerd. Gedurende het traject kunnen deze worden gewijzigd of aangevuld. De werkwijze gaat uit van veranderende omstandigheden gedurende het project, terwijl het uitgangspunt bij de watervalmethode is dat bij de aanvang van het project alle benodigde informatie aanwezig is en dat deze informatie niet of nauwelijks wijzigt. Het uitgangspunt bij Agile is, dat het gewenste eindresultaat efficiënter bereikt kan worden door tijdens het project bij te sturen.
Het contract
Ook al is de Agile methode gebaseerd op samenwerking, flexibiliteit en vertrouwen, het is toch van belang om gemaakte afspraken goed vast te leggen. Dat kun je uitleggen als een blijk van wantrouwen, maar ook als een manier om vast te leggen wat partijen van elkaar (mogen) verwachten. Ik beschouw een contract altijd liever als een methode om de samenwerking te ondersteunen.
Zowel bij de watervalmethode als bij de Agile methode kun je afspraken maken over de volgende onderwerpen:
- 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 hoe wordt er gestuurd?
Het is echter afhankelijk van de gekozen ontwikkelmethode op welke onderwerpen de meeste nadruk komt te liggen. In een traditioneel contract zal de nadruk meer liggen op scope, tijd en kosten. In een Agile contract wordt echter veel meer belang gehecht aan kwaliteit en continuïteit van het team. Al zal de tijdsplanning en het kostenaspect ook voldoende aandacht moeten krijgen.
Samenwerking
Omdat een belangrijk aspect van de Agile methode de samenwerking tussen opdrachtgever en opdrachtnemer is, moeten beide partijen voldoende mensen met de juiste kennis en ervaring ter beschikking stellen om een bijdrage te leveren aan het ontwikkelingsproces. In de tweede plaats is het nodig dat de betrokken personen beslissingsbevoegd zijn. Tijdens het proces moeten er dagelijks beslissingen worden genomen. Als deze vraagstukken continu moeten worden teruggelegd bij het hoger management, belemmert dit het ontwikkelingsproces. Tot slot dient een contract met betrekking tot de Agile ontwikkelmethode goede procesafspraken en afspraken over communicatie te bevatten. Is in het geval van lineaire softwareontwikkeling is de scope een vaststaand gegeven, bij ontwikkeling door middel van de Agile methode staat het budget en/of de tijd vast.
Vastlegging van de ontwikkelingen tijdens het proces
De realiteit is dat de scope van een overeenkomst gedurende een Agile-project voortdurend wordt bijgesteld. Om achteraf te kunnen vaststellen of partijen over en weer hun verplichtingen uit hoofde van de overeenkomst zijn nagekomen, is het essentieel dat de tussentijdse beslissingen en keuzes met hun motivatie gedegen zijn vastgelegd. Partijen kunnen hiervoor een logboek hanteren. Deze vastleggingen zijn ieder te beschouwen als wijzigingen in de overeenkomst. Cruciaal in de initiële overeenkomst is dus een duidelijke omschrijving van de procedure die partijen hanteren bij de wijzigingen of vervolgstappen gedurende het project.
Wil je meer weten over hoe je problemen met je ICT-leverancier zoveel mogelijk kunt voorkomen? Ik heb er een boek over geschreven: “ICT-contracten: goed geregeld”. Grip op contractsonderhandelingen voor ICT-managers en ondernemers.
Wil je persoonlijk overleg? Ik maak graag tijd voor een vrijblijvende kop koffie en een goed gesprek. Bel me (06-20640950) of mail me: mijke@sandersja.nl.
Ken je IT-managers voor wie deze tips of inzichten waardevol zijn, dan vind ik het erg leuk als je mijn blogpost deelt.
