Veel bedrijven besteden het ontwikkelen van internet- en softwareprojecten uit. Vaak worden deadlines niet gehaald en is de kwaliteit niet zoals verwacht. Podiumauteur Hugo Messer geeft drie redenen waarop de meeste outsourceprojecten falen.
Internet- en softwareprojecten worden vaak uitgevoerd op basis van een vaste prijs en een vaste deadline. De klant die het project outsourced voelt zich dan ‘beschermd’ tegen eventuele vertraging en misverstanden bij de levering. Maar bent u als klant echt beschermd of vergroot dit het risico op een mislukt project alleen maar?
Een van mijn klanten had het ontwikkelen van zijn website geoutsourced naar een concurrent met een afdeling in Azië. De klant had een aantal – voor hem duidelijke – functionele specificaties toegevoegd die alle vereisten omvatten. De leverancier maakte op basis hiervan een schatting en er werd een deadline overeengekomen. Een paar maanden later werd de deadline niet gehaald en het resultaat van het project was verre van wat hij verwacht had. Hoe kan dat?
Problemen vaste prijsovereenkomsten
Volgens mij zijn de drie belangrijkste problemen van vaste prijsovereenkomsten in een offshore samenwerking:
1. De drang om alles 100% te specificeren
Het grootste obstakel bij softwareontwikkeling is het duidelijk maken van de vereisten. Ondanks het feit dat wij mensen denken dat we alles van tevoren kunnen specificeren, is dit vaak niet het geval. Ten eerste is het heel moeilijk om van tevoren overal aan te denken. Ten tweede, als ik van tevoren overal aan kan denken, moet ik dit kunnen communiceren naar degene die het gaat maken. En daar zijn we niet zo goed in. De oplossing binnen de software-industrie is agile software methodes. Nadeel van deze methode is dat het met incrementele levering werkt, waardoor het erg lastig is om op basis van een vaste prijs te werken.
2. Wie is er verantwoordelijk?
De klant denkt dat hij alles gespecificeerd heeft. Voor hem is het duidelijk wat er gemaakt moet worden en hij is er zeker van dat alles duidelijk staat beschreven in het document met vereisten. De programmeur leest het document en begrijpt er niks van. Toch zegt hij dat hij eraan gaat beginnen. Wie zit er dan fout: de verzender of de ontvanger? Volgens het contract is het de ontvanger. De klant is daar niet mee geholpen, want hij zit met een niet afgerond project. Een actievere houding van de klant is dus vereist om het project tot een goed einde te brengen. Maar omdat het project is geoutsourced, vindt de klant dat: ‘alles op papier staat, dus doe het gewoon en lever het zoals overeengekomen is’.
3. Gebrek aan onderlinge band
Het project is volledig de verantwoordelijkheid van de leverancier, waardoor de klant meestal niet betrokken is bij wie er aan het project werkt. Hij heeft zijn project in een zwarte doos gestopt en verwacht dat daar uit komt wat er afgesproken is, binnen de deadline. Om te zorgen dat er (op tijd) geleverd wordt is de projectmanager meestal een tussenpersoon tussen klant en programmeur. Soms zelf één onshore + één offshore projectmanager. Er is dus geen directe verbinding tussen degene die de software uitvindt en degene die de software bouwt. Dit gebrek zorgt ervoor dat misverstanden ontstaan over vereisten en over mensen.
Natuurlijk zijn er veel projecten die zonder problemen geleverd worden. Maar ik heb bovenstaande problemen vaak zien gebeuren wanneer projecten op basis van een vaste prijs gedaan werden.
Eerdere bijdragen:
Over de auteur:
Dit podiumartikel is geschreven door Hugo Messer, eigenaar van Bridge Outsourcing BV
Over het podium:
Ook uw visie geven op ontwikkelingen binnen uw vakgebied? Plaats een artikel op MT Podium. Log in op mt.nl/profiel en voeg onder 'activiteiten' uw artikel toe. Interessante bijdragen worden meegenomen in de nieuwsbrief en op home geplaatst. MT Magazine publiceert bovendien periodiek 'Het beste van MT Podium'.
