•  
•  
•  
•  

0 Reacties Bewaren

Het uitbesteden van je softwaredevelopment vergt wel wat van je organisatie. We benoemen hier 15 risico's op drie gebieden, die zich voornamelijk aan jouw kant van de relatie voordoen.

Outsourcing heeft zich bewezen als een strategie die door veel IT-afdelingen wordt gebruikt om tot kostenbesparing of innovatie te komen. Maar door de jaren heen hebben we bedrijven, ongeacht de grootte, zien worstelen in het outsourcen van softwareontwikkeling. Vaak liggen de kernoorzaken van de problemen hierin niet zozeer in het outsourcingproces of lag het aan de partner, maar eerder vanwege interne factoren.

Als we de ervaringen van bedrijven analyseren, zien we terugkerende thema's, of waarschuwingssignalen die als ze juist worden geadresseerd een bedrijf kan helpen proactief de obstakels weg te nemen naar een succesvolle outsourcing. Deze 15 risicogebieden vallen in drie categorieën van softwareleiderschap:

Business: Niet alle risico's van een softwareontwikkelingsproject liggen binnen het domein van de IT-afdeling. Ze zijn eerder te vinden in die plekken van het bedrijf waar de stakeholders van de business zitten. Die stakeholders zien de commerciële kansen die kunnen worden bereikt via software-oplossingen.

Management: Risico's die zich voordoen als het management niet zorgt dat de doelen van software-ontwikkeling doelbewust, helder en met gezonde teamdynamiek worden nagestreefd

Technologie: En we zien dat ongeacht de keuze van outsourcingpartner dat risico's ontstaan door gemankeerde elementen in de technologie-architectuur, tools en framework.

Business

Niet gedefinieerde maatstaven. De leiders (business en IT) moeten helder zijn in "Hoe ziet succes eruit?" Een projectbeschrijving of mission statement moet nauw verbonden zijn met de verwachte uitkomsten in de business die zichtbaar zijn en gekwantificeerd. De doelen van de software-ontwikkeling moeten daarmee in overeenstemming zijn.

Inconsistente prioriteiten. Welke elementen (mogelijkheden, functionaliteit, componenten) van een software-oplossing zijn het belangrijkst? Voor bedrijven die iteratieve technieken in ontwikkeling en uitrol gebruiken (agile sprints bijvoorbeeld) is het belangrijk een seriële oplevering van werkbare producten te hebben die gebaseerd zijn op de prioriteiten die door de business naar voren zijn gebracht.

Weinig managementondersteuning. Leiders zetten de toon voor hun teams en zijn de ultieme cultuurbewakers. Als het senior management niet de importantie van een ontwikkelingsinitiatief benadrukken in woord en daad, dan is het dom te veronderstellen dat de belanghebbenden binnen hun afdeling daarin met overtuiging deel gaan nemen.

Gemis aan teambetrokkenheid. Soms kan een derde partij niet anders dan falen doordat ze niet door jouw medewerkers worden betrokken op een manier die nodig is om de taken die ze van jou hebben gekregen af te ronden.

Geen partnerschapscontract. Jouw outsourcingpartner is een verlenging van je interne team. Hun succes is jouw succes. We bevelen bedrijven aan te denken aan een 'convenant' in plaats van een 'contract'. Zakelijke partners zijn samen in een convenant - strijden voor een gezamenlijk doel. In contrast daarmee wordt van leveranciers verwacht simpelweg goederen of een dienst te leveren tegen een vooraf gestelde prijs. Dat werkt niet in het geval van het ontwikkelen van maatsoftware waarin de requirements steeds veranderen.

Management

Onrealistische verwachtingen. Elke leider met ervaring in contractuele relaties heeft ongetwijfeld eens onenigheid gehad over de verplichtingen in de overeenkomst... de verwachtingen van de ene partij komt niet overeen met de acties van de andere partij. "Nou, wat werd bedoeld met dat deel van de overeenkomst is...", is een zin die vele malen is uitgesproken. Het grijze gebied van verwachtingen en aannames is precies de plek waar de meeste risico voorkomen. Redelijke partijen die samenwerken kunnen normaal gesproken tot een werkbaar compromis komen - maar onrealistische verwachtingen kan de relatie doen ontsporen.

Leiderschap zonder focus. Soms worden de 'juiste' stakeholders - gebaseerd op kennis en vaardigheden - aan een project toegewezen, maar die toewijzing neemt niet weg dat er behoefte is aan gerichte aandacht voor het project. Zal de leider meer nodig hebben om te zorgen dat andere behoeften van de business worden geadresseerd? Is er genoeg rekening gehouden met andere prioriteiten van de business die wellicht op het bordje van die persoon zullen landen?

Onduidelijke mijlpalen. In de gloriedagen van pure Waterfall-projecten was het live gaan een enkele Big Bang-gebeurtenis. Tegenwoordig betekenen iteratieve, continue toepassing van methodologieën als Agile dat de mijlpalen extreem duidelijk moeten zijn. Zonder heldere - en duidelijk gecommuniceerde - mijlpalen kunnen stakeholders en andere geïnteresseerde partijen mogelijk onnodige verwarring zaaien als een softwarerelease "iets mist" waarvan ook niet de bedoeling was dat dat in deze iteratie zou zijn opgenomen.

Gemis aan teaminteractie. Goede communicatie is altijd belangrijk geweest in ontwikkelprojecten. In het tijdperk van iteratieve ontwikkeling en uitrol, multigeografische teams, meerdere tijdzones en een snelheid die soms aan krankzinnigheid grenst is goede communicatie een essentiële kerncompetentie voor het projectteam. Processen en samenwerkingstechnologie moeten op een elegante manier samen komen om er zeker van te zijn dat de constante heen-en-weer-overdracht tussen de participanten naadloos en met weinig risico wordt afgehandeld.

Zwakke processen. Technologie wint het nooit van slechte processen in een ontwikkelproject. De snelheid die geleverd wordt door de technologie zal simpelweg een project verslikken als het struikelt over slechte uitvoeringsmethoden - of zorgt ervoor dat het project met een noodvaart het ravijn inrent. De roadmap en de methoden die gebruikt worden in het project moeten volledig begrijpelijk zijn voor het bedrijf en de outsourcingspartner - en beide partijen moeten blijven communiceren over de methoden tijdens de duur van het project.

Technologie

Inadequate vaardigheden. Het is verrassend hoe vaak we merken dat een outsourcingspartner niet voldoende is uitgerust. Je zal je ervan moeten vergewissen dat het projectteam de benodigde vaardigheden en ervaring heeft om succesvol te zijn. Certificaten, doorlopende training en functionele ervaring zijn allemaal dimensies die onderdeel moeten zijn van je due diligence voordat je het contract afsluit.

Ongedefinieerde operations Een van de redenen achter devops was het overbruggen van de kloof tussen applicaties en operations. Deze twee moeten samenwerken gedurende de ontwikkeling en uitrol. Door daaraan een outsourcer toe te voegen is een effectieve manier om het werk gedaan te krijgen, maar voegt ook complexiteit toe. Wie is verantwoordelijk voor de hosting? Hoe wordt de software gecertificeerd voor het bedoelde platform - en wie doet dat?

Ineffectief ontwerp. Adresseren de ontwerpelementen van het systeem op de juiste manier de doelen van de business? We zien verrassend vaak dat er onvoldoende aandacht is voor die samenhang. Zal bijvoorbeeld deze mooie nieuwe webapplicatie op de tweede dag na de lancering stuk gaan als gebruikers het proberen op hun mobiele apparaten? Of vergt de oplossing zo veel pagina's aan data-invoer waardoor online klanten gefrustreerd afhaken in het aankoopproces? Onvoldoende samenhang tussen ontwerp en de zakelijke doelen is een enorme risicofactor die vermijden moet worden.

Geen quality assurance (QA). De snelheid van agile development - en de kans om snel code naar de productieomgeving te deployen - kan leiden tot het negeren of minimaliseren van een goede quality assurance. Een software-outsourcer zou wellicht niet goed begrijpen welke stappen in QA worden verwacht (of zelfs vereist door wetgeving).

Technische achterstand. Vaak zien we bedrijven met een lange lijst aan noodzakelijkheden die eerst moeten worden gedaan. Deze technische achterstand kan een heel scala aan functionaliteit bevatten die nodig is om concurrerend te blijven, of software die bijgewerkt moet worden om bepaalde belangrijke applicaties draaiende te houden. De aanpak van die achterstand is vaak voldoende, maar niet afdoende. De snelheid van de geplande veranderingen brengt het bedrijf dan niet in een betere situatie. Met het risico van een technische achterstand moet radicaal worden afgerekend: versnel de verandering door het inschakelen van outsourcingpartners of overschakelen naar technische platforms bijvoorbeeld.

Conclusie

We bevelen elke manager aan kritisch te kijken naar de context tussen je business, management en technologie en waakzaam te zijn met die 15 risicogebieden. Technologie is geen kostenpost maar eerder een investering in de kansen voor de business. Het verminderen of vermijden van deze 15 risico's zorgt ervoor dat je investering in tijd en geld in een outsourcing-relatie de meeste opbrengst voor je bedrijf genereert.

Lees meer over

• software
• outsourcing
• uitbesteden
• Development