Ik verbaas me wel eens over het feit dat veel bedrijven nog steeds de voorkeur geven aan traditionele IT-projecten boven modernere werkwijzen. Er wordt vooral gedacht vanuit de techniek en vooraf gedefinieerde functionele eisen, waarbij de snelheid en waarde van de opgeleverde functionaliteit eigenlijk niet wordt gemeten. Dat is makkelijk voor de ontwikkelaar, maar het is zeker niet in het belang van de klant.
In de softwareontwikkeling draait alles rond agile tegenwoordig. Het is modieus, maar de manier waarop ontwikkelaars hier invulling aan geven, kan sterk verschillen. Het grootste gat dat ik zie in de dienstverlening van veel partijen is de manier waarop de resultaten van een project meetbaar worden gemaakt. Een populaire methode is het gebruik van User Stories om de de gewenste functionaliteit vast te leggen in een taal die zowel voor het management als de ontwikkelaars te begrijpen is. Door vervolgens User Story Points te bepalen voor de delen functionaliteit, krijgt de klant helder inzicht in de op ‘kosten’ gebaseerde waarde die elk oplevermoment toevoegt aan zijn business. Dat overzicht is voor beide partijen prettig en het zorgt dat er veel efficiënter wordt gewerkt met een veel beter resultaat.
Value-based pricing
Op het moment dat je de performance van IT-projecten meetbaar maakt, verandert in feite de hele dynamiek van het proces. De ontwikkelaar en de klant kunnen direct zien wat er wordt bereikt en werken samen om het beste resultaat te behalen. Dit zegt echter vaak nog niets over wat de waarde is die er voor de aandeelhouders is gecreëerd. Ik denk dat value-based pricing de toekomst is voor het ontwikkelen van maatwerksoftware. Hoewel we een vergelijkbaar concept, het use-based pricing, ofwel het ‘betalen naar gebruik’, ruimschoots hebben omarmd in de wereld van cloud computing is dit idee toch nog maar nauwelijks doorgedrongen in de wereld van de applicatieontwikkeling. Eigenlijk is dat vreemd. Je vraagt een ontwikkelaar een bedrijfsapplicatie met je te ontwikkelen die waarde toevoegt aan je organisatie. Dan is het toch heel normaal dat je de kosten van zo’n project koppelt aan de concrete voordelen die ermee worden bereikt? Een beperkende factor is hierbij dat veel klanten en ontwikkelaars geen inzicht hebben in de resultaten van hun projecten, maar vooral de focus leggen op de kosten en de geleverde inspanning. Zeker in mijn ervaring is de waarde die maatwerksoftware levert voor een bedrijf vaak vele malen groter dan de gedane investeringen in tijd en geld. Een bijkomende nieuwe factor is bovendien dat IT in alle facetten van bedrijfsvoering een steeds belangrijkere rol gaat innemen.
Transparantie
Het klinkt zo logisch, maar in de praktijk kom je het nog te weinig tegen: transparantie en openheid bij IT-projecten. Door slecht ingeregelde en niet-gestandaardiseerde projectmethoden gebeurt het maar al te vaak dat de doelstellingen van een ontwikkelpartij totaal niet overeenkomen met de daadwerkelijke wensen van de klant. Het gevolg is inefficiëntie in het proces, wat meestal de hoofdreden is dat dit soort ontwikkelprojecten veel duurder uitvalt dan nodig. Het meetbaar maken van de waarde die er wordt gecreëerd, is alleen mogelijk als de klant en zijn ontwikkelpartner daarbij intensief samenwerken. Dat kost extra inspanning, maar het inzicht dat ze hierdoor krijgen in het ontwikkelproces zorgt er wel voor dat continu de meerwaarde wordt aangetoond van hun samenwerking. Statische software is niet meer van deze tijd, net als ouderwetse samenwerkingsverbanden tussen softwareontwikkelaars en hun klanten. Alles draait om dynamiek, transparantie en meetbaarheid.
Erik Seveke is medeoprichter van GlobalOrange
Dag Erik,
De problematiek die je schetst zie je terug bij elke methode of het nu om agile (modern) of waterval (ouderwets) gaat. Zo zie je ook dat het vaak goed bij zowel agile als waterval. Kortom: het probleem dat je schetst heeft helemaal niets te maken met de methode zelf, maar de wijze zoals de methode wordt toegepast. Er is namelijk geen enkele methode die het verbiedt om dynamisch, transparant en meetbaar te werken. Als dat niet gebeurt ligt dat veel eerder aan de competenties van de projectleider.
Vriendelijke groet,
Leon Dohmen