Het is niet gemakkelijk om offshoring succesvol te maken. Om grensoverschrijdend, met verschillende culturen en talen te werken. Als u ervaring heeft met (het managen van) een offshore team, heeft u waarschijnlijk dagen gehad waarop u met uw handen in het haar zat? Het goede nieuws is dat u uw leven gemakkelijker kunt maken als u zich op de juiste dingen richt, zo kunt u offshoring succesvol maken zonder met de handen in het haar te zitten.
Er is een aantal veel voorkomende en voorspelbare problemen bij offshore samenwerkingen. Een combinatie van deze problemen leidt vaak tot de conclusie dat ‘offshoring niet werkt' of dat ‘het niet de resultaten geeft die we verwachtten'. De meeste mensen geven één onderdeel de schuld: communicatie. Als u ervaring heeft op dit gebied, dan heeft u waarschijnlijk momenten meegemaakt waarbij u te veel tijd besteedde aan het uitleggen van taken dan u voor ogen had? U kon de deadline niet halen omdat het offshore team de eisen niet begreep maar u kwam hier pas na de deadline achter? De vraag is nu: waar moet u op letten zodat offshoring succesvol is? Mijn ervaring leert dat er twee paden zijn, te weten focus op het software ontwikkelingsproces en focus op het communicatie proces.
Beiden zijn belangrijk en moeten verbeterd worden. Bij het communicatie proces kan het meeste gewonnen worden. Als dat goed zit, zal het ontwikkelingsproces automatisch verbeteren. Als u echter de nadruk legt op het software ontwikkelingsproces, kan het zijn dat feedback ontbreekt die ervoor zorgt dat iedereen van het proces leert. In het communicatie proces iseen aantal belangrijke gebieden waar u zich op kunt richten zodat uw offshore project een succes wordt:
1. Creëer een duidelijke feedback structuur: vraag zowel de onshore als de offshore teams elkaar steeds feedback over hun prestaties te geven. Dit kan geschieden door een wekelijkse meeting die een vaste agenda heeft waarin onderwerpen zoals ‘wat er vorige week goed ging, wat er vorige week fout ging, wat zijn de 2-3 gebieden waar er verbetering mogelijk is' behandeld worden. Daarnaast kunt u beide kanten vragen de individuen in het team of de samenwerking in zijn totaliteit een cijfer te geven. Als u dit cijfer elke dag,week en/of maand krijgt kunt u een patroon zien en daardoor worden dingen duidelijker.
2. Creëer verschillende rollen voor tactische en proces gerelateerde verantwoordelijkheden: De persoon die verantwoordelijk is voor het dagelijks managen van de projecten krijgt vaak een tunnelvisie. Hij is erg betrokken bij de ‘wat' (de taken, de deadlines, de eisen) en hij ziet de ‘hoe' (het proces, de verantwoordelijkheden, de dagelijkse routine) niet meer zo duidelijk. Door deze rollen te scheiden en iemand aan te stellen die zich op het dagelijkse werk richt en iemand anders aan te stellen die als supervisor fungeert, creëert u de structuur die nodig is voor doorlopende verbetering.
3. Creëer een leermoment: Organiseer een tweewekelijkse of maandelijkse meeting van twee uur waarin zowel de tactische mensen als de supervisors een gemeenschappelijk doel hebben: leren hoe de samenwerking verbeterd kan worden (en natuurlijk: actie ondernemen). Een voorbeeldagenda: a. goed nieuws/prestaties; b. Wat hebben we de laatste maand geleerd dat de samenwerking kan verbeteren (laat iedereen verplicht 2-3 suggesties geven?) c. Wat kunnen we morgen implementeren, wie doet het en wat is de deadline?
De centrale focus met deze instrumenten is: feedback en leren. De mensen die betrokken zijn bij de samenwerking zijn slim en ervaren genoeg om hun werk iedere dag te verbeteren. Maar ze moeten in staat gesteld en gestimuleerd worden om hun hersenen te gebruiken en de gebieden waar verbetering mogelijk is te vinden. Ze hebben ook structuur nodig om deze verbeteringen te kunnen implementeren en actie te ondernemen.
De uitkomst van deze drie instrumenten is vaak drievoudig: 1. De persoonlijke relaties worden sterker, waardoor alles wat het team doet beter wordt; 2. Het softwareontwikkelingsproces verbetert elke dag, elke week. 3. De communicatie wordt soepeler. Het eindresultaat: een offshore samenwerking die creatieve output , gelukkige teamleden en groei voor uw bedrijf creëert.
Allemaal prima. Wat er echter aan voorafgaat en tegelijk de basis is van een succesvolle offshoring is, ik herhaal het nog maar eens, kennis van de cultuur en wijze van communiceren van de samenwerkingspartner. Echter die kennis ontbreekt bij vrijwel alle offshoringsbedrijven en zogenaamde experts op dit gebied, zowel bij Nederlanders als bijvoorbeeld Indiers
Helemaal mee eens. Ik heb zelf ruime ervaring met offshoring naar India en het aansturen van teams daar. Niet alleen software ontwikkeling, maar ook bepaalde design aspecten. Wat Hugo terecht aangeeft is dat communicatie alles is. Wat onderbelicht wordt, zijn de grensoverschrijdende cultuurverschillen. Het idee van een duidelijke feedback structuur creëren is leuk, maar het moment dat iemand uit India daadwerkelijk eerlijke (en dus bruikbare) feedback geeft moet ik nog meemaken. Vaak komt er wel feedback, maar er wordt al gauw naar onze mond gepraat.
Een heel ander onderwerp uit de praktijk: zijn wij als ‘opdrachtgevers’ verantwoordelijk voor arbeidsomstandigheden aan de andere kant? Door onjuiste feedback (=slechte communicatie!) bestaat het risico dat we steeds hogere eisen stellen aan prestaties van het offshore team. Hierdoor loopt de druk vaak hoog op, en zijn werktijden van 7×16 uur geen uitzondering. Wat voor effect heeft dat op de producten die geleverd worden? Zijn de teamleden dan gelukkig? Waar sommige verklaren dit niet ons probleem te vinden ben ik van mening dat dit wel degelijk ons probleem is.
Concluderend: Ja met communicatie valt of staat alles, maar er is meer dan dat. Probeer ook eens te vragen aan de offshoring partij hoe zij graag aangestuurd willen worden. De cultuurverschillen zijn tenslotte enorm – mijn advies is om deze vooral te erkennen, te begrijpen en vooral te accepteren.
Offshoring gaat over geld. Wat ontbreekt is hoe de inverstering in tijd, mensen en dus alweer geld voor al die verbeteringen t.a.v. communicatie verrekend moeten worden. En als die verborgen kosten inderdaad verrekend zijn, is de offshoring dan nog wel een succes te noemen?
De schrijver van dit artikel impliceert dat als de communicatie goed verloopt, de software ontwikkeling als vanzelf een succes is. Uiteraard spelen er ook andere zaken mee, zoals de kwaliteit van het personeel en daarmee ook van de implementatie. In de praktijk blijkt het erg moeilijk om ‘rotte appels’ uit het team te verwijderen (vooral als ze lid van een hoge kaste zijn).
Een ander intrinsiek probleem van offshoring is dat er in de toekomst steeds minder mensen hier in staat zullen zijn om een goede functionele specificatie te schrijven.
Bert en Martijn, bedankt voor de invalshoek ‘cultuur’. Misschien is het goed als jullie handvatten geven over hoe deze culturele verschillen te overbruggen zijn?
Mijn ervaring is dat een belangrijk ‘middel’ om de cultuur te overbruggen juist feedback/meetings zijn, waarbij het essentieel is dat de teamleden elkaar regelmatig in levende lijve ontmoeten.
Het lastige met cultuur is dat het een ‘ongrijpbaar’ begrip is. Ik heb zelf meer dan 1.5 jaar in India gewoond en hierdoor ‘snap’ ik de cultuur beter. Maar hoe leert iemand die er niet kan wonen de culturele eigenaardigheden?