JURIDISCHE VALKUILEN IN ICT

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

Download Report