Het 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.
Beste business case van 2009
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.
Met het inrichten van processen en gebruik van standaarden bereik je geen transparantie. Transparantie bereik je met communicatie.
Klant moet wensen en eisen inzichtelijk maken
Zolang business cases nog politieke documenten zijn, opdrachtgevers nog steeds allerlei (voor hun) onnodige kosten schrappen, kosten voor beheer niet meegenomen (mogen) worden en men alle overige kosten binnen de organisatie anders dan het pure ICT deel als pm posten opneemt zal een ICT project nooit transparant worden.
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.
Eens met Peter.
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.
Binnen het vakgebied Project Management worden diverse vraagstukken sinds jaar en dag als lastig, complex en problematisch gezien. Deze classificatie geldt evenssn voor het schatten en begroten van projecten of programma’s.
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.
Of ICT projecten nu wel of niet bestaan en of beheerkosten nu wel of niet onderdeel moeten uitmaken van je projectschattingen wordt door de auteur van het artikel beweert noch ontkent. Dat is volgens mij ook niet de kern van de discussie die hij hier aansnijdt.
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)
@Kraaij, zonder een goede wijze van inrichten van processen en gebruik van standaarden, is goede communicatie niet mogelijk. Denk maar eens aan de vele manieren van FPA toepassen. Communicatie betekent vaak ook uitleggen hoe jij het bedoeld en vragen hoe de ander het opvat.
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.
>> Zonder een goede wijze van inrichten van processen en gebruik van standaarden, is goede communicatie niet mogelijk. Denk maar eens aan de vele manieren van FPA toepassen. Communicatie betekent vaak ook uitleggen hoe jij het bedoeld en vragen hoe de ander het opvat.
@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?
@Kraai, lees mijn reactie nog maar eens. Ik zeg dat er intern en extern inhoudelijk gecommuniceerd moet worden en wel in twee richtingen. Je maakt vaak mee dat er verschillende definities en voorstellingen gebruikt worden, zonder dat het meteen helder was. Daarnaast is er soms ook sprake van een gebrek aan professionaliteit of integriteit. Dat levert wazige plannen, onduidelijke rapportages en schimmige offertes op. Niemand zit daarop te wachten, ook al worden daarbij nog zo veel woorden en getallen gebruikt.
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.