Aanpak van global sourcing projecten

Veel bedrijven zijn inmiddels geconfronteerd met outsourcing van software development projecten. Dientengevolge beginnen ook resultaten hiervan bekend te raken. En recentelijk onderzoek toont aan dat twee van de drie bedrijven hun oorspronkelijke doelstelling niet halen. Weten we nu ook wat de oorzaken zijn ?

De afgelopen jaren heb ik het voorrecht gehad om twee projecten met een 'zware outsourcing component' te mogen managen. Bij beide projecten werd ik halverwege het project betrokken. Dit houdt in dat setup inmiddels had plaatsgevonden en men in de 'operationele development mode' verkeerde. En daar kwamen (zoals ook bij niet-outsourcing-project weleens gebeurd) enige hobbels naar voren die genomen moesten worden.

Aangezien er ook lokaal development plaatsvond, heb ik mij gefocussed op de vraag 'wat is specifieke global sourcing problematiek' en wat kunnen we als generieke problematiek beschouwen.

Hobbels en oorzaken

Bijna 'as usual' komen problemen bij software development pas naar voren, na oplevering van de software door het development-team. Dit bleek ook hier het geval. Vergeleken met niet-global sourcing projecten, zijn hier grotendeel dezelfde oorzaken voor aan te wijzen. Voor de insider niet geheel nieuw: Onvoldoende (functionele) specificaties,; Gebrek aan Architectuurview; Onvoldoende programmeer standaards en richtlijnen. Dus op dit moment spreek ik nog over een stukje bekende problematiek.

De verschillen tussen locaal en globaal 'problem solving' waren aanzienlijk. Het oplossen van de lokale problemen ging vele malen sneller. Volgens mij ligt hier een groot verschil tussen lokale- en globale (in dit geval India) resources. Lokaal ontstaan er discussies, van hoe werkt dit .., hoe heb je dit opgelost .. et cetera en teaming (wel of niet geformaliseerd) ontstaat gewoon.

Het outsourcing team, krijgt een bug en gaat zitten staren, past iets aan, levert op en niet zelden is het niet (helemaal) gefixed. Ook de oplostermijn is vele malen langer.

Bovenstaande is natuurlijk gechargeerd, maar de essentie is voor mij wel duidelijk: het aspect van team communicatie is 'lokaal' vele malen vanzelfsprekender. Hierbij komt dat communicatie naar aanleiding van problemen anders plaatsvindt. Lokaal willen wij een probleem zo gauw mogelijk oplossen. Globaal heb ik het gevoel dat problemen worden gezien als een 'tekortkoming' met als gevolg een houding van 'laten we dit niet in de groep gooien'

Communicatie

Communicatie is de differentiator. Dit blijkt ook uit een voorval dat ik aan den lijve heb ondervonden en wat ik jullie niet wil onthouden.

Tijdens een van mijn domme vragen binnen het projectteam, snelde een (lokale) collega naar mij toe en zei dat ik zelf mijn informatie maar eens uit het systeem moest halen. Hij gaf druk gebarend, ten overstaan van iedereen aan, hoe ik dit moest doen. Een Indiase collega die inmiddels (naar ik dacht) zich de Europese werkwijze had eigen gemaakt zag dit aan. Hij kwam na enige tijd confused naar mij toe en zei dat deze houding (medewerker instrueert openlijk de manager) 'complitely impossible' zou zijn in India. Overigens het feit dat hij rechtstreeks naar mij toe kwam om dit te zeggen geeft al aan dat hij al redelijk geïntegreerd was.

De oplossing

De oplossing voor genoemde problematiek ligt wel genuanceerder, maar in basic denk ik dat allereerst de kwaliteit van specifiacties/architectuur/standaards en richtlijnen moet verbeteren. Hiernaast moet reviewing op alle niveaus plaatsvinden. Dit moet geen inhoudelijke discussies opleveren, maar een verwijzing naar de standaard/richtlijn, waar niet aan wordt voldaan. Dit is een iteratief proces, want er is vrijwel nooit tijd (lees budget) om maanden hieraan te besteden. Vaak nemen we 80 procent van het vorige project over! Overigens, bovenstaande is de oplossing van het generiek probleem waar we in software-development-land toch al enige tientallen jaren tegenaan lopen.

Ten aanzien van global sourcing lijkt het mij de oplossing om het aanleveren van werkzaamheden, geleidelijk aan opbouwen. Dit kunnen zowel designs, requirements of code zijn. Via 'quality reviews' kunnen we de kwaliteit hiervan bepalen en naarmate de kwaliteit acceptabel is, moeten we de omvang en frequentie van deze packages opvoeren. Uiteindelijk moet ook het reviewen door global sourcing plaatsvinden (na gebleken geschiktheid).

Het lokaal laten meedraaien van globale resources binnen het project team, is in eerste instantie een absolute must. Want ondanks het beschikken over alle soorten van sociale media, werken face-to-face contacten vele malen versnellend en wekken ze ook meer vertrouwen.