'Meeste ict-projecten niet succesvol'

Volgens Ernst & Youngs ICT-Barometer kan minder dan de helft van de Nederlandse ict-projecten succesvol worden genoemd. Vooral de invoering van crm-systemen zou vaak in de soep lopen.

Ernst & Youngs respondentengilde van ict-directeuren, -managers en -professionals geeft wel aan dat projecten over het algemeen vaker succesvol zijn dan in voorgaande jaren, en bovendien zijn projecten die helemaal mislukken met vier procent een relatieve zeldzaamheid. Niettemin spreekt Jacob Verschuur van Ernst & Young van een 'ronduit schokkende' uitslag: 'Er zijn circa 100.000 bedrijven vanaf 5 medewerkers in Nederland die ruw geschat 380.000 ict-projecten op jaarbasis starten. Als we uitgaan van de 4 procent van projecten die volledig mislukt, dan zien we in het onderzoek ruim 15.000 volledig geflopte projecten per jaar!' Volgens Verschuur worden daar jaarlijks ongeveer 4.000 bedrijven door getroffen. Die krijgen te maken met 'falende boekhoudsystemen, haperende netwerken, onbenaderbare websites en vooral erg veel slecht werkende crm-systemen,' zo stelt hij.

De respondenten geven verschillende redenen op voor het mislukken danwel niet volledig succesvol zijn van ict-projecten. Het vaakst, in 37 procent van de gevallen, stuit men op technische problemen waardoor de kersverse applicatie kortere of langere tijd niet werkt, of het levenslicht dus in het geheel niet te zien krijgt. Het feit dat een toepassing niet of niet geheel aan de verwachtingen voldoet, wordt door 28 procent genoemd als reden om een project geen succes te noemen. Verder wordt het uitlopen van het ontwikkeltraject door 23 procent genoemd, en is voor 11 procent een kostenoverschrijding reden om zich niet positief over een ict-project uit te laten.

Reacties (79)

[NiGeLaToR]

Zijn mij twee dingen opgevallen aan deze resultaten, aan de ene kant het feit dat we dit nog steeds accepteren zoals het is en het tweede dat met name de niet-technische implementaties die mislukken. Hoe meer het lekker upgraden of migreren van troep is gaat het prima, maar zodra het om bedrijfsprocessen automatiseren gaat, het omgaan met informatie of het delen van kennis/informatie raken de projecten vaker in het slop.

Das simpelweg omdat je dan de ICT-er het werk van de architect, aannemer en bouwkundige niet moet laten doen - maar puur het werk van de bouwvakker, de man/vrouw die het bedachte gaat realiseren. Nog steeds wordt het normaal gevonden om te roepen 'ik heb het overzicht van mijn klanten kwijt', waarop de ICT-er geacht wordt te antwoorden met 'Oh, dan installeer ik toch een CRM systeem... '. Werkt niet.

[Kalief]

Nee idd. Het automatiseren van een slechte werkwijze leidt alleen maar tot een geautomatiseerde slechte werkwijze. Maar het is voor managers aantrekkelijk om organisatorische problemen in een ict-project te duwen, mislukt het dan is het de schuld van de it-ers.

[Left]

Mijn ervaring is dat projecten mislukken doordat er onrealistische doelen gesteld worden. Dit komt aan de ene kant doordat de klant geen goed beeld heeft van wat er mogelijk is, en aan de andere kant doordat de ICT'ers geneigd zijn de klant zijn zin te geven terwijl ze eigenlijk 'nee' hadden moeten verkopen.

[Gucky]

Hmmm....

regelmatig met projecten te maken gehad die "op hun kont' lagen. Met het weer aanwijzen en positief motiveren van verantwoordelijken was het meestal wel weer vlot te trekken... (als het tenminste geen onzinnig project was...).

Vaak ontbrak het aan support vanuit het management, waardoor het enthousiasme tot een dieptepunt daalde. Daardoor alleen al waren projecten gedoemd te mislukken.
Andersom is helaas ook vaak het geval: iemand achter een bureau denkt iets leuks uit en dat wordt zonder al teveel kennis en overleg met de aanstaande gebruikers ingevoerd (lees: doorgedrukt...). Ook dat heeft nauwelijks kans van slagen.
Meestal zijn de knelpunten:
1. gedegen onderzoek en inventarisatie (wat is er nu echt nodig en hoeveel van het bedrijf krijgt er mee te maken?)
1b. kosten/baten analyse aan de hand van voorgaande acties (je moet op dit punt durven stoppen of het roer drastisch om durven gooien!)
2. draagvlak bij alle betrokkenen van hoog tot laag (andersom is beter)
3. draagvlak krijg je door voorlichting en serieus overleg met alle betrokkenen (de acties voor inventarisatie en het overleg overlappen elkaar voor een gedeelte)
4. testen, testen en nog eens testen samen met ervaren (en zeer kritische) gebruikers in een copie van de werkomgeving, met dezelfde (of een hogere) belasting als in de werkomgeving.
5. de "ontvangende" afdeling/organisatie moet de acceptatie ook tekenen voor OK!
6. de support organisatie moet bij elke test betrokken zijn om al kennis op te bouwen voor het support na acceptatie en invoering
7. cursussen voor de eindgebruikers meerekenen (hoe beter en intuïtiever het eindproduct, hoe lager de kosten hiervoor _meestal_ zullen uitvallen)
8. project redelijk strak leiden, maar ondanks dat toch net flexibel genoeg om slagvaardig met tegenvallers om te kunnen gaan; een ieder moet goed weten wat zijn/haar taak is en de bijbehorende verantwoordelijkheden.
9. als de kennis niet in huis is van bepaalde technische onderdelen kun je die bij een goed bedrijf altijd inhuren; duidelijke afspraken zijn nodig. Als de eigen organisatie het eindproduct moet supporten, moet het eigen personeel vanaf het begin geheel meedraaien!


Verantwoordelijken zijn vaak bang om hun gezicht te verliezen (zie punt 1b) en juist '_daardoor_ gaat het nogal eens goed fout....


Gerard.

[Reactie gewijzigd door Gucky op 23 juli 2024 07:39]

[Motrax]

Laten we eerlijk zijn:
- Te weinig ervaren ICT'ers
- Onrealistische eisen van opdrachtgevers
- Veranderende scoop
- Technisch gezien is een omgeving vaak complex, niet alles is te voorzien
- Alles moet zo goedkoop mogelijk en zo snel mogelijk opgeleverd worden, geen tijd voor bijvoorbeeld testen
En dan vind ik het aantal projecten dat niet lukt nog best laag...

[Floor]

Je vergeet het belangrijkte:
grijpen naar maatwerk omdat bedrijven weigeren de organisatie aan te passen. Maatwerk is een mooi synoniem voor problemen:
- niet standaard dus uitermate grote kans op fouten,
- weinig mogelijkheden tot testen (financieel meestal).
- belemmerd de ontwikkeling (We hebben maatwerk dus we kunnen moeilijk naar de nieuwe versie)
en zo kan ik nog wel even doorgaan.
Maatwerk is bij mij Not Done. Een leverancier die daarmee begint wijs ik linearecta de deur uit.

[Taeke]

Ga jij je baas maar vertellen dat hij zijn organisatie moet aanpassen voor een stukje software. Software zou de bedrijfsprocessen moeten ondersteunen, niet dicteren. Probleem is dat veel bedrijfsprocessen niet zomaar even in een standaard software pakket zijn te vangen. Enige aanpassing vanuit het bedrijf is dan ook wel gewenst, maar om alles om het software pakket te laten draaien gaat te ver.

Verder wordt een software systeem en met name een CRM door veel werknemers gezien als de oplossing voor al hun problemen. Ze vergeten echter dat een CRM op zichzelf niets kan. Er zullen eerst maanden aan data moeten worden ingevoerd, voordat een CRM resultaat gaat leveren.

[Reactie gewijzigd door Taeke op 23 juli 2024 07:39]

[Verwijderd]

Het probleem is meer dat je bedrijfsprocessen eerst goed moeten zijn, voordat je kunt gaan automatiseren. Daarnaast is het vaak zo dat je door de automatisering je bedrijfsprocessen beter anders kunt gaan indelen.

Het idee dat software ondersteunend is en het bestaande proces zo kan blijven als het is, is een garantie voor problemen.

Juist op het moment dat men iets gaat automatiseren, moet men gaan kijken hoe het anders en beter kan.

Probleem is dat veranderingen altijd weerstand oproepen. Mensen willen vasthouden aan het hun bekende en dus veilige systeem. Hoe vaak ik al niet mensen met een strak gezicht heb zien zeggen dat het oude systeem beter was, terwijl er vlak daarvoor een klus geklaard was in 15 minuten waar men met het oude systeem 2 dagen mee bezig geweest was en het nog vol met fouten zat..

"tekeningen ontdubbelen".. "ja als ik die optie gebruik, werkt het nooit"..
ok.. dan gaan we dat meteen even proberen.. kijk, zo, hier klikken, ontdubbelen aan en hoppa.. het gewenste resultaat. "nou als ik het doe gaat het altijd mis". Ok, doe jij het dan eens.. hoppa, het gewenste resultaat. "Nou toch werkt het niet ik blijf gewoon mijn oude zelf gebouwde excel gevalletje wat fouten maakt gebruiken".

*zucht*

[Verwijderd]

Wij hebben een calculatiepakket en doen ook veel maatwerk, maar alle maatwerk dat wij maken wordt eerst grondig getest, of de klant daar nu op wilt wachten of niet.

ivm het upgraden, een goed onderbouwd systeem kan zelfs indien er maatwerk is upgraden naar een nieuwe versie.

Het is niet het maatwerk dat het probleem is. Het zijn de 'specialisten' die het maatwerk moeten leveren die het probleem zijn.
En natuurlijk ook de klanten die inderdaad het maatwerk zo snel en goedkoop mogelijk willen en dan kom je terug uit bij die zogenaamde 'specialisten' die een graantje van de wereld willen meepikken.

We zijn in een ict-cultuur terecht gekomen waarin alles zo snel mogelijk moet gebeuren en helaas gaat men hier vaak in de fout.

[J.J.J. Bokma]

Maatwerk is bij mij Not Done. Een leverancier die daarmee begint wijs ik linearecta de deur uit.

Ha ha ha, dus jij verplaatst maatwerk in de software naar maatwerk in de organisatie. En dat is ook een - welicht zeer belangrijke - reden waarom diverse projecten falen. In plaats van maatwerk koopt men een oplossing die dicht in de buurt komt, en vervolgens moet iedereen zich maar aanpassen binnen de organisatie.

Verder maak je nogal een grote denkfout: maatwerk kan prima standaard zijn (door met (open) standaarden te werken), of worden. Diverse Open Source projecten zijn ooit begonnen als maatwerk binnen een bedrijf (als Perl programmeur noem ik ff Perl, maar ik zelfs Linux kan je zien als: begonnen als een prive-maatwerk project).

Natuurlijk ben in bevooroordeeld, ik doe alleen maar maatwerk (vnl. Perl). En een van de dingen die ik doe (en een must vind): is er een bestaande oplossing die ik zo veel mogelijk kan (her)gebruiken. Wielen uitvinden laat ik graag aan anderen over. Maar ik ga iemand geen totaaloplossing aansmeren + een cursus als maatwerk beter is. En beter is niet altijd de laagste aanschafprijs.

[Verwijderd]

Maatwerk hoeft niet synoniem te zijn voor problemen en soms ontkom je er niet aan.

Ik ben het met je eens dat indien er voor standaard werk heel veel maatwerk geschreven moet worden, dat men dan eens moet overwegen waarom al die andere bedrijven het anders doen. Of dat andere dan misschien niet beter is, zodat men geen maatwerk hoeft te gebruiken.

Toch.. helemaal aan maatwerk ontkomen kan domweg niet altijd. Soms heeft een bedrijf een dermate uniek intern proces, dat er domweg geen software voor is.

Maatwerk kan ook prima, mits beide partijen (afnemer/leverancier) zich er van bewust zijn dat maatwerk ook echt maatwerk moet zijn en dat dat tijd en geld kost. Dat je maatwerk minder makkelijk kunt vangen in te krappe budgetten of tijdsplanningen. Dat er draagvlak voor moet zijn, dat er een projectgroep moet zijn met ten minste 1 van de daadwerkelijke gebruikers er in, dat men niet moet beginnen met programmeren voordat helemaal vastligt wat er moet komen, enzovoort.

Waar het bij maatwerk op vast loopt is dat er vaak in het sales gesprek van alles beloofd wordt. Daarna wordt er een junior programmeur (=prutser) neergezet en die begint wat te prutsen her en der. De lokale 'IT nerd' van het bedrijf (die dat is omdat hij de toner uit de laserprinter kan vervangen) stuurt het project aan en dan als de prutser eindelijk iets heeft geleverd wat compiled, wordt het aan de eindgebruikers gepresenteerd als het ei van columbus.

[OddesE]

Dat IT alleen het bedrijfsproces zou moeten ondersteunen en niet dicteren is een achterhaald idee. Vaak worden bedrijven die koploper zijn op hun gebied en flink investeren in IT (uiteraard helemaal aangepast aan hun bedrijfsproces) in een later stadium zijdelings ingehaald door kleinere organisaties die hun eigen proces hebben aangepast aan de beschikbare software in plaats van andersom. Op het moment dat je een klant laat betalen met een SMS, wat pas je dan aan, de beschikbare technologie of of het bedrijfsproces? Je bestaande bedrijfsproces is gebaseerd op de mogelijkheden en vooral limieten van beschikbare hulpmiddelen. Als je dan nieuwe hulpmiddelen krijgt moet je proces veranderen om die nieuwe mogelijkheden te benutten.

Zelf ben ik een software ontwikkelaar voor een internetbedrijf (http://gx.nl/ ). Onze klanten laten regelmatig maatwerk bouwen, maar wat wil je ook? Hoeveel software denk je dat er standaard op de schappen ligt voor een televisiestation dat alle live streams van het Big Brother huis via de website wil uitzenden? Of een telco die je met één druk op de knop vertelt of je je mobiele abonnment kunt verlengen, tegen welke kosten etc. Ons maatwerk bestaat er meestal uit stukken code aan elkaar te brijen tot een totaaloplossing voor de klant zijn situatie. En voor sommige bedrijven en in sommige markten zijn die situaties bijna uniek. Hiervoor heb ik gewerkt voor KEMA aan software voor electriciteitsleveranciers. Het hele electriciteitsnet is zeer difuus met grote verschillen tussen de netwerken in de verschillende landen e.d. Wederom, hoeveel standaard software ligt er op de plank? Het is niet alsof je even Open Electricity Grid Manager download of zo.

[McChouffe]

En wat dacht je van:
- Gebrek aan management support

Ook altijd een belangrijke factor omdat eindgebruikers dan het idee krijgen dat het ict-project niet belangrijk is en dus ook niet echt gaan meewerken.

[Greyh0und]

- Te weinig ervaren ICT'ers

Ik zit momenteel op een ICT-Beheer opleiding, alles wat wij (als klas zijnde) moeten doen is ZELF alles opzoeken, dus wat doen we? we flanzen wat in elkaar en kopieëren alles van elkaar, maar daar leren wij niets van dus als we van de opleiding af zijn en ons papiertje hebben weten we nog niets...

Dus ik geef de schuld aan de scholen (ik geef ook toe dat we niet erg gemotiveerd zijn, maar dat gaat ook niet als je bvb niets van linux af weet en dan opeen een server moet opzetten

[To_Tall]

Dat heet intresse in je toekomstige vak.

Toen ik in 1999 aan mijn ICT opleiding Beheer Informatie systemen begon wist ik al wat een Router, Switch, HUB, Linux, Windows enz

Ik had voordat ik aan mijn opleiding begon of zelfs wist dat ik aan een MBO opleiding moest denken al met Linux gespeeld. Mijn neef had Kabel internet. Ik heb dagen bij mijn neef gezeten met mijn eigen PCtje om daar linux op te installeren.

Windows 2000 Kwam uit. Ik 2000 installeeren en vergelijken met andere systemen.
-----
Tijdens mijn opleiding moesten er BATCH bestanden worden gemaakt voor windows 98 om bepaalde proccessen auto te laten uitvoeren.

Ik kon hier al mee overweg. terwijl 99% van mijn klas genoten niet eens wisten hoe zij in DOS een bestand moesten opstarten.

Ik hoor vaak van mensen in een ICT opleiding
Ik moest ineens NOVEL installeren maar wat is dat?
Linux heb ik nog nooit gedraaid en nu moet ik een Linux server installeren.
Heb een opdracht gekregen om een Startup Script te maken in VBS..


Mensen moet zich in hun nieuwe vak wel weten wat een VBS script is.. En wat een Router is enz. Door dat mensen zelf niet verder kijken en maar aan een school boek blijven kleven komen nauwlijks verder.

Leer in de breede niet in de lengte. Daarnaast wanneer je dingen uitzoek zal je dat langer onthouden dan wanneer je leeraar ooit eens vertel Waar het word MoDem vandaan komt.

[Reactie gewijzigd door To_Tall op 23 juli 2024 07:39]

[Verwijderd]

Herken mezelf hier ook in, heb nu een MBO niveau 3 systeembeheerder diploma, wilde eigelijk wel voor de niveau 4 gaan maar trok het echt niet meer met de manier van leren op school.
Kijk dat ze je je gang laten gaan en alles zelf uit laten zoeken vind ik prima maar als je dan echt iets niet weet en om hulp vraagt word gewoon gezegd raadpleeg het internet maar.
Hieruit blijkt ook dat de leraren OF het gewoon niet willen uitleggen OF dat zij er dus zelf ook maar weinig vanaf weten.
Heb precies hetzelfde gehad wat jij zegt met Linux, nog nooit van mn hele leve mee gewerkt wel is van gehoort maar dan moet ik ineens een server in CLI op gaan zetten dus het was verboden om een GUI te gebruiken
En uitleg? ho maar, zoek maar op internet...

[Verwijderd]

Mensen die denken dat ze alles kunnen leren slaan door naar school te gaan slaan wat mij betreft de plank helemaal mis. Op de lagere school leer je echt, op de middelbare school wordt al meer zelfstandigheid verwacht en op vervolg opleidingen nog meer. Ik heb zelf HBO Informatica gedaan en heb er vrijwel niets geleerd omdat ik mijzelf vrijwel alles al lang had aangeleerd (op het MBO heb ik nog wel wat geleerd). Ik zie de opleiding die ik heb gedaan dan ook niet meer dan als een filter, mensen die geen affiniteit/kennis hebben met IT vallen af. Natuurlijk is het dom om gewoon 4 jaar in de bankjes te zitten zonder dat de docent/professor je iets bijbrengt, maar het betekend wel aan het einde van de rit dat het papiertje wat je ontvangt aantoond dat je iig doorzettingsvermogen bezit. Ik snap je frustraties, maar omgekeerd kun je niet verwachten dat de kennis er met de pap-lepel wordt ingegoten.

[Verwijderd]

Dat heet intresse in je toekomstige vak.

Toen ik in 1999 aan mijn ICT opleiding Beheer Informatie systemen begon wist ik al wat een Router, Switch, HUB, Linux, Windows enz

Het is de bedoeling dat je het tijdens de opleiding leerd, en niet voor de opleiding. Zo heeft die opleiding toch ook geen zin. En daarnaast waren de ict scholen in 1999 wel beter dan nu.

[To_Tall]

Beter dan nu??

In die tijd had niet iedereen Internet
Mijn ICT leerraar was iemand die uit het bedrijfs leven was geplukt en nog nooit voor een klas had gestaan.
Mijn Klas was de eerste ICT opleiding van die school.
Veel leerlingen dachten o beetje op internet rommelen leuk.

Natuurlijk is het de bedoeling dat je wat leert op school. Maar er wordt ook van de leerling zelf verwacht al wat kennis aan boord te hebben, zelfstandig te kunnen werken. en niet bang is voor het onbekende.

Daar schort het nogal aan, en veel houden alleen vast aan dat ene school boek. Daarnaast moet je zelf op school ontwikkelen als jij niet 2 stappen vooruit leert denken. en thuis voorwerk Documentatie van systemen doorneemt kom je nooit ergens.

Als jij op school onvoldoendes haal en net je examen weet te redden is dat leuk. Nu moet je zelf gaan bewijzen en niet in hokjes denken.

[hansg]

Je "leerraar" nederlands was zeker ook zo van straat geplukt?

[Evilslayer]

Ja natuurlijk is het de bedoeling dat je het grootste stuk van de leerstof pas kent nadat je het gezien hebt, maar het kan toch geen kwaad om een beetje (veel) voorkennis te hebben.
Voor ik in de lagere school terecht kwam kon ik ook al een beetje lezen en een beetje rekenen en ik ben waarschijnlijk niet de enige hier
Nu (5de jaar secundair) ben ik de enige in klas die ooit al eens een linux distrutie draaiende heeft gezien. En er zijn er ook niet veel die ooit al eens een pc vanbinnen uit gezien hebben.
Wil dit zeggen dat ik niet meer leer? Natuurlijk niet, ik leer nog elke dag nieuwe dingen bij.

[hackerhater]

Ik zit zelf op HBO informatica (heerlen)
Maar het niveau is echt om te huilen

Ik ben de enigste van de klas met voorkennis
Ik beweer zeker niet dat ik alles onder linux kan, maar de command-line schrikt me niet af
Ik werk zelf ook het liefste in coder-mode en wil niet dat die omgeving zich met mijn code bemoeid. Hier ben ik ook weer een uitzondering in.
en na een jaar ook de enigste die grotere dingen in elkaar kan programeren zonder knippen en plakken.
Veel van mijn klasgenoten zitten maar onzin te schoppen onder de les en weten de grondpriciepes van programeren nog niet eens.

De docent is ook niet veel beter. Die loopt jaren achter en weet ook heel veel niet.
De scholen zullen vroeger zeker veel beter zijn geweest als nu
"nieuwe leren"

[J.J.J. Bokma]

Leer in de breede niet in de lengte

Iemand die verstand heeft van "alles" kan bijna niks
Iemand die alleen ervaring heeft met een hamer, kan alleen spijkers in de muur slaan

Er is dus een soort middenweg. Ik zou zeggen: in het begin: leer breed, en na een paar jaar: specialiseer. Je weet dan wat er te koop is, en wat je leuk vind, en hebt een voldoende breede basis om ook dingen die niet direct met je specialisme te maken hebben te volgen.

Verder: niet iedereen zit op een opleiding om alles leuk te vinden. Ikzelf voel mij meer thuis in een zwaar theoretische opleiding. (Ik leer liever hoe VBScript intern werkt, dan dat ik 40 uur scripts in elkaar moet draaien). In mijn "tijd" (begin jaren '90) was de UU een fijne plaats voor precies dat (inclusief een presentatie van Linus in 1994 :-D).

[Verwijderd]

Zullen we daar nog aan toevoegen: gebrek aan kundig personeel bij de klant? ICT afdelingen zijn al jaren weg en verder wordt alles behalve het management zo ongeveer geoutsourced. Je hebt rustig te maken met 6 verschillende detacheerders die allemaal komen uitleggen hoe een organisatie de bedrijfsvoering heeft geregeld, welke informatiestromen er zijn, welke werkstromen er zijn, wie welke verantwoordelijkheden heeft, welke informatiebehoefte er bij het management bestaat, et cetera. De organisaties die dat soort dingen nog zélf weten zijn zeldzaam aan het worden, en dat is eigenlijk nog veel erger. De klant kán zo niet eens weten wat hij wilt....

[JeroenB]

Als je uitlopende ontwikkeltrajecten, te hoge kosten, etc. allemaal ziet als "niet succesvol", dan vind ik het een redelijk wonder dat bijna de helft toch succesvol is. Ik zou persoonlijk eerder verwachten dat zo'n 90% meer kost dan gedacht

En er zijn natuurlijk heel veel redenen aan te wijzen. Wat vooral veel kost is het feit dat doelstellingen en schattingen vaak worden verward: als iets over 2 maanden af moet zijn omdat klant A dat nodig heeft, dan wil het niet zeggen dat het ook haalbaar is. Vaak wordt deze "target" echter wel als "estimation" aangenomen en faalt het project vervolgens om op tijd af te zijn. Dus het ontwikkeltraject loopt uit, het kost meer geld, etc. Maar waar komt dat door? Niet omdat de projecten inhoudelijk verkeerd worden uitgevoerd, maar omdat de gemiddelde manager denkt dat als hij een einddatum in een projectplan invult, dat die dan daarmee ook haalbaar is geworden.

[Niemand_Anders]

Allereerst behoren de milestones door het IT bedrijf te worden bepaald op basis van het werk en beschikbare mensen wat eraan kan werken. Ten tweede dient zodra aan development wordt begonnen de requirements worden bevroren. Als systeem architect / development manager geef altijd mijn geschatte uren * 1,5 door. Die 1,5 is erg belangrijk, developers kunnen namelijk ziek worden, kunnen vrije dagen opnemen, etc.

Verder bevatten alle door ons opgeleverde onderdelen unit, regression en systeem testen.

In 7 jaar dat ik nu management doe, heb ik slechts 1 maal een deadline met 2 dagen niet gered. En nog nooit zijn bij ons de kosten hoger uitgevallen dan begroot. Verder tekent de klant voordat wordt begonnen een overeenkomst waarin de kosten staan. Zijn wij meer tijd kwijt, dan kunnen wij dat niet aan de klant doorrekenen.

Overigens kunnen op de manuren die ik doorgeef aan de project manager niet bezuinigd worden. Willen ze de kosten voor de client goedkoper laten uitvallen, dan zullen ze een aangepast uur tarief moeten gebruikt of het 'management' voor nop moeten doen. Overigens zijn wij regelmatig enkele dagen eerder gereed dan de de opgegeven milestones.

Wij hebben dan ook alleen maar tevreden clienten. Wel zijn een aantal clienten 'weggelopen' omdat ze onze begroting (zowel tijd als kosten) niet realitisch vonden. Wij (ik) doe(n) namelijk niet aan pragmatische oplossingen. Die bijten namelijk altijd naar verloop van tijd terug met als gevolg uitloop en kosten overschrijving.

[supertheiz]

Als je kijkt hoe vaak de besluiten worden genomen en hoe de inzet wordt geregeld vanuit het bedrijf vind ik het niet gek.
Voorbeeld CRM:
Het zou moeten zijn dat je als bedrijf behoefte hebt aan meer inzicht in je klanten, of concrete problemen hebt. Vervolgens ga je op papier zetten wat je beter wilt en hoe. Hierna zoek je software en implementatiepartner.
Het gaat: Een bedrijf wil CRM. Waarom? Geen idee!. Er wordt niets op papier gezet, hiervoor wordt een implementatiepartner gezocht die ook de implementatie doet. Vervolgens worden er een paar mensen uit het bedrijf als adviseur aangewezen die nergens verstand van hebben.

Aan alle managers: Een tool is geen oplossing, maar een hulpmiddel om iets om te lossen!

[Nivado]

Ik heb bij een bedrijf gewerkt waar CRM volledig volgens hoe het zou moeten is geimplementeerd. Er werd een eisen en wensen pakket opgesteld ed. Vervolgens werden bij diverse leveranciers gekeken of ze er aan konden voldoen. De gekozen leverancier zou aan alle eisen en de meeste wensen kunnen voldoen.
Na de implementatie van het pakket bleek het pakket toch niet aan alle eisen kunnen voldoen.

Bovendien moet een CRM pakket eerst gevuld worden alvorens het gebruikt kan worden. Ten slotte zijn er mensen (mede) verantwoordelijk voor het voeden van nieuwe info in het systeem, die zelf niets aan het systeem hebben, en zien het systeem hoofdzakelijk als extra belasting.
Het grootste probleem van CRM is dat je er niet meteen iets mee kan. Het kost héél véél tijd en energie alvorens CRM iets gaat opleveren.

[ijdod]

Dan is het dus niet 'zoals het zou moeten' gedaan. Een sanity/reality check hoort daar ook bij.

[inquestos]

Sorry, maar 4 procent wat volledig mislukt is juist extreem laag!
Ik ken de exacte getallen niet meer, maar bij tastbare producten haalt nog geen 4% de grens van "erg succesvol". Je mag al heel erg blij zijn als je project break-even draait (<50% iig). De winst zit hem natuurlijk ook wel in de extremen aan de goede kant. Ik moet de cijfers (vrijwel exact dezelfde vraagstellingen ook) nog ergens hebben liggen, maar geloof me, als ICT'er mag je dan wel heel blij zijn met zulke getallen.

[woutur]

Neen, dat mogen ze niet. Jouw redenering gaat namelijk niet op. Het product dat ze implementeren bestaat immers al. Het is de software. Die is in 100% van de gevallen gelukt (in tegenstelling tot mislukt), anders bestond het niet op de markt. Tastbare producten kunnen op allerlei manieren erg succesvol zijn, bijvoorbeeld als ze de schappen halen. Waar jij misschien met succesvol op doelt is het percentage producten dat vanaf de ideefase uiteindelijk ook op de markt gezet wordt. Daar is dat percentage inderdaad erg laag van maar geenszins vergelijkbaar met het lukken of mislukken van ICT-projecten.

Zelf werkend bij de overheid kan ik vertellen dat vrijwel elk programma dat we gebruiken betreurenswaardig is. Van oracle e-business meuk, tot eigen ontworpen software. Het enige wat betrouwbaar werkt en een consistente interface heeft is maat-software uit begin jaren negentig. De rest heeft gezorgd voor zeer serieuze achterstanden in betalingen op allerlei gebieden. Merkwaardig genoeg worden in interne publicaties de invoeringen bejubeld, terwijl ik denk dat de laatste projecten als zeer onsuccesvol beschouwd kunnen worden.

[RutgerDB]

Ze vergeten nog een belangrijk punt, amateurisme door IT 'experts'. De markt trekt weer aan en dat merk je goed. Er komen steeds meer amateurs een gokje wagen in de IT.

1999/2000 was echt de top. Toen kon je als helpdeskmedewerker Fl. 100,- per uur verdienen. De meeste van dat soort figuren konden niet eens XP installeren

[a.prinsen]

Bij ons gaan eigenlijk lopen onze projecten meestal vast op tekortkomingen van de klant:

Interne machtstrijd bij de klant zelf:
Klant die pakket aanschaft zonder precies te weten wat hij wilt (de software moet immers Ingesteld worden naar de wensen van de klant)
Tegenwerkende interne organisaties zoals ondernemingsraad
Enorm lange trajecten om aan informatie te komen , etc etc etc...

Al dit soort problemen liggen vaak buiten de macht van de leveranciers maar worden gemakshalve wel als slechte project bestempeld.

Een klant (betrokkenen en verantwoordelijken) zal nooit zelf zeggen dat ze er zelf een potje van hebben gemaakt en de schuld altijd bij de leverancier schuiven. (zeker niet als het je baan zou kunnen kosten)

Problemen die bij ons zelf liggen kunnen we gelukkig altijd (redelijkerwijs) snel oplossen.

[Reactie gewijzigd door a.prinsen op 23 juli 2024 07:39]

[TheekAzzaBreek]

Maar dat hoort toch tot de standaardproblemen die je op moet lossen in je project? Als je alleen de techniek aanpakt en niet verder kijkt dan de software ben imho niet erg professioneel bezig.

@Janoz: dat komt regelmatig voor, ja. En dan vertel je de klant dus wat een enorm risico dat is, en bedenk je samen hoe je dat zou kunnen oplossen. De 'zachte' kant van de ict blijft nou eenmaal het belangrijkste: aansluiting bij de organisatie, acceptatie bij gebruikers en beheerders, dat soort dingen.

[Reactie gewijzigd door TheekAzzaBreek op 23 juli 2024 07:39]

[Janoz]

Dat kun je wel leuk zeggen, maar over het algemeen heb je te maken met een paar contacten bij de klant. Je mag al blij zijn wanneer je een paar representatieve mensen uit de gebruikers groep kunt ondervragen.

Bij de klant heb je meestal iemand die het specifieke traject als zijn spelekindje ziet. Hij is degene die wil beslissen wat het zou moeten kunnen zonder dat hij capabel is de gevolgen van deze keuzes te overzien.

[Civil]

Daar kun je toch begeleiding en advies in geven als organisatie die vaker met dergelijke trajecten te maken heeft en dus de valkuilen kent ?

[Verwijderd]

Duidelijk nog nooit zo'n traject doorlopen. Denk je nu werkelijk dat naar die adviezen geluisterd wordt als dergelijke figuren eenmaal hebben besloten dat het HUN project is? Vergeet het maar!

[ijdod]

Als de klant daarvoor wil betalen wel. Helaas willen ze vaak niet echt weten dat ze wat manko's hebben (net als de IT bedrijven zelf, overigens), dus dat is niet altijd zo makkelijk verholpen als gesteld.

[Verwijderd]

Goh, dit zou ik zelf geschreven kunnen hebben, heel herkenbaar. Meestal zijn het inderdaad de klanten die de voortgang van een project in gevaar brengen. Vaak willen ze voor een dubbeltje op de eerste rang, of ze weten juist niet precies wat ze nu eigenlijk willen. De ICT manager zal, wanneer hij/zij zich moet verantwoorden, geen minuut aarzelen om vervolgens alle schuld op de de leverancier af te schuiven.

Het is gewoon onderdeel van werken op projectmatige basis.

[homernt]

klopt maar toen had ook nog geen XP

Ik heb idd voobeelden gezien mensen die eigen winkel hadden en dan database beheerder worden met 0,0 feeling voor computers. Aaaargh.

Maar projecten mislukken niet vaak door amateurisme maar meer door mis management. Die van tevoren niet goed hebben na gedacht wat ze willen en/of gewoon dingen overhoofd hebben gezien. Duidelijk kaders stellen.

[vgroenewold]

Helemaal mee eens, hoeveel er zowiezo al mislukt door mismanagment. Het is echt schrikbarend als je dat grondig zou onderzoeken, ik hoor het van mensen "close to the top" in verschillende instanties continue.

Overigens is dat dus incompetentie van mensen, zowel van sommige IT "specialisten" als bazen.

[Snuffel]

Het zijn echt niet alleen de amateurs die falen, ook gerenommeerde bedrijven slaan geregeld de plank mis.

Ik heb bij meerdere bedrijven ICT trajecten gestart zien worden, en niet een daarvan is ofwel volgens plan danwel volgens wens uitgevoerd.
Ze hadden allemaal twee dingen gemeen: kosten werden ver overschreven en deadline werd in geen van de gevallen gehaald.
Let wel: GEEN van deze bedrijven was amateuristisch!

[brobro]

Amateurisme regeert de wereld. Ik zou wel eens willen weten wat de scores zijn van 'verander-trajecten' in het algemeen. Er gaat in organisaties zoveel mis, dat het me niet verbaasd dat het in de IT ook mis gaat.

Het is schering en inslag dat re-organisaties door het personeel zoveel mogelijk genegeerd worden en daardoor op niets uitdraaien.
Neem dan het wijdverbreide digibetisme en je verbaasd je hier niet over. De meeste mensen die geen bijzondere interesse hebben in computers kunnen er nauwelijks mee overweg en vrezen iedere nieuwe muisklik.

Een nieuw programma voldoet dan nooit aan de eisen, want als het 'iets kan' moet je er meestal 'iets over leren', de meest krachtige software is meestal niet in 5 minuten onder de knie. (denk aan photoshop, geavanceerde office functies, maar ook crm systemen)

[Janoz]

Mwah, ik zie het eerder andersom. Mensen die XP kunnen installeren en daarom denken dat ze een IT expert zijn....

[vgroenewold]

ps. Is het half mislukken van een project dan beter?

[pinockio]

Ik neem aan dat je Windows 98, NT of misschien 2000 bedoelt... XP bestond toen nog niet

[Upsilon]

De uitslag vind ik helemaal niet gek eigenlijk.
28% Toepassing voldoet niet (volledig) aan verwachtingen
Dit komt zonder meer door het feit dat er niet doorgevraagd wordt, dus dat bij de projectleiding niet bekend is wat de opdrachtgever exact wil hebben. Er wordt te weinig tijd gestoken in het vooronderzoek, waardoor iets gemaakt wordt wat er misschien op lijkt, maar misschien ook helemaal niet. Verder vinden opdrachtgevers het 'toch maar ict', dus niet belangrijk genoeg om er voldoende aandacht aan te geven. "Ik heb gezegd wat ik wil dus dat doen ze." Als de meningen niet blijken te stroken dan wordt het vaak veel te laat ontdekt.
23% Project is uitgelopen qua tijd
Ook een vaak gezien probleem. Dit komt vaak doordat opdrachtgevers 'ineens' de scope van het project wijzigen. Verder zijn er binnen ICT-projecten veel onvoorziene risico's en beheerst projectleiding het risicomanagement niet goed genoeg (anders zou uitloop afgebakend zijn).

Verder valt het me best mee in mijn optiek en vind ik het nogal een gekleurde berichtgeving als ik eerlijk ben. De samenvatting sluit eveneens af met de volgende alinea:

ICT-projecten zijn steeds vaker succesvol: een op de drie managers/professionals geeft aan dat projecten vaker succesvol zijn dan in voorgaande jaren, 9% heeft juist minder vaak succes en bij de rest is er geen sprake van verandering. Per saldo leiden projecten dus vaker tot succes dan voorheen.

[regmaster]

Tja, als ik kijk hoe het bij de overheid gaat dan klopt de stelling wel.
Er is te weinig inhoudelijke kennis aanwezig bij managers om te beoordelen wat voor impact projecten hebben. Heel vaak worden PID's voor projecten geschreven zonder medeweten van de ICT afdeling terwijl projecten steeds meer een ICT component hebben.
Kortom, aan het eind van de rit komt er eens iemand langs om te vragen of het project gestart kan worden en of er nog een werkstationnetje beschikbaar is om het tonnen kostende stukje software er ff op te zetten. De ontluistering is groot als het erop neer komt dat er ineens veel meer budget moet worden vrijgemaakt voor het ICT component dan gebudgeteerd was. Vaak verdwijnen projecten dan in de kast want er is geen geld meer voor de broodnodige aanpassing van de infrastructuur.
Gelukkig word men zich hiervan steeds meer bewust, helaas gaat die ontwikkeling slechts langzaam.