Een recent onderzoek van PM Solutions, een Amerikaans project management advies bureau, beschreef de top 5vijf 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.
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.