Is Correct begroten van softwareontwikkeling/onderhoud toch mogelijk ?
“Software Sizing, Estimating, Control en Benchmarking”
Verwachtingen NGI Uitnodiging NGI 20 april 2006 • Software sizing • Estimating, control, benchmarking • 70 % projecten niet volgens verwachting • RAD, RUP, DSDM, webapplicaties, ERP • FPA technieken • Hulpmiddelen om te begroten (SLIM) • Praktijkvoorbeelden • Randvoorwaarden • Baten van de aanpak voor verschillende partijen: opdrachtgever, opdrachtnemer, ontwikkelaar….financiële controller, inkoper, klant, management……
Wie van u is in staat om “goed” te begroten ? • • • • • • • • • •
Transparant Herhaalbaar Gebaseerd op een product (omvang) Onzekerheden Kwaliteit Tijdsdruk Wijzigingen tijdens de ontwikkeling (of heeft u die niet ?) Complexiteit Ontwikkelomgevingen Industrie (administratief financieel, overheid, Telecom, scientific, control, real time? ) • Pakket implementaties (SAP, Siebel….)
Agenda • • • • • • • • • • •
wie is QSM welke dienstverlening welke klanten Hoe werkt QSM Omvang Begroten Pauze Demonstratie Estimate, Control en Benchmark Baten van de aanpak voor verschillende partijen valkuilen, waarheden, onzin van metrics wat kan QSM wel en niet
Wie is QSM? Quantitative Software Management Een Bedrijf en een Concept
WAT IS ONS DOEL? Software ontwikkeling / inkoop nauwkeurig te begroten, te monitoren om daarmee risico’s van software ontwikkeling te managen
HOE DOEN WIJ HET? Door Hulpmiddelen, Scholing en Expertise te leveren
Historie QSM? QSM inc. opgericht in 1978 door Lawrence Putnam Ex-officier US-Army, Statisticus, Ontwikkelde het SLIM model Industriedatabase >7200 projecten 4e generatie architectuur tools QSM Europe opgericht in 1994 door Hans Vonk Econoom, bestuurlijke informatiekunde Metrics specialist Managing Partner QSM Europa FPA Expertise Centrum opgericht in 2002 Voorzitter NESMA
Wat Biedt QSM ? SOFTWARE MANAGEMENT HULPMIDDELEN SLIM Estimate SLIM Control SLIM Metrics FPA Scope Manager
OPLEIDING en TRAINING QSM in SW Ontwikkeling QSM in het SW Inkoop Proces QSM Introductie voor Managers FPA (Intro, Basis, FPAi, Certificering, workshops)
EXPERTISE/CONSULTANCY Software project planning Software project monitoring en rapportage Software benchmarking Metrics implementatie FPA Consultancy / outsourcing
Klanten
Quantitative Software Management
Hoe QSM Werkt
Succesvol begroten en bijsturen van projecten
Omvang
Estimate Productiviteit
Randvoorwaarden: - Budget - Tijd - Kwaliteit - Staf Voortgangsdata - Omvang Plan - Mijlpalen - Fasen - Defects - inspannin
Metrics Post Project Analyse
Control Project evaluatie data
Voortgang, Impact Afwijkingen
Veel gestelde vragen • Wat is het verschil tussen omvang en begroten ? • Waarom is omvang belangrijk ? • Wat is de relatie tussen omvang, doorlooptijd, inspanning en kwaliteit ? • Wanneer is een project gereed om te worden opgeleverd ?
Verschil Omvang en Begroten Omvang is het meten van de grootte van een product in kleine gelijkvormige eenheden. (vergelijk aantal m3 van een bedrijfspand) Begroten is het voorspellen van de benodigde inspanning, de kosten, de doorlooptijd en de kwaliteit om een product te maken op basis van omvang en ervaringscijfers . (vergelijking: de kosten om een luxe bedrijfspand in Breukelen te bouwen zijn bv. 3000 euro per m3, inclusief bestrating etc. en heeft een doorlooptijd van 6 maanden nadat het ontwerp door de gemeente is goedgekeurd)
Quantitative Software Management
Omvang
Omvang Omvang is essentieel om historie op te bouwen en om vervolgens herhaalbaar en transparant te kunnen begroten (omvang kan bv. worden uitgedrukt in regels sourcecode, functiepunten, use-cases, requirements, componenten etc.)
Wanneer tijdens een project kan Omvang worden gemeten ? Omvang kan vanaf de start van een project worden bepaald. Onzekerheid in omvang is een vorm van risico en is zeker in een vroeg stadium in een project een natuurlijk gegeven, maar kan worden gebruikt om de reserve binnen begrotingen te berekenen. (Onzekerheid kan worden uitgedrukt in een range, bv. Min. 100, Verw. 300 en Max. 1000 eenheden)
In welke gevallen kan de Omvang worden bepaald ? In alle gevallen waarbij software wordt ontwikkeld, onderhouden, geïmplementeerd, dus ook bij: • DSDM, RUP, RAD, WEB, ERP • Pakketten (SAP, SIEBEL..) • Technische ontwikkeling, Control, Real time, Systeem, Embedded, Telecom
Waarom Omvang ? • • • • • •
Beschrijft het product Basis voor transparantie Basis voor opbouw historische projectendatabase Basis voor herhaalbare begrotingen Basis voor contract met opdrachtgever Basis voor beoordeling kwaliteit basisdocumenten (requirements, basisontwerp, technische ontwerp)
Basis voor Project- en Scope Management
Waarom FPA ? • Wereldwijde ISO gecertificeerde standaard • Uitstekende methode om omvang herhaalbaar vast te stellen • Onafhankelijk van de techniek, ontwikkelmethoden en hulpmiddelen, industrieën, • Geeft een functionele, op het gebruik gerichte methode en biedt daarom een goede basis om met de opdrachtgever te bespreken • Voldoende ervaringscijfers bekend om te gebruiken bij het begroten
Waarom wordt FPA onvoldoende gebruikt ? • FPA kan niet 1 op 1 worden vertaald in kosten en doorlooptijd (Er is dus geen betrouwbare, eenvoudige norm om te begroten zoals uren/functiepunt, ranges tussen de 3 en 100 uur per functiepunt) • Arbeidsintensief • Wordt niet gezien als vak • Wordt onvoldoende gewaardeerd • Onvoldoende experts beschikbaar • Vooroordelen door onvoldoende kennis – – – – – –
oude standaard, Zou niet objectief en vergelijkbaar zijn (verschillende interpretaties) Zou niet geschikt zijn voor nieuwe methode en technieken Zou niet geschikt zijn voor technische omgevingen Zou niet geschik zijn voor pakketimplementaties Zou niet geschikt zijn voor onderhoud
Quantitative Software Management
Estimate, Control en Benchmarking
Succesvol begroten en bijsturen van projecten
Omvang
Estimate Productiviteit
Randvoorwaarden: - Budget - Tijd - Kwaliteit - Staf Voortgangsdata - Omvang Plan - Mijlpalen - Fasen - Defects - inspannin
Metrics Post Project Analyse
Control Projectevaluatie data
Voortgang, Impact Afwijkingen
Ken U Doelen en realiseer ze Op tijd leveren Binnen budget leveren Leveren wat beloofd is Betrouwbare Producten
Om Software Management Doelen te kunnen realiseren
Meten is het sleutel woord
Indien u niet meet , kunt u het niet managen!
Er zijn honderden mogelijke factoren en elke omgeving is uniek Management
Specificatie
Gebruikers Training Methoden Hulpmiddelen
Meer dan 175 factoren onderkend
Technieken Scholing
We moeten in het factoren vinden die Praktisch en Bruikbaar zijn
QSM Identificeert Drie Praktische en Bruikbare Ontwikkel Proces Factoren Software Product Hoe groot ?
Software Proces Hoe Efficiënt?
Doorlooptijd Hoeveel Tijdsdruk
De Belangrijkste Ontwikkel Proces Factoren die Tijd, Effort en Betrouwbaarheid Verklaren
Belangrijkste Management Factoren Proces Factor
Product Omvang
Productiviteit
Tijdsdruk
Tijd
Totale Effort
Fouten
De Belangrijkste Ontwikkel Proces Factoren die Tijd, Effort en Betrouwbaarheid Verklaren RELATIES MOETEN GEKWANTIFICEERD WORDEN OM BRUIKBAAR TE ZIJN
Belangrijkste Management Factoren Proces Factor
Produkt Omvang Productiviteit Tijdsdruk
Tijd
Totale Effort
Fouten
Hoe Kunnen We deze relaties Kwantificeren?
Verzamel empirische gegevens en analyseer ze !
Gegevens tonen de Relaties Ontwikkeltijd neemt toe met produkt omvang
Dezelfde trend is waarneembaar voor effort en fouten Duration, Effort, Discovered Defects vs. Size Duration vs. Size QSM Database
Effort vs. Size QSM Database
1000
Months
1000 100 10
1
1
10
100
1
0.1 1000
1
Effective SLOC (thousands)
Discovered Defects vs. Size QSM Database
100000
100 10 1 100
Effective SLOC (thousands)
© Quantitative Software Management, Inc. #23
0.1 1000
Discovered Defects
1000
10
100
Effective SLOC (thousands)
10000
1
10
0.1 1000
Person-Months
10000
100 10
100000
Gegevens tonen de Relaties
Produkt Omvang Team Effort Projekt Tijd Kwaliteit / Betrouwbaarheid
QSM Heeft de Relaties Gekwantificeerd
QSM Heeft de Relaties Gekwantificeerd
Larry Putnam, oprichter van QSM, definieerde de
QSM Software Proces Model ook bekend als
Software LIifecycle Management of SLIM Model
SLIM : De QSM Software Proces Vergelijking is gebaseerd op gegevens OMVANG
INSPANNING
DOORLOOPTIJD
PP = ESLOC / [((PM/12)/B)^1/3*((Maanden/12))^4/3] Piek
Staf
Stijging Daling
Tijd
SLIM Gebruikt Twee Belangrijke Proces Parameters PI - De Productiviteits Index Meet de efficiency van het software ontwikkel proces Management schaal 1-40
MBI - De Manpower Buildup Index Meet de tijdsdruk op de software ontwikkelingen 14 punts management schaal Omvat alle type software en alle ontwikkel methoden. Is gebaseerd op gegevens van meer dan 7200 actuele software projecten.
PI is de QSM Proces Productiviteits Index Alle Factoren die de Productiviteit Beïnvloeden Management
Specificatie
Gebruikers Training Methoden Hulpmiddelen
Technieken
Meer dan 175 factoren onderkend
Scholing
Uniek voor elke omgeving
QSM Proces Productiviteits Index Invloed: Administratieve omgeving
Omvang = 500 FP JAVA Mens Jaar = euro 100.000
Productiviteits Index Effort
Tijd
Kosten
Hoog
Laag
16
70
9
585.000
15
90
10
750.000
14
120
12
1,000.000
QSM Proces Productiviteits Index Invloed: Administratieve omgeving
Omvang = 500 FP JAVA Mens Jaar = euro 100.000, doorlooptijd fixed op 9 maanden
Productiviteits Index Effort
Tijd
Kosten
Hoog
Laag
16
70
9
585.000
15
158
9
1,450.000
14
325
9
2,900.000
MBI is de QSM Manpower Buildup Index (Zegt iets over staffing en tijdsdruk)
Management Schaal Staf Meet Tijdsdruk
5
Kalender Maanden
4 3
2006 J
F
M
A
M J
J
A
S
O
N D
2 1 Maanden
QSM Manpower Buildup Index Invloed:
Omvang = 500 FP, JAVA Mens Jaar = euro 100.000, PI = 15
MBI 5 4 3 2 1
Effort 200 130 90 60 40
Tijd 8 9 10 11
Kosten 1.500.000 1.000.000 680.000 450.000
13
300.000
Pauze
Quantitative Software Management Methods For Excellence
Begroten met behulp van SLIM Estimate
Elk schot in de roos
Voorbeeld Estimate Staffing & Probability Analysis CD R&D C&T
0
1
2
3
4
5
6
78
Work Breakdow n Structure
9
10
10 8
4 2 0
0
Phase 1: Concept Definition Determine project scope and feasibility Secure project sponsorship Define and secure preliminary resources Phase 2: Reqts & Design Analysis/Software Requirements Conduct needs analysis Draft preliminary software specifications Develop preliminary budget Review/refine s/w specifications/budget with team Develop delivery timeline Design Review preliminary software specifications Develop functional specs/high level design Develop prototype based on functional specificatio Final verification functional specifications Phase 3: Construct & T est Development Detailed Design Develop code Perform developer unit testing System Testing Develop test plans Perform system integration testing Perform system acceptance testing Documentation Develop and review help system Develop and review user manuals Pilot/Training Phase 4: Perfective Maint Deployment Post Implementation Review
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 okt nov dec jan feb mrt apr mei jun jul aug sep okt nov dec jan feb mrt '03 '04 '05
1
2
3
4
5
6
78
9
10
Tasks
6
Avg Staff (people)
Milestones P_Mnt 0 - CSR 1 - SRR 2 - HLDR 3 - LLDR 4 - CUT 5 - IC 6 - STC 7 - UAT 8 - FCR 9 - 99R 10 - 99.9R
Avg Staff (people)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 okt nov dec jan feb mrt apr mei jun jul aug sep okt nov dec jan feb mrt '03 '04 '05
SOLUTION PANEL Life Cycle C&T Duration 6,9 15,5 Months Effort 6.258 10.172 MHR 361,8 588,0 EUR (K) Cost 7,3 7,3 people Peak Staff 1,5 63,8 Days MTTD 1-10-2003 Start Date 27-2-2004 PI=17,5 MBI=3,6 Eff FP=1.000
CONTROL PANEL 17,5 7,3 1000
14,0
21,0 PI
Project: test
5,8
8,7 Peak Staff
800
1200 Eff FP
Voorbeeld Estimate
SOLUTION PANEL Life Cycle C&T Duration 6,9 15,5 Months Effort 6.258 10.172 MHR 361,8 588,0 EUR (K) Cost 7,3 7,3 people Peak Staff 1,5 63,8 Days MTTD 1-10-2003 Start Date 27-2-2004 PI=17,5 MBI=3,6 Eff FP=1.000
Voorbeeld Estimate R&D R&D C&T CD C&T R&D C&T P_Mnt
1
1
0
1
2
Avg Staff (people) Avg Staff (people) <Single Goal - C&T Duration 4,4> Avg (people) <Single Goal3Staff - C&T Duration 4,4> 2 4 5 2 3
4
5
6
78
6
78 78
6 9
35 35 10
10
30 30 8 25 25
Avg Staff (people) Avg Staff (people) Avg Staff (people)
Milestones Milestones 0 - CSR 0Milestones - CSR 1 - SRR 10- -SRR CSR 2 - HLDR 21- -HLDR SRR 3 - LLDR 32- -LLDR HLDR 4 - CUT 43- -CUT LLDR 5 - IC 54- -ICCUT 6 - STC 65- -STC IC 7 - UAT 76- -UAT STC 8 - FCR 87- -FCR UAT 9 - 99R 98- -99R FCR 10 - 99.9R 10 99.9R 9 - 99R 10 - 99.9R
20 620
15 15 4
10 10
52 5
0 1
1
2
2
3
4
5
6
7
8
3 4 5 6 7 8 okt nov dec jan feb mrt apr mei jun 2 nov3 4 dec5 6 8 10 11 12 13 14 15 16 17 okt1 jan7 feb9 mrt apr mei jun '03 '04 okt'03 nov dec jan feb mrt apr'04 mei jun jul aug sep okt nov dec jan feb mrt '03 '04 '05 Project: test Project: test Project: test
0 0
Voorbeeld Estimate 0
1
2
3
4
5
6
78
9
10
Tasks
Phase 1: Concept Definition Determine project scope and feasibility Secure project sponsorship Define and secure preliminary resou... Phase 2: Reqts & Design Analysis/Software Requirements Conduct needs analysis Draft preliminary software specifica... Develop preliminary budget Review/refine s/w specifications/bu... Develop delivery timeline Design Review preliminary software specif... Develop functional specs/high level... Develop prototype based on functio... Final verification functional specifica... Phase 3: Construct & Test Development Detailed Design Develop code Perform developer unit testing System Testing Develop test plans Perform system integration testing Perform system acceptance testing Documentation Develop and review help system Develop and review user manuals Pilot/Training Phase 4: Perfective M aint Deployment Post Implementation Review
Work Breakdown Structure
1 okt '03
2 nov
3 dec
4 jan '04
5 feb
6 mrt
7 apr
8 mei
9 jun
10 jul
Project: test
11 aug
12 sep
13 okt
14 nov
15 dec
16 jan '05
17 feb
mrt
Vergelijking Plan versus industrie en eigen historische projecten Validate Estimate with History Validate Estimate with History C&T Duration (Months) vs Effective SLOC C&T Duration (Months) vs Effective SLOC
100 100
10 10
1
1 1 1.000 1.000
10 10
100 100
Effective SLOC (thousands) Effective SLOC (thousands)
PI vs Effective SLOC PI vs Effective SLOC
50 50
CONTROL PANEL <Single Goal - C&T Duration 4,4> CONTROL PANEL <Single Goal - C&T Duration 4,4> 20,4 31,0 1000 20,4 31,0 1000
30 30
PI PI
20 20
16,3 16,3
10 10
10 10
100 100
PI PI
24,5 24,8 37,2 800 1200 24,5 24,8 37,2 800 1200 Peak Staff Eff FP Peak Staff Eff FP
0 0 1.000 1.000
Effective SLOC (thousands) Effective SLOC (thousands)
Current Solution Current Solution
0,1 0,1 1.000 1.000
Effective SLOC (thousands) Effective SLOC (thousands)
40 40
Historical Projects Historical Projects
QSM 2005 Business QSM 2005 Business
Avg. Line Style Avg. Line Style
1 Sigma Line Style 1 Sigma Line Style
Project: test Project: test
1
C&T Effort (MHR) (thousands) C&T Effort (MHR) (thousands)
100 100
1.000 1.000
C&T Duration (Months) C&T Duration (Months)
10 10
10 10
C&T Effort (MHR) vs Effective SLOC C&T Effort (MHR) vs Effective SLOC
100 100
Quantitative Software Management Methods For Excellence
Monitoren van de Project Voortgang en het Beheersen van uit de hand gelopen Projecten
Elk schot in de roos
Vergelijk Voortgang met Plan S SS S
2 22 2
Size Size
3 458 6 9 11 7 10 12 66 9 11 7 10 12 3 3 44558 3 45 6
13 13
1415 1415
16 16
120 120
Stoplichten geven advies voor herplanning 100 100
80 80
60 60
ESLOC (thousands) ESLOC (thousands)
Actual Actual Interpolated Interpolated Plan Plan Green CB Green CB Yellow CB Yellow CB S = Start S = Start 2 = G-CDR 2 = G-CDR 3 = G-FCC 3 = G-FCC 4 = C-CDR 4 = C-CDR 5 = G-SIT 5 = G-SIT 6 = C-FCC 6 = C-FCC 7 = N-CDR 7 = N-CDR 8 = CDR 8 = CDR 9 = C-SIT 9 = C-SIT 10 = FCC 10 = FCC 11 = N-FCC 11 = N-FCC 12 = N-SIT 12 = N-SIT 13 = SIT 13 = SIT 14 = UOST 14 = UOST 15 = IOC 15 = IOC 16 = FOC 16 = FOC
De actuele data is structureel 40 40 buiten de groene bandbreedte. 20 20
0 0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 * 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 * Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul '95 '96 '95 '96 1
Date 31/07/96 (19.00 mos) Date 31/07/96 (19.00 mos) Size (ESLOC(K)) Size (ESLOC(K)) PI PI MBI MBI
Plan Plan 89.92 89.92 14.1 14.1 4.1 4.1
Actual Actual 49.03 49.03
%Diff %Diff -45.5 -45.5
Wanneer dingen fout gaan . . . Herplan Size S S
3 3
458 6 9 11 7 10 12 13 45 6 7 9 8
1415 11 12 10
16 13
14 15
16
120
100
80
60
40
QSM zoekt passende curve bij de actuele data om de bijbehorende einddatum te vinden.
20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 * Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul '95 '96
Date 31/07/96 (19.00 mos)
Size (ESLOC(K)) PI MBI
Plan 89.92 14.1 4.1
Actual/ Forecast 89.57 11.5 3.1
%Diff -0.4 -18.2 -13.7
ESLOC (thousands)
Actual Interpolated Forecast Plan Green CB Yellow CB S = Start 2 = G-CDR 3 = G-FCC 4 = C-CDR 5 = G-SIT 6 = C-FCC 7 = N-CDR 8 = CDR 9 = C-SIT 10 = FCC 11 = N-FCC 12 = N-SIT 13 = SIT 14 = UOST 15 = IOC 16 = FOC
2 2
Monitor Project Voortgang tegen Plan Schatten, Volgen en Voorspel wanneer het project gereed is met SLIM Control Gantt Chart S S
24 7 24
Aggregate Staffing Rate S S
7
24 7 24
Total Cum Effort S S
7
MB
50
Maint
Jan '96
3 Jul
9 Jan '97
15 21 Jul Jan '98
27 Jul
* Jan '96
Total Defect Rate S S
24 7 24
S S
7
Jan '96
9 Jan '97
15 21 Jul Jan '98
27 Jul
24 7 24
S S
15 21 Jul Jan '98
27 Jul
Current Plan Actual Interpolated S = Start, 2 = DDES, 4 = CUT, 7 = DEL
0 *
24 7 24
7
Jan '96 Current Forecast
15 21 Jul Jan '98
60
Green Control Bound
27 Jul
0 *
24 7 24
7
3 Jul
9 Jan '97
15 21 Jul Jan '98
27 Jul
0 *
Date 12/6/97 (19.18 mos)
20 9 Jan '97
27 Jul
40
Jan '96
40
3 Jul
15 21 Jul Jan '98
80
0 *
0 *
$ (millions)
600
200
Jan '96
3 Jul
9 Jan '97
Total MTTD
7
Total Cum Cost
9 Jan '97
3 Jul
S S
1000
0 *
400
3 Jul
24 7 24
Size 7
Jan '96
2000
ESLOC (thousands)
S S
0 *
Days
Jan '96
27 Jul
27 Jul
Defects
100 15 21 Jul Jan '98
15 21 Jul Jan '98
Defects
200
9 Jan '97
9 Jan '97
1000
Total Cum Normalized Defects 300
3 Jul
3 Jul
2000 PM
100
7
People
150
24 7 24
Elapsed Months Agg. Staff Total Cum Effort (PM) Total Defect Rate Total Cum Normal Defects Total MTTD (Days) Size (ESLOC(K)) Total Cum Cost ($ M) PI
Yellow Control Bound
Plan 18.52 24.17 1338.99 4 1622 5.06 398.54 30 18.6
Actual/ Forecast 18.52 81.45 1746.07 9 1044 2.53 443.40 39 16.8
Life Cycle includes MB, Maint
%Diff 0.0 237.0 30.4 96.4 -35.6 -50.0 11.3 30.4 -9.7
Quantitative Software Management
Baten voor verschillende partijen
Baten van de aanpak voor verschillende partijen • QSM levert alleen informatie waarmee partijen kunnen sturen. • Alleen die partijen die bereid zijn om te sturen met deze informatie hebben baat bij deze aanpak. • Kritieke succesfactor ligt in het op het juiste niveau binnen de organisatie plaatsen van deze aanpak: dwz dicht bij beslissers. • Beslissingen worden transparant, onderbouwd op feiten. • Inkopers kunnen leveranciers beoordelen op hun prestaties. • Leveranciers kunnen objectief de impact van omvang, complexiteit, doorlooptijd, kwaliteit en wijzigingen aantonen en bespreken. • Opdrachtgevers kunnen een bewustere keus maken waarin zij investeren en wat de alternatieven zijn. • Verwachtingen worden gemanaged. • Projecten hoeven niet meer te falen !!!!
Quantitative Software Management
Onzin, valkuilen, waarheden
Onzin van metrics
• • • • • •
vervangt expert schattingen is alleen functiepunten invoeren een vaste prijs per FP (absoluut dus niet !!!) simpele modellen, tegen geringe kosten zelf te ontwikkelen levert vooral weerstanden op levert geen directe besparingen op
Valkuilen
• Te veel aandacht voor een technisch model en niet voor de invoering (veranderingsproces) • Informatie niet tijdig beschikbaar • Informatie wordt niet gebruikt • Informatie komt niet bij de beslissers • Informatie maakt falen uit het verleden duidelijk • Misbruik en manipulatie van informatie • Meet het proces en niet de medewerkers • Metrics functie te laag in de organisatie gepositioneerd • Metrics functie als een part-time functie zien
Waarheden • • • • • • •
Projecten falen >70 % Veel falen kan voorkomen worden Daarmee kunnen besparing van > 20 % worden bereikt Het SW ontwikkelproces wordt inzichtelijk Levert (initieel) weerstanden op Grote projecten zijn relatief goedkoper, maar risicovoller Kleine teams zijn productiever, leveren betere kwaliteit, tegen een gering verlies aan doorlooptijd • Cijfers kunnen worden gemanipuleerd
Hoe kunnen wij u helpen? • Informatie leveren om projecten / outsourcing te managen • Omvang van projecten bepalen • een marktconform plan leveren • offertes vergelijken met de industrie database • projectgegevens verzamelen • produceren van voortgangsrapportages • verzamelen historische gegevens leveranciers • leveranciers benchmarken • Ondersteuning bij het selecteren van de leverancier
• QSM levert essentiële informatie !!!
Tot slot
U bent succesvol, als u in staat bent om de geleverde informatie daadwerkelijk te gebruiken om uw projecten beter te beheersen.
