Managed hosting door True

Falen ICT-project is moeilijk bewijsbaar

Het is voor opdrachtgevers verre van eenvoudig om juridische actie te ondernemen wanneer een ict-dienstverlener faalt bij de uitvoering van een ict-project. Om tussentijds een ict-project te kunnen ontbinden en bijvoorbeeld schadevergoeding te ontvangen voor geleden schade, moet aan 'behoorlijk wat' voorwaarden worden voldaan. Dat schrijft ict-jurist Polo van der Putt in een artikel op de website IT en Recht.

'Veel ict-projecten lopen uit, kosten meer dan begroot of leveren niet de gevraagde functionaliteit', schrijft van der Putt. 'Vaak vertoont een project al tijdens de rit de eerste tekenen van mislukking. De wet biedt de afnemer dan soms de mogelijkheid om er tussentijds uit te stappen.' Aan deze 'voortijdige ontbinding zijn echter behoorlijk wat voorwaarden ontbonden, zo legt de ict-jurist uit. Dat geldt overigens ook wanneer de afnemer de opleverdatum wel afwacht.

Dit alles komt doordat rechters volgens de ict-jurist 'in het geval van ict-overeenkomsten een eigen invulling hebben gegeven aan het wettelijke systeem voor nakoming en tekortkoming.' Daardoor kunnen juristen volgens Van der Putt hun cliënten pas goed verdedigen wanneer ze op de hoogte zijn van de 'relevante jurisprudentie'. 'Anders kan plotsklaps blijken dat fatale termijnen toch niet fataal zijn, ingebrekestellingen geen rechtsvervolg hebben of dat een nakomingsbevestiging soms niet volstaat.'

Verzuim aantonen is lastig

De ict-jurist geeft in zijn artikel een aantal waarschuwingen aan medejuristen en afnemers. Ten eerste moet een opdrachtgever tijdig actie ondernemen. 'Als een afnemer niets doet wanneer de leverancier te kort schiet, kan hij het recht verliezen om zich later nog op tekortkoming te beroepen.'

Ten tweede moet dit op de juiste manier gebeuren. De opdrachtgever moet 'verzuim' aantonen, wil hij in zijn recht staan. Maar: 'Hoofdregel is dat verzuim pas intreedt nadat de schuldenaar een herkansingspoging heeft gehad en opnieuw heeft gefaald.'

Belangrijk is bovendien dat bij die herkaningspoging een termijn wordt gesteld. Van der Putt haalt een uitspraak aan van een rechter uit 2009 in een geschil tussen Fortis en ict-dienstverlener Raindrop, waarbij de rechter twee door Fortis gestuurde brieven niet wil aanmerken als ingebrekestellingen, omdat er geen termijn in wordt gesteld.

SAP

Daarnaast moet de ingebrekestelling 'de verweten gebreken met voldoende detail te beschrijven.' Van der Putt verwijst daarbij naar een rechtszaak van Waterdrinker tegen SAP. Omdat de kamer- en tuinplantenleverancier in een brief niet specifieert wat exact het probleem is, weigert de rechter 'ingebrekestelling' vast te stellen.

De opdrachtgever schrijft volgens Van der Putt namelijk aan SAP dat 'de geconstateerde tekortkomingen mogelijk nog te verhelpen zijn, maar dat Waterdrinker wegens een gebrek aan vertrouwen kiest voor beëindiging van het project.' De rechter ziet daarom geen aanleiding om te constateren dat er sprake is van 'een blijvende onmogelijkheid van nakoming'.

Dit artikel delen:

Reacties

Ik snap het niet. Er is voor ieder project toch een contract opgesteld? Waarin duidelijke grenzen voor tijd, budget en resultaat worden opgenomen? Als je daar overheen gaat, dan weet je: dan doe je iets niet goed. Les een van projectmanagement gaat over het opdelen van projecten (staging) om de afzonderlijke delen zoveel mogelijk in de hand te houden. Kennelijk worden tijd- en budgetoverschrijdingen niet gemeld of opgelost in een projectdeel maar meegenomen naar het volgende. Hetgeen helemaal in gaat tegen alles wat we geleerd hebben. Vind je het dan gek als elk project uit de hand loopt?

Kennelijk is aanbesteding bij overheidsprojecten tegenwoordig iets van zo laag mogelijk inschrijven, want als het uit de klauwen loopt past de overheid toch wel bij.

@Henk:
Welkom in de real-world!
Bij een project van een paar duizend euro zijn specificaties nog sluitend op te stellen, maar de kosten en complexiteit van dit soort systemen zijn te groot om een sluitende beschrijving te hebben.

Als je specificaties en contracten 1:1 gaat volgen wordt niemand blij. De klant krijgt een waardeloze bende omdat er vast ergens een functionaliteit vergeten is te beschrijven. (Oeps, een order kan niet meer gewijzigd worden) En de leverancier is enorm veel tijd kwijt om te beschrijven wat standaard is (Met het pijltje omhoog kan de waarde van het aantal met 1 verhoogd worden...)
Uiteindelijk komt hier een middenweg in, en dan is het lastig om te bepalen wat een "ordersysteem" nu exact inhoud voor de klant en leverancier. Zeker als er tientallen koppelingen en tientallen mensen betrokken bij zijn.

Jij koopt jouw auto natuurlijk ook met de complete specificatie erbij: TERUG! de fuseekogelrubber is grijs ipv zwart... Ik koop zelf een auto die rijdt, omdat ik niet 10x zoveel voor een auto wil betalen omdat de volledige specificatie moet worden doorgenomen voordat ik teken.

O ja, het gaat hier trouwens helemaal niet over overheidsprojecten, maar in het algemeen.

Een belangrijke vraag is natuurlijk in hoeverre het altijd duidelijk is dat de dienstverlener faalt. Ik ken voorbeelden waarbij een contract werd gesloten maar de opdrachtgever onvoldoende duidelijk kon aangeven wat hij nodig had. Verder geven opdrachtgevers vrijwel nooit de gehele sturing uit handen aan een leverancier en zullen zijn zelf ook zaken moeten regelen.
Eigenlijk zijn met name aanbestedingen hierin schijnzekerheid. De klant kan nooit exact beschrijven wat hij wil hebben en de leverancier kan nooit met zekerheid beloven dat hij dit kan leveren binnen de beoogde tijd. En toch blijven wel telkens doen alsof dat wel het geval is, terwijl er toch diverse voorbeelden zijn die het tegendeel bewijzen.

Een mooi voorbeeld is het ICT project 'Joint Strike Fighter'... Uitstappen ho maar, kan niet meer, is de leverancier in gebreke?? Ik betwijfel het.
Op kleinere schaal worden ook projecten gestart waarbij de allernieuwste applicaties en systemen moeten worden geïmplementeerd, waarvan niet eens de meest basale bugs en comptabiliteit vraagstukken bekend zijn (die worden alleen bekend door je op nieuw terrein te gaan bewegen).
Wel denk ik dat de commerciële kant van de markt vaak nalaat op die risico's in te gaan naar een klant. En veel opdrachtgevers willen dat ook helemaal niet horen, en zo draait de cirkel lekker rond.....

Het falen is doorgaans niet zo moeilijk te bewijzen, anders moeten alle partijen hebben zitten te slapen. Als het mis gaat, dan ligt dat meestal aan beide kanten en is er ook (directe en indirecte) schade aan beide kanten. De vraag hoe groot de schade aan beide kanten is en hoe de schuld verdeeld zou moeten worden, is meestal moeilijker te beantwoorden. Daar kom je alleen uit door vanaf het begin helder te communiceren. Hoe slechter je dat doet, hoe groter de totale schade.

Zeker als partijen tegenover elkaar zijn komen te staan, werkt men te veel vanuit de eigen denkwereld. Maar contracten gelden niet alleen voor het moment dat de samenwerking leverancier-klant nog goed verloopt, maar juist ook voor als het mis gaat. Tezamen met de wetgeving (die soms leidend en soms aanvullend is) bepalen zij hoe gehandeld moet worden om nog meer schade te voorkomen.
De aanbevelingen van Van der Putt zijn goed. Ga er nooit vanuit dat de rechter dezelfde denkbeelden heeft over redelijkheid en billijkheid als jijzelf.

Ik moest weer eens denken aan een oud project waar ik bij betrokken was.
Daar werd getest met een stopwatch in de hand. En ook als de oplevering te laat was kwam er een ton boete per dag bij.
Heel vreemd genoeg liep dat project redelijk soepel.

als ik contraexpertises doe kijk ik mede naar de gevolgde ontwikkelaanpak. wat deed men eerst, wat deed men na elkaar dan wel naast elkaar. en spiegel dat een door veel ervaring ontwikkeld referentiekader.
dan is het niet meer moeilijk om aan te tonen waar een project begon te ontsporen. voorbeelden van grote projecten en ook dat referentiekader heb ik beschikbaar. en datzelfde referentiekader gebruik ik ook proactief.
dagblad trouw heeft al eens enige woorden gewijd aan deze aanpak, maar de doorbraak moet nog komen.

Ik kan boekdelen vol schrijven met schrijnende voorbeelden van falende ICT-projecten bij de overheid. Hiermee gaan miljoenen verloren, zonder dat daar iemand voor verantwoordelijk wordt gesteld.

Gezamenlijk het probleem te lijf gaan... dat voorkomt een falend project. En waarom vragen afnemers in de IT eigenlijk niet om garanties?

Iedereen met niveau vanaf prince2 foundation kan een project opzetten dat niet kan falen.
Het gaat erom om fasen te plannen waarbij je na afloop de tussenresultaten steeds tegen de Business Case toetst.

Het is de taak van de Project Manager om dit plan op te stellen en van de Business om hiervoor mandaat te geven. Het gaat mis als minstens een van die partijen prutser is en de ander dat accepteert (in feite dus beide prutser :-)

CasperD, 12-01-2011 15:00: Het zal me aan mijn aars oxideren welke kleur de rubber rond de fuseekogel heeft. Maar als ik een auto bestel met airco en die zit er bij levering niet in, dan heeft een of andere pipo zijn werk niet goed gedaan. En als de kleur van de lak anders is dan besteld, is er gewoon niet aan de voorwaarden van het contract voldaan. Daar heb je nu eenmaal een contract, een PID enz. voor.

Zoals met elk project gaat het niet om gemierenneuk, maar enorme tijd- en budgetoverschrijdingen zijn dermate basaal dat je daar echt niet meer van kan spreken.

En dat van de overheid was maar een voorbeeld.

Helaas is dit artikel gebaseerd op de werkelijkheid zoals die in 'onze' ICT wereld de overhand heeft.
Overeenkomsten zijn heel vaak standaard ICT-Office contracten (inspanningsverplichting en fitness for specification) terwijl als onderwerp van aankoop de licenties van de software met aanvullend maatwerk worden genoemd. Als bijlage en beschrijving van de leveringsverplichting wordt doorgaans de offerte van de leverancier gebruikt.

Op deze manier is het voor de leverancier heel goed mogelijk om met een goed gevoel van comfort een scherpe aanbieding te doen, om zodoende de concurrentie voor te blijven.

Voor de afnemer is een dergelijke constructie desastreus. En wel om de volgende reden.
1. De verplichting van de leverancier beperkt zich tot het doen van een inspanning (uren budget);
2. De leveringsverplichting is omschreven in ‘termen’ van de leverancier, die daar een eigen uitleg aan kan geven;
3. Zodra hij vindt dat de specificaties zijn gehaald, ligt de bewijslast van eventuele ontbrekende of foutieve onderdelen bij afnemer (door de inspanningsverplichting).

Directies van bedrijven die grote ICT-projecten wensen te gaan doorvoeren, doen er goed aan om passende overeenkomsten (maatwerk) op te (laten) stellen. Randvoorwaarden waar een passende overeenkomst aan moet voldoen zijn o.a.:
1. Resultaatverplichting (fit for use of fit for purpose);
2. Onderwerp van levering moeten de overeengekomen specificities zijn (géén verwijzing naar producten van de leverancier, maar naar bedrijfsprocessen van de afnemer);
3. Heldere afspraken over wijzigingen, escalaties, acceptaties, projectmanagement;
Verder moet de afnemer bij voorbaat besluiten welke twee van de volgende projectparameters fixed en onveranderbaar zijn: geld, tijd, functionaliteit.

Lopende het project dient de afnemer een projectmanager aan het project toe te kennen, die instaat is om de leverancier volgens de afspraken te managen. Managen op de projectparameters waarvan er één als flexibel is aangemerkt. Alleen op die manier wordt de kans op falen geminimaliseerd.

Dit heeft niets met IT of leverancierscondities te maken, maar alles met het volgens van rechtsregels die gelden voor alle soorten dienstverlening (sterker: voor alle leveringen, producten en diensten) Advocaten die hierover klagen moeten zich eens afvragen of voor een door hen opgesteld contract "fit for purpose" wordt gegrandeert en of de advocaat z'n honorarium terugbetaald als een contractonderhandeling uitloopt.
Voorbeelden zijn leuk; neem die auto zonder de airco. Je moet dan wel melden dat de airco ontbreekt; de autodealer kan niet op afstand zien of de airco ontbreekt of de gebruiker een instellingsfout maakt of zelfs met ramen open rijdt. Specificeren wat er mankeert is kennelijk net zo moeilijk voor afnemers als speciferen wat je wilt hebben. Goed opdrachtgeverschap is een schaars goed.

Dit kan alleen als volgt worden opgelost en ingebed binnen de competentiegebieden van de PM.


Contracten: Contracten dienen waterdicht te zijn. Er mag geen enkele ruimte bestaan tussen afspraken. Aangezien het project in z’n geheel bestaat uit het maken van afspraken, dienen de afspraken helder beschreven te zijn. Het moet zo zijn dat een rechter op het contract kan rechtspreken. Er mogen geen situaties ontstaan dat het er niet staat, dat er veronderstellingen zijn, aannames of ‘ik bedoelde’, want dan geef je ruimte voor speculaties en misverstanden. Een contract hoort een weergave te zijn van de beoogde projectuitvoering. Bij geschil moet het dan ook puntsgewijs aantoonbaar zijn waar de afwijkingen zijn opgetreden en wie daar een specifieke rol in heeft gehad.

Voorbeeld het verhaal van Hans Brinkers
Wie kent niet het verhaal van Hans Brinkers, die Nederland redde van de verdrinkingsdood door zijn vinger in het gat in de dijk te steken. Een toevalstreffer? Een goed geleid project? We weten het niet, we hebben allemaal wel vernomen dat het contractueel heel wat voeten in de aarde had. Voordat je het gat kunt dichten, moet de dijk gebouwd worden. In het verleden was er altijd veel hulp van goedwillende burgers; goede bedoelingen, die niet altijd goed uitpakten. Als iemand de helpende hand uitsteekt, doe je niet moeilijk. Je krijgt dan een inspanningscommitment, en geen resultaatsverplichting. Dat lijkt aardig, maar kan lastig worden als de dijk het lang moet uithouden. Toegegeven, bij de noodreparaties mag ook iedereen meehelpen. De les: stel kwaliteitseisen aan de projectmedewerkers onder de contractkop 'organisatie'. De dijk is gebouwd met verschillende materialen. Wie die geleverd heeft, is niet duidelijk. Iedereen die een vrachtje over heeft brengt dat. Na enige tijd gaan de basaltblokken schuiven over het te natte zand; de inkoop was niet in de haak. De les: schrijf een specificatie en neem in het contract de afname-inspectie op. Na oplevering is iedereen blij; het natte gevaar is ingedamd. Over verborgen gebreken zijn geen afspraken gemaakt. Na jaren beginnen de gebreken. Een gildelid heeft gesjoemeld. De dijk zakt sneller in dan verwacht. Reparaties ten laste van de opdrachtgever is de enige oplossing. Het gildelid is reeds gevlogen. De les: maak afspraken over termijnen en prestaties. Met een garantie en bankgarantie of inhouding kun je veel geld besparen. Er is jarenlang doorgeploeterd zonder contract, steeds weer wat verzakt en opgelapt. Er is geen onderhoudscontract, want dat is duur. We laten dijkwachters regelmatig inspecteren. Die enkele keer dat het mis gaat, is toch in een andere eeuw. Dat risico hoef je niet te managen. De bevolking is eraan gewend dat het bij stormvloed maar net goed gaat. Het grote gevaar is echter rustig aan het werk. Van binnen rot de dijk onzichtbaar weg. Het water vreet zich een weg.
Dan komt Hans Brinkers langs. Het was hem al opgevallen dat het gras op de dijk een bruine plek kreeg. Hij dacht 'zeker graszaad gekocht zonder specificatie en garantie'. Nu ziet hij een straaltje uit de dijk komen. Het zand spoelt mee met het water. Eindelijk wordt Brinkers wakker en steekt bij gebrek aan ander gereedschap zijn vinger in de dijk. Hij heeft geen communicatieplan opgesteld voor als hij in moeilijkheden komt. De gsm ligt thuis, want hij zou alleen even zijn vaste wandelingetje maken. Uren later gaat mevrouw Brinkers samen met de buurman op zoek. Als ze hem vinden, zegt Brinkers alleen maar: "een gat in de dijk". Dat er iets moet gebeuren is duidelijk, ook voor de buurman, een ervaren projectmanager. Die heeft ooit een boekje gelezen over projecten en contracten en zegt: "Even wachten, ik moet thuis naslaan wat ik nu moet doen. Dat kost nu wat tijd, maar levert een veel beter resultaat op. Tot straks.


John Roos
06 81430098

Rare conclusie van John. Wat nou fit for use? Moet de klant dus wel eerst in detail specificeren welk beoogd gebruik. Fit for purpose; idem dito. Verschuil je niet achter juridische kwalificaties, maar zeg wat je wilt zodat de leverancier kan aangeven of hij dat wil en kan leveren en hoe je samen met goede communicatie zorgt dat projecten goed verlopen. Evt met positieve prikkels om succes te stimuleren (geld of pizzas voor teams etc). Overigens...de meeste projecten lopen goed af. Zou advocaat Polo geen tekstverwerker gebruiken (met vast heel veel bugs en regelmatige fixes) dan zou hij geen artikelen meer schrijven. Of heeft hij nog een typemachine?

Enige oplossing voor de crisis in ICT-projecten is vertrouwen. Net zo goed als iemand ook een advocaat in huurt op grond van vertrouwen (door referenties, voorgaande ervaring), of naar een arts gaat op grond van vertrouwen, zo zouden ICT-bedrijven ingehuurd moeten worden.
Zo'n ICT-bedrijf kan vertrouwen wekken door zo snel en zo vaak mogelijk goed werkende software op te leveren. Als een bedrijf niet binnen een maand goed functionerende software kan opleveren, is er geen vertrouwen. Dat voorkomt dat na een jaar of vele jaren van worstelen niks is opgeleverd. Dat zorgt er ook voor dat zogenaamde 'waterdichte' contracten ook niet opgesteld hoeven te worden - van zulke contracten worden alleen juristen beter.
De 'auto-bestellen' metafoor wordt er ook weer bijgehaald in sommige comments. Software IS niet het bouwen van een auto. Software is het ONTWERPEN van een auto. Daar zit een wereld van verschil tussen.

Ik hoor wel iets doorschemeren over kwaliteit, maar daar begint het wel mee. Eerst goede requirements opstellen (wat toch best moeilijk blijkt te zijn in de praktijk) Als het project gstart is tussentijds controleren of deze requirements goed zijn doorvertaald in tussenproducten en daarna gestructureerd testen.

Uiteraard is een goede fasering en een goede relatie met de betrokken partijen belangrijk, maar hoe vaak gebeurt het niet dat er door voortschrijdend inzicht niet wordt voldaan aan de gestelde wensen en eisen van de opdrachtgever. Dat moet dus goed gemanaged worden. Ik heb zelf meegemaakt dat bij een project (in verre vorm van escalatie werd gediscusieerd over de punt bij duizendtallen dat niet was gespecificeerd in de requirements. Het projectbudget was ongeveer gedubbeld en deelname in dat project is dan echt niet leuk meer.

Pas de laatste jaren wordt steeds duidelijker dat management van Requirements een must is. Probleem daarbij is dat projecten, waarvan het resultaat veelal moet aansluiten op bestaande omgevingen, tegen het gegeven aanlopen dat, ondanks dat de Requirements voor die projecten goed zijn beschreven, er sprake is van onvoldoende zicht en grip op die bestaande omgeving. Domweg omdat in het verleden de zaken niet goed zijn beschreven, noch gedocumenteerd. In projecten krijg je dan te maken met het geldverslindende fenomeen Voortschrijdend Inzicht. Veel organisaties doen er daarom goed aan te investeren in het beschrijven van de huidige situatie en vast te leggen op welke fronten deze wel voldoet en op welke fronten niet. En dat kan weer alleen goed worden gedaan op basis van duidelijke processen en goed functionerend informatiemanagement. Kortom: terug naar de basis, de regie in handen van de business en ICT als kritische leverancier of service organisatie die duidelijke eisen stelt aan de beginsituatie en aan de vraagstelling waarvoor zij met oplossingen moet komen.

@John, ik vrees dat jouw werkelijkheid een beetje anders is dan de onze. Ik heb geen enkel miljoenencontract gezien zonder maatwerk op verzoek van inkoopmanagers, projectmanagers, enzovoorts van de opdrachtgevers. Ook als het om slechts enkele tonnen gaat, dan nog zie ik steeds weer maatwerkcontracten.

Volgens mij haal je een MKB-situatie en een grootbedrijf/overheid-situatie door elkaar. Grote afnemers hebben hun eigen standaardcontracten op basis van hun inkoopvoorwaarden.
Probeer maar eens bij Philips, Essent of een ministerie zaken te doen via alleen een standaard ICT~Office contract. Dat luk je niet. Bij publieke en private tenders vragen de uitbestedende partijen altijd aan de inschrijvers in hoeverre zij aan hun inkoopvoorwaarden kunnen voldoen.
De standaard ICT~Office contracten worden aan het MKB en kleine organisaties aangeboden, maar ook die zijn meestal slim genoeg om die aan te laten passen.

Wat wel belangrijk is dat vanaf het begin een projectmanager van de opdrachtgever meewerkt aan het opstellen van de specificaties en van het contract. Juristen en NEVI inkoopmanagers hebben geen verstand van het meten van de vorderingen bij een ICT-contract. Jouw voorstel van “Lopende het project dient de afnemer een projectmanager aan het project toe te kennen” is dus verkeerd. Dan kan het al te laat zijn.

Gerbrand van Dieijen, 14-01-2011 09:55 De auto metafoor wordt erbij gehaald dat partijen zich gewoon moeten houden aan de specificaties en de afspraken.

@John van Voren. Het ICT~Office contract is bedoeld als referentie en niet als letterlijke uitleg van een bepaalde situatie. Natuurlijk hebben grote bedrijven, eigen uitgebreide contracten als basis voor hun inkoop.
Naast een solide juridische basis, is het doorlopend managen van het project vanuit de afnemer een andere belangrijke pijler voor succes. En dan bedoel ik een projectmanager van niveau (die wordt aangestuurd door de persoon - directie niveau - die ook de onderhandeling en de contracten heeft gedaan), met voldoende mandaat om zijn opdrachtnemer te kunnen sturen. Naast mandaat is ook de beschikbare tijd voor projectmanagement een belangrijk aspect. In veel gevallen volgt een bedrijf de waan van de dag (of van de week), terwijl het uitgestippelde projectbeleid wordt ondergesneeuwd door de eisen van nieuw aangestelde businessmanagers.
Met andere woorden: "Denk al voor ge doende gaat en doende denk dan nog".

@Prince2: specificaties voor "fit for use" en "fit for purpose" - wel even lezen: "Onderwerp van levering moeten de overeengekomen specificities zijn (géén verwijzing naar producten van de leverancier, maar naar bedrijfsprocessen van de afnemer)"

@jurist: wellicht is het boek "Lead IT or lose IT" van Nico Beenker wat voor jou?

@Henk: Jouw metafoor gaat op bij het leveren van een kant-en-klaar software pakket met optionele modules (auto met airco).
Voor zoiets is inderdaad een eenduidig leveringscontract op te stellen.

De schrijver heeft het echter over de ontwikkeling van nieuwe software (een nieuw model auto).
Van idee naar product is een lange weg en, zoals bij alle ontwikkeltrajecten het geval is, worden details pas tijdens het traject ingevuld.

Vertrouwen en goede samenwerking tussen de partijen is hierbij onontbeerlijk.
Het contract heeft dan ook eerder het karakter van een intentie-verklaring dan een specificatie.

Uiteindelijk komt het aan op de kwaliteit van hoe het projectwerk wordt gedaan zowel door uitvoerenden als leidinggevenden, hoe de teams samenwerken en blijven inspelen op veranderingen, welke kunde en kennis ieder an sich heeft en hoe soepel de samenwerking is met diegenen waar het project mee heeft te maken en hoe kundig en ervaren de opdrachtgever is. (Het-wij-ik-zij).

Overigens ben ik nog nooit een studie tegengekomen waarbij significante verschillen werden aangetoond bij falende projecten en niet-falende projecten. Kortom, zolang er geen degelijk onderzoek is geweest kan ieder roepen dat - vul in naar eigen keuze - procent van de projecten faalt.

In het artikel wordt ook ingegaan wat het doet met projectmedewerkers als ze steeds op projecten komen waar de stekker eruit wordt gehaald. Het primaire belang, als hij is gedetacheerd bij een klant, is dat zijn eigen werkgever hem "goed" houdt voor het volgende project.

Als je geluk hebt is er bij het project waar de stekker eruit is nog geld om te evalueren en te bepalen wat in soortgelijke situaties anders had gemoeten cq welke kennis en vaardigheden op een hoger peil moeten worden gebracht.

De discrepancy tussen wat een opdrachtgever van een
ICT project verwacht en wat de leverancier levert
kan verschillende oorzaken hebben:
1) begin :overenthousiaste consultants halen de
opdracht binnen en zeggen toe dat hun product alle
functionaliteit levert die gevraagd wordt vaak bezijden
de waarheid, want de developpers weten wel beter
Het is maar een deel van wat er gevraagd wordt
2) De manageers van de opdrachtgever moeten
hun mensen mee krijgen de nieuwe werkwijze te gaan
gebruiken, dat lukt niet altijd
2) Btoch wordt begonnen met inventarisatie van eisen, wensen planningen, inzet mensen en middelen maar
het inzicht ontbreekt hoe ze de alle
3) lopende het project worden de obstakels ontdekt,
mesnsen op andere projecten gezet

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.