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.
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.