Global Software Ontwikkeling: Vaste prijs of niet?

Internet en software projecten worden vaak uitgevoerd op basis van een vaste prijs & 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?

Ik sprak gisteren een klant die het ontwikkelen van zijn website had geoutsourced naar één van onze concurrenten die een branch in Azië heeft. Hij voegde functionele specificaties toe die alle vereisten omvatten en duidelijk waren voor hem. De leverancier maakte 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.Ik denk dat de problemen van vaste prijs overeenkomsten, vooral in een offshore samenwerking zijn:
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. Maar hierbij is het probleem weer dat deze methoden met incrementele levering werken, daardoor is het erg lastig 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 in het vereisten document staat beschreven. Als de programmeur het document leest en er niks van begrijpt maar toch zegt dat hij eraan gaat beginnen, wie zit er dan fout? De verzender of de ontvanger? Volgens het contract is het de ontvanger. Maar dat helpt de klant niet, want het zorgt niet voor een afgerond project. Een actievere houding van de klant is vaak vereist om het project tot een goed einde te brengen, maar omdat hij het project geoutsourced heeft vindt hij dat ‘alles op papier staat, doe het gewoon en lever het zoals overeengekomen is’.

3. Gebrek aan onderlinge band
Omdat het project volledig de verantwoordelijkheid van de leverancier is, is de klant meestal niet betrokken 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 ervoor te zorgen dat er (op tijd) geleverd wordt is de projectmanager meestal een tussenpersoon tussen klant en programmeur. Soms zelf één onshore + één offshore. Er is dus geen menselijke connectie tussen degene die de software uitvindt en degene die de software bouwt. Dit gebrek aan een menselijke connectie zorgt ervoor dat misverstanden ontstaan over vereisten en over mensen.

Natuurlijk zijn er veel projecten die zonder problemen geleverd worden, maar ik heb het bovenstaande vaak zien gebeuren wanneer projecten op basis van een vaste prijs gedaan werden.