Vakblad Projectmanagement en agilemanagement - nr. 22 - 2024
Vakblad projectmanagement en agilemanagement
Foto voorpagina:
Het is het einde van het jaar. De winter is een mooie periode voor introspectie. Hoe doe je je werk? Waarom doe je iets op de manier waarop je dat doet? Deze editie laat zien hoe goed te reflecteren.
2 Hoofdartikel
Ophouden met negatief zijn.
6 Reflecteren: vooral kijken naar je eigen gedrag in projecten
Is reflecteren hetzelfde als evalueren? Nee, dat is het niet. En analyseren valt ook niet onder de noemer reflecteren, evenals post mortem momenten dat niet doen. Maar wat is het dan wel?
12 Interview Joop Schefferlie:
‘Wat heeft certificering het vakgebied projectmanagement in de afgelopen jaren gebracht?’ Deze reflectie-vraag legden we voor aan Joop Schefferlie, directeur IPMA
Certificering. Andere vragen aan hem waren of en wanneer IPMA en PMI als projectmanagement vakverenigingen samen kunnen gaan. En of er wel 28 IPMA competentiegebieden moeten blijven.
20 Gesprek met Jeroen Venneman, voorzitter Agile Consortium
Bij de opkomst van het agile werken werd er afscheid genomen van veel projectmanagers. Op dit moment zien we dat bedrijven afscheid nemen van hun agile coaches. Hoe komt dat? ‘Het verwachte resultaat op organisatieniveau blijft te lang uit voor bedrijven, er wordt gezocht naar andere oplossingen’, zegt Jeroen Venneman, voorzitter Agile Consortium. Een reflectie op het agile werken.
25 Quotes
28 Opdrachtgever, let op je veerkracht
Ongeveer een 0,5 procent van de projecten is volgens de statistieken van professor Flyvbjerg succesvol. Ofwel, een opdrachtgever krijgt in 99,5 procent van de projecten een andere uitkomst dan vooraf bedacht en afgesproken. Een opdrachtgever moet dus beschikken over de nodige veerkracht om bij fikse tegenslagen in een project oplossingen te vinden?
36 Gesprek met Paul Iske, Instituut voor Briljante Mislukkingen
Het Instituut voor Briljante Mislukkingen is opgericht in 2010 door prof. dr. Paul Louis Iske. Hij wil met zijn team aan ondernemers en organisaties laten zien dat falen in projecten zeker een optie is. ‘Mislukken moet je als fenomeen waarderen’, aldus Paul Iske die toelicht hoe in eigen projecten te reflecteren aan de hand van 16 archetypen. ‘Een fout verdient vergeving. Een Briljante Mislukking verdient waardering.’
42 Ervaringen in projecten
Karel, hij is IT projectmanager, neemt ons mee in een (niet goed) lopende omvangrijke SAP implementatie.
46 Begrotingen vaak te optimistisch opgezet
Al zo lang er applicaties worden ontwikkeld, wordt er geklaagd: te duur, te laat, te weinig functionaliteit en/of te lage kwaliteit! Allerlei redenen worden daarvoor aangehaald. Een reden die je bijna nooit hoort: dat er onprofessioneel en onrealistisch wordt begroot. Dit laatste hoeft niet voor te komen.
53 BPUG
54 Onderzoek naar meten rendement applicaties
Als KWD willen we een antwoord geven op de vraag WAAROM er zo weinig aandacht wordt besteed aan het meten van rendement van applicaties. Veel concrete tips daarvoor zijn te vinden in de literatuur. Maar organisaties laten het meten liever achterwege. Wat is er aan de hand? Aan het onderzoek kunt u deelnemen.
60 Reflectie-enquête onder KWD-projectmanagers
Reflecteren in de praktijk. Hoe reflecteren we als projectmanager?
Columns
18 John Hermarij Evaluaties? Niet doen. Experimenteer!
26 Leo Klaver Traagheid Troef
Ophouden met negatief zijn
Het wordt weleens vergeten: projectmanagement is een geweldig vak. Als projectmanager mag je werken aan de meest uitdagende projecten die niet zelden het maatschappelijk landschap veranderen. Daarom is het altijd weer merkwaardig en onbegrijpelijk dat Projectmanagement zo vaak negatief in het nieuws is. De meest complexe zaken worden in projecten aangepakt, maar in de media gaat het daar niet over. Niet interessant of uitdagend is dan vaak de insteek, maar dat een project te lang duurt, te veel kost of niet het gewenste resultaat oplevert. Als dat al zo is, dan is dat in de regel niet te wijten aan het project of projectmanagement zelf maar aan heel andere zaken die -vaak uit politieke overwegingen- niet mogen worden benoemd. Projectmanagement wordt dan als schaamlap voor het benoemde falen gebruikt. Zeer ten onrechte. Het zou goed zijn om meer het positieve van projectmanagement en projectmanagers te benoemen, ook vanuit het vakgebied zelf.
Deze editie gaat over reflecteren. Ik wil hierbij een oproep doen om op het vakgebied te reflecteren vanuit het positieve en niet vanuit het negatieve. Daar moeten we mee ophouden. Alles kan beter, sneller en goedkoper, maar dat is niet waar het om gaat. Kernpunt in projecten is dat er stapsgewijs wordt gewerkt aan verbetering. Reflecteren hoor hierbij om alle (vervolg)stappen te kunnen zetten. ‘Fouten verdienen vergeving, mislukkingen verdienen waardering’, zegt Paul Iske van het Instituut van Briljante Mislukkingen in een gesprek met hem. Reflecteren is daarmee net
zo belangrijk als welk onderdeel in een project dan ook.
Maar hoe moet je reflecteren? Hoe doe je dat? Het wordt in deze editie van het Vakblad toegelicht. Het is zo’n begrip, waarvan iedereen weet wat ermee wordt bedoeld, waarvan iedereen snapt dat het goed is om te doen, maar vaak in de spreekwoordelijke la wordt gelegd als iets wat altijd nog kan. Dat is jammer en altijd weer een gemiste kans. Bij reflecteren gaat het om hoe je je werk doet, niet om wat je doet. Reflecteren is dat je aan jezelf vragen stelt over je gedrag. Waarom doe je iets op de manier waarop je dat doet? Zou een andere manier van werken niet beter zijn, voor jezelf, voor anderen in het project, voor het project zelf, voor opdrachtgevers, voor stakeholders. Daarmee kan reflecteren lastig en confronterend zijn: stel dat er iets naar boven komt in je handelen dat je niet van jezelf kent, dat je daardoor je gedrag moet bijstellen. Nog erger, stel dat er hiaten in je kennis naar boven komen. Misschien weet je niet eens hoe je wat doet omdat je alles op routine doet. Let wel, bij reflectie gaat het nogmaals niet om te evalueren of je je werk goed doet: dat is nabeschouwen. Ook goed om te doen, maar bij reflectie is het doel om een beter beeld te krijgen van je zelf om daarvan te leren.
Door te reflecteren kun je ook zien wat je bent. Ben je een bezinner die kijkt hoe anderen een probleem aanpakken en eerst nadenkt voordat hij/zij iets doet? Of ben je een beslisser die goed
is in logisch denken en redeneren? Of ben je een beslisser die een taak plant en uitvoert en niet zo geïnteresseerd in wat voor theorie dan ook? Of ben je vooral een doener die graag problemen oplost door iets uit te proberen? Door te reflecteren kun je erachter komen wat en waarom je gemakkelijk afgaat en wat je liever niet doet omdat je er niet goed in bent. Juist daar liggen ook voor projectmanagers uitdagingen. Door te reflecteren kun je erachter komen waar nog uitdagingen voor jou liggen en mogelijkheden voor persoonlijke groei. Wie persoonlijk groeit, groeit in de regel ook als professional in zijn of haar vakgebied. Daarom reflecteren, dus.
Reflectie heeft ook impact op je kennisniveau als projectmanager. Stel je bent vooral een beslisser die graag plant en uitvoert, dan zul je minder geïnteresseerd zijn in bijvoorbeeld mogelijke nadelen en/of risico’s die kunnen kleven aan de implementatie van een bepaalde technologie. Een beslisser denkt hoe hij AI-kan inbedden in wat er al is, terwijl een denker daar nog even over nadenkt. Is het wel zo slim om in AI te investeren in dit project in de zorg dat ik omhanden heb? Iedereen zegt wel dat AI in de zorg de toekomst is, maar zou het ook niet kunnen betekenen dat de zorg zich alleen maar nog afhankelijker maakt van de grote high tech bedrijven? Zou het niet zo kunnen zijn dat er op den duur meer geld richting deze bedrijven vloeit dan naar mensen die patiënten op een menselijke manier terzijde kunnen staan? AI kan wellicht helpen een diagnose te stellen, maar dat maakt een patiënt nog niet beter. Anders gezegd, in projecten kunnen meer resultaten worden geboekt die het verschil maken als een projectmanager niet alleen een beslisser is, maar zich ook bekwaamd heeft in het bezinnen, of het logisch nadenken en/of in het experimenteren.
Door op een meer holistische manier naar jezelf te kijken en daarvan te leren, kun je ook zien waar je kennis nog bijgespijkerd moet worden. Dan heb ik het niet alleen over het behalen van certificaten et cetera, maar meer over het toepassen van opgedane kennis. Je kunt gecertificeerd zijn in de agile werkwijze, maar vervolgens maakt het een groot verschil of je deze kennis toepast
Gratis of betaald abonnement op het Vakblad project- en agilemanagement
Voor u ligt editie 22. Het accent ligt ditmaal op reflectie en hoe dit te doen. Vakblad Projectmanagement verschijnt driemaal per jaar. Het wordt gestuurd naar projectmanagers, managers van projectmanagementafdelingen, programmamanagers, multi-project managers en lijnmanagers die betrokken zijn bij projecten in de eigen organisatie.
Wilt u weten of u in aanmerking komt voor (gratis) toezending? Stuur uw aanvraaggegevens door via www.kwdrm.nl/vakblad. De redactie beoordeelt de aanvraag. Een betaald abonnement kost 25,00 euro per jaar, inclusief 9 % btw. Elke editie is ook digitaal te ontvangen.
Aanleveren content
Heeft u ideeën voor content die een bijdrage kunnen leveren aan het vak projectmanagement of wilt u in contact komen met redactieregisseur Luuk Ketel: laat het ons weten via vakblad@ kwdrm.nl
als bezinner, denker, doener of beslisser. Een beslisser kan op basis van zijn of haar kennis een epic/project en de daaraan gekoppelde sprints inplannen en hup uitvoeren, terwijl een bezinner eerst gaat nadenken over of een sprint wel zinvol is, of het wel past in het geheel. Een bezinner wil waarschijnlijk ook eerst te rade bij anderen die kunnen helpen zijn of haar invalshoek te verbreden of te onderbouwen.
Daarmee is nog niet te vraag beantwoord hoe je kunt reflecteren. In deze editie gaan we daarom ook wat dieper op deze vraag in. Het is in ieder geval wat meer dan jezelf op een stoel te zetten aan de rand van een meer en dan dromerig voor je uit te staren. Reflecteren is een kunst die geleerd moet worden. Gelukkig zijn er inmiddels de nodige methoden een aanpakken om het
reflecteren op een goede manier te doen. Zo is er bijvoorbeeld de Learning Style Inventory die is ontwikkeld door David Kolb en die wordt gebruikt in het onderwijs en management. Dan is er bijvoorbeeld ook nog het STARR-model en het model van onderwijsdeskundige Fred Korthagen. Dit laatste model laat zien dat je steeds cirkels doorloopt van handelen en het opdoen van ervaringen.
Als je weet hoe te reflecteren dan kun je bijvoorbeeld het volgende leren. Het voorbeeld is geplukt van internet: ‘Ik heb door te reflecteren geleerd dat ik in een presentatie altijd moet starten bij het vertrekpunt van het project. Wanneer je begint met het delen van de eindresultaten, voelen de mensen die minder in het project zitten zich wellicht bedolven onder een berg informatie. Daardoor ontstonden tijdens mijn presentatie veel vragen, die ik eigenlijk had kunnen tackelen als ik iedereen in het begin beter had meegenomen in het waarom achter mijn project. Eventueel had ik dat ook kunnen doen door aan het begin een korte animatiefilm over mijn project te tonen. Voor een volgende presentatie ga ik een korte animatie over mijn project maken zodat iedereen gemakkelijk kan worden meegenomen in wat het is dat ik voor de organisatie aan het doen ben en waarom. Ik ga daarvoor de hulp vragen van Sophie die al ervaring heeft in het maken van korte animaties over projecten’.
Een goede manier om te reflecteren is ook door een certificatietraject af te lopen, zegt Joop Schefferlie, directeur IPMA-Certificering die toelicht welke waarde een certificeringsreis heeft. Zo’n reis helpt je om te zien waar je jezelf al goed hebt ontwikkeld en waar nog aan te sleutelen valt. Een dergelijk certificaat is overigens ook vaak nodig om bij opdrachtgevers grote projecten te doen die een impact hebben. Overigens helpt certificeren ook de opdrachtgever: die ziet aan een gehaald certificaat wat hij in huis haalt.
Reflecteren is leren. Dat doe je overigens nooit alleen, altijd met elkaar. Het vak projectmanagement leer je niet alleen uit boeken, ook door het met elkaar te doen in bijvoorbeeld in een meester/leerling of coaching aanpak zoals KWD
Resultaatmanagement die heeft ontwikkeld. Het is goed denkbaar dat als projectmanagers goed weten te reflecteren er betere resultaten kunnen worden geboekt en dat er minder projecten als mislukt kunnen worden beschouwd. Reflecteren, kennis opdoen hoe je als persoon, als individu projecten uitvoert in een wisselwerking met anderen, zou dan nog wel eens een goed investering kunnen zijn.
KWD heeft tijdens haar laatste Vakdag editie 12 in de KWD-boekenreeks uitgebracht: Projectmanagement: een reflectie op de toekomst. Met deze editie wil KWD projectmanagers helpen zich een beeld te vormen van deze toekomst en welke competenties ze daar voor nodig hebben. Het zal u niet verbazen dat kunstmatige intelligentie daarin een rol speelt. Wat er ook zal gebeuren in de toekomst: projectmanagement blijft mensenwerk en de het brein van mensen zal nooit door technologie vervangen kunnen worden. Tijdens de vakdag deed Ayca Szapora uit de doeken hoe dit brein werkt: ‘We moeten dingen vooral behapbaar maken door ze eenvoudig te maken en vaak te herhalen’, zei ze. Verbeteren, het doorvoeren van transities is niet iets wat je in een grote stap voor elkaar krijgt. Het is wel iets dat projectmanagers in kleine brokjes voor elkaar krijgen. Ophouden met negatief zijn over projectmanagement dus.
Luuk Ketel
KWD resultaatmanagement
Luuk Ketel vormt samen met Annet Holtrop, Ronald Kappert, Bart van den Hooff en Leo Klaver de redactie van het Vakblad Projectmanagement.
Reflecteren: vooral kijken naar je eigen gedrag in projecten
AUTEUR: LEO KLAVER
Reflecteren. Het staat centraal in deze editie van het Vakblad. Maar hoe doe je dat? Is reflecteren hetzelfde als evalueren? Nee, dat is het niet. En analyseren valt ook niet onder de noemer reflecteren, evenals post mortum momenten dat niet doen. Maar dat is het dan wel? Het heeft in ieder geval vooral met gedrag te maken en niet zozeer met kennis.
Reflecteren is terugkijken op hoe je te werk bent gegaan, in dit geval als projectmanager in projecten. Doel daarvan is om ervan te leren om vervolgens deze kennis mee te nemen naar volgende projecten. Doel daarvan is natuurlijk om meer kansen op succes te creëren in projecten. Een goede manier om te reflecteren is door op een gestructureerde manier vragen te stellen over een opgedane ervaring, of een probleem, of een manier van werken. Het nut van reflecteren is dat je door vragen aan jezelf te stellen een koppeling kunt maken tussen wat je hebt gezien, ervaren, gedacht en gedaan. Je kan je reflectie opvalpunten dan bijvoorbeeld vastleggen in een notitieboekje op een vrijdagmiddag momentje.
Het gaat er bij reflecteren om steeds terug te kijken op, en jezelf vragen te stellen over hoe jij aan het werk bent en wat daar de achtergronden van zijn. Het is een vorm van bewustwording: je krijgt
een beter beeld van jezelf en je wordt je beter bewust van je eigen gedragingen, gedachten en gevoelens.
Het gaat er dan niet zozeer om of je het werk goed of juist niet goed hebt gedaan. Dat is nabeschouwen en evalueren. Het is juist belangrijk om zelfevaluatie – het beoordelen van je eigen handelen – uit te stellen als je wilt reflecteren. Je vermogen om te beoordelen is overigens van groot belang bij het oplossen van problemen en het nemen van besluiten. Als je goed een oordeel kunt vormen, dan kun je bijvoorbeeld beter inschatten hoe groot het probleem werkelijk is, je kunt dan ook duidelijker aangeven wat het doel is van je besluit en wat de beste keuze is uit alle mogelijke oplossingen of besluiten. Een goed beoordelingsvermogen is een belangrijke soft skills, oftewel een vaardigheid en persoonlijke kwaliteit waarmee jij als professional in staat bent om effectief te functioneren en harmonieus samen te werken met andere mensen.
Bij evalueren gaat het ook veel meer om het beoordelen van je voorgenomen werkplan. Iemand die evalueert vergelijkt de verwachting die hij van tevoren had met de feitelijke gang van zaken. Dan kun je conclusies trekken en doelen stellen voor een volgende keer. Bij evalueren beoordeel je de resultaten van je acties. Kijk je naar welke eventuele storende factoren een rol hebben gespeeld in het realiseren van beoogde
resultaten. En trek je conclusies om in soortgelijke situaties in de toekomst deze storende factoren niet of een minder zware aanwezig te laten zijn.
Bij reflecteren:
● Omschrijf je de situatie en omgeving
● Onderzoek je je gedrag.
● Stel je vragen over je eigen vaardigheden
● Achterhaal je je motivatie of overtuigingen
● Sta je stil bij je identiteit.
● Is er oog voor je dieperliggende drijfveren
Reflecteren helpt je te groeien en jezelf te ontwikkelen vanuit opgedane ervaringen en betekent terugblikken op je eigen gedrag en ervaringen. Door diepgaand na te denken om zo tot nieuw zelfinzicht te komen en nieuwe keuzes te maken. Reflecteren betekent dat je jezelf een spiegel voorhoudt om zo te overdenken hoe je bijvoorbeeld werkt, welke keuzes je daarbinnen maakt, welke vaardigheden je inzet en hoe dat voelt. Er zijn drie vormen van reflectie te onderscheiden:
1. Reflecteren op persoonlijk functioneren Daarbij sta je vooral stil bij wie jij bent, wat je motivatie en je doelen zijn in het leven. Deze vorm van reflectie kan je helpen bij je persoonlijkheidsontwikkeling.
2. Reflecteren op beroepsmatig handelen Deze vorm van reflecteren richt zich vooral op je professionele competenties en het methodisch handelen. Je kunt zo onderzoeken wat het effect is van de methoden die jij inzet.
3. Reflecteren op persoonlijk beroepsmatig handelen in de maatschappelijke context
Reflecteren is een vaardigheid. Wanneer je dat regelmatig doet, ontdekt je waar je van nature goed in bent en de punten waar je jezelf nog kunt en wilt ontwikkelen
Bij deze vorm van reflecteren kijk je ook naar de context van jouw functioneren en handelen. Hierbij vraag je je af wat het effect is op de omgeving, de maatschappij en in hoeverre jij hier verantwoordelijk voor bent.
Deze drie vormen van reflectie zijn niet altijd zo duidelijk van elkaar te onderscheiden; de ene hangt nauw samen met de andere. Het draait bij reflectie in ieder geval altijd om jouw eigen rol en bijdrage in bepaalde situaties.
Zelfreflectie is daarmee tweeledig: Je durft naar jezelf te kijken en je bent je bewust van de impact van jouw gedrag op anderen. Je bent je
Uitproberen
Cirkel van Korthagen
Alternatief (gedrag) ontwikkelen
Belangrijke aspecten begrijpen
Situatie ervaren
Terugblikken
ook bewust van de impact van het gedrag van anderen op jou.
Hoe te reflecteren?
Maar hoe doe je dat dan, reflecteren. Kies een concrete situatie en kijk daarop terug. Wat was jouw manier van handelen? Ervoer je blokkades in je handelen of in de communicatie met anderen? Reflecteer regelmatig en 'rooster' tenminste één keer per week een reflectiemoment in liefst op een vast moment. Stel jezelf open reflectievragen die zowel vooruit als achteruit kijken. Reflecteer niet alleen op negatieve situaties. Je kunt ook veel leren van situaties waarin je gedrag een positief effect had op mensen en de situatie. Reflecteren is een vaardigheid. Wanneer je dat regelmatig doet, ontdekt je waar je van nature goed in bent en de punten waar je jezelf nog kunt en wilt ontwikkelen.
Er zijn verschillende manier om te reflecteren, hieronder volgen een paar praktische modellen die je kunnen helpen om te reflecteren.
Korthagen
Het model Korthagen omvat de volgende vijf stappen:
1. Je kiest een situatie die voor jou van betekenis was. Bijvoorbeeld een lastige vergadering van stakeholders.
2. Je blikt daarop terug door deze ervaring voor jezelf te beschrijven. Dat kan ook door daarover te schrijven in een dagboek. Wat was je rol? Geef aan waarom en hoe je hebt gehandeld zoals je hebt gedaan.
3. Je begrijpt waarom de situatie voor jou van betekenis was. Je ziet wat de meest belangrijke kenmerken van deze ervaring was. Bewustwording dus. Wat vond je moeilijk en
VOORBEELDEN REFLECTIEVRAGEN
Om terug te blikken:
1. Wat was het mooiste moment van afgelopen periode?
2. Hoe heb je jezelf de afgelopen periode gevoeld?
3. Welke successen heb je geboekt?
4. Wat maakte dat het een succes was?
5. Welke eigenschappen en kwaliteiten heb je hiervoor ingezet?
6. Wat heb je over jezelf geleerd?
7. Op welk moment voelde je je het vrolijkst?
8. Wie heeft je het meest verrast of geholpen?
9. Welke tegenslagen heb je gehad en wat kun je hiervan leren?
10. Waar wil je nooit meer naar terug?
11. Wat heb je goed gedaan en waar je ben je trots op?
12. Heb je genoeg tijd voor jezelf genomen?
13. Op welk moment moest je echt je weerstand overwinnen?
14. Op welke ‘nee’ ben je het meest trots?
15. Op welk moment ben je 100 procent trouw aan jezelf gebleven?
Om vooruit te blikken
1. Hoe wil je je de komende periode voelen?
2. Welk verlangen ga je waarmaken?
3. Waar hoop je op?
4. Welke dingen wil je graag realiseren?
5. Welke processen wil je optimaliseren?
6. Waarvan wil je afscheid nemen?
7. Welke dingen wil je nog meer doen omdat je er energie van krijgt?
8. Met wie wil je meer tijd doorbrengen?
9. Wanneer neem je tijd om te ontspannen?
10. Waar ga je meer ‘ja’ tegen zeggen?
11. Waar ga je meer ‘nee’ tegen zeggen?
12. Wat is op dit moment het allerbelangrijkst voor je?
13. Waar word jij vrolijk van?
14. Waar krijg je energie van?
15. Wat kost je energie?
16. Hoe is je werk-privé balans?
17. Heb je voldoende tijd besteed aan de mensen die echt belangrijk voor je zijn?
18. Heb je genoeg tijd om te sporten?
19. Welk cijfer geef je jouw gezondheid?
20. Ben je 100 procent trouw aan jezelf?
waarom? Vraag anderen hoe ze jouw gedrag hebben ervaren.
4. Bedenkt hoe je ook anders in deze situatie had kunnen handelen.
5. Je probeert de gevonden alternatieven uit in een volgende bijeenkomst, vergadering.
Het model van Korthagen neemt je gedachten en gevoelens in de reflectie mee. Daardoor neem je meer persoonlijke antwoorden mee op vragen zoals:
● Welke acties heb ik ondernomen?
● Wanneer werk ik methodisch en wanneer vanuit mijn intuïtie?
● Wanneer werk ik routinematig?
● Op welke manier geef ik samenwerking vorm
● Hoe is mijn gedrag te omschrijven
● Hoe kijk ik terug op mijn gedrag?
● Wat ging goed? Wat kon beter?
● Ben ik tevreden met het resultaat?
● Zijn anderen tevreden met het resultaat?
● Wat zou ik een volgende keer anders doen?
Wat heb ik daarvoor nodig?
STARR
STARR model richt zich vooral op feiten, oorzaken en gevolg. Als je de STARR-methode gebruikt, geef je antwoord op vragen over de Situatie, Taak, Actie, Resultaat en Reflectie. Deze methode is ontstaan in het HR-vakgebied en is daarom erg taakgericht en weinig emotioneel van karakter. In de reflectiefase gaat het om antwoorden te vinden op de volgende vragen:
● Hoe kijk je terug op jouw gedrag?
● Wat ging goed? Wat kon beter?
● Ben je tevreden met het resultaat?
● Zijn anderen tevreden met het resultaat?
● Wat zou je een volgende keer anders doen?
Wat heb je daarvoor nodig?
Leerstijlen van Kolb
Niet iedereen kan van nature gemakkelijk reflecteren. Sommige mensen geven bijvoorbeeld de voorkeur aan kennisleren. Zij vinden het leuker om met theorieën bezig te zijn dan met hun eigen houding. Welke manier van leren jij vooral zult gebruiken is afhankelijk van je eigen leerstijl. Door een leerstijlentest (zie 123test.nl) te doen kun je achterhalen welke leerstijl bij jou hoort. Zo weet
Bij reflecteren onderzoek je je manier van handelen, maar ook hoe je reageert op een bepaalde situatie en hoe dat voelt
je of je een doener, bezinner, denker of beslisser bent. De bezinner is bijvoorbeeld iemand die graag gebruikmaakt van reflectie. Hanteer je meestal een andere leerstijl, dan zul je minder snel reflecteren.
De Learning Style Inventory (LSI), ontwikkeld door David Kolb, is een van de eerste en meest gebruikte modellen voor leerstijlen in het onderwijs en management. Deelnemers aan de test vullen lijsten in met statements waaruit kan worden geconcludeerd welke leerstijl bij iemand past.
De leerstijlen die Kolb onderscheidt:
1. De bezinner kijkt hoe anderen een probleem aanpakken en denkt eerst na voordat hij iets doet. Hij ziet veel oplossingen, omdat hij een probleem vanuit veel standpunten kan bekijken. Daardoor neemt hij beslissingen soms traag.
2. De denker is goed in logisch denken en redeneren. Hij probeert algemene regels te ontdekken en leert het liefst uit boeken. Het is belangrijker dat ideeën logisch zijn, dan dat ze praktisch uitvoerbaar zijn.
3. De beslisser plant een taak en voert die uit. Hij is niet zo geïnteresseerd in theorieën. Hij doet het goed in conventionele intelligentietesten. Houdt zich liever bezig met technische problemen dan met mensen.
4. De doener houdt van experimenteren en lost problemen op door iets uit te proberen. Hij past zich goed aan nieuwe situaties. Soms
kan een doener drammerig overkomen in zijn dadendrang.
Effect van je reflecties
Bij reflecteren onderzoek je je manier van handelen, maar ook hoe je reageert op een bepaalde situatie en hoe dat voelt. Dat laatste, je gevoel, is een thema waarbij je uitgebreid stil moet staan in je manier van reflecteren. Vaak reageren we uit een eerste impuls op een situatie. Dat betekent dat je niet eerst nadenkt voor je iets doet, maar handelt op basis van je eigen emoties. Ook kan het zijn dat je werkt vanuit vooringenomen standpunten of overtuigingen zonder dat je dit zelf in de gaten hebt. Je gaat er bijvoorbeeld vanuit dat een collega met wie je samenwerkt iets niet kan, en zonder er echt over na te denken heb je zijn taken daarom overgenomen.
Door te reflecteren:
● Vergroot je je zelfkennis en zelfbewustzijn.
● Word je je bewust van de emoties die in bepaalde situaties bij jou een rol spelen.
● Krijg je nieuwe inzichten in hoe je daarnaar handelt.
● Word je je beter bewust van de impact die je hebt op anderen.
● Reflectievragen kunnen zowel gebruikt worden om terug te kijken als om vooruit te blikken.
Over de auteur: Leo Klaver is lid van de redactie van dit Vakblad
Joop Schefferlie (IPMA):
‘Er
bestaan geen Holy Grails voor het vak
projectmanagement’
‘Wat heeft IPMA-Certificering het vakgebied projectmanagement in de afgelopen jaren gebracht?’ Deze reflectie-vraag legden we voor aan Joop Schefferlie, directeur IPMA Certificering. Een andere vraag aan hem was of en wanneer IPMA en PMI als projectmanagement vakverenigingen samen kunnen gaan. En of er wel 28 IPMA competentiegebieden moeten blijven. Dit waren zijn antwoorden.
AUTEURS: LUUK
‘Mooie vragen’, begint Joop Schefferlie zijn antwoord op de ‘Wat’ vraag. ‘Dit soort vragen zet je altijd aan het denken over wat we nu allemaal met elkaar in het projectmanagement vak aan het doen zijn. Wat we willen is wel duidelijk: het vak projectmanagement beter maken. We willen meer succesvol afgeronde projecten realiseren bij klanten, voor opdrachtgevers. Slagen we daarin? Uitgelicht worden altijd de projecten die niet goed gaan, dat is logisch en dat mag en moet ook. Aan de andere kant gaat er ook best veel goed. Maar dat is nog geen antwoord op de ‘Wat’ vraag, ofwel wat certificering het vakgebied heeft gebracht.’
Als je het hebt over projecten die niet goed gaan, dan doel je waarschijnlijk op grootschalige opdrachten. Het vaak aangehaalde CHAOS rapport van The Standish Group laat zien dat het inmiddels wat beter gaat, vooral in de wat kleinere projecten.
‘Ja, dat klopt, maar het ‘verkleinen van projecten’ is geen Haarlemmerolie dat eenmaal opgesmeerd overal en altijd naar superresultaten leidt. Die olie bestaat helemaal niet: er is geen Holy Grail te vinden in projectmanagement. Er zijn zeker aanpakken die in bepaalde situaties helpen een gewenst resultaat te realiseren, maar ‘Iets dat Altijd Werkt’ zal niet gevonden worden. Daarvoor zijn projecten te uniek en bovendien blijven projecten mensenwerk. Uniciteit plus mensenwerk is geen formule waaruit je een Holy Grail kunt destilleren of afleiden.’
Uniek plus Mensenwerk plus Certificeren leidt per definitie ook niet tot succes?
‘Daar hoort nog wat bij als je succesvol wilt zijn. Als projectmanager en opdrachtgever moet je ook goed kunnen nadenken over de omstandigheden waarin en waaronder het project moet worden uitgevoerd. Ook moet helder zijn in welke branche het project moet worden uitgevoerd. Als je weet wat voor soort project het is, dan is het vervolgens voor opdrachtgevers in samenwerking met de projectmanager zaak te bekijken welke uitvoeringsmensen die de branche kennen het beste op het project gezet kunnen worden. Welke competenties zijn in het team nodig? Maar ook: welke aanpak kan het meest passende zijn om succesvol te worden? Waterfall? Agile? Of hybride? Ik ben van mening dat opdrachtgevers en projectmanagers over al dat soort zaken te weinig nadenken. En dat kan het realiseren van succes in de weg staan.
Certificering kan hier helpen een meer succesvolle weg af te leggen. Vaak staan projectmanagers aan het roer gedurende de gehele looptijd van een project. De vraag is of dat zinvol is. Vaak is het beter om vooral in grote projecten verschillende typen projectmanagers aan te stellen. Dit omdat projecten vaak verschillende fasen
kennen die allemaal een eigen aanpak verdienen. Certificering kan helpen hier een beter inzicht in te krijgen.’
Kun je dat toelichten?
‘Certificeren is een reis, een proces dat de projectmanager doorloopt en die belangrijker is dan het uiteindelijke certificaat zelf. Een senior projectmanager die IPMA-B gecertificeerd wil zijn, moet een behoorlijk aantal grote stappen doorlopen alvorens dat te zijn. Natuurlijk, het hebben van kennis is belangrijk, maar een belangrijke stap is ook dat je goed naar jezelf moet kunnen kijken. Reflectie en leren. Dat is niet altijd eenvoudig, zo wijst de praktijk uit: reflecteren kan voor mensen moeilijk zijn. Als je jezelf verder wilt ontwikkelen moet je voor jezelf een beeld kunnen vormen van je eigen gedrag in projecten. Heb ik voldoende kennis? Wat zou ik moeten bijleren? Hoe competent vind ik mezelf op kennisonderdelen? Dat zijn lastige vragen om te beantwoorden. Een certificaat krijg je dan ook niet zomaar. Wil je in aanmerking komen voor bijvoorbeeld een IPMA-B certificaat, dan, moet je kunnen aantonen dat je projecten hebt uitgevoerd waarin je de beschreven 28 competenties in dit certificaat voldoende hebt kunnen inzetten. Hoe is het gesteld geweest met de complexiteit waarmee ik te maken heb gehad? En heb ik daar een voldoende antwoord op kunnen vinden?
Verder moet je in de meeste gevallen ook nog een toets ‘Toegepaste Kennis’ afleggen. Het is echt een reis.’
Voor alle duidelijkheid: met certificaat A en B kan een projectmanager aantonen dat hij of zij grote projecten heeft afgerond. Doen de certificaten C en D hetzelfde, maar dan voor de kleinere projecten?
‘Precies, zo zit dat. Bij B gaat het vaak over de grotere projecten. D is voor beginnende projectmanagers die met het vak kennis willen maken of stappen daarin willen zetten. C heeft middelgrote projecten als context. Ervaring wordt ook getoetst.’
Door te werken aan een certificaat ontdek je waar kennishiaten bij jezelf zitten en kun je daaraan werken. Kun je nu ook zeggen dat als je gecertificeerd bent, dat je dan ook beter in staat bent om in projecten het gewenste resultaat te behalen?
‘Dat is natuurlijk de hamvraag. Ik moet deze vraag zowel met ja als met nee beantwoorden. Ja, omdat je in het certificeringstraject goed naar jezelf kijkt, weet je waar je kracht ligt als projectmanager, en heb je zwakke plekken aangepakt. Daardoor kun je in projecten van grotere waarde zijn. Maar je moet tegelijkertijd weten waar je als projectmanager waarde kunt toevoegen. Als je bijvoorbeeld goed kunt experimenteren, dan kun je op dat terrein waarde toevoegen in een project. Maar je moet ook kunnen zeggen: voor dat stuk in het project kun je beter iemand anders nemen die daarin meer geschoold is of meer ervaring in heeft. Dat is het nee-gedeelte van dit antwoord: nee een certificaat leidt niet automatisch tot meer succes. Daarvoor is eigenlijk nodig dat er een goede match is tussen de afzonderlijke onderdelen in een project en projectmanagers die in die onderdelen meer dan gemiddeld goed zijn. Die projectmanagers moeten dan wel beschikbaar en ingezet kunnen worden. Dat is vaak helaas geen mogelijke realiteit.’
Als je jezelf verder wilt ontwikkelen moet je voor jezelf een beeld kunnen vormen van je eigen gedrag in projecten
Het zou inderdaad mooi zijn als je in projecten het volledige scala aan soorten projectmanagers tot je beschikking zou kunnen hebben: beslissers, denkers, doeners, planners, managers nodig die
Projectmanager
Profiler KWD geeft snel profiel projectmanager weer
Met de KWD-App Projectmanager profiler is binnen vier minuten een beeld te verkrijgen van het profiel van een projectmanager. De Projectmanager Profiler geeft een aantal vragen die ingevuld laten zien wat het kennis- en ervaringsniveau van een projectmanager is, welke competenties meer dan gemiddeld zijn ontwikkeld en hoe zijn of haar persoonlijkheid is te omschrijven. Voor dit laatste wordt onder gebruik gemaakt van de persoonlijkheidskenmerken zoals die zijn opgenomen de BIG FIVE test. Voor het bepalen van het kennis- en ervaringsniveau is Project Management Body of Knowledge (PMBOK) het referentiekader. PMBOK omschrijft negen functionele kennisgebieden, die nader worden uitgewerkt in 37 deelgebieden.
De KWD-App Projectmanager Profiler is te vinden op: https://app.kwdrm.nl/#/pm-profiler
graag experimenteren. Met elkaar zouden ze veel successen kunnen realiseren. Komt dit aspect in het certificeringsproces ook aan de orde? Ofwel kun je aan een certificaat zien met welke type projectmanager je van doen hebt?
‘Hoe je als mens in elkaar steekt valt uiteraard niet te certificeren. Door het certificeringsproces af te lopen krijg je wel zelf een beeld hoe je in elkaar steekt. Op basis daarvan kun je beter beoordelen in wat voor projecten jouw kennis optimaal tot zijn recht kan komen en kun je dat ook aan opdrachtgevers meegeven. Vaak, zo is
de begrijpelijke realiteit, krijgt een project een interne- of externe projectmanager die op dat moment beschikbaar is het hele project van voor tot achter te managen. Dat is niet noodzakelijkerwijze de meest efficiënte weg. Als er beter voor en tijdens projecten gematched kan worden, dan komt dat zeker de te realiseren kwaliteit in een project ten goede.’
Door dit alles gaat het niet altijd goed in projecten?
‘Ik hoop nog steeds dat we voor en tijdens een project een beter match kunnen gaan vinden tussen project en projectmanager. Hier ligt ook een rol voor de opdrachtgever. Zoals gezegd succes boek je met elkaar. Een gecertificeerde projectmanager in projecten is niet per definitie beter of slechter en een gecertificeerde projectmanager kan zeker van extra waarde zijn in een project, maar een project kan ook niet zonder een goede opdrachtgever. Het certificeringsproces helpt een opdrachtgever om een betere match te maken tussen project en projectmanager. ‘
Hoe kan een opdrachtgever dat doen?
‘Wat ik uit de praktijk terugkrijg is dat A, B en C-gecertificeerde projectmanagers betere en grotere projecten krijgen om te managen. Dat is natuurlijk ook zo omdat grote bedrijven niet zelden IPMA-certificatie verplicht stellen, omdat ze anders die omvangrijke projecten niet binnen kunnen halen. Opdrachtgevers van grote projecten geven mij terug dat hij of zij aan de hand van een IPMA-Certificaat een beter beeld hebben van de afzonderlijke projectmanagers in een groep en daarmee ook een beter beeld hebben van de totale groep. Met dat beeld weten opdrachtgevers weten daarmee ook hoe de groep zich verder kan en moet ontwikkelen met name wat betreft gedragscompetenties om het gewenste resultaat te kunnen realiseren. Projectmanagers moeten methodieken, frameworks goed kunnen beheersen, maar ze moeten ook stappen zetten in volwassenheid van het vakmanschap. Dat kan met behulp van een certificeringstraject. Die stap naar volwassenheid is en wordt lang niet bij alle bedrijven gezet. Dan zijn er projectmanagers in projecten aan het werk die technisch goed tot zeer goed onderlegd zijn, maar die groentjes
Projectmanagers moeten methodieken, frameworks goed beheersen, maar moeten ook stappen zetten
het certificeren van competenties die horen bij een bepaalde rol die een projectmanager in een project moet kunnen uitvoeren. Een planner of risk-manager bij Shell, hoeft als voorbeeld echt niet alle 28 competenties zich eigen maken. Een senior programmamanager moet een andere balans in zijn competenties hebben dan een senior projectmanager.’
Wat je zegt is dat het certificeren van competenties in de toekomst meer situationeel gericht moet zijn?
zijn op gebieden als politiek onderhandelen, stakeholdermanagement of het samenstellen van een team. Op die terreinen moet er dan eigenlijk nog veel geleerd worden. Het is prima dat er nu veel wordt getraind in Prince2 of welke andere methode dan ook, dat is een mooie basis, maar er moet ook worden getraind in het volwassen worden.’
Kan dat niet goed in een meesterleerling relatie?
‘Zeker, alles is hier goed, er is immers ook nog een tekort aan 6.000 projectmanagers die hoe dan ook zijn opgeleid. Als er maar aantoonbare stappen worden gezet.’
Gezien in de tijd, is het certificeren en daarmee het reflecteren anders geworden dan 20 jaar geleden?
‘Vroeger bestond er een lijst van 54 competenties voor projectmanagers. Dat was zoveel dat er eigenlijk geen touw meer aan vast te knopen was. Nu zijn er 28 IPMA competenties waarin de competentie gedrag steeds belangrijker is geworden. Het gaat niet alleen om het hebben van kennis, maar het gaat steeds meer om het hebben van gedrag dat nodig is om de competentie goed in te zetten. Je kunt alles weten van stakeholdermanagement, maar als je niet weet hoe je met stakeholders goed moet communiceren, dan kom je nog nergens. Verder ben ik wel van mening dat de IPMA zijn competentiecurriculum moet updaten om uiteindelijk te komen tot
‘De basislijn van 28 IPMA competenties is terug te brengen naar een basisset, dat is af te stemmen op wat de projectmanager in een bepaalde situatie per rol moet kunnen. Dat wil overigens nog niet zeggen dat al het overige in de competentieset van nu niet waardevol zou zijn, integendeel, iedere te zetten stap is waardevol. Met de uitwerking van deze gedachte is in Nederland een begin gemaakt. De gedachte wordt internationaal gezien gelukkig ook steeds meer omarmt. Doel is dat je aan een certificaat goed kunt zien welke rol is ontwikkeld, ook voor trainers en coaches. Iets anders is dat je bij IPMA niet je hele leven met een eenmaal behaald certificaat uit de voeten kunt. Eenmaal gecertificeerd zul je op gezette tijden in een ervaringsoverzicht kunnen aantonen dat je nog steeds tenminste acteert op hetzelfde niveau van complexiteit als toen je het certificaat behaalde. Om je certificaat geldig te houden, kijken we daarbij zeker ook naar wat je omgeving vindt van jouw functioneren als projectmanager, ook qua gedrag. En we zien graag dat je in de vijf voorgaande jaren als een soort permanente educatie tenminste 35 uur per jaar in jezelf hebt geïnvesteerd. Dat blijft, ook als er wordt gewerkt met een basisset.’
Wat doet een organisatie als IPMA met alle methodieken die er worden ontwikkeld?
‘Ja, er zijn veel nieuwe methode bijgekomen die allemaal in hun eigen waarheid geloven. Daar zullen we niet zoveel mee doen, wel moet in de nieuwe ICB4, de internationale Individual Competence Baseline standaard, agile en duurzaamheid worden geïntegreerd. Die onderwerpen zitten nu
Joop Schefferlie: ‘Aan een certificaat kun je zien welke rol is ontwikkeld, ook voor trainers en coaches’
al wel in de A, B, C en D cerficeringstrajecten van IPMA, maar het moet nog een geheel worden.’
Als we hier even naar de toekomst mag kijken, hoe groot is de kans dat er morgen een Master Projectmanagement kan worden gevolgd aan een universiteit, met eenzelfde status als een MBA?
‘Dat is ook internationaal zeker een stap die we graag willen zetten.’
Hoe groot is de kans dat de twee vakverenigingen in Nederland, IPMA en PMI samengaan omdat we met zijn allen toch hetzelfde doel willen bereiken?
‘In Nederland werken we daar waar mogelijk samen. Neem bijvoorbeeld de Research Awards die we gezamenlijk toekennen aan mensen die iets moois hebben ontwikkeld. Internationaal is het een ander verhaal. Dat ligt gecompliceerd, ook omdat PMI in het buitenland vele malen groter is dan IPMA en er dus ook financiële zaken een grote rol spelen. Dus om op je vraag terug te komen, dat zie ik nog niet zo snel gebeuren. Verder is de wereld van projecten en projectmanagement zo groot dat er goed twee vakverenigingen kunnen bestaan. Wij certifi-
ceren in Nederland jaarlijks zo rond de 1500 mensen, terwijl er 6000 projectmanagers al dan niet gecertificeerde projectmanagers nodig zijn. Het merendeel van de gecertificeerden zitten op het niveau C en D. Per jaar komen er circa 5 IPMA-A gecertificeerden bij. Dat niveau ligt hoog. De meest recente A-projectmanager heeft het luchtverkeersleidingssysteem in Lelystad Airport aangelegd. Een IPMA-B gecertificeerde heeft al snel 10 jaar ervaring op senior niveau. Daar waar we samen het vakgebied sterker kunnen maken en kunnen zorgen voor meer succes in projecten, daar zullen we dat zeker samen doen. Alles begint evenwel bij de projectmanager die zegt: ik wil die ontwikkelingsreis maken.’ ●
Over de auteurs: Luuk Ketel en Leo Klaver zijn lid van de redactie van dit Vakblad
John Hermarij
John Hermarij is blogger (www.johnhermarij.nl), auteur en internationaal spreker over leiderschap in veranderende tijden. Voor meer informatie: www.dhirata.nl.
Evaluaties? Niet doen! Experimenteer!
De Tweede Kamer trakteert ons regelmatig op een parlementaire enquête. In zekere zin zijn dit de "moeders aller evaluaties." Ik voorspel met grote zekerheid dat over twintig jaar, wanneer de Lelylijn er eindelijk ligt, Kamerleden zich opnieuw zullen verbazen over hoe het toch weer zo uit de hand heeft kunnen lopen. Men zal concluderen dat we te maken hadden met onrealistische verwachtingen en kostenramingen, gebrekkig risicomanagement, slechte communicatie en samenwerking, politieke druk en haast, en gebrekkig toezicht en verantwoording. Het lijkt alsof we hier te maken hebben met Friedrich Nietzsche’s concept van de ‘eeuwige wederkeer’: we ontdekken telkens opnieuw hoe het zou moeten, maar blijken niet in staat tot blijvende verandering. Hoe is dit mogelijk?
Dingen die niet werken, trekken onze aandacht. Niemand maakt zich druk om een auto die rijdt, een kookplaat die verwarmt, of een trein die op tijd vertrekt. Alles wat goed gaat, is niet interessant. Pas wanneer er tegenslag is of risico’s zich manifesteren, gaan we onderzoeken waarom dat zo is en wat we eraan kunnen doen. Ik ken iemand die veel reisde en een lijst bijhield van alle spullen die hij ooit vergeten was in te pakken. Elk jaar werd zijn koffer zwaarder, terwijl hij het meeste daarvan nooit gebruikte. Hij wist precies wat er fout kon gaan, maar veel minder hoe hij met minder bagage goed voorbereid kon reizen.
Hier raken we de kern van mijn probleem met evaluaties. Wanneer iets ingewikkeld en complex is, heeft evalueren weinig zin. Wat is het anders dan achterafwijsheid? Iedereen kan dat. Na afloop heb je immers veel meer informatie dan tijdens de uitvoering van het project. Het is dan makkelijk om te zeggen: "als de projectmanager dit of dat had gedaan, was het goed gegaan." Maar iets beweren is iets anders dan bewijzen.
Evalueren is verworden tot een leeg ritueel. We koesteren de illusie dat we, door terug te kijken en fouten te identificeren, in de toekomst slimmer zullen zijn. Maar de realiteit is dat elke situatie uniek is, met eigen uitdagingen, actoren en omstandigheden. Evaluaties hebben de neiging ons in slaap te sussen met het idee dat we lessen hebben geleerd, terwijl de wereld om ons heen blijft veranderen op manieren die we niet kunnen voorspellen.
Wat als we zouden stoppen met evalueren en ons meer zouden richten op experimenteren? In plaats van achteraf te wijzen op wat fout ging, kunnen we beter voortijdig erkennen dat we niet alles weten en dat we leren door te doen. Dit vereist een verschuiving van een cultuur waarin we achteraf straffen en bekritiseren, naar een cultuur waarin we voortdurend leren, testen en aanpassen. We zouden minder tijd moeten steken in evaluatierapporten en meer in het verbeteren van ons vermogen om snel en flexibel te reageren op de realiteit van het moment.
Het is tijd om evaluaties los te laten. Niet omdat reflectie en leren onbelangrijk zijn, maar omdat ze ons beperken wanneer we ze alleen gebruiken om te kijken naar wat niet werkt. De grootste innovaties en successen zijn vaak het resultaat van een onbevangen blik vooruit, niet van een fixatie op wat er misging. We moeten stoppen met de illusie dat we de toekomst kunnen beheersen door het verleden eindeloos te analyseren. In plaats daarvan moeten we ons richten op experimenteren, leren in real-time, en onzekerheid omarmen als een natuurlijke staat van vooruitgang. De toekomst is geen perfect geoptimaliseerde herhaling van het verleden, maar een spannend en bovenal onvoorspelbaar avontuur. ●
Gesprek met Jeroen Venneman, voorzitter Agile Consortium
‘Je
kunt de agile werkwijze niet de schuld geven’
AUTEURS
EN
INTERVIEWERS:
RONALD KAPPERT & LEO KLAVER
Tijden veranderen. Bij de opkomst van het agile werken werd er afscheid genomen van veel projectmanagers. Op dit moment zien we steeds vaker dat bedrijven afscheid nemen van hun agile coaches. Hoe komt dat? ‘Het verwachte resultaat op organisatieniveau blijft te lang uit voor bedrijven, er wordt gezocht naar andere oplossingen’, zegt Jeroen Venneman, voorzitter Agile Consortium. Het lijkt erop dat de agile werkwijze de schuld krijgt voor tegenvallende resultaten. Maar mag je daar het agile gedachtengoed wel de schuld van geven? Jeroen Venneman geeft een reflectie op het agilegedachtengoed.
Behalve het uitblijven van het verwachte resultaat op organisatieniveau, zijn er nog twee andere redenen aan te wijzen voor het afscheid nemen van agile coaches door bedrijven. Jeroen Venneman ligt toe. ‘De agile werkwijze heeft gezorgd voor groei van autonomie in organisaties. Autonomie heeft minder specialisme in ‘management’ nodig. Agile coaches, scrummasters, release train engineers en ook product owners hebben bijgedragen aan de borging van deze autonomie in teams. Dat bedrijven vaker afscheid nemen van hun agile coaches komt omdat bedrijven die de agile werkwijze hebben omarmd continue verbetering vanuit de lijn willen oppakken. De coaching skill is geen specialisme meer, maar geborgd in de organisatie. Andere oorzaak is dat de problemen waar de bedrijven tegenaan lopen vragen om een volgende transformatiefase. Die gaat verder dan het beeld dat veel mensen hebben bij een agile werkwijze, waarin agile vaak een doel op zich is en niet is gekoppeld aan meetbare business resultaten.’
Jeroen Venneman geeft vervolgens een toelichting op de werkzaamheden van het Agile Consortium. Het bestuur bestaat uit vrijwilligers die eenzelfde passie delen: inspiratie brengen vanuit
het agile gedachtengoed. Het Agile consortium is onafhankelijk en heeft geen commerciële belangen. Met de organisatie van events, het faciliteren van werkgroepen en door invulling te geven aan het Certify to Inspire programma wordt een groeiende community ondersteund. Er is echter een verschuiving te zien binnen deze community omdat het animo voor een agile werkwijze bij bedrijven zienderogen afneemt. ‘Ja, dat klopt. Vanuit het Agile Consortium zien wij de behoefte aan agile afnemen en aan Business agility toenemen. We denken dan ook na over aanpassing van onze naam om daarmee de ondersteuning van de volgende transformatie fase vorm te geven. Zo zijn we eerder overgegaan van het DSDM consortium in het Agile Consortium.’
Wat zou voor de volgende fase een passende naam zijn? Iets als Hybride Consortium?
‘Wie weet, het wordt in ieder geval iets dat tot uitdrukking brengt dat het ons te doen is om de verbinding tussen Business en IT te faciliteren en vorm te geven. Om zo echt op organisatieniveau wendbaarheid en “flow” te realiseren. Andere mogelijkheden voor een passende naam naast hybride zijn dus flow, of business agility. We komen er wel uit.‘
Is agile an sich daarmee een gepasseerd station?
‘Bedrijven hebben jarenlang geïnvesteerd in het agile werken. De agile coaching skills en de kennis en ervaring met agile werken worden geacht aanwezig te zijn bij medewerkers die nu worden aangenomen op een bepaalde functie. Agile is een aanvullende skill aan het worden. Het ‘afvinken’ van de agile skill wordt veelal gedaan vanuit de aan- of afwezigheid van bepaalde agile certificeringen. Er zijn veel verschillende soorten agile certificeringen, met veel verschil in kwaliteit. Vooral als het gaat om het toetsen op skills. Het is goed om kritisch te kijken hoe certificering aan de toetsing op skills bij kan dragen.’
Dan doel je op wat het Agile Consortium en IPMA bieden aan certificeringsmogelijkheden?
‘Ja, dat zijn twee mooie voorbeelden. Het Agile Consortium biedt met de practitioner en master certificering een goede certificering gekoppeld aan skills en continu leren vanuit een community. Agile Consortium wil de beweging naar de eerdergenoemde volgende transformatiefase richting hybride, flow, business agility, of hoe je het ook wil noemen ook op het niveau van certificering ondersteunen. IPMA is een mooi voorbeeld van agile als aanvullende skill dat aan de projectmanagement certificeringen is gekoppeld. Hier hebben we vorig jaar op ingehaakt.’
Is er een toekomst zonder agile?
‘Voor sommige grote bedrijven die al lang met agile bezig zijn en nu afscheid nemen van onder meer agile coaches, is het juister om te zeggen dat de functie van agile coach, aan het afnemen is. Mensen die deze functie op hun visitekaartje hebben staan, al dan niet als zzp’er, vinden het steeds lastiger om een klus te vinden. Dat komt aan de ene kant doordat er steeds meer mensen zijn gekomen die deze functie op hun visitekaartje hebben gezet, maar ook omdat bedrijven minder
waarde toekennen aan wat deze functie hen brengt. De verwachte resultaten blijven voor hen te lang uit. Het label agile verliest aan kracht om de beweging in organisaties te brengen. In die zin is er een toekomst zonder agile denkbaar. Dat neemt niet weg dat de agile skills bij mensen die nodig zijn in organisaties die wendbaar willen zijn, nog steeds hard nodig zijn. Dit blijkt ook uit het artikel van het Business Agility Institute en de Agile Alliance: Skills in the New World of Work, Which Agile Skills are Most In-Demand in Today's Workforce? (https://businessagility.institute/ learn/skills-in-the-new-world-of-work/750).’
Agile is een aanvullende skill aan het worden
Waarmee je wilt zeggen dat er behoefte is aan “agile”-professionals die meer kunnen bieden dan alleen de agile werkwijze in praktijk te brengen? ‘Precies. De agile werkwijze heeft zich inmiddels afdoende bewezen daar waar het gaat om de ontwikkeling van software in meerdere teams. Daar is het prima voor geschikt. Maar binnen organisaties gebeurt er meer dan alleen software ontwikkelen. Een organisatie wil werken aan continuïteit, aan wendbaarheid, aan het versterken van het innovatief vermogen en het leveren van waarde. Dan is kennis van agile werken alleen niet voldoende. Een effectieve samenwerking moet er zijn tussen Business en IT, Agile Compli-
Jeroen Venneman, voorzitter Agile Consortium
ance, -Legal, -Risk, -Finance, -HR en -Marketing, en Governance. Dit zowel in een hybride omgeving als in omgevingen waar agile wordt gewerkt of meer traditioneel. Er is verbreding van kennis en ervaring nodig. Verbreding die je terugziet als een plus skill bij coaches en transformatie consultants, maar ook bijvoorbeeld bij de scrum master die data-kennis heeft, of ervaring in een hardware-omgeving. Kennis hoe effectief te coachen is ook nodig, maar bijvoorbeeld als plus bij een manager. Het is een combinatie van kennis die verder gaat dan T-shape. Het is een beweging naar Pi-shape zoals in het eerdergenoemde artikel wordt beschreven’.
En als die plus-combinatie van kennis in een organisatie aanwezig is, dan gaat het zo’n bedrijf voor de wind?
‘De plus-combinatie is zeker geen garantie, maar het is wel een enabler voor autonomie waardoor er meer betrokkenheid bij de samenwerking in teams op waarde kan zijn. Maar als een organisatie wendbaar wil zijn, dan is daar meer voor nodig. Wendbaarheid vraagt ook om een bepaalde mindset. Dat is een cultuurverandering waarbij het midden-management een belangrijke rol speelt. Die managers worstelen daar niet zelden mee, omdat dergelijke managers vanuit de top veranderdoelen meekrijgen die conflicterend kunnen zijn met de benodigde veranderbeweging. Het is dus niet zo eenvoudig.’
Hoe zit het dan met projectmanagement? Daarvan werd toch gezegd dat agile projectmanagers overbodig zou maken?
‘Ja, dat werd gezegd. Alles zou gerealiseerd kunnen worden via stabiele autonome teams en tijdelijke teams met één persoon verantwoordelijk voor het resultaat. Autonomie en alignment zouden ervoor zorgen dat de teams weten welke kant op te werken. Veel projectmanagers hebben als reactie daarop de functiebenamingen scrum master, release train engineers, coach, of product owner op hun visitekaartje laten zetten. Nu lijkt het erop alsof er weer een beweging de andere kant op gaat en dat projectmanagers weer meer worden gewaardeerd, omdat het een gevoel
Er
is een gereedschapskist nodig met daarin voldoende kennis om business agile te zijn. Daar hoort ook bij kennis en ervaring over compliance, legal, risk, finance, HR en marketing
van controle geeft als iemand duidelijk op het te realiseren resultaat is aan te spreken. De projectmanager met agile als plus skill is de verbeterslag hier. Het is dus zeker geen stap terug in de tijd. We hebben projectmanagers nodig die waardegericht zijn en afhankelijkheden goed kunnen managen in een hybride omgeving van agile en niet-agile werken. Bovendien gaat het er niet om wat er op het visitekaartje staat. Het gaat om de aanwezigheid van deze projectmanagement skills. Skills waarvan je wellicht denkt, die zijn ook goed toe te kennen aan een product owner. En dat is precies wat ik bedoel met het gaat niet om het visitekaartje, het gaat om de skills. Je kan goed agile werken met projectmanagers en niet-agile met product owners, het is belangrijk om te weten welke skills in welke context toe te passen.’
Zeg je dat het sturen op waarde te weinig vorm heeft gekregen vanuit het agile werken en dat daardoor het succes van agile op organisatieniveau is uitgebleven?
’Ja, dat is zeker één van de redenen. Het bereiken van het sturen op waarde vereist ook de eerdergenoemde bredere scope. Het gaat hier echt over een volgende fase waar het gereedschap agile vervangen moet worden door business agility waarin IT over het algemeen een belangrijk onderdeel is van de business.’
Business agility dus en niet alleen agile…
‘De vele afhankelijkheden in organisaties moet worden aangepakt. Dat vooral. Het wordt com-
plex in organisaties als afhankelijkheden over meerdere teams en projecten zijn verdeeld en er overzicht nodig is hoe de samenwerking in de teams is georganiseerd. Het betreft hier niet alleen IT teams als we het hebben over waarde creatie. Projectmanagement skills kunnen hier hun waarde bewijzen en bijdragen aan business agility. Obeya rooms, Objectives and Key Results (OKRs) en Quaterly Business Reviews (QBRs) kunnen helpen om overzicht en samenwerking op business niveau meer vorm te geven.’
Mag je agile de schuld geven als er geen waarde wordt aangetoond?
‘Dat hangt sterk af van wat jouw definitie van agile is. Voor velen is die scope beperkt omdat bijvoorbeeld het inrichten van een organisatie op waardestromen hier geen onderdeel van uitmaakt. Dan is de waarde beperkt tot dat wat teams en teams van teams samen opleveren. De samenwerking over de teams moet beter dan nu gestructureerd worden richting waarde creatie. Dat is de volgende stap die organisaties moeten zetten richting business agility. Die waarde creatie is in agile-omgevingen nu onvoldoende. Het topmanagement ziet dat er wel geld wordt uitgegeven aan coaches en consultants maar ziet niet de gewenste en verwachtte resultaten komen. De noodzaak voor de volgende transformatiefase met ook meer betrokkenheid van het management wordt vaak niet gezien in de agile werkwijze.’
Agile lijkt voorbij de hype. Wat is de nieuwe golf?
‘Het gaat steeds meer de hybride kant op, waarin agile werken naast projectmatig werken goed kan functioneren. Het gaat niet om het label agile of projectmatig, of een nog andere “taal”. Het gaat om wat je wil bereiken. Het doel is belangrijk en niet het middel. Dat gezegd hebbende, we hebben het vaak over hetzelfde, of het nu gaat over agile of over projectmanagement. In het projectmanagement taalgebruik duiden we een omvangrijk project aan de hand van gewenste functionaliteit, een epic dus. Als we zo’n groot brok opknippen in kleine stukken, met allemaal hun eigen features of feature sets, dan noemen we het weer agile. De governance via agile
portfolio management is weer heel herkenbaar vanuit projectmanagement. Veel dingen liggen heel dicht bij elkaar. Langdurige projecten zijn er steeds minder en het agile gedachtegoed van kort cyclisch wordt steeds meer omarmd. Dat dit agile gedachtegoed niet altijd aanwezig is in een omgeving die zegt agile te werken, blijkt uit het feit dat je regelmatig ziet dat werk bij agile teams makkelijk doorschuift van de ene sprint naar de andere en van het ene kwartaal naar het andere. Het kan dan lang duren voordat er echt waarde wordt opgeleverd.’
Is het management van nu wel goed toegerust voor business agility?
‘Een hybride aanpak die de verschillende manieren van werken met elkaar verbindt is er op veel plekken nog niet. Hierdoor is het lastig om samenwerking in de volle breedte van de organisatie vorm te geven. De complexiteit en onoverzichtelijkheid die hierdoor ontstaat zorgt voor een toenemende behoefte aan control binnen het bestuur. Het risico op terugvallen op command en control in plaats van groei van autonomie vanuit alignment ligt op de loer. Er is een combinatie nodig van agile en projectmanagement skills dat kan uitmonden in business agility. Dat is waar het binnen organisaties om draait of moet draaien. Er is een gemeenschappelijke taal nodig om deze weg af te lopen. En er is een gereedschapskist nodig met daarin voldoende kennis om business agile te zijn. Daar hoort ook bij kennis en ervaring over compliance, legal, risk, finance, HR en marketing. Het Consortium wil in dat proces een ondersteunende rol spelen en ja die gaat verder dan alleen een agile werkwijze.’ ●
Over de auteurs: Ronald Kappert en Leo Klaver zijn lid van de redactie van dit Vakblad
‘Elke reflectie op iets veronderstelt zowel een voorafgaande vertrouwdheid met de zaak als een zekere mate van vervreemding’
Ton Lemaire
‘I love the man that can smile in trouble, that can gather strength from distress, and grow brave by reflection’
Thomas Paine
‘Het niet onderzochte leven is het leven niet waard’
Socrates
‘De reflectie wordt het oog van de ziel genoemd’
Jacques Bénigne Bossuet (bisschop en schrijver)
‘It's good to reflect on life and take a step back and sit and relax and do something else’
Floor Jansen
‘Je leven is een weerspiegeling van je gedachten. Als je je gedachten verandert, verander je je leven’
Brian Tracy
‘Groei is stil, reflectie is zijn stem’
Bayu Prihandito
‘If there is time to reflect , slowing down is likely to be a good idea’
Daniel Kahneman
‘Zelfbewustzijn geeft je het vermogen om zowel van je fouten als je successen te leren’
Lawrence Bossidy
‘Volg effectieve actie met stille reflectie. Uit de stille reflectie zal nog effectievere actie voortkomen’
Peter F. Drucker
Leo Klaver
Leo Klaver is redactielid van dit Vakblad.
Traagheid Troef
Het menselijk brein kan maar een beperkt aantal beelden per seconde waarnemen. Niet dat er een harde onder- of bovengrens is, maar hou het er maar op dat een gemiddeld mens per seconde circa 15 beelden kan zien. De rest gaat aan het menselijk oog voorbij. Dat zegt overigens nog niets over de verwerking van deze beelden. Als een beeld een pagina uit een boek zou zijn, dan is de maximale te behapbare snelheid wellicht 10 minuten per beeld. Een mens zou eigenlijk een intern systeem moeten hebben dat aangeeft wanneer het brein weer nieuwe informatie kan ontvangen. Dat systeem is er niet en dus raakt het brein oververmoeid en gaat op enig moment volledig op slot: burned out.
De volgende vraag is dan natuurlijk: hoeveel informatie kan een mens eigenlijk behappen? Dat heeft bijvoorbeeld Thomas Landauer onderzocht. Hij kwam in 1989 tot de conclusie dat een gemiddelde volwassene in zijn leven ongeveer 125 megabyte aan informatie kan opslaan, dat is ongeveer wat in honderd dikke leesboeken staat. Onthouden we alle informatie die tot ons komt: nee. Mensen onthouden 10 procent van wat ze horen, 20 procent van wat ze lezen, 50 procent van wat ze doen en 100 procent van wat ze zelf ontdekken. Aan zelf doen en zelf ontdekken gaat echter voldoende lezen en voldoende luisteren aan vooraf. Het een kan niet zonder het ander en oefening baart kunst. Als je niet kunt luisteren en lezen, dan heeft al het overige geen zin, dan zul je niet veel zelf ontdekken.
Al dat lezen en luisteren en doen en ervaren en zelf doen, betekent voor een mens dat die per dag ongeveer 70.000 gedachten binnenkrijgt en ook moet verwerken. Dan worden snelheid en zeker ook nauwkeurigheid van belang. Als je te overhaast te werk gaat, kan je brein belangrijke details missen. Afbeeldingen zijn hier beter dan tekst. De mens verwerkt beelden 60.000 keer sneller dan tekst en 90 procent van de informatie die naar het brein wordt verzon-
den is visueel. De mens denkt dus vooral visueel. Maar ook beelden moeten verwerkt worden en omgezet in iets wat de moeite waard is. Nu zijn de meeste beelden leuk maar onnuttig. Maar sommige beelden zijn voor een individu de moeite waard om te onthouden of om er iets mee te doen. Dat afwegen heeft evenwel tijd nodig. Traagheid is voor de mens daarom een uiterst waardevol begrip dat helaas langzaam aan het uitsterven is. ‘Geef me zes uur om een boom om te hakken en ik zal de eerste vier uur bezig zijn met het slijpen van mijn bijl’, zei Abraham Lincoln ooit. Hij wilde daarmee uitdrukken dat er een balans moet zijn tussen het denken over hoe efficiënt te werken en het daadwerkelijk uitvoeren van de opdracht. Ofwel: er moet een balans zijn tussen traagheid en uitvoering.
Die balans komt steeds meer onder druk te staan. Er moet tegenwoordig altijd snel worden gehandeld en nagedacht. Producten en diensten moeten sneller dan de concurrent op de markt worden gepositioneerd. Informatie moet sneller tot ons komen, informatie moet sneller worden gegenereerd. Alles maar dan ook alles lijkt in een versnelling hoger te moeten. Inspelen op de toekomst moet sneller, sneller dan is ingespeeld op het verleden, zo lijkt. Maar het beoordelen van een situatie, een nieuwe gedachte, een nieuwe methode, een nieuwe techniek kost tijd, ofwel vraagt om de nodig traagheid. En dat terwijl AI de projectmanager noopt tot een verhoogde inzet van zijn of haar denken. Een fatbike-houding leidt weliswaar tot meer snelheid, een groter hype-gevoel, maar ook tot grote(re) ongelukken. De mens beschikt gelukkig ook over een systeem dat ons in staat stelt om dingen langzamer te doen. Meer informatie hierover is te vinden in het boek van Daniel Kahneman: Thinking, Fast and Slow.
Waarom dit alles gezegd: omdat de traagheidsgedachte bij mij naar boven kwam tijdens het luisteren naar de key-note van Richard van Hooijdonk tijdens de geslaagde KWD-Vakdag. Hij verhaalde over de mens in de toekomst. In drie kwartier kreeg ik mijn dagelijkse hoeveelheid van 100.000 woorden binnen. Dat is in onderzoek naar boven gekomen; een mens die 70 jaar leeft krijgt in totaal ongeveer 35 miljard woorden te verstouwen. Na de key-note had mijn brein rust nodig. Ik weet gelukkig hoe dat te doen: door je stressniveau te verlagen, door naar buiten te gaan en genieten van de natuur, door mij aan mijn hobby te wijden, door steeds minder tijd aan mijn smartphone te gunnen en door te bewegen. Onwillekeurig dacht ik aan de Nederlandse dichter Hendrik Marsman: Denkend aan Holland zie ik brede rivieren traag door oneindig laagland gaan. Later op de dag deed Ayca Szapora in haar key-note een korte mindfullness-oefening: oneindig gleed ik even door de tijd. Het bracht mijn brein tot rust en deed weer wat het moest doen: focussen.
Opdrachtgever, let op je veerkracht
AUTEURS: EDWIN VAN DIEËN EN NICO VERMEIJ
De statistieken die professor Flyvbjerg1 met enige regelmaat presenteert over de mate waarin projecten binnen de vooraf bepaalde kaders rond geld, tijd en scope succesvol afgerond worden spreken zeer heldere taal. Ongeveer een 0,5 procent van de projecten is volgens zijn cijfers nog succesvol. Ofwel, een opdrachtgever krijgt in 99,5 procent van de projecten een andere uitkomst dan vooraf bedacht en afgesproken. Een opdrachtgever moet dan ook beschikken over de nodige veerkracht om bij fikse tegenslagen in een project oplossingen te vinden. Hoe kan een opdrachtgever over veerkracht gaan beschikken? Voor projectmanagers is deze kennis ook van belang: zij moeten immers altijd met opdrachtgevers werken.
De mate waarin in projecten wordt afgeweken van vooraf opgestelde financiële kaders is indrukwekkend. Naar aanleiding van de nieuwe kostenraming voor de renovatie van het Binnenhof, haalde het Financieel Dagblad 2 nog even wat projecten voor het voetlicht ( zie tabel 1).
Geld is uiteraard niet het enige in projecten. Het gaat in projecten ook over tijd en scope. Nu is een tabel over de afwijkingen van projecten op
Tabel 1: voorbeelden kostenoverschrijdingen in projecten (in € miljoen)
financiën makkelijker te maken dan een tabel over afwijkingen in tijd en scope. Maar ook daar kunnen de afwijkingen groot zijn. Wat de afwijkingen ook precies mogen zijn, een opdrachtgever van een project heeft in de regel te maken met de nodige tegenslagen en moet dat kunnen opvangen met aanpassingen. Anders gezegd, een opdrachtgever moet over veerkracht kunnen beschikken. We definiëren hierbij het begrip veerkracht als: het vermogen van een opdrachtgever om zich aan te passen aan nieuwe omstandigheden om opdrachten alsnog op een goede manier te laten realiseren. Maar hoe krijg je dat als opdrachtgever?
Een opdrachtgever kan hier zowel een persoon zijn als een organisatie. De opdrachtgever als persoon heeft de rol de projectmanager aan te sturen. Hij of zij moet beslissingen nemen in het project, of moet de regisseur zijn van het besluitvormingsproces. Hij moet in deze rol kunnen handelen namens de gehele organisatie. Mocht dit laatste niet kunnen, dan zie je vaak een extra opdrachtgever verschijnen namens een ander deel.
Waar kan de opdrachtgever zijn veerkracht vandaan halen?
Een van de belangrijkste competenties waar een opdrachtgever over moet beschikken, is de competentie politiek handelen. Bij deze competentie
gaat het om het goed kunnen benutten van de krachtsbronnen middelen, relaties, kennis&slimheid en persoonlijke kracht.
Veerkracht uit middelen. Uit tabel 1 blijkt dat opdrachtgevers in projecten genoodzaakt kunnen worden om veel meer middelen in te zetten dan vooraf geraamd. Het is dan handig om over diepe zakken te kunnen beschikken om de benodigde financiële aanpassingen te kunnen doen. Bij middelen gaat het overigens niet altijd alleen om geld, het kan ook gaan om tijd, productiemiddelen, transportmiddelen en personeel.
Veerkracht uit relaties. Bij fikse tegenslag in een project hebben opdrachtgevers anderen nodig om oplossingen te vinden. Dit kunnen financiers zijn, zoals subsidiegevers, de Tweede Kamer, of beleggers. Het kan ook betekenen extra kennis moet worden verkregen, of hulp van leveranciers of vergunningverleners. Het lot van het project hangt als inzet van anderen nodig is af van de kracht van de reeds opgebouwde relaties. Als het mis gaat, is het meestal te laat om nog deze relaties te ontwikkelen. Het advies van Flyvbjerg aan opdrachtgevers is om bruggen te bouwen voordat die nodig zijn. Make friends and keep them friendly. Voor opdrachtgevers speelt dit advies in twee richtingen: je hebt bevriende relaties nodig om het project alsnog te kunnen laten afronden én je hebt binnen je organisatie
Competenties waarover opdrachtgevers moeten kunnen beschikken
vrienden nodig om je eigen positie als opdrachtgever te kunnen behouden. Opdrachtgevers moeten de belangrijke stakeholders binnen hun organisatie dus meenemen in de ontwikkelingen binnen de opdracht. Dit om informeel mandaat te kunnen behouden om namens de rol als opdrachtgever te kunnen blijven invullen.
Veerkracht uit kennis en slimheid. Het helpt enorm als opdrachtgevers kennis hebben van de relevante vakgebieden rond de opdracht. Bij tegenslagen is dan bekend in welke alternatieve richtingen mogelijke oplossingen gevonden kunnen worden. Deze kennis kan ook aanwezig zijn in personen die een opdrachtgever om zich heen heeft verzameld. Met gecombineerd analytisch vermogen is samen meer dan een paar zetten vooruit te denken, om zo tot nieuwe slimme strategieën te komen.
Veerkracht uit persoonlijke kracht. Een opdrachtgever is zelf ook een bron van veerkracht. Bij persoonlijke kracht gaat het allereerst om de formele positie die wordt ingenomen in de organisatie. Die positie bepaalt waar je binnen je organisatie zelfstandig over kunt beslissen. Is zelf een leverancier te selecteren? Is zelfstandig besluiten te nemen over inhoudelijke vraagstukken aangaande het project? Zijn medewerkers door de opdrachtgever te verplaatsen over de teams? Waar het bij de veerkracht uit relaties gaat om het informele mandaat, bij persoonlijke kracht gaat het om het formele mandaat.
Persoonlijke kracht gaat ook over hoeveel werk je aankunt. Als een opdrachtgever een werkdag kan verlengen van 8 naar 16 uur, dan zijn extra vraagstukken goed aan te pakken binnen de geldende deadline van het project.
Veerkracht is voor een opdrachtgever onmisbaar.
Binnen opdrachten ontstaan tegenslagen als vanzelf.
Niet alles lukt zoals vooraf bedacht
Misschien wel het belangrijkste aspect bij persoonlijke kracht is de geestelijke veerkracht. Hoe goed kan een opdrachtgever mentaal omgaan met tegenslagen? Is nog steeds met mildheid en mededogen te acteren? Kan een opdrachtgever in een ontspannen modus blijven werken ook als er druk is? Neuropsycholoog Rick Hanson geeft in zijn boek Veerkracht3 een handleiding hoe door innerlijke rust veerkracht te vergroten. Uit zijn onderzoek blijkt dat hersenen te trainen zijn in het veerkrachtiger worden door het benutten van eerdere ervaringen waarin tegenslagen goed zijn overwonnen. Ook het gevoel van zeggenschap over de loop der dingen is te vergroten door
Edwin van Dieën
bewust te focussen op de zaken waar je als mens wel invloed op hebt. In managementkringen is de link met de theorie rond de cirkel van invloed en de cirkel van betrokkenheid dan al snel gelegd.
Resumerend
Veerkracht is voor een opdrachtgever onmisbaar. Binnen opdrachten ontstaan tegenslagen als vanzelf. Niet alles lukt zoals vooraf bedacht. Het loont daarom voor opdrachtgevers de moeite om te investeren in de eigen veerkracht. Het gaat dan om het vinden van een goede balans in de aandacht voor relaties, het hebben van de juiste middelen, kennis, en persoonlijke kracht,
Het helpt enorm als opdrachtgevers kennis hebben van de relevante vakgebieden rond de opdracht
om met dit alles de juiste interventies te kunnen doen. Opdrachtgevers moeten ruimte creëren om veerkracht bij te kunnen “tanken” zodat ze er kunnen staan als het er echt op aan komt. Opdrachtgevers die investeren om daar beter in te worden is, onderscheiden zich in de regel van de middelmaat. ●
Kopje?
1. Flyvbjerg B. & Gardner D. (2023). How big things get done. London, Macmillan, p 189
2. https://fd.nl/samenleving/1515074/ budgetoverschrijdingen-bij-grote-projecten-eerderregel-dan-uitzondering geraadpleegd op 1 juni 2024
3. Hanson, R. (2019). Veerkracht. Een handleiding voor innerlijke rust, kracht en geluk. Utrecht, Ten Have
Edwin van Dieën is manager bij de gemeente Dordrecht, Nico Vermeij is oprichter van Promi bv. Ze zijn lid van de interessegroep ‘Goed opdrachtgeverschap’ van IPMA. Dit artikel is gebaseerd op hun bijdrage aan de IPMA-vakdag op 29 mei 2024.
Nico Vermeij
Improving team and workplace dynamics through understanding biases and love languages
Eind 2024 organiseerde Agile Consortium een event, over het onderwerp ʻImproving team and workplace dynamics through understanding biases and love languagesʼ. Improve ICT in Eindhoven trad op als host van het event. Samen met sprekers Robert van Lieshout, Linda van de Gevel en Sophie van der Mierden maakten deelnemers op interactieve wijze kennis met dit onderwerpen.
Stabiele teams en de onderstroom
Stabiele teams streven naar het leveren van steeds meer waarde en borgen dit met name in de bovenstroom. Veel organisaties geven onvoldoende aandacht aan de onderstroom. Het leren begrijpen van elkaars drijfveren en overtuigingen dragen bij aan het behalende van de gewenste effectiviteit en resultaten. Dat heeft dan ook geleid tot het verbinden van een enthousiaste groep van professionals die samen zijn gaan interacteren en leren.
Bewustwording
Biases zijn essentiële, mentale shortcuts die onze besluitvorming beïnvloeden, vaak onbewust. Wat betreft de vijf love languages: iedereen heeft een voorkeurstaal, denk aan waardering en erkenning (bv. woorden, daden, tijd). Bij beide onderwerpen kun je in teams starten met bewustwording.
Communicatie en begrip
In de praktijk hebben we veel verwachtingen en onvervulde
behoeften, zowel op persoonlijk als professioneel vlak. Door misalignment en miscommunicatie kunnen er serieuze spanningen ontstaan die het functioneren van teams negatief beïnvloeden.
Verbinding
Door in teams de verschillende talen en biases te begrijpen kunnen mensen sterkere verbindingen leggen en aan hun onderlinge relatie werken. Daarbij wordt het makkelijker om onbewust ongewenst gedrag te vermijden. Zo ontstaat er meer respect en begrip in het team.
Praktische tips
Als informeel leider, coach of Scrum master kun je denken aan het spiegelen in spannende situaties, het organiseren van een team retrospective. En kun je inzichten bieden die teamleden naar meer begrip en verbinding kunnen leiden. Effectieve facilitatie is hierbij essentieel. Om te kunnen leren moet je vertragen. Veel biases vinden plaats ‘in the heat of the moment’. Zorg ervoor dat je
de rust inbouwt om te kunnen reflecteren.
Over events van het Agile Consortium
Vanuit het Agile Consortium is er veel aandacht voor de agile communities in Nederland. Zo houdt een deel van het bestuur zich ook bezig met de vertegenwoordiging van jonger publiek in Nederland: Chiel van Ewijk, Thijs Assmann, Nathalie Hezemans en Ivo Heijtel. Gezamenlijk zetten zij in op het organiseren van een aantal events per jaar bij een variëteit aan organisaties. Bijvoorbeeld bij consultancybureaus die zich actief met agility bezig houden, zoals Strict en Improve ICT, alsook bedrijven die een transformatie doorgemaakt hebben, zoals ABN Amro en De Nationale Politie.
Ben jij geïnteresseerd en geënthousiasmeerd? Meld je dan aan voor onze nieuwsbrief voor updates over onze volgende events op https://www. agileconsortium.nl/newsletters/
BOEKRECENSIE AUTEUR: HENNY PORTMAN
Waardevolle Agile Retrospectives
Ben Linders en Luis Gonçalves hebben een compact en praktisch boek geschreven, “Waardevolle Agile Retrospectives, een gereedschapskist met retrospective oefeningen”. Het boek, oorspronkelijk getiteld “Getting Value out of Agile Retrospectives”, is in meerdere talen beschikbaar. Hoewel het al wat ouder is, blijft het nog steeds relevant en sluit het goed aan bij het thema reflectie.
In de eerste paragrafen geven de auteurs een definitie van een retrospective, leggen ze uit waarom retrospectives belangrijk zijn, en hoe ze waarde kunnen toevoegen aan teams. Ze benoemen ook de randvoorwaarden die nodig zijn om een effectieve retrospective te kunnen uitvoeren. Het hart van het boek gaat over het ontwerpen van retrospectives en bevat diverse oefeningen die teams kunnen gebruiken.
De definitie van een retrospective volgens de auteurs luidt: "Een manier voor teams om hun werkwijze te evalueren en voortdurend beter te worden in wat ze doen." Het doel van retrospectives is, aldus de auteurs, "het vormen en versterken van teams, waardoor je organisatie sneller, efficiënter en innovatiever wordt."
Om met retrospectives echt waarde te creëren, raden de schrijvers aan om een aantal maatregelen te nemen:
● Versterk teams
● Stimuleer leren en het ontwikkelen van wederzijds begrip
● Beperk obstakels
● Hanteer de gouden regels voor procesverbetering
● Focus op duidelijk gedefinieerde problemen
● Maak gebruik van oorzaak-gevolganalyses
● Volg verbeteracties nauwgezet op
● Varieer met verschillende oefeningen
De randvoorwaarden voor het uitvoeren van een retrospective zijn gebaseerd op het boek *Project Retrospectives* van Norman Kerth. Deze voorwaarden omvatten de noodzaak van rituelen, het benoemen van het proces, het uitspreken van de 'Prime Directive voor retrospectives', het vermijden van klaagsessies (de "duistere kant" van retrospectives), en het belang van een bekwame facilitator voor de retrospective.
Voor de structuur van een retrospective volgen de auteurs de vijf stappen die zijn beschreven door Esther Derby en Diana Larsen in hun boek *Agile Retrospectives*. Deze stappen zijn:
1. Het speelveld bepalen
2. Data verzamelen
3. Inzichten creëren
4. Acties definiëren
5. Afsluiten
Door het gebruik van verschillende oefeningen, afgestemd op het specifieke doel dat je wilt bereiken, kun je de meeste waarde uit een retrospective halen.
Het boek biedt een breed scala aan oefeningen. Voor elke oefening wordt aangegeven wat de verwachte resultaten zijn, in welke situaties de oefening het meest effectief is, en hoe deze uitgevoerd kan worden. Enkele van de toegelichte oefeningen zijn:
● Vragen stellen
● De Zeester (Stop, Minder, Behouden, Meer, Start)
● De Zeilboot (doel/visie, risico’s, vertragingen, wat helpt om het doel te bereiken)
● Woord retrospective (hoe je je voelt)
● Automerk (de iteratie vergelijken met een automerk)
● Retrospective van retrospectives (voor meerdere teams)
Het boek sluit af met een paragraaf over de voordelen van retrospectives en hoe je eventueel product owners en klanten kunt betrekken, evenals een hoofdstuk over de invoering van retrospectives in je organisatie.
Conclusie
Waardevolle Agile Retrospectives biedt een compacte en praktische leidraad voor het uitvoeren van retrospectives. Het boek introduceert niet alleen de structuur van een retrospective, gebaseerd op de vijf stappen van Esther Derby en Diana Larsen, maar geeft ook een breed scala aan oefeningen, variërend van de Zeester tot de Waardestroomanalyse. Deze oefeningen helpen teams om hun werkwijzen continu te verbeteren en bieden agile coaches, scrum masters en projectmanagers concrete handvatten om retrospectives effectief in te zetten.
Door verschillende oefeningen in te zetten, afgestemd op specifieke doelen, kunnen teams maximale waarde uit hun retrospectives halen. Dit wordt verder ondersteund door de gegeven randvoorwaarden, zoals het vermijden van klaagsessies en het zorgvuldig inzetten van een facilitator. Het boek benadrukt het belang van reflectie voor het versterken van teams en het verbeteren van processen.
Aanbevolen voor agile coaches, scrum masters en projectmanagers die na het lezen van dit boek retrospectives de aandacht kunnen geven die ze verdienen en hun gereedschapskist met een scala aan oefeningen kunnen uitbreiden. ●
Henny Portman is blogger/recensent (hennyportman.wordexpress.com), auteur, internationaal spreker, consultant en eigenaar van Portman PM(O) Consultancy
Gesprek met Paul Iske, Instituut voor Briljante Mislukkingen
‘Een fout verdient vergeving. Een Briljante Mislukking verdient waardering’
Het Instituut voor Briljante Mislukkingen is opgericht in 2010 door prof. dr. Paul Louis Iske. Hij wil met zijn team aan ondernemers en organisaties laten zien dat falen in projecten zeker een optie is. Echt? ‘Ja, we laten zien dat en hoe ze van mislukkingen kunnen leren. Mislukken moet je als fenomeen waarderen zeker als het gaat om Briljante Mislukkingen’. Om dat te kunnen doen moet men op eigen projecten reflecteren. Paul Iske vertelt hoe dit te doen aan de hand van 16 archetypen. Eind november van dit jaar reikte het Instituut voor Briljante Mislukkingen overigens de Briljante Mislukkingen Award 2024 uit voor projecten in de zorg. Dit was de 10e keer dat dit gebeurde met Ministerie van VWS, de Zorgautoriteit, het Zorginstituut en ZonMw als partners.
INTERVIEWERS EN AUTEURS: ANNET HOLTROP & LEO KLAVER
Tijdens de IPMA-Vakdag heb je een lezing gehouden in de hoedanigheid van Chief Failure Office. Prachtige titel, dan heb je zeker ook wel een gedachte over wat falen is…. ‘Ik heb overal een mening over. En zelfs daar heb ik een mening over’, trapt Paul Iske het gesprek af. Hij trekt met anderen het Instituut voor Briljante Mislukkingen en is deeltijdhoogleraar in Maastricht en Stellenbosch, een universiteitsstadje dichtbij Kaapstad, Zuid-Afrika. ‘De laatste
keer dat ik er was kwam de wind uit het zuiden en was het er steenkoud. De volgende morgen waaide het uit het noorden, was het 25 graden en kon ik in zee met de pinguïns spelen. Het weer varieert enorm daar. Het is net een project dat alle kanten uitgaat.’
Maar het klimaat kan niet falen of mislukken... ‘Klopt, je kunt hoogstens zeggen dat het weer altijd anders is en dat je daar dus nooit op
uitgekeken en uitgestudeerd raakt, net zoals dat in projecten overigens het geval is. Wat dat betreft was ik verrast toen ik deze titel van een KWD-boek las: Nul Mislukkingen voor business owners. Ik snap dat het vooral een wens is die met deze titel door KWD wordt uitgesproken, maar die wens moet je helemaal niet hebben, omdat je dan waarschijnlijk dingen laat liggen die je beter wel had kunnen doen. Als je in projecten zegt: dit en dat doe ik niet, daar begin ik niet aan, want het zou wel eens kunnen uitdraaien op een mislukking, dan ben je bezig om alle innovatiekansen in het project de nek om te draaien. En dan doe je ook de werkelijkheid geweld aan: want het is de normaalste zaak van de wereld dat er af en toe wel eens iets niet lukt.’
En dan is natuurlijk de vraag: wat te doen met deze werkelijkheid?
‘Precies. Het beste is hetgeen niet helemaal goed is gegaan te bezien, als een soort resultaat in de vorm van ervaring dat je mee kunt nemen naar volgende projecten. Dergelijke ervaringen zijn zeer waardevol en daarom noemen wij ze ook Briljante Mislukkingen, omdat ook dan een stap voorwaarts is gemaakt. Dat is voor mij een goede definitie van succes: een of meer stappen vooruitzetten.’
Heb je mooi voorbeeld van een Briljante Mislukking waarmee iets is gedaan?
‘Een voorbeeld van een briljante mislukking is de eerste Elf Stedentocht die Maarten van der Weijden ging zwemmen. Het was eigenlijk een experiment en is briljant mislukt. Hij heeft die eerste keer veel geleerd, over eten, over het tijdstip -in augustus was het water veel te warm, over beter slapen, over mentale steun, over de beste bril in het water. Als het hem was gelukt, had ik vijf euro overgemaakt, maar nu vond ik het zo sneu dat ik vijftig euro heb gestort. De tweede keer heeft hij alle kennis van zijn eerste poging
gebruikt en toen haalde hij het wel. Toen heb ik vijftig euro overgemaakt, want hij had het toch maar mooi geflikt na die briljante mislukking de eerste keer.’
Probleem met wat ervaring betreft is natuurlijk wel dat elk project uniek is en dat het vrij lastig kan zijn om gebruik te maken van eerder opgedane ervaringen.
‘Wij hebben in ons instituut de faal-ervaringen in projecten gebundeld in 16 archetypen. Daarmee kun je kijken welke factoren aan falen ten grondslag kunnen liggen. Door die patronen in projecten te herkennen kun je de omvang van mislukkingen verminderen. Deze aanpak is wezenlijk anders dan de meeste post mortem evaluaties of action reviews of evaluaties, of hoe je het ook wilt noemen. Ik zie dat in dergelijke evaluaties werkelijk alle details worden meegenomen in een soort van poging om de schepping van de aarde opnieuw te beleven. Dat kan nuttig zijn om dieper in een project te duiken, maar je leert er niet van hoe het in een volgend project beter en slimmer te doen.’
Noem eens een faalarchetype?
‘Een veel voorkomende mislukfactor is ‘De lege plek aan tafel.’ Als daarvan sprake is wordt in een project besluiten genomen zonder daarbij alle betrokkenen mee te nemen. Ik heb een groot programma in de zorgsector geëvalueerd waarin werd gewerkt aan een nieuwe vergoedingssystematiek voor langdurige psychische zorg. Alle partijen waren daarbij betrokken en toch werd een paar dagen voordat de systematiek zou worden gepresenteerd de stekker uit dit project getrokken. Wat bleek: een vertegenwoordiger van een partij bleek niet het mandaat te hebben van zijn achterban om ja tegen het voorstel te zeggen.’
Nog een….
Misschien zie je eerder de Canyons of de Junk
‘Die heet de ‘Duikers van Acapulco’. U ziet dat we de archetypen hebben voorzien van aansprekende benamingen. In Acapulco zijn er mensen die van grote hoogten, zeg 40 meter vanaf een klif in de golven springen. Dat geeft hun een kik. Springen moeten ze doen op het moment doen dat de golf onder hen het hoogst
is en zij dus de kortste afstand tussen klif en golf kunnen afleggen. Is de timing verkeerd, dan zijn ze seconden langer onderweg en komen ze veel harder in aanraking met de golf en komen ze met barstende hoofdpijn weer boven water. Timing is ook in projecten van cruciaal belang. Je kunt nog zo’n mooi idee hebben, maar het project moet ook op het goede moment komen om het in vruchtbare grond te laten ontkiemen. Een goed idee komt ook op het juiste moment. Alle faal-archetypen tezamen is te zien als een soort van risico-managementaanpak. Door de archetypen te bestuderen en toe te passen, is het nodige aan mislukken te voorkomen. Gaat het dan toch nog mis, dan is er wellicht sprake van een nieuw archetype die aan het geheel moet worden toegevoegd. Ik ben daar altijd naar op zoek.’
Wat vind je het mooiste archetype?
‘Misschien is dat wel ‘De Brug van Honduras’. In dat land stroomde een rivier en daar werd een brug over gebouwd. Prachtige brug, totdat orkaan Mitch in 1998 langskwam. Die veranderde de loop van de rivierbedding waardoor de brug ineens 400 meter verderop kwam te liggen en geen functie meer had. Dat zie je in projecten ook vaak: het probleem heeft zich verplaatst. Dat is bijvoorbeeld ook te zien na de invoering van statiegeld op blikjes etc. In het uitbetaald krijgen van 15 cent statiegeld zijn, zo blijkt, vooral mensen geïnteresseerd die op de kleintjes moeten letten. Die halen die blikjes uit de bakken waardoor rondom de bakken rommel ontstaat, terwijl de vieze blikjes en flessen uit de bakken er ook nog eens ervoor zorgen dat de apparaten die de blikjes en flessen in ontvangst moeten nemen niet goed meer werken. Het probleem heeft zich met andere woorden verplaatst en er is een nieuw probleem ontstaan.’
Het gaat hier te ver om alle 16 archetypen te behandelen.
‘Zeker, kijk daarvoor op onze website, maar deze wil ik ook graag nog even noemen: De Junk. Deze laat zien dat projectmanagers niet zelden te lang doorgaan met een project waarvan een blind paard kan zien dat het niets wordt. Het is hun baby geworden, waar ze geen afstand van kunnen nemen omdat ze er al zoveel tijd en aandacht
Reflecteren is voor mij dat je voordat je aan een project begint nadenkt over zaken die verkeerd zouden kunnen gaan
aan hebben besteed. En dan ook nog even deze: het ‘Verkeerde portemonnee’ archetype. Dat is het fenomeen waarin in een project gewerkt wordt aan een oplossing waarvoor de een moet betalen, maar waarvan een ander de vruchten plukt. Dat is de reden waarom preventieprojecten vaak mislukken omdat het moeilijk is aan te tonen dat degene die investeert ook degene is die profiteert. Het herkennen van al deze archetypen in projecten is aan te duiden als ‘single learning’. Als vervolgens de kennis daarvan wordt meegenomen naar andere projecten, dan is dat aan te duiden met ‘double’ learning.’
Kan een dergelijk leerproces worden ondervangen door Kunstmatige Intelligentie in te zetten?
‘AI staat wat mij betreft voor Aanvullende of Assisterende Intelligentie, die alleen maar goed kan worden ingezet als het gebruik kan maken van goede data. Dergelijke data is lang niet altijd aanwezig. Projecten mislukken niet zelden doordat er een gebrek is aan consistente en kwalitatief goede data waardoor er geen goede relatie te leggen is tussen strategie en de doelstelling van het project. In dat soort gevallen worden projecten opgezet omdat het kan en niet omdat het moet. De genoemde 16 faalfactoren kunnen ook helpen om relevante data te verzamelen waarmee risico’s zijn te minimaliseren. Zelf hebben we 250 projecten die zijn mislukt, geanalyseerd aan de hand van twee zaken: welke faalpatronen hebben een rol gespeeld en wat waren de grootste leerkansen.’
Blijft natuurlijk wel dat we als mens niet overal invloed op kunnen uitoefenen. Covid-19 is hier een mooi voorbeeld.
‘Zeker zijn er zaken waar je geen invloed op hebt, maar die wel invloed op jou hebben. Een sponsor kan plotseling van het toneel verdwijnen, een reorganisatie kan roet in het eten gooien, een project kan om politieke redenen een hele lange looptijd hebben. Dat laatste is het geval bij een groot programma op het Europese spoor dat als doel heeft alle management- en veiligheidssystemen op het spoor en in de treinen te moderniseren en harmoniseren. Een miljardeninvestering en een enorm complex project dat vanaf het begin eigenlijk al gedoemd was om met problemen te worden geconfronteerd. In het projectplan staat namelijk dat het project ruim 10 jaar gaat duren. Maar in zo’n lange tijd kan er veel veranderen, ook qua technologie. Dit zijn de ‘Zwarte Zwanen’ in een project. Organisaties kunnen als een project te lang gaat duren ineens veranderen of zelfs verdwijnen.’
Dus met de archetypen kun je goed reflecteren, vooraf en achteraf?
‘Patronen in projecten kun je gebruiken om richting te kiezen. Waar moeten we eigenlijk naar toe? Waar zitten de meeste en waardevolste leermomenten in een project? Door voortdurend als projectmanager bedacht te zijn op faalpatronen, krijg je op den duur daar een zesde zintuig voor. Dan zie je snel dat er voor een op zich prachtig idee is, geen afdoende middelen zijn om het uit te voeren. Dan zie je ook als er te veel middelen zijn en er daardoor niet geoptimaliseerd gaat worden. Als je met de archetypen goed naar projecten kunt kijken, zie je de essentiële zaken scherper.’
Is reflectie ook nodig in agileprojecten, waarin in kleine stapjes voorwaartse beweging wordt gecreëerd? Dan gaat toch alles vanzelf goed?
‘Keep on dreaming. Agile sluit in software-ontwikkelprojecten goed aan bij de 16 archetypen. Je kunt snel naar een stap kijken en besluiten
Paul Iske, Instituut voor Briljante Mislukkingen
om niet of anders door te gaan. Mijn punt is dat reflectie je een kans biedt om te leren als iets in projecten niet helemaal gaat zoals je dat had gewild. Waarbij ik hier ook gezegd wil hebben dat ik zeker niet vies ben van successen of van projecten waarin alles perfect verloopt. Als ik op vakantie ga en het is mooi weer en natuur prachtig, dan geniet ik daar immens van.’
Kun je als projectmanager altijd aan de gewenste knoppen draaien om optimaal resultaat te boeken, dit in de breedste zin van het woord?
‘Nee, natuurlijk niet. Soms kun je alleen maar drukken op een knop die wel beschikbaar is. Ik heb ooit aan een project gewerkt waarin het bonussysteem projecten de verkeerde kant op duwde. Dan heb je als enige knop dat systeem maar even buiten werking gaat zetten. Als projectmanager moet je nu eenmaal af en toe georganiseerde domheid tackelen met georganiseerde slimheid. Kijk, het hele leven hangt aan elkaar van twee dingen: dingen die belangrijk zijn en dingen die urgent zijn. In een organisatie kan het urgent zijn om voortdurend brandjes te blussen, maar er moet ook een moment komen waarin de organisatie aandacht laat uitgaan naar dingen die belangrijk zijn. Dan heb je wel een visionair nodig die zegt: ik vind het gewoon dom wat we aan het doen zijn. En ik wil niet dom zijn. Je moet slim en leuk kunnen werken, anders hou je het niet vol. We noemen dat intern SLB ofwel Slimmer Leuk Buffelen.’
Is dat ook een
archetype.
‘Ja en heet ‘Einstein’. Die heeft gezegd dat je dingen zo simpel mogelijk moet maken. Niet dom, maar zo simpel mogelijk. Ik zie vaak dat mensen veel zaken gewoon te ingewikkeld maken, inclusief onderliggende systemen. Ik kan met een bijna aan zekerheid grenzende zekerheid zeggen dat het gros van zogenaamde leiders in organisatie de complexiteit daarin niet kunnen doorgronden en er dus ook geen rekening mee kunnen houden. En dan loopt de vertaalslag van idee naar uitvoering, inclusief de communicatie met stakeholders in de soep. Dat soort leiders laat de organisatie en de mensen die daarin werken in grote verwarring en wanhoop achter.
Dit is voor mij een goede definitie van succes: een of meer stappen vooruitzetten
Een goede leider neemt tijdig afstand van een project en neemt ook de moeite om ergens wat extra tijd en energie in te stoppen in de vorm van extra bijscholing of extra investering. Maar ja, de werkelijkheid is dat er in organisaties heel veel Canyons zitten, ook een archetype. Dan is er sprake van veel ingesleten patronen. Mensen doen dingen vaak op eenzelfde manier en dat werkt dan prima, maar dan zien ze niet meer dat er ook andere methoden of werkwijzen zijn die veel beter kunnen werken en minder risico’s in zich dragen. Je kunt heel hard werken en dan toch het bedrijf kopje onder zien gaan. BCC en Kodak zijn hier de mooie voorbeelden. Reflecteren is voor mij dat je voordat je aan een project begint nadenkt over zaken die verkeerd zouden kunnen gaan. Misschien zie je dan ook veel eerder bijvoorbeeld de Canyons in een organisatie of de Junks, of….’
Ik heb je in dit gesprek nog niet het woord fout horen gebruiken. Dat is opmerkelijk.
‘Ja, het gaat ook niet om fouten, het gaat om mislukkingen. Tegen een kind dat leert lopen en dat valt daar zeg je ook niet goh, je hebt een fout gemaakt. Ieder stapje is voor een kind een stukje informatie om mee te nemen richting volgende stap. Je kunt verder niet alles van tevoren weten, zeker niet in een maatschappij die steeds complexer wordt. Dat moet evenwel niet betekenen dat je dan maar niets doet. Begin gewoon en dan zie je gaandeweg wel wat niet kan en wat beter, maar je moet wel blijven nadenken. Daarbij helpen de 16 archetypen. Verder moet je plezier hebben in het boeken van vooruitgang, hoe die vooruitgang ook gaat. Ook een Briljante Mislukking moet met plezier tot stand komen en moet gezien worden als een stap vooruit in plaats van achteruit. Een fout verdient vergeving en een Briljante Mislukking verdient waardering.’ ●
De ervaringen van Karel worden niet opgepakt in een complex programma
Als Karel als IT-projectmanager van start gaat in een lopende omvangrijke SAP implementatie wordt het traject bestuurd door een groot SAP consultancybedrijf (Sure). De implementatie vindt plaats in een organisatie met een groot applicatielandschap. Sure is door een ander consultancybedrijf (Better) ingeschakeld voor de implementatie van Salesforce en van de integratiemiddleware. De implementatie omvat 150 integraties tussen data aanleverende en data verwerkende apps. Het geheel moet onder controle worden gebracht: de integratietesten gaan binnenkort starten. Karel krijgt als opdracht de integratie tussen data aanleverende en data verwerkende apps binnen het programma te realiseren.
Hij stelt vast dat er naast Sure en Better ook nog 19 apps DevOps teams betrokken zijn in het programma. Deze teams hadden moeten worden aangesloten op het programma, maar dat is nog niet gebeurd. Deze teams en achterliggende leveranciers zijn daardoor niet op de hoogte van de aanpak en planning van het programma. Hij stelt ook vast dat de 150 te realiseren integraties qua voortgang hopeloos achterlopen op de planning.
Om de integratie weer goed op de rails te krijgen, zoekt Karel direct contact met het programmamanagement. Hij stelt deze vraag: ‘Wat is het plan om de geplande integratietest uit te voeren?’ Hij vraagt in detail ook naar teststrategie, testaanpak, testdekking en testscenario’s waaruit blijkt welke processen moeten worden 'afgetest'.
Het programmamanagementteam weet geen antwoord op al deze vragen te geven.
Karel vraagt door en wil de beschrijving van de toekomstige processen die door SAP en de verschillende omliggende applicaties moeten worden ondersteund. Deze beschrijvingen zijn, zo blijkt, twee maanden voor de integratietest nog lang niet op het gewenste detailniveau dat nodig is om de processen adequaat te kunnen testen.
Als ook het datamanagement-team aankondigt niet in staat te zijn om een productie-afslag master data aan te leveren voor aanvang van de SIT, geeft Karel het advies om de integratietest uit te stellen. Dit om tijd te hebben om eerst zaken op te lossen, zoals een betere procesbeschrijving en het op orde brengen de kwaliteit van de master data.
Wie is Karel?
Karel is een ervaren senior projectmanager die model staat voor de projectmanagers zoals die binnen KWD aan uitdagende en complexe projecten werken. Je kunt Karel zomaar
tegenkomen bij KWD, maar draagt dan wel een andere naam. Karel vertelt in dit Vakblad wat hij tegenkomt als project- en programmamanager in complexe projecten
Stub
Leverancier Sure voelt zich niet verantwoordelijk voor de integratietesten, omdat dit niet vastgelegd is in het contract. Het bedrijf neemt de positie in dat op tijd gestart kon worden met de geplande integratietesten op basis van ‘stubs’. Met een stub kan je integraties simuleren. Onder druk van de leverancier kiest het senior programmamanagement voor het handhaven van de planning. Karel denkt er het zijne van en weet uit ervaring: dat gaat dus niet goed.
De integratietest duurde uiteindelijk ongeveer negen maanden langer dan verwacht omdat integraties niet gereed waren, omdat de betreffende leveranciers nog gecontracteerd moesten worden en het werk nog ingepland moest worden. Voor de masterdata werd besloten om handmatig data aan te maken van een set gebaseerd op de 20 grootste klanten met alle onderliggende master data. Met deze set, die niet representatief was, verliepen alle testscenario’s naar wens. Prachtig, dacht Karel en wist: dat gaat dus weer niet goed.
Na de lange integratietesten kon eindelijk een aanvang gemaakt worden met de gebruikersacceptatietesten. Ook dit duurde veel langer dan gepland. De oorzaak was hetzelfde als wat Karel al eerder had aangegeven bij de datasets: de proceswijzigingen waren onvoldoende gedetailleerd overeengekomen en vastgelegd in design documenten. Uiteindelijk duurde het nogmaals
negen maanden voordat de acceptatietesten konden worden herstart. Ze moesten ook nog eens verlengd worden omdat de master data aan het begin niet kon worden aangeleverd.
Ontslagen
Pakweg twee jaar na de start van de integratietesten wist het bedrijf nog steeds niet hoe de ‘to-be state’ eruit zou komen te zien. De go-live datum was inmiddels twee jaar verschoven. De gehele gang van zaken was een drama voor dit bedrijf. De CIO, de CEO, de COO en de MT-laag werden ontslagen.
Karel had hard gewerkt om het programma in goed banen te leiden. Hij had duidelijk besproken en vastgelegd met het programmamanagement wat volgens zijn ervaring moest gebeuren. Onder druk van de leveranciers en andere stakeholders koos het bedrijf toch elke keer voor een halve oplossing.
De programmaleiding had, zo had Karel het management op grond van zijn ervaring laten weten, tijd en resources moeten vrijmaken om de procesveranderingen eerst op detailniveau vast te leggen. Dat had de weg vrijgemaakt om eisen en wensen vast te stellen om daarmee functionele, non-functionele en technische requirements op te kunnen stellen. Idem was dat opgegaan voor de logische en fysieke dataobjecten die leiden tot een logisch- en fysiek datamodel.
Met dit inzicht had de teststrategie (governance, testdekking, testscenario’s en testscripts) kunnen worden overeengekomen, net als de datastrategie (governance, data cleansing, datatransformaties en datamigratie). Doordat dan de fysieke dataobjecten bekend zijn, kunnen interface contracten worden opgesteld en gerealiseerd. Dit zou een enorme kostenbesparing hebben opgeleverd en de doorlooptijd van het programma met minimaal een jaar hebben verkort.
Het project leerde Karel dat het kennelijk lastig is voor organisaties om ten volle te profiteren van ervaringen van een door de wol geverfde projectmanager. Deze ervaring nam hij mee naar een volgend project. ●
BEHEERS DE VOORUITGANG, VOORDAT HET
JOU BEHEERST
Wij beheersen de vooruitgang. Met een ecosysteem van 25+ expertbedrijven maken we organisaties blijvend wendbaar, weerbaar en onderscheidend.
Dat is de kunst van het digitaal transformeren.
Hoe software-ontwikkelprojecten professioneel te begroten
Begrotingen vaak te optimistisch opgezet
Al zo lang er applicaties worden ontwikkeld, wordt er geklaagd: te duur, te laat, te weinig functionaliteit en/of te lage kwaliteit! Allerlei redenen worden daarvoor aangehaald: matige requirements, veel changes, gebrek aan goed personeel, etc. Een reden die je bijna nooit hoort: dat er onprofessioneel en onrealistisch wordt begroot. Dit laatste hoeft niet voor te komen.
AUTEUR: HAROLD VAN HEERINGEN
Hoe so&ware-ontwikkelprojecten professioneel te begroten
Begro7ngen vaak te op7mis7sch opgezet
PAuteur: Harold van Heeringen,
Al zo lang er applica5es worden ontwikkeld, wordt er geklaagd: te duur, te laat, te weinig func5onaliteit en/of te lage kwaliteit! Allerlei redenen worden daarvoor aangehaald: ma5ge requirements, veel changes, gebrek aan goed personeel, etc. Een reden die je bijna nooit hoort: dat er onprofessioneel en onrealis5sch wordt begroot. Dit laatste hoeD niet voor te komen.
Auteur: Harold van Heeringen
rojectmanagers weten hoe belangrijk een realistische begroting is; het is de basis voor de businesscase, de teamomvang, de doorlooptijd, de voortgangsrapportages, etc. Over begroten zegt Steve McConnell in zijn boek “Software estimation, demystifying the black art!” dat er vaak in een project te optimistisch wordt begroot. Als er (te) weinig budget beschikbaar komt, kan er sprake zijn van een te korte doorlooptijd, te klein team. Dat kan leiden tot meer stress, wat kan leiden tot meer defects en rework. Een oplossing kan dan zijn om alsnog extra mensen aan het team toe te voegen. Dat leidt meestal niet tot meer snelheid in project, maar, wel tot hogere kosten. Ofwel: een optimistische begroting kan makkelijk tot grote overruns (hogere kosten) leiden.
De agile aanpak, waarin in korte iteraties aan producten wordt gewerkt, zou het begrotingsprobleem oplossen, maar dat is zeker niet het geval. Er moet ook dan een begroting worden opgezet omdat degene die het budget ter beschikking stelt wil weten wat er geleverd is als het budget en de doorlooptijd ‘op’ zijn. Is dan alle functionaliteit geleverd die nodig is dan wel wordt verwacht? Engels onderzoek toont aan dat dit vaak niet zo is. Zie kaderstuk 1 waarin uit de doeken wordt gedaan dat in Engels onderzoek naar voren is gekomen dat agile softwareprojecten een 268 procent hogere kans op mislukken hebben.
Begrotingen in de praktijk
Projectmanagers weten hoe belangrijk een realis5sche begro5ng is; het is de basis voor de businesscase, de teamomvang, de doorloop5jd, de voortgangsrapportages, etc. Over begroten zegt Steve McConnell in zijn boek “SoDware es5ma5on, demys5fying the black art!” 1 dat er vaak in een project te op5mis5sch wordt begroot. Als er (te) weinig budget beschikbaar komt, kan er sprake zijn van een te korte doorloop5jd, te klein team. Dat kan leiden tot meer stress, wat kan leiden tot meer defects en rework. Een oplossing kan dan zijn om alsnog extra mensen aan het team toe te voegen. Dat leidt meestal niet tot meer snelheid in project, maar, wel tot hogere kosten. Ofwel: een op5mis5sche begro5ng kan makkelijk tot grote overruns (hogere kosten) leiden.
Als een project daarentegen pessimistisch wordt begroot, dan gaat de wet van Parkinson op. Die wet zegt dat ‘als er veel geld beschikbaar wordt gesteld, het extra budget ook opgemaakt wordt.’ Het project had wellicht goedkoper/sneller gekund, maar het gaat dan in ieder geval niet over het budget heen. Dat kan politieke voordelen opleveren. Dit is een belangrijke theorie. In figuur 1 wordt dit effect uitgebeeld.
Begrotingen van software-ontwikkelprojecten worden van oudsher gemaakt door experts: architecten, ontwikkelaars, projectmanagers met verstand van zaken en veel ervaring met projecten in de IT. Het vervelende is dat expertbegrotingen erom bekend staan dat ze optimistisch zijn. Volgens nobelprijs winnaar Kahnemann zijn mensen ‘hard-wired optimists’. Ervaren projectmanagers lossen dit op door een risicomarge op het project te zetten.
Er zijn ook organisaties die om te begroten gebruik maken van parametrische modellen. Een bekend model is COCOMO II dat door dr. Barry Boehm
Als een project daarentegen pessimis5sch wordt begroot, dan gaat de wet van Parkinson op. Die wet zegt dat ‘als er veel geld beschikbaar wordt gesteld, het extra budget ook opgemaakt wordt.’ Het project had wellicht goedkoper/sneller gekund, maar het gaat dan in ieder geval niet over het budget heen. Dat kan poli5eke voordelen opleveren. Dit is een belangrijke theorie. In figuur 1 wordt dit effect uitgebeeld
Figuur 1: De impact van een optimistische- en pessimistische begroting op de kosten
Figuur 1: De impact van een op5mis5sche- en pessimis5sche begro5ng op de kosten
Kader 1. Engels onderzoek: agile softwareprojecten hebben een 268% hogere kans op mislukken.
Kader 1. Engels onderzoek: agile soDwareprojecten hebben een 268% hogere kans op mislukken.
Begro7ngen in de prak7jk
is ontwikkeld. Een groot nadeel van dit model is dat het is gebaseerd op het aantal te maken regel codes. Het aantal regelcodes is aan het begin van een ontwikkeling echter niet bekend. Als het geschat moet worden treedt het optimisme van de mens weer naar voren. Er zijn ook modellen beschikbaar die gevoed kunnen worden met ‘functional size’. Met behulp van een ISO gecertificeerde standaard, zoals Nesma, wordt eerst de omvang van de functionele user requirements
gemeten, bij voorkeur door een gecertificeerde analist. Dit zorgt ervoor dat de functionele omvang op een objectieve, herhaalbare, verifieerbare en daarmee verdedigbare wijze wordt vastgesteld. Omdat deze methodes alleen naar de functionele requirements kijken, spelen factoren als de te gebruiken ontwikkeltaal, of bepaalde eisen aan de gebruiksvriendelijkheid van de software niet mee. Een applicatie van 1000 functiepunten (FP) die ontwikkeld is in Java biedt net zoveel gebruikersfunctionaliteit als een applicatie van 1000 functiepunten die in Cobol is gebouwd.
Begro5ngen van soDware-ontwikkelprojecten worden van oudsher gemaakt door experts: architecten, ontwikkelaars, projectmanagers met verstand van zaken en veel ervaring met projecten in de IT. Het vervelende is dat expertbegro5ngen erom bekend staan dat ze op5mis5sch zijn. Volgens nobelprijs winnaar Kahnemann zijn mensen ‘hard-wired op5mists’. Ervaren projectmanagers lossen dit op door een risicomarge op het project te zeWen.
Er zijn ook organisa5es die om te begroten gebruik maken van parametrische modellen. Een bekend model is COCOMO II dat door dr. Barry Boehm is ontwikkeld. Een groot nadeel van dit model is dat het is gebaseerd op het aantal te maken regel codes. Het aantal regelcodes is aan het begin van een ontwikkeling echter niet bekend. Als het geschat moet worden treedt het op5misme van de mens weer naar voren. Er zijn ook modellen beschikbaar die gevoed kunnen worden met ‘func5onal size’. Met behulp van een ISO gecer5ficeerde standaard, zoals Nesma2, wordt eerst de omvang van de
2 www.nesma.org
Het meten van de omvang van een project is een cruciale eerste stap in een begroting
Het meten van de omvang is een cruciale eerste stap in een begroting. Het is te vergelijken met een schilder die voorafgaande aan het schilderen van een muur eerst gaat kijken hoeveel vierkante meter die muur is en wat voor muur het is. Als de omvang bekend is, dan weet de schilder vanuit zijn ervaring wel ongeveer hoeveel hij per vierkante meter daarvoor moet offreren.
Datzelfde gaat op voor softwareprojecten. Als de functionele omvang bekend is, dan wordt het mogelijk om te kijken wat de metrieken zijn van vergelijkbare afgeronde projecten: de ‘Project Delivery Rate’ (Uren per FP), de Kosten per FP en de leversnelheid (FP per maand). Het is mogelijk dit soort data zelf op te bouwen, maar daar is wel wat expertise voor nodig. Het is ook mogelijk om gebruik te maken van de data van de International Software Benchmarking Standards Group (ISBSG). Zij bieden een repository aan met meer dan 11.800 data punten van afgeronde projecten, releases en sprints. De functionele omvang van veel recente projecten in deze repository zijn gemeten met de Nesma methode. Deze data worden geleverd als een Excel bestand, waardoor het mogelijk is eenvoudig een dataset te selecteren van relevante projecten. Eigenlijk zou ieder groot of belangrijk project deze reality check moeten uitvoeren. Meet de omvang in FP, reken de uren/FP uit van je begroting, en check of deze in lijn is met de data in de ISBSG repository. Zo niet, dan moet er een goede reden voor zijn dat de begroting afwijkt!
Enigszins gesimplificeerd voorbeeld
Ik heb onlangs een begroting gemaakt voor een Amerikaans bedrijf in de farmaciesector dat gebruik maakt van Oracle Clinical in hun applicatielandschap. Dit is een pakket dat door Oracle wordt geleverd, maar dit wordt in 2027 van de markt gehaald. Dit bedrijf is nu op zoek naar een andere pakketleverancier en wil ook kijken hoe duur het zelf ontwikkelen van de gebruikte Oracle Clinical functionaliteit is, en hoe snel men dit eventueel kan doen. Het bedrijf is een Microsoft .Net huis en men heeft net ook een ander zelf gebouwd systeem afgerond, in een agile manier van werken. Het herbouwproject van Oracle Clinical, mocht daarvoor worden gekozen, zou door eenzelfde soort team worden gedaan, alhoewel ze wel zouden moeten opschalen als dat nodig is.
Eerst is een high-level Nesma functional size analyse gemaakt van het genoemde andere ontwikkelde systeem: ongeveer 1500 FP groot. Op basis van de bestede uren, de kosten van deze uren en de doorlooptijd konden de metrieken vastgesteld worden:
● PDR: 8,9 uur/FP.
● Cost/FP: $ 767.
● Delivery Speed: 84 FP per maand. Vervolgens is een ‘sanity check’ uitgevoerd op de ISBSG-data en deze metrieken lagen in lijn met de dataset van vergelijkbare projecten. Zie tabel 1
De gerealiseerde Project Delivery Rate ligt in lijn met wat verwacht mag worden van dit type project en dit Amerikaanse bedrijf is goed in staat om dit type projecten te realiseren tegen een ongeveer marktgemiddelde productiviteit.
Vervolgens is de functionaliteit van de Oracle Clinical gebruikersdocumentatie gemeten met de Nesma methode, wat uitkwam op een omvang van rond de 3300 FP. Aangezien het bedrijf niet alles wil herbouwen, is door een aantal mensen goed gekeken naar de onderkende functies en of deze in het herbouwproject zouden worden opgenomen. De definitieve functionele projectomvang kwam uit op zo’n 3000 FP. Op basis daarvan is de begroting gemaakt. Dat kwam uit op een meest waarschijnlijk scenario van 27600 uren. De kosten worden begroot door de te verwachten ontwikkelkosten per uur in India en in de USA te vermenigvuldigen met het aantal uren per locatie.
Monitoren van de voortgang
Een van de voordelen van de agile manier van werken is dat er na iedere sprint nieuwe data is: uren besteed, kosten besteed en functionele omvang geleverd. Door dit te meten, kunnen de genoemde metrieken na iedere sprint worden bijgewerkt en kan de totale begroting op basis hiervan worden bijgewerkt.
Tabel 1. Dataset vergelijkbare projecten
Metriek:
Dit is belangrijk, want ook in agile projecten kan het behoorlijk mis gaan, zoals eerder al aangegeven. Een van de kernprincipes van agile is ‘Embrace Change over following a plan’. Dat klinkt goed, maar kan snel de verkeerde kant op gaan.
Veel teams gebruiken story points om te schatten hoeveel werk er in de komende sprint kan worden opgeleverd. Het probleem van story points is echter dat het om een subjectieve methode van het schatten van effort gaat, niet om het schatten van functionaliteit. Ook wordt er vaak geen ratioschaal maar een ordinale schaal gebruikt, zodat metrics gebaseerd op story points maar beperkt nuttig zijn. In figuur 2 wordt uitgelegd waarom.
Op de y-as staat de beschikbare capaciteit van het team in uren per sprint, in dit voorbeeld 1000 uur. Op de x-as staan de sprints in tijd uitgebeeld. In het voorbeeld realiseert het team in iedere sprint 80 story points, en lijkt dus erg voorspelbaar. Maar omdat de story points ook aan zaken als code refactoring, oplossen van bugs en andere taken worden toegekend, wordt het moeilijk om de overall project status te volgen als het gaat om afgeronde functionaliteit. Ook rework dat leidt tot gewijzigde functionaliteit en zelfs verwijderde functionaliteit kunnen ertoe leiden dat er steeds minder tijd besteed wordt aan de groene
blokken: nieuwe functionaliteit. En die groene blokken vormden de basis voor de begroting en is wat de klant of gebruiker verwacht geleverd te krijgen. De anders gekleurde blokken hebben invloed op de gerealiseerde productiviteit. Hier kom je pas achter als je regelmatig meet hoeveel functionaliteit er is opgeleverd en dit vergelijkt met wat je op dat moment had verwacht.
In figuur 3 is zichtbaar gemaakt hoe de totale begroting daarop aangepast kan worden.
Op de y-as staat de beschikbare capaciteit van het team in uren per sprint, in dit voorbeeld 1000 uur. Op de x-as staan de sprints in 5jd uitgebeeld. In het voorbeeld realiseert het team in iedere sprint 80 story points, en lijkt dus erg voorspelbaar. Maar omdat de story points ook aan zaken als code refactoring, oplossen van bugs en andere taken worden toegekend, wordt het moeilijk om de overall project status te volgen als het gaat om afgeronde func5onaliteit. Ook rework dat leidt tot gewijzigde func5onaliteit en zelfs verwijderde func5onaliteit kunnen ertoe leiden dat er steeds minder 5jd besteed wordt aan de groene blokken: nieuwe func5onaliteit. En die groene blokken vormden de basis voor de begro5ng en is wat de klant of gebruiker verwacht geleverd te krijgen. De anders gekleurde blokken hebben invloed op de gerealiseerde produc5viteit. Hier kom je pas achter als je regelma5g meet hoeveel func5onaliteit er is opgeleverd en dit vergelijkt met wat je op dat moment had verwacht. In figuur 3 is zichtbaar gemaakt hoe de totale begro5ng daarop aangepast kan worden.
Op de x-as staan de sprints en op de y-as de hoeveelheid functionaliteit (functiepunten) die naar verwachting opgeleverd zou moeten zijn. Dit voorbeeld laat zien dat de voortgang achterloopt op de begroting, en dat bijsturen waarschijnlijk nodig is.
Door het project op deze manier te monitoren houdt de projectleider grip op de te verwachten kosten en de doorlooptijd, en is hij in staat vroeg in te grijpen als de productiviteit lager is dan verwacht.
Functional
Size Measurement en
Software Cost Estimation
Over Functional Size, ook wel functiepunten genoemd, wordt in de praktijk nog wel eens
Figuur 2: Effort besteed door agile teams door de 5jd gemeten
Figuur 2: Effort besteed door agile teams door de tijd gemeten
Over Func5onal Size, ook wel func5epunten genoemd, wordt in de prak5jk nog wel eens lacherig gedaan, omdat het al een oude methode is (eind jaren 70 ontwikkeld bij IBM). Veel bedrijven hebben geprobeerd ermee te werken, maar hebben dit vaak als las5g ervaren. Het is om ermee te werken nodig te investeren in exper5se en mensen moeten dit werk ook willen doen en leuk vinden. Gecer5ficeerde analisten in deze aanpak hebben een groot aantal telrichtlijnen moeten leren om gedetailleerd de func5epunten te kunnen meten.
moeten leren om gedetailleerd de functiepunten te kunnen meten.
Over Func5onal Size, ook wel func5epunten genoemd, wordt in de prak5jk nog wel eens lacherig gedaan, omdat het al een oude methode is (eind jaren 70 ontwikkeld bij IBM). Veel bedrijven hebben geprobeerd ermee te werken, maar hebben dit vaak als las5g ervaren. Het is om ermee te werken nodig te investeren in exper5se en mensen moeten dit werk ook willen doen en leuk vinden.
opgeleverd. Deze methode heet Easy Functional pagina’s zodat deze snel te leren is en eenvoudig is toe te passen.
Gedetailleerd meten is echter niet nodig. Er zijn verschillende varianten beschikbaar waarmee eenvoudig en snel de func5onele omvang kan worden vastgesteld. Nesma heeD een methode ontwikkeld die gericht is op het snel en eenvoudig meten van func5onaliteit die in een sprint is opgeleverd. Deze methode heet Easy Func7onal Sizing (EFS)4. De gids bevat slechts een paar pagina’s zodat deze snel te leren is en eenvoudig is toe te passen. De resultaten zijn te vergelijken
Gecer5ficeerde analisten in deze aanpak hebben een groot aantal telrichtlijnen moeten leren om gedetailleerd de func5epunten te kunnen meten.
Gedetailleerd meten is echter niet nodig. Er zijn verschillende varianten beschikbaar waarmee eenvoudig en snel de func5onele omvang kan worden vastgesteld. Nesma heeD een methode ontwikkeld die gericht is op het snel en eenvoudig meten van func5onaliteit die in een sprint is opgeleverd. Deze methode heet Easy Func7onal Sizing (EFS)4. De gids bevat slechts een paar pagina’s zodat deze snel te leren is en eenvoudig is toe te passen De resultaten zijn te vergelijken
4 Efs.nesma.orgGedetailleerd meten is niet nodig. Eenvoudig en snel kan de functionele omvang worden vastgesteld
4 Efs.nesma.org
De resultaten zijn te vergelijken met de resultaten van een gedetailleerde meting. Dat maakt het mogelijk om data van afgeronde projecten ook met EFS te gebruiken voor het begroten, monitoren of benchmarken van projecten, releases en sprints. Dit geeft agile teams de mogelijkheid om naast de story points ook metrieken op te bouwen ten aanzien van de geleverde functionaliteit en daarnaast te monitoren of ze op schema liggen v.w.b. de totaal op te leveren functionaliteit. Meer informatie is te vinden op efs.nesma.org.
(ICEAA5) de Cost Es5ma5on Body of Knowledge for SoDware (CEBoK-S) ontwikkeld met de mogelijkheid hierin te cer5ficeren. De bedoeling is om het volwassenheidsniveau van de begro5ngen in de markt te verhogen. In figuur 4 wordt het es5ma5on maturity model van een van de toonaangevende leveranciers van begro5ngssoDware Galorath6 getoond.
Figuur 4: Es5ma5on Maturity Model
Figuur 4: Estimation Maturity Model
Deze figuur is te zien dat het verhogen van de volwassenheid van het begro5ngsproces in organisa5es aan kan leiden tot betere begro5ngen. Vanaf level 2 wordt gebruik gemaakt wordt van ‘formal sizing’, oDewel func5onal size measurement. Beter begroten voert naar meer succes in projecten, minder waste en lagere kosten.
Maturity Model
Conclusie
Zoals eerder gezegd is het maken van een professionele en realistische begroting een belangrijke basis voor een succesvol project en wordt nog steeds veel overgelaten aan de kennis en deskundigheid van (optimistische) experts.
Conclusie
Veel soDware-ontwikkelprojecten worden begroot door menselijke experts die daardoor kunnen mislukken, ook als ze op een agile manier werken. In dit ar5kel is beschreven wat organisa5es
5 www.iceaaonline.com 6 www.galorath.com
Om het vakgebied ‘Software Cost Estimation’ te professionaliseren heeft Nesma samen met de International Cost Estimation and Analysis Association (ICEAA ) de Cost Estimation Body of Knowledge for Software (CEBoK-S) ontwikkeld met de mogelijkheid hierin te certificeren. De bedoeling is om het volwassenheidsniveau van de begrotingen in de markt te verhogen. In figuur 4 wordt het estimation maturity model van een van de toonaangevende leveranciers van begrotingssoftware Galorath getoond. Deze figuur is te zien dat het verhogen van de volwassenheid van het begrotingsproces in organisaties aan kan leiden tot betere begrotingen. Vanaf level 2 wordt gebruik gemaakt wordt van ‘formal sizing’, oftewel functional size measurement. Beter begroten voert naar meer succes in projecten, minder waste en lagere kosten.
Veel software-ontwikkelprojecten worden begroot door menselijke experts die daardoor kunnen mislukken, ook als ze op een agile manier werken. In dit artikel is beschreven wat organisaties kunnen doen om de volwassenheid van hun begrotingsproces naar een hoger niveau te tillen door gebruik te maken van de nieuwe Nesma methode Easy Functional Sizing en data van relevante afgeronde projecten. ●
Harold van Heeringen is Principal Consultant bij IDC Metri, en de huidige president van de non-profit organisatie Nesma
Dé community voor projectprofessionalss
De Best Practice User Group
Het meest inspirerende, verbindende en verrijkende netwerk voor ofessionals in projecten, programma’s en portfolio’s.
De BPUG Projectcommunity bestaat uit ruim 200 professionals die door middel van projecten, pro-gramma’s en portfolio’s en andere aanpakken veranderingen in organisaties realiseren. Binnen de ver-eniging delen we met elkaar kennis en ervaring over het gebruik van best practices voor ons vakgebied en aanverwante vakgebieden.
Een best practice is voor ons méér dan een ‘methodiek-uit-een-boekje’. Best practices hebben zich in de praktijk bewezen als werkwijzen die écht helpen om de gewenste verandering te realiseren. Hierbij is het essentieel om goed te kijken naar de context en best practices niet integraal over te nemen. Daarom zijn praktijkverhalen over het gebruik van best practices belangrijk.
Op 10 oktober 2024 vond de BPUG Communitydag plaats, waar projectmanagementprofessi-
Lid worden?
Een lidmaatschap kost slechts € 82,50 (exclusief BTW) per jaar. Dan kun je zonder verdere kosten deelnemen aan álle evenementen van de BPUG Projectcommunity.
onals en studenten samenkwamen om te leren, te netwerken en te discussiëren over actuele ontwikkelingen binnen projectmanagement. Het programma bestond uit diverse workshops en presentaties die voor verdiepende inzichten zorgden. Lees een volledig verslag op https://www.bpug.nl/ communitydag-2024/een-terugblik-op-de-communitydag-2024.
Kijk voor meer informatie over de vereniging, het lidmaatschap en de communitydag op www.bpug.nl
Waarom willen wij NIET weten of onze applicaties renderen?
“The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using fewer materials and labor to perform the same task”.
Tom Clancy, The sum of all fears.
AUTEUR: JOS VAN DER HEIJDEN
Er zijn bruggen die in de bouw over tijd en over budget gaan en een enkele stort na de bouw in of vertoont gebreken zoals die van onze hogesnelheidslijn, maar over het algemeen zijn bruggen geschikt voor hun taak. Dat komt in belangrijke mate voort uit de gedetailleerdheid van het ontwerp en de constructieberekening vóórdat met de bouw wordt gestart. De specificaties staan vast en kunnen gedurende de bouw maar marginaal worden aangepast.
Voordat in een brug wordt geïnvesteerd wordt eveneens berekend wat het rendement van de brug zal zijn. Rendement definiëren we in dit geval als de opbrengst ten opzichte van de investering. Rendement kan financieel worden uitgedrukt bijvoorbeeld als Return On Investment (ROI) of als Net Present Value (NPV). Of in andere kwantiteiten of in kwalitatieve opbrengsten.
Voor een brug zou dat kwantitatief kunnen zijn: de gegenereerde tol, als het om een tolbrug gaat. Of de besparing in CO2 uitstoot omdat minder omgereden hoeft te worden. En kwalitatief zou dat gebruiksgemak kunnen zijn, de gebruiker kan sneller de plaats van bestemming bereiken.
De traditionele aanpak van de bouw van software-applicaties is met de bruggenbouw te vergelijken maar er zijn grote verschillen. Een brug wordt als geheel opgeleverd en functioneert direct als brug, terwijl een applicatie vaak niet conform ontwerp wordt opgeleverd en slechts gedeeltelijk of helemaal niet functioneert.
Omvangrijke bedragen worden gestoken in de ontwikkeling en implementatie van applicaties, vaak op basis van een initiële businesscase. We zien in de praktijk echter zelden of nooit dat er wordt gemeten of die investering rendeert, kwantitatief dan wel kwalitatief.
Onze stelling: applicaties kunnen effectiever en efficiënter worden ontwikkeld en/of geïmplementeerd.
Applicaties zijn dé drivers van de business, elk bedrijfsproces leunt in meer of mindere mate op een applicatie. Het rendement van de totale orga-
nisatie wordt voor een substantieel deel bepaald door effectiviteit en efficiëntie van die applicaties, zo is te stellen. Dus zou je mogen verwachten dat organisaties geïnteresseerd zijn in die efficiëntie. Onze jarenlange ervaring met honderden projecten van allerlei aard is onze ervaring laat dit zien: dat zijn de organisaties niet!
Meten rendement op applicaties
Adviseurs zoals Giovanni Dhondt (voor de agile aanpak) en Michiel van der Molen (voor de traditionele aanpak) en ook onderzoekers binnen de wetenschap promoten het meten van het rendement op applicaties en geven daarvoor ook hele duidelijke handvatten. Maar in de praktijk gebeurt dit meten niet of nauwelijks door organisaties. Dat vind ik vreemd omdat daarmee eigenlijk wordt gezegd: het interesseert ons niet en we willen ook niet van onze fouten leren.
In commerciële organisaties gaat het nagenoeg de hele dag om streven naar efficiëntie, optimalisatie van het productieproces, kostenbesparingen, omzet en EBITDA. Alleen als het om applicaties gaat vergeten we dat. Waarom?
Als KWD willen we een antwoord geven op de vraag WAAROM er zo weinig aandacht aan wordt besteed. Als er zoveel concrete tips worden gegeven in de literatuur hoe het rendement van applicaties te meten, maar organisaties doen het niet, wat is er dan aan de hand?
We hebben deze vraag inmiddels besproken met mensen uit de praktijk en met professoren en hoogleraren zoals Rob Kusters van de OU, Rini van Solingen van de TU Delft en Carl Marnewick van de universiteit van Johannesburg. Uit de gesprekken kwamen als mogelijke oorzaken naar voren:
● Er is geen noodzaak. Zolang onder aan de streep het bedrijfsresultaat, de EBITDA, voldoende is, is C-level niet geïnteresseerd in het specifieke rendement van de ICT.
● Het is bedreigend. Stel dat we zouden ontdekken dat IT projecten efficiënter kunnen worden uitgevoerd, dat het beter kan, wie wil zich dan verantwoordelijk houden?
● Het is complex.
o Hoe relateer je een verbeterd resultaat aan een (deel van een) applicatie. Immers er heeft implementatie plaatsgevonden, het gebruik is van invloed en hoe weeg je dat allemaal mee?
o Verbeterd resultaat meet je niet slechts in Euro’s; het vraagt om een holistische beschouwing. Ook marktaandeel, klanttevredenheid, leveringsbetrouwbaarheid, medewerkerstevredenheid, enz. gelden als verbeterd resultaat. En soms zijn deze aspecten niet in harde cijfers uit te drukken.
● Medewerkers wisselen van rol of organisatie. Dus soms “erf” je als projectmanager de producten van je voorganger. Als je een andere visie hebt en je brengt veranderingen in het project aan dan is dat van invloed op het uiteindelijke resultaat en metingen aan de applicatie.
● Het zit niet in de cultuur. Het meten van resultaten vraagt een organisatie-brede aanpak, oftewel het moet in de cultuur zitten. Anders is er een gedragsverandering door de hele organisatie nodig en dat is een langdurig proces.
● Het “beleid”: veel wordt vervangen omwille allerlei redenen, maar goede afwegingen daarvoor ontbreken niet zelden.
Deze mogelijke en andere oorzaken willen we graag als KWD verder onderzoeken. Wij willen
nogmaals graag weten waarom er zo weinig aandacht voor dit onderwerp is. De uitkomsten zijn van belang om verbeteringen in applicatie-ontwikkelingen te kunnen realiseren.
Succes van applicaties
Rendement op een applicatie is te zien als een vorm van succes van die applicatie of van het initiatief waardoor die applicatie is ontwikkeld of aangeschaft en geïmplementeerd. Al vinden wij dat je een meer holistisch beeld zou moeten vormen van het succes van een applicatie dan rendement alleen. Naast rendement is een tevreden klant, een groter marktaandeel, een schoner milieu natuurlijk ook succes. Maar voor dit artikel ligt de focus op het rendement.
In ons boekje “Resultaatgericht sturen op waarde” is eveneens aandacht besteed aan projectresultaat. In figuur 1 staan de verschillende vormen van “project’-succes: Succes van een project, dus ook die van de bouw of de aanschaf en implementatie, wordt volgens onderzoekers Zwikael en Smyrk en Zwikael en Meredith gemeten in drie verschillende dimensies:
● Project Management Succes (PMS): Dat is gelijk aan de gouden driehoek: op tijd, binnen budget en de volledige scope.
● Project Ownership / businesscase Succes (POS): De businesscase is behaald volgens geraamde kosten en de gestelde doelen.
Figuur 1: De verschillende vormen van project-succes
Succes van een project, dus ook die van de bouw of de aanschaf en implementa6e, wordt gemeten volgens onderzoekers Zwikael en Smyrk iiien Zwikael en Meredith:iv gemeten in drie verschillende dimensies:
- Project Management Succes (PMS): Dat is gelijk aan de gouden driehoek: op 6jd, binnen
● Project Investment Succes (PIS): Het initiatief was de moeite waard volgens de investeerder. Maar dat kan ook al het geval zijn bij POS.
Zwikael and Meredith onderzochten 35 projecten in Europa en Australië op PIS door de Net Present Value (NPV) die vooraf was berekend te vergelijken met de NPV die achteraf, met de werkelijke waarden berekend kon worden. In 61 procent van de IT projecten was de NPV achteraf niet behaald ten opzichte van de vooraf berekende NPV. Overigens stellen zij dat het PIS lager kan zijn dan het POS omdat stakeholders tevreden kunnen zijn met de behaalde projectresultaten ondanks dat die misschien lager zijn dan als berekend in de businesscase ten behoeve van het POS. De stakeholder die uiteindelijk verantwoordelijk is voor het behalen van het resultaat is volgens hen niet de projectmanager maar de “project funding entity” en de project owner (let op, dit is niet de product owner in de agile aanpak) in het bijzonder. De initiatiefmanager is verantwoordelijk voor het PMS resultaat. Verder stellen de onderzoekers dat per initiatief de detaildoelen in belangrijkheid kunnen
verschillen. Bij het ene initiatief is binnen budget blijven belangrijk, bij een ander initiatief de scope en verderop in de tijd de te behalen benefits. Ze pleiten er dan ook voor om voorafgaand aan een initiatief de doelen duidelijk en in voldoende detail te bediscussiëren en vast te leggen. Dit om het resultaat goed te kunnen beoordelen. En het kan dienen als benchmark om ervan te leren voor volgende projecten.
Wat meten we wel?
Investmentsucces is de mate waarin de in het initiatief geïnvesteerde euro rendement heeft opgeleverd, niet slechts in uitgedrukt in euro’s maar bezien vanuit een holistisch perspectief. We (zouden moeten) meten of de business owner en de overige stakeholders t/m C-level tevreden zijn met het resultaat. Zouden moeten… want in de praktijk meten we dit dus niet of nauwelijks.
Wat meten we dan wel? De Standish Group verzamelt sinds 1994 data over projecten en of deze projecten succesvol zijn, “challenged zijn” of falen en daarmee meten zij al jarenlang de mate van “Management Succes”.
Wat meten we dan wel? De Standish Group verzamelt sinds 1994 data over projecten en of deze projecten succesvol zijn, “challenged zijn” of falen en daarmee meten zij al jarenlang de mate van “Management Succes”.
Over de jaren heen geeft dat het beeld in figuur 2
Over de jaren heen geeY dat het beeld in figuur 2.
Figuur 2: Management Succes zoals gemeten door de Standish Group over een periode van 30 jaar
Bron “Beyond Infinity” CHAOS report 2023 van Jim Johnson. The standish group.
Bron “Beyond Infinity” CHAOS report 2023 van Jim Johnson. The standish group.
Successfull = Op 6jd, volgens budget en volgens scope.
Successfull = Op tijd, volgens budget en volgens scope.
Challenged = Minimaal één van deze drie criteria is niet gehaald.
Challenged = Minimaal één van deze drie criteria is niet gehaald.
Failed = Het initiatief is gecancelled of de software is nooit gebruikt.
Failed = Het ini6a6ef is gecancelled of de soYware is nooit gebruikt.
Figuur 2: Management Succes zoals gemeten door de Standish Group over een periode van 30 jaar
Figuur 3. Projecten traditioneel gemeten door Standish Group en modern
Figuur 3. Projecten tradi6oneel gemeten door Standish Group en modern
Pure measurement
Of een initiatief succesvol is werd traditioneel gemeten volgens de zogenaamde “gouden driehoek (PMS): op tijd, conform budget en conform scope. In de “moderne” meting van
en een hoge klanttevredenheid””. Waarom zou je een initiatief van start laten gaan als het niet leidt tot rendement of tot een hogere klanttevredenheid? Dan is het zonde van tijd en geld.
CHAOS database.
Figuur 3. Projecten tradi6oneel gemeten door Standish Group en modern
Dat geeft het beeld zoals in meting geeft dus een ander, slechter resultaat.
Pure measurement
Pure measurement
CHAOS pleit overigens voor “pure” measurement en noemt dat zelfs de “enige echte meting van (project-)succes: “de combinatie van rendement
afkomstig uit het CHAOS rapport toont de ‘Pure’ gemeten projecten die én rendement leveren én een hoge klanttevredenheid (kolom 1) of één van deze 2 criteria (kolom 2).
geeft specifiek het behaald rendement in
Hieruit blijkt dat men in 29 procent van de projecten tevreden of zeer tevreden was met het
CHAOS pleit overigens voor “pure” measurement en noemt dat zelfs de “enige echte me6ng van (project-)succes: “de combina6e van rendement en een hoge klanaevredenheid”” een ini6a6ef van start laten gaan als het niet leidt tot rendement of tot een hogere klanaevredenheid? Dan is het zonde van 6jd en geld
CHAOS pleit overigens voor “pure” measurement en noemt dat zelfs de “enige echte me6ng van (project )succes: “de combina6e van rendement en een hoge klanaevredenheid”” Waarom zou je rendement of tot een hogere . Projecten ‘Pure’ gemeten in het CHAOS rapport
hoge klanaevredenheid (kolom 1) of één van deze 2 criteria (kolom 2) in projecten weer.
Figuur 4. Projecten ‘Pure’ gemeten in het CHAOS rapport
Figuur 4. Projecten ‘Pure’ gemeten in het CHAOS rapport
Figuur 5. Behaalde rendementen in 50.000 projecten
Figuur 5. Behaalde rendementen in 50.000 projecten
Figuur 4 atoms6g uit het CHAOS rapport toont de ‘Pure’ gemeten projecten die én rendement leveren én een hoge klanaevredenheid (kolom 1) of één van deze 2 criteria (kolom 2)
Figuur 5 geeY specifiek het behaald rendement in projecten weer.
Hieruit blijkt dat men in 29 procent van de projecten tevreden of zeer tevreden was met het rendement. Ruimte voor verbetering dus Gezegd moet worden dat het genoemde percentage gebaseerd is op een keiharde, cijferma6ge berekening, maar op een score van een meerkeuzevraag.
Toch rijst ook hier de vraag op waarom we niet het PIS of het resultaat van “pure measurement” willen verbeteren?
Geen projecten meer.
rendement. Ruimte voor verbetering dus. Gezegd moet worden dat het genoemde percentage niet gebaseerd is op een keiharde, cijfermatige berekening, maar op een score van een meerkeuzevraag. Toch rijst ook hier de vraag op waarom we niet het PIS of het resultaat van “pure measurement” willen verbeteren?
Geen projecten meer.
In het CHAOS report “Beyond Infinity” uit 2023 geeft de auteur Jim Johnson zijn mening weer dat we moeten ophouden om in “projecten te denken”. We moeten denken in termen van dat “we ons geld besteden aan het ontwikkelen en implementeren van software”. Dit komt ook overeen met de agile aanpak waarbij volgens het eerste principe van het Agile Manifesto ook wordt uitgegaan van “continue oplevering van waardevolle software”.
Prof. Rini van Solingen zegt dat we meer moeten experimenteren met kleine initiatieven en daar de successen van meten. In de lucht houden wat werkt, afschrijven van wat niet werkt. Maar klein houden want dan is het falen ook klein.
Maar of het nu gaat om klein of groot, een projectmatige aanpak of een agile aanpak, voor ons onderzoek maakt het eigenlijk niet uit. Wij willen graag weten of de investering in de ontwikkeling en implementatie van de software rendabel is vanuit een holistisch perspectief.
Rendabel zijn van de software zien wij als het ultieme succes voor een organisatie op softwareontwikkeling en -implementatie.
En omdat er wel onderzoek is gedaan naar projectsucces en niet of nauwelijks onderzoek naar het behaalde rendement op softwareontwikkeling en -implementatie willen we leren van de factoren van projectsucces en kijken of deze ook daar van toepassing zijn.
Oproep om mee te werken
Het CHAOS rapport noemt als harde randvoorwaarden voor het behalen van succes in projecten:
● Succesvolle projecten hebben een ervaren en zeer vaardige projectmanager;
● Projectmanagement tools helpen bij projectsucces;
● Alle projecten moeten een duidelijk doel hebben in lijn met de organisatiedoelen;
● Onvolledige requirements veroorzaken challenged en failed projecten.
Het is raar dat er bij zoveel “challenged” en falende initiatieven -zo rond de 30 procent- zo weinig interesse is bij organisaties en hun verantwoordelijken voor Project Investment Succes. Tenminste, wij als KWD komen het niet of nauwelijks tegen.
Onze vraag is: “Waarom niet?”….
Ik roep CEO’s en CFO’s op mee te doen aan een onderzoek naar deze Waarom-vraag binnen organisaties. Gevonden antwoorden zullen helpen het Rendement op Investeringen verder te verbeteren. Dat heeft, mag ik aannemen, toch wel jullie aandacht?
We gaan de vraag op twee manieren onderzoeken:
1. Via semi-gestructureerde interviews: dit neemt een uur van uw tijd in beslag.
2. Via discussie-avonden: we gaan uit van ongeveer 4 avonden. In een beperkte groep aan het einde van de dag, van 16:00 tot 20:00, willen we centraal in het land, Nieuwegein, deze materie met u bespreken. Een diner wordt door onze eigen kok voor u verzorgd. Uiteraard worden de resultaten hiervan met u gedeeld.
Wilt u deelnemen? Neem dan contact op met: Jos van der Heijden Jos.van.der.heijden@kwdrm.nl 06-26877346
Jos van der Heijden is projectmanager bij KWD resultaatmanagement
Reflecteren:
een veelgebruikt
stuk gereedschap
Reflecteren we als projectmanager?
Je kunt alleen reflecteren, of met een ander, of in groepsverband. Je kunt reflecteren over het eigen handelen, het handelen in teamverband, over verwachtingen of over resultaten van een project, of een sprint, een, een epic etc. Je kunt naar het handelen kijken, naar de motivatie of de doelstellingen, of naar de resultaten. Het doel van reflectie kan zijn: leerdoelen formuleren, effectiever handelen, het handelen toetsen op leerdoelen, gezamenlijk leren en effectiever/ productiever worden, of geleerde lessen borgen voor toekomstig gebruik.
AUTEUR: RONALD KAPPERT
Het reflecteren op het eigen handelen, het handelen van het team is noodzakelijk om met elkaar de gewenste resultaten te kunnen bereiken. We hebben een enquête gehouden onder 42 projectmanagers om te vernemen wat het thema ‘reflectie’ bij hen losmaakt. In dit artikel staan de antwoorden op de aan hen gestelde vragen.
Vraag 1. Ben je van mening dat reflectie een rol hoort te spelen in ons vak projectmanagement?
Antwoord: 100% is van mening dat dit inderdaad het geval is. Het geeft aan dat projectmanagers reflecteren in hun werk.
Vraag 2. Denk je wel eens na over hoe goed je bezig bent in je vak?
Antwoord: Ook hier een unisono ‘ja’.
Vraag 3. Hoe denk jij na over je eigen handelen en gedrag?
Reflecteren we als projectmanager?
Figuur 1 geeft de eigen reflectiestijl weer. De respondenten konden meerdere antwoorden geven. De waarde van de score per antwoord geeft aan hoeveel van de respondenten het antwoord hebben aangekruist.
Reflecteren: een veelgebruikt stuk gereedschap
Een projectmanager benadrukte dat een aanleiding om te reflecteren ook naar voren kon komen “op het moment dat ik het gevoel heb niet te handelen vanuit de persoon die ik wil zijn (authentiek vanuit mijn persoonlijke kracht)”. Ook dat kan deel uitmaken van het voortdurende spiegelen dat projectmanagers doen met zichzelf en hun omgeving.
Je kunt alleen reflecteren, of met een ander, of in groepsverband. Je kunt reflecteren over het eigen handelen, het handelen in teamverband, over verwach?ngen of over resultaten van een project, of een sprint, een, een epic etc Je kunt naar het handelen kijken, naar de mo?va?e of de doelstellingen, of naar de resultaten. Het doel van reflec?e kan zijn: leerdoelen formuleren, effec?ever handelen, het handelen toetsen op leerdoelen, gezamenlijk leren en effec?ever/produc?ever worden, of geleerde lessen borgen voor toekoms?g gebruik.
Auteur: Ronald Kappert
De commentaren en feedback op deze enquêtevraag gaven aan dat projectmanagers waarschijnlijk voortdurend reflecteren. “Op de terugweg even je ervaring van de afgelopen dag doornemen en op de volgende heenweg een beetje nadenken over hoe je de zaken nog beter gaat aanpakken. Voor mij is dit een automatisme om continu te verbeteren”, liet een van hen weten.
Vraag 4. Soms gebruik je andere mensen voor reflectie. Wanneer doe je dat?
Het reflecteren op het eigen handelen, het handelen van het team is noodzakelijk om met elkaar de gewenste resultaten te kunnen bereiken. We hebben een enquête gehouden onder 42 projectmanagers om te vernemen wat het thema ‘reflec?e’ bij hen losmaakt. In dit ar?kel staan de antwoorden op de aan hen gestelde vragen.
De commentaren en feedback op deze enquêtevraag gaven aan dat projectmanagers voortdurend reflecteren. “Op de terugweg even je ervaring van de afgelopen dag doornem de volgende heenweg een beetje nadenken over hoe je de zaken nog beter gaat aanpakken is dit een automa?sme om con?nu te verbeteren”, liet een van hen weten.
Vraag 1. Ben je van mening dat reflec3e een rol hoort te spelen in ons vak projectmanagement?
Antwoord: 100% is van mening dat dit inderdaad het geval is. Het geeQ aan dat projectmanagers reflecteren in hun werk.
Vraag 2. Denk je wel eens na over hoe goed je bezig bent in je vak?
Antwoord: Ook hier een unisono ‘ja’.
Vraag 3. Hoe denk jij na over je eigen handelen en gedrag?
De enquête laat zien dat de spannende momenten in het project -de hittepunten- een goede aanleiding zijn om even stil te staan en na te denken over de vraag waar je staat als resultaatverantwoordelijke. De meest voor de hand liggende vraag is dan om af te wegen hoe je in die situatie op te stellen, welke interventie in te zetten, met wie te schakelen. Hoe is het project gegaan ten opzichte van de eigen doelstellingen, hoe zou ik een nieuw project beter vorm kunnen geven? Ofwel een mix van reflecteren en evalueren.
De enquête laat zien dat de spannende momenten in het project -de hiZepuntenaanleiding zijn om even s?l te staan en na te denken over de vraag waar je staat als resultaatverantwoordelijke. De meest voor de hand liggende vraag is dan om af te die situa?e op te stellen, welke interven?e in te zeZen, met wie te schakelen. Hoe gegaan ten opzichte van de eigen doelstellingen, hoe zou ik een nieuw project beter geven? Ofwel een mix van reflecteren en evalueren
Reflectie doe je soms zelf, soms zoek je daar ook anderen bij op. In de reflectie met anderen krijg je feedback op het eigen handelen. Is dat nog voldoende effectief? Figuur 2 laat zien wanneer projectmanagers de hulp van anderen inroepen. Een belangrijke aanleiding voor zelfreflectie, ook met anderen, is als er hittepunten in het project zijn en er een belangrijke beslissing moet worden genomen, zo blijjkt uit de antwoorden. “Het gaat daarbij in eerste instantie om een validatie van eigen waarnemingen en aannames”, of “om een blik van iemand anders op een situatie of persoon te houden tegen mijn eigen waarneming”. Deze feedback geven dan personen die direct betrokken zijn bij de projectsituatie, zoals het eigen team. Maar er wordt zeker ook gebruik gemaakt van mensen die meer op afstand
Een projectmanager benadrukte dat een aanleiding om te reflecteren ook naar voren het moment dat ik het gevoel heb niet te handelen vanuit de persoon die ik wil zijn vanuit mijn persoonlijke kracht)”. Ook dat kan deel uitmaken van het voortdurende projectmanagers doen met zichzelf en hun omgeving.
Figuur 1 geeQ de eigen reflec?es?jl weer. De respondenten konden meerdere antwoorden geven. De waarde van de score per antwoord geeQ aan hoeveel van de respondenten het antwoord hebben aangekruist.
Vraag 4. Soms gebruik je andere mensen voor reflec3e. Wanneer doe je dat?
Figuur 1. Eigen reflec?es?jl
Figuur 1. Eigen reflectiestijl
Figuur 2. Handmatige taken die geautomatiseerd kunnen worden
Reflec?e doe je soms zelf, soms zoek je daar ook anderen bij op. In de reflec?e met feedback op het eigen handelen. Is dat nog voldoende effec?ef? Figuur 2 laat zien projectmanagers de hulp van anderen inroepen.
Een belangrijke aanleiding voor zelfreflec?e, ook met anderen, is als er hiZepunten en er een belangrijke beslissing moet worden genomen, zo blijjkt uit de antwoorden. daarbij in eerste instan?e om een valida?e van eigen waarnemingen en aannames van iemand anders op een situatie of persoon te houden tegen mijn eigen waarneming feedback geven dan personen die direct betrokken zijn bij de projectsituatie, zoals
betrokken zijn, om de “situatie te bespreken met een buitenstaander voor een andere blik”. Dat kan zijn een coach, of een mentor. In de commentaren wordt ook gewezen op het belang van reflectie met vakgenoten die zich goed in de problematiek kunnen verplaatsen.
Vraag 5. Welke feedback vraag je van je opdrachtgever?
Wat wil de projectmanager graag van de opdrachtgever weten? Drie antwoorden kwamen bij meer dan 75 procent van de deelnemers terug (zie figuur 3): hoe tevreden is de opdrachtgever over de voortgang in het project, hoe kijkt de opdrachtgever naar de manier waarop de projectmanager acteert (en welke verbeteringen de opdrachtgever mogelijk acht), en hoe tevreden is de opdrachtgever over voortgang en verloop van het project.
Voortgang gaat over de progressie tegenover de planning en het halen van de deadlines, iets waar opdrachtgevers altijd erg op gesteld zijn. Een mogelijk hittepunt kan zijn als de voortgang niet gaat zoals de opdrachtgever voor ogen heeft. Het verloop van het project gaat over de manier waarop het project de voortgang behaalt. Het kan allerlei zaken omvatten zoals het betrekken van stakeholders, de omgang met belangrijke risico’s, de rapportage naar de stuurgroep, enz.
Opdrachtgevers kunnen daar in het algemeen goed feedback op geven.
Met de feedback van opdrachtgevers kun je als projectmanager kijken naar hoe en waar te verbeteren. Let op dat je als projectmanager meer momenten hebt met je opdrachtgever dan alleen je optreden in een stuurgroep zodat de opdrachtgever je ook op andere momenten leert kennen. Deelnemers aan de enquête zeiden er dit over: “Ik wil met opdrachtgever het gelopen proces, de bereikte doelen en mijn handelen daarin bespreken” en “ik wil weten of de manier waarop ik hem informeer, nog steeds effectief is”. Modern projectmanagement vraagt ook om meer nadruk op de zachtere factoren, zoals de vraag: “hoe werken we samen?” Ook daar kan feedback op worden verkregen.
Vraag 6. Waarvoor gebruik je reflectie in een groep?
Als we samen reflecteren dan krijgt reflectie er een dimensie bij: de samenwerking in de groep en effectief deze samenwerking is. (Zie figuur 4 ). 90 procent van de geënquêteerden heeft Retrospectives als antwoord aangekruist. Dit is niet zo verwonderlijk, gegeven dat retrospectives een belangrijk instrument in leren en verbeteren zijn in agile trajecten. De retrospective komt ook nadrukkelijk naar voren in de gekozen werkvorm
Ik gebruik reflectie in een groep om:
Feedback van opdrachtgever
Hoe je als projectmanager acteert en welke verbeteringen hij ziet
Zijn tevredenheid betreffende het verloop van het project
Zijn tevredenheid betreffende de kwaliteit van de behaalde mijlpalen
Zijn tevredenheid betreffende de voortgang van het project
Anders
3. Feedback van opdrachtgever
Figuur 3. Feedback van opdrachtgever
Wat wil de projectmanager graag van de opdrachtgever weten? Drie antwoorden kwamen bij meer dan 75 procent van de deelnemers terug (zie figuur 3): hoe tevreden is de opdrachtgever over de voortgang in het project, hoe kijkt de opdrachtgever naar de manier waarop de projectmanager acteert (en welke verbeteringen de opdrachtgever mogelijk acht), en hoe tevreden is de opdrachtgever over voortgang en verloop van het project.
Samenwerking te verbeteren
Verschillende invalshoeken/perspectieven te kunnen krijgen
Er niet alleen voor te staan
Complexe situaties te analyseren en een optimale handelwijze te bepalen
Conflicten te kunnen beslechten
Eigen motivatie en gedrag te kunnen evalueren
Andere
Figuur 4. Reflecteren in een groep
Figuur 4. Reflecteren in een groep
Voortgang gaat over de progressie tegenover de planning en het halen van de deadlines, iets waar opdrachtgevers al?jd erg op gesteld zijn. Een mogelijk hiZepunt kan zijn als de voortgang niet gaat zoals de opdrachtgever voor ogen heeQ
Als we samen reflecteren dan krijgt reflec?e er een dimensie bij: de samenwerking in de groep en effec?ef deze samenwerking is. (Zie figuur 4). 90 procent van de geënquêteerden heeQ Retrospec?ves als antwoord aangekruist. Dit is niet zo verwonderlijk, gegeven dat retrospec?ves een belangrijk instrument in leren en verbeteren zijn in agile trajecten. De retrospec?ve komt ook nadrukkelijk naar voren in de gekozen werkvorm (zie de volgende vraag hieronder). De focus is dan niet zozeer gericht op specifieke situa?es maar is een algemenere beschouwing op de vraag over de onderlinge samenwerking, de gezamenlijke processen en de vraag hoe produc?viteit en kwaliteit verbeterd kunnen worden. Eén van de projectmanagers benoemde dat samen reflecteren als addi?onele resultaat kan hebben: het bevorderen van de teambuilding. Ook werd genoemd dat het effec?ef is om vanuit gezamenlijkheid, met meerdere perspec?even en invalshoeken, te kijken naar
Figuur
(zie de volgende vraag hieronder). De focus is dan niet zozeer gericht op specifieke situaties maar is een algemenere beschouwing op de vraag over de onderlinge samenwerking, de gezamenlijke processen en de vraag hoe productiviteit en kwaliteit verbeterd kunnen worden. Eén van de projectmanagers benoemde dat samen reflecteren als additionele resultaat kan hebben: het bevorderen van de teambuilding. Ook werd genoemd dat het effectief is om vanuit gezamenlijkheid, met meerdere perspectieven en invalshoeken, te kijken naar problematische situaties met complexe problemen.
Vraag 7. Welke werkvorm gebruik je voor reflecties?
De meest gebruikte werkvormen voor reflectie zijn de lessons learned sessies en de retrospectives. Zie figuur 5.
De meeste projectmanagement methoden geven aan de geleerde lessen uit het project vast te leggen in een eindrapportage. Bij de PRINCE2 methode is dat het End Project Report (EPR), dat bedoeld is als deliverable op het formeel afsluiten van het project. Het gebruik van een EPR komt uit de enquête als werkvorm naar boven die nog steeds gebruikt wordt. En we zien dat een lessons learned sessie naast de EPR gebruikt worden, al is dat zeker ook bedoeld als tussen-
tijdse evaluatie om de geleerde lessen te kunnen toepassen in het vervolg van het project.
De retrospective komt nadrukkelijk ook als vorm naar voren. Hierbij benadrukken verschillende respondenten dat “een retro op meerdere niveaus kan plaatsvinden: bij een sprint, of een release, of een roadmap, bij een Program Increment (PI) sessie, etc.” en dat “de retrospective vele werkvormen kent”.
De vele ‘Anders’ antwoorden en de losse commentaren laten zien dat er veel meer reflectie-vormen worden toegepast: “op de situatie toegespitst gesprek of format”, “buddy-sessies in eigen format”, “met elkaar praten”, “intervisie”, “brainstorm of benen-op- tafel sessie”, of de “blameless postmortem”. Dat is dan niet bedoeld om iemand ergens van te beschuldigen maar om eerlijk en objectief te kunnen onderzoeken wat de echte oorzaken zijn om daar iets van te leren om onnodige hittepunten in projecten te voorkomen.
Conclusie
Reflectie speelt een levendige rol in het dagelijkse werk van de projectmanagers, variërend van voortdurende zelfreflectie tot groepsreflectie. Reflectie is daarmee een veelgebruikt stuk gereedschap van de projectmanager. Of zoals een van de deelnemers het in goed Nederlands uitdrukte, het is “Part of the game”. ●
Welke werkvorm gebruik je
End Project Report Lessons learned sessie Retrospective Brainstormen Geen van alle Anders Demo
Figuur 5. Gebruikte werkvormen voor reflectie
en de retrospec?ves Zie figuur 5
De meeste projectmanagement methoden geven aan de geleerde lessen uit het project vast te leggen in een eindrapportage. Bij de PRINCE2 methode is dat het End Project Report (EPR), dat bedoeld is als deliverable op het formeel afsluiten van het project. Het gebruik van een EPR komt uit de enquête als werkvorm naar boven die nog steeds gebruikt wordt. En we zien dat een lessons learned sessie naast de EPR gebruikt worden, al is dat zeker ook bedoeld als tussen?jdse evalua?e om de geleerde lessen te kunnen toepassen in het vervolg van het project. De retrospec?ve komt nadrukkelijk ook als vorm naar voren. Hierbij benadrukken verschillende respondenten dat “een retro op meerdere niveaus kan plaatsvinden: bij een sprint, of een release, of
Ronald Kappert is projectmanager bij KWD resultaatmanagement
Figuur 5. Gebruikte werkvormen voor reflec3e
De meest gebruikte werkvormen voor reflec?e zijn de lessons learned sessies
De Redactieraad van Vakblad Projectmanagement
Luuk Ketel werkt ruim 30 jaar in het werkveld van project-, agile- en lijnmanagement als leverancier van projectsucces voor opdrachtgevers. Naast opdrachten bij klanten deelt hij zijn kennis en ervaring in professionaliseringstrajecten bij projectmanagementorganisaties en -leergangen. Binnen KWD coördineert hij de onderzoeken hoe projectmanagement in de praktijk uitgevoerd wordt en is medeauteur van verschillende KWD projectmanagementboeken.
Bart van den Hooff is hoogleraar Organizational Communication & Information Systems bij het KIN Center for Digital Innovation aan de Vrije Universiteit Amsterdam. Hij promoveerde aan de UvA (Communicatiewetenschap) op een onderzoek naar adoptie, gebruik en effecten van e-mail in organisaties, en is sindsdien altijd geïnteresseerd gebleven in de impact van nieuwe digitale technologieën op organisaties en mensen. Naast zijn wetenschappelijke werk heeft hij ook ervaring als consultant.
Zijn onderzoek en onderwijs gaan over IT-management in de context van digitale transformatie – van complexiteit van IT-architecturen tot de veranderende rol van de IT-functie, en van cybersecurity tot ontwikkeling en implementatie van nieuwe systemen. Hij is tevens opleidingsdirecteur van de Master ‘Digital Business and Innovation’ aan de School of Business and Economics van de VU.
Leo Klaver studeerde landbouwkunde en geschiedenis. Begon zijn journalistieke loopbaan als fotograaf bij een Fries maandblad en was de eerste elektronische redacteur in Nederland bij Uitgeverij Misset.
Was (hoofd)redacteur van De Automatisering Gids en is sinds 1986 zelfstandig journalist/uitgever. Werkte voor ministeries, Europees Parlement, voor veel magazines en zette tal van magazines op. Begon in 2004 uitgeverij TIEM. Recente publicaties zijn: ʻNever Stop Looking For Soupʼ, over zijn pelgrimstocht naar Santiago de Compostella en ʻPelgrimeren in Polen, van de Hel naar de Hemelʼ.
Vakblad Projectmanagement informeert zijn lezers over actuele ontwikkelingen in de theorie en de praktijk van het boeiende vakgebied van projectmanagement. De artikelen bevinden zich op het snijvlak van business en ICT. Tot de doelgroepen behoren projectmanagers, managers van projectmanagement afdelingen, programmanagers, multi-projectmanagers en lijnmanagers die betrokken zijn bij projecten in hun eigen organisatie. Het Vakblad vraagt u aan via: www.kwdrm.nl/vakblad
Artikelen of ideeën zijn welkom en kunt u doorgeven aan de redactie: vakblad@kwdrm.nl. Artikelen worden inhoudelijk beoordeeld door de redactieraad, bestaande uit: Annet Holtrop, Ronald Kappert, Luuk Ketel (KWD Resultaatmanagement), Bart van de Hooff (Vrije Universiteit Amsterdam) en Leo Klaver (Klaver Communicatie). Drie keer per jaar verschijnt het Vakblad Projectmanagement. 1500 edities worden als hard copy gestuurd naar lezers/abonnees. Daarnaast ontvangen 1500 lezers/abonnees de editie digitaal. KWD Resultaatmanagement geeft het vakblad uit. De uitgever verzendt het magazine gratis aan lezers die tot de doelgroep behoren.
Annet Holtrop
Annet heeft een brede ervaring als project-, programma- en afdelingsmanager, in nationaal en internationaal. In alle rollen creëert ze overzicht door complexe zaken op te splitsen in duidelijke componenten. Hierbij werkt zij altijd vanuit verbinding met de opdrachtgever, stakeholders én de teamleden.
De projecten die Annet geleid heeft, variëren van implementaties van pakketten tot volledige digitale transformatie naar een papierloos kantoor, outsourcing van diensten en end-to-end softwareontwikkelingsprojecten. Voor Annet staat KWD-resultaatmanagement voor Kunnen, Willen en Doen. Zonder daden, geen avontuur en geen resultaten. Annet is programmamanager bij KWD.
Ronald Kappert is projectmanager bij KWD Resultaatmanagement. Hij heeft ruim 20 jaar projectervaring, vooral met projecten die een organisatie-brede impact hebben. Ronald werkt graag met een programmatische opdracht waarin hij ICT kan gebruiken om veranderingen gestalte te kunnen geven. Ronald heeft die rol ingevuld in een groot aantal branches aan zowel klant- als leverancierszijde. Publicaties van zijn hand zijn: Stuurgroep aan het roer en Nul mislukkingen voor Business Owners (beide in de KWD boekenreeks); Wat is nodig voor goede samenwerking opdrachtgever en projectmanager; en het drieluik Projectpolitiek - Hoe politiek is mijn project, Projectpolitiek - De projectmanager in de politieke jungle, en Projectpolitiek - Een kwestie van Willen en Durven. Ronald is begonnen als natuurwetenschappelijk onderzoeker. Zijn inspiratie haalt hij uit onder meer uit beeldende kunst, zoals het expressionisme of de Nederlandse stroming De Stijl.
De redactie beoordeelt de aanvraag voor gratis toezending. Een betaald abonnement kost € 25,- of € 10 per nummer incl. 9% btw. Advertentietarief: € 750,– (ex. btw) per plaatsing voor een 1/1 adv full colour.
Het magazine wordt gelezen door: projectmanagers, programmamanagers, lijnmanagers, informatiemanagers, adviseurs, projectleiders, consultants, directeuren, CIO’s, vice-presidents, scrummasters, teamleiders, trainers, PMO’s. (Meer projectmanagers lezen het magazine dan PMO’s.)
Teksten&Realisatie: KWD Resultaatmanagement en Leo Klaver (Klaver Communicatie, De Lutte) Vormgeving: HGPDESiGN, Alphen aan den Rijn
Copyright: Gehele of gedeelte overname of reproductie van de inhoud van dit magazine is alleen toegestaan na schriftelijke toestemming en bronvermelding. De uitgever is zich volledig bewust van zijn taak om een zo betrouwbaar mogelijke uitgave te verzorgen. Niettemin kan hij geen aansprakelijkheid aanvaarden voor eventuele onjuistheden.
