Projectmanager moet schatting inzichtelijk maken
Lead Expert Estimating
Expert van Computable voor de topics: Development en Beleid
MeerHet schatten van de duur en kosten van ict-projecten is en blijft een lastig proces. Vaak zie je dat organisaties hiervoor geen duidelijk methodiek kiezen en niet leren van voorgaande projecten. Intern hebben ict-afdelingen dit misschien wel goed georganiseerd, maar meestal is slechts een deel van het proces vastgelegd in officiële standaarden, waardoor de aanpak verre van transparant is. Steeds vaker eisen organisaties dat wordt vastgelegd hoe een schatting is gemaakt.
Er klinkt een steeds luidere roep om transparantie in de maatschappij: inzicht in de kosten voor je mobiele telefoon, inzicht in de kosten van je koopsompolis, inzicht in de provisie van je hypotheekadviseur. Maar hoe zit het met transparantie van schattingen? Hoe is men tot deze schatting gekomen? Wat is nu precies in deze schatting meegenomen? Onder welke voorwaarden geldt deze schatting? Hoe verhoudt deze schatting zich tot voorgaande projecten? Om deze vragen te beantwoorden moet het schattingsproces stap voor stap worden doorlopen.
Een eerste stap is het definiëren van standaardmethodieken om te voorkomen dat bij ieder project het wiel opnieuw wordt uitgevonden of in het ergste geval bij ieder project een nieuw wiel wordt uitgevonden. Standaardmethodieken zijn omvangmetingen zoals de Functiepuntanalyse (FPA) of de COSMIC Functional Size Measurement Method (COSMIC), maar ook gestandaardiseerde expert-schattingsmethodieken zoals schattingen op basis van 'Proxies' of 'Stereotypen'. Uiteindelijk gaat het om de bepaling van de omvang, waarbij 'Proxies' of 'Stereotypen' standaardelementen zijn die in een bepaald type systeem voorkomen.
Het bepalen van deze omvang is slechts een voorbereiding van de tweede stap in het proces, het inschatten van de benodigde inspanning. Hoeveel tijd is nu nodig voor een 'functiepunt'? Hoeveel tijd is nu nodig voor een 'stereotype'? Het is natuurlijk mogelijk om hier een inschatting voor te geven, maar waar is deze dan op gebaseerd? Welke aannames zijn hierbij gedaan? Wat is nu precies in die inschatting meegenomen? Het is als met de kosten voor een mobiele telefoon, je denkt 'ik betaal per minuut', maar in sommige gevallen komen hier starttarieven bij en als je over je bundel heen gaat gelden ineens andere prijzen, om maar te zwijgen over de telefoon zelf, een reparatie hieraan of aansluitingskosten. Het moet duidelijk zijn want alleen met transparantie kan je de kosten kan je twee telefoonproviders of twee ict-bedrijven met elkaar vergelijken. Enkel een prijs per 'functiepunt' of per 'stereotype' zegt dan ook niets en maakt het nog steeds onmogelijk om appels met appels en peren met peren te vergelijken. Zoals ook de eenheidsprijs voor fruit niet bestaat moet je ook bij schatten weten waar je nu precies over praat.
Om te komen tot een goed onderbouwde inspanning is een derde belangrijke stap nodig, het leren van ervaringen binnen je eigen organisatie als ook van anderen (benchmarking). Om deze ervaring op te bouwen is het belangrijk om metrieken te verzamelen tijdens en na afloop van projecten. De grote vraag is echter, welke metrieken? En wat betekenen die metrieken nu precies? Om de inspanning van nieuwe projecten te kunnen bepalen, meten de meeste organisaties in ieder geval de inspanning van voorgaande projecten. Echter, hoe zit het met doorlooptijd en kwaliteit? Doorlooptijd, en met name tijdsdruk, kan een grote invloed hebben op de inspanning. Maar ook teveel tijd leidt tot extra kosten (in extreme gevallen het telkens weer inwerken van nieuwe mensen). De te besteden tijd kan daarbij weer invloed hebben op de kwaliteit. Om het dan nog maar niet te hebben over invloeden van niet functionele eisen, gebruikte technologie, complexiteit van de software en teamervaring. Dit is ook zo'n stap die binnen de meeste organisaties wel wordt gedefinieerd maar helaas nog onvoldoende is gestandaardiseerd. De IEEE 1045-1992-standaard is een goede stap in de richting, echter nog onvoldoende. Zonder verdere standaardisatie wordt het al lastig om cijfers binnen één organisatie te vergelijken en maakt het benchmarking met andere organisaties vrijwel onmogelijk.
Van de stappen definiëren van standaardmethodieken, schatten van de benodigde inspanning en het leren van ervaringen is alleen de eerste stap voldoende vastgelegd in officiële standaarden. Het wordt dan ook tijd dat we onze aandacht vestigen op verdere standaardisatie van de inspanningsbepaling, vastlegging van metrieken en benchmarking. Dan zijn we pas echt op weg naar transparantie.
Goed projectmanagement kan alleen als er een goede business case is opgesteld. De redactie van Computable zoekt naar de beste business case van het jaar 2009. Een vakkundige jury buigt zich over voorgedragen cases en kiest de uiteindelijke winnaar.
Via een invulformulier kunnen bedrijven hun business case bij Computable aandragen. Uiteraard zijn business cases van afgeronde projecten welkom, maar ook de business cases van nog lopende of nog te starten projecten zijn welkom. Zolang de business case of het project maar linkt aan het jaar 2009.
Het aanmelden van business cases kan tot en met 20 januari 2010. In april 2010 worden de beste business cases van 2009 bekendgemaakt, mede in de jaargids Computable Business Cases 2010.
Michel Kraaij, 03-12-2009 16:49
jaja, 04-12-2009 0:17
Peter, 04-12-2009 13:03
Verder is mijn stelling dat ICT projecten niet bestaan, het maken van ICT is immers geen doel. Vaak is het de verbetering van een businessproces en moet je voor de transparantie ook al die kosten meenemen die nodig zijn voor het bedenken van het nieuwe proces. Dit is dus inclusief het beschrijven van alle activiteiten die niet met ICT worden gedaan.
Verder zijn de kosten voor het beheer vaak een veelvoud van de projectkosten, iets dat vaak vergeten wordt maar voor de transparatie cruciaal is. Je bent er namelijk niet met versie 1.0
Transparantie is dus meer dan vertellen wat je gaat doen maar ook vertellen wat er nog meer moet gebeuren. Dit alles aan je ICT projectmanager overlaten is vragen om ellende, die is namelijk wel klaar met versie 1.0 van de software. Dat beheer en je organisatie niet klaar zijn was niet zijn opdracht.
Nico Viergever, 04-12-2009 13:13
Wanneer je van houding verandert en het project ziet als een verbetering van een businessproces, zul je ook anders over de planning gaan denken. Niet meer gelijk in technische details maar plannen vanuit business products. Hierdoor zal de planning aan de gebruikerskant duidelijker en transparanter worden. De planning zal ook van beter kwaliteit worden: beter onderbouwd en meer inzicht in verwachtingen, onduidelijkheden en risico's.
Maar het feit blijft dat een planning altijd een voorspelling is en daarom nooit uitkomt.
Armand Jeffrey, 04-12-2009 13:24
Wat mij verbaast is dat er telkens technieken worden bedacht die in de praktijk worden toegepast waarvan bijna niemand kan beweren of deze op enige wetenschappelijke benadering berust of niet.
Ik zou er voor willen pleiten om het vakgebied van de Project Manager, net zoals thans geldt voor Algemeen Management, te verheffen tot een wetenschappelijk object van onderzoek. Hiermee zou de wazigheid die ontstaat als gevolg van de geclaimde Best Practices eens doorgelicht kunnen worden en van bewezen en betrouwbare wetenschap voorzien kunnen worden.
Het gevolg kan zijn dat er ook betere en betrouwbaardere schattingsmodellen in het leven geroepen kunnen worden waarmee elk project, onafhankelijk van het object dan wel de discipline, op professionele wijze uitgevoerd kunnen worden en het bereiken van resultaten binnen gangbare beheersing kan plaatsvinden.
Anthony Louws, 04-12-2009 16:51
De discussie is: hoe transparant kun je projectkosten maken en helpt standaardisatie van de schattingsmethodiek daarbij?
Ik zie het zo: Schattingen van kosten en duur van een ICT project is als de kosten van een schilderij dat nog gemaakt moet worden. Je weet de literprijs van de verf, je weet de uurprijs van de schilder en als je een beetje research doet ken je de reputatie van de schilder. Maar kan je daarmee de kosten van het schilderij bepalen? Ik denk het niet.
Het maken van een stuk software is een creatief proces, mensenwerk bovendien. Je kan wel randvoorwaarden afspreken, maar je kan het nauwelijks vangen in gestandaardiseeerde regeltjes. Laat staan dat je dat wetenschappelijk zou kunnen aantonen.
Best practises zijn er natuurlijk wel. Lees dit boek eens:
Agile Estimating and Planning (Mike Cohn)
John, 04-12-2009 22:54
Tegen Eric van der Vliet zou ik willen zeggen dat ook de opdrachtgever zijn schattingen inzichtelijk moet maken. Het gaat niet om ICT, maar om de afstemming van ICT en business. De genoemde benchmarking bijvoorbeeld, geldt ook voor de opdrachtgever. Een politieke business case (zoals gebruikelijk) is een goede basis voor een avontuur, maar niet voor een project. Ook leuk, maar wel heel anders. Ook daarover moet gecommuniceerd worden.
Michel Kraaij, 06-12-2009 9:51
@John: Ik ga je opmerking omdraaien naar een vraag. Dat je een goed verhaal moet hebben om een opdrachtgever te overtuigen, lijkt mij duidelijk. Echter, kun je enkel een goede onderbouwd verhaal doen als je processen en standaarden gevolgd hebt?
Creert een chef-kok enkel een goede maaltijd als hij een recept gevolgd heeft?
John, 06-12-2009 14:28
Het antwoord op je vraag is nogal voor de hand liggend: nee. Daarbij past de opmerking dat bij het inrichten van processen en gebruik van standaarden ook al veel gecommuniceerd wordt. Het is meer dan alleen een handboek processen en standaarden droppen.
Maar zonder een goede interne communicatie en metacommunicatie, is geen goede externe communicatie. Eric van der Vliet heeft dat goed gezien.
10-02 Het einde van het begin van cloud en virtualisatie
10-02 De windwakken van de cloud-sector
09-02 Citoto
09-02 Lang leve de hackers!
09-02 Modder gooien in ICT-land
08-02 Reseller verliest slag om het groene huishouden
08-02 Hadoop lijkt een alleskunner
07-02 Hou zicht op de informatie bij HNW
07-02 Eigen werknemer kan ook een vijand zijn
06-02 Krachtenbundeling NGI en TestNet is goede zaak
10-02 Infor helpt Ferrari met bouwen F1-auto's
10-02 Veenman en 20/20 vision adviseren samen klant
09-02 ERP-traject Eigen Haard krijgt forse directiesteun
08-02 Sogeti ontslaat nog eens 110 medewerkers
07-02 Western Digital haalt hard uit naar Stellar Data
07-02 Verhuurder Capgemini-pand vecht verhuizing aan
06-02 'Marktwaardering Facebook is kwart te hoog'
06-02 Delta Lloyd verlengt contract met Human Inference
06-02 Krachtenbundeling NGI en TestNet is goede zaak
03-02 De kracht van 'niet moeten, maar willen'
|
|
Probleemloos ontwikkelen voor een hybride cloudmodel
Aanbieders van geavanceerde bedrijfsapplicaties willen nieuwe klanten graag de mogelijkheid geven om op......
| Aantal reacties met 3+ sterren | Gemiddelde waardering | |||
 | 1 | 155 | 6.4 | |
 | 2 | 121 | 6.7 | |
 | 3 | 109 | 6.4 | |
 | 4 | 79 | 6.6 | |
| 5 | 53 | 6.1 | |
| 6 | 49 | 6.3 | |
 | 7 | 48 | 6.5 | |
| 8 | 44 | 6.1 | |
| 9 | 43 | 6.0 | |
| 10 | 40 | 6.3 | |
Computable.nl is onderdeel van VNU Media, uitgever van o.a.: NationaleVacaturebank.nl | Intermediair | IntermediairPW | Carrièregids.nl | CompanyRating | NationaleStagebank.nl | Banen.nl | HRbase.nl | HRdirectory.nl | Financebase.nl | InIct.nl | InInterim.nl | InOverheid.nl | Overheidscircuit.nl | Computable | CRN | IT Knowledge Base | Tweakers.net | Recruitmentbloggers
Sitemap | Abonneren | Adverteren | Algemene voorwaarden | Disclaimer | Privacy | Alle rechten voorbehouden © 1995-2012 VNU Media