Zoals bij alles is er bij offshoring geen heilige graal voor success. Er zijn bij offshoring veel factoren die invloed hebben op de mate van succes van uw project. Maar ik denk dat er twee dingen zijn die van groot belang zijn.
1. De mensen
Vorige week sprak ik een Amerikaanse klant, een starter uit Nashville die enkele maanden met een Indiaas team had gewerkt. Hij vertelde me dat ze op kantoor grappen over dat de namen van de mensen waar ze mee werken niet veranderen, maar de mensen wel. Ik ben nu een tijd actief in de offshoring industrie en weet dat deze grap soms waarheid is. Veel offshore software ontwikkeling bedrijven laten hun klanten niet direct contact onderhouden met de programmeurs. Ze ‘verstoppen’ ze achter verschillende lagen van projectmanagers en ontwikkelaars.
Het belangrijkste om een bedrijf succesvol te maken zijn de mensen die bij het bedrijf werken. Als je een offshore of nearshore team inhuurt, denk ik dat je wil weten wie er in jouw team werkt. En je wil ook met hen persoonlijk samenwerken, want het zijn de individuele teamleden die het werk doen, niet de projectmanagers.
2. Het communicatieproces
Alles hangt en staat met communicatie. Toen ik Bridge oprichtte in 2005, werkte ik samen met offshore en nearshore softwarebedrijven. Wat ik vaak hoorde was ‘Ja, stuur me maar een projectverzoek en dan doen we het project’. En zo wordt het meeste offshore werk gedaan: stuur de specificaties op, maak een schatting, word het eens over een prijs en deadline en starten maar. Als je geluk hebt zal de juiste leverancier een goedlopend proces hebben. Maar in veel gevallen zullen communicatieproblemen ervoor zorgen dat er problemen ontstaan bij het afronden van het project. Wat nu?
Om een structuur aan te brengen in de communicatie is mijn advies om aandacht te besteden aan de volgende 4 punten:
A. Softwareontwikkelingsproces
Denk na over ‘hoe gaan we werken’ en het communicatieproces dat het softwareontwikkelingsproces ondersteunt. Vooral Scrum heeft veel opties zoals sprintplannen, dagelijkse stand-ups en takenschatting, die ervoor zorgen dat er over grenzen gecommuniceerd kan worden..
B. Word het eens over een dagelijks en wekelijks vergaderingritme
De frequente interactie die normaal gezien op kantoor is, mist bij offshoring. Het is daarom belangrijk om vaste tijden in te stellen waar de vooruitgang kan worden besproken. Het is goed om een dagelijkse vergadering te houden waar bij je vraagt, a. wat is er gedaan? b. wat gaat er nog gedaan worden? c. waar zit je vast? En in de wekelijkse vergadering kan er een uitgebreidere evaluatie gedaan worden over het project, de taken en de communicatie.
C. Gebruik de juiste softwaretools
Er zijn veel tools beschikbaar die samenwerking tussen verschillende teams ondersteunen. Je hebt een projectmanagementtool nodig dat zich bezig houdt met planning, schattingen, tijdsindeling, taken, bugs, het opslaan van documenten.
D. Definieer verantwoordelijkheden
Maak functieprofielen voor iedereen die betrokken is bij de samenwerking. Dit zorgt ervoor dat iedereen precies weet wat er van hem of haar verwacht wordt en door dit te bespreken wordt het ook duidelijk.
Om samen te vatten, er is geen geheime sleutel tot success, alles hangt en staat met het creëren van de juiste routine, zodat mensen het juiste gedrag vertonen. En om dit te doen is het belangrijk dat je tijd investeert in het zoeken naar de juiste mensen en dat je nadenkt over hoe je met ze gaat communiceren.
Als je dat nu allemaal zo keurig organiseert, afspreekt en nakomt, dan ben je kennelijk “in control”. Wat is dan nog het argument om te gaan offshoren? Wat daar dan nog beter aan dan werken met (lokale) eigen of ingehuurde mensen?
Dat kan dan alleen maar de prijs zijn. Ik ben daarom wel nieuwsgierig waar het omslagput ligt. Wat is de kritieke omvang van een project waarbij offshoring gaat lonen, vooropgesteld dat je aan de in het artikel genoemde voorwaarden voldoet?
Ik denk dat hoe beter je de zaken voor elkaar hebt, hoe minder aantrekkelijk het is de grens over te gaan – het omslagpunt schuift op. Natuurlijkzijn die tips waardevol, maar niet omdat alleen offshoring dan beter loopt; projecten lopen sowieso beter als je organisatie en afstemming in orde is en je de juiste rollen en de juiste routine hebt gedefinieerd. Bedrijven die daar meer in investeren kunnen voor de uitvoering gewoon in Nederland blijven shoppen. Is ook nog beter voor de werkgelegenheid in de Nederlandse ICT sector en goed voor de economie.
1a) klanten die direct contact onderhouden met programmeurs. Haalbaarheid hiervan is sector-specifiek lijkt me. De meesten van ons hebben vast wel een smartphone, pc, navigatiesysteem enz. Hebben we ooit contact met de programmeurs van microsoft, apple, android, tomtom etc? Ik gok zo van niet. Maar als ik een nieuwe windows versie koop, beschouw ik mezelf toch als klant.
Indirect deel ik de mening wel: het helpt als je ontwikkelaars weten wat ze maken, hoe het past in het grote geheel en als ze regelmatig contact hebben met de architecten en testers “aan de andere kant”
1b) je wil weten wie er in jouw team werkt. Ja, mee eens. Maar dat wordt wel een duur grapje. Als ik een weekje naar India ga om mijn collega’s daar te leren kennen, kost dat, alleen aan reis- en verblijfskosten, al snel net zoveel als 2 manweken werk. Stuur je meerdere mensen, meerdere malen die kant op, dan creëer je indirect een behoorlijke kostenpost voor het project, zeker gemeten naar de maatstaven van je offshore-collega’s
2a) hoezo is dit nodig, die bedrijven in India zijn toch allemaal CMM(i) level 3 of hoger?
(sorry, het cynisme neemt af en toe de overhand)
2b) op papier klinkt dit heel goed. In de praktijk gaat dit vaak tegenvallen. Waarom: het model wat hier geschetst wordt werkt bij ons vanwege onze typische communicatiestijl. Mensen in het verre oosten hebben een andere communicatiestijl, zullen niet snel om hulp vragen en hebben vaak andere interpretaties van begrippen als “klaar” en “kwaliteit”
2c) een projectmanagement tool dat zich bezighoudt met bugs en het opslaan van documenten? Dit is geen pm-tool meer. Wat je nodig hebt zijn tools of een tool-suite die “collaborative software development” ondersteund (sorry, ik kan hier zo 1-2-3 geen goede vertaling voor bedenken). Typisch dat hier alleen over documenten en bugs gesproken wordt. Het helpt nog veel meer als je ook je broncode van de software kunt delen. Dan kun je namelijk rechtstreeks bij elkaar in de “keuken” meekijken. Dit geeft bijvoorbeeld ook de mogelijkheden peer-reviews over verschillende lokaties te doen, zodat je vanuit Nederland kunt beoordelen of men zich op de andere lokatie goed aan de architectuur en ontwerpregels houden.
Maar, vergeet vooral niet: “a fool with a tool, is still a fool!!!”
2d) gaat dit helpen, ook hier heb ik mijn twijfels bij. Kijk ik binnen de eigen organisatie, hebben we prachtige functieprofielen, maar ook mensen die de kantjes eraflopen, of niet alles kunnen/willen/mogen doen wat er in het profiel staat. Ook de manier waarop dit ingevuld wordt verschilt per medewerker. Omdat je lokaal zit, weet je dit, kun je het daar waar nodig bijsturen. Op afstand wordt dit allemaal veel complexer. Gecombineerd met cultuur en taalverschillen geloof ik niet dat dit veel gaat helpen
Wat is dan wel de sleutel tot succes?
De vraag insinueert dat offshoring per definitie tot succes leidt, en daar heb ik hele grote vraagtekens bij….
Al jarenlang word ik geconfronteerd met het fenomeen offshoren. Met aandacht heb ik dit stuk van Hugo gelezen. En wederom is er een “specialist” aan het woord die zijn eigen winkelnering probeert te promoten.
Ik daag de Computable en haar lezers uit om deze fabel nu eindelijk eens te ontkrachten, laat hierover nu maar eens een brede maatschappelijke discussie over ontstaan.
Helaas is er hier in dit medium te weinig ruimte om alle praktijkvoorbeelden die ik de laatste 10 jaar heb mee mogen maken aan te halen. Maar in ieder geval steekt er 1 ervaring met kop en schouders bovenuit. IT zit zo in de business verweven dat de afstand business — IT niet te groot kan zijn. De ITer aan de andere kant van de wereld heeft geen flauw benul van het business proces, meer concreet: Kent de ITer in Azie de NL. hypotheken? Neen. Hoe moet hij dan in godsnaam het geautomatiseerde verwerkingsproces beheren.
Even nog een naschrift bij mijn vorige reactie: Een goed bevriend echtpaar heeft een (vakantie) woning in India en is regelmatig 3 maanden daar. Ik hoor iedere keer bij hun terugkomst de meest smeuiige verhalen over bv. de werkattitude daar.
Gekscherend hebben we al kunnen concluderen dat de jaren 70 televisieserie ” It ain’t half hot mum” geen komedie is, maar pure werkelijkheid.
En vooruit dan, nog een argument: Eigen initiatief of creativiteit wordt in Azie niet op prijs gesteld, sterker nog wordt zwaar afgestraft. Niet alleen de koe, maar ook ISO20K en KPI’s zijn heilig en dit smoort iedere vorm van zelf nadenken in de kiem.
Gartner heeft zojuist een artikel geschreven over onshoring :
http://www.collaborative.com/uploads/file/Gartner Newsletter- The Onshoring of IT Services.pdf
“There is a growing body of evidence that suggests teh actual cost of offshoring is significantly higher than a simple comparison of dollars per hour. Challanges with software and testing quality, required rework creating inefficiency in the software development process, additional effort because of time zone challanges, language and other communication issues, high turnover (up to 40% annually in some cases), and intellectual property ans security risks.”