Werken met een Indiase outsourcingspartner

Je moet al ver zoeken om een Indiase service provider te vinden die niet CMMI level 5 gecertificeerd is. Ze zijn het bijna allemaal. Wie daaruit afleidt dat outsourcing een gebakken broodje is, komt bedrogen uit. Uit praktische ervaring blijkt dat drie factoren het succes van een outsourcingsproject bepalen: communicatie, architectuurbewaking en beheer van design.

Een gebrekkig beheer van communicatie is een belangrijke oorzaak voor het mislukken van een outsourcingsproject. Het is dus belangrijk dat we communicatie als een schaars goed beschouwen. Dat schaars goed willen we onder controle krijgen door het ten eerste te formaliseren, te vereenvoudigen en identificeerbaar of specifiek te maken.

FORMALISEER COMMUNICATIE
Investeer in een geformaliseerd communicatieplan en zorg ervoor dat dit document een formeel beslissingproces doorloopt. Identificeer bij beide partners op voldoende hoog managementniveau personen om dit communicatieplan te bespreken en formeel te aanvaarden. En leg ook een duidelijk escalatiepad vast. Belangrijke elementen in zo’n communicatieplan zijn :

• Het samenwerkingsproces: Hoe verloopt de samenwerking tussen de klant, de outsourcer en een eventuele derde partij? Wie spreekt met wie ? Is dit een driepartijensamenwerking – business-IT-leverancier, of werkt de leverancier in onderaanneming voor IT?
• Welke zijn de verantwoordelijkheden en deliverables van alle partijen?
• Detailleer de operationele processen voor release kick-off, knowledge transfer, design, constructie, acceptatietest, conversie enzovoort.
• Beschrijf de organisatiestructuur.
• Beschrijf de afspraken voor project monitoring, het risk/issue management, configuratiemanagement, change mangement en continuous process improvement.

Dit document moet een formele goedkeuringsprocedure met alle betrokken partijen doorlopen, anders blijft het in praktijk dode letter. Bij geschillen op elk niveau van het project en in beide organisaties moet dit document hét referentiedocument zijn. Hoewel de afspraken geformaliseerd zijn, wil dat niet zeggen dat ze niet kunnen evolueren. Wijzigingen zijn mogelijk, maar moeten dezelfde goedkeuringsprocedure doorlopen.

HOU COMMUNICATIE EENVOUDIG EN PRECIES
Om aan te duiden hoe je communicatie eenvoudig en precies houdt, nemen we de defect tracking tool als voorbeeld. In een defect tracking tool kunnen slechts drie tot vier velden als betrouwbaar worden beschouwd. Meer dan tien accuraat ingevulde velden voor een tracking tool is wishfull thinking. Hou het gebruik van de tracking tool dus beknopt en eenvoudig.

Maak communicatie ook precies, haast mathematisch. Daarvoor
gelden enkele eenvoudige vuistregels. Benoem en identificeer issues, risks, defects, changes, requirements en andere met een éénduidige code. Een discussie rond CR541 mag dan bureaucratisch in de oren klinken, ze heeft in ieder geval de charme van de identificeerbaarheid. En dat is heel wat waard in een project waar niet iedereen de gemeenschappelijke taal ten volle beheerst.

Een andere vuistregel; structureer je communicatie. Organiseer bijvoorbeeld een wekelijkse projectmeeting en een maandelijkse governance meeting, op dezelfde plaats en dezelfde tijd. Dat kan triviaal lijken, maar structuur is een belangrijke meerwaarde in het realiseren van efficiënte communicatie. Een laatste vuistregel betreft de rapportering. Ook hier moet eenvoud en het intuïtieve karakter van de rapportering primeren.

Structureer de projectrapporten naar een éénduidig stramien. Dat zorgt ervoor dat de rapporten in de tijd en over het project vergelijkbaar zijn en dat er door de auteurs niets cruciaals vergeten wordt. Beperk ook het aantal belangrijke gegevens tot drie à vier blokken.

DURF TE ESCALEREN!
In het communicatieplan werd een escalatiepad vastgelegd. Gebruik het tijdig! Escalatie hoeft geen conflict in te houden. Het is het juiste antwoord op een vastgelopen beslissingsproces.

HEFBOMEN VOOR EEN GOEDE COMMUNICATIE: PROJECTSTRUCTUUREN UML?

Communicatie beheren vereist meer dan enkele vuistregels. De projectstructuur is een belangrijke hefboom.

Tot slot nog een woordje over Unified Modelling Language (UML). UML is geen methodologie. Het is een geheel van afspraken rond notaties, benamingen en definities, met andere woorden: een taal. Zoals elke taal is deze niet immuun aan interpretaties en misverstanden. Het gebruik van UML is weliswaar een hefboom, maar op zich geen garantie voor een formele, eenvoudige en precieze communicatie tussen de betrokken partijen. Beide partijen dienen duidelijke afspraken te maken rond gelaagdheid van de specificatie en ze maken een keuze uit het UML-aanbod, die het best aansluit op de noden van het project.

ARCHITECTUURBEWAKING
In bovenstaand diagram neemt de outsourcingspartner verantwoordelijkheid
voor het hele ontwikkelingstraject, te beginnen met de designfase. We hebben hierboven betoogd dat deze structuur vanuit communicatiestandpunt een werkbare aanpak is gebleken. Maar dat betekent niet dat de klant nu van de zijlijn kan toekijken hoe de partner de baan tot een goed einde brengt.

De klant moet de nodige initiatieven nemen om de architectuur van het te ontwikkelen systeem in goede banen te houden. Daarvoor stellen we ook weer enkele vuistregels en hefbomen voor.

HEFBOMEN VAN ARCHITECTUURBEWAKING
Het Software Architecture Document (SAD) is het high level referentieplaatje voor de architectuur van het systeem. Het beoogt een eenvoudige en overzichtelijke beschrijving te zijn van de hoofdcomponenten en interfaces van het te bouwen systeem. Het SAD legt afspraken vast rond de gelaagdheid van de applicatie-architectuur. Het bepaalt de grenzen van die lagen en principes waarop die beslissingen zijn gebaseerd.

Bovendien vind je in de SAD afspraken rond deployment, operationele procedures en softwarearchitectuur. Een andere belangrijke hefboom voor architectuurbewaking is de standaardisatie van design. Als het design 100% UML-gebaseerd is, is men goed gestart. Maar UML is een taal, geen methodologie of een set van praktische afspraken. Ga dus in detail rond het niveau waarop design gedocumenteerd moet worden en leg de structuren van je designmodellen vast (wat noteer ik waar en hoe?). Voer ook enkele piloten uit. Om redenen van traceability leg je ook best strikte naamconventies vast.

ARCHITECTUURBEWAKING IN HET VELD
Om deze afspraken rond architectuur in het veld ook waar te maken moet een incubatieperiode van twee tot drie maanden worden ingepland. Tijdens die periode start je enkele piloot-designoefeningen. Pas in deze piloten de afgesproken
vormvereisten toe, controleer en verbeter. Het motto is daarbij ‘leren door herhaling’. Door op een uniforme wijze de verschillende designpiloten aan te pakken en te becommentariëren worden de architectuurvereisten actief in het veld geïntroduceerd.

DESIGNBEWAKING
SAD is een onderdeel van het communicatieplan. We zijn dus nu op het punt aanbeland waarbij de nodige afspraken zijn gemaakt en geformaliseerd. Bovendien hebben we de afspraken getest tijdens enkele designpiloten. Iedere partner weet wat hem te doen staat, en nu kan het echte werk beginnen.

De klant schakelt nu over op een delegate and audit mode. De oursourcingspartner heeft nu volledige verantwoordelijkheid over design en ontwikkeling. En de klant zet van zijn kant enkele automatische en manuele controlemechanismen in gang. Naamgeving, UML-packagestructuren en consistentie van diagrammen bijvoorbeeld, kunnen grotendeels automatisch gecontroleerd worden. Met manuele controles wordt de consistentie en volledigheid van het design gecontroleerd, alsook mogelijke verfijningen in de afbakening van componenten en interfaces.

Designbewaking heeft een drieledig doel. Het is evident dat de klant op deze manier zijn outsourcingspartner kan sturen in het project en hij kan er ook de voortgang mee meten. Maar door deze actieve bewaking bereikt de klant ook een derde doelstelling. Hij krijgt vroeg in het project zicht op het verloop van de kennisoverdracht naar de outsourcingspartner. In het licht van een langdurige relatie is het voor de klant belangrijk om een zicht te krijgen op de mate waarin de outsourcingspartner de business van de klant beheerst en er – blijvend – de juiste resources aan toewijst.

De klant heeft nu naast een geheel van afspraken ook een duidelijke gesprekspartner waarmee het project kan afgewerkt worden en eventueel nieuwe initiatieven opgestart.

Luc Jorissen en Jan Bovend’aerde zijn inno.com consultants.