Methodisch Begroten van Projecten

Sogeti Sizing,Estimating & Control

Harold van HeeringenSizing, Estimating & Control

harold.van.heeringen@sogeti.nl

Harold van HeeringenConsultant Software MetricsAfdeling Sizing, Estimating & ControlSogeti Nederland B.V.Harold.van.heeringen@sogeti.nl Twitter: @haroldveendam

Nesma-Voorzitter wg COSMIC-Wg Benchmarking-Wg Begroten

COSMIC-Benchmarking initiative

ISBSG-Executive advisor

DACE/ISPA-SIG Parametrische Analyse

Computable- Expert panel ICT branche

Even voorstellen

Wat wil ik jullie laten zien?

Methodisch begroten van Projecten is een cruciale factor voor het succesvol realiseren van projecten.

Outline

• De IT industrie heeft een enorm probleem met het begroten van projecten. Waarom?

• Wat kunnen we doen om realistisch te begroten?

• Enkele tips

Waarom heeft de IT industrie een begrotingsprobleem?

Veel projecten falen

• Standish Chaos report (2009) [1]

> 32% van de projecten is succesvolOp tijdBinnen budgetBevat 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 succes percentage (35%) ten opzichte van de vorige studie (2007).

Maar waarom?? • Instabiele user requirements

>Te vroeg starten met realisatie>Gebruikers te weinig/ te laat betrokken

• Onrealistische begroting en planning>Expertbegrotingen – niet gebaseerd op

ervaringscijfers>Gewenste doorlooptijd ipv. Realistische doorlooptijd

• Onrealistische verwachtingen !!

Hoe worden projecten begroot?• Vrijwel altijd: expertbegroting

>Kennis/ervaring experts>Hulpmiddelen (vaak excel)>bottom-up: uren per activiteit

• Resultaat: gemiddeld 30% te optimistisch>Moeilijk te onderbouwen, Uren

optimistisch ingeschat >Experts gaan niet zelf al het werk doen>Vergeten activiteiten

Te optimistisch schatten [3] W

aars

ch

ijn

lijk

heid

Inspanning

50/50 mediaan resultaat

90% . . . . . . . . . . . . . . . . 24 uur75% . . . . . . . . . . . . . . . . 22 uur50% . . . . . . . . . . . . . . . . 20 uur10% . . . . . . . . . . . . . . . . 18 uur 0% . . . . . . . . . . . . . . . . 16 uur

. . . . . . . . 14 uur

. . . . . . . . 12 uur

. . . . . . . . 10 uur

. . . . . . . . 8 uur

. . . . . . . . 6 uur

. . . . . . . . 4 uur

. . . . . . . . 2 uur

Expert Schatting: 1e mogelijkheid

0%

100%

Bv: taak – Codeer en Unittest Programma X

expertbegroting

realistische begroting

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

Onderschatten of overschatten [3]

Onderschatten

Overschatten

Lineaire extra kosten

Extra uren worden besteed

Te lage schattingen

Extr

a K

oste

n

0%

>100%

Te hoge schattingenRealistische schattingen

Non- Lineaire extra kosten

-Planningsfouten

-Vergroten team veel duurder maar nauwelijks sneller

-Extra management attentie / overhead

-Stress: Meer defects, lagere onderhoudbaarheid !!

A

Realisati

e (

uu

r)5.000

15.000

CB

10.000

5.000 uur

3.000 uur

7.000 uur

7.000

Begroting Resultaat

A: Optimistisch3.000 uur

5 maanden

!Faalt10.000 uur

12 maanden

7

B: Realistisch5.000 uur

maanden

!

7

SlaagtEfficiënt!

5.000 uur

maanden

C: Pessimistisch7.000 uur

11 maanden

! !

SlaagtInefficiënt

7.000 uur

11 maanden

Realisatie is zeer sterk afhankelijk

van de begroting !!!

Effect in de praktijk

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

De IT heeft een probleem!

• Druk van de klant!>Klant: Het moet goedkoper >Klant: Het moet sneller>Klant: Weet exacte requirements (nog) niet>Klant: Wil een vaste prijs aanbieding (te)

vroeg in de project levenscyclus

>Klant pusht richting optimisme ipv realisme!

De IT heeft een probleem!

• IT – begroot (te) optimistisch!>IT - Weet niet precies ‘hoe groot’ het is

Onvolwassen begrotingsmethodieken

>IT - kent haar eigen performance nietKan begroting niet goed onderbouwenWeet niet goed wat realistisch isLeert slecht van verleden

>IT gaat relatief eenvoudig mee met optimisme

Wat kunnen we doen om realistisch te begroten?

Realistisch begroten

• Optimisme leidt tot falende projecten

• Maar hoe kunnen we een realistische begroting maken?

• Naast expertbegroting ook een methodische begroting !!

Methodische Begroting

Meten van Functionele Omvang

Omvang in Functiepunten

Gebruik ervaringscijfers

Productiviteit: Uren per functiepunt

Gebruik Tools

Scenario-analyse (doorlooptijd, teamsize, etc.)

Analogie – begroten van verven muur

>Meten omvang met ISO maat (centimeters) en instrument (meetlat)

oppervlakte in m2

>Ervaringscijfers (benchmark data??)Roller: 15 m2 per uurBlokwitter: 8 m2 per uurKwast: 4 m2 per uur

>Scenario analyse1 of 2 schilders?Moet in 1 dag af!Voorbewerken? Onregelmatig oppervlak? ETC!

Meten van functionele omvang

• Functiepunt analyse (FPA) of COSMIC>Omvang is samen met productiviteit de

belangrijkste factor die de benodigde inspanning bepaald

>Objectieve, herhaalbare, verifieerbare methodes (beiden ISO normen)

>Kwantificeren de door de gebruiker gewenste functionaliteit in een eenheid (functiepunt (FP) of COSMIC functiepunt (CFP))

>Ook toepasbaar vroeg in PLC !

Functiepuntanalyse

Gebruikers Transacties Gegevensverzamelingen

ILGV

KGV

IF

OF

UF

COSMIC

Gebruikers Transacties Gegevens

W

X R

E

Cone of uncertainty

0

-50

50

100

150

200 Feasibilitystudy

Requirementsspecification

Software development

Pro

ject

clo

su

re

Vari

ab

ilit

y (

%)

Time

Slecht begroot of slecht beheerst project

De kegel wordt niet vanzelf nauwer. Men neemt beslissingen om hem

nauwer te maken. Het later wijzigen van deze beslissingen leidt ertoe dat

de kegel weer wijder wordt.

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

• Benchmarking !!

Ervaringscijfers

• Eigen ervaringscijfers>Per omgeving (Java, Oracle, .Net, etc.)>Per ontwikkelfase (ontwerp, bouw, test)>Per locatie (onshore, offshore)

• Benchmarkcijfers>Databases van de tools (bv QSM SLIM)>ISBSG repository (R11 - 5.200 projecten)[4]

Voorbeeld QSM Datamanager [6]

ISBSG

• Primary Programming Language = Cobol

ISBSG R11

MEASUREMENT VALUES in I NTERVAL 435

AVERAGE (P50) 25,3PERCENTI LE10% (P10) 4,1PERCENTI LE 25% (P25) 7,6MEDI AN 15,7PERCENTI LE 75% (P75) 28,1PERCENTI LE 90% (P90) 51,6

www.isbsg.org

Generiek begrotingsmodel

Behoefte Software

Energie

Softwareontwikkel

proces

Afval

Tijd

Omvang Omvang

Fouten

Inspanning

Doorlooptijd

Fouten

Productiviteit

Factor: Omvang

Functiepunten

Factor: Omvang

Lines of Code

Factor: InspanningAantal uur

Instroomsnelheid

Piekbezetting

Factor: Doorlooptijd

Aantal weken

Factor: Kwaliteit

Aantal fouten

Factor: ProductiviteitSamenstelling en ervaring

teamOntwikkelomgeving

ComplexiteitKwaliteitssysteem

Externe beinvloedingsfactoren

Doorlooptijd is extreem belangrijk [4]

Inspanning (uur) =

Onm

ogelijk

Onpraktisch

Insp

an

nin

g

Doorlooptijd

Plan A: 7.500 uur, 7 maanden

Plan B: 4.400 uur, 8 maanden

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)

Constante

Doorlooptijd4

Estimate / Business Case

Kosten afhankelijk van Time-to-market

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

Tools: QSM SLIM [6]

QSM SLIM Estimate [6]

Historische data [6]

Tuning van de PI

QSM SLIM Estimate - voorbeeld

Avg Staff (people)<Single Goal - Life Duration 9,9>

1 2 3 4 5 6 7 8 9 10 11okt'09

nov dec jan'10

feb mrt apr mei jun jul aug sep

0

2

4

6

8

10

Avg S

taff (people)

65432

FOB&T

Milestones 2 - FOG 3 - TOG 4 - BG 5 - STG 6 - UAG

Milestones 2 - FOG 3 - TOG 4 - BG 5 - STG 6 - UAG

WBS [6]

Vergelijken met historyCompare Estimates to Historical Data

B&T Duration (Months) vs Effective FP

10 100 1.000 10.000

Effective FP

1

10

100

B&

T D

uration (Months)

B&T Effort (MHR) vs Effective FP

10 100 1.000 10.000

Effective FP

0,1

1

10

100

1.000

B&

T E

ffort (MH

R) (thousands)

Current Solution Logged Solutions Historical Projects QSM 2008 Business FP Av g. Line Sty le 1 Sigma Line Sty le Project: Klant X - Project Y

Wat levert methodisch begroten op?

Voor de organisatie> Inzicht in de performance over projecten heen> Mogelijkheden tot interne en externe

benchmarking> Verhoogde grip: voorspelbaarheid en

transparantie> Onderbouwing initiatieven voor

procesverbetering> Afspraken met leveranciers m. b. t.

kostenreductie

Welke organisatie wil dit niet?

Wat levert methodisch begroten op?

Voor het project, de projectleider> Beter onderbouwde en verdedigbare begroting> Aanvullende zekerheid naast de expertbegroting> Uitspraak over de kwaliteit van de documentatie

Welke Projectleider wil dit niet??Maar hoe richt u zoiets in??

Hoe kunt u uw organisatie hierop inrichten?

Estimating & Performance Measurement Proces

planBegroot

do

Administreer

check

Evalueer

actRapporteer

Omvangsmeting: COSMIC/FPA

Begrotingstools: QSM SLIM Estimate/ ISBSG

Data collectie: Administreer projectresultaatOmvang: geleverde omvangTool: QSM Datamanager

Finetunen begrotingstools:Analyseer metrics, Raporteer trendsTool: QSM Metrics

Verzoek tot begroting

Project uitvoering

Project afgelopen

Per kwartaal

Resultaat: Methodische Begroting (naast expertbegroting!)

Resultaat: Management rapportage en Bijgewerkte begrotingstools

Resultaat: Database met project ervaringscijfers

Project administratie-Standaard WBS-Zuiver boeken van uren-Registreren issues

Tracking tools- QSM SLIM Control

Gecontroleerde uitvoering

Hulpmiddelen

• Functional Sizing Methode>NESMA FPA Rabobank>COSMIC Rabobank>functionele mailbox: fm.rn.gict.sr.ba

metricsgroep

• Toolsuite>QSM SLIM Rabobank

Processen

• Estimating proces>Coördinator rol>Inrichten templates en sjablonen>Uitvoeren FPA / COSMIC>Uitvoeren methodische Begroting>Expert challenge>Vastleggen definitieve begroting

Staffing & Probability Analysis

Avg Staff (people)<Quick Estimate Wizard Solution>

1 2 3 4 5 6 7 8 9 10jul'10

aug sep okt nov dec jan'11

feb mrt apr mei jun

0

2

4

6

8

10

Avg

Sta

ff (pe

op

le)

87654321

R&DC&T

Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R

Milestones 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R

RISK GAUGE<Quick Estimate Wizard Solution>

<No constraints>

DurationEffort

Peak StaffQuality

% 0 20 40 60 80 100

SOLUTION PANEL - <Quick Estimate Wizard Solution>

DurationEffortCost

Peak StaffMTTD

Start Date

C&T6,842

723,28,3

1,2091-11-2010

Life Cycle9,855

954,68,3

1,2091-8-2010

MonthsPM$ (K)peopleDays

PI=18,8 MBI=3,7 Eff SLOC=55.000

CONTROL PANEL<Quick Estimate Wizard Solution>

PI 15,0 22,6

18,8

Peak Staff 6,6 9,9

8,3

Eff SLOC (K) 44 66

55

Processen

• Control proces>Coördinator rol>Inrichten templates en sjablonen>Oplevering data vanuit project>Meten changes (COSMIC/FPA)>Uitvoeren Control>Forecasting>What-if scenario’s >Oplevering Status / Forecast rapport

SEI Core Metrics

Schedule

6 12 18 24 30 36 42 48 5403-10

'0914-11 26-12 06-02

'1020-03 01-05 12-06 24-07 04-09 16-10

Bouw & Test

Ph

ase

s

10

Milestones 10 - INC10Milestones 10 - INC10Milestones 10 - INC10

Size

6 12 18 24 30 36 42 48 5403-10

'0914-11 26-12 06-02

'1020-03 01-05 12-06 24-07 04-09 16-10

0

1.000

2.000

3.000

4.000

5.000

FP

10

FTE Staff

6 12 18 24 30 36 42 48 5403-10

'0914-11 26-12 06-02

'1020-03 01-05 12-06 24-07 04-09 16-10

0,0

2,5

5,0

7,5

10,0

12,5

15,0p

pl

10

Date 12-6-2010 (36,43 weeks)

Cum Eff FP (FP)Avg Staff Life Cycle (ppl)PIMBI

Plan3.765,7

9,121,6

2,6

Actual/Forecast

2.065,08,0

20,31,6

Est. toComplete

1.811,1

Current Plan Actuals Current Forecast Green Control Bound Yellow Control Bound Project: Solv eon SOLV-IT

Processen

• Data collectie>Coördinator rol>Inrichten templates en sjablonen>Oplevering data vanuit project>Vaststellen projectomvang (COSMIC/FPA)>Vastleggen in QSM Datamanager>Benchmarking>Oplevering Benchmarkrapport

Processen

• Analyse en rapportage>Coördinator rol>Inrichten templates en sjablonen>Analyse ervaringscijfers>Opleveren management rapportages>Aanpassen tools/templates

Trendlines uren/fp 3GL enkel fp

Uren / FP vs Effective FP

10 100 1.000 10.000

Effective FP

1

10

100

1.000

Ure

n / F

P

Uren / FP vs Effective FP

10 100 1.000 10.000

Effective FP

1

10

100

Ure

n / F

P

Uren / FP vs Effective FP

10 100 1.000 10.000

Effective FP

1

10

100

1.000

Ure

n / F

P

3GL Cobol Jav a QSM 2008 Business FP Av g. Line Sty le 1 Sigma Line Sty le

Wat kun je nu al doen als PM??

• Maak gebruik van standaarden• Laat een omvangmeting maken • Reality check van de

expertbegroting• Achteraf vastleggen van data• Benchmark je project bij ISBSG

>www.isbsg.org

ISBSG• Not-for-profit organisatie• 3 Belangrijke Questionnaires en

repositories>Software New Developments &

Enhancements>Software Maintenance & Support>COSMIC Industry Data

• Download questionnaire: www.isbsg.org• ISBSG anonimiseert de data• Je ontvangt gratis een benchmark

rapport!

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

Wat heb ik u laten zien?

Methodisch begroten van projecten is een cruciale factor voor het succesvol realiseren van projecten.

Bronnen

[1] Standish Group – Chaos report 2009, http://www.standishgroup.com

[2] Sogeti Nederland B.V., http://metrieken.sogeti.nl/Home/SEC/Publicaties.jsp

[3] McConnell – Software Estimation, demystifying the black art, 2006[4] Putnam & Myers - Five core metrics, The Intelligence Behind

Successful Software Management, Dorset House Publishing 2003[5] ISBSG – http://www.isbsg.org[6] QSM – http://www.qsm.com of http://www.qsm-europe.com [7] Galorath SEER – www.galorath.com