Onduidelijke doelstellingen, gebrekkige communicatie tussen ontwikkelaar en gebruiker, veranderende wensen van gebruikers en onderschatting van de complexiteit zijn er vaak debet aan dat ICT-projecten mislukken of te laat af zijn. En dan zijn met het ontwikkelen en beheren ook steeds grotere bedragen gemoeid. Andere oorzaken: onvoldoende samenwerking en betrokkenheid, ondersteuning en sturing. Weet men echter voldoende valkuilen te ontwijken, dan neemt de kans op succes aanzienlijk toe, meent een consultant. Bovendien reikt hij enkele handvatten voor projectevaluatie aan.
Een mislukt project veroorzaakt materiële schade: de onderneming blijft bijvoorbeeld zitten met onbruikbare hard- en software. Daarnaast kan ook immateriële schade ontstaan doordat een goede naam beschadigd raakt of de werksfeer wordt aangetast. Het is echter geen sinecure om te achterhalen waarom een project crashte als politieke agenda’s en vooroordelen regeren. Ook kan een toetsing worden gehinderd door ‘rectificaties’ achteraf en intussen vertrokken medewerkers. Veel organisaties evalueren hun projecten maar mondjesmaat. Toch wegen de nadelen niet op tegen de voordelen. Bedrijven die consequent hun projecten evalueren blijken veel minder last van budgetoverschrijdingen te hebben. Bij een klein project kan de scope van het onderzoek worden beperkt. Met een kort onderzoek komen natuurlijk niet alle aspecten en criteria aan bod. Als een project echter 80 procent van de bekende valkuilen kan ontwijken, vergroot dit de kans op succes aanzienlijk.
Men kan op verschillende tijdstippen en niveaus onderzoeken of projecten effectief worden gestuurd. Een opsomming van een aantal handvatten voor een projectevaluatie, zowel vooraf als achteraf: wanneer moet men waarop letten. En een aantal criteria op een rij om een verantwoorde en beheerste uitvoering van een ICT-project mogelijk te maken.
Zo kan het bestuur van een organisatie met dit gereedschap de organisatorische omgeving en opzet van projecten toetsen. Vervolgens worden die beleidsdocumenten onderzocht die een kader vormen voor ICT-projecten. Daarnaast kan de stuurgroep of projectleiding laten beoordelen of het project intern effectief wordt gestuurd. Het onderzoek beperkt zich dan tot stuurdocumenten en aanvullende interviews binnen het project.
Als een softwarefout later wordt geconstateerd, nemen de herstelkosten nu eenmaal sterk toe. En als een ICT-project al vanaf de start onvoldoende sturing geniet, wordt het eveneens moeilijker een goed eindresultaat te bereiken. De kans bestaat zelfs dat het project niet meer beheersbaar is en voortijdig gestaakt moet worden. Begin daarom zo vroeg mogelijk in een project met kwaliteitsonderzoeken.
Normen en informatie
Om een systeem effectief te besturen dient het doel bekend en realiseerbaar te zijn. Daarnaast moet de leiding beschikken over voldoende stuurmaatregelen en moet het effect van deze maatregelen op het systeem bekend zijn. Ten slotte zijn normen en informatie nodig om te bepalen wanneer en hoe bijgestuurd moet worden. Informatie wordt ingedeeld in ‘feed forward’ of voorwaartse koppeling en ‘feed back’ of terugkoppeling. Voorwaartse koppeling is gebaseerd op voorspellingen en dus efficiënt, omdat sturen mogelijk is voordat resultaten bekend zijn. Terugkoppeling is echter effectiever omdat gestuurd wordt op basis van feiten. Naast voorwaartse koppeling is terugkoppeling nodig om fouten in voorspellingen niet te herhalen.
Meestal wordt een project gestuurd op tijd, geld, kwaliteit, organisatie en informatie. Een project verloopt beheerst als het eindproduct voldoet aan de afgesproken kwaliteitseisen, op tijd wordt overgedragen en binnen het budget blijft. Daarbij moeten projectleden altijd over de gewenste informatie kunnen beschikken en maakt de projectorganisatie effectief werken mogelijk. Hiervoor moeten op elk niveau alle beheersaspecten worden bewaakt, zowel met voorwaartse informatie als met terugkoppeling. Dit is te controleren door alle stuurproducten op te nemen in een schema conform de tabel ‘Stuurproducten’.
Veel ICT-projecten falen als de beleidsmatige aansturing blijft steken in het eerste stadium van automatisering (John Thorpe – The Information Paradox, McGraw-Hill, 1998). In dat stadium beperkt de projectsturing zich tot ‘de stekker moet in het stopcontact’, de winst volgt dan vanzelf. Inmiddels zijn veel bedrijven via ‘Information’ aangeland in het ‘Business Transformation’ stadium. Informatie bezit dan strategische waarde en heeft grote invloed op de inrichting en aansturing van bedrijfsprocessen. Naast beheersing van ICT-middelen moet het strategische niveau baten laten realiseren voor de organisatie. Deze projectbaten moeten zodanig vastgelegd zijn dat men later objectief kan nagaan of ze zijn gerealiseerd. Bijvoorbeeld: een geschat kostenverschil tussen de oude en de nieuwe situatie kan achteraf eenvoudig worden geverifieerd.
Projectomgeving
Het ICT-beleid bepaalt het wat en hoe van projecten, gerelateerd aan de organisatiestrategie en externe invloeden. Het wat komt meestal terug in een projectplan waarin de projectdoelen en het budget worden vastgelegd. Het gaat fout als het beleidsniveau projecten opzadelt met onduidelijke of onsamenhangende doelen. Als het projectbudget te krap blijkt, moeten er tijdens het project extra middelen komen of de omvang en kwaliteit van het eindproduct zal verminderen.
De meeste ICT-projecten worden onderweg groter en complexer. Men kan daarom beter 75 procent van de essentiële functionaliteit op tijd realiseren dan een 100 procent oplossing later opleveren. Honoreer alle gebruikerswensen en uw project eindigt te laat. ‘Beter’ is hier de vijand van ‘goed genoeg’. Door de projectomvang te beperken tot maximaal anderhalf jaar, vermindert de complexiteit en verbetert de beheersing. Dit leidt echter tot meer projecten en relaties daartussen. Het is dan de kunst afhankelijkheden tussen projecten te minimaliseren.
Grote organisaties besteden gemiddeld 70 procent van het totale ICT-budget aan onderhoud. Kosten, baten en risico’s moeten daarom zowel tijdens de project- als de beheersfase worden onderzocht. Deze analyse vormt het uitgangspunt voor de prioriteitsstelling, doelstelling en de toewijzing van middelen voor een project.
Beleidsdocumenten die het hoe beschrijven gelden als kwaliteitsnormen voor de inrichting en beheer van de informatievoorziening. Vaak wordt dit ingevuld met procesbeschrijvingen en templates van documenten. Hierbij is een groeipad mogelijk met Itil, ISO of CMM voor ogen. Een flexibele wijze van systeemontwikkeling bijvoorbeeld, kan in de praktijk worden ervaren als een keurslijf. Beoordeel daarom het nut van ICT-beleid aan de hand van de problemen en behoeften binnen de organisatie.
Voor de bewaking van projecten wordt meestal een stuurgroep opgericht die de eindverantwoordelijk draagt voor het realiseren van het projectdoel. De stuurgroep kan het project alleen effectief sturen met de juiste gegevens van alle beheersaspecten. Dit kan bijvoorbeeld door deze gegevens op te nemen zowel in het plan van aanpak als in voortgangsrapportages en detailplanningen van volgende fases. Concentreer de besluitvorming daarnaast op de kwaliteit van de mijlpaalproducten op de afgesproken tijdstippen. Te vaak worden projecten op ad-hoc basis bestuurd.
Plan van aanpak
Uit de projectopdracht van de Stuurgroep met de doelstelling, tijd, middelen, kwaliteit, randvoorwaarden enzovoort, wordt het plan van aanpak afgeleid. De Stuurgroep moet dit plan van aanpak goedkeuren. Het plan moet tenminste bevatten: een risicoanalyse, een beschrijving van de projectorganisatie, een plan voor de communicatie met de organisatie, een tijdplan voor het realiseren van de producten en de toegepaste kwaliteitsborging.
Om de risico’s te bepalen dient men eerst te analyseren waar het project (in)direct van afhankelijk is. Bepaal van alle relevante objecten de kans op problemen en de gevolgen daarvan in tijd en geld voor het project. Het risico wordt vervolgens berekend door de kans op een probleem te vermenigvuldigen met de vervolgschade. Laat meerdere onafhankelijke en ervaren mensen de risico’s schatten en betrek gegevens uit oude risicoanalyses, projectschattingen en evaluaties.
Allereerst is een ICT-project voor de uitvoering grotendeels afhankelijk van de techniek. Onderzoek systeeminterfaces afzonderlijk, omdat ze onverwacht kunnen wijzigen bij onderhoud van een ander systeem. Binnen de organisatie zijn mogelijk ook afdelingen, processen en locaties onderling sterk afhankelijk. Verder kunnen relaties tussen leveranciers, afnemers en partners een project beïnvloeden. Daarnaast heeft een projectleider teamleden nodig met voldoende kennis, ervaring en betrokkenheid om het projectdoel conform tijdplan en normen te realiseren. Dit geldt nog sterker voor sturende en controlerende taken.
Een risicoanalyse bevat bovendien maatregelen om risico’s te verminderen. Zo moeten de projectorganisatie, werkwijze en informatiestromen afgeleid zijn van de risicoanalyse. Breng een direct verband aan tussen de omvang van de maatregelen en de hoogte van het risico. Als essentiële mensen of middelen niet beschikbaar zijn, reserveer dan extra tijd, zorg voor een back-up of pas de kwaliteitsnormen aan. Als de beschikbare personele capaciteit onduidelijk is, bewaak dit dan met een capaciteitsplanning vooraf en urenregistratie achteraf. Een gecontroleerde in- en uitstroom van personeel houdt het projectteam effectief. Als daarna de restsom van alle risico’s bijvoorbeeld 50.000 gulden of drie maanden uitloop bedraagt, plan dan een even grote reservepost.
Het eindproduct van elk project is uniek en daarmee meestal ook de aanpak. Het plan van aanpak dient de producten te beschrijven en een gefaseerde realisatievolgorde. Meestal wordt een selectie gemaakt uit een opsomming van alle stuur- en systeemproducten. De keuze voor een product is een afweging van de kosten of doorlooptijd ten opzichte van de toegevoegde waarde. Als producten worden geschrapt, kunnen echter fouten optreden in gerelateerde producten. De productkeuze moet derhalve in het plan van aanpak worden onderbouwd.
De kans op succes van het project wordt vergroot door overeenstemming te bereiken over de systeemfunctionaliteit, de prioriteitstelling en de normen. Toekomstige gebruikers vroegtijdig en intensief bij het project betrekken is daarvoor essentieel. Dit kan met behulp van een incrementele ontwikkelmethode, waarbij het gewenste systeem in een aantal versies wordt ontwikkeld. Bij voorkeur vindt terugkoppeling met gebruikers plaats met gebruiksklare systeemdelen, niet met stapels papier. Bij ICT-projecten zijn het meestal de gebruikers die de functionele eisen en wensen definiëren, het ontwerp beoordelen en acceptatietesten uitvoeren. Materiedeskundigen kunnen echter ook helpteksten, handleidingen en werkprocedures produceren, nieuwe gebruikers opleiden en projecten evalueren – bekeken door de ogen van de gebruiker.
Planning en beheersing
Per product moet de benodigde capaciteit voor het ontwikkelen en testen zijn gepland. Reserveer circa 50 procent van de totale tijdsinspanning voor reviews, testen en herstelwerk. De betrouwbaarheid van een planning verbetert als bij het opstellen ervan ervaringscijfers en statistische modellen zijn gebruikt. Het plan van aanpak zal tevens moeten specificeren hoe projecten worden gecoördineerd. De planning moet dan de geschatte levertijd van het projectresultaat weergeven door de doorlooptijden van alle producten en gerelateerde projecten samen te vatten.
Het projectresultaat moet gecontroleerd worden met de vooraf vastgestelde eisen en wensen van de gebruikers. Deze kwaliteitseisen moeten ondubbelzinnig zijn. Een eis als ‘optimale gebruiksvriendelijkheid’ is bijvoorbeeld subjectief, terwijl ‘de gebruikersdocumentatie dient alle schermen te verduidelijken’ wel objectief controleerbaar is. Leg daarnaast een uniforme testprocedure vast, dit voorkomt dat elke tester controleert op zijn eigen manier. Als de kwaliteit van een product onduidelijk is, moet de test namelijk herhaald worden. Naast testen van componenten, is een integratietest noodzakelijk omdat sommige problemen pas optreden bij koppeling van systemen. De testomgeving moet daarom zoveel mogelijk lijken op de normale gebruikssituatie.
Bij de aftrap worden projectdoelen uitgesplitst in formele taken, relaties, bevoegdheden en verantwoordelijkheden. Bevoegdheden en verantwoordelijkheden moeten voldoen aan de controletechnische functiescheiding. Dit houdt in dat normstelling, uitvoering en controle bij verschillende personen moeten liggen. Een ontwikkelaar mag bijvoorbeeld niet zijn eigen producten formeel goedkeuren. Op vooraf geplande momenten moet een onafhankelijk kwaliteitsinspecteur de kwaliteit van producten beoordelen en de ontwikkelaars, projectleider en Stuurgroep daarover informeren.
ICT-projecten zijn vaak complex door de grote hoeveelheid versies van stuur- en systeemproducten. Om dubbel werk te voorkomen is er een configuratiemanager (CM) nodig die de status van alle productversies bijhoudt. Een CM identificeert, archiveert en verstrekt productversies met een vastgestelde status en rapporteert daarover. Daarnaast is er een procedure nodig om de status van een product te wijzigen. Van elke productversie moet duidelijk zijn wat de status is, wie eigenaar is en welke wijzigingen er ten opzichte van de vorige versie zijn doorgevoerd.
Registratie en archivering moeten controle van het project mogelijk maken. Daarvoor dient onafhankelijk personeel betrokken te zijn bij de administratie van projectinformatie. Dit geld met name voor de besturingsaspecten tijd, geld en kwaliteit. Het plan van aanpak dient de overlegstructuur voor het project te definiëren en welke registraties nodig zijn voor de rapportages. Leg per overleg het doel vast, de functie van de leden en de vergaderfrequentie. Zo moet bijvoorbeeld uit de verslagen blijken wie, wanneer, welke versies van producten hebben goedgekeurd. Documenteer altijd wie besloten heeft de planning of de kwaliteitsnormen aan te passen, de inhoudelijke wijziging en de redenen daarvoor. Dit geldt ook voor het aanspreken van reserves. Verder is het een goede gewoonte een logboek aan te leggen met gebeurtenissen en reacties.
Bij rapportages wordt meestal gekozen voor het principe ‘management by exception‘. Hierbij escaleren alleen gegevens als ze zodanig afwijken van de randvoorwaarden dat het hogere management daarop moet reageren. Normen en randvoorwaarden moeten echter een zekere speelruimte bieden. Als het projectteam de meeste problemen zelf niet kan oplossen, verstopt de besluitvorming. Let erop dat een managementrapportage uitsluitend gegevens bevat die zijn ontstaan op dat niveau of zijn vastgelegd in lagere registraties.
Draagvlak
Bepaal daarnaast binnen de projectorganisatie wie wanneer welke informatie moet krijgen, zowel qua vorm als inhoud. Controleer vanaf het begin of de afgesproken werkwijze voor alle projectleden duidelijk is. Verder verdienen de informele samenwerking, teambuilding en sociale vaardigheden ook aandacht. Gebruikers en ontwikkelaars die bijvoorbeeld onvoldoende samenwerken, kunnen een goed plan in de praktijk volledig laten mislukken. Als de cultuur binnen een organisatie niet resultaatgericht is, worden projectverantwoordelijkheden mogelijk onvoldoende ingevuld.
Omdat het projectresultaat invloed heeft op processen, moeten alle betrokkenen worden geïnformeerd. Communicatie is cruciaal voor de steun die het project vanuit de organisatie nodig heeft. Kwaliteit kan worden omschreven als ’tegemoetkomen aan gewekte verwachtingen’. Door de informatieverstrekking vanuit de projectorganisatie te plannen zijn problemen te voorkomen. Een communicatieplan bevat minimaal een lijst met doelstellingen, de aanpak, taken, verantwoordelijkheden en de geplande inzet van middelen. Gebruik meerdere communicatiemiddelen zoals een website, mailings, folders en persoonlijke contacten, afhankelijk van de organisatiecultuur. Men kan het personeel betrekken door een proeftuin in te richten en met een controlegroep de effectiviteit van de communicatie testen. Bij grote projecten kan het zinvol zijn een communicatiedeskundige in te zetten.
Nadat een project is afgesloten, zijn met een nacalculatie de gerealiseerde kosten en baten vast te stellen. Hiermee kunnen project- en informatieplan worden bijgewerkt. De analyse van verschillen tussen planning en realisatie levert ervaring op die gebruikt kan worden bij volgende projectschattingen. Zo is na het functioneel ontwerp met een techniek als de FunctiePunt Analyse (FPA) de benodigde tijd te schatten om de programmatuur te realiseren. Voor een betrouwbare schatting moet uit ervaringscijfers worden bepaald hoeveel uur werk één functiepunt oplevert. Naast het gemiddelde is ook de standaardafwijking nodig om de marge in de schatting te bepalen. Een grote marge duidt bovendien op een slechte beheersing.
Naast de productkwaliteit kan een evaluatie ook de kwaliteit van de aanpak toetsen. Zo kunnen methodes, technieken, tools en projectmanagement worden verbeterd. Daarnaast zijn met een evaluatie de behaalde successen te identificeren en is het functioneren van betrokkenen te beoordelen. Analyseer of afwijkingen op de planning veroorzaakt werden door externe wijzigingen op uitgangspunten, doelstellingen of eisen of dat er bijvoorbeeld onvoldoende expertise aanwezig was.
Een projectevaluatie is effectiever als zij structureel deel uitmaakt van een standaard werkwijze. Alleen door standaardisatie kan efficiënt ervaring worden opgebouwd. Er bestaan veel projectmanagementmethodes waarbij proces- en productstandaarden goed op elkaar afgestemd zijn. Een goede methode bevat een beschrijving van kernprocessen als planning en management van scope, wijzigingen, tijd en kosten. Tevens worden ondersteunende processen toegelicht, zoals het managen van risico’s, kwaliteit, resources, communicatie en aanschaf. Documenttemplates kunnen de efficiency verder verhogen.
Onderzoekspsychologie
Tot slot de psychologie van het onderzoek zelf. Stel een onderzoeksteam samen met zowel interne als externe leden. Externen leveren ontbrekende expertise en een ‘frisse blik’, intern personeel biedt contextuele informatie en vereenvoudigt de acceptatie van de onderzoeksresultaten. Bepaal echter vooraf wanneer een organisatie bereid is van haar fouten te leren. Zo roepen veel hondenbezitters hun hond pas bij zich om hem te bestraffen als hij iets verkeerds gedaan heeft. Op den duur komt de hond niet meer als zijn baas hem roept. Dat is hem dan wel afgeleerd.
H.J.K.W. van der Molen,
IT-consultant
DMR Consulting Group
Niveau, eigenaar | Naam stuurproduct | Type | Omschrijving | Stuuraspect | ||||
T | G | K | O | I | ||||
Strategisch ICT-beleid, | ||||||||
Management | Onderhoudsstrategie | FF | Wie onderhoudt hoe strategische applicaties | O | O | |||
Projectplan | FF | doelen, budgetten voor ontwikkeling en onderhoud | O | O | O | O | ||
Meta-objectgegevens | FF | Standaards voor gegevens- en procesmodel | O | |||||
Beveiligingsplan | FF | Risico’s en maatregelen voor beveiliging | O | O | O | |||
ICT-standaarden | FF | voor aanschaf hard- en software | O | O | ||||
Ontwikkelstandaard | FF | Wat en hoe ontwikkelen (proces, normen, templates) | O | O | O | |||
Projectevaluatie | FB | Beoordeling van producten en processen | O | O | O | O | O | |
Tactisch, | ||||||||
Stuurgroep | Projectopdracht | FF | Per project gedetailleerd, toewijzing projectleider | O | O | O | O | |
PVA-Risicoanalyse | FF | Projectrisico’s en tegenmaatregelen | O | O | O | O | ||
PVA-Functionele eisen | FF | Eisen, uitgangspunten en randvoorwaarden | O | |||||
PVA-Communicatieplan | FF | Taken en inzet communicatiemiddelen | O | O | ||||
PVA-Tijdsplanning | FF/FB | Wie, wat, wanneer, hoeveel gepland/gerealiseerd | O | O | O | |||
PVA-Projectorganisatie | FF | Taken, verantwoordelijkheden en werkrelaties | O | O | ||||
PVA-Kwaliteitsplan | FF | Hoe is de productkwaliteit gegarandeerd | O | O | O | |||
Auditrapport | FB | Kwaliteit van productversie of processen | O | O | O | |||
Operationeel, | ||||||||
Projectleider | Urenregistratie | FB | Bestede t.o.v. geplande uren aan een product | O | O | |||
Besluitenlijst | FF | B.v. functionele (K) en organisatorische (O) besluiten | O | O | O | O | O | |
Voortgangsrapportage | FB | Afwijkingen op planning, normen en risicoanalyse | O | O | O | O | O | |
Aanpak volgende fase | FF | Aanvulling, afwijkingen op het algemene PvA | O | O | O | O | O |
Voorbeelden van stuurproducten van ICT-projecten. Legenda: FF, FB = Feed Forward, Feed Back informatie; T, G, K, O, I = Tijd, Geld, Kwaliteit, Organisatie, Informatie.