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