Webinar Opdrachtgeverschap bij IT-projecten

Goeiemorgen, allemaal. Welkom bij dit webinar
van de RijksAcademie voor Digitalisering en Informatisering Overheid, RADIO.
Zoals jullie hier achter mij kunnen zien.
Vandaag doen we dit webinar samen met Pieter Frijns van Bureau Gateway.
Ik zal straks vragen aan hem om zich even voor te stellen.
We gaan het hebben over opdrachtgeverschap van IT-projecten.
Voor veel mensen een ingewikkeld onderwerp.
Veel mensen hebben geen IT-achtergrond
en zien zich plotseling in de rol van opdrachtgever
van een veranderprogramma met een IT-component.
Daar gaan we dit webinar over hebben.
Dus ik vraag eerst aan Pieter om zich even voor te stellen
en misschien ook even om uit te leggen wat Bureau Gateway nu precies is,
voor degenen die dat nog niet weten.
Dank je wel, Ronald. Goedemorgen.
Mijn naam is Pieter Frijns. Ik ben eindverantwoordelijk
voor alle gateway reviews die in Nederland worden uitgevoerd.
Je ziet hierachter ook het embleem.
Wij bestaan nu ruim 12,5 jaar. Gateway review is een methode
een collegiale reviewmethode afkomstig uit Engeland.
Ooit ontstaan rond de eeuwwisseling waar toen is aangegeven:
een heleboel van onze projecten en programma's gaan niet optimaal.
Wat is daar de oorzaak van?
Een van de knelpunten zat hem ook bij de opdrachtgever,
eigenaar van een verandertraject van een project naar een programma.
Zo is gateway review daar ontstaan. Hoe kunnen we dat nou het beste doen?
Toen was het idee: we gaan vier collega's vragen om op gezette tijden
bij een collega-opdrachtgever een reflectie uit te voeren.
Niet 'wat heb ik gedaan', niet vanuit de evaluatie,
maar vanuit de preventieve, lerende en helpende invalshoek.
Dus de vraag daarbij is: 'wat ik van plan ben,
is dat realistisch en is dat realiseerbaar?
En hebben jullie nog feedback voor mij,
of liever feedforward, om meer succesvol te kunnen zijn
met de veranderingen die ik aan doen ben?'
Dat was in Engeland.
Dat hebben we ook naar Nederland gehaald.
In 2009 zijn we gestart
en in 2010 is de accreditatie naar Nederland gekomen.
Sindsdien zijn wij druk bezig 40 à 50 gateway reviews per jaar uit te voeren.
Over de reviews heen, voeren wij wat analyses uit.
Wat zijn de patronen? Welke trend zien we?
Wat zijn de punten voor aandacht, voor verbetering?
En wat wij vandaag hopen samen met Ronald
om jullie mee te nemen in een aantal van deze ervaringen.
Uiteraard lukt dat niet om allemaal in een uur te doen,
maar wij gaan ons best doen.
Wat wel een goede is om eraan toe te voegen:
ik ben geen exhibitionist die z'n verhaal kwijt wil. Wat voor mij belangrijk is:
Kunnen wij goede vragen beantwoorden die jullie interessant vinden?
Wij kunnen veel vertellen,
maar het heeft geen waarde als je denkt: daar heb ik niks aan.
Bij dezen nodig ik namens Ronald en mijzelf u uit
om zo veel mogelijk vragen in de chat te gooien,
zodat wij daar ook op kunnen inspelen
en dat we geen college staan te geven.
-Zeker. Dank je wel, Pieter.
Daar sluit ik me bij aan. Stel vooral je vragen, die worden naar ons doorgezet.
Dan kan ik de vraag aan Pieter stellen.
Pieter en ik hebben ook al veel sessies samen gedaan
in een live setting voor ABD'ers, mensen van de Algemene Bestuursdienst.
En die vragen heb ik ook meegenomen naar deze sessie.
Ik zal ook proberen om aan de hand van wat al eerder gesteld is
ook een aantal vragen zelf aan Pieter te stellen.
Misschien mag ik beginnen met de eerste vraag. Nog even over die gateway:
is dat alleen voor de Rijksoverheid of ook voor andere bestuurslagen?
Gateway review is ooit geïntroduceerd
voor grote ICT- en digitaliseringtrajecten binnen de Rijksoverheid,
maar sinds 2011 zijn ook de grote gemeenten aangesloten
bij het gebruik van gateway review en daarna ook alle provincies.
Op dit moment voeren we gateway review uit
bij zowel Rijk, provincie, gemeenten, waterschappen,
maar ook op andere publieke taakorganisaties
of ngo's die daar behoefte aan hebben.
Dat doen we ook met een pool van zo'n 400 topambtenaren
die af en toe een weekje vrijmaken om dat met vier collega's samen te doen.
Die pool bestaat uit zo'n 400 man.
Dat is ook Rijk, provincie, gemeenten, waterschappen,
universiteiten, hogescholen,
dus college van besturen, maar ook van zbo-organisaties
die daarin plaatsnemen. Dus dat is eigenlijk door de hele overheid.
Interessant. Om dan maar even af te trappen:
zie je daar vergelijkbare vraagstukken, vergelijkbare dingen
waar ze mee worstelen in die verschillende bestuurslagen?
Eigenlijk zijn de patronen die we zien niet zo verschillend.
Als je kijkt waar je mee zit. Hoe ben je een goeie opdrachtgever?
En toch, om maar een voorbeeld te noemen:
Als het gaat over opdrachtgeverschap zien we vaak het spanningsveld van:
hoe ben ik een goede opdrachtgever in een politiek-bestuurlijke setting?
Waarbij we ook gebruikmaken van gemeenschapsgeld
waar we eigenlijk onder de kaasstolp leven.
Iedereen ziet wat je doet. 'Ga je wel goed om met ons belastinggeld?'
Dan zie je een aantal knelpunten, bijvoorbeeld bij opdrachtgeverschap.
Wat we zien en wat we vaak minder expliciet maken,
is als we een opdracht verstrekken dat we vaak in de valkuil stappen van:
Opdracht geven is het verstrekken van een opdracht.
Terwijl je de vraag kan stellen:
Wat is dan de vraag die je aan de opdrachtnemer stelt?
Een van de elementen die erin zit is: hoe scherp is jouw vraag?
Dat betekent bijvoorbeeld dat je de keuze kan maken:
'Doe dit voor mij.'
'Ga voor mij een broodje halen', om het zo maar te zeggen.
'Doe dit met mij', we gaan samen iets doen in deze verandering.
Of 'doe dit namens mij', dan ga je iemand mandateren.
Het mag duidelijk zijn, afhankelijk van het type opdracht
krijg je ook een andere interactie met de opdrachtnemer.
Die patronen zie je overal terugkomen.
Maar vooral het patroon dat we regel- matig niet scherp genoeg verwoorden
wat we van de ander verwachten.
Of impliciet denken: de opdrachtnemer snapt wel wat ik bedoel
en dan zijn we weg. Dus het scherper krijgen van: 'wat wil ik bereiken?
Hoe gaan we dat samen doen? Wie is mede-eigenaar hiervan?
Wat ga ik met de opdrachtnemer doen?' Dat komt door de hele overheid terug.
Dat is niet uniek voor de overheid. Ik hoor het ook van vrienden en collega's
uit de profit-organisaties.
Dat is een interessant punt dat je noemt:
'Doe het met mij, namens mij, of voor mij.'
Want vaak merk ik toch dat mensen bij de opdrachtgever
een soort hiërarchie ook ervaren.
De opdrachtgever is als het ware hoger dan de opdrachtnemer.
En de opdrachtgever moet vooral duidelijk zijn
in wat hij of zij van de opdrachtnemer wil.
Ik begrijp dat jij dat anders ziet.
Ja, eigenlijk praat je over een aantal zaken.
Aan de ene kant over de verwachting over en weer.
Hebben we hetzelfde beeld waaraan we willen werken?
Maar er zit ook iets in,
dat heeft met project- en programmamanagement te maken.
Ik wil daar een tekeningetje bij maken als het kan.
Wat wij vaak zien, is dat we ergens, ik doe het maar even zo,
een politieke opdracht krijgen.
Vanuit een regeerakkoord, de minister of iemand anders
en dat komt ergens het ambtelijk apparaat binnen.
Lees even gemakshalve op het topniveau van het ambtelijk apparaat.
Dat kan bij de Rijk zijn, een DG, of een gemeentesecretaris.
Dat kan een GMT-lid zijn of provinciesecretaris.
En eigenlijk zegt die: wacht even, ik ben wel opdrachtnemer.
Opdrachtnemer
van een opdracht uit de politiek, maar tegelijkertijd ben ik opdrachtgever.
Iemand die met mij, namens mij of voor mij gaat uitvoeren.
Dus ik krijg hier ergens, stel dat dit even de directeur-generaal is,
dan zegt ie: 'ik heb er niet voldoende tijd voor, zit in de portefeuille van...
Ik zet het door aan de directeur in mijn directoraat.'
Maar die directeur is dus tegelijkertijd
opdrachtnemer van de opdracht van de DG.
Maar opdrachtgever, dan zegt ie:
'wacht even, ik kan dat niet. Daar heb ik extra steun voor nodig.'
Dat is een programma...
manager, bijvoorbeeld.
Zegt de programmamanager: 'Ik ben opdrachtnemer van jouw opdracht,
maar ik ben opdrachtgever naar de projecten die onder mij ressorteren.'
Dus hij heeft weer een boel opdracht- nemers in de vorm van projectleiders.
En zo zie je het allemaal doormandateren.
En wat hier de crux is, is dat je zegt:
Als je hiernaar kijkt, brengen we heel veel hiërarchie
in opdrachtgeverschap,
maar het is de hiërarchie van de staande organisatie.
Maar is die hiërarchie van de staande organisatie
zo belangrijk in de projectorganisatie?
Moet je dat niet veel meer op basis van gelijkwaardigheid doen?
We zijn samen op pad om aan deze opgaven te werken
en dat is niet hiërarchisch.
Besluitvorming is hiërarchisch, samenwerking is niet hiërarchisch.
Wat we zien is dat wij de hiërarchische vorm vaak terug laten komen
in de projecten en programma's, dezelfde hiërarchie,
als we ook in de staande organisatie zien. Dat geeft verwarring.
Ben je nou opdrachtgever of ben je nou DG?
Ben ik nou opdrachtnemer of -gever als directeur?
Op die manier zie je de verwarring terugkomen.
Ja.
En dat betekent dus eigenlijk, wat je impliciet zegt:
ga daar ook goed het gesprek over aan met elkaar
over de verschillende rollen die je hebt.
-Absoluut.
Als je van boven naar beneden gaat, zou je hier kunnen zeggen:
Wat is het doel, de scope, wat zijn de kaders
en de uitgangspunten
waarlangs je wil gaan werken?
Alleen hier gaat het over de politieke opdracht.
Hier gaat het over de opdracht die je doorzet in het ambtelijk apparaat
en hier: wat zijn de opdrachten aan de verschillende programmamanagers?
Wat zijn doel, scope, kader en uitgangspunten van het project?
Zo vertaalt zich dat naar beneden. Maar van beneden naar boven
krijg je dan de vraag:
Wat zijn dan de resultaten?
En hoe vertaalt het resultaat van een project zich
naar de doel van het programma?
En hoe vertaalt dat doel zich dan weer
naar het effect wat we willen bereiken?
Wat we nu vaak zien,
is dat veel van de gesprekken gaan over de resultaten van projecten,
en wordt de koppeling tussen de bedoeling
en het effect en de maatschappelijke opgave,
want daar doen we met z'n allen voor,
dat we dat uit het oog verliezen.
Heel herkenbaar. Ik heb weleens een directeur in onze sessie horen zeggen:
'Als ik van mijn DG een opdracht krijg...
Ik ga dat gesprek niet aan over het doel en de scope.
Hij ziet me aankomen.'
Jouw boodschap is: toch doen.
-Absoluut.
Als jij niet weet wat de ander verwacht, heb je een probleem.
We hebben, ik durf het nu te zeggen,
ik ga niet zeggen welke het was, in 2010 een gateway review uitgevoerd,
en toen interviewden we de toenmalige DG
en die zei: dit is wat de minister wil.
Tijdens de review hebben we ook de minister geïnterviewd
en toen bleek dat de DG 180 graden de andere kant opging
dan wat de minister bedoelde,
omdat ze dat gesprek niet voldoende gevoerd hadden.
Dit is maar een voorbeeld,
maar we hebben nu zoveel honderden reviews uitgevoerd.
Je ziet gewoon vaak dat het niet bespreken
'wat is de bedoeling? Wat verwachten we van elkaar?'
dat dat een probleem is.
Misschien even een zijstapje.
Soms is er ook wat verwarring over de rol van de eigenaar en de opdrachtgever.
Kan je daar nog iets over zeggen?
Wat wij vaak zien bij de eigenaar is:
'Ik ben eigenaar van een opgave of wij zijn eigenaar van de opgave.'
Dat is wat anders dan dat je opdrachtgever bent voor een programma
of voor een opdracht. Dus wat je ziet is dat de eigenaarsrol
eigenlijk de verantwoordelijkheidsrol is die je in de organisatie hebt.
De opdrachtgever is de rol die je hebt om de verandering vorm te geven.
Dus de eigenaar... De Britten hebben dat op een hoop gegooid,
die noemen dat de 'senior responsible owner'.
Maar bij ons is de eigenaar de eigenaar in de organisatie
en de opdrachtgever is een rol die je als eigenaar van dat vraagstuk hebt.
Wat het nu nog complexer maakt,
is dat bij de meeste maatschappelijke opgaven waar we mee bezig zijn,
je niet alleen eigenaar bent.
Het zijn vaak wicked problems, problemen die we niet ineens kunnen oplossen,
dat moet stapsgewijs, telkens een stapje verder.
Maar ik kan het ook niet als één DG of één departement
of alleen als Rijk of gemeente. Dat moet je samen doen.
Dan wordt de opdrachtgeversrol natuurlijk
door een vereniging van eigenaren gedaan.
Mede door de mensen die vanuit hun staande organisatie
eigenaarschap zouden moeten vertonen op dat vraagstuk
en gezamenlijk ook de opdrachtgeversrol vervullen.
Wat we nu nog vaak zien, is een-op-een.
'Ik ben eigenaar. Ik ben opdrachtgever.' Nee:
'Wij zijn de vereniging van eigenaren
en een van deze leden treedt op namens de vereniging als opdrachtgever.
Daar moet je het over hebben. Wat we in de praktijk zien,
is dat dat soort gesprekken onvoldoende plaatsvinden.
Hoe komt dat? Heb je daar een idee van?
Is het een gebrek aan inzicht dat het belangrijk is?
Of is het een gebrek aan tijd of aandacht?
Het is een combinatie van factoren, denk ik.
Maar dat is persoonlijk. Als ik daarnaar kijk,
dan is de ene kant: we hebben veel projecten, programma's lopen.
De literatuur zegt:
niet meer dan drie, vier kan je tegelijk als opdrachtgever behartigen.
Als je ziet hoeveel verandertrajecten we binnen de overheid hebben,
zie je dat vaak de portefeuilles van de opdrachtgevers veel breder zijn.
Dus je moet gaan kiezen en selecteren, aan de hand van de opgaven.
Ten tweede: die hiërarchie is erin geslopen.
We hadden ooit...
In de jaren tachtig is projectmanagement ontstaan als een methodiek,
omdat we ontdekten dat de hiërarchische organisaties niet in staat waren
flexibel genoeg mee te bewegen voor de ontwikkelingen.
Toen hebben we dat ontwikkeld om de processen beter te kunnen beheersen,
beter te kunnen begeleiden, faciliteren en mogelijk te maken.
In de loop van de tijd is de hiërarchie die in de staande organisatie zit
ook in ons projectmanagement geslopen.
Daardoor is projectmanagement niet meer dat wendbaar bootje,
maar is het onderdeel geworden van een grote container
die maar heel langzaam kan veranderen.
Interessant. Ik zie dat er een paar vragen zijn binnengekomen.
Mooi, interactie. Leuk.
-Zeker.
We hebben ook geen strakke lijn afgesproken,
dus het is ook leuk als er wat vragen tussendoor komen.
Ik zie hier een vraag: 'Ik hoor Pieter nu ook zeggen
dat een loepzuivere definitie van de rollen in een programma of project
van wezenlijk belang is.'
'R-A-S-C-I,' ik weet niet helemaal wat dat is.
RASCI-modellen.
-Kijk.
'is dan een simpel modelletje om het gesprek daar over te voeren.'
Is dat een...
-Dat zou een hulpmiddel kunnen zijn.
RASCI-modellen zijn prima om op die manier de verdeling te maken.
Wie doet wat, hoe zitten de verantwoordelijkheden?
En ik vind het mooi, het laatste wat deze vragensteller aangeeft:
Het is goed om het gesprek daarover te voeren, want ik denk dat dat de crux is.
Het gaat niet om: staat het mooi op papier hoe we het moeten doen?
'Hebben we het met elkaar gedeeld en houden we elkaar scherp
in de uitvoering van die rollen?'
Want wat we bij gateway vaak zien, is dat we prachtige rapporten zien,
die vallen bij ons toch onder het mom van APMK'tjes.
Dat staat voor 'als de papieren maar kloppen'.
Maar als dat klopt, kan je het mooi verantwoorden,
maar papier gaat dan niet bewegen.
En juist zo'n RASCI-model kan heel goed gebruikt worden
als een soort projectieplaat om met elkaar het gesprek op gang te houden,
maar ook niet alleen aan het begin, maar tijdens het hele proces.
Doen we het dan goed samen? Vervullen we onze rollen goed?
Zijn we zuiver? Doen we het goed?
Zonder, want dat zien wij in de praktijk ook wel,
dat mensen het RASCI-model toepassen,
maar dan wordt het rigide: 'Dit is van mij en dit van jou'.
Je zult wel dat RASCI-model vanuit het wij-gevoel...
Kan best wel zijn dat ik iets voor jou doe,
ook al is het niet mijn rol, omdat we gezamenlijk aan die opgaven werken.
Dat heeft weer te maken met die gezamenlijkheid. Niet de hiërarchie,
maar de gezamenlijkheid van het werken aan het vraagstuk.
Helder. Jij zei net:
We doen ook overal analyses over de gateways.
Dus als je nou van een afstand kijkt, zijn er dan grote patronen of trends,
de dingen die je terugziet?
-Dit is een van de trends,
dat we het gebruik van project- en programmamanagementmethoden,
niet hiërarchisch bedoeld, toch hiërarchisch maken. Dat is er een.
Het niet expliciet maken van wat ik als opdrachtgever verwacht
en hoe we willen samenwerken.
Wat we vaak zien is dat we toch snel vergeten dat we ooit begonnen
met een maatschappelijke opgave, maar het project wordt het doel
in plaats van de opgaven. Dus kijk of het project nog steeds aansluit
bij de opgaven waarmee we bezig zijn.
Dat betekent dat we vaak veel discussies op projectniveau hebben,
waar misschien het antwoord zou moeten zijn:
Het project heeft resultaat, laten we stoppen en een nieuwe starten,
zodat we beter aan de opgaven kunnen werken.
Wat je ook ziet in dit plaatje zijn meerdere projecten.
Een van de geleerde lessen dat we vaak onvoldoende op samenhang sturen.
Er lopen meerdere projecten. Hoe beïn- vloeden die elkaar en wat dragen die bij?
En zo zijn er nog meer lessen te trekken,
maar dit zijn vanuit dit plaatje de eerste.
Ja. Een van de dingen die we ook vaak horen,
is dat er heel erg op inhoud gestuurd wordt.
Heel erg op resultaten.
Ik weet dat jij daar een mooie tekening bij hebt.
De focus van veel rapportages
en veel dashboards ligt erg op feiten.
Tijd, geld, en 'heb ik het productje geleverd?'.
Maar ook daarvoor geldt weer: je moet uitkijken dat geen APMK'tje is.
Het tweede wat we vaak zien, en dat vond ik wel mooi, een collega zei ooit:
'Onze dashboards zijn erg gevuld met watermeloenen.'
Hoezo? 'Ze zijn rood van binnen, maar groen van buiten.'
Waarmee wordt bedoeld:
In hoeverre weerspiegelt het dashboard de echte stand van zaken?
En waardoor komt dat? In 2014/2015
zagen we op basis van de analyses uit de gateway reviews:
Laten we eens kijken, waar besteden wij nou aandacht aan
tijdens de projecten, de reflecties en het beheersen van de projecten?
En toen zagen we eigenlijk dat er vier aspecten van belang zijn.
Dit is jouw befaamde klavertje.
-Het geluksklavertje.
En er is ook een boek, 'Gelukkig veranderen',
want veranderen kan leuk zijn, maar vaak is het frustrerend.
Dus wij hopen met het geluksklavertje wat meer plezier te krijgen
in de veranderingen die nodig zijn.
Er zijn vier aspecten van belang om bij elkaar te houden.
Inhoud: dat betekent wat ik net zei, het effect wat we willen bereiken,
het doel wat we voor ogen hebben,
maar ook de resultaten die we willen boeken.
Dat is het blaadje 'inhoud'.
Het tweede blaadje is 'proces en procedures'.
Als je iets wil gaan doen, zal je dat met elkaar moeten doen.
Je moet afspraken maken: hoe doe ik het? Hoe vliegen we het aan?
Welke methoden kiezen we? Hoe werken we samen?
Hoe zijn de processen ingericht? Hoe informeren we elkaar?
Dat is het proces-blaadje. Eigenlijk is het: hoe doe ik het?
Maar dan ben je nog niet aan het veranderen. Er is nog een ander aspect,
want als we de gateway reviews bekijken en we spreken met opdrachtgevers
en met de reviewers, dan zeggen ze ook: 'Wacht eens even,
het is en blijft mensenwerk, dus we moeten samenwerken.'
Dus dat is het blaadje 'relatie'. Hoe werken wij samen?
Wie zijn erbij betrokken? Hoe communiceren met elkaar?
Hoe doen we dat? Dus eigenlijk: wie doet het?
En soms kan je ook zeggen: met wie doe ik het?
En het vierde blaadje, ik noem het altijd een buzzword,
dat is cultuur. Maar feitelijk zijn dat:
Welke ingesleten patronen hebben we nou in onze organisatie?
Wat willen we veranderen met het project dat we anders gaan werken?
Oftewel: wat gaat er in onze werkwijze anders worden?
Wat zijn dan... Normaal zeggen we dan: 'zo doen we het nou eenmaal hier'.
Wat gaat er dan veranderen in het antwoord op die vraag?
Toen wij de aanbevelingen uit de gateway reviews gingen plotten,
gebeurde er iets heel bijzonders. Toen gingen wij tellen.
En toen bleek dat ongeveer 68 procent van de waarnemingen,
ging over proces. Ook aanbevelingen.
Niet van: ga eens nadenken over de bedoeling.
Nee, dan staat er: herijk de businesscase.
Of: je hebt een probleem, je hebt misschien te weinig geld.
Dan komt de opmerking: ga meer budget halen.
Maar de vraag is: wat hebben we nodig om dat voor elkaar te krijgen?
We gaan heel erg op deze kant zitten.
Wij noemen dat 'de blauwe kant', de procedures, et cetera.
De blauwe kant in het klavertje heeft een andere betekenis. Wij noemen dat:
zuurstofgebrek.
Waarom noemen wij dat zuurstofgebrek?
Omdat de mensen die de verandering moeten vormgeven,
de zuurstof van de organisatie, te weinig wordt benut.
En sinds de introductie van het geluksklavertje
zijn we meer aandacht gaan besteden aan de relationele, culturele aspecten,
maar gaan we ook meer vragen stellen. Een voorbeeldje:
Als ik te lang aan het woord ben, moet je het zeggen.
Om een voorbeeldje te geven:
Als ik een gateway review uitvoer,
spreek ik ook iemand die bijvoorbeeld in een stuurgroep zit.
Dan vragen we aan degene: Wat is nou de reden, vanuit de relationele kant,
dat jij in die stuurgroep zit?
Hoe verbind jij je dan met die opdracht?
Dan krijgen we drie soorten antwoorden. De een zegt:
'Ik was de laatste die bukte, dus ik moest wel.'
De tweede zegt: Ik behartig de organisatiebelangen hier.
En de derde zegt: Ik geloof in de verandering.
De eerste twee zijn niet echt profijtelijk
voor de verandering die we vorm geven. Dus de vraag is relationeel.
'Hoe heb je in de stuurgroep dan met elkaar gesproken?
Voel jij je mede-eigenaar?
Voel jij je medeverantwoordelijk voor de verandering?
Of doe je het omdat je calidad de qua dat maar moet?'
Dat maakt heel veel uit. Dus dat klavertje
heeft ook het gesprek geïntroduceerd om deze aspecten...
De vraag: Geloof je er zelf wel in, in zo'n vraag?
Regelmatig hoor je: eigenlijk niet, maar we proberen de schade te beperken.
Of: Ik geloof er wel in, maar ik weet niet hoe ik het moet doen.
Heb je dat ook in je stuurgroep of met de projectorganisatie besproken?
Vaak wordt daar het antwoord op gegeven:
'Dat kunnen we misschien wel beter doen.' En eigenlijk wat je ziet:
Het gaat heel erg om de dialoog.
Daar zouden we meer aandacht voor moeten hebben.
Maar dat staat op gespannen voet met de hoeveelheid werk en stress.
Dus dat is best wel een dilemma.
Ja, ik denk dat dat voor velen herkenbaar is
die ook deelnemen aan een stuurgroep.
Waarbij zij zo nu en dan daar eens een uurtje aan besteden,
daar een enorme hoeveelheid documenten en voortgangsrapportages
op zich af krijgen,
als die over IT gaan dat ook nog best wel lastig vinden,
om dat goed te begrijpen, die taal goed te spreken.
En dan worden zij geacht om beslissingen te nemen daarover.
Ik ga je even onderbreken, want het is leuk dat iemand in een stuurgroep zit,
maar heb ik als stuurgroeplid aangegeven welke informatiebehoefte ik heb?
Ik heb regelmatig in stuurgroepen gezeten,
maar dan wil ik niet alle bouten en moeren-rapportages hebben.
Dan wil ik als besluitvormer op strategisch niveau weten:
Wat is de impact voor het project of programma waarmee we bezig zijn?
Het kan zijn: ik heb een aanbestedingsvraagstuk
of 'we zijn nog bezig met technische discussies',
maar die discussie hoef ik niet te horen.
Dat ik weet dat er een technische discussie is, is genoeg.
Juist bij ICT hebben we vaak de neiging om te denken dat we op stuurgroepniveau
alle IT-ins en outs moeten begrijpen om besluiten te kunnen nemen.
Nee, je moet afspraken maken met je programmamanager of projectleider
die de voortgang rapporteert of de dilemma's neerzet,
dat hij dat doorvertaalt naar jouw perspectief als opdrachtgever
en niet vanuit het perspectief van de ontwikkelaar
of van de technisch deskundige.
Dat is een belangrijk punt dat aansluit bij een van de eerder gestelde vragen,
maar dit is een mooi moment om dat nu in te brengen.
Heb je suggesties om onbewuste of onwillige opdrachtgevers
op een effectieve manier bewust te maken
van hun rol en verantwoordelijkheid?
Mensen zullen zeggen: Dat heeft te maken met digitalisering, daar ben ik niet van.
Zoals jij als ik het goed begrijp aangeeft:
Het gaat niet echt over de digitalisering en de operationele opgaven,
maar het is meer strategisch.
Ja, het gaat erom: Hoe ga ik anders werken?
En wat betekent dat voor de wijze waarop we willen samenwerken?
Een van de dingen is,
ik ga dat toch een 'Loesje-poster' noemen.
Er is een mooie Loesje-poster die zegt: Leven is het meervoud van lef.
Eigenlijk gun ik iedereen veel meer lef, ook in de vorm van opdrachtnemer.
Toon het lef om die vragen te stellen.
En ga dan niet, want zien vaak zien, dan stel je een moeilijke vraag,
dan zegt de opdrachtgever: Dat weet ik niet, dat is techniek.
'Daar heb ik jou toch voor.'
Dan zijn er twee elementen. Dat klopt. Aan de andere kant: dat klopt niet.
Stel dan de vraag: Wat verwacht je dan van mij?
Wat is dan het vraagstuk wat ik voor jou kan oplossen?
Dus toon het lef ook om die vragen te stellen.
Zorgt ervoor dat het noodzakelijke gesprek plaatsvindt, al vanaf het begin.
Want als je de eerste vraag, en dat wil ik graag meegeven
aan programmamensen en projectleiders. Je hebt maar één keer het eerste contact.
Op het moment dat je bij de opdrachtgever komt om te kijken
wat zijn vraagstuk is en welke opdracht je dan gaat doen voor deze opdrachtgever,
welke randvoorwaarden ga je dan stellen om de opdracht te accepteren?
Mijn advies is: vaak zijn het inhoudelijke en procedurele randvoorwaarden.
Geld, personeel, et cetera.
Maar welke randvoorwaarden vanuit relatie en cultuur stellen wij dan?
Bijvoorbeeld:
Zijn wij samen op pad met deze opgave?
Gekscherend: mag ik jou 's nachts wakkerbellen als ik een dilemma heb,
als blijkt dat doel, scope, kaders of uitgangspunten niet meer toereikend zijn?
Voel jij je dan ook medeverantwoordelijk?
Oftewel: stel ook de culturele en relationele randvoorwaarden
om gezamenlijk succesvol te kunnen zijn.
En dat is belangrijk, want dan heb je ook naderhand
de goede informatie die je nodig hebt om te kunnen starten,
maar ook de dialoog van begin af aan neergezet.
Doe dat de eerste keer niet en naderhand kom je op een knelpunt,
dan heb jij het probleem.
Dan heb jij namelijk het probleem wat je hebt gezegd op te lossen, niet opgelost.
Dan krijg je een ander soort dialoog. Dus laat dit van begin af aan aan bod komen.
Ik heb vragen, maar ik zie dat er ook vragen binnenkomen.
Dus ik vind het wel leuk om die dynamiek te gebruiken.
Het is een lang verhaal, maar ik zal het snel voorlezen.
Het lastige is dat bij het niet bereiken van het gewenste resultaat
de eigenaar wordt aangesproken en niet de opdrachtgever.
Dus blijven alle eigenaren zich ook als opdrachtgevers gedragen
en is er steeds meer control en steeds meer belemmert die control
de wendbare ruimte die programma's nodig hebben.
Hoe kijk jij daarnaar?
Ik denk dat hier twee verschillende antwoorden op te geven zijn.
Het eerste antwoord is, ik herken het patroon,
maar dat heeft te maken met dat wij risicomijdend bezig willen zijn.
Het moet binnen tijd en geld, et cetera.
De vraag is: ben je met de goeie kaders gestart?
We redeneren vaak vanuit: de wereld is maakbaar en voorspelbaar.
Dus als ik de opdracht accepteer, weet ik dan al wat ik ga opleveren,
hoeveel het gaat kosten, et cetera. En raad eens:
in 99 procent van de trajecten waarin we zitten, klopt dat niet.
Het duurt vaak langer, kost meer geld,
er komen meer ontwikkelingen in de buitenwereld die van invloed zijn.
Vanuit het controleperspectief is het controlemechanisme vaak te veel
vanuit het controleren in plaats van beheersen.
Is herkenbaar voor velen.
Het tweede wat ik daarop zou willen zeggen, is ook:
De eigenaar kan ook opdrachtgever zijn,
maar maak dan, en dat heeft met die relatie te maken, duidelijk:
Praat jij dan met de persoon als eigenaar
of praat je met je collega als opdrachtgever?
Daarbij komt het plaatje van net
om de hoek kijken. Ik ga 'm even terugpakken.
Hiërarchisch gezien is dit de eigenaar.
Maar functioneel gezien kan die ook als opdrachtgever fungeren.
Vanuit die rol heeft ie een andere verantwoordelijkheid
in de lijnorganisatie dan als opdrachtgever voor een verandering.
En dat zul je ook expliciet moeten maken in het gesprek.
Dat heeft weer te maken met de dialoog.
Zodat je zegt: ik praat nu als eigenaar of ik praat nu als opdrachtgever.
Daar heb je als opdrachtnemer ook een rol in, om dat scherp te krijgen.
Vanuit welke rol zegt iemand dat dan?
Helder, dank je wel.
Ik weet niet of dat een antwoord is op de vraag,
maar anders zien we 'm vanzelf in de chat terugkomen.
Een vraag die ook aansluit bij wat jij net zei over:
dingen gaan toch een beetje anders dan je van tevoren had bedacht:
Is de gateway-systematiek meegegroeid met nieuwe werkwijzen zoals agile?
Ja.
Dat is het korte antwoord, ik zal 'm ook toelichten.
Kijk, gateway review is eigenlijk vormgegeven,
komt voort uit OGC, ook eigenaar van PRINCE2 en MSP.
Dan heb je heel dat... businesscase, plan van aanpak, realisatiefase,
implementatiefase, afrondingsfase
en daar zit ook de gateway-typologie op.
Los daarvan hebben wij in Nederland, de zogenaamde 'Dutch approach',
er ook voor gezorgd dat wij een starting gate hebben,
gateway review in de beleidsfase om te kijken of de randvoorwaarden er zijn.
We hebben de health check om te optimaliseren waarmee we bezig zijn.
Maar we hebben ook, als je het hebt over agile- en scrumachtige bewegingen,
daar het uitgangspunt van:
als iemand besluit met agile/scrum te werken
dan nemen wij dat als uitgangspunt tijdens onze reflectie op
waar iemand mee bezig is.
Wat betekent dat je soms zegt: wacht eens even.
'Ik heb nu een aantal sprintjes afgesproken in dat proces.
Kan je eens kijken of het na zes weken goed is gegaan?'
Daar zou de gateway-systematiek niet 1-2-3 op inspelen.
Maar wel: heb ik het pad zoals ik het wil aanvliegen met de verschillende sprinten
en hoe ik dat wil gaan doen, en werk ik voldoende gericht
en resultaat gestuurd, wat bij agile nadrukkelijk geldt,
dan spelen we daar gewoon op in.
En we hebben in de community voldoende mensen
die daar kennis en kunde van hebben, dus we groeien mee.
Daarnaast, en dan ga ik even terug naar corona.
Daar zien we een boel crisisinterventies ontstaan.
Normaal heeft gate review een voorbereidingstijd van tien weken,
maar we hebben ook een gateway reflectiedag, die kan binnen vier weken.
Dat betekent dat je snel feedback krijgt
of de maatregelen die je wil nemen wel of niet goed zijn.
Zo'n reflectiedag is ook prima inzetbaar
als je in een sprint van tien weken even wil kijken
of je op koers zit om dat sprintje goed af te ronden.
Dus daar kan je gebruik van maken. Op die manier zijn we ook 'n beetje adaptief
meegegaan in het de ontwikkelingen in de buitenwereld.
Oké, leuk om te horen.
Ik wil even een ander punt aansnijden.
Wij zitten als overheid vaak in een politiek-bestuurlijke,
eigenlijk altijd in een politiek-bestuurlijke context,
waarin soms vanuit de politiek of de organisatie
extra wensen komen die mogelijk verstorend kunnen zijn voor het proces.
Dat is één aspect.
En soms blijkt ook, je gaf het zelf ook al aan,
is niet alles van tevoren uit te denken.
Er komen nieuwe ontwikkelingen, er zijn technische issues,
ketenpartners komen ineens met wensen. Het ontwikkelt zich.
Wat heel goed past bij een agile-methodiek, denk ik.
Maar is dat ook iets wat jullie zien?
Er zijn een paar dingen die je benoemt, die ik even los wil benoemen.
Het ene heeft namelijk te maken met: als je een project doet,
heeft dat een lange doorlooptijd.
Terwijl dat project loopt, verandert iets in de buitenwereld.
Dan is de eerste vraag:
Hoe gevoelig is dan de programma- organisatie voor deze ontwikkelingen?
Hoe vindt dan het gesprek tussen de opdrachtgevers
en de programmaorganisatie plaats om daarop in te spelen of niet?
Een van de valkuilen die we regelmatig zien,
we noemen dat de 'scope creep', dat we maar blijven 'bijjongen'
met nieuwe functionaliteiten of wensen,
waardoor het programma zoals het ooit gestart is, niet meer hetzelfde is,
maar wel nog op dezelfde manier gestuurd wordt.
Gateway review geeft dan toch het advies: hold your horses.
Even herijken voordat je verdergaat.
Een van de ondertitels van gateway review is weleens geweest
'stoppen zonder stilstaan'.
Je gaat door, maar gaat wel even herijken.
Relevant, maar doen we nog de goede dingen?
Heeft weer te maken met doel, scope, kaders, uitgangspunten.
Als die verandert, heb je in principe een ander programma of project?
Wees je daarvan bewust, want het heeft consequenties voor wat wel en niet kan,
maar ook welke middelen je daarvoor nodig hebt.
Het tweede is dat wij vaak zien,
en daar zie je ook het spanningsveld tussen agile- en projectmatig werken,
is dat wij een eigenaar zoeken en dat het in één keer goed moet.
Dus wat we zien en ik ga toch maar even een plaatje tekenen:
Als je kijkt naar de beheersing van projecten en programma's,
maar ook van je organisatie, zijn er twee assen die je daarvoor kunt gebruiken.
Eén is namelijk: de wereld is stabiel. Oftewel, er verandert niks.
Of de wereld is dynamisch, oftewel:
er vinden bewegingen plaats in mijn omgeving
of binnen mijn eigen organisatie die iets kunnen betekenen.
Iets is bij jou bekend
of iets is bij jou onbekend.
Als je kijkt hoe wij vaak met programma's omgaan,
wat we in de gateway reviews tegenkomen,
gaan we ervan uit dat de wereld stabiel is en dat we alles weten.
En dat noemen we in dit plaatje: planmatig risicomanagement.
Standensystematiek.
Wat zijn m'n potentiële risico's en mitigerende maatregelen
en ik hou m'n logboek bij.
Soms zeggen we: De wereld is dynamisch,
dus we doen dynamisch risicomanagement.
Dat is eigenlijk dezelfde systematiek.
Bekende risicogebieden, mitigerende maatregelen en vervolgens monitoren.
Als we ervan uitgaan dat de wereld stabiel is,
maar we informeren elkaar niet goed, niks menselijks is ons vreemd,
dan zie je dat we hier vaak te maken hebben met,
noem het maar simpel, crisismanagement.
Het oplossen van dingen die we hadden kunnen weten.
Hebben we toch last van, gaan we iets mee doen.
Eigenlijk zitten de meeste van onze projecten in een dynamische wereld,
je gaf het zelf al aan, en we kunnen niet alles weten. Niet in de binnenwereld,
technologische ontwikkelingen vinden plaats,
de complexere sociale maatschappij is lastig,
dus hier zeg je: hoe ga ik om met onzekerheidsmanagement?
Oftewel, hoe goed ben ik voorbereid op het onvoorspelbare?
Dit is wat we vaak tegenkomen bij projecten en programma's.
Dit is wat de eigenaar graag wil, namelijk één antwoord
en zeker weten: ik heb het nu besloten, het gaat goed.
Ik maak er weleens een flauw grapje bij. Heb jij een rijbewijs, Ronald?
Jazeker.
Heb jij een risicolog op je dashboard liggen van je auto als je rijdt?
Nee.
Waarom doen we het dan bij projecten en organisaties wel?
Want feitelijk sturen wij onze organisatie op een spreadsheet.
Terwijl als je een auto rijdt, en zo zou je ook je organisatie...
dan heb je ramen, spiegels, soms ook een medepassagier,
soms ben je daar blij mee, soms niet, maar die helpen jou in beeldopbouw
en je bent continu bezig om te kijken wat er gebeurt in de omgeving.
Is het relevant? Moet ik daar wat mee?
Veel van de projecten worden gestuurd op het spreadsheet.
Als er iets verandert, wordt misschien het spreadsheet aangepast en that's it.
Maar dit zijn de dingen die je wist.
Maar de meeste projecten gaan fout door dingen die we niet wisten.
Omdat we gefocust zijn, dus ik zeg weleens gekscherend:
Risicomanagement, ik hou er niet van, want dat zijn onbedoelde verstoringen.
Management is sturen, dus je stuurt op onbedoelde verstoringen.
Het klinkt misschien heel flauw. Maar wat je ziet, bij veel projecten
kijken we naar de risicologs en dat leidt af van het resultaat.
Je zou bij dit concept van risico- management de vraag kunnen stellen:
Moeten we dat wel willen?
Moeten we niet meer naar zekerheidsmanagement?
Want je weet...
Als we straks naar huis gaan, ga je een boel dingen tegenkomen
waardoor je wel of niet veilig thuiskomt.
Dus de vraag is: hoe kom ik zo goed mogelijk van hier straks thuis?
Met alle mogelijke onzekerheden, bedreigingen die voorbijkomen.
Dus je wil je slaagkans vergroten,
maar dan ben je gefocust op je doel
en je bent iedere keer alert op: wat ben ik aan het doen?
En eigenlijk hoort daar één ding bij: we noemen dat het BOB-model.
Ik kan 'm even apart schrijven.
Want dat is voor dit kwadrant, ik noem het even BOB.
Je doet iedere keer aan beeldvorming.
Dat is niks anders dan kijken: wat zie ik, wat hoor ik, wat ruik ik, et cetera.
Continu beeld opbouwen.
Dan heb je iets gezien, dan is de vraag:
oordeelsvorming.
Wat vind ik daar dan van?
Ik zie iets, ik heb iets gegeten, vind ik niet lekker.
Besluitvorming is daarna pas:
'In de toekomst wil ik dat niet meer eten.'
En eigenlijk doe je dit duizenden keren per dag.
Beeldvorming: er staat een stoel, hij staat dichtbij genoeg, ik kan gaan zitten.
Maar dat geldt voor alle ontwikkelingen in het project.
Je bent continue, door dit goed te doen, dit proces
ben je veel meer in control
en ben je flauw gezegd voorbereid op het onvoorspelbare.
Maar dit is een attitudekwestie, niet een procedure.
Dus als je het klavertje weer pakt, is onze cultuur risicomijdend.
Blauw neerzetten.
Proces is planmatig risicomanagement,
terwijl onze cultuur voor succesvol bezig zijn, veel meer zou zijn:
slaagkansvergroting
doormiddel van veel betere beeldopbouw, communicatie en samenwerking.
Ja, dat is heel helder.
Het vraagt ook wel iets meer van je als opdrachtgever, veronderstel ik.
Want in die wereld die heel planmatig is,
dan leun je een beetje op jouw opdrachtnemer of programmamanager.
En helemaal als het over IT-projecten gaat waar je je
ietwat ongemakkelijk bij kan voelen.
Als het allemaal planmatig is, wordt het gewoon uitgevoerd.
Als het onzeker is en als je voortdurend alert moet zijn, wat hier ook uit blijkt,
dan vraagt dat meer en misschien ook wel meer tijd van je
als opdrachtgever.
En vaak hebben mensen die tijd niet. En dan?
Er zijn twee antwoorden: je voorkomt schijnzekerheid,
want je kan zeggen 'ik maak een plan', maar dan kom je in een APMK'tje terecht.
Het tweede is: eigenlijk kan je niet meer dan drie,
maximaal vijf programma's goed runnen als opdrachtgever.
Dus daar zit een spanningsveld in het werkveld.
Maar als we dat tegelijkertijd van elkaar weten,
is het des te belangrijk om goede afspraken te maken
met de opdrachtnemer, de programma- manager of changemanager:
hoe gaan we met elkaar om?
En welke samenwerkingsvorm past hier dan bij?
Want ik kan best een gemandateerde opdrachtnemer neerzetten:
'Jij mag dat namens mij doen.'
Maar dan je moet je afspreken: Wat betekent dat dan?
Dus je moet ook voorkomen dat alles over de tafel van de opdrachtgever gaat.
Dus het heeft te maken met de wijze van zekerheid afspreken.
Mandatering, hoe gaan we met elkaar om?
Maar als je met elkaar in gesprek bent, is dat minder lastig.
Er zijn sommige mensen die zeggen: Als je niks van mij hoort, gaat het goed.
Dan word ik altijd onrustig.
Dan denk ik: gaat het nou goed of heb je geen tijd om met mij te praten?
Dan zeg ik: Ik wil even een afspraak. Wanneer kan ik jou even spreken?
Dan kan je zeggen: Het gaat goed, dus ik voel me senang.
En ik zie dat het goed gaat. Nou, mooi.
Dan kan dat een uitkomst zijn. Ja.
Maar het is niet zo dat door drukte de eigenaarsverantwoordelijkheid vervalt
of daarmee belegd kan worden bij de opdrachtnemer.
Precies. Blijf erover in gesprek en maak er afspraken over.
Ik wil nog even een ander thema aanspreken
wat ook bij veel opdrachtgevers een vraagstuk is:
Hoe zorg je nou voor voldoende draagvlak binnen de organisatie?
Het is natuurlijk belangrijk dat je de mensen meekrijgt.
Heb je daar nog kwesties voor?
Is jouw definitie van draagvlak dan 'de mensen meekrijgen'?
Dat is een goede vraag. Dat is natuurlijk meer dan dat.
Want het betekent ook de gebruiker meenemen.
Dat betekent je partners meekrijgen.
Het is veel omvattender dan dat.
Wat je dus ziet is dat eigenlijk, en dat is,
excuus voor het lawaai, wat wij vaak zeggen:
Je kan nooit vroeg genoeg een reflectie inbouwen
en je kan niet vroeg genoeg de dialoog starten.
Dus wat vanuit het gateway- perspectief belangrijk wordt gevonden,
en ook door onze reviewers, is, hoe eerder je de dialoog start,
hoe eerder je met elkaar dat gesprek voert, hoe succesvoller je gaat zijn.
Dat is 1.
Dus denk goed na wat je wil, maak goede afspraken over hoe je gaat samenwerken,
maar maak er ook niet iets geheimzinnigs van.
Een van de dingen die je ziet,
is dat wij vaak vanuit een bepaald beleid
of vanuit bepaalde methodologie iets bedenken
en dat dan plat gezegd over de schutting gooien
en dan mag de ander dat gaan toepassen.
Onder het mom van: we hebben erover nagedacht,
je hoeft alleen nog maar uit te voeren.
Raad wat,
vaak is dan de zinsnede 'is het beleid of is er over nagedacht?'.
De uitvoerbaarheid is een belangrijk element.
Dat zien we ook terugkomen in de rapporten, de laatste evaluaties.
Dus als je praat over draagvlak betekent dat dat je heel goed moet weten:
Wie zouden betrokken moeten zijn bij het onderkennen van het vraagstuk?
Maar ook: wie zouden er betrokken moeten zijn bij het oplossen?
De oplossing van het vraagstuk.
Een van de dingen die wij vaak zien, we werken opgavengericht,
is toch dat we dan de opgaven doorvertalen naar een programma.
En dan gaan we weer de usual suspects uitnodigen
om mee te denken in het vraagstuk.
Maar als je bij opgavengericht werken het blaadje 'relatie' neemt,
is het de vraag: Wie voelt zich verbonden en is geïnteresseerd
om mee te denken over dit vraagstuk?
Dan heb je al mensen die vanuit hun intrinsieke motivatie mee willen doen,
die vaak vanuit een andere lijn denken dan de standaard patronen
die je normaal tegenkomt. Dan creëer je al meer de interactie
en daarmee het draagvlak al in de wijze waarop je het aanpakt.
Dat is 1. 2, en dat is een bevinding van analyses van de laatste tijd:
We noemen dat 'wiel van verbinding'.
En ik ga er eentje tekenen voor alle zekerheid.
Dit is een beetje een ei, dat moet een wiel voorstellen.
In tijden van Pasen moet dat kunnen, zal ik maar zeggen.
Maar feitelijk als je kijkt naar waar we voor staan,
is toch vaak de vraag:
wat is de opgave waar we voor staan?
En die opgave zullen mensen vanuit een financieel perspectief,
personeelsperspectief of IT-perspectief anders bekijken.
Dus de vraag is: wat is nou de echte opgave
en hoe kunnen we de kracht van de diversiteit,
de verschillende invalshoeken al bij de analyse
en de vaststelling van opgave scherp te krijgen?
Dus de kracht van de diversiteit,
Meerdere disciplines, meerdere achtergronden
al bij de opgavedefinitie betrekken.
Dan is de tweede vraag:
Maar wie voelt zich dan ook mede-eigenaar?
Ik zou niet zeggen medeverantwoordelijk, Maar mede-eigenaar. Waarom?
Mensen zeggen vaak: ik voel me eigenaar.
Maar eigenlijk is dat een intentieverklaring en geen wilsverklaring.
Want als het spannend wordt, rennen we toch weg. 'Ja, maar het is van hem.'
Daarom zeg ik: de meeste opgaves kennen meerdere eigenaren.
Dus is de vraag: in hoeverre voelt de Vereniging van Eigenaren
zich ook eigenaar?
Bijna als een soort watermerkje in het contract:
'Ik ben mede-eigenaar.' Dat het er gewoon in zit.
Als je dit hebt, is het derde, want is dan eigenlijk
het gemeenschappelijk
ontwerp?
Eigenlijk: langs welke principes willen we dan aan deze opgaven gaan werken?
Even naar de bouw.
Opgave: ik wil woningen hebben.
De mede-eigenaar is een groep mensen
die een woning willen hebben.
Dus we gaan een appartementencomplex maken.
Dan is de vraag: wacht eens even, is het een modern huis?
Is een traditioneel huis?
Is het een betonconstructie? Of willen we hout? Milieuvriendelijk of niet?
Allemaal ontwerpprincipes die belangrijk zijn.
Dat geldt voor elke opgave ook, dan moet je doorvertalen:
langs welke lijn gaan we dat doen?
Dit is eigenlijk je basisontwerp om aan de opgave te werken.
Om dan succesvol te kunnen zijn,
gaat het eigenlijk ook over het samenwerkingsarrangement.
Een samenwerkingsarrangement is eigenlijk niks anders dan:
Wie is erbij betrokken? Hoe werken we samen?
Hoe vindt besluitvorming plaats? Hoe vindt dialoog plaats?
Hoe vindt verantwoording plaats? Hoe willen wij samenwerken?
En wat je ziet, is dat hier ook belangrijk is:
Meedenken is belangrijk, maar meebeslissen niet.
Dus je moet duidelijk maken: hoe lopen dan ook de beslissingslijnen?
En wat verwacht je dan van de besluitvorming aan uitleg?
Daardoor krijg je draagvlak? Ze hoeven het niet met je eens te zijn,
maar als men overeenkwam dat zo de besluitvorming loopt,
dan weet je dat je op die manier draagvlak krijgt over het proces.
Kan je nog steeds discussies hebben,
maar als je wit en zwart bij elkaar moet brengen...
Je kan niet altijd polderen naar grijs. Soms moet je wit of zwart nemen.
Als je dit hebt, is de volgende vraag: welke methode heb ik dan nodig?
Of welke instrumenten?
En wat wij dus vaak zien, we hadden het over agile,
over projectmanagement, MSP, PRINCE2.
De methode die je kiest, of het instrumentum,
is dus ook een impliciete keuze hoe je samenwerkt.
Bij PRINCE2 heb je een stuurgroep en een afwijkingsrapportage.
Bij agile/scrum heb je de business, de ontwerper en de beheerder
gezamenlijk in één ruimte zitten. Dat is een ander samenwerkingsarrangement.
Daar moeten we goed naar kijken. Het derde is: Hoe faciliteren we dan
de samenwerking?
Om maar even een voorbeeld te nemen van een projectteam,
dan is de vraag: wat betekent het nou?
Is het project nou signalerend, coör- dinerend, faciliterend of realiserend?
Wat wij vaak zien is dat de opdrachtgever van het programma verwacht
dat ie het probleem oplost, terwijl ze vaak iets maken,
lees: enablers hebben, om de lijn- organisatie beter te laten functioneren.
En daar zit de rol van de eigenaar.
Die moet zorgen dat het projectresultaat gebruikt wordt. Zie je hiernaar kijkt,
zie je vaak dat per context kan verschillen
wat het antwoord is op deze aspecten.
Als je het goed tekent, kun je dit als spaken zien.
Ik zeg altijd: als dit niet is afgestemd,
ik noemde het samenwerkings- arrangement en de methode die je kiest,
dan krijg je een slag in je wiel.
Maar als iets echt in onbalans is, knalt er een spaak uit
of is zodanig krom, je weet zelf als je fietst,
dan gaat ie tegen je vork zitten en kom je niet meer vooruit.
Dat komen we bij projecten regelmatig tegen,
omdat we onbewust
niet expliciet genoeg deze dingen met elkaar bespreken.
En dan ontstaat dus ook minder draagvlak.
Ja. Mooi, verhelderend plaatje.
Er is ook nog een vraag: Hoe ziet het eruit als je
in je programma voorbereid bent op onzekerheden?
Kan je zeggen: nou, zo ongeveer.
Als je het regelmatig met elkaar hierover hebt,
maar ook dat je, voor mij is dat, expliciet en bewust,
blijft kijken: is de wereld zoals ik 'm heb ingeschat nog steeds hetzelfde?
Dus stick to the plan, maar wel met, net als je in een auto rijdt,
je weet hoe je moet besturen en dat er dingen zijn,
maar dat je om je heen moet kijken. Hoe verwerk je dat?
Door een aantal dingen.
Dan ga ik ook een beetje gateway promoten, maar zo bedoel ik dat niet.
Zorg ervoor dat je op gezette tijden even een reflectie van buitenaf krijgt:
'Ben ik nog met de goeie dingen bezig?' Of zitten we vanuit ons enthousiasme
in een soort tunnel waardoor we de buitenkant niet meer voldoende hebben?
Dan gaat het om het goede gesprek intern, goede beeldvorming,
maar ook:
iedereen heeft zijn blinde vlekken. Dat geldt voor mij, jou en iedereen.
Dat is juist de kracht, om af en toe anderen even te laten meekijken.
Doen we nog de goede dingen en doe het op de goeie manier?
De twee woorden die daaronder zitten, zijn:
Zorg ervoor wat onbewust gebeurt,
dat we dat bewuster gaan doen.
Het kan dus helpen om iemand te vragen om eens aan te geven:
Wat heb ik nou gedaan?
En wat impliciet gebeurt,
expliciet te maken.
Juist dat impliciete is vaak het grootste risico om succesvol te zijn.
Want dat worden straks onderstromen, dingen die niet benoemd gaan worden.
Dus een heleboel dingen gebeuren impliciet.
Maak ze expliciet. Juist door dit aspect te incorporeren in jouw plan van aanpak,
en er zijn een heleboel methoden, dwarskijksessies,
allerlei dingen die je kunt organiseren,
maar door dit in je proces in te bakken en elkaar ook iedere keer te bevragen:
'Je zegt dit, maar waar baseer je dit op?'
Dus eigenlijk de verklaring te vragen in plaats van alleen het statement
wat er gezegd wordt? Waar baseer ik het op? Waar komt het vandaan?
Want dan kom je ook steeds weer terug op:
Zijn dat nog dezelfde uitgangspunten en principes?
Er komt een compliment binnen,
dat is ook wel leuk.
-Heel fijn.
Bijzonder helder verhaal, prachtige beeldspraak, top.
Dank je wel.
-Heb je vast in je zak.
Ik wil het ook nog even iets kleiner maken.
Stel nou dat je opdrachtgever bent van een IT-bedrijf
dat gewoon iets voor jou moet maken.
Je zou kunnen zeggen: 'Mooie plaatjes,
die leverancier moet gewoon doen wat ik vraag.'
Mee eens?
Kan ik me goed voorstellen, afhankelijk van het systeem dat gebouwd wordt.
Maar wat wel belangrijk is:
heb jij dan ook goed geformuleerd wat je van de ICT-leverancier verwacht?
Want hoe meer je aan de ander vraagt om het voor jou te doen,
zonder dat jij daarbij betrokken bent,
moet je veel meer specificeren wat je wil.
En dat betekent bij IT-projecten niet dat je technisch moet specificeren,
maar wel je functionaliteiten.
En wel: waar moet dat systeem met welke andere systemen samenwerken?
Hoe past dat systeem dan in mijn bedrijfsprocessen?
Wat voor type gebruikers heb ik dan?
Want de aard van de gebruikers bepaalt ook
hoe de user interface eruit komt te zien.
Wat is de systematiek? Waar komen de dataverbanden?
Is het een data-entry-systeem of wordt de data ingelezen
en is het een bewerkingssysteem?
Welke rapportages of beelden wil ik eruit hebben?
Dus op het moment dat je het meer op afstand zet,
zul je ook aan de opdrachtnemer duidelijker moeten maken
en tijd voor nemen om uit te leggen wat je nodig hebt.
En wat we in de praktijk zien, is dat we dan te makkelijk zeggen:
'Ik heb dat nodig.'
Als je niet uitkijkt: 'ik ben ook voor jou niet beschikbaar', zeggen we impliciet.
En misschien onbewust.
Dan wordt er iets gebouwd wat dan weer niet voldoet aan de wensen.
En daar krijg je spanning,
want de leverancier levert niet wat jij gevraagd hebt.
'Maar dit heb jij toch gevraagd?' Nee.
Dat komt dus omdat de dialoog niet heeft plaatsgevonden.
Wat is nou de opdracht die je mij meegeeft en wat is het resultaat?
Wanneer krijg ik decharge?
Wat we vaak zien, is dat bij veel trajecten niet wordt afgesproken:
Wat zijn de decharge-criteria op basis waarvan het project
of het contract dan ook de prestatieverklaring krijgt.
'We gaan jou betalen.'
Dat heeft ermee te maken dat we hier en hier
te weinig aandacht aan besteden op het moment dat we het op afstand plaatsen.
Als ik jou vraag 'ga voor mij een paar stiften kopen'
en je komt terug. 'Maar ik heb stiften nodig voor een whiteboard.
Dit zijn permanentmarkers, daar heb ik niks aan.
Ronald, wat ben je toch dom geweest. Ik heb toch gevraagd om stiften?' Nee.
Je hebt gedaan wat ik vroeg. Alleen ik heb m'n vraag niet gespecificeerd,
en daar zul je heel nadrukkelijk op moeten letten.
Hoe meer je zegt 'doe het voor mij',
hoe beter je moet specificeren wat je nodig hebt.
en ook daar kan je de hybride variant kiezen dat de opdrachtnemer
een paar keer terug mag komen om te kijken of ie jou begrepen heeft.
Dat moet je dan inbouwen.
Dat vraagt dus ook van jouw inzicht in hoe jouw organisatie in elkaar zit,
welke systemen er allemaal zijn, wat de samenhang tussen die systemen is.
Heb jij de mensen die die samenhang ook in beeld kunnen brengen
zodat je het ook begrijpt?
-Precies.
Het vraagt wat extra maatregelen om je eigen zaken op orde te krijgen.
Ja, dat is natuurlijk waarin we een rol voor de ceo zien
maar ook de informatiemanagers die daar een bijdrage in zouden moeten hebben
en daarbij ook de eigenaar in de rol van opdrachtgever
zouden moeten ondersteunen om tot een betere vraag te komen.
Om ook aan te geven, want dan komen we weer terug op dat eerste plaatje.
Even kijken of ik 'm terug kan vinden.
Doel, scope, kaders, uitgangspunten.
Zijn die vanuit de opgave voldoende doorvertaald wat dan,
ik neem even de projectleider, de contractant vraagt om te leveren.
Heb je dat doorvertaald? Maar als een van die vier niet helder is,
want eigenlijk zijn het de kaders:
'Dit systeem moet passen in dit ICT-landschap.'
Maar zeg je dat niet, weet je ook niet hoe dat zich tot elkaar verhoudt.
Dan kan ik een solitair systeem bouwen wat misschien heel mooi is,
maar niet past in jouw context.
Dit wordt dan cruciaal om van algemeen naar specifiek te gaan.
Daar heb je tijd voor nodig. Dat hoef je als opdrachtgever niet zelf te bedenken.
Dan kan je best de hulp van informatie- mensen en andere partijen krijgen,
maar het is wel cruciaal. Als je dat niet doet,
dan krijg je een mooi resultaat, waar je helaas niks mee kan.
Dan is er spanning.
De opdrachtgever zegt 'jij levert niet wat ik vraag'
en de opdrachtnemer zegt 'ik heb geleverd wat jij gevraagd hebt'.
Glashelder, Pieter.
Ik zie dat we nog een kleine twee minuten hebben.
Ik geef je nog een complimentje. We zijn nu toch met complimentjes bezig.
'Alvast dank. Fijn om een aantal belang- rijke aspecten van opdrachtgeverschap
helder uitgelegd en verbeeld te krijgen.' Helemaal mee eens.
En ook voor de mensen die achter een scherm zitten:
Deze modellen, ik hou er zo van. Het geeft zoveel meer inzicht
in hoe de dingen in elkaar zitten.
Pieter, zoals jullie zien, is niet de beste precieze schrijver.
Dat is het voordeel van zo'n webinar. Je kan terugkijken, terugspoelen
en inzoomen, indien nodig.
Misschien nog een ding aan toevoegen.
-Ga je gang.
Ik kan me voorstellen dat we veel dingen besproken hebben,
het is niet mijn leeftijd dat ik zo hiëroglyfig schrijf,
dat is een gebrek aan goed kunnen schrijven.
Ik kan me voorstellen dat dit nog vragen oproept.
In een uurtje kan je maar weinig behandelen.
Ik wil ook de kijkers uitnodigen: Mochten jullie nog vragen hebben,
willen jullie nog meer weten: jullie weten Ronald te vinden.
Is het interessant om binnen de eigen organisatie
een keer een gesprek hierover te hebben:
Let me know. Met plezier kom ik naar jullie toe om te kijken
om jullie verder te helpen om input te geven aan de dialoog
in jullie organisatie. Dus bij dezen wil ik dat ook aanbieden.
Ja. Dank je wel, Pieter.
En ook veel dank voor je heldere verhaal en heldere uitleg.
Ik sluit natuurlijk helemaal aan bij wat Pieter zegt.
Ook RADIO kunnen jullie altijd benaderen voor opleidingen, voor lesmateriaal.
Ik dank je zeer.
-Graag gedaan
en bedankt voor dit interview.
-Oké.