Conventionele planning versus waarschijnlijke duur

De conventionele manier om projecten te plannen blijkt vaan niet reëel, omdat onvoldoende rekening wordt gehouden met het voorkomen van verstoringen. Het meest beïnvloedt de complexiteit van het te ontwikkelen informatiesysteem de haalbaarheid van een project, bovendien hebben systemen de neiging steeds complexer te worden. Statistiek biedt de mogelijkheid de totale vertraging door mogelijke verstoringen te bepalen. Daarom is het aan te bevelen bij (middel)grote projecten ook een statistische methode te gebruiken die een uitspraak kan doen over de waarschijnlijke duur van het project. Sturing moet echter blijven plaatsvinden op basis van de conventionele planning.

Een statisticus waadde vol vertrouwen door een rivier, die gemiddeld één meter diep was. Hij verdronk. – Godfried Bomans

In 1986 heeft T. Capers Jones de resultaten van een automatiserings-onderzoek gepubliceerd dat hij had gehouden bij 200 grote organisaties in de VS. Hieruit bleek dat het gemiddelde softwareproject 1 jaar te laat gereed kwam en het budget met 100% werd overschreden. Verschillende andere onderzoeken hebben verder aangetoond dat ca. 25% van alle projecten nooit wordt afgebouwd. Treffende voorbeelden hiervan bereiken regelmatig de media. Omdat organisaties op toenemende schaal automatiseren, mislukken er dus steeds meer projecten. Het is de vraag of sommige van deze mislukte projecten zouden zijn opgestart als vooraf een reëlere schatting van de projectduur en kosten zou zijn gemaakt.

Dit artikel gaat in op de vraag waarom informatiesystemen steeds complexer worden en welke consequenties dit heeft voor de haalbaarheid van een project. Vervolgens belicht het de nadelen van het op conventionele wijze plannen van (middel)grote projecten. Tot slot volgen suggesties om de invloed van verstoringen op een project te verminderen.

Het begrip ‘project’ wordt in zeer uiteenlopende betekenissen gebruikt. Een van deze definities luidt: een geheel van activiteiten, uitgevoerd door een specialistische groep in een tijdelijk samenwerkingsverband, dat gericht is op een bepaald doel. In dit artikel staat ‘project’ voor een samenwerkingsverband dat bepaalde documenten moet opleveren. Tevens worden de begrippen ‘omvang’, ‘lengte’ en ‘kosten’ van een project door elkaar gebruikt. Omdat de hardwarekosten nog steeds afnemen zal de voor het project benodigde budget nl. bijna recht evenredig zijn met de duur ervan.

Te weinig beperkingen

In de loop der tijd is veel vooruitgang geboekt bij het effectiever en efficiënter ontwikkelen van informatiesystemen. Dit is bereikt door onder andere het gebruik van project- en ontwerp-methodieken en het toepassen van tools tijdens de ontwikkeling. Verder zorgt ook het gebruik van hogere generatie talen tot een hogere productiviteit van de systeemontwikkeling. Een aantal complicerende factoren doen deze vooruitgang echter grotendeels teniet.

In de eerste plaats domineren een groot aantal min of meer incompatibele hardware- en software standaarden nog altijd de markt. Dit heeft grote invloed op de koppeling van informatie-architecturen. Kenmerkend voor deze integratie zijn datacommunicatie, het fenomeen right-sizing en het feit dat bepaalde gegevens steeds vaker over de grenzen van één systeem heen worden gebruikt. Dit betekent dat het integreren van een nieuw informatiesysteem in de bestaande infrastructuur steeds complexer wordt door de toename van het aantal koppelingen.

Ten tweede neemt de strategische waarde van informatie toe. Deze trend loopt gelijk met het verzelfstandigen van organisatie-onderdelen in zogenaamde business units die dan zelf verantwoordelijk (moeten) zijn voor hun eigen informatievoorziening. Dit vereist echter een decentralisatie van budget en delen van het informatiebeleid waardoor meer betrokkenheid en deskundigheid wordt verlangd van het lijnmanagement. Het gevolg is dat het ontwikkelen en invoeren van informatiesystemen riskanter wordt, waardoor men in toenemende mate externe bureaus inschakelt.

In de ideale situatie zet een organisatie eerst de optimale processtructuur op volgens de principes van de Administratieve Organisatie. Vervolgens is het mogelijk door informatieplanning de informatiebehoefte op hoog niveau te bepalen. Via het stellen van prioriteiten wordt uiteindelijk het projectplan samengesteld, waarna men per project kan aanvangen met de systeemontwikkeling. Veel organisaties zullen echter om uiteenlopende redenen niet op dergelijke wijze een project voorbereiden. Dit betekent echter wel dat het gedetailleerd vaststellen van de informatiebehoefte bij de ontwikkeling van een informatiesysteem moeilijker wordt.

Daarbij blijkt dat de productiviteit van systeemontwikkelaars achterloopt t.o.v. de door de gebruikers gewenste functionaliteit (Demand Pull). Onder functionaliteit wordt hier verstaan: de functionele inhoud van een informatiesysteem, zowel procesmatig als qua gegevens. De eisen die de gebruiker aan een systeem stelt zijn volgens de wet van Van Waayenburg niet specifiek genoeg (de gebruiker weet niet wat hij wil, wel wat hij niet wil). Daardoor stelt men de informatiebehoefte van de gebruiker vaak genererend vast, d.w.z. A+B+C+…. Omdat de technische mogelijkheden nog steeds toenemen, worden hierbij in de praktijk vaak te weinig beperkingen opgelegd – de (overvragende) klant betaalt immers!

Het risico dat men één systeem wil ontwikkelen als oplossing voor alle problemen binnen een organisatie is niet denkbeeldig. Als de complexiteit van het te ontwikkelen systeem stijgt, groeit echter niet alleen het budget, maar ook de faalkans van het project.

Realistische ramingen

Pas bij de kosten/baten analyse weegt de organisatie de verschillende functionele alternatieven tegen elkaar af. De kosten zijn normaal gesproken redelijk voorspelbaar. De baten bestaan vaak uit kostenbesparingen op personeel, onderhoud en exploitatie en zijn daarmee afhankelijk van de organisatorische ‘fit’ van het informatiesysteem na oplevering. Daardoor is het moeilijk te voorspellen hoe hoog de kostenbesparing door het invoeren van een informatiesysteem uitvalt, zeker als dit op een hoog niveau binnen een organisatie gebeurt (strategische informatiesystemen). Hierdoor loopt men de kans dat het meest veelbelovende en dus meest omvangrijke alternatief wordt gekozen.

Volgens de wet van Plasman is de verwachte functionaliteit vaak de inverse van de werkelijke bruikbaarheid, ofwel hoe meer mogelijkheden een systeem heeft, hoe slechter het zal functioneren.

Bij het maken van een betrouwbare kosten/baten analyse is de betrokkenheid van het management dus onontbeerlijk. Deze moet echter ook weer niet zo groot zijn dat er over schattingen wordt onderhandeld. Een schatting die op een dergelijke manier tot stand is gekomen heeft alleen politieke doelstellingen, als gereedschap voor de projectleider is zij dan waardeloos geworden. Hierbij moeten we opmerken dat het produceren van realistische schattingen haaks staat op het verschijnsel dat schattingen politiek worden gekleurd. Soms worden begrotingen expres te laag ingeschat om een ‘go’-beslissing te forceren. De achterliggende gedachte is dat een organisatie gemakkelijker bijvoorbeeld twee ton uitgeeft om het verlies van één ton te voorkomen, dan dat ze meteen drie ton op tafel legt. De consequentie is dat men dergelijke schattingen altijd moet laten uitvoeren door een onafhankelijke derde partij.

Benodigde tijd plannen

Plan: to bother about the best method of accomplishing an accidental result – Ambrose Bierce

Een efficiënte projectmanagement-methode stelt de taakvolgorde op een zodanige wijze vast dat een net goedgekeurd product zo min mogelijk veranderingen in reeds realiseerde producten tot gevolg heeft.

Daarvoor moeten producten met een hoog abstractie-niveau het eerst worden opgeleverd zodat het onderhoud aan de op te leveren systeembeschrijving wordt geminimaliseerd. In de regel realiseert men systemen daarom top down. Globaal gezien is eerst het beschrijven van de systeemeisen aan de orde en vervolgens de functionele systeembeschrijving, waaruit dan de technische systeembeschrijving en de programma’s worden gemaakt.

Om de voor een project benodigde tijd te plannen, stelt men eerst een lijst met gewenste producten vast. Vervolgens schat de planner de benodigde tijd om deze individuele producten te realiseren. Daarna volgt, door het toepassen van netwerkplanning, het plaatsen van deze processen in de gewenste volgorde en afhankelijkheid. Om de totale doorlooptijd van het gehele project te bepalen, rekent men via CPM (Critical Path Method) deze tijdsduren lineair door. Als de aanwezige capaciteit minder is dan deze optimale oplossing vergt, zal het nodig zijn de uitkomst daarvan aan te passen. Uitkomst is de kortste doorlooptijd waarin de capaciteit zo efficiënt mogelijk wordt benut.

Hierbij wordt echter geen rekening gehouden met vertragingen die tijdens een project kunnen voorkomen. Omdat de dure capaciteit zo optimaal mogelijk moet worden gepland, loopt een project door vertragingen bijna altijd uit. Sommige planners zeggen: ‘Men moet zo’n planning maken om te weten wanneer men ervan afwijkt’. Een dergelijke planning is echter altijd een ‘best case’ situatie, die pas later in het traject beter overeen zal komen met de werkelijkheid.

De lengte van verstoringen

Bij het projectmatig realiseren van een informatiesysteem kunnen een aantal problemen optreden. Besproken zijn reeds de moeilijkheden bij het vaststellen van de gewenste functionaliteit. Tevens is er een niet optimale communicatie tussen gebruiker en ontwikkelaar mogelijk door de kloof in taalgebruik. Bovendien is het nadenken over de functionaliteit van het systeem voor de gebruiker een bewustwordingsproces. Als deze onvoldoende bij de ontwikkeling wordt betrokken, zal de gewenste functionaliteit dus later of helemaal niet bekend worden. Methoden als SDM (System Development Methodoly) bieden een raamwerk waarbij de projectmanager in principe vrij is bepaalde taken/producten binnen zijn project te laten vallen. Als hij irrelevante producten schrapt, kan dit echter de consistentie van werken geweld aandoen door een niet optimale productvolgorde. Als later op te leveren producten afhankelijk zijn van een geschrapt product, dan kan een functionele ‘mismatch’ pas later worden ontdekt.

Tijdens de ontwikkeling van een informatiesysteem kunnen verstoringen in meerdere of mindere mate voorkomen. Het effect van storingen verschilt echter. Dit maakt het noodzakelijk verstoringen die een vertraging veroorzaken met een constante duur te onderscheiden van verstoringen die een vertraging teweegbrengen met een duur die afhankelijk is van de mate waarin het project gevorderd is. Voorbeelden van verstoringen met een constante vertraging zijn: een verkeerde inschatting van de complexiteit van taken; het uitvoeren van taken door mensen (het ‘90%-gereed’ syndroom); het overplaatsing van personen, wat inwerktijd voor nieuw personeel tot gevolg heeft; de onverwachte afwezigheid van betrokken personen; en het veranderen van de prioriteit van projecttaken. Voorbeelden van verstoringen met een variabele duur zijn: een verkeerde inschatting van de complexiteit van het project; fouten in de producten die niet onmiddellijk worden hersteld; het wijzigen van de hard-/software standaard of meta-gegevens; wijzigingen in gekoppelde informatiesystemen; en onvoorziene reorganisaties.

Evenals het schatten van de lengte van een taak is de lengte van de verstoringen een functie van de omvang en complexiteit van een systeem. Voor het bepalen van de totale vertraging als gevolg van voorgekomen verstoringen kan een beroep doen op de statistiek. Het gebruik van statistische methoden bij de ontwikkeling van software minder voor de hand te liggen. Statistiek wordt echter al gebruikt om in de testfase te bepalen hoe lang men nog moet testen bij een gevonden aantal fouten.

De Poisson-methodiek

Als een paar aannames wordt gedaan, bestaat de mogelijkheid ruwweg te berekenen hoe sterk de invloed van verstoringen kan zijn. De aanname luidt dat de duur van de verstoringen normaal verdeeld is (zie figuur 1). Vereenvoudigd kan er dan worden gerekend met een gemiddelde duur van de verstoring (de meridiaan van de normale verdeling). Een normale verdeling betekent dat het ook zo kan zijn dat een verstoring een negatieve invloed op de duur van het project heeft, bijvoorbeeld als men functionaliteit schrapt. Dit zal waarschijnlijk niet vaak voorkomen.

Een verdere aanname is dat het voorkomen van verstoringen ‘Poisson’ verdeeld is. Dit betekent dat het aantal verstoringen lineair toeneemt met de lengte van het project. Het houdt echter wel in dat, naarmate een project langer duurt, de waarschijnlijke duur beter te voorspellen zal zijn – dit in tegenstelling tot conventionele planningsmethoden. Bij een groot aantal verstoringen zal de Poisson-frequentie namelijk beter overeenkomen met een theoretische voorspelling.

Bekend uit de literatuur is het feit dat de kosten voor het herstellen van fouten in software exponentieel toenemen met de tijd. Dit is onder andere te verklaren doordat een fout in een systeembeschrijving kan teruggrijpen op meerdere producten. De verstoringen waarbij de lengte constant is, zullen accumulerend verantwoordelijk zijn voor een lineaire toename van de duur van een project. De verstoringen met een variabele lengte zullen opgeteld waarschijnlijk een exponentiële stijging van de lengte van het project tot gevolg hebben.

Het volgende rekenvoorbeeld is sterk vereenvoudigd door aan te nemen dat er slechts twee typen verstoringen zijn, één met een constante, en één met een variabele lengte. Uitgangspunt hierbij vormt een initiële schatting van de projectduur die op een conventionele manier tot stand is gekomen. Men kan deze initieel geschatte duur van een project (x) dan omrekenen naar de waarschijnlijke duur met de formule:

Waarschijnlijke duur = A.x + exp(B.x + C) – exp(C); { x ≥ 0 }

Hierbij is de factor (A – 1) het effect van constante verstoringen en de component exp(B.x) het gevolg van verstoringen met een variabele lengte.

Uitgangspunt is het standaardproject van Capers Jones zoals genoemd in de inleiding met een lengte van 1 jaar en een overschrijding van 100%. Vervolgens wordt de formule (met C = 0) in een grafiek weergegeven waarin op de horizontale as de initieel geplande duur van het project staat, tegenover de waarschijnlijke duur op de verticale as (zie figuur 2).

Uit deze grafiek blijkt dat verstoringen een dramatische invloed kunnen hebben op de waarschijnlijke duur van een project. Bij een project met een initieel geplande duur van drie jaar zal in dit voorbeeld de waarschijnlijke duur tussen zes en tien jaar bedragen. Als men vooraf constateert dat het aandeel van de constante verstoringen 30% van de initieel geplande duur bedraagt, dan is de waarschijnlijke duur acht jaar.

Geen enkel project zal zich geheel aan de invloed van verstoringen kunnen onttrekken. Wanneer een project in tijdnood komt door een harde deadline, kan het testen minder aandacht krijgen dan nodig is. Hierdoor zal het systeem dan in het algemeen niet meer kunnen voldoen aan de gestelde kwaliteitseisen. Dit betekent dat in feite het probleem verschuift naar de fase Beheer, waar de exploitatiekosten door de verminderde onderhoudbaarheid waarschijnlijk de schatting fors zullen overschrijden. Het alternatief, het systeem te laat opleveren, kan ongewenste (contractuele) consequenties hebben.

Uit het rekenvoorbeeld blijkt dat lange projecten gemiddeld verder uitlopen dan korte projecten. Hierdoor kan een project falen omdat het systeem niet meer voldoet aan de op dat moment gewenste functionaliteit. De tevredenheid van gebruikers is namelijk afhankelijk van hetgeen gewenst is op het moment van oplevering. Bovendien kan de informatiebehoefte van een gebruiker naar een hoger plan verschuiven als de behoeften op lager niveau zijn vervuld. Projectmanagers proberen de planning te handhaven door toepassing van feed-forward of feed-back besturingsmaatregelen. In het algemeen kan worden gesteld dat feed-forward besturing sneller en efficiënter is, maar feed-back besturing valt effectiever in te zetten.

De meest algemene vorm van feed-forward besturing is het produceren van realistische schattingen. Nodig hiervoor is onder andere het berekenen van de productiviteit per persoon per jaar. In deze berekening neemt men een aantal type constante verstoringen op zoals gemiddeld ziekteverzuim. Omdat de ontwikkeling en invoering van informatiesystemen tegenwoordig riskanter is, wordt er een groter beroep gedaan op de kennis, motivatie en vaardigheden van de projectmedewerkers. Het investeren in kwaliteit werkt daarom positief omdat dan minder fouten worden gemaakt. Zoals gezegd voert het toepassen van softwaretools en vierde generatie talen de productiviteit van de systeemontwikkelaars op. Daarbij zullen het toepassen van een goede systeemontwikkelmethode en het voorschrijven van een documentstandaard eveneens effect sorteren.

Het gebruik van prototyping om de functionele specificaties te achterhalen lijkt veelbelovend, maar met introductie hiervan moet men rekening houden met de vereiste deskundigheid van de betrokken systeemontwikkelaars. De projectorganisatie moet bovendien afgestemd zijn op het veranderde realisatietraject. Het kan bijvoorbeeld moeilijk zijn het moment te bepalen wanneer men moet stoppen met prototyping om met de bouw van het eigenlijke systeem te beginnen.

Door toepassen van object-georiënteerde talen (OO) kan, door hergebruik van objecten, de productiviteit van de systeemontwikkeling worden opgevoerd. Efficiënt gebruik van bibliotheekroutines en objecten vereist wel een bepaalde standaardisatie.

Het stabiliseren van de interne organisatie zorgt ervoor dat de omgeving waarin het informatiesysteem moet integreren na oplevering weinig verandert. Dit betekent dat de functionele specificaties van het opgeleverde systeem waarschijnlijk beter overeenkomen met de eerder door de gebruikers gewenste functionaliteit. Onvoorziene reorganisaties tijdens of na het ontwikkeltraject moeten derhalve worden vermeden.

Afhankelijk van de situatie

Streven naar minder functionaliteit en dus kleinere projecten zorgt ervoor dat de gebruikers na korte tijd het systeem krijgen opgeleverd. Tevens kan men de ontwikkelcapaciteit spreiden, waardoor het mogelijk is aan meer projecten capaciteit toe te kennen. Enkele voordelen van kleine(re) projecten zijn: minder uitloop door kortere tijdsduur en daardoor een hogere slagingskans; de mogelijkheid tot betere spreiding van ontwikkel-capaciteit; prototyping werking bij latere projecten; snellere aansluiting op de behoefte van de gebruikers; en een minder omvangrijk project is flexibeler tussentijds aan te passen.

Nadelen van kleine(re) projecten zijn: vooraf ontevredenheid van de gebruiker door verminderde functionaliteit; afstemmingsverlies door niet-integrale aanpak; een kleine omvang is niet altijd toepasbaar, bijvoorbeeld bij het integraal vervangen van grote systemen; en een prioriteitstelling bij het vaststellen van de informatie-behoefte is noodzakelijk.

Het kan gunstig zijn niet geheel aan de informatiebehoefte van van de gebruiker te voldoen als het daardoor mogelijk is gebruik te te maken van een standaardpakket. Doel van deze afweging is het snel en daardoor goedkoop ontwikkelen van systemen die de gebruiker toch voldoende ondersteunen.

Voorbeelden van feed-back besturing zijn het bijstellen van de planning en het inzetten van extra personeel. Deze laatste oplossing is echter gebonden aan de wet van Brook: het inzetten van extra personeel zal een project nog meer vertragen. Het is dan beter de leden van het projectteam te laten overwerken dan extra mensen toe te voegen. Wanneer de werkdruk echter zodanig hoog wordt dat het aantal fouten sterk stijgt, is uitloop van een project onvermijdelijk. Soms kan men ook een project versnellen door mensen uit het projectteam te halen.

Voorts is het belangrijk lering te trekken uit de fouten uit het verleden. Om te voorkomen dat automatiseringsbedrijven verantwoordelijk worden gesteld voor fouten tijdens een project, probeert men soms de gebruiker aansprakelijk te stellen, waarna de zaak geruisloos in de doofpot kan verdwijnen. De synthese tussen gebruiker en ontwikkelaar zal in deze sfeer niet optimaal zijn.

In hoeverre verstoringen voorkomen, is afhankelijk van de situatie. Door onder meer een strakke leiding is het optreden van verstoringen wel te beïnvloeden. Er zijn echter factoren die zich moeilijk laten controleren. Een minder snelle technologische vooruitgang nl. zou (paradoxaal genoeg) ook een verkorting van de projectduur kunnen veroorzaken door de stabiliserende werking. Dit houdt in dat het achteraf berekenen van de uitloop van het project niet rechtstreeks te gebruiken is voor de beoordeling van de projectmanager.

Gebruik statistische methode

Om een aantal redenen hebben projecten de neiging hebben steeds complexer te worden. De complexiteit en daardoor de projectlengte zijn factoren die de haalbaarheid van een project het meest beïnvloeden.

Projecten begroten met behulp van conventionele planningsmethoden kent een aantal moeilijkheden. Niet alle verstoringen zijn te voorzien in een planning. Hoewel niet als harde wetmatigheid, kan worden gesteld dat het halen van een planning die op conventionele wijze is gemaakt waarschijnlijk heeft geleid tot een hogere inspanning en/of een lagere kwaliteit dan voorzien.

Het effect van verstoringen op de duur van een project kan zeer groot zijn. Het is dan ook aan te bevelen om bij (middel)grote projecten, naast conventionele planningsmethoden, een statistische methode te gebruiken die een uitspraak kan doen over de waarschijnlijke lengte van deze projecten. Sturing moet echter nog steeds plaatsvinden op basis van de conventionele planning.

Een dergelijke methode toepassen zal echter nog (veel) onderzoek vergen, dat zich moet richten op historische projectdocumentatie. Hieruit is dan bijvoorbeeld de Poisson-frequentie en de gemiddelde lengte van de voorgekomen verstoringen te bepalen.

Daarnaast kunnen de gebruikte projectgegevens kunnen sterk gebonden zijn aan de betrokken organisatie. Er bestaat bijvoorbeeld een sterke afhankelijkheid met de planningsmethode die wordt gebruikt om de initiële schatting te maken. Derhalve is het nodig aanvullend onderzoek te doen naar situationele factoren die projectschattingen in dit verband kunnen beïnvloeden.