Een groot nieuw systeem is landelijk uitgerold. De stuurgroep is zeer tevreden en vraagt ons voor de evaluatie. Dan blijken de gebruikers zeer ontevreden. Wezenlijke uitzonderingen kunnen ze niet meer registreren. De administratie kost 2x meer tijd. Klagen heeft tot nu toe niet geholpen, niemand luistert en de achterstanden lopen op. Medewerkers zijn boos en gefrustreerd. Een aantal wil niet eens meer meewerken aan de evaluatie.
Een diepgaand onderzoek onder IT professionals geeft een waardevol inzicht in de manier waarop zij kijken naar hun eigen projecten. Een aantal gegevens:
- 75% vertrouwt er niet op dat hun project slaagt, 27% weet zeker dat hun project mislukt.
- 80% is voor de helft van de werktijd bezig met herstelwerkzaamheden.
- 78% heeft het gevoel dat de stakeholders in de organisatie niet gelijk oploopt met de ontwikkelaars en de ontwikkeling van het systeem. Managers schatten dit percentage nog hoger in.
- 55% van de IT professionals geeft aan dat ze denken de doelen van de organisatie te begrijpen.
Doemdenkers?
IT professionals zijn net als management en medewerkers van organisaties vaak gefrustreerd als het gaat om de grotere IT projecten. De projecten duren altijd langer, zijn duurder en leveren minder op dan verwacht. Niet moeilijk om dat achteraf te constateren. IT professionals blijken echter al op voorhand te weten dat het niet gaat lukken. Het zijn geen doemdenkers, dus het is ook geen zelfvervullende voorspelling. Ze hebben een positieve houding. Hoewel management en IT professionals dezelfde zorgen hebben, zijn de verwachtingen van de IT professionals meer realistisch dan die van het management.
Oorzaken
De drie belangrijkste redenen waarom een IT project mislukt:
1. Onduidelijke business doelen.
2. Visies van stakeholders verschillen.
3. Extreem veel werk moet worden overgedaan.
Wie wil wat?
Vooral bij de start van een project gaat het mis. Een systeem moet bijdragen aan de business doelen. Als die onduidelijk zijn dan wordt het moeilijk om het systeem daarop af te stemmen. Tegelijkertijd is het een garantie op verschillende visies van de stakeholders. Vaak wordt al werkend duidelijk waaraan het systeem echt moet voldoen. Dan is er al gebouwd, dus dat moet over, en dat is dan 50% van het werk van IT-ers.
Waar strandt het schip?
Organisaties zijn vaak slordig als opdrachtgevers. Het lukt hen niet op voorhand duidelijk te maken wat de succes criteria zijn van een systeem. Gedurende het proces wordt dat steeds duidelijker, en daar krijgen ze dan een flinke rekening voor. IT-ers gaan ook niet helemaal vrij uit. Terwijl 55% de organisatiedoelen niet helder voor ogen heeft, terwijl ze op voorhand al weten dat het niet gaat lukken, gaan ze toch aan de slag.
Resultaat van de evaluaties
En iedere keer die evaluaties met goede voornemens om het de volgende keer heel anders te doen: betere samenwerking tussen management, gebruikers en IT-ers en met de bedrijfsdoelen als uitgangspunt.
Geen succesverhaal
De stuurgroep, opdrachtgever van onze evaluatie dacht echt dat ze een topproduct afgeleverd hadden. Hoe kan het gebeuren dat het eigen management niet door heeft hoe ontevreden de gebruikers zijn?
De titel van uw blog trok enigszins mijn aandacht. Na het lezen dacht ik echter: ''What's new?''. Graag breng ik een belangrijk inzicht in.
1. Methode: Er zijn verschillende methodieken ontwikkeld die de kwaliteit, kosten en tijd moeten bewaken van projecten. Het begint inderdaad bij een goede voorbereiding.
2. Projectmanagement: Een projectmanager welke start met een project zonder de juiste uitgangspunten/overeenstemming betekent automatisch vragen om problemen. Hij/zij heeft altijd de mogelijkheid om in de voorbereiding op de rem te trappen als de doelen, stakeholders, changeproces Governance etc. niet op orde zijn of door hem/haar niet op orde te brengen zijn. Dit dient vastgelegd te zijn in projectmandaat/projectbrief.
De conclusie als doelen niet helder, verschil in stakeholders visie en werk overdoen kan worden voorkomen door de inzet van een professionele ervaren projectmanager.
Het vak projectmanagement wordt nog steeds door velen onderschat. Zolang er mensen actief zijn in het vak die géén ''Nee'' durven zeggen, blijven IT-projecten uitglijden.
Een opdrachtgever is zelf deelgenoot van een 'mission of failure', echter wordt niet voor niets en projectmanager ingezet om zijn/haar belangen te behartigen.
Mijn tip is: ''Begin nimmer met een wazige opdracht welke op voorhand al niet wordt gedragen door de verschillende stakeholders. Toets de opdracht altijd!''
Een geweldig exemplarisch artikel van Aart Pijl.
Het is niet voor het eerst dat een dergelijke realiteit als voorbeeld wordt gebruikt. Het gebeurd namelijk veel vaker dan men uiteraard bekennen wil. Elk afgerond IT project is natuurlijk een ‘succes verhaal’ op zich.
Basaal zijn er drie redenen waarom dit zo loopt zoals beschreven.
IT vs Non IT
Het is veel IT-ers en project managers, onduidelijk dat de IT als materie lineair is. Ook blijken zij in de praktijk hier weinig idee van te hebben. Wanneer je namelijk de lineaire werking en wetmatigheden van de IT niet kent, ligt hier een bron van tegenstrijdigheden, vertraging en frustratie. Dat betekend dat men zich die materie kennis eigen zal moeten maken en laat nu juist dat aspect in al die IT courses ontbreken.
Kort en goed. Als we weten dat veel IT-ers die wetmatigheden niet kennen, hoe wil je dan verwachten dat Non-IT management dit wel zou kunnen weten?
Eenduidige communicatie
Als het vorige punt al de nodige problemen binnen IT projecten kan oproepen, dan weet u dat communicatie ook een heikel onderwerp is. Immers, er bestaan gewoonweg twee belevingswerelden die op elkaar lijken maar in de praktijk volkomen anders uitpakken. Het artikel van Aart is hier een eenvoudig voorbeeld van. Men zal dus eerst Non-IT duidelijk moeten kunnen maken wat IT is, hoe de wetmatigheden werken en dan wordt het plots een stuk eenvoudiger.
Sale sale sale
Door voorgaande twee punten krijgen we tenslotte te maken met een partij met een commercieel belang. Of dit nu een externe of interne partij is maakt weinig uit. De belangen van de commerciele winst worden vaak boven kwaliteit verheven met alle gevolgen van dien.
Trajecten worden vaak opzettelijk dusdanig gecompliceerd opgezet, dat het moeilijk debatteren is om elkaar weer te vinden als koper/verkoper in geval van een dispuut. Overal hangt namelijk weer een prijskaartje aan waardoor men makkelijk kan stellen dat een ‘redelijke wens’ plots weer een aanvulling op het originele plan word, waar vervolgens weer een prijskaartje aan hangt.
U ziet het al. Er zijn alleen hier al verschillende gebieden die voor Non-IT als mijnenveld kan dienen met vele financiele gevolgen van dien. Maar het kan nog erger. 85%+ van de IT projecten bij overheden worden niet binnen de gestelde tijd, volgens de gemaakte afspraken, binnen het gestelde budget opgeleverd. We hebben daar vele voorbeelden van. De reden? Heel eenvoudig. Mensen op posities die geen affiniteit met de materie IT hebben maar wel regie willen voeren.
Waar te beginnen? Heel eenvoudig. Leg Non-IT op eenvoudige manier uit wat IT is, aan welke wetmatigheden IT onderhevig is, en ga dan samen het traject in. Dat scheelt enorm veel onkosten en discussie onderweg, maar meer nog achteraf. Eén seminar hiervoor is al voldoende.
En de ‘Civile Matrix’ krijgt u bij deze van mij cadeau. Helemaal gratis.
Succes.
Wat dit artikel wat mij betreft weer aantoont is dat het lastig blijft om een hele oplossing van te voren te bedenken, helemaal te bouwen en dan achteraf te gaan kijken of er iets bruikbaars gemaakt is.
Zou het dan geen idee zijn om een keer richting Agile te denken? Direkt binnen een maand het meest waardevolle onderdeel bouwen en opleveren, voordat de rest gebouwd gaat worden. Ja, dit heeft een flexibele organisatie nodig en veel input van de opdrachtgever. Maar misschien zou je wat over moeten hebben voor een goed resultaat.
@ The Wim
Beste Wim,
Ik nodig je van harte uit mijn reflectie hier boven te lezen. Het probleem is namelijk dat veel IT-profssionals niet eens weten van de werking en wetmatigheden van de IT als materie.
Lees hier dat je met iets als Prince2, ITLI, TMAP, OTAP, PM of Agile of scrum, juist helemaal de mist in kunt gaan omdat je geen rekening houd met die wetmatigheden.
Twee problemen die ten grondslag liggen aan falen in IT projecten.
1. Geen rekening houden met de wetmatigheden die de materie IT kenmerkt en hoe dit beweegt
2. De brug niet kunnen maken van IT naar Non-IT
Ik nodig je zeker uit over dit aspect je licht eens te laten schijnen. wie weet.
'Een diepgaand onderzoek onder IT professionals geeft een waardevol inzicht in de manier waarop zij kijken naar hun eigen projecten. '
Kan de schrijver van dit artikel wellicht de bron van dit diepgaande onderzoek vermelden?
Algemeen: bij alle projecten waar IT en de business betrokken zijn is het zinvol om al in een zo vroeg mogelijk stadium van het proces met elkaar om de tafel te gaan zitten - als partners / collega's niet als tegenstanders. Dat zou een hoop (toekomstige) ellende voorkomen.
Nico
|
|
27
-
02
-
2012
|
14
:
41
uur
De basis van de problemen zit in de laatste alinea van het artikel: “De stuurgroep, opdrachtgever van onze evaluatie dacht echt dat ze een topproduct afgeleverd hadden. Hoe kan het gebeuren dat het eigen management niet door heeft hoe ontevreden de gebruikers zijn?”
De algemeen geaccepteerde manier van naar projecten kijken is een focus op het project alleen. Een focus op “delivery”, het liefst binnen tijd en budget. Daarmee verdwijnt de lange termijn (Business Case) naar de achtergrond en zal ook de kwaliteit het kind van de rekening worden. Het gevolg zal in het beste geval zijn: operatie geslaagd, patiënt overleden. Bijvoorbeeld met hoge herstelwerkzaamheden.
Een fundamenteel andere manier van kijken naar projecten zet dan ook de Business Case en de kwaliteit op de voorgrond. Met kwaliteit bedoel ik kwaliteit zoals de gebruiker dat voelt en niet het voldoen aan de standaarden van de leverancier zoals dat vooral in ICT vaak geldt. Met een focus op de effecten op de lange termijn (dus niet eenzijdig sturen op oplevering binnen tijd en geld) en een focus op kwaliteit kan dan ook geen sprake meer zijn van ICT projecten want ICT is een middel, geen doel. Tenzij je een ICT-er bent, natuurlijk.
NumoQuest haalt methodes aan. Het bovenstaande is in lijn met PRINCE2, een aanpak die door ICT-ers gedominieerd wordt maar juist niet voor die groep bedoeld is maar voor de opdrachtgevende kant van een project. Zie ook voor een verdere toelichting: (Klik hier)
De andere aanpakken die NumoQuest beschrijft, TMAP, OTAP, PM of Agile, zijn ICT ontwikkelaanpakken en hebben weinig te maken met projectmanagement dat gericht is op de klant en de Business Case. Ook beschrijft NumoQuest ITIL. Dit heeft niets te maken met projectmanagement. Dit is een IT beheersaanpak (stabiliteit in Business as Usual).
Beste Nico,
Alle Respect voor je mening. Ik gaf sec alleen maar weer met welke methodieken men momenteel allemaal niet aan het gooien is om.
Dat je mijn beredenering terzijde schuift is bijzonder jammer. De reden dat ik je dit aangeef is dat wanneer je de wetmatigheden van de materie IT niet kent, niet adopteert, in welke IT discipline, dan hoef je niet eens naar een laatste alinea te wijzen want ik kan je garanderen dat de stuurgroep de laatste van je problemen zullen zijn.
Wanneer namelijk opdrachtgever en nemer niet op hetzelfde niveau zitten, dan zul je vaker dan ooit een stuurgroep nodig hebben. Als je businessmodel niet conform die wetmatigheden blijkt, je Pid, je aanvliegen, het maakt mij verder niet eens uit wat al niet, dan kun je gewoon wachten op de eerste geschillen en vertragingen.
Het is juist zo jammer dat men weinig of niet bekend is met de wetmatigheden van die materie. Maar goed, ik hoe dan ook gelukkig uiteindelijk de rekening niet te betalen.
Nico
|
|
28
-
02
-
2012
|
11
:
43
uur
Beste NumoQuest,
Ik schuif jouw redenatie niet terzijde. Ik begrijp niet goed wat jij verstaat onder “wetmatigheden'' en daarom kan ik er ook geen kritiek op hebben of terzijde schuiven.
Mijn punt is dat de professionaliteit binnen de IT (of het gebrek daaraan) een veel kleiner probleem is dan het gebrek aan besturing. Terecht breng je in jouw eerste reactie commerciële belangen ter sprake. Hier ligt m.i. de oorzaak van de problemen. Binnen “IT-projecten” ligt de nadruk te veel op de rol van de (interne) leverancier en wordt de rol van de echte opdrachtgever niet voldoende ingevuld. Dit probleem wordt zeker bij de overheid zelfs vergroot door de versterking van de rol van de CIO’s; interne leveranciers. Hierdoor zal de echte klant zich nog minder met de eisen, wensen en besturing gaan bemoeien.
Als gevolg hiervan vind ik voor verbetering de rol van ontwikkelmethodieken als TMAP, OTAP, PM of Agile minder belangrijk. Het gaat om besturing door de klant. Juist hiervoor is PRINCE2 een goed hulpmiddel. Helaas is PRINCE2 door de IT sector gekaapt, vooral door ITIL experts, en is er een verkeerd beeld ontstaan met vervelende gevolgen. Lees het artikel maar eens onder de link die in mijn eerdere reactie heb opgenomen.
Veel grotere organisaties, vooral de overheid, hebben bakken met geld verspild met matige PRINCE2 opleidingen voor de verkeerde mensen (IT-ers) door matige opleiders (IT-ers). Het gevolg is dat de PRINCE2 opleidingen en implementaties veelal ineffectief zijn geweest en dat de nadruk ligt op procedures, de papierwinkel en templates. Maar niet op betere besturing. De enige die van deze trend beter zijn geworden, zijn de IT leveranciers met hun ondermaatse PRINCE2 “experts”. Als “echte” PRINCE2 trainer en expert kijk ik hier al jaren met afschuw naar.
Leveranciers, ook de interne, kunnen niet veel met PRINCE2 en zullen het door commerciële belangen zelfs als een onwerkbare aanpak zien als zij kijken naar de principes. Hierdoor en door hun cultuur hebben zij een eigen PRINCE2 versie in de markt gezet die niet effectief is. Dit wordt ook wel PINO genoemd, PRINCE In Name Only.
PRINCE2 is gericht op besturing door de klantenkant van projecten. Hier valt enorm veel winst te halen. Maar gezien de huidige cultuur en gewoontes valt het niet mee om een andere koers in te slaan. Hoewel ik bij grote overheidsorganisaties toch aardige resultaten heb geboekt door managers op alle niveaus aan de klantenkant aan te spreken, weet ik maar al te goed hoe moeilijk dit is. Maar het is de moeite waard en kan veel opleveren.
@ Nico
Ik vind het heel jammer te lezen dat je het idee hebt dat er sprake is van een schuldvraag of vingerwijzing.
Het gaat er hier om dat twee partijen niet dezelfde taal spreken met alle gevolgen van dien. Zoals voorgesteld, beter te continueren per email, uiteraard in alle vrijblijvendheid.
Per slot van rekening hoef ik namelijk de kosten van de uitloop van de projecten niet te financieren. Sterker, ik probeer ze juist te voorkomen.
@ NIco
Beste Nico, we spreken gelukkig dezelfde taal en kijken op exact dezelfde manier tegen de problematiek aan. Sec kijk je eigenlijk naar twee oorzaken.
1. Commerciële belangen door mensen die niet begrijpen van IT en de wetmatigheden en gedragingen die de materie IT met zich mee brengt.
2. Politieke belangen en invloeden van mensen op cruciale plaatsen die geen kennis hebben van de gedragingen en de wetmatigheden van de materie IT.
Overigens wil ik in deze ook graag opmerken dat dit ook voor veel 'IT'ers' op gaat. Keien in hun vakgebiedje maar IT materie begrip en kennis erg povertjes.
Ik nodig je zeker uit kennis te nemen van die meest basale merite van IT als materie en hoe dit in de praktijk in te zetten voor IT en Non IT 'alike'.
Het is volkomen op basis van gelijkheid en vrijblijvendheid.
Wat de PINO betreft? Gewoon het PID als 'Project bijbel' opbouwen heeft veel meer waarde als het hele scala aan documenten.
Mocht je nader willen corresponderen nodig ik je graag uit dit evt. per email voort te zetten.
Dank.
Nico
|
|
28
-
02
-
2012
|
14
:
48
uur
Beste NumoQuest,
Ik geloof na het lezen van jouw bijdragen niet echt dat wij op een lijn zitten. Jij lijkt “de schuld” wel erg te leggen bij het gebrek aan kennis van IT. Ik stel daar tegenover dat IT een zaak is van IT-ers en dat zij gewoon moeten realiseren wat er gevraagd wordt en de zaak niet moeten compliceren door terminologie etc. IT is een middel en een (belangrijke) bijzaak maar je moet het niet belangrijker maken dan het is. Ik benader het probleem niet vanuit de IT maar vanuit de organisatie.
Wat de documentatie betreft: je haalt regelmatig de PID aan. Mag ik je er op wijzen dat de PID nooit als document bedoeld is en (gelukkig) in de 2009 versie ook semantisch geen document meer is? Een eenvoudige indicatie van PINO? De aanwezigheid van een (template voor de) PID.
Er zijn veel belangrijker zaken dan de oppervlakkigheden van documentatie. Zie mijn link naar de principes
Aart Pijl MCM MA CMC
|
|
4
-
03
-
2012
|
18
:
09
uur
Voor de lezers die meer over het onderzoek willen weten. Geneca Industry Survey, winter 2010-2011. 596 business en IT professionals.
Het is boeiend om te zien hoe door een blog er ogenschijnlijk direct boven water komt waar de problematiek in IT-projecten door worden veroorzaakt. Althans dat is één van mijn voorzichtige conclusies die ik trek op basis van hetgeen ik lees.
Verschillende mensen met ieder zijn/haar eigen expertise en ervaring verschillen duidelijk van mening over de onderliggende redenen van het ontsporen van IT-projecten. In mijn ogen word het juist veroorzaakt door de verschillende wijze van kijken naar IT- projecten.
In concreto kan worden vastgesteld dat IT-projecten afhankelijk zijn van diverse factoren welke de kaders scheppen voor succes.
De eenvoudige vraag die we ons moeten stellen is vooral: ''Waar doen we het voor?''. De antwoorden zijn echter complexer dan de vraag, want de diverse belangen en doelstellingen (IT en Non-IT) spelen hierbij mee. Zolang de uitganspunten niet in overeenstemming zijn met elkaar dan is het eerste ingredient van 'mislukking' aanwezig...
Initiatief vanuit Business
Het begint bij een IT-project allemaal bij communicatie, doelstellingen en kaders bepalen vanuit non-IT alvorens één bit door IT geproduceerd kan worden. Zo'n project moet invulling geven aan een behoefte tot automatiseren van een behoefte in de business.
Initiatief vanuit IT
Een andere benadering is wanneer IT een 'uitvinding' doet, nieuwe mogelijkheden ontdekt om business te doen. We noemen dit ook wel innovatie. Dat is de stimulans om business te stimuleren.
Deze twee uitgangspunten dekken de lading van waaruit we met elkaar kunnen spreken...
De algemene vraag is dan eers: ''Uit welk perspectief benadert u een IT-project?''
Is hier sprake van bijsturing? Volgens mij gaf ik een aanvulling en tevens een inzicht zoals men ook zou kunnen kijken.
Misschien nog even een aantal (kleine) nuances.
IT is een vakgebied pur sang. Er zijn vele professionals aan het werk met 'automatiseren'. Jarenlang werd de business medegestuurd vanuit de mogelijkheden van IT. Nieuwe uitvindingen groeiden tot daadwerkelijke innovaties. In mijn blog schrijf ik daar uitgebreid over.
We leven nu in een tijd dat op gebied van IT eigenlijk alles wel mogelijk is. Hiermee komen we weer terug waar het ooit uit is ontstaan, namelijk de business wensen.
IT is, zonder IT te devalueren, inmiddels gegroeid tot een ''nutsvoorziening'' daar waar het om gestandaardiseerde oplossingen gaat als b.v. de werkplek en de eerste laag kantoorautomatisering. Hiermee kgunnen al heel veel bedrijven de standaard werkzaamheden goed uitvoeren.
De cyclus van innoveren bevindt zich boven de standaard kantoorautomatisering. Er moet dus een gezonde samenwerking zijn tussen Business en IT. We moeten niet automatiseren om het automatiseren is mijn boodschap. Soms is een ouderwets leibord nog steeds een geweldige oplossing...
Kortom, samenwerken, communiceren en elkaar willen begrijpen is de sleutel. En moet iedereen dan begrijpen wat IT is? Volgens mij weten vele niet hoe de energie uit de muur komt, maar weten hele goede toepassingen te benutten op 220v ;-)
Deze discussie heeft allerlei wegen bewandeld, die wat mij betreft steeds onduidelijker werden zoals ''wetmatigheden van de materie IT''.
Wat ik hiervoor aanstipte, wat mogelijkerwijs hierop wel aansluit,is dat de kwalitatief beste IT oplossingen tegenwoordig Agile worden gemaakt (zie hiervoor de laatste Automatiseringsgids). Maar is de overheid wel een Agile organisatie? Als je in 1 maand een release wil doen van productierijpe software moet de hele keten (stakeholders, developers, testers, hosting) hiervoor beschikbaar zijn. Als opdrachtgever is het dan handig om deze materie ook te kennen.
Zoals door @richard aangaf, laten we hier breder kijken. Zijn het wel alleen de IT projecten waar de overheid problemen mee heeft (OV Chip, Betuwelijn, Noord-zuid lijn)? Wat Prince2 leert is dat er een duidelijke rol is van de opdrachtgever. Dit is ook hierboven aangestipt. Wie wil er eigenlijk nog werken bij de overheid om dit werk te doen? We willen een ''lean and mean'' overheid hebben, maar krijg je die zomaar?
Beste Richard,
Ik ben bang dat ik je hier, met alle Respect overigens, ietwat moet bijsturen.
Vraag 1. Wat is automatiseren?
Als je twee werelden bij elkaar brengt, in dit geval IT vs Non IT, zul je samen moeten begrijpen wat IT is, hoe het zich beweegt en wat de grenzen zijn.
Vraag 2. Wat beoog je te automatiseren?
Je kunt natuurlijk roepen dat je alles wil en verwacht van IT. Wanneer je vraag 1 niet hebt weten te beantwoorden, gaat het hier al fout.
Vraag 3. Wat levert die automatisering[sslag] op?
ALs je domweg gaat automatiseren omdat iemand dat goed heeft weten te verkopen, iets wat verrassend vaak plaats neemt, is dat een mooi recept voor disaster. Automatiseren doe je omdat je wil besparen. Zo eenvoudig is dat.
Ik verwijs even naar mijn voorgaande reacties al hier en naar (Klik hier) om juist inzichtelijk te maken dat het hierboven mis gaat.
Overigens niet alleen hierboven. Materie IT is zo prachtig schaalbaar en voorspelbaar, dat je weet dat als het hier niet goed zal gaan, het later in de processen van uitvoering en plan ook meer zal kosten dan je lief is.
En dat is nu precies de basis waarom het vaak zo fout gaat in IT. Helaas. IT, pracht vak.
Over de auteur:
