Sogeti seminar 2009 - Why we should estimate in a methodical way and how to do so.

1. Methodisch Begroten van ProjectenWaarom en hoe? Harold van Heeringen Sizing, Estimating & Control harold.van.heeringen@sogeti.nl www.twitter.com/haroldveendam Vianen, 15 september 2009

2. Wat wil ik u laten zien? Methodisch begroten van projecten is een cruciale factor voor het succesvol realiseren van projecten.

3. Outline De IT industrie heeft een enorm probleem met het begroten van projecten. Waarom? Hoe kunnen we realistisch begroten? Wat kunt u doen om voortaan realistisch te begroten?

4. Projecten falen Standish Chaos report (2009) [1] 32% van de projecten is succesvol Op tijd Binnen budget Bevat alle benodigde functionaliteit 44% van de projecten is niet succesvol 24% is voortijdig gestopt of is opgeleverd maar nooit gebruikt Een duidelijke afname van het succespercentage (35%) ten opzichte van de vorige studie (2007)

5. Maar waarom?? Onrealistische begroting en planning! Vrijwel altijd: expertbegroting

6. Gevaar van expertbegrotingen Industrie leunt zwaar op experts Matige onderbouwing Niet gebaseerd op kwantitatieve data Vergeten activiteiten Ongefundeerd optimisme Geen mogelijkheid om ervaringscijfers op te bouwen Gemiddeld 30% te optimistisch

8. Vergroten team  veel duurder maar nauwelijks sneller

9. Extra management attentie / overhead

10. Stress: Meer defects, lagere onderhoudbaarheid !!>100% Extra Kosten Lineaire extra kosten Extra uren worden besteed Onderschatten Overschatten 0% Te lage schattingen Te hoge schattingen Realistische schattingen

11. Effect van Optimisme/Pessimisme Begroting Resultaat 15.000 A: Optimistisch Faalt ! 10.000 uur 3.000 uur 12 maanden 5 maanden 10.000 Realisatie (uur) B: Realistisch Slaagt ! Efficiënt! 5.000 uur 5.000 uur 7.000 maanden 7 maanden 7 5.000 uur 3.000 uur 7.000 uur C: Pessimistisch Slaagt ! Inefficiënt ! 7.000 uur 5.000 Realisatie is zeer sterk afhankelijk van de begroting !!! 7.000 uur 11 maanden 11 maanden A C B

12. Voordelen van realistische begrotingen Projectstatus beter controleerbaar Realistisch plan  actuals Minder stress – hogere kwaliteit Oorzaak 40% software defects is stress Extreme druk leidt tot 4x zoveel defects Onderhoudbaarheid van de code!! Verhoogde geloofwaardigheid

13. De IT industrie heeft een probleem! IT industrie – begroot (te) optimistisch! Business: Het moet goedkoper Bevordert optimisme Business: Het moet sneller Bevordert optimisme IT - Weet niet precies ‘hoe groot’ het is Onvolwassen begrotingsmethodieken IT - kent haar eigen performance niet Kan begroting niet goed onderbouwen Weet niet goed wat realistisch is IT gaat relatief eenvoudig mee met optimisme

14. Realistisch begroten Optimisme leidt tot falende projecten Maar hoe kunnen we een realistische begroting maken? Naast expertbegroting ook een methodische begroting !!

15. Methodische Begroting Meten van Functionele Omvang Omvang in Functiepunten Gebruik ervaringscijfers Productiviteit: Uren per functiepunt Gebruik Tools Scenario-analyse (doorlooptijd, teamize, etc.)

16. Meten van functionele omvang Functiepunt analyse (FPA) of COSMIC Objectief, herhaalbaar, verifieerbaar Technologie onafhankelijk Eenheid ‘product’ maakt verzamelen ervaringscijfers mogelijk Productiviteit: uur per functiepunt Kwaliteit: defects per functiepunt

17. Ervaringscijfers Eigen ervaringscijfers Per omgeving (Java, Oracle, .Net, etc.) Per ontwikkelfase (ontwerp, bouw, test) Per locatie (onshore, offshore) Benchmarkcijfers Databases van de tools ISBSG repository (R11 - 5.200 projecten)[4]

18. Scenario analyse [2] Plan A: 7.500 uur, 7 maanden Plan B: 4.400 uur, 8 maanden Constante Inspanning (uur) = Doorlooptijd4 Voorbeeld: Kiezen voor een doorlooptijd van 8 maanden in plaats van 7 maanden (14 % langere doorlooptijd) resulteert in een afname van het aantal benodigde uren met 40 % !! (bij dezelfde productiviteit en omvang) Onmogelijk Inspanning Onpraktisch Doorlooptijd Bron: Putnam & Myers - 5 Core metrics

19. Een realistische begroting [3] Voorbeeld Scenario 1: Doorlooptijd: 5,5 maanden Inspanning: 5.000 uur Teamsize: 6,7 fte Kosten: € 430.000 Voorbeeld Scenario 2: Doorlooptijd: 5,2 maanden Inspanning: 5.500 uur Teamsize: 7,5 fte Kosten: € 480.000 Voorbeeld Scenario 3: Doorlooptijd: 4,8 maanden Inspanning: 5.900 uur Teamsize: 8,3 fte Kosten: € 530.000 Voorbeeld Scenario 4: Doorlooptijd: 4,5 maanden Inspanning: 6.300 uur Teamsize: 9,4 fte Kosten: € 620.000 Voorbeeld Scenario 5: Doorlooptijd: 5,8 maanden Inspanning: 5.200 uur Teamsize: 6,2 fte Kosten: € 400.000 Voorbeeld Scenario 6: Doorlooptijd: 6,1 maanden Inspanning: 4.900 uur Teamsize: 5,8 fte Kosten: € 380.000 Voorbeeld Scenario 7: Doorlooptijd: 6,3 maanden Inspanning: 4.700 uur Teamsize: 5,5 fte Kosten: € 360.000 Estimate / Business Case Kosten afhankelijk van Time-to-market

20. Tools QSM SLIM toolsuite [5]

21. Tools Galorath - SEER for Software [6]

23. Inzicht in de performance over projecten heen

24. Mogelijkheden tot interne en externe benchmarking

25. Verhoogde grip: voorspelbaarheid en transparantie

26. Onderbouwing voor procesverbeterinitiatieven

28. Beter onderbouwde en verdedigbare begroting

29. Aanvullende zekerheid naast de expertbegroting

30. Uitspraak over de kwaliteit van de documentatie

31. Welke Projectleider wil dit niet??

33. Inrichten is niet eenvoudig. Een paar tips! Tip 1: Stel een E&PM proces in met een proces eigenaar in MT. Tip 2: Zorg voor standaardisatie en templates! Tip 3: Gebruik indien mogelijk COSMIC. Tip 4: Kies een goede toolsuite. Tip 5:Implementeer een standaard WBS.

36. Conclusies Veel projecten mislukken omdat wordt uitgegaan van onrealistische verwachtingen. Realistische begrotingen zijn te maken door naast de expertbegroting ook een methodische begroting te maken. Om dit te doen is het nodig om een ‘Estimating & Performance Measurement’ proces in te richten

37. Wat heb ik u laten zien? Methodisch begroten van projecten is een cruciale factor voor het succesvol realiseren van projecten.

38. 4 November: Workshop Benchmarking (Harold van Heeringen & Luca Santillo) 5 November: Keynote: Jeroen Versteeg, CEO Sogeti Nederland B.V. 6 November: Estimating the functional size of applications built with the Oracle eBS Package (Frank Vogelezang) – Industry paper http://www.iwsm-mensura-2009.org/

39. Sogeti Sizing, Estimating & Control Bedankt voor uw aandacht ! Harold van Heeringen Sizing, Estimating & Control harold.van.heeringen@sogeti.nl www.twitter.com/haroldveendam Internet: metrieken.sogeti.nl Sogeti Sizing, Estimating & Control NESMA – bestuur NESMA – voorzitter werkgroep COSMIC NESMA – werkgroep Benchmarking NESMA – werkgroep Telrichtlijnen COSMIC – Measurement Practices Committee COSMIC – Benchmarking Committee ISBSG – Technical & Advisory Committee QSM – trekker gebruikersgroep Nederland

40. Vragen?

42. Bronnen [1] Standish Group – Chaos report 2009, http://www.standishgroup.com [2] McConnell – Software Estimation, demystifying the black art, 2006 [3] Putnam & Myers - Five core metrics, 2003 [4] ISBSG – http://www.isbsg.org [5] QSM – http://www.qsm.com of http://www.qsm-europe.com [6] Galorath SEER – www.galorath.com