Zaken die kunnen spelen:
1) Er heeft een aanbesteding met een irreëel Pakket van Eisen plaats gevonden, waarbij de leveranciers hun concurrenten goed genoeg kennen om te weten wie er wel en niet aan zaken kunnen voldoen. Omdat de ervaring leert dat nogal eens (om bv politieke redenen) pakketten worden gekozen die niet aan alle eisen voldoen, zouden leveranciers geneigd kunnen raken om maar alles toe te zeggen en dan later damage-control uit te voeren. Dat lukt doorgaans aardig omdat er bij de opdrachtgever carrières verbonden zijn met de implementatie, dus is de interne afdekking geborgd voor een zekere periode en mate van problemen.
2) Er is aan klantzijde een projectgroep opgezet met carrière-managers aangevuld met mensen van finance en control. Dan zie je nog wel eens dat de behoeften, wensen en vragen niet gaan over de ondersteuning van het primaire proces, maar wel over de inzichtelijkheid en rapportages. Bv in de zorg staat financiele controle nogal eens centraal, waarbij de behandelaar een gebruiksonvriendelijke applicatie krijgt om maar de juiste rapportages (mooie kant en klare powerpoint-grafieken) uit op te kunnen hoesten. Dat wekt weerstand en soms sabotage. Een IT-project moet dus bij voorkeur gestart worden vanuit het primaire proces en niet vanuit de management-randen van de organisatie. Op basis van de keuze voor een pakket wat past bij het primaire proces dienen vervolgoplossingen gezocht te worden voor Business Intelligence: datawarehouse, BI-tools etc.
3) IT-leveranciers en consultants hebben een zeker belang in het niet functioneren van de implementatie om meer consultancy-uren te verkopen, zie ook het voorbeeld in het artikel. De IT-leveranciers die hun business-model niet op 'uurtje-factuurtje' hebben gebaseerd -bv de echte SAAS-oplossingen- zijn nog dun gezaaid. Eigenlijk kun je aan de omvang van de helpdesk en de pool aan consultants bij een leverancier al afmeten in welke mate het business-model is gebaseerd op blijvend onderhoud en ondersteuning/consultancy. Gek genoeg zijn de omvang van die ploegen vaak juist een pré in een aanbestedingstraject?!
4) een IT-project is bij uitstek het moment waarop de organisatie die wil implementeren zijn gezicht moet laten zien als het gaat om de processen. Dan ontstaat automatisch een spanningsveld tussen wat applicaties kunnen ondersteunen aan bestaande processen en wat er aan processen moet veranderen om aan te sluiten op de filosofie/structuur van de applicatie. Dat is een rouwproces-traject vol veranderingen, vaak op de werkvloer rond het primaire proces. Dat is heel veel ingewikkelder om op te lossen dan een paar trainingen te geven.

Toch zie ik het zonnig in: wij komen steeds vaker tegen dat in projectgroepen de hulpverleners worden betrokken als kenners bij uitstek van het primaire proces. Daarnaast raakt men gewend aan internet-based SAAS-oplossingen die zich richten op een web-3.0 toekomst waarin zelfstandigheid van de klant centraal staat en gemikt wordt op het minimaliseren van consultancy-inkomsten, welke immers onvoorspelbaar kunnen zijn door de conjuncturele bewegingen van de economie. Als meer klanten buiten de gebaande paden durven kijken en kiezen, dan beweegt de branche al snel in zijn geheel mee!

Een nogal ronkende titel. Falende projecten. Wat zijn dat? Welke criteria voor falen zijn gehanteerd? Na enige zoeken in het artikel blijkt dat het gaat om IT-projecten die over tijd én over budget gaan of worden afgebroken? Ja dank je de koekoek. Da's wel heel kort door de bocht. Niet gekeken is hoeveel over tjd en budget, niet gekeken is naar wijzigingen in de business omgeving van het project, niet gekeken is naar oorzaak van de afwijkingen. Ja, dan is het makkelijk en tendentieus om te zeggen dat 92% faalt.
Mijn stelling is: een project kan niet mislukken. Ieder project levert wat op. Wat wij traditioneel mislukken noemen betekent dat er een onverwacht resultaat van het project was.

@Nico, verschrikkelijk jammer om dit polderverhaal weer eens een keer te lezen.

Ik vermoed dat er sprake is van veel angst. Angst om je baan kwijt te raken of je omzet te verliezen. Angst om als incompetent beoordeeld te worden en op je plaat te gaan. Van dichtbij heb ik de processen mee mogen maken die tot middelmatigheid leiden en slechte projecten.

Jammer dat in dit stuk de excellerende IT organisatie niet met koeieletters wordt genoemd. ZIJ verdienen het. De middelmatig presterende partijen zouden plaats moeten maken voor de topper.

Mijn ervaring leert dat de houding die ik nu kies mijn telefoon niet op roodgloeiend zet. Men is bang voor duidelijke standpunten. De liefde voor duidelijke, effectieve en efficiente oplossingen mag het eigenbelang niet doorkruisen.

De vraag blijft: hoe maken we de weg naar succes zo aantrekkelijk dat we durven om business cases stevig te bespreken, projecten af te blazen, projectteams te herschikken, afscheid te nemen van leveranciers etc. Gaan voor succes, durven we dat wel?

(even mijn telefoon aanzetten ;-)

Ik blijf me er over verbazen dat de IT steeds maar weer de schuld bij de opdrachtgever wil leggen. "Ze snappen niks van ons vak, de domoren". Tja, als wij een project verkopen leggen we alles uit aan de opdrachtgever, in gewoon Nederlands. We proberen het probleem van de opdrachtgever duidelijk te krijgen om vervolgens een oplossing te bieden.
De doorsnee ICTer roept na de tweede zin van een opdrachtgever al dat hij de oplossing voor het probleem heeft en laat dat nu iedere keer juist het systeem zijn dat ze verkopen. Het bekende verhaal van de hamer en de spijker.
Vervolgens gaat de ICTer geheimtaal uitslaan, zinnen vol woorden die in normaal nederlands dat managers spreken een heel andere betekenis hebben. Zo zag ik een manager eens rood aanlopen toen de ICTer hem een SOA aan wilde smeren.
Het probleem blijft dat ICTers product georiënteerd zijn en niet klantgeorienteerd. Ze zijn gefixeerd op de pakketjes die ze aanbieden en niet op de problemen van de klant/.
En als ik dan de reactie weer voor me zie: "Wij zijn anders", "wij zijn beter" dan weet je weer dat er weinig gaat veranderen.
Het grote probleem is evenwel dat ICT totaal geen begrip heeft van mensen en juist daar ligt de basis voor succes. Door samen te werken met adviseurs, business coaches, die misschien weinig van ict maar veel van mensen begrijpen, zal de succesrate ineens geweldig stijgen.
Voor alle duidelijkheid, de succescore van mijn bedrijf is 98%. Een 300% return of investment het eerste jaar garanderen wij. Welk ICT bedrijf kan deze cijfers overleggen?

WIN-WIN= Lose-Lose, tenzij …

De situatie die Nico beschrijft is een typische Win-Win situatie. De klant krijgt zijn prestigieuze ICT implementatie. Dat staat goed op zijn CV. En natuurlijk betrek je dat van een groot en gerenommeerd ICT concern. Een oud gezegde luidt: nobody is ever fired for doing business with IBM. Hetzelde geldt voor CAP, Deloitte, Coopers, Accenture, etc.. De leverancier krijgt veel declarabele uren en dat is in de kern zijn business. Ook hij is dus tevreden. Feitelijk is dit een lose-lose situatie omdat er niet kan worden gesproken over een succesvol project.

Het voorgaande klinkt een beetje cynisch maar dat ben ik niet. Mijn ervaring is dat de kernoorzaak van falende ICT projecten dieper zit. De kernoorzaak is dat beide partijen, opdrachtgevers en ICT dienstverleners hebben leren leven met het probleem. Beide zijn er ook van overtuigd dat het niet anders kan. Dat de business en ICT wereld niet perfect is. Met dat laatste ben ik het overigens eens maar prestaties en resultaten kunnen wel veel beter dan nu veelal wordt gerealiseerd is mijn ervaring.

Betere prestaties en resultaten beginnen met de erkenning dat het beter kan maar dat men niet weet wat men anders moet doen om dat te realiseren. Toch zijn daar eenvoudige methoden voor beschikbaar. De tegenstrijdige belangen tussen leverancier en opdrachtgever staan deze methoden vaak in de weg. Partijen die dat in willen zien maken gebruik van een neutrale buitenstaander om die methoden aan te reiken en zo succes binnen handbereik te brengen. En ook dan is iedereen tevreden. Wat is er in deze business mooier dan een succesvol ICT project!

Het verhaal van Nico is (helaas) zeer herkenbaar en waar, maar toch eerst een kanttekening. Het verhaal gaat op voor grote ICT-projecten. Er gaan veel projecten gelukkig wel goed en we leren ook steeds meer. Dat laat echter onverlet dat het trackrecord van de ICT-brnache op het gebied van projecten (veel te) slecht is.
Het is noodzakelijk zaken fundamenteel anders te gaan doen, anders lossen we dit probleem nooit op. Want ga maar na: de gemiddelde time to market is ongeveer 9 maanden en dalend, terwijl het gemiddelde ICT-project 2 jaar duurt. Om dit dilemma op te lossen, moeten we dus fundamenteel anders omgaan met ICT-projecten.
Al sinds de jaren 60 is bekend dat praktisch alle business software die we gebruiken, de eigenschap heeft vanzelf steeds complexer (en dus minder onderhoudbaar) te worden, tenzij expliciet aandacht wordt besteed aan de onderhoudbaarheid. Dit is bekend als Lehman's law. Omdat de business continu verandert, moet de software die die business ondersteunt, ook constant mee-evolueren. Ook tijdens nieuwbouw hebben we last van Lehman's law. De eisen veranderen namelijk tijdens het project en meestal wordt het ontwerp hier niet meer op aangepast en is expliciete aandacht (en dus ook inspanning) nodig om het systeem onderhoudbaar te houden. Tot zover het probleem van de ICT-ers in hun eigen domein.
In de business zien we dat er steeds meer informatie beschikbaar is en gebruikt wordt om zakelijke beslissingen te nemen. We zullen businessprocessen daarom niet meer in de eerste plaats als informativerwerkende processen moeten zien. We moeten op zoek naar de originele feiten die in de business worden gecreëerd. Een origineel feit is bv. een klant die om de levering van een bepaald product of dienst vraagt. Of, in overheidssfeer, een autoriteit die een rijbewijs uitgeeft, waarbij het originele feit is, de datum vanaf welke iemand de bevoegdheid krijgt om een bepaalde categorie voertuigen te besturen. Het tot stand brengen van feiten zijn transacties, de personen die in een bepaalde rol de transacties uitvoeren, zijn de actoren. Dit levert een veel compacter model op dat wel compleet is en de essentie van de business weergeeft, dit in tegenstelling tot de functionele modellen die we nu gewend zijn. Omdat het model de essentie van een business weergeeft, is het stabiel en biedt het ook een stabiele basis om onderhoudbare informatiesystemen op te ontwerpen. We zien dus dat we niet alleen de informatieverwerkende processen ontwerpen, maar dat ook de businessprocessen volgens bepaalde regels ontworpen moeten worden. Dat is dus anders dan ICT-ers gewend zijn, waarbij de business aangeeft wat de bedrijfsprocessen zijn en de ICT-ers alleen opschrijven in functionele modellen (input-proces-output).
Samengevat is hier beschreven dat we een organisatie beschouwen als een sociaal systeem dat bestaat uit actoren die samenwerken om het bedrijfsresultaat tot stand te brengen.
Alleen als dit inhoudelijke aspect wordt toegevoegd aan ICT-projecten, zullen onze projectmanagement methoden en technieken toereikend zijn om projecten beheerst uit te voeren.

Een mens faalt omdat hij zelf nog niet ontwikkeld is, als mens ben je nog niet af, de evolutie van het licht is nog niet voltooid bij de mens, dus alles wat een mens doet is onaf. En het is dan niet zo verwonderlijk dat een mens steeds faalt, en dus ook een ICT-project dat door mensen wordt gestuurd. Het ligt alleen moeilijk bij mensen, omdat het niet zo gemakkelijk is om toe te geven als mens dat je nog niet alles kunt en kent.
Veel mensen proberen dag in dag uit zaken te verbeteren, maar dat lukt niet. Dat lees ik ook in dit artikel, mensen maken steeds dezelfde fouten. Dat kan ook niet anders, want mensen leven vanuit patronen, die ingebakken zijn in de moleculen van hun lichaamsmaterie. En dat betekent dat iedereen elke dag hetzelfde liedje zingt en nooit echt verandert of verbetert. In de deltawetenschap lilaca is daar onderzoek naar gedaan en er is ook ontdekt dat het wel mogelijk is om te veranderen. Het is alleen niet zo'n populaire bezigheid, omdat niemand wil veranderen. Net als ieder ander mens verval ook ik in de dingen steeds willen verbeteren, maar dat is een doodlopende weg, daar begin ik ondertussen wel achter te komen. Toch biedt de lilaca perspectieven voor de echte avonturiers, die op zoek zijn naar zichzelf en naar kennis en kunde.

Nico, je antwoord aan Willem Mastenbroek op zijn vraag hoe het komt dat IT-bedrijven het verantwoordelijk management niet bij de les houdt is dus: oppervlakkigheid en commercieel opportunisme. Weinig verrassend, zoals jezelf ook opmerkt. Maar dat je het géén schande vindt, is wat mij betreft wel degelijk een verrassend standpunt. Veel grote ICT-projecten (ik noem alleen C2000 van de politie) zijn met belastinggelden betaald. Dat is dus wél schande volgens mij. Waar is je gevoel voor maatschappelijke verantwoordelijkheid? En dat van die IT-bedrijven? Het is zoals het is, schrijf je. Maar jij bent toch geen opportunist?

Hi Teun,
Ik voel het meeste sympathie voor de positie van opdrachtgevers, zij hebben recht op onwetendheid en op een goed en eerlijk advies. Anderzijds mag je van een opdrachtgever ook een professionele en zorgvuldige houding verwachten. Zéker wanneer het publiek geld betreft! Te vaak zie ik bij allerlei uitvoeringsinstanties (zoals bij IT-brokkenpiloot UWV) ongeïnteresseerde eindverantwoordelijke opdrachtgevers die hun rol niet eens wíllen invullen. Top-bestuurders halen er de neus voor op en komen daar mee weg. Dat geldt nu ook voor de Raad voor de Rechtspraak. Je kan een doorsnee IT-bedrijf niet heel erg kwalijk nemen dat ze ook van dit soort (aanklooiende) opdrachtgevers een riante opdracht willen aanvaarden. Je kunt ze wél een verwijt maken wanneer ze slecht opdrachtgeverschap niet stevig aan de kaak stellen. Maar in de eindafweging is het een gedeelde verantwoordelijkheid en vind ik het woord schande niet passen.

ICT als excuses voor slechte bedrijfsvoering
Na 9 jaar ervaring met de invoering van een ERP systeem in een ministerie kan ik zeggen dat de invoering van ICT vaak als excuus dient voor een slechte bedrijfsvoering waarin onduidelijkheid bestaat over de onderlinge rolverdeling en sprake is van een gebrekkige transparantie. Vele projecten leren dat de bedrijfsvoering op orde moet zijn.
ICT kan een goede bedrijfsvoering verder verbeteren, maar is niet in staat een slechte bedrijfsvoering goed te maken.
Uiteindelijk is het dus altijd "de schuld van de opdrachtgever" dat een ICT-project mislukt.
Je kunt het de timmerman die een stuk aan je huis bouwt toch niet kwalijk nemen dat de bewoners niet in staat zijn te bepalen wat er in die nieuwe kamer moet gebeuren en hoe die aansluit op het "oude" huis?

IT projecten zie ik net zo vaak lukken als mislukken. En mislukken betekent dan veelal dat er minder functionaliteit of meer kosten/tijd nodig zijn. Wat ik vaker zie mislukken zijn grote ict projecten die meerdere jaren lopen. Dat lijkt mij op zich ook niet zo vreemd. Kenmerk van grote projecten is, voor wat ik waarneem, vaak een sprong in het diepe. Wat ik ervaar als onjuist aan grote projecten is dat de opdrachtnemer na enige tijd niet wil zeggen dat het niks wordt (geld verlies?) en dat de opdrachtgever dat niet wil horen (gezichtsverlies?) en dus werken we langzaam toe naar een debacle. Vaak zie ik dan wisselingen van projectleiders, gemandateerde opdrachgevers enz.

Ik denk dat met name de professionaliteit van opdrachtgever en leverancier hier in het geding zijn. Het zou goed zijn als de opdrachgever zijn rol goed speelt en dat de opdrachtnemer nee durft te zeggen.