Hoe kom je van een falend IT-project af?

fail-faal-it-project-altijd-kat.jpgDe op één na ergste openingszin in mijn inbox is toch wel “een tijd geleden zijn wij een IT-project gestart, maar…” Ik weet niet wat het is, maar het lijkt wel of elk IT-project gruwelijk faalt: gemiste deadlines, vele extra rekeningen (liefst terwijl een vaste prijs bedongen was), eindeloos gesoebat over specificaties, maandenlange vertraging bij oplevering en uiteindelijk de helft van de functionaliteit krijgen voor tien maal de prijs. Om dat juridisch op te lossen is geen pretje. Zeker niet omdat de meeste klanten denken “als het lang genoeg geduurd heeft en we nog steeds niets zien, dan trekken we de stekker eruit”. Maar zo werkt het niet.

Het grootste juridische struikelblok is dat opdrachtgevers in een IT-project maar laatste kansen blijven geven. De wet biedt je namelijk pas de gelegenheid een project te staken als de wederpartij “in verzuim” is, en daarvan is pas sprake als hij een fatale deadline heeft gemist of als hij in gebreke is gesteld. Beide opties zijn juridisch tot op alle punten en komma’s uitgeprocedeerd, en het verbaast dan ook niet dat het héél lastig om te bewijzen is dat hiervan sprake is. In een helder artikel (PDF) legt IT-advocaat Polo van der Putt duidelijk uit waar de juridische valkuilen liggen.

Eerst maar eens die “fatale termijn”. Daarmee wordt een deadline bedoeld die écht deadline is, oftewel missen daarvan is jou(w bedrijf) fataal. Essentieel daarbij is dat de wederpartij wist dat het om een fatale termijn ging. Dat de termijn belangrijk was voor jou, is niet belangrijk. Het klassieke voorbeeld van een fatale termijn is de bruidstaart: de bakker moet weten dat die voor de trouwdag wordt besteld, en een dag te laat is echt onaanvaardbaar.

Bij IT-projecten ligt dat iets anders. Daar is uitstel of iets latere levering eigenlijk altijd wel mogelijk. Immers, geen IT-project dat per se op je trouwdag af moet zijn. En werkt de IT-er met een beetje toegesneden algemene voorwaarden, dan is er nooit sprake van een fatale termijn, hoe belangrijk die voor de klant ook is. De voorwaarden definiëren dan simpelweg elke termijn als zijnde niet fataal, ongeacht mededeling van de klant. (Toegegeven, zulke voorwaarden schrijf ik ook.)

Van der Putt signaleert een vonnis waarbij de rechter het droogjes als volgt samenvat waarom IT-deadlines nimmer van niveau trouwdag kunnen zijn:

Dit te meer nu feit van algemene bekendheid is dat automatiseringsprojecten kunnen uitlopen, en uitlopen ook vaak plaats vindt.

Een rechter met IT-clue. Iedereen weet dat IT-projecten altijd uitlopen, dus iedereen moet snappen dat deadlines slechts bedoeld zijn als indicatieve termijnen – “ergens rond 27 mei zou leuk zijn, maar 19 september mag ook hoor”. Van een falende leverancier kom je dus niet af met het argument “u had 27 mei moeten opleveren en dat is niet gebeurd”.

De andere juridische boeg waar je het over kunt gooien is dat er niet correct geleverd wordt. De leverancier schiet tekort, juridisch gezegd. Dat kan een grond zijn om te ontbinden, maar dat bewijzen is moeilijker dan je denkt. Zeker als het gaat om toekomstige tekortkomingen, het “dit komt nooit meer goed”-argument:

Het zal in de praktijk niet eenvoudig zijn om voldoende aannemelijk te maken dat tekort zal worden geschoten. Doorgaans zal het de afnemer aan voldoende expertise en wetenschap ontbreken om aan te kunnen tonen dat correcte nakoming onmogelijk zal zijn. Bovendien zal, zeker bij langlopende projecten waar de leverancier nog een lange termijn heeft om te presteren, altijd wel een gezaghebbende expert gevonden kunnen worden die met kracht van argument kan betogen dat correcte nakoming wel mogelijk is.

Kun je wel bewijzen dat sprake is van een daadwerkelijke tekortkoming, dan is het mogelijk om het project te annuleren. Eis is dan wel dat de IT-er in verzuim is. De wet eist dan als hoofdregel dat hij in gebreke is gesteld. Dat wil zeggen: er is een tekortkoming gesignaleerd, de IT-er heeft een laatste kans gehad om het recht te zetten en ook daarna blijft het tegenvallen. In dat geval mag je als opdrachtgever opzeggen. Maar ook dat is moeilijker dan je denkt. Twee struikelblokken:

  1. Er moet een schriftelijke ingebrekestelling zijn verstuurd. Dat is een brief (geen mail) met daarin de toverformule “ik stel u bij deze in gebreke en eis dat u de hierboven gesignaleerde fouten herstelt”.
  2. De ingebrekestelling moet een redelijke termijn stellen voor het herstel van de fouten.

Te vaak denken opdrachtgevers dat het genoeg is te constateren dat er gefaald is en dat ze daarmee mogen opzeggen. Dat is dus expliciet niet zo. Evenmin is sprake van een ingebrekestelling als men geen uiterlijke termijn stelt, maar bv. alleen aanbiedt te gaan overleggen om te kijken wat er nog te redden valt.

Of te wel: zachte heelmeesters maken stinkende wonden. Een afnemer die meent dat er sprake is van een tekortkoming doet er verstandig aan om ook een termijn te stellen. Praten kan altijd nog.

Er zijn uitzonderingen op deze regel. Zo is een ingebrekestelling niet nodig wanneer de leverancier heeft gemeld dat hij niets meer gaat doen of als er lange tijd helemaal géén reacties komen op klaagmails. Of als de enige oplossing is om maar helemaal opnieuw te beginnen. Maar ik zou er niet op durven vertrouwen als ik de jurisprudentie erop nalees.

Met deze samenvatting doe ik Polo’s artikel nauwelijks recht, dus lees graag het gehele artikel: (Dreigende) tekortkoming en verzuim van IT-dienstverleners bij IT en Recht.nl.

Waar ik zelf dan nog benieuwd naar ben: waarom laten IT-klanten het altijd zo gierend uit de hand lopen met die projecten? Is het omdat IT moeilijk is en je geen idee hebt wat ze aan het doen zijn? Omdat je (vanwege de auteursrechten op de code) vast zit aan deze leverancier en je dus alle gelden kwijt bent als je opzegt? Of hebben IT-ers betere komtwelgoedpraatjes dan aannemers?

Arnoud<br/> PS: de voor mij ergste openingszin is “u bent mijn laatste hoop”, en ja die krijg ik zo eens per week.

33 reacties

  1. Wat hier niet genoemd word zijn kortings-clausules in het contract. Bijvoorbeeld dat er 10% korting gegeven word als er tot 1 maand te laat geleverd word, 15% tot 2 maanden enzovoort. Ik neem aan dat daar juridisch geen spijker tussen te krijgen is (behalve wanneer de klant te laat is met het geven van specificaties / feedback)

  2. De hardnekkige oorzaak van dit soort problemen ligt helaas wel ook voor een groot deel bij de klant: Verwachten dat voor een fixed price op basis van te summiere of juist te ver uitgewerkte (en mogelijk tegenstrijdige) specificaties echt gebouwd wordt wat je wil. Er is altijd voortschrijdend inzicht, en de truuk is om daar zo vroeg mogelijk rekening mee te houden en het project bij te sturen. En dat betekent (bijvoorbeeld) het gebruik van Agile development methodieken.

  3. VLDR heeft gelijk. Een complex stuk software implementeren staat eigenlijk gelijk aan het specificeren ervan. Bij vrijwel geen enkel (groot) project* kan een klant dus vooraf voldoende specificeren. Zou hij dat wel kunnen dan zou hij bijna ook de implementatieverantwoordelijkheid (deels) op zich kunnen nemen.

    Hier ligt dan ook het grote verschil met de bruidstaart waarbij het aantal variabelen (de ‘specificatie’) veel kleiner is.

    *mooie uitzondering hierop is natuurlijk een bestaand systeem precies opnieuw implementeren maar bijvoorbeeld in een iets andere technische context.

  4. Ik zie hier toch een beetje een cirkelredenatie: IT-projecten lopen uit omdat je de overeenkomst niet kunt ontbinden, want de rechter zegt je mag de overeenkomst niet ontbinden omdat algemeen bekend is dat IT-projecten vaak uitlopen.

  5. @Fred: Streng zijn naar je leverancier zou die cirkel moeten kunnen doorbreken. Maar ja, je hebt gelijk. Iedereen laat het maar begaan, en dat schept de verwachting dat leveranciers mogen begaan. Net zoals we accepteren dat standaardsoftware vol bugs zit en dat we nu eenmaal van tijd tot tijd gehackt worden.

  6. Ik heb projecten meegemaakt waar de oorspronkelijke specificatie 20 pagina’s was, maar een maand na start komt er ineens 1000 pagina’s specificatie los. Rara wat dat doet met de plannen – alleen het nauwgezet lezen is al een ruime maand vertraging…

    Zelden is een project vrij van wijzigingen in de specificatie, of is de specificatie volkomen helder. Zelden komen er geen wijzigingen na een eerste ronde van feedback…

    En software is altijd wijzigbaar, toch? Als de fundering van een weg eenmaal ligt, roep je niet meer dat je toch graag een tunnel had gewild. Ik heb projecten meegemaakt waar halverwege een project de klant ineens komt vragen of misschien beter zou zijn en of we dat er ook even bij willen doen. Niet dus.

  7. Ik zie toch vaak dat er geen duidelijke omschrijvingen, deadlines en vereiste functionaliteiten in contracten genoemd worden. Ook zie je bijna nooit het principe van deelopleveringen waarbij pas betaald wordt als een deel van het project geaccepteerd wordt door de klant. Doordat de leverancier vaak het grootste gedeelte van het geld al vooraf krijgt, of per maand een bedrag, is er voor de leverancier geen haast meer om volgens wens van de klant op te leveren.

    Veel leveranciers zijn ook bewust vaag of summier in de omschrijving van de geleverde dienst, zodat ze onder de kostprijs kunnen offreren en de aanbesteding winnen. Door het onvermijdelijke meerwerk tegen een vorstelijke beloning, halen ze alsnog hun winst uit het project, want de klant wil uiteindelijk een werkend systeem en zit dan al vast aan de leverancier en het contract. Wat dat betreft wijkt de ICT weinig af van de bouwsector.

  8. Lijkt me inderdaad wat VLDR en Paul zeggen. De klant wil iets, het project wordt daarop uitgerekend. Na een tijdje heeft iemand door dat het project bezig is en maakt de opmerking “en hoe zit het dan met X?”, “zou het niet handig zijn als Y?”, “en Z doen we dus niet meer aan?”. En alles moet worden aangepast…

    Om in de vergelijking te blijven. Men besteld een taart die 3 dagen kost om te maken. Twee dagen voor het huwelijk vraagt vader of er ook noten in de taart zitten, want die mag hij niet. Taart moet opnieuw gebakken worden en die deadline kan je wel vergeten. Vervolgens merkt een oom op dat het huidige formaat niet eens door de deur kan, dus doe maar opnieuw.

    Met een taart zijn genoeg praktische oplossingen te bedenken. Een gebakje voor vader en de taart in de andere kamer snijden. Maar een IT-project voor een bedrijf moet gewoon goed zijn, anders doet het enkel meer schade dan goed. Dus blijf je uitstellen als men van te voren niet nadenkt. Maar een organisatie is complex, en er zijn honderden uitzonderingen, dus dat gaat je (haast) nooit lukken.

    En als het dan fout gaat, mailen we onze laatste hoop, Arnoud! En als het dan fout gaat, stellen we Arnoud aansprakelijk voor zijn advies! 🙂

  9. ICT’ers zijn in essentie gewoon oplichters die zaken beloven waarvan ze van te voren al weten dat ze die niet waar kunnen maken.

    Daar zijn allerlei oorzaken voor. ‘ Ik denk dat de belangrijkste oorzaak ligt in het feit dat ICT’ers totaal geen feeling lijken te hebben met de normale bedrijfvoering van organisaties terwijl de organisaties onvoldoende ICT kennis hebben om hun wensen goed over te brengen. Een andere groot probleem is de beheersbaarheid van ICT projecten. ICT’ers hebben eingelijk belachelijk veel input nodig want anders doen ze vaak maar maar wat en dat werkt zolang je in kleine teams zit met korte communicatielijnen en veel gebruikersparticipatie. Juist grote projecten zijn daarom vaak belachelijk kostbaar en gevoelig voor mislukken. En als je alles in kleine projecten doet krijg je ICT chaos van tientallen zo niet honderden ICT eilandjes die totaal niet op elkaar aansluiten.

  10. Even offtopic 🙂

    De HTML van je de laatste regel word niet goed afgesloten. Ik gebruik even [] als voorbeeld, zodat hij het als tekst neemt. [small]PS: de voor mij ergste openingszin is “u bent mijn laatste hoop”, en ja die krijg ik zo eens per week.[/p]

    Alle tekst na deze regel is aanzienlijk kleiner.

  11. Helder artikel, waarvoor mijn hartelijke dank!

    Uit eigen ervaring sprekende: Een opdrachtgever heeft vantevoren meestal geen exact heldere blik over wat het eindproduct moet kunnen. Er worden dan ook te weinig concrete afspraken gemaakt over (exacte) functionaliteit van het op te leveren (of dat nu een product of dienst is). Daarnaast hebben erg veel ICT’ers de neiging om voorbij te gaan aan de exacte eisen van opdrachtgevers en bedenken zij altijd wel iets waardoor het product uiteindelijk toch even iets anders wordt. Opzich is het ook wel begrijpelijk, als ik je vraag om een glas mee te nemen is onduidelijk wat voor glas ik bedoel en zou ik het glas wat ik verwacht te krijgen beter moeten omschrijven. Perceptie dus.

    Beide gegevens leiden tot het niet voldoen aan de verwachtingen van de opdrachtgever en dus een escalatie. Enige wat echt helpt is erg duidelijke afspraken maken aan de te leveren dienst of product, dit tot in detail uitwerken en nauwkeurig volgens die eisen opleveren….

    Noot: Rijkswaterstaat laat de laatste 7 jaar het idee van nauwkeurig omschrijven juist heel erg los. Zij geven een opdracht (gechargeerd: bv: bouw een tunnel) en de opdrachtnemer moet maar zien hoe hij het doet. Dat heeft als voordeel een enorme tijdsbesparing aan beschrijvingen, als nadeel dat het eindproduct soms niet helemaal is zoals de opdrachtgever het zich voorgesteld had.

  12. Er zijn een aantal problemen die geconstateerd kunnen worden.

    Het eerste speelt al bij de eerste onderhandelingen. Die worden namelijk niet door een ICT’er gevoerd maar door een sales representative. Iemand die dus onvoldoende weet wat zekere eisen concreet zullen betekenen aan werklast. “Even een knopje erbij” kan betekenen dat iemand de gehele code moet herschrijven (bijvoorbeeld omdat een tijdelijke variabele is gebruikt terwijl hij dan toch voor langere tijd opgeslagen moet worden). Terwijl de sales representative een boom met tak en schommel belooft voor 100 euro, zegt de achterban dat ze ?f een boom kunnen leveren voor 100 euro, ?f boom met tak voor 200 euro, ?f boom met tak en schommel voor 400 euro.

    Het tweede probleem zit, zoals anderen al aangaven, in de flexibiliteit van de ICT’ers. Als opeens blijkt dat kleurenblinden ook het programma moeten kunnen gebruiken, is dat meestal geen probleem. Dit levert echter wel problemen op: programmeurs maken of op langzaam tempo hele goede code, of in snel tempo best slechte code. XKCD spreekt hier boekdelen: http://xkcd.com/844/

    Een derde probleem zit hem bij de klant. Ik werkte in een zorginstelling waar een nieuw klanten registratiesysteem moest komen. De onderhandelingen zijn gevoerd door onze ICT medewerker, zonder vertegenwoordiging van de mensen die het systeem werkelijk zouden gaan gebruiken. Hierdoor is het niet duidelijk waar de prioriteiten horen te liggen en kregen we uiteindelijk een systeem waarmee je heel veel mee kon… maar maar 10% nodig had. Net die dingen die echt nodig waren ontbraken, en de grote hoeveelheid opties maakte het alleen maar onnodig ingewikkeld.

    Een vierde probleem zit hem in geld. Als je een goed systeem bouwt dat iedereen kan onderhouden, zal je klant geen onderhoudscontract nodig hebben. Als alles op tijd af moet zijn, dan werk je altijd met reserves in tijd; als 30% te laat mag zijn, werk je financieel het effectiefst als net onder de 30% te laat is.

    Een laatste probleem zit hem in het feit dat je sneller een product in de praktijk kunt testen. Het is veel sneller om in 1 uur een slecht programma te schrijven dat je in 9 uur, met input van fouten in de praktijk, verbetert, dan dat je in 100 uur een perfect programma schrijft. Daar komt bij dat je niet alles voor alle gelegenheden perfect hoeft te maken. Een kleine tabel met leerlingen namen hoeft niet erg ingewikkeld gemaakt te worden, totdat… http://xkcd.com/327/ . Dit alles wekt de schijn op dat er veel vertraging is; in plaats dat een programma na 2 jaar geleverd wordt, wordt het al na 1 jaar geleverd, wordt een jaar lang in de praktijk getest waarbij er nog steeds constant aan geknutseld wordt.

    Kortom, er is weinig interne communicatie bij de ICT’er, en ook bij de klant. De klant verandert heel vaak van mening over hoe het programma er uit moet gaan zien en wat het moet kunnen. Het is financieel beter om niet alles op tijd af te krijgen (voornamelijk omdat we nu accepteren dat het niet hoeft), en programma’s zijn sneller af als ze in de praktijk worden getest dan daarbuiten.

    Het is een combinatie van deze factoren dunkt mij wat ervoor zorgt dat ICT projecten zo vaak uitlopen en dat de kwaliteit nooit zo hoog is als je zou willen.

  13. Het is zo gemakkelijk voor IT-projekten om te vertragen of te falen omdat er zoveel incompetente mensen bij betrokken zijn. Heb je als bedrijf het geluk dat je goede programmeurs in dienst hebt, wordt hun efficiency ondermijnt door hun incompetente manager. Of moeten ze verplicht samenwerken met mensen die de hele dag systemen ‘ontwerpen’ en dus geen verstand van zaken hebben. En dan heb ik het nog niet eens gehad over de salesafdeling of de klant zelf.

    Een paar maanden op zo’n manier werken en de goede programmeur heeft elders een baan gevonden. En dan moet het bedrijf mensen aannemen die minder nuttig zijn. Enzovoorts..

    In het kort: het probleem is incompetentie. En als er 1 schakel zwak is…

  14. Als grote projecten falen dan komt dat omdat je op de verkeerde manier werkt. Eerst een pak documentatie maken wat het product moet kunnen, daarna een leuk design maken, daarna pas beginnen met programmeren en als je d?n past begint met testen, ben je al minstens een jaar te laat en zijn de eisen al weer helemaal anders.

    Daarnaast heb je beperkte resources (budget en tijd) tegenover deliverables (functionaliteit en kwaliteit).

    Wat je ook kunt doen, is direct beginnen met het maken en testen van het product, vanaf dag 1. Natuurlijk weet je niet wat ?lle eisen zijn, maar dat doet er ook niet toe. Het doel is om zo snel mogelijk een initi?le versie te hebben waar gebruikers doorheen kunnen klikken. Je werkt in zogenaamde iteraties van een maand, twee weken, of whatever. Vooraf elke iteratie spreek je af wat er ge?mplementeerd wordt en na elke iteratie wordt dit gepresenteerd (en getest door de klant).

    Het aller-aller-aller belangrijkste is (tussentijdse) feedback. Zonder feedback van de klant zijn programmeurs nergens. Hoe later je feedback levert, hoe moeilijker (en duurder in budget/tijd) het is om je product te wijzigen.

    De klant heeft dus ook een verantwoordelijkheid. Deze moet zorgen dat er continu (elke iteratie) gebruikerstesten plaatsvinden. Daarnaast heeft de klant de verantwoordelijkheid om nieuwe functionaliteit te omschrijven en te prioriseren. Hij kan (en moet!) dus ook de prioriteiten bijstellen wanneer nodig. Als de klant dus meer functionaliteit wil, dan verschuift dus ook de deadline; wil hij toch minder functionaliteit, dan verschuift de deadline dus ook.

    Een inschatting van de tijd nodig per functionaliteit wordt door de programmeurs gedaan, dat zijn namelijk de enigen die weten hoe lang iets daadwerkelijk duurt. Gebaseerd daarop kan de klant bepalen of hij wil betalen voor die functionaliteit of niet; of dat het eenvoudiger kan en dus goedkoper wordt/minder tijd kost.

    Ik kan iedereen aanraden die erin gelooft dat je vantevoren alle eisen helder moet hebben en dit in een 100-pagina’s groot document moet neerzetten om eens te zoeken naar ‘agile software development’ en dan specifiek naar ‘Scrum’, zoals ook VLDR aangaf.

    Ik werk dus voor een software leverancier en wij hebben dus nooit falende projecten. Maar dat zal wel toeval zijn.

  15. De oplossing is zoals altijd: 80% ontwerptijd. 10% ontwikkel en 10% test. En na die eerste 80% zijn er geen wijzigingen meer mogelijk…….

    Maar ja, ik moet de eerste opdrachtgever nog vinden die daarmee accoord gaat.

    Of wat van der Hoorn zegt, maar daar moet de opdrachtgever ook zin in hebben. EN fixedprice gaat je ook niet lukken op die manier…

  16. Agile is lang niet overal geschikt voor. Het werkt (net als RAD en RUP) vooral op systemen die qua functionaliteit erg afhankelijk zijn van overzichtelijke zaken als userinterfaces en usecases en vereist bovendein een nog hogere participatie van de klant als normaal terwijl dat juist vaak een groot probleem is.

  17. Een echte deadline die ik bij een aantal projecten heb meegemaakt is de ingangsdatum van een wet. Als de wet van kracht wordt, moet ook de ondersteunende software in productie gaan. Als je als ICT-leverancier dan te laat oplevert, komt de klant voor enorme kosten te staan omdat hij (tijdelijk) een andere oplossing moet implementeren, bijvoorbeeld het inhuren van een legertje uitzendkrachten.

  18. Wat vreemd dat het bruidstaart-principe nergens op gaat bij IT projecten. Hoe zit het met situaties waarin: -support van de oude oplossing vervalt; -licentie verloopt, dus nieuwe oplossing laten maken of oude met een onredelijke lange en dure termijn verlengen; -IT project moet af zijn v??r de verkoop (of aankoop) van een bepaald bedrijfsonderdeel; -Oplossing moet af zijn om op tijd de aanbesteding voor opdracht xx te kunnen winnen, waarbij de IT oplossing van cruciaal belang is.

    In deze situaties, die ik zo even verzin maar niet ondenkbaar zijn, is toch duidelijk te spreken van ‘het project moet af zijn, anders is het niet meer zinvol’, of zorgt het in ieder geval voor aantoonbaar gederfde inkomsten.

  19. Agile is niet voor alle projecten geschikt (Welke supermarkt koopt een kassasysteem dat nog niet werkt voor de verswaren?). Zelfs als je Agile methoden (zoals het opleveren van functionaliteit in deelstappen) gebruikt, moet de fundering die je aan het begin van het project legt goed ontworpen zijn, zodat de uiteindelijke applicatie solide in elkaar zit.

    Mark, mijn vuistregel is 40% ontwerp, 30% ontwikkel en 30% testen, met de aantekening dat fouten in het ontwerp een orde (factor 10) duurder zijn om te verhelpen dan fouten door de ontwikkelaars gemaakt.

    Wat zijn oorzaken van hoofdpijn IT projecten? * De gebruikers niet betrekken bij de specificatie * Teveel functionaliteit vragen * Complexiteit onderschatten * Verkeerde platformkeuze * Tussentijdse specifcatiewijzigingen * Niet of onvoldoende planning * Onvoldoende volgen van de projectvoortgang * Fundamentele fouten in het ontwerp (onvoldoende QA op ontwerp) * Incompetentie van de implementators (Ik weet vrijwel zeker dat de lijst niet compleet is.)

    Een (juridische) methode om als opdrachtgever beter de vinger aan de pols te houden is “deelleveringen” af te spreken: je maakt met je leverancier een plan waarbij de leverancier iedere maand een afgesproken stuk functionaliteit oplevert (geef hem wel de tijd om een goed ontwerp te maken). De opdrachtgever test iedere oplevering. Maak betaling afhankelijk van leveringen en acceptatie.

  20. Arnoud, even een juridische nitpick.

    Moet de term die je onder de opsomming 1 en 2 gebruikt niet zijn: ‘ontbinden’ (na verzuim en een tekortkoming etc.) in plaats van ‘opzeggen’, want die laatste term betekent juridisch iets anders (en is los van een tekortkoming altijd mogelijk, denk aan 7:408 BW of 7:764 BW).

  21. @MathFox: Agile betekent zeker niet dat je een onaf product (bijv. een kassasysteem) in productie gaat gebruiken. Dat zou ook nergens op slaan.

    Grootste probleem waar wij tegenaanlopen als IT-organisatie: * Incompetentie van de ontwerpers * Te laat in het proces worden betrokken, waardoor de deadline heel krap is

    Die deelleveringen waar je het over hebt, dat is juist wel agile. Het voordeel daarvan is, mits je dat goed afspreekt (i.e. wie is eigenaar van de software), dat je als opdrachtgever ook tussentijds naar een andere leverancier kunt als je dat zou willen. Je hebt immers tussentijdse werkende versies.

  22. @Mark: Inderdaad, je gaat dan ontbinden volgens de wet. Had ik even te makkelijk geformuleerd voor de leesbaarheid. En van 7:408 BW mag je bij algemene voorwaarden afwijken (behalve bij consumentklanten, 7:413 lid 2 BW).

    Praktisch punt is wel dat als je opzegt, je niets kunt met het resultaat en je wel je geld kwijt bent.

  23. Interessant artikel en discussie! Zou een oplossing kunnen zijn als de opdrachtgever meer via deelprojecten werkt? Dus niet meteen een compleet eindresultaat willen, maar eerst een opdracht (die de opdrachtgever eigenlijk zelf zou moeten) als ‘formuleer de eisen waaraan een nieuw systeem moet voldoen’. Daarna een nieuwe gunning ronde voor de tweede fase: ‘wat is nodig om aan de eisen van fase 1 tegemoet te komen’. Vervolgens weer een nieuwe fase, uiteindelijk resulterend in een opdracht voor daadwerkelijke ontwikkeling en testen van een ict-systeem.

    Maar nu ik dit opschrijf komt deze methode me erg tijdrovend en (dus) ook duur over…

  24. Het grootste juridische struikelblok is dat opdrachtgevers in een IT-project maar laatste kansen blijven geven.

    En het grote struikelblok van de traditionele waterval-methode van IT-projecten is dat dit onontkoombaar is. Betere specificaties schrijven is dan juist niet de oplossing. Men kan van een IT-project niet schatten wat de nieuwe inzichten van klanten en developers zijn over een maand. Stel je duidelijke milestones per fase en hou je de klant niet constant in een feedback loop bij elke fase van ontwikkeling, dan onstaat er deadline stress, vertraging tussen fases en functionaliteiten die niemand gebruikt: Meer dan de helft van features worden zelden tot nooit gebruikt en dragen niet toe aan de business value van een project product.

    Een klant weet vooraf niet wat hij/zij wil, dit ontdekt hij/zij tijdens het project. Een developer weet vooraf niet hoe hij/zij het project gaan uitvoeren tot op de byte, hij/zij ontdekt shortcuts, raakt geinspireerd, luistert naar de gebruikers en vindt de meest effectieve technologie. Inspiratie gooit roet in het eten van voorspelbaarheid: Of een inspiratieloos voorspelbaar project, of een geinspireerd “onvoorspelbaar” project. Picasso kon ook niet precies zeggen hoe een schilderij ging worden, technologie developers zijn in die zin gelijkend op artiesten.

    Hoe kom je van een falend IT-project af? Door voortaan alleen Agile/Lean projecten uit te besteden. Hard itereren tot het project slaagt, en niet pas achteraf erachter komen dat het project faalt en dat er nieuwe specificaties moeten worden geschreven met wat factuurtjes erbij. Als er iemand goed is geworden in het extraheren van steeds meer geld dan zijn het wel de bedrijven, die jarenlang met waterval projecten hebben gewerkt. Zij die weten hoe je een SLA schrijft die gunstiger is voor bedrijf, dan voor de klant. Het traditionele development proces is nog te veel blackbox, klanten kunnen pas te laat corrigeren. En als die blackbox 95% af is, zo zegt de projectleider, dan geef je wel een laatste kans (of 3).

    Agile is niet voor alle projecten geschikt (Welke supermarkt koopt een kassasysteem dat nog niet werkt voor de verswaren?). Zelfs als je Agile methoden (zoals het opleveren van functionaliteit in deelstappen) gebruikt, moet de fundering die je aan het begin van het project legt goed ontworpen zijn, zodat de uiteindelijke applicatie solide in elkaar zit

    Een scrum team en een stand-up meeting voor non-IT supermarkt medewerkers: Wat heb je gisteren gedaan? Wat ga je doen vandaag? Waar loop je tegen aan? zou heel goed werken.

    Voor de ontwikkeling van een kassasysteem is Agile juist enorm geschikt. Zodra je een werkend prototype hebt, hoef je dat niet meteen te implementeren, maar kun je wel alvast User en Customer feedback ontvangen. Dan weet je tijdens en niet pas achteraf tijdens het testen, dat appels wegen aan de kassa, minder effectief is voor korte rijen dan appels wegen op de groenteafdeling.

  25. moet de fundering die je aan het begin van het project legt goed ontworpen zijn

    De fundering voor een project in Scrum is de Product Backlog. Deze is ontworpen door de Product Owner. Een Agile blik leert dat projectontwerpen in de werkelijkheid dynamische objecten zijn, ipv statisch en bindend. Traditionele wrijving ontstaat wanneer een klant de specificaties wil wijzigen — in Agile worden verandering en nieuwe inzichten juist verwelkomt. Immers een feature die aan het begin van het project waardevol leek, kan door marktwerking tijdens het project waardeloos worden. Agile doet er alles aan om de productkwaliteit te verhogen op een kosteneffectieve manier.

    Traditioneel: Klant dicteerd specificaties: Ik wil een speaker die MIDI-tonen speelt als een product word gescanned. Specificaties: Externe MIDI-speakers gekoppeld aan het systeem, 12 uur. Product is af, klant hoort de toon en vind het maar niets: Klant wil MIDI tonen kunnen wijzigen, maar dat was niet opgenomen in de specificaties, en kost dus een extra 8 uur.

    Agile: Klant schrijft user story: Als een marketeer, wil ik dat de kassa geluid produceert als een artikel wordt gescanned, omdat dit bijdraagt aan de ervaring en feedback geeft aan een winkelganger.

    Developer pakt dit op: De scancomputer bevat reeds een speaker, bij dit prototype kunt u horen wat dit voor toon geeft. De speaker is reeds gekoppeld aan het systeem.

    Klant geeft feedback: De toon is te fel en scherp, is dit mogelijk om goedkoop aan te passen?

    Developer: Ja, maar eenmalig, als u de juiste toon aanlevert, dan kan ik het implementeren in het product. Over feedback aan winkelgangers gesproken: de kassanummering zou kunnen gaan branden, zodra een kassiere inlogt, die mogelijkheid is reeds ingebouwd.

    Resultaat Agile: Een goedkoper, beter, klanttevreden, minder bloated, meer waardevol product, met een basis niet in een ellenlang statisch bindende specificatie, maar in een dynamische specificatie die beter werkt met veranderingen en zich vormt naar de nieuwe inzichten en werkelijke wensen.

  26. Ik heb het artikel van Van der Putt proberen te doorgronden, maar 1 ding is mij niet helemaal duidelijk. Stel, je zit in de fase dat je aan je leverancier een ingebrekestelling stuurt. Wat schiet je daar mee op als klant? Immers, je bent bezig om van het project af te komen, maar dan ben je ook meteen het reeds betaalde voorschot-bedrag kwijt.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.