Bij unieke projecten zijn evaluaties zinloos
En een project is al snel uniek
Binnen de gangbare projectmanagement theorien (zoals IPMA en PRINCE2) is de evaluatie één van de onderdelen van een project. De evaluatie is het sluitstuk van een project waarmee lering wordt getrokken voor volgende projecten. De vraag is echter of evalueren een zinvolle bezigheid is? Een project kent veel unieke karakteristieken en vaak bepaalt de agenda van de deelnemers de insteek van een evaluatie en dus de uitkomst ervan. Voorafgaande aan elke evaluatie dient daarom eerst de volgende vraag met “ja” te worden beantwoord:
Wordt dit project binnen één jaar herhaald, waarbij drie van vijf GOKIT-thema’s gelijk blijven?
Als deze vraag met “nee” wordt beantwoord, kan men beter het uurtarief van alle deelnemers van de evaluatiebijeenkomst bij elkaar optellen en voor dat geld op de vrijdagmiddag-borrel een goede fles wijn open trekken en extra borrelhappen bestellen. Dit wordt vast gezelliger en levert waarschijnlijk nog meer op ook!
Valkuilen bij evaluaties
Bij het evalueren (van een project) bestaan de volgende valkuilen:
- (Enkele van) de deelnemers zijn meer bezig met het volgende project en evalueren plichtsmatig mee zonder aandacht. De evaluatie wordt dan ook niet goed voorbereid;
- De bekende straten worden schoongeveegd;
- De evaluatie dient niet ter lering voor de deelnemers, maar als instrument om zaken elders voor elkaar te krijgen (Budget voor afdelingen of voor toekomstige projecten; Het profileren van personen of afdelingen binnen de organisatie);
- Het is onduidelijk wie belang heeft bij een evaluatie en het gebeurt omdat “het moet” volgens de projectmanagement methode;
- De evaluatie wordt niet goed vastgelegd en/of gearchiveerd.
Maar als er goed geevalueerd wordt, alle deelnemers actief mee doen en er geen verborgen agenda’s zijn. Dan is de volgende vraag: Is de kennis die nu wordt vastgelegd bruikbaar voor volgende projecten? Ook dit blijkt in de praktijk vaak tegen te vallen…
GOKIT-thema’s
GOKIT (de afkorting voor Geld, Organisatie, Kwaliteit, Informatie en Tijd) geeft de vijf belangrijkste thema’s weer binnen projectmanagement. Hoewel “informatie” in deze context wellicht lastig is te duiden, veranderen de overige thema’s zichtbaar per project. De organisatie verandert, de scope wijzigt er is minder geld en meer tijd of juist andersom. Als drie van de vijf thema’s wijzigen, wijkt een project dermate af van de voorgaande projecten, waardoor uitgevoerde evaluaties hiervan eigenlijk onbruikbaar zijn geworden.
Zeker als de tijd verder voort schrijdt….
De vele variabelen, de kansen en de risico’s van een project veranderen als de periode tussen twee projecten groter wordt. De interne en externe politiek wijzigt, het projectteam wordt opnieuw samengesteld en de technische mogelijkheden nemen toe of af etc. etc. Na één jaar leven we in een andere wereld waardoor eerdere evaluaties de facto onbruikbaar zijn geworden. Daarom is evalueren ook zinloos als de verwachting is dat het project niet spoedig wordt herhaald.
De meeste mensen (zeker de moderne kenniswerkers) zijn meer geneigd om zelf zaken uit te zoeken dan een oude evaluatie – als deze al gevonden kan worden – af te stoffen en de kennis hieruit toe te passen. Zelf uitzoeken is leuker, men kan meer uren schrijven en daarnaast is het vaak onduidelijk welk deel van een evaluatie nog bruikbaar is en welk deel niet. Zeker als men de eerder genoemde valkuilen in het achterhoofd houdt.
Bij het lezen van een evaluatie blijft daarom altijd het gevoel bestaan dat deze niet meer bruikbaar is voor datgene wat nu gedaan moet worden.
Unieke projecten vragen om een unieke aanpak. De kennis die hiervoor nodig is, zit in de medewerkers van het goed samengesteld projectteam en is opgedaan tijdens andere projecten, niet uit andere evaluaties.
Deze column werd ingezonden door Steven Oosterling. Heeft u ook iets wat u bezig houdt? Plaats uw eigen column ›
Kennispartners
Annemieke Figee
Hugo Meijers
Joost van Rantwijk
Michel Lamtink
Leo Kerklaan
Carien Verhoeff
Lessons learned is als een bijbelboek voor de krijgsmacht. Evalueren is de volgende keer nog beter overleven.
Het boek Teams door het vuur geeft een vertaling van deze principes naar het bedrijfsleven.
Er is altijd een excuus om niet te evalueren. Er is nooit een excuus voor een gesneuvelde maat die gered had kunnen worden door een After Action Review.
Als het eindevaluaties betreft ben ik het grotendeels met je eens. Maar er is ook zoiets als tussentijdse evaluaties. Ook bij unieke projecten kunnen die een grote toegevoegde waarde hebben omdat ze tot verbetering van het project zelf kunnen leiden. Natuurlijk hangt het dan volledig af van de manier waarop die evaluatie wordt uitgevoerd. Belangrijkste is dat de deelnemers de ruimte krijgen hun bijdrage te leveren. En deze ook serieus meegenomen wordt…
@Rob,
Projecten in een private of publieke organisatie zijn geen (letterlijke) zaak van leven en dood. De vergelijking die je maakt met de krijgsmacht is een soortgelijke vergelijking als die topsport met het bedrijfsleven. Niet alle metaforen of vergelijkingen die in management thema’s worden toegepast zijn zonder meer bruikbaar.
@ J.A. Man.
Ik denk dat evaluaties altijd zinvol zijn voor de personen die eraan meedoen. De kijk van anderen op wat ze vinden van een project (proces en resultaat) levert voor mij regelmatig verassende inzichten op die ik goed kan gebruiken in een volgende project.
Vriendelijke groet,
Leon Dohmen
Nu is IPMA geen projectmanagement theorie, laat staan een methodiek als Prince2.
Daarnaast lijkt het artikel meer gericht op de Opdrachtgever van een project.
Dat laatste is een goede zaak. Goed Opdrachtgeverschap is aantoonbaar één van de grootste succesfactoren – en dús faalfactoren – van projecten.
Daarnaast is een goede business risk analyse, een sluitende business case, complete requirements en het nalezen van Lessons Learned uit eerdere projecten essentieel.
Elke Opdrachtgever zal stellen dat zijn of haar project uniek is. Maar uit de Lessons Learned zou zomaar kunnen blijken dat wat de Opdrachtgever voor ogen staat al eerder geprobeerd is, en mislukt.
Het niet starten of anders inrichten van zo’n project zou daardoor zomaar miljoenen kunnen besparen.
Dat staat toch een stuk beter in de media.
De grootste valkuil bij een evaluatie is deze uitsluitend op de projectinhoud te richten. Een evaluatieopzet gebaseerd op de beheersaspecten GOTIK alleen, miskent de complexiteit van menselijk gedrag dat zich in projecten openbaart.
Een goede evaluatie heeft niet alleen een eindrapport (met een feitenverzamelen en oordeel) tot doel, maar ook een stevig gesprek over het procesverloop van het project. Mijn ervaring is dat publieke opdrachtgevers in toenemende mate deze kritische gesprekken tijdens een projectevaluatie waarderen. Zolang het doel is om werkelijk te leren van het project in plaats van een (ongericht) oordeel over werkprocessen uit te spreken, blijft een evaluatie van onschatbare waarde. En dan is een rapport als eindproduct ook niet langer vanzelfsprekend, maar zijn andere methoden opeens voorhanden.
Tenslotte kan men het ook omdraaien: een project niet evalueren is eigenlijk een doodzonde: hoe weet de opdrachtgever dan welke projectresultaten – en nog belangrijker: welke projecteffecten – hij heeft gerealiseerd?
Volgens mij moet je niet evalueren na het project, maar tijdens het project. Problemen maar ook potentiële verbeteringen kunnen dan nog tijdens het lopende project opgepakt worden. Een mooi voorbeeld hiervan zijn software ontwikkelingsprojecten die gebruik maken van SCRUM, maar ook andere processen zoals bijvoorbeeld in de auto-industrie de gebruik maken van KANBAN hebben dit soort tussentijdse evaluaties.
— http://www.scrum.org/storage/scrumguides — pagina 12
Sprint Retrospective (team evaluatie)
De Sprint Retrospective is een kans voor het Scrum Team om zichzelf te inspecteren en een plan te maken om zichzelf gedurende de komende Sprint te verbeteren.
De Sprint Retrospective vindt plaats na de Sprint Review en vóór de volgende Sprint Planningsbijeenkomst. Dit is een drie-uur-timebox bijeenkomst voor Sprints van één maand. Proportioneel minder tijd wordt gepland voor kortere sprints.
Het doel van de Sprint Retrospective is om:
- Te inspecteren hoe de laatste Sprint is gegaan met betrekking tot mensen, relaties, processen en tools;
- Dingen die goed gingen en potentiële verbeteringen te identificeren en te ordenen; en,
- Een plan te creëren om verbeteringen op de manier waarop het Scrum Team zijn werk doet te implementeren.
— —
veel succes met evalueren.
Een project is per definitie uniek. Mijn ervaring is dat evalueren – tijdens en/of achteraf en mits serieus gedaan – bijdraagt aan je eigen expertise en kennis en die van de andere betrokkenen. Die bagage benut je als vanzelf om bij te sturen of het een volgende keer iets anders aan te pakken. Daar gaat het vooral om; niet om een rapport voor bureaulade A of B.
Uniek in de zin van eenmalig? Ja, dan heeft het niet veel zin. Maar de meeste professionals bewegen van project naar project. Dus heeft het wel degelijk zin. Je evalueert namelijk niet het project, maar het menselijk handelen n.a.v. het projectverloop. Dus Wicher slaat de spijker op de kop. Misschien kan ik het voor Steven ‘t beste samenvatten met de beginzin op Evaluon: Je kunt nooit twee keer dezelfde fout maken. Want de tweede keer is geen fout, maar een keuze.
@Peter Janssen :Methodologies should only be mixed after extensive discussions are held among Agile coaches and other stakeholders in the project. Most often organizations modify Agile methodologies to an extent when there is no element of Agile evident in the new version. When the project fails, the organization places the blame on Agile methodologies.
When mixing methodologies, it should be kept in mind that Agile methods cannot be mixed with Waterfall or traditional methods. Waterfall methodologies are most useful on linear projects that do not have any unpredictability, whereas Agile projects are typically unpredictable and are subject to constant change.
http://scrumstudy.com/blog/?p=233