Schattingen van kosten en doorlooptijden van systeemontwikkeltrajecten zijn vaak onnauwkeurig en onbetrouwbaar, vooral doordat het totstandkomen ervan niet gestandaardiseerd is. Daar is wat aan te doen, al is het gemakkelijker de onvoorspelbaarheid als een hogere natuurwet te beschouwen en op de oude voet door te gaan.
Bij veel bedrijven en instellingen komt schatting van kosten en doorlooptijden van systeemontwikkeltrajecten tot stand door samenwerking van personen die verstand hebben van functionele specificaties (ontwerpers) en mensen die bedreven zijn in het managen van projecten (projectleiders). Uit een mix van ervaring, systeemeisen en omgevingsvariabelen komen dan de getallen tot stand. Het hele proces is in de praktijk vaak sterk persoonsgebonden, weinig gedocumenteerd en daardoor niet reproduceerbaar. De betrouwbaarheid van kostenschattingen is daardoor vaak laag. Dit is een van de oorzaken waardoor systeemontwikkeltrajecten niet binnen het budget blijven.
Het doel van omvang- en kostenschattingen is vaak tweeledig. Aan het begin van een project willen organisaties een tijdinvestering berekenen die dicht bij de uiteindelijke realisatiekosten zal liggen. Dit maakt een reële kosten-batenanalyse van het project mogelijk. In een later stadium wil de organisatie de voortgang van de uitvoering sturen aan de hand van gemaakte urenschattingen.
Hoewel veel organisaties reeds tevreden zouden zijn met het kunnen opstellen van een solide ‘business case’ en met een effectieve sturing tijdens de projectuitvoeringsfase, zijn er nog andere potentiële toepassingen van omvangschattingen. Opgebouwde ervaringscijfers vormen een krachtig instrument voor bewaking van de kwaliteit en productiviteit van de systeemontwikkelomgeving.
Geloof
Het succesvolle gebruik van elke schattingmethodiek staat of valt met een gestandaardiseerde systeemontwikkelomgeving. Deze standaardisatie is noodzakelijk om betrouwbare ervaringscijfers te kunnen opbouwen, zodat je uiteindelijk kunt voorspellen dat de realisatie van een hoeveelheid f aan functionaliteit een hoeveelheid m aan te investeren middelen vereist. Over het algemeen is het resultaat van een schattingmethodiek een bepaalde puntenscore, die volgens het geloof achter menige methodiek een lineair verband vertoont met de te investeren middelen. Die puntenscore noemen we f.
Om tot een schatting van de hoeveelheid tijd of geld te komen, vermenigvuldigen we de puntenscore met een ervaringscijfer, e. Het ervaringscijfer geeft voor een specifieke ontwikkelomgeving het aantal uren of de hoeveelheid euro’s aan waarmee één meeteenheid f correspondeert. Onder ‘specifieke ontwikkelomgeving’ verstaan we dan alle kenmerken van een omgeving waarin systeemontwikkeling plaatsvindt die van invloed zijn op de productiviteit ervan. Voorbeelden zijn: taal, platform, kennis van mensen, systeemontwikkelmethodiek, projectmanagementmethodiek en tooling. Door vermenigvuldiging van de grootheden f en e komen we tot een maat voor de investering in geld of uren (m); f (punten) x e (euro/uur per punt) is m (euro/uur).
Fataal
Hoe maken we nauwkeurige omvangschattingen en hoe rekenen we die om naar een betrouwbare voorspelling van de middeleninvestering? Zowel f als e bevatten een onnauwkeurigheid die tot een resultante onnauwkeurigheid in m zal leiden. Een afwijkende inschatting van het aantal punten samen met een afwijkende omrekeningsfactor kan een fatale combinatie opleveren die in een zeer slechte prognose voor m resulteert.
De nauwkeurigheid van f is onder andere afhankelijk van: de volledigheid en kwaliteit van de voorhanden zijnde systeemdocumentatie, de evaring van degene die de schatting maakt en de variatie tussen schattingen van verschillende personen. De nauwkeurigheid van e hangt onder meer af van: de hoeveelheid vergelijkbare projecten, stabiliteit van de ontwikkelomgeving (veranderingen in taal, platform, kennis van mensen, systeemontwikkelmethodiek, projectmanagementmethodiek, tooling et cetera).
De hierna besproken maatregelen zijn er dan ook alle op gericht f evenredig te laten zijn met de functionele omvang van het te realiseren systeem en e zo betrouwbaar mogelijk vast te stellen. Bovendien willen we m niet alleen kunnen uitrekenen, maar ook weten met welke betrouwbaarheid hij berekend is.
Succesfactoren
Er zijn tien kritieke succesfactoren in het licht waarvan de organisatie maatregelen kan nemen. Ten eerste: kies een schattingmethodiek die bij de schattingdoelstelling past. Een schattingmethodiek die je voor een vroege kosten-batenanalyse (business case) gebruikt, moet aan andere eisen voldoen dan een schattingmethodiek die je toepast bij de uitvoeringsfase. Denk aan vereiste schattingbetrouwbaarheid en vereist documentatieniveau.
Ten tweede: kies een schattingmethodiek die bij het type systemen past dat je gaat ontwikkelen. Voor administratieve systemen wordt bijvoorbeeld al tijden fpa (functiepuntanalyse) gebruikt. Er bestaan echter ook andere, eveneens ISO-erkende schattingmethodieken, zoals Cffp (Cosmic Full Function Points), die niet alleen geschikt zijn voor administratieve systemen, maar ook inzetbaar zijn om meer technische systemen, zoals ‘command-and-control’- en realtime software, te kwantificeren. De methodiek UCP (Use Case Points) sluit weer goed aan bij documentatiestandaarden (UML) die tegenwoordig vaak gebruikt worden.
Ten derde: standaardiseer de ontwerpproducten. Schattingen op basis van ontwerpdocumenten, bijvoorbeeld ‘use cases’, die de ene keer zeer gedetailleerd zijn en de volgende keer zeer globaal zullen een betrouwbare omvangschatting bemoeilijken. Zelfs met een standaard decompositieniveau moet je erop letten dat functionele beschrijvingen eenduidig zijn. Er zal altijd variatie blijven bestaan in de mate van eenduidigheid waarmee ontwerpers in staat zijn functionaliteit te beschrijven. Collegiale toetsing tijdens de ontwerpactiviteiten en de invoering van een paar kengetallen waar de functionele beschrijvingen aan moeten voldoen kan de variatie daarin verminderen. Als laatste moeten de ontwerpproducten compleet zijn. Als door bijvoorbeeld een onvolledige inventarisatie de functionele omvang van het systeem twee maal zo groot blijkt te worden, kan geen enkele schattingmethodiek een betrouwbaar resultaat opleveren.
Transparantie
Ten vierde: zorg voor ondersteunende tools. Alles moet erop gericht zijn de eigen rituelen van de schatters in het schattingproces zo veel mogelijk uit te bannen. Alleen als je maar één schatter hebt, van wie vaststaat dat hij altijd zal blijven, hoef je dit niet te doen. Zorg anders voor ’templates’ die een gestandaardiseerde uitvoering van de schatting mogelijk maken. Geef goede handleidingen voor de toepassing van deze tools.
Ten vijfde: instrueer de schatters. Iedereen moet op dezelfde manier tellen. Het geven van periodieke workshops voor het bijbrengen en vers houden van die kennis draagt bij aan een gestandaardiseerde uitvoering.
Ten zesde: bepaal welke systeemontwikkelactiviteiten wel en welke niet binnen de kostencalculaties, realisatiecijfers en richtwaarden zullen vallen. Een kosten- of urenschatting is niets waard als niet bekend is welke systeemontwikkelactiviteiten erbinnen vallen. Iedereen zal het erover eens zijn dat ontwerp, bouw en systeemtests binnen een schatting moeten vallen. Hoe zit het met projectleidersuren, opleveringsactiviteiten, acceptatietests begeleiden, documentatie, gegevensconversie en gebruikersopleiding? Het moet duidelijk zijn wat wel en wat niet binnen een kostenschatting is meegenomen. Onderdelen waarbij een hoge mate van afhankelijkheid van de gebruikersorganisatie optreedt worden vaak buiten het projectbereik gehouden omdat kosten en doorlooptijd slecht voorspelbaar zijn. Je kunt ook deze dingen in de schattingen meenemen, maar de consequentie is dat de betrouwbaarheid dan meestal afneemt. Naast deze benadering van beneden af kan je ook kijken naar de totale kosten van de systeemontwikkelorganisatie en deze relateren aan het totale ontwikkelde of onderhouden softwareportfolio. Ook de kosten van huisvesting, infrastructuur en dergelijke tellen dan mee. Dit lijkt op wat bijvoorbeeld Gartner doet als het een systeemontwikkelomgeving benchmarkt. Onze doelstelling is echter in eerste instantie niet de vergelijking met externe organisaties, maar de eigen procesoptimalisatie.
Ten zevende; zorg voor een transparante kosten- en urenregistratie. Alle op een project gemaakte kosten en uren voor de aangegeven en geselecteerde systeemontwikkelactiviteiten moeten uit de administratie te halen zijn.
Dapperen
Ten achtste: bepaal de eigen organisatiespecifieke richtwaarden. De omrekeningsfactor e is ontwikkelomgevingspecifiek. Hij hangt af van zaken als platform, ontwikkelgereedschap, type systemen, vaardigheid van projectleiders, ontwerpers en schatters enzovoort. Je hebt dus weinig aan richtwaarden die van internet of uit een boek komen. Deze zijn een aardige eerste indicatie, maar naast het feit dat ze afgeleid zijn van totaal andere systeemontwikkelomgevingen dan de onze, wordt bij deze cijfers ook helemaal niet aangegeven welke ontwikkelactiviteiten er precies onder vallen, laat staan dat dit de manier is waarop wij onze systeemontwikkelactiviteiten registreren. We zullen dus de omvangschattingen moeten relateren aan de werkelijke realisatiekosten en urenbestedingen. Als we dat voor een aantal projecten doen, kunnen we met een beetje elementaire statistiek onze eigen richtwaarden afleiden. Bovendien kennen we de precisie (standaarddeviatie) van deze richtwaarden en kunnen we bijgevolg iets zinnigs zeggen over de betrouwbaarheid van toekomstige kostenschattingen die daarop gebaseerd zijn. Een door de auteur opgezet zelflerend systeem dat zowel de richtwaarden en hun nauwkeurigheden als de historische ontwikkeling laat zien, kan daarbij helpen.
Ten negende: maak een implementatieplan. Besteed aandacht aan de integratie van de schattingmethodiek(en) met de systeemontwikkelmethodiek (Dsdm, RUP) en projectmanagementmethodiek (Prince2). Beschouw omvang-, kosten- en urenschattingen als een essentieel onderdeel van het systeemontwikkelproces. De uitvoering ervan en de calculatieproducten moeten verankerd worden in de projectmanagement- en systeemontwikkelmethodiek. Toepassing van de methodieken zelf kost tijd en geld. Houdt de registratie van ervaringscijfers en de uitgifte van richtwaarden centraal en beschouw deze activiteiten als integraal onderdeel van de kwaliteitsbewaking.
Ten tiende: ‘slecht zijn en verbeteren is beter dan slecht zijn en niets doen’. Vergist u zich niet, harde gegevens over systeemontwikkelproductiviteit en -kwaliteit en de ontwikkeling daarvan zijn alleen voor de dapperen onder de it-managers. Velen zijn bang hun baas een stok te geven om hen mee te slaan. Het is makkelijker de onvoorspelbaarheid van kostenschattingen als een hogere natuurwet te beschouwen en op de oude voet door te gaan.< BR>
Jo Sanders, consultant bij Management View, Inter Access
