Dat het grootste deel van de softwarerealisatie-projecten faalt is bij veel mensen bekend. Dat de opdrachtgevers hier zelf gedeeltelijk aan mee werken is bij minder mensen bekend. De huidige markt is heel erg gericht op prijs en dit werkt in het geval van softwarerealisatie-projecten averechts. In dit artikel wordt betoogd dat het kiezen van een realistische aanbieding altijd de voorkeur heeft boven de goedkoopste aanbieding.
De software-industrie is als je het goed beschouwd een heel vreemde branche. Iedereen weet dat veel projecten falen door te optimistische schattingen, maar toch willen de opdrachtgevers vaak al ‘fixed-price' offertes ontvangen op het moment dat nog nauwelijks duidelijk is wat de software moet gaan doen. De softwareleveranciers geven hun vaste prijzen af omdat ze vanwege de marktomstandigheden geen keus hebben. Hierbij is het nog steeds zo dat veel schattingen worden gemaakt door experts, die weliswaar deskundig zijn in het realiseren van sofware, maar niet perse deskundig zijn in het begroten hiervan. Uit literatuur blijkt dat deze experts de kosten in veruit de meeste gevallen zwaar onderschatten.
De opdrachtgever kiest vervolgens vaak de goedkoopste in plaats van de meest realistische aanbieding. Gevolg is dat de leverancier met onrealistische verwachtingen van start gaat, er na verloop van tijd achter komt dat het project (en daarmee zijn winstgevendheid!) in gevaar komt en dan beginnen de problemen. Gevolg is een falend project en wellicht een business case die negatief uitvalt. Hoe gaan we hier als industrie uitkomen? Hoe kunnen we er nu voor zorgen dat we al vroeg in het project een realistische schatting kunnen maken van de projectkosten?
Het antwoord ligt in het vooraf bepalen van een realistische range waarbinnen de aanbiedingen moeten liggen. Gebaseerd op de omvang van de te leveren functionaliteit en met behulp van relevante ervaringscijfers wordt een realistische range bepaalt waarin de projectkosten met een hoge mate van zekerheid komen te liggen. Er zijn meerdere methoden om op basis van high-level requirements een schatting te maken van de omvang van de op te leveren software. Realistische productiviteitscijfers kunnen bijvoorbeeld worden gevonden in het recentelijk uitgebrachte boek ‘Practical Software Project Estimation' van de International Software Benchmarking Standards Group (ISBSG). Dit boek staat boordevol productiviteitscijfers en formules waarmee men op basis van de functionele omvang en enkele andere projectkenmerken een goede inschatting kan maken van de realistische range waarin de projectkosten komen te liggen.
Een voorbeeld. Stel een opdrachtgever wil een vaste prijs offerte ontvangen voor een nieuw systeem dat in Oracle moet worden ontwikkeld. Alleen de high-level requirements zijn klaar en men wil een indicatie hebben van de realistische range waarin de kosten komen te liggen. Een functiepunt analist gebruikt een aantal indicatieve technieken om de omvang vast te stellen. Hij geeft aan dat de meest waarschijnlijke omvang 450 functiepunten is en dat het voor 70 procent zeker is dat de omvang tussen de 380 functiepunten en de 675 functiepunten ligt.
Gebruik makend van de formules en productiviteitscijfers van de ISBSG kan de realistische range worden vastgesteld op:
Optimistisch: 380 functiepunten (FP) * 5,9 uur per functiepunt (uur/FP) = 2.242 uur, doorlooptijd 6,1 maanden
Waarschijnlijk: 450 FP * 8,0 uur/FP = 3.600 uur, doorlooptijd 6,6 maanden
Conservatief: 675 FP * 15,6 uur/FP = 10.530 uur, doorlooptijd 7,7 maanden
Op het moment dat leveranciers een aanbieding aanleveren die onder het optimistische scenario of boven het conservatieve scenario ligt (zonder dat hier een goed verhaal bij hoort), is het verstandig om deze uit te sluiten.
Zolang de opdrachtgevers op prijs blijven selecteren (zonder zelf een beeld te hebben of deze realistisch is) en de leveranciers niet in staat zijn om realistische schattingen af te geven, zullen mislukte projecten meer regel dan uitzondering blijven. Zodra we gaan beseffen dat het uitvoeren van projecten op basis van realistische verwachtingen veel betere resultaten geeft dan het uitvoeren van projecten die zijn gebaseerd op optimistische verwachtingen, kunnen we als industrie een volgende stap in volwassenheid gaan maken.
Goedbeschouwd is het dus een goede zaak als een aanbieder die nu te laag biedt meer gaat vragen voor hetzelfde werk: hij doorstaat de realitycheck en hij krijgt meer centen bij gunning. Iets zegt me dat dit niet de bedoeling is…
@Wouter
Dat ligt eraan wat je als klant belangrijk vindt bij je opdracht:
– op tijd klaar? De kans dat een meer dan optimistische planning gerealiseerd wordt is heel klein.
– voldoet niet alleen aan de expliciete, maar ook aan de impliciete eisen? De kans dat iemand die verlies maakt op je opdracht de moeite neemt impliciete eisen te realiseren is heel klein.
– goedkoop? Dat kan op korte termijn wenselijk zijn.
– lange termijn relatie? Die bouw je niet op door elkaar voor de gek te houden.
Even voor de duidelijkheid: Met “impliciete eisen” bedoel ik dat er gewerkt wordt op basis van de bedoeling van de eisen in plaats van op de letter van de eisen.
Zodra we gaan beseffen (..) kunnen we als industrie een volgende stap in volwassenheid gaan maken.
Dat kan nog wel eens HEEL erg lang gaan duren.
Een zeer goede opmerking, eerst meten dan weten is het motto voor dit soort zaken. Eerst een eigen inschatting maken van de kosten (hoe dan ook) en dan een afweging te maken van de aangeboden offertest is een goede tip denk ik. Dit maakt de keuze met betrekking tot de prijs van een aangeboden product een stuk realistischer.
Om op functiepunten een schatting te maken van de verwachte begroting en dit mee te laten wegen in het goedkeuren van een offerte lijkt een goede manier om in ieder geval de prijsvechters die producten leveren met een te lage kwaliteit eruit te kunnen filteren. Toch blijft het inschatten van de realistische kosten wat mij betreft ook wat theoretisch en een oefening op papier. Het kan richting geven. Ik heb de ervaring dat het berekenen van functiepunten bij een hoop organisaties nog niet ingeburgerd is en er geen ervaring mee is. Dus ook lastig om dit in te gaan voeren en een goed beeld te vormen.
Maar dit is nog steeds gericht op de prijs van een aangeboden product. Als je echt naar de kwaliteit van het aangeboden product wil kijken dan zal je toch inhoudelijk het aangeboden product moeten gaan bekijken. En kwaliteit is in vele gevallen de eisen die je hebt gesteld bij het aanvragen van een offerte. Dus mijn voorstel zou zijn (naast een inschatting van de realistische kosten) dat als je een offerte vraagt (of een aanbesteding start) dat je de eis stelt dat de leverancier pas de offerte gegund wordt als de leverancier goed door een testtraject is gelopen bij de aanbestedende partij. Een acceptatie test voor de aanbesteding of offerte dus.
Hiermee kan je namelijk nog steeds beginnen met de goedkoopste partij, met als bindende voorwaarde dat alle eisen bekeken worden in een acceptatietest. Als er niet wordt voldaan aan de eisen (waar een leverancier “Ja dit kan ons product” op gemeld heeft), dan wordt er niet aanbesteedt en krijgt de tweede partij “in de wachtrij” de kans om zich te bewijzen.
Als dit expliciet wordt aangegeven bij de leverende partij dan mag je verwachten dat de leverancier wel een dubbel-check doet of hij/zij wel aan de gevraagde kwaliteit (eisen) voldoet. Het testen van een product kost de leverancier tijd en geld en dit is een investering die je vanuit je business alleen kan doen als je er bijna zeker van bent dat je ook aan de eisen voldoet, lijkt mij.
Als we dit breder in de IT zouden introduceren, dan
– is een offerte en een akkoord hierop niet alleen een theoretisch verhaal, maar daadwerkelijk in de praktijk bewezen
– wordt je offerte serieuzer genomen door de aanbieders (heeft wat gewennigs tijd nodig denk ik)
– voorkomen we uiteindelijk meerkosten doordat alle eisen ‘bewezen’ zijn als je uiteindelijk een aanbieding accepteert. Een eis waaraan niet voldaan wordt kan alsnog worden opgelost binnen de prijs van de offerte.
Dus naast een realistische inschatting van de kosten, wat ik een goed idee vindt, ook de kwaliteit niet uit het oog verliezen. Eerst het product inhoudelijk accepteren via een fysieke acceptatie test voorkomt discussie en meerwerk achteraf als het project al loopt en de papieren al getekend zijn.
Uit het voorbeeld blijkt al een factor 5 in kosten te voorschijn te komen met een betrouwbaarheid van maar 70%. De belangrijkste oorzaak van het mislukken is dan ook het doen van een fixed-price aanvraag. Daarmee vermindert de motivatie bij de opdrachtgever om te prioritiseren en de scope te beperken.