Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Vijf redenen waarom IT-projecten mislukken

Offshoring reikt helpende hand uit

Computable Expert

drs. Hugo Messer
CEO, Bridge Outsourcing B.V.. Expert van Computable voor de topics Outsourcing en Loopbaan.

Een recent onderzoek van PM Solutions, een Amerikaans project management advies bureau, beschreef de top 5\vijf oorzaken van het mislukken van een project. Het onderzoek bij 163 bedrijven geeft aan dat maar 47 procent van de projecten als ‘succesvol’ gezien wordt.

De top 5 oorzaken voor problemen bij projecten volgens het onderzoek:

Eisen: Onduidelijk, geen overeenstemming, geen prioriteit, tegenstrijdig, dubbelzinnig, onnauwkeurig.
Mensen: Niet genoeg mensen, conflicten tussen mensen, hoe lang mensen hun positie behouden is onduidelijk, slechte planning.
Schema’s: Te strak, onrealistisch, en veel te optimistisch.
Planning: Gebaseerd op te weinig data, ontbrekende items, niet genoeg detail, slechte schattingen.
Risico’s: Niet geïdentificeerd of aangenomen, niet gemanaged.

Binnen it-afdelingen of software firma’s is nummer twee vaak het belangrijkste knelpunt. Omdat er niet genoeg vaardige mensen zijn (meestal door het tekort aan getalenteerde mensen op de it-markt), kunnen producten niet op tijd klaar zijn, maatwerk projecten kunnen niet binnen de deadline geleverd worden, de druk op de it-afdeling groeit van dag tot dag. Hoewel er geen oplossing is die al deze problemen op kan lossen, kan offshoring een grote verbetering zijn. Het belangrijkste ingrediënt voor verbetering is ‘mensen’.

Eisen

In it-projecten is het altijd moeilijk om een duidelijk beeld van de eisen te krijgen. Mensen (vooral gebruikers) kunnen zich geen voorstelling maken van de uitkomst van een project en pas als de uitkomst er al is, worden de eisen duidelijker. Offshoring helpt hier omdat het mensen dwingt meer tijd te investeren in het ontwikkelen van een duidelijk eisenpakket en het dwingt mensen ook om na te denken over processen.

Mensen missen de frequente communicatie die voorkomt als ze samen op kantoor zitten. Hoewel dit ook nadelen heeft begrijpen de meeste outsourcers één ding: als ik niet duidelijk opschrijf wat ik wil, zal mijn team in het buitenland het op hun eigen manier interpreteren en zal de uitkomst niet zijn wat ik voor ogen had. Een paar weken geleden sprak ik een klant die het zo zei: ‘omdat ik mijn programmeur precies moet vertellen wat ik nodig heb, moet ik nadenken over wat ik nou eigenlijk wil. Dit is een voordeel, omdat de oplossingen waar we mee komen veel sterker zijn en het bespaart ons tijd die we eerder nodig hadden om resultaten heen en weer te sturen’.

Een populair software development process is ‘agile’ of ‘scrum’. Wat voor proces er ook gebruikt wordt (het kan een strikt proces volgens het Agile Manifesto zijn of een eigen ontwikkeld proces), omdat mensen een proces moeten ontwerpen, documenteren en implementeren, verandert er iets. Meer specifiek, behandelen Scrum en Agile het probleem in het opstellen van requirements: in plaats van te mikken op 100 procent requirements vooraf, worden projecten in kleinere stukjes gehakt en de uitkomst van die stukjes wordt iedere 2 tot 4 weken getest, waardoor een project effectiever naar het einddoel wordt gestuurd.

Mensen

Hier zit het grootste voordeel voor mensen die in zee gaan met offshoring. Het is makkelijker om hooggeschoolde mensen aan te trekken omdat er toegang is tot een grote arbeidsmarkt van het offshore land. De mensen zijn normaliter geen werknemers (tenzij het een dochteronderneming is), dit maakt het makkelijker voor de outsourcer om teamleden toe te voegen of te verwijderen wanneer dit nodig is. Als er een project release gepland staat en er moet sneller gewerkt worden, kunt u makkelijk wat meer mensen aannemen, hierdoor wordt het waarschijnlijker dat de deadline gehaald wordt.

Schema’s, planning and risico’s

Schema’s kunnen realistischer gemaakt worden door meer of minder mensen voor een team aan te nemen. Planning kan niet direct vereenvoudigd worden maar indirect wordt het vaak wel verbeterd door betere processen te creëren. In veel gevallen gaan bedrijven meer ‘agile’ ontwikkelen waardoor er automatisch kortere ontwikkelingscycli ontstaan en deze zijn makkelijker te plannen en te managen.

Sommigen zeggen misschien dat offshoring voor meer risico zorgt bij een project. Maar dat hoeft niet zo te zijn. Als het werk op een gestructureerde manier georganiseerd wordt door constant processen te verbeteren kunnen de risico’s zelfs verlaagd worden. Meestal gaat het niet om het risico zelf, maar om het besef dat het er is. Offshoring dwingt mensen na te denken en beter te plannen en zorgt ook voor meer mensen die mee kunnen denken (bijvoorbeeld een procesmanager aan de offshore kant). Terwijl er nagedacht wordt over ‘hoe we gaan werken’ kunnen risico’s opgemerkt worden voordat er begonnen wordt met werken. En door frequente feedback (dagelijkse en wekelijkse meetings) worden verdere risico’s snel opgemerkt en kan er effectief gehandeld worden.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

De laatste drie alinea's geven wat mij berteft aan wat een vreemde gedachtenkronkel er aan de orde is. Als je mensen al uitsluitend als geschoolde productiemiddelen ziet, wat is dan het verschil met de ZZP-er of de detakracht hier? En als strakkere planning of het onderkennen van risico's etc. de gewenste efficiency brengt, dan doe je dat toch niet alleen als je gaat offshoren? Als dit werkelijk gebeurt "zoals het hoort", dan lopen projecten thuis net zo soepel en gesmeerd. Wie gaat er dan in vredesnaam nog offshoren?

Klinkt een beetje als Een vrouw is negen maanden zwanger. Laten we gaan offshoren. Negen vrouwen zijn dan een maand zwanger, dus bespaar je tijd.

Dit is duidelijk geschreven door een project management bureau. Wijs de mensen aan en begin erop te schieten. De meeste mensen betrokken bij het proces wijzen al tijdens het project op de overige vier oorzaken, maar worden stelselmatig genegeerd. Offshoring is geen oplossing. Het is slechts het verschuiven van het probleem.

@Redactie: In uw nieuwe voorwaarden staat dat reacties met (verkapte) reclame voor producten of diensten worden bewerkt of niet geplaatst.

Dhr. Messner grijpt hier een onderzoek aan betreffende het mislukken van ict-projecten om zijn eigen product 'dienstverlening bij offshoring' t.b.v. Bridge Outsourcing B.V. te verkopen. Dat gebeurt nu al maandenlang. Kunt u niet eens iemand aan het woord laten over dit topic die er niet zelf aan verdient?

Dat het aan de mensen ligt, dat is absoluut niet waar. Dat er niet genoeg mensen zijn is ook niet waar. Onduidelijkheid en onzorgvuldigheid is de kern. Het probleem ligt hem in het voortraject. Wat moet er precies komen, voor wie en wat voor mogelijkheden moeten er in het project zitten. Teveel mensen op één project, met verschillende werkwijze, kan ook voor problemen zorgen. ook een wisselend persooneelsbestand.
De 'praatjesmaker' heeft vaak onvoldoende technische kennis om het project goed in te kunnen lijven. Niet goed verdiepen voor wie het is en wie het gaan gebruiken. 'Denken in solutions' is fout, solution dit en dat. Zo kan ik nog wel even doorgaan.

Beste Kees,

"Kunt u niet eens iemand aan het woord laten over dit topic die er niet zelf aan verdient?".

In 2009 ben ik, na 45 jaar werkzaam te zijn als ICT-er, gepromoveerd op dit onderwerp aan de Middlesex University te Londen. Het proefschrift is ook in Computable aan de orde geweest. Het proefschrift (520 pagina's) geeft 139 factoren met als big hitters:
- poor project management;
- deadlines are unrealistic;
- poor communication;
- incomplete/weak definition requirements;
- insufficient involvement of future users;
- lack of senior management involvement and commitment;
- lack of professionalism.

Outsourcing kan alleen als kapstok gebruikt worden om dit soort problemen aan te pakken. Hopelijk "dwingt" het de organisatie om de problemen dan aan te pakken. Anders ben je bezig om problemen te outsourcen en dan krijg je alleen maar problemen terug.

@Aart van Dijk
Wat mij specifiek stoorde aan dit artikel is het feit dat het genoemde onderzoek niets te maken heeft met de primaire boodschap ervan. De schrijver begint met een summiere opsomming van de 5 belangrijkste punten van het onderzoek en zegt vervolgens : "Hoewel er geen oplossing is die al deze problemen op kan lossen, kan offshoring een grote verbetering zijn."

Dat is een propositie zonder enige semantieke waarde.

Eerst wijzen naar een zorgvuldig gepleegd onderzoek, daarna een statement met het woord "kan" erin, waarmee de auteur in feite aangeeft dat elk verband tussen offshoring en de eventueel daarmee gerealiseerde verbeteringen in IT-projecten op louter toeval berust.
Waarschijnlijk realiseerde de auteur dat, waarna hij alsnog het woord "grote" toevoegde om de nietszeggendheid nog enigzins te compenseren.

Dit artikel is duidelijk bedoeld om managers die willen besparen op mensen door goedkope offshore arbeid aan te wenden, daar één of andere "management-onzin" reden voor te geven (of als reclame voor capgemini?).

Al heel wat van mijn kritiek is reeds door andere mensen geplaatst, ik kan nog toevoegen dat offshoring helemaal niet zal helpen om vooraf het eisenpakket samen te stellen. Elke poging om op voorhand perfect de requirements vast te leggen is gedoemd te mislukken. Het enige wat helpt is snelle feedback via b.v. prototyping en een zo direct mogelijke communicatie tussen de ontwikkelaar en de klant, wat alleen maar bemoielijkt wordt door outsourcing.

Dit artikel geeft de essentie keurig weer in de 5 punten. Vervolgens geeft het een goede aanzet om van de eisen naar de mensen te gaan. Maar daarna wordt het een reclame praatje als je het mij vraagt.

Heel veel projecten lopen mis, simpel omdat de doelstelling gewoon niet smart genoeg is vastgelegd. We willen "een" systeem dat "iets" doet. Tja, dan krijg je tijdens het bouwen leuke uitdagingen. Aan de eisen van het te bouwen systeem moeten ook eisen gesteld worden (requirements management), zelf maak ik gebruik van een checklist van de 10-geboden van requirements.
Als hieraan is voldaan, dan is het met een normaal presterende projectleider en voldoende mensen (daar is een outsourcing land dan soms wel weer makkelijk voor) een peuleschil om binnen budget, binnen tijd en een gegarandeerd correct systeem op te leveren.

Reclamepraatje of niet, er zit wel een kern van waarheid in het betoog van Hugo. @Koen: Overigens snap ik jouw opmerking over reclame voor Capgemini niet, want die kom ik bij geen enkele reactie tegen...

Als expert in Offshoring heb ik de vraag "Poldermodel of Fabrieksaanpak?" in vele cultuurworkshops aan de orde gesteld. Het is misschien wel dé hamvraag in een succesvol project. Wat in veel trajecten nodig is dat er een creatief deel is én een fabrieksdeel. In het creatieve deel zit de denkkracht, wordt alles ter discussie gesteld, weet iedereen het beter. In het fabrieksdeel zit alles op slot: de requirements zijn bevroren, de aanpak ligt vast. Er moeten meters gemaakt worden! De kunst is nu deze twee in goede harmonie met elkaar te laten samenwerken. Nou wil het toeval dat we in Nederland meer op het poldermodel zitten en in India meer op het fabrieksmodel. In mijn ervaring een perfecte basis: de beroemde "Best of both worlds". Het is van belang wel duidelijk te zijn naar beide bloedgroepen over hun rol en de rol van de ander. Wil je naar een volwassen "One-shoring" organisatie dan moet je nog een stap extra doen: zorg dat er in India mensen zitten die het Poldermodel snappen en naleven en vice versa: zorg dat er in Nederland mensen zijn die weten hoe het fabrieksmodel werkt en dit naleven.

Kern van mijn betoog: er zitten in offshoring wel degelijk elementen die kunnen helpen. Helaas is 'een onsje offshore' niet te koop en al zeker niet als tovermiddel. Invulling van offshoring is ook mensenwerk en je weet wat er kan gebeuren als je medicijnen verkeerd gebruikt.

Tot slot: ik zal nooit pleiten voor offshoring als middel om een project te redden. Offshoring moet je strategisch inzetten. Maar dit gezegd hebbende realiseer ik me dat dit in het algemeen geldt: als projecten mislukken ligt de oorzaak veelal buiten het project: organisatie, governance, procesinrichting, enz.

Dit artikel bevestigt de 2-jaarlijkse uitgaven van het CHAOS-Standish report (Amerikaans universitair onderzoek). Slechts 1/3 van de IT projecten kent geen noemenswaardige problemen, de rest wordt te laat opgeleverd, of met de weinig functionaliteit of van slechte kwaliteit en alle mogelijke combinaties.
Onrealistische verwachtingen en daaraan gekoppelde oplossingen (9 vrouwen voorbeeld), slechte planningen, optimische experts (mensen die veel weten van een deel maar een project is meer dan dat deel) maken ook daar deel uit van de top 5. Het gebruiken van metrieken, historische data en daarvan afgeleide parametrische modellen kunnen heel veel ellende voorkomende. Om een of andere reden is cost engineering een discipline die in de IT onterecht niet aanslaat.

@Ton Dekkers
Het is nog maar de vraag of een cost engineer beschikt over goede probabilistische modellen beschikt om
een betrouwbare kostenraming op te stellen voor een groot overheidsproject bijvoorbeeld. Daarnaast lijkt mij het beheersen van die kosten, cost controlling, wezenlijk meer van belang.

Is de reactie van hwoolschot echt zo goed? Nu is hij expert in offshoring, dus enerzijds zal hij wel weten waar hij het over heeft, maar anderzijds verdient hij zijn boterham aan het fenomeen, dus bevat zijn artikel automatisch verdedigende waarden. In mijn ogen is offshoring het oplossen van een probleem zonder de oorzaak ervan aan te pakken.. Gelukkig waarschuwt hij ook voor “verkeerd medicijngebruik” en dat valt hem te prijzen. Dat zijn tevens de woorden die we moeten onthouden, want dat geldt thuis, maar ook over de grens. Ik blijf van mening dat wij in Nederland in staat moeten zijn om projecten van A tot Z te realiseren. Dat wij thuis de mix moeten kunnen vinden tussen ‘polderen’ en ‘fabrieken’. Tijdens elke fase is er ruimte voor een creatief proces, behalve tijdens het programmeren; dan is alles vastgelegd, besloten en overeengekomen. We zitten dan niet op een programmeur te wachten die eerst nog eens kritisch naar de oplossing kijkt. Als het dan nog mis gaat, zou dat ook het geval zijn als e.e.a. geoffshored was. Lood om oud ijzer dus. En dan komt de heer Dekkers (ook al vijf sterren) met metrieken, modellen en cost-engineering. Het zou beter zijn als hij komt met eenvoudige (en tegelijkertijd o zo moeilijke) oplossingen voor basisprincipes als het maken en nakomen van afspraken. Dan zou het gemiddelde project er al een stuk beter voor staan.

Beste hk, allereert wil ik even kwijt dat ik geen geld verdien aan offshoring, geen idee waar je dat op baseert. Of mijn reactie 5 sterren waard is weet ik ook niet, het is feitelijk ook niet zo belangrijk. Wat ik uit ervaring weet is dat Offshoring in ICT nog steeds zeer beladen is en emotionele reacties uitlokt.
En dat is op zijn zachts gezegd vreemd te noemen. Geen enkele industrie kent dit fenomeen. Ik hoor nooit iemand bij de VW-dealer vragen of alle onderdelen wel uit Duitsland komen. Mijn nieuwe Asics (ik mag graag hardlopen) komen zeker niet uit Nederland, in Twente is het weefgetouw al heel lang verdwenen. Dus waarom zouden wij tot doel moeten hebben in Nederland een project van A tot Z uit te voeren?

Terug naar de kernvraag: "Is Offshoring een middel om IT-projecten te verbeteren?"

Toen ik er mee begon (in de jaren negentig) had ik sterk mijn twijfels. Er zijn genoeg redenen te verzinnen waarom projecten juist met offshoring gedoemd zijn te mislukken.

Als wiskundige ken ik een aanpak waarmee stellingen kunnen worden bewezen: het bewijs uit het ongerijmde.
Voor niet-wiskundigen: ga uit van het omgekeerde en toon aan dat dit tot een negatieve conclusie komt.
In mijn geval: ga ervan uit dat offshoring wel werkt, doe er dus ook alles aan. Mocht het dan nog mislukken, dan is het ook duidelijk aangetoond.

Dit bleek een lastige klus: om offshoring te laten werken was er veel nodig....goede processen, betere communicatie, strakkere afspraken over scope, tijd, geld, kwaliteit. Betere tooling ook. Dit alles bleek een spin off voor betere projecten. Net als het Y2K-probleem veel Beheer en Onderhouds omgevingen heeft opgeruimd.

In mijn geval heeft het dus gewerkt. Maar ik zag ook veel organisaties enorm worstelen met dit fenomeen. Offshoring werd zeer kort door de bocht ingezet als tovermiddel. Managers die na 1 bezoekje aan India dachten het ei van Columbus te hebben gezien.
Laat ik duidelijk zijn: Offshoring is uitbesteden voor gevorderden. Het vraagt om een lange adem en moet op alle nivo's (strategisch, tactisch, operationeel) nauwkeurig worden geimplementeerd.

Maar doe je dat, dan zijn de voordelen op termijn groot en zal de ICT in staat zijn eindelijk volwassen te worden net als de industrie.

Beste HWoolschot,

Uit uw reactie lees ik een aantal oplossingen voor het vaker succesvol laten verlopen van IT projecten. Deze staan (naar mijn mening) volledig los van offshoring maar zijn meer een positief gevolg van offshoren.

Ik (consultant/scrum master) ben van mening dat we prima in staat zijn om succesvol projecten uit te voeren, maar dat we wel meer volwassen kunnen worden.

Stuur dit artikel door

Uw naam ontbreekt
Uw 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.