Sogeti MD Seminar 21 sep 2010 (NL)
•Télécharger en tant que PPT, PDF•
1 j'aime•544 vues
Topic: Succesvol aanbesteden van ICT projecten
![Uitdagingen vanuit het standpunt van de leverancier Metrieken in Aanbestedingen Harold van Heeringen Sizing, Estimating & Control [email_address] @haroldveendam](https://image.slidesharecdn.com/sogetimdseminar21sep2010v10-12851354810113-phpapp02/85/sogeti-md-seminar-21-sep-2010-nl-1-320.jpg)
![Agenda ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Similaire à Sogeti MD Seminar 21 sep 2010 (NL)
Similaire à Sogeti MD Seminar 21 sep 2010 (NL) (20)
Plus de Harold van Heeringen
Plus de Harold van Heeringen (20)
Sogeti MD Seminar 21 sep 2010 (NL)
- 1. Uitdagingen vanuit het standpunt van de leverancier Metrieken in Aanbestedingen Harold van Heeringen Sizing, Estimating & Control [email_address] @haroldveendam
- 6. Generiek begrotingsmodel Omvang Omvang Fouten Inspanning Doorlooptijd Fouten Productiviteit Factor: Omvang Functiepunten Factor: Omvang Functiepunten Factor: Inspanning Aantal uur Instroomsnelheid Piekbezetting Factor: Doorlooptijd Aantal weken Factor: Kwaliteit Aantal fouten Factor: Productiviteit Samenstelling en ervaring team Ontwikkelomgeving Complexiteit Kwaliteitssysteem Externe beïnvloedingsfactoren Behoefte Software Energie Software ontwikkel proces Afval Tijd
- 11. Volledigheid / detailniveau requirements tijd Concept Definitie Globaal ontwerp Detail-ontwerp Realisatie Idee Waarom Wat Hoe Aanbesteding 4x 3x 2x 1x 0.8x 0.5x Project Rate 1 4 2 3 3 1 4 1 5 1 6 2 7 4 8 4 9 5 10 5 Average 3
- 12. Omvang neemt altijd toe time Omvang Aanbesteding Concept Definitie Globaal ontwerp Detail-ontwerp Realisatie Idee Waarom Wat Hoe Challenge: Met welke omvang gaan we rekenen en met welke omvang rekent onze concurrent?
- 14. Project bij verschillende doorlooptijden Inspanning (uren) Doorlooptijd A Doorlooptijd: 6 maanden Inspanning: 4.500 uur Max. teamomvang: 5,8 fte MTTD: 1,764 dagen B Doorlooptijd: 7 maanden Inspanning: 2.400 uur Max. teamomvang: 2,7 fte MTTD: 2,816 dagen Omvang en productiviteit constant
- 15. Uitdaging: Doorlooptijd Begroting / Business Case Kosten afhankelijk van de gewenste time-to-market Voorbeeld Scenario 1: Doorlooptijd: 5,5 maanden Inspanning: 5.000 uur Teamgrootte: 6,7 fte Kosten: € 430.000 Voorbeeld Scenario 2: Doorlooptijd: 5,2 maanden Inspanning: 5.500 uur Teamgrootte: 7,5 fte Kosten: € 480.000 Voorbeeld Scenario 3: Doorlooptijd: 4,8 maanden Inspanning: 5.900 uur Teamgrootte: 8,3 fte Kosten: € 530.000 Voorbeeld Scenario 4: Doorlooptijd: 4,5 maanden Inspanning: 6.300 uur Teamgrootte: 9,4 fte Kosten: € 620.000 Voorbeeld Scenario 5: Doorlooptijd: 5,8 maanden Inspanning: 5.200 uur Teamgrootte: 6,2 fte Kosten: € 510.000 Voorbeeld Scenario 6: Doorlooptijd: 6,1 maanden Inspanning: 4.900 uur Teamgrootte: 5,8 fte Kosten: € 480.000 Voorbeeld Scenario 7: Doorlooptijd: 6,3 maanden Inspanning: 4.700 uur Teamgrootte: 5,5 fte Kosten: € 440.000
- 16. Uitdaging leverancier Prijs per functiepunt Doorlooptijd Plan A: 767 €/FP Plan B: 452 €/FP 3. Wat is uw prijs per functiepunt voor een Java applicatie van 500 FP ? Antwoord: 380 €/FP ?? Klant verwachting
- 19. Te hoge en te lage begrotingen in de praktijk 10.000 5.000 uren 3.000 uren 7.000 uren 7.000 Aanbieding Resultaat ! 7 A Realisatie (uren) 5.000 15.000 C B Faalt 10.000 uur 12 maanden B: Realistisch 5.000 uur 7 maanden Succesvol ! Efficient! 5.000 uur maanden Succesvol ! Niet efficiënt ! 7.000 uur 11 maanden A: Optimistisch 3.000 uur 5 maanden C: Pessimistisch 7.000 uur 11 maanden
- 23. Voorbeeld van een goede vraag ‘ Wat is uw productiviteit (uur/FP) voor een gemiddeld complex Java project van 500 functiepunten en een doorlooptijd van 20 weken? Uit te voeren activiteiten zijn technisch ontwerp, coderen, unit test, systeem test en ondersteuning van de gebruikersorganisatie tijdens de gebruikers acceptatie test.’
Notes de l'éditeur
- Ik wil u graag meenemen in de wondere wereld van de software metrieken en wel die software metrieken die vaak in aanbestedingen worden gebruikt. Dan heb ik het over metrieken als prijs/FP en uur/FP. Ik werk binnen de afdeling Sizing, Estimating & Control van Sogeti en ben in die rol betrokken bij het beantwoorden van metrieken gerelateerde vragen in aanbestedingen. In deze presentatie wil ik u meenemen in de uitdagingen die leveranciers hebben bij het beantwoorden van deze vragen.
- Dit is de agenda van deze presentatie. Eerst even onze kennis opfrissen van het begroten van projecten op basis van omvang en ervaringscijfers Daarna gaan we kijken welk soort vragen we vaak tegenkomen in aanbestedingen. Dan wil ik u laten zien welke uitdagingen de leveranciersorganisaties hebben bij het beantwoorden van deze vragen Tenslotte wil ik u graag een aantal aanbevelingen meegeven die u kunnen helpen om de juiste leverancier te kiezen.
- Allereerst een korte opfrissing van uw geheugen. Functiepuntanalyse is een objectieve methode om de functional user requirement te meten. Omdat de methode objectief is, maakt het niet uit wie de omvang meet. Twee gecertificeerde functiepunt analisten zullen met dezelfde uitgangsdocumentatie tot dezelfde omvang in functiepunten komen. De methode is onafhankelijk van de technische oplossing en van de implementatie. Een systeem van 500 functiepunten dat in Java wordt gerealiseerd is dus net zo groot als een systeem van 500 functiepunten dat in Cobol wordt gebouwd. Wat vaak vergeten wordt is dat de methode alleen de gewenste functionaliteit meet. Het is een productmaat en zeker geen projectmaat. Het begroten van software realisatieprojecten op basis van functiepunten is daarom een hachelijke zaak, vol onzekerheid.
- Op dit moment bestaat er echter geen methode om de projectomvang te meten die beter geschikt is dan functiepunt analyse en deze methode wordt dan ook veelvuldig gehanteerd. We meten de omvang in functiepunten en gebruiken dan zaken als de benodigde uren, doorlooptijd en teamomvang op basis van ervaringscijfers van eerder afgeronde projecten. Hiervoor gebruiken we tools als de QSM SLIM suite, onze eigen tool de Sogeti Estimating wizard of de benchmarkdata van de ISBSG.
- U ziet hier een illustratie van een projectbegroting die is gemaakt in QSM SLIM Estimate. We zien dat we een omvang van 500 functiepunten hebben ingegeven. Op basis van de database van ervaringscijfers die erachter hangt wordt een optimaal scenario uitgerekend door de tool en zien we zaken als doorlooptijd, uren, kosten, piekbezetting en kwaliteit terug.
- 3.01 Meten & Begroten dagdeel 3 v1.0 Sogeti Nederland B.V. v1.0 Deze begroting is gebaseerd op het Generieke begrotingsmodel. Een software realisatie project begint altijd met een bepaalde behoefte. Dit is in feite de gewenste functionaliteit en de omvang hiervan kunnen we meten met functiepunten. De omvang van het product dat opgeleverd wordt kunnen we ook meten in functiepunten. Tijdens het project moeten we een bepaalde inspanning leveren. Hierbij zijn een aantal zaken belangrijk voor het model: het aantal uren, de snelheid waarmee het team wordt opgebouwd en het aantal fte dat maximaal aan het project werkt. De productiviteit waarmee het project gerealiseerd kan worden is afhankelijk van een groot aantal zaken, die per organisatie verschillen. Dit gaat dus veel verder dan technische omgeving alleen. Het project heeft een bepaalde doorlooptijd in weken of maanden. Verder worden er tijdens het project en na de oplevering fouten gevonden. Het model gaat ervan uit dat 95% van de fouten voor de oplevering aan de klant worden gevonden en hersteld. Al deze factoren hebben invloed op elkaar en deze invloed heeft een non-lineaire aard. Op het moment dat we aan een schroef draaien, dan draait alles mee. Dat betekent dus dat het mogelijk is om een aantal scenario’s uit te rekenen voor hetzelfde project, waarbij we steeds aan een bepaalde schroef draaien en waarbij de uitkomsten dus steeds verschillen.
- We hebben uw kennis opgefrist en gaan nu r kijken naar de typische vragen die we in aanbestedingen tegenkomen.
- Op het moment dat een leverancier overweegt om te gaan inschrijven op een aanbesteding, dan moet hij eerst voor zichzelf de volgende vragen beantwoorden. In deze presentatie focus ik op de metrieken gerelateerde vragen in de aanbesteding en die hangen natuurlijk samen met het feit of we in staat zijn het project nauwkeurig te begroten. Sogeti Nederland B.V.
- Dit zijn typische vragen die we in veel aanbestedingen tegenkomen. Het gaat vaak over metrieken als productiviteit in uren per functiepunt en prijs per functiepunt. Wie van u denkt dat dit goede vragen zijn om de juiste leverancier te kiezen? Sogeti Nederland B.V.
- Ik wil u nu laten zien welke uitdagingen de leveranciers hebben om dit soort vragen te beantwoorden.
- Sogeti Nederland B.V. Laten we eerst eens kijken naar de omvang. U ziet hier de welkbekende ‘Cone of uncertainty’. In deze figuur ziet u dat de omvang van de requirements bijzonder onzeker is vroeg in de project levenscyclus. Naarmate het project vordert worden er beslissingen genomen om de onzekerheid te reduceren. Nu is het zo dat het moment van aanbesteden vaak dusdanig vroeg in de project levenscyclus is, dat er nog heel veel onzekerheid over de omvang is. De requirements zijn nog niet 100% helder. Binnen Sogeti hebben we een waarderingssystematiek ontwikkeld die de kwaliteit van de uitgangsdocumentatie meet. De documentatie die bij ons binnen komt krijgt een rapportcijfer en dit cijfer is input voor onze begrotingsmodellen. U ziet hier de rapportcijfers van de laatste 10 door ons begrote projecten. Geen voldoendes, gemiddeld een 3. Dit is dus de documentatie waarop de leveranciers een fixed-price moeten afgeven!
- Sogeti Nederland B.V. Als we nog even verder kijken naar de omvang, dan zien we dat de omvang die we vaststellen bij de aanbesteding niet de omvang is die uiteindelijk gerealiseerd zal worden. Door zogenaamde scope creep en requirements creep zal de omvang van de functionaliteit toenemen. Scope creep, het toevoegen, wijzigen of verwijderen van functionaliteit tijdens het project kan worden ingevuld door change management en wordt normaal gesproken betaald door de klant. Requirements creep is echter een ander verhaal. Het verder detailleren van bestaande requirements kan tot een gewijzigde omvang leiden, zonder dat hier een factuur voor gestuurd kan worden. Stel dat uit ervaringscijfers blijkt dat dit altijd zo’n 20% is. Waarop baseren we dan onze aanbieding? Waarop baseert de concurrentie haar aanbieding?
- Dan kijken we naar een andere belangrijke factor: de doorlooptijd. We nemen als uitgangspunt de software equation die door Putnam senior is gepubliceerd en die ook in de QSM SLIM tooling wordt gebruikt. U ziet de formule staan. Het idee is dat bij een gegeven omvang en een gegeven productiviteit, het altijd mogelijk is om verschillende inspanning / doorlooptijd scenario’s te maken. De omvang is objectief gemeten. De productiviteit komt uit de ervaringscijfers. U ziet hier 2 verschillende plannen staan. Omdat de formule een zwaarder gewicht toekent aan de doorlooptijd is dit een belangrijke factor. De doorlooptijd iets verkorten leidt tot een onevenredige toename van het totaal aantal benodigde uren.
- De reden daarvoor wordt duidelijk als we naar deze figuur kijken. Ik heb de twee plannen uit de vorige figuur hier iets verder uitgewerkt. We zien dat we voor plan A een groter team nodig hebben dan voor plan B. Dit team is misschien groter dan u zou verwachten. Dit komt omdat iedere extra persoon in een team de overall productiviteit verlaagd. Er worden extra communicatiepaden gecreëerd en het wordt moeilijker om het project te managen in die zin dat iedereen nuttig aan het werk gehouden moet worden. Een groter team betekent ook meer defects, wat hier tot uiting komt in een lagere mean-time-to-defect. Iedere defect moet worden gelogd, terug naar de bouw, geanalyseerd, opgelost, geunittest en weer aan de systeemtest worden opgeleverd. Veel extra werk per defect dus.
- Voor iedere begroting geldt dat er een minimale doorlooptijd bestaat. Een kortere doorlooptijd is simpelweg niet mogelijk, ook niet als er met een enorm groot team wordt gewerkt. Er is ook een optimale doorlooptijd. Een langere doorlooptijd betekent dat het team te klein wordt en men minder efficiënt wordt. Daartussen is in feite alles mogelijk. Vanuit onze afdeling Sizing, Estimating & Control leveren we altijd 7 scenario’s aan aan onze interne klanten: bid- en contractmanagement. Zij hebben echter vaak de mogelijkheid om een begroting als uitgangspunt te hanteren bij het beantwoorden van de vragen in de aanbesteding. Simpel, omdat er geen ruimte wordt geboden om de context te schetsen van de begroting. De vraag is nu: wat is de doorlooptijd die we gaan gebruiken in onze aanbieding? Sogeti Nederland B.V.
- Even een praktijkvoorbeeld. Dit is een van de vragen waarvan ik u zostraks heb gevraagd of u het een goede vraag vond. U ziet dat het voor een leverancier erg lastig is om deze vraag zo te beantwoorden. Er is een onmogelijke zone en een inefficiënte zone. Daartussen kunnen we de prijs per functiepunt variëren met de doorlooptijd. Als dit een vraag is die in een aanbesteding wordt gevraagd, dan hebben we dus een uitdaging bij het beantwoorden hiervan. We kunnen de laagste prijs/FP geven waarbij we in ons achterhoofd een bepaalde doorlooptijd als randvoorwaarde houden. De klantverwachting is echter zeer waarschijnlijk heel anders. Dit betekent dat als het contract gegund wordt op basis van deze prijs/FP, er vervolgens een discussie zal ontstaan over de doorlooptijd.
- In de vorige slides heb ik u een aantal uitdagingen van leveranciers getoond. Hierbij komt nog het aspect van de concurrentie. Deze uitdagingen zijn expliciet als de leverancier professioneel genoeg is om een begrotingsproces te hebben ingericht, waarbij wordt begroot met functiepunt analyse en ervaringscijfers en de tooling om tot nauwkeurige begrotingen te komen. Er zijn echter ook veel leveranciers op de markt die deze professionaliteit niet hebben. Het kan voorkomen dat zij een prijs/FP noemen die nergens door wordt onderbouwd en dat men het risico op de koop toe neemt. Ook kan het zijn dat men projecten probeert te kopen door een lage prijs/FP te noemen. Het kan dus zo zijn dat een leverancier een aanbieding doet die niet realistisch is. Opportunisme en commerciële belangen spelen nou eenmaal een grote rol in deze markt. Dit is echter in niemands belang! Waarom is het belangrijk dat een aanbieding realistisch is?
- Een leverancier die een te lage en niet realistische prijs heeft afgegeven zal het project starten met een te lage begroting. Het team zal waarschijnlijk te klein zijn. Dit leidt uiteindelijk tot non-lineaire extra kosten. Dit is een garantie voor een falend project. Er wordt stress gecreëerd in het team wat zal leiden tot veel extra defects en een lagere onderhoudbaarheid van de code. De relatie tussen de leverancier en de klant zal snel slechter worden en alle changes tijdens het project, hoe klein ook, zullen een bron van discussie zijn, waarvoor de klant uiteindelijk zwaar moet betalen. Van start gaan met een te hoge begroting is ook niet efficiënt, maar kost niet meer dan er is begroot. Dit is de zogenaamde wet van Parkinson die aangeeft dat als iemand te veel tijd krijgt voor een bepaalde taak hij een manier vindt om deze tijd te besteden. U ziet dat het kiezen van een realistische begroting de voorkeur heeft. Wat is nu het effect in de praktijk? 1.01 Meten & Begroten dagdeel 1 v1.0 Sogeti Nederland B.V. v1.0
- Sogeti Nederland B.V. Stel u krijgt 3 aanbiedingen, een optimistische, een realistische en een pessimistische. Project A zal falen en misschien wel 3x over de kop gaan. Project 2 slaagt en is efficiënt. Project 3 slaagt ook, maar had efficiënter gekund. Welke aanbieding had u gekozen? Voor de aanbestedende partij is het daarom van cruciaal belang om niet automatisch de goedkoopste aanbieding te kiezen, maar om de meest realistische aanbieding te kiezen! U begrijpt dat het een grote uitdaging voor veel leveranciers is om deze kennis over te brengen bij klanten waar men alleen naar de prijs kijkt.
- Als laatste wil ik u nog een aantal aanbevelingen meegeven die volgens mij moeten leiden een betere selectie van leveranciers en daarmee tot een verhoging van het aantal succesvolle projecten.
- Stel alstublieft de juiste vragen. Het moet mogelijk zijn om een objectieve vergelijking te maken, waarbij zoveel mogelijk factoren gelijk zijn gehouden. Een cruciale stap is hierbij het vaststellen van de realiteitswaarde van de aanbieding. U kunt hierbij gebruik maken van tooling zoals de eerder genoemde QSM tools, maar ook de ISBSG database met meer dan 5200 projecten erin. Verder is het belangrijk dat u de leveranciers vraagt om e rvaringscijfers aan te leveren op basis waarvan de realiteitswaarde van zijn aanbieding kan worden getoetst Voorbeeld: een (geanonimiseerde) QSM SLIM datamanager extract van relevante projecten
- Een goede vraag zou volgens mij als volgt opgebouwd moeten zijn. Een metriek om te vergelijken, de technologische omgeving, de omvang, de complexiteit, de fasen en activiteiten die zijn inbegrepen en natuurlijk de doorlooptijd!
- U ziet hier een voorbeeld van zo’n vraag. De criteria van de vorige slide komen hier allen in terug. De antwoorden die u op deze vraag krijgt kunt u op de juiste manier met elkaar vergelijken. Het is nu belangrijk om de antwoorden te toetsen op realiteitszin.
- In deze slide ga ik uit van een project van 500 FP dat wordt gebouwd in Java. Ik heb de ISBSG database R11 gebruikt om een range vast te stellen waarbinnen een realistische aanbieding zou moeten liggen. ISBSG geeft aan dat de projecten in haar database waarschijnlijk tot de best-in-class behoren, omdat men slecht gelopen projecten niet zo snel zal aanleveren en omdat een organisatie een bepaalde vorm van volwassenheid moet kennen om uberhaupt te benchmarken. Ik heb een selectie gemaakt uit de database, waarbij ik de kwaliteit van de data, de omvang en de programmeertaal als selectiecriteria heb gebruikt. Dit levert 24 geselecteerde projecten op, die op de volgende wijze zijn gerangschikt. Als we naar de productiviteit in uur/FP kijken dan heeft 10% van de 24 projecten het beter gedaan dan 3,5 uur/FP. Ik zou als realistische range gebruiken de P25-P75. leveranciers die aangeven dat ze het goedkoper kunnen dan 7,2 uur/FP zou ik wantrouwen en dan zou ik eens goed naar het geleverde bewijsmateriaal kijken of dit wel valide is.
- Ik heb u laten zien dat het gebruik van onvolledige vragen met betrekking tot metrieken als prijs per functiepunt en uren per functiepunt leiden tot uitdagingen bij de leveranciers. De vragen zijn als het ware niet te beantwoorden zonder een bepaalde context erbij te geven. De antwoorden op de vragen kunnen dus niet goed worden vergeleken en het is eenvoudig een slechte keuze te maken als het puur om de prijs gaat. Stelt u daarom de juiste vragen en evalueer de antwoorden op realiteitszin en vraag om bewijs. Als automatisch de goedkoopste wint, zijn er te weinig goede vragen gesteld! Sogeti Nederland B.V.
- Dit is een onderwerp dat voor mij persoonlijk erg belangrijk is. Ik zal daarom op de International Workshop on Software Measurement een workshop leiden dat wat mij betreft zou moeten leiden tot een standaard set vragen waarmee aanbestedingen kunnen worden uitgerust om op een objectieve en realistische manier de juiste leverancier te kiezen. De resultaten zal ik uiteraard delen op onze site en via media als SlideShare op linkedIn. Sogeti Nederland B.V.
- Bedankt voor uw aandacht.