Handvatten voor het succesvol opleveren van programmatuur JURIDISCHE VALKUILEN IN ICT-PROJECTMANAGEMENT ICT-Projectmanagers professionaliseren zich door het behalen van een Prince2 en/of IPMA certificaat. Wat in het certificeringstraject onderbelicht blijft zijn juridische consequenties die zich binnen ICT-projecten voordoen. Dit begint al bij de start van een project waarbij de gesloten overeenkomst tussen opdrachtgever en dienstverlener rechten en plichten bepaalt die op partij(en) rust(en). Projectmanagers dienen te beseffen wat deze rechten en plichten inhouden. H et realiseren en opleveren van programmatuur is een complexe aangelegenheid waarbij zich tal van problemen kunnen voordoen. Privacy issues en gegevensbeveiliging dwingen IT-professionals steeds meer rekening te houden met de juridische consequenties van programmatuurleverantie. The Obamacare Website (http://www.businessinsider.com/the-coderswho-built-the-obamacare-website-knew-it-had-hugeproblems-2013-10) is een recent en sprekend voorbeeld hoe het mis kan gaan. Het laatste ‘juridische’ geschil over dit project is voorlopig nog niet beslecht. Programmatuurontwikkeling verloopt volgens een aantal - redelijk generieke - stappen waarin de verantwoordelijkheden van deelnemers gaandeweg het projectverloop wijzigt. Deze gewijzigde verantwoordelijkheid brengt met zich mee dat aansprakelijkheden ook wijzigen. Deelnemers van het project (waaronder projectmanagers) zijn zich niet altijd bewust van deze zich wijzigende rolverdeling en de hiermee samenhangende juridische consequenties. Doel van dit artikel is een overzicht op hoofdlijnen aan te reiken om juridische valkuilen in ICT-projectmanagement te voorkomen. De opbouw van het artikel is als volgt: Eerst worden de stappen van programmatuurontwikkeling beschreven. Van elke stap worden de hoofdactiviteiten en de rolverdeling tussen de opdrachtgever en projectmanager beschreven. Per stap wordt aangegeven welke juridische valkuilen zich kunnen voordoen en hoe deze valkuilen zijn te voorkomen. Het artikel wordt afgesloten met een conclusie. Nota bene: In het artikel wordt vaak het woord adequaat gebruikt. Met adequaat wordt bedoeld een beschrijving van het onderhavige begrip zodanig dat het begrip is te normeren en te toetsen. STAPPEN VAN PROGRAWMMATUURONTWIKKELING We sluiten aan op het model systems development life cycle (SDLC, zie figuur-01) om het proces van planning, creatie, testen en invoering van programmatuur te beschrijven. AUTEUR FRANS HUYGEN, Beëdigd Informaticus NVBI, Gerechtelijk ICT deskundige LRGD en directeur Ranwood B.V. 8 IPMA Projectie Magazine | 01-2014 De volgende projectstappen worden in het model onderscheiden: Requirements; Ontwerp; Realisatie; Testen en Invoeren. Onderstaande tabel bevat van elke projectstap met hoofdactiviteiten een beschrijving en de rolverdeling van de opdrachtgever en projectmanager. 5. 6. 1.1 START 1. 2. 3. Alhoewel ‘Start’ geen onderdeel is van het systems development life cycle (SDLC, zie Figuur-01) kunnen zich hierin al wel valkuilen voordoen, bijvoorbeeld door het niet afspreken van leveringsvoorwaarden of door projectafspraken te maken zonder de reikwijdte van het project te kennen. Andere valkuilen die zich kunnen voordoen: Ter hand stellen van leveringsvoorwaarden (rolverdeling: projectmanager controleert en adviseert; opdrachtgever beslist). Stel daarbij vast of u te maken heeft met een professionele partij of niet. Consumenten genieten extra bescherming. De reikwijdte van het plan van aanpak zal bij de start van de opdracht meestal niet verder reiken dan het opleveren van requirements, tenzij de requirements bij de start bekend zijn (rolverdeling: projectmanager adviseert; opdrachtgever beslist). Beschrijf het object van levering op een adequate wijze (meetbaar en toetsbaar) zodat hierover achteraf tussen partijen geen misverstand kan ontstaan (rolverdeling: projectmanager voert uit; opdrachtgever beslist). beslist kan worden (rolverdeling: projectmanager voert uit; opdrachtgever faciliteert en beslist). Voorkom misverstanden achteraf door een registratie waaruit duidelijk blijkt wat de opdrachtgever over de requirements heeft besloten (zie 1). Registreer als de opdrachtgever anders over requirements besluit dan dat u (heeft) (ge) adviseert(d) (rolverdeling: projectmanager adviseert en registreert; opdrachtgever beslist). Toets of is geleverd zoals is afgesproken (conformiteit, zie 4) en artikel 17, lid 2 BW7 (rolverdeling: projectmanager registreert; opdrachtgever beslist). Artikel 17, lid 2 BW7: “Een zaak beantwoordt niet aan de overeenkomst indien zij, mede gelet op de aard van de zaak en de mededelingen die de verkoper over de zaak heeft gedaan, niet de eigenschappen bezit die de koper op grond van de overeenkomst mocht verwachten. De koper mag verwachten dat de zaak de eigenschappen bezit die voor een normaal gebruik daarvan nodig zijn en waarvan hij de aanwezigheid niet behoefde te betwijfelen, alsmede de eigenschappen die nodig zijn voor een bijzonder gebruik dat bij de overeenkomst is voorzien.” 1.3 ONTWERP Het opstellen van de (technische) ontwerpspecificaties zoals procesbeschrijvingen en beschrijvingen van schermen en gegevens. De eis die aan een ontwerp gesteld kan worden is dat een opdrachtgever de functies van de programmatuur en de vormgeving daarvan kan begrijpen. Een prototype kan onderdeel zijn van de ontwerpspecificaties. 7. De opdrachtgever is in staat de ontwerpspecificaties te beoordelen en daarover te beslissen (rolverdeling: projectmanager voert uit; opdrachtgever faciliteert en beslist) 8. Voorkom misverstanden achteraf door een registratie waaruit blijkt dat de opdrachtgever het ontwerp, als blauwdruk van de te realiseren programmatuur, heeft begrepen en heeft geaccepteerd (rolverdeling: projectmanager adviseert en registreert; opdrachtgever beslist). 9. Toets of is geleverd zoals is afgesproken (conformiteit, zie 4) en artikel 17, lid 2 BW7 (rolverdeling: projectmanager registreert; opdrachtgever beslist). 1.2 REQUIREMENTS 1.4 REALISATIE 4. Alhoewel de onderdelen realisatie en testen van elkaar verschillen is de samenhang en de wisselwerking tussen beide in de praktijk groot. Testuitkomsten dienen als input voor het completeren en vervolmaken van de programmatuur. Bij de realisatie kunnen verschillende leveranciers zijn betrokken waardoor risicovolle afhankelijkheden ontstaan. De rol van de projectmanager verandert van Vaststellen van eisen waaraan de te ontwikkelen programmatuur moet voldoen op basis van de eisen van de opdrachtgever; de eisen van gebruikers en de eisen afkomstig uit de omgeving. Beschrijft de requirements op een adequate wijze, zodanig dat deze door de opdrachtgever worden begrepen en dat er door de opdrachtgever over > 01-2014 | IPMA Projectie Magazine 9 Projectstappen Hoofdactiviteiten Rolverdeling Context van het project vaststellen en de condities waaronder project wordt uitgevoerd. Opdrachtgever beslist Start (Projectmanager is Adviseur) Projectmanager controleert, voert uit en adviseert Requirements (Projectmanager is Adviseur) Op basis van analyse en interviews in kaart brengen van requirements. In samen werking met opdrachtgever prioriteit requirements vaststellen. Omvang van het project bepalen. Vaststellen doelen, analyse van de omgeving en analyse van de gebruikers. Opdrachtgever faciliteert Projectmanager voert uit en adviseert. Vaststellen requirements en prioriteit van requirements vaststellen. Opdrachtgever beslist Projectmanager faciliteert, adviseert en registreert Ontwerp (Projectmanager is Adviseur) In samenwerking met de beoogde gebruikers opstellen van ontwerpspecificaties. Opstellen ontwerpspecificaties zoals bijvoorbeeld beschrijving van processen, schermen en gegevens. Een interactief prototype kan tot ontwerpspecificaties behoren. Opdrachtgever faciliteert Vaststellen ontwerpspecificaties Opdrachtgever beslist Projectmanager voert uit en adviseert Projectmanager faciliteert, adviseert en registreert Realisatie (Projectmanager is Leverancier) w Op basis van ontwerpspecificaties realiseren van de programmatuur. Realiseren en (technisch) testen van programmatuur Projectmanager voert uit Aan gebruikers beschikbaar stellen van programmatuur ten behoeve van testen Opdrachtgever faciliteert Testen programmatuur Opdrachtgever faciliteert en adviseert Projectmanager bewaakt Projectmanager voert uit Testen (Projectmanager is Adviseur) Programmatuur ter acceptatie aanbieden aan beoogd gebruikers. Projectmanager bewaakt Accepteren programmatuur Opdrachtgever beslist Projectmanager bewaakt en registreert Invoeren (Projectmanager is Leverancier) Ingebruikname van de programmatuur. In productie nemen programmatuur Opdrachtgever beslist Projectmanager levert > 10 adviseur naar leverancier. Als leverancier vergewist de projectmanager zich ervan dat de ter acceptatietest aangeboden programmatuur of onderdelen daarvan werken volgens de afgesproken ontwerpspecificaties. 10. Start met een plan van aanpak waarin de kwaliteit en het resultaat van de op te leveren programmatuur op adequate wijze is beschreven, zodanig dat de te leveren programmatuur meetbaar is en getoetst kan worden (rolverdeling: projectmanager voert uit; opdrachtgever faciliteert en beslist). 11. Voor zover dit niet in de leveringsvoorwaarden is IPMA Projectie Magazine | 01-2014 geregeld: Maak afspraken over het intellectueel eigendom en de toekomstige exploitatierechten. Maak afspraken over de vertrouwelijkheid van gegevens. Vrijwaar opdrachtgever voor schade als gevolg van inbreuk op de rechten van derden, bijvoorbeeld door hergebruik van bestaande (niet eigen) programmatuur (rolverdeling: projectmanager adviseert en voert uit; opdrachtgever faciliteert en beslist). 12. Documenteer wijzigingen op een adequate wijze zodanig dat de opdrachtgever de wijziging kan 13. 14. 15. 16. beoordelen en daarover kan beslissen. Actualiseer ontwerpspecificaties (rolverdeling: projectmanager adviseert en registreert; opdrachtgever beslist). Documenteer fouten en de oplossing daarvan op een adequate wijze zodanig dat van elke fout de status voor de opdrachtgever inzichtelijk en begrijpelijk is (rolverdeling: projectmanager registreert; opdrachtgever beslist). Voorkom misverstanden achteraf door een registratie waaruit blijkt dat de opdrachtgever heeft beslist over wijzigingen en over de afhandeling van fouten (rolverdeling: projectmanager registreert; opdrachtgever beslist). Toets of is geleverd zoals is afgesproken (conformiteit, zie 4) zie ook: Artikel 17, lid 2 BW (rolverdeling: projectmanager registreert; opdrachtgever beslist). Draag programmatuur(onderdelen) aan de hand van een protocol van oplevering over aan de opdrachtgever (rolverdeling: projectmanager voert uit en registreert; opdrachtgever faciliteert en beslist). Nota bene: Conversietrajecten zijn risicovol. Vervuiling van gegevens kan ervoor zorgen dat projecten aanzienlijk uitlopen en de nieuwe programmatuur na de ingebruikname (nog) fouten vertoont. Op voorhand onderkennen en evenwichtig verdelen van conversie risico’s tussen opdrachtgever en leverancier voorkomt problemen achteraf. 1.5 TESTEN 17. Het testen en accepteren van de programmatuur vindt plaats door de ‘eigen’ organisatie. Op basis van voortschrijdend inzicht kan de ‘eigen’ organisatie wijzigingen verlangen voordat programmatuur wordt geaccepteerd. Voorkom misverstanden achteraf door een registratie waaruit blijkt dat de opdrachtgever de programmatuur(onderdelen) heeft geaccepteerd (rolverdeling: projectmanager registreert; opdrachtgever beslist). 1.6 INVOEREN Na de ingebruikname van programmatuur wordt onderhoud op de programmatuur uitgevoerd. In een onderhoudsovereenkomst worden afspraken gemaakt over support, nieuwe versies en garanties. Een Escrowovereenkomst kan noodzakelijk zijn om de continuïteit van de verwerking te regelen. De projectmanager kan bij deze activiteiten zijn betrokken. De programmatuur kan echter ook zijn overgedragen naar de onderhoudsorganisatie van de opdrachtgever. 2 CONCLUSIE Het starten van de ontwikkeling van programmatuur vindt plaats op basis van een overeenkomst tussen een opdrachtgever en dienstverlener. De inhoud van de overeenkomst bepaalt de rechten en de plichten waaraan partijen dienen te voldoen. In de onderdelen requirements, ontwerp en testen (figuur-01) is de rol van projectmanager hoofdzakelijk die van adviseur (overeenkomst van opdracht, (art. 7:400 BW en verder). Art. 7:400 BW “De overeenkomst van opdracht is de overeenkomst waarbij de ene partij, de opdrachtnemer, zich jegens de andere partij, de opdrachtgever, verbindt anders dan op grond van een arbeidsovereenkomst werkzaamheden te verrichten die in iets anders bestaan dan het tot stand brengen van een werk van stoffelijke aard, het bewaren van zaken, het uitgeven van werken of het vervoeren of doen vervoeren van personen of zaken.” Bij het uitvoeren van zijn adviestaken moet de projectmanager voldoen aan de zorgvuldigheid en deskundigheid die van een redelijk handelend en bekwaam projectmanager geëist mag worden (gecertificeerd en voldoende ervaring). U wordt als dienstverlener aangesproken op uw professionaliteit (bent u gekwalificeerd om de overeengekomen arbeid uit te voeren?) en uw presentatie (welke verwachtingen zijn door u gewekt?). Voldoet de projectmanager niet aan deze eisen dan kan hij tuchtrechtelijk worden vervolgt. In de onderdelen realisatie en invoeren (figuur-01) wijzigt de rol van projectmanager van adviseur naar leverancier (overeenkomst van koop, art. 7:1 e.v. BW). [[Art. 7:1 BW “Koop is de overeenkomst waarbij de een zich verbindt een zaak te geven en de ander om daarvoor een prijs in geld te betalen.”]] De te leveren programmatuur moet voldoen aan wat is afgesproken in het ontwerp (conformiteitseis vastgelegd in art. 17, lid 2 BW7, zie punt 6 bij requirements). Misverstanden achteraf zijn te voorkomen door een adequate registratie waaruit de status van analyse, ontwerp en programmatuur(onderdelen) is te herleiden en hoe daarover door de opdrachtgever is beslist. 1. Jonker, L (2013, Mei 2013). Verantwoordelijkheden in IT-trajecten: wie schrijft, die blijft! Automatiseringsgids. Geraadpleegd http://www.holla.nl/mediamanagement/user/1222.pdf 2. TJ de Graaf - 2006, Zwaarte van de schuld – onder omstandigheden onaanvaardbaar. Geraadpleegd https://openaccess.leidenuniv.nl/bitstream/handle/1887/4411/04.pdf?sequence=26 3. W.F.R. Rinzema en B.T. Beuving (2001/6) Computerrecht: ‘Advies’ is niet altijd goed. 4. Reinout Rinzema, Computerrecht 2012/40 Kwaliteit en software: een goede zaak. Geraadpleegd http:// www.ventouxlaw.com/files/201204_Computerrecht_ Kwaliteit_en_software.pdf 01-2014 | IPMA Projectie Magazine 11
© Copyright 2024 ExpyDoc