Zo voorkomt u dat uw IT project ook mislukt

Over waarom een IT project mislukt volgens een ‘a car crash in slow motion’ scenario. En wat u kunt doen om dat te voorkomen.

Als u nieuwe software of nieuwe technologie succesvol wilt implementeren, dan is niet de nieuwe technologie of nieuwe kennis het grootste probleem, maar ‘oud denken’. Door de valkuilen niet tijdig te herkennen, voltrekt het IT project zich vervolgens volgens een ‘car crash in slow motion’ scenario. Op het moment dat u voor het eerst ziet dat het fout gaat, bent u al te laat om nog in te grijpen. Over hoe dramatische IT ongelukken kunnen gebeuren en hoe u deze voorkomt, leest u in deze tekst. Auteur is Wolter Toet, IT specialist pur sang, pleitbezorger van gezonde IT projecten en kennispartner van het ICT informatiecentrum.

Veel IT projecten mislukken volgens het ‘a car crash in slow motion’ scenario. Dit is een langzame, voorspelbare mislukking die in ruwweg 6 stappen verloopt.

Stap 1. Voorbereiding pakketselectie

Het projectteam, bestaande uit de key-users en de applicatie-experts van IT, start met de procesbeschrijvingen (huidige processen + knelpunten, verbeterpunten) en de beschrijving van het huidige applicatielandschap, inclusief de interfaces. Zij stellen ook vaak een zeer gedetailleerde lijst met eisen en wensen op. Het selectietraject wordt ‘volgens het boekje’ uitgevoerd: long list, short list, RFQ’s, demo’s en uiteindelijk blijven er twee kandidaten over. Stap 1 duurt vaak vier tot zes maanden en wordt geleid door de IT manager/CIO, vaak in samenwerking met de CFO.

Stap 2. Contractfase

De onderhandelingen worden gestart. De CEO wordt er nu bij betrokken en na enig stevig heen en weer onderhandelen over met name de prijs, wordt het contract getekend.
 

‘Op het moment dat u voor het eerst ziet dat het fout gaat, bent u al te laat om nog in te grijpen’.

 

Stap 3. Analyse- en designfase

In de eerste fases van de implementatie verdiepen de consultants zich in uw bedrijf, analyseren zij de workflows en de processen met de key-users en maken zij de eerste ontwerpen voor hoe uw huidige processen in de software ingericht zullen gaan worden.

Na de inhoudelijke goedkeuring, vaak door de key-users, wordt deze fase afgesloten. N.B. In veel gevallen zijn in deze fases zowel alle licenties als de benodigde hardware en infrastructuur al gekocht en ingericht.

Stap 4. Configuratie- en bouwfase

Hierna start de leverancier met de configuratie en bouw van de software en de interfaces. Key-users beginnen vaak al met het schrijven van de testscripts en de eerste aanzet tot dataconversie wordt gestart.

Stap 5. Test- en acceptatiefase

De key-users krijgen nu voor het eerst een goed beeld van de totale software oplossing. En dat valt dan altijd heel erg tegen: ‘Zo werken we hier niet, hier valt niet mee te werken, dit is niet wat we bedoelden.’ Uiteraard zitten er dan ook nog fouten in de software, maar de verwachtingen van de key-users zijn altijd hooggespannen en dan valt het altijd heel erg tegen. Nu begint het getouwtrek. De leverancier stelt zich op het standpunt dat, afgezien van wat bouwfoutjes, dit toch echt afgesproken is. Maar uw key-users kunnen gefundeerd aangeven dat dit allemaal niet gaat werken. Beide partijen staan lijnrecht tegenover elkaar.
 

‘De key-users krijgen nu voor het eerst een goed beeld van de totale software oplossing. En dat valt dan altijd heel erg tegen’.

Stap 6. Escalatie fase

Het escaleert tot op stuurgroepniveau, de CEO wordt erbij betrokken en ‘partijen gaan aan tafel’. Bent u eindverantwoordelijk, dan hebt u nu op hoofdlijnen drie optie

1. U kiest de kant van de leverancier, stelt dat alle bouwfouten opgelost moeten worden, maar als de functionaliteit inderdaad is zoals afgesproken, dan ‘is dit het en hier gaan we mee live’.
2. U kiest de kant van uw key-users en laat de leverancier het pakket aanpassen volgens de wensen van de key-users.
3. U constateert dat dit niet meer goed komt en beëindigt het IT project.

Bijna altijd wordt voor optie 2 gekozen, de software wordt aangepast. Uiteraard tegen meerprijs. Nu komt het project op het beruchte hellende vlak:

• De aanpassingen zijn nooit kleine cosmetische aanpassingen, want dan had de leverancier het niet tot een escalatie laten komen. Het betreft altijd serieuze aanpassingen in de bestaande logica (kennis) van het pakket. Dat doet het pakket zelden goed.
• Serieuze aanpassingen betekent dat enkele delen van de software herschreven moeten worden. Eigenlijk moet alles opnieuw getest worden. In aanpassingen zitten altijd fouten, dus fixen, weer aanpassen en opnieuw testen. En dan nog blijkt het niet …
• De go-live wordt weer uitgesteld. Uw mensen in de projectorganisatie raken vermoeid en uw organisatie gaat twijfelen of het niet zal gaan zoals het zo vaak gaat in dit soort projecten. Lees: mislukt volledig. De motivatie daalt per dag.

Het IT project glijdt langzaam weg.

Op dat moment wordt vaak een go/no-go meeting gepland; doorgaan of stoppen. Daarin wordt bepaald of het geheel toch goed genoeg is om de go-live voorbereidingen te kunnen gaan treffen. Of dat het eigenlijk geen zin meer heeft, dat het ‘tegen beter weten in’ is. In circa de helft van de projecten wordt in de go/no-go-meeting besloten dat het risico te groot is. De software is onvoldoende stabiel, de geboden functionaliteit is onvoldoende, er zijn te veel workarounds nodig en nog te veel open issues en de leverancier durft geen garantie te geven dat dit binnen afzienbare tijd nog op te lossen is. Er wordt alsnog besloten om te stoppen.
 

‘De go-live wordt weer uitgesteld. Uw mensen in de projectorganisatie raken vermoeid en uw organisatie gaat twijfelen. De motivatie daalt per dag.’

 
In de andere gevallen wordt besloten dat de go-live-fase toch gestart kan worden en dat de resterende issues in de nazorgfase worden opgelost. De voorbereidingen worden getroffen, de software gaat krakend en knarsend live en er volgen drie tot zes maanden met verhoogde dijkbewaking, voordat alles eindelijk redelijk werkt. Maar ondertussen hebt u een stevige vendor lock-in, want uw leverancier is de enige die het maatwerk kan onderhouden en dit bij toekomstige upgrades en nieuwe release kan aanpassen. Dus bij elke nieuwe release betaalt u weer de hoofdprijs, het maatwerk moet weer aangepast worden.

Hoe kan het zo misgaan?

De basis is fout. Uw aanpak, uw vertrekpunt is verkeerd

Koopt u nieuwe software, dan koopt u eigenlijk geen software, maar kennis. Kennis van de vele implementaties van deze software die u voorgegaan zijn. Eigenlijk koopt u een hele verzameling ‘best practices’ van de processen die u nodig hebt en die u met behulp van deze software in uw organisatie wilt implementeren.

Echter, u heeft nu verouderde software, die vaak al jaren door uw organisatie gebruikt wordt. Uw organisatie is aan die oude software gewend en weet wat die software biedt aan (on-)mogelijkheden. Niet zelden is de organisatie om de oude software heen gevormd en zijn organisatie en software met elkaar vergroeid. U heeft niet alleen oude software, maar ook een ‘oud denkende’ organisatie. Van uw eindgebruikers tot uw MT leden, ze willen wel nieuwe software, maar de rest moet uiteraard wel ‘hetzelfde blijven’. En dat staat haaks op wat nodig is om nieuwe software en nieuwe technologie succesvol te kunnen implementeren. Want, zoals gezegd, nieuwe software is feitelijk nieuwe kennis, de ‘latest best practices’ op het gebied van procesinrichting. Dit betekent dat u uw processen aan moet passen aan de mogelijkheden van de software. En niet dat u de software moet aanpassen aan uw huidige processen. Die zijn ontstaan rondom de (on-)mogelijkheden van de oude software.
 

‘Niet zelden is de organisatie om de oude software heen gevormd en zijn organisatie en software met elkaar vergroeid. U heeft niet alleen oude software, maar ook een ‘oud denkende’ organisatie’.

 

Om die nieuwe kennis in de nieuwe software te kunnen ontsluiten, om daarmee uw processen optimaal te kunnen inrichten, heeft u kennis van die nieuwe software, die nieuwe technologie, nodig. U heeft externe experts nodig die de mogelijkheden van de nieuwe software volledig kennen en weten hoe andere bedrijven dit uitgenut hebben. Dat zijn dus niet uw key-users of uw IT experts. Zij kennen alleen de huidige processen en de oude software en weten uiteraard wat ze anders zouden willen.

Kort samengevat
Wilt u nieuwe software en/of nieuwe technologie succesvol implementeren, dan is het ‘oud denken’ in uw organisatie uw grootste probleem, niet de nieuwe technologie en de nieuwe kennis. Vanuit die context bezien, waar zitten dan de valkuilen in de implementatie waardoor het ‘a car crash in slow motion’ scenario ontstaat?

Gratis extra boek (tijdelijk) Hoe IT projecten mislukken door ‘oud denken’ en wat u daaraan kunt doen. Een nieuw boek dat u in heldere taal uitlegt waarom onnodig veel bedrijfssoftware projecten mislukken, hoe u de symptomen daarvan tijdig herkent en wat de beste aanpak is om dit te voorkomen. Jarenlange ervaring vertaalt in adviezen die u veel tijd, geld en zorgen kunnen besparen.

1. De start is verkeerd

Vaak wordt gestart met het in detail beschrijven van de huidige bedrijfsprocessen door uw key-users. Dat lijkt logisch, maar is om twee redenen verkeerd:

Ook tijdens de selectie wordt dit laatste nauwelijks serieus getoetst. Leveranciers tonen graag wat hun software allemaal kan en key-users kijken in hoeverre het past bij hoe zij nu werken. Leidend in het selectieproces is: in hoeverre heeft de software voldoende functionaliteit om ons de huidige werkwijze te kunnen bieden? De technologie- of softwarekeuze wordt feitelijk gemaakt op basis van het oude denken van uw key-users, niet op basis van wat u hiermee wilt bereiken, terwijl dat toch de echte reden was om de verouderde software te gaan vervangen.
 

De echt serieuze confrontatie tussen het oude denken en de nieuwe softwareoplossing (omtrent procesinrichting, werkwijze en technologie) vindt pas plaats in de testfase. Dit is op circa twee derde van het IT project, gerekend vanaf het tekenen van het contract en circa anderhalf tot twee jaar nadat u hebt besloten om de verouderde software daadwerkelijk te gaan vervangen.

3. Maar dan staat u al schaakmat ..

Op het moment dat de werkelijke confrontatie plaatsvindt tussen uw oud denkende key-users en de nieuwe software, staat u feitelijk al schaakmat:

Nu stoppen met het IT project en het verlies voor lief nemen doet niemand. Driekwart van het geld is al uitgegeven. De organisatie dwingen de opgeleverde software te accepteren, is nagenoeg onmogelijk, die confrontatie gaan slechts weinigen aan.

Blijft dus als enige oplossing over dat de leverancier de software ‘ombouwt’ naar de door de key-users gewenste werkwijze. Met als resultaat dat u krijgt wat u had, weliswaar in nieuwe techniek, maar zonder nieuwe kennis. En met een serieuze hoeveelheid maatwerk, waardoor in de toekomst nieuwe releases niet passen. Tegelijkertijd ontstaat een vendor lock-in: alleen uw huidige leverancier kan en wil het maatwerk in beheer nemen. U bent minimaal de eerstkomende vijf jaar tot elkaar veroordeeld. Inclusief hoge kosten.

Samengevat
Wilt u uw verouderde software (technologie) vervangen, dan moet uw vertrekpunt zijn wat u met nieuwe software wilt bereiken. Concreet en helder gedefinieerd. Dat is het vertrekpunt in de selectie van de nieuwe software. Is eenmaal de juiste oplossing gekozen, dan worden de mogelijkheden die de nieuwe oplossing biedt leidend. Leidend in hoe de processen ingericht moeten worden, leidend in de implementatie uitvoering, uw projectorganisatie, uw besturing. Leidend is niet hoe uw eigen key-users en/of IT-experts het willen. Leidend is wat u met de vervanging wilt bereiken.

Suggesties om verder te lezen

Nieuwe software is nieuwe kennis (Artikel)
Uitstelgedrag bij IT projecten. Herkenbaar? (Artikel)
Zo pakt u uw softwareproject aan (PDF)
Waarom IT projecten mislukken (e-boek)

Gratis voor u beschikbaar

Bedrijfssoftware box (voor selectie van ERP, CRM, HRM, DMS, TMS, BI oplossingen)

Ook interessant

Nieuws en ontwikkelingen (ICT nieuwsbrief)
Alle gratis boeken (ICTboekensite.nl)
Alle whitepapers (ICTwhitepapers.nl)