Zowel zakelijk als privé, voor routinematige en ad-hoc activiteiten, zowel in de dagelijkse werkzaamheden als in projecten werken veel afspraken niet of goed genoeg. Werkende afspraken maken blijkt niet eenvoudig. Maar liefst 80 procent van projectafspraken wordt niet naar tevredenheid van de klant gehaald. Ook in de werkelijkheid van elke dag loopt nog van alles niet naar wens…: 'net' te laat komen, 'druk… druk… druk'. Kortom, het is meer dan de moeite waard extra handvatten te hebben om werkende afspraken te maken en na te komen!
De bekende handvatten schieten helaas vaak te kort… SMART (Bill Reddin): Specifiek – is de doelstelling eenduidig?, Meetbaar – onder welke (meetbare/observeerbare) voorwaarden of vorm is het doel bereikt?, Acceptabel – is het acceptabel voor de doelgroep of het management?, Realistisch – is het doel onder de gestelde condities haalbaar?, Tijdgebonden – wanneer (in de tijd) moet het doel bereikt zijn? én RUMBA Gezondheidszorg: Relevant – is de doelstelling relevant?, Understandable – is de doelstelling begrijpelijk?, Measurable – is vast te stellen of de doelstelling behaald wordt, liefst door een meting?, Behavioral – is de doelstelling beschreven in termen van waarneembaar gedrag? en Attainable – is de doelstelling haalbaar?.
De trams rijden vrijwel altijd!
TRAMS-afspraken werken dus wél! Ik stel dan ook een andere checklist voor, om het succes van de tram (ook) op andere afspraken toe te passen die gebaseerd is op de letters TRAMS:
T – rams rijden altijd op tijd, het tijdschema is realistisch en (mede) gebaseerd op het aantal passagiers op bepaalde tijden en op de weersomstandigheden en eventuele speciale evenementen in de omliggende dorpen, steden en gemeenten;
R – ijden altijd recht op hun doel af, mocht er (tijdelijk) een koerswijziging nodig zijn, dan wordt een wissel aangelegd en eventueel een iets andere route, de meeste tussenliggende haltes en zeker het eindstation blijven altijd gelijk;
A – ls je eerder wilt uitstappen of overstappen (veranderingen zoals onverwachte gebeurtenissen, mee- en tegenvallers en risico’s) is dat mogelijk bij elke (volgende) halte en – in een echt noodgeval – door aan de noodrem te trekken op elke plek langs de route;
M – eetbare tevredenheid, omdat de prijs/ prestatie vast staat, denk aan comfort, de dienstregeling, de veiligheid aan boord… Bovendien worden er regelmatig klanttevredenheidsonderzoeken uitgevoerd;
S – neller dan de meeste andere alternatieven vormen van vervoer om op je gewenste bestemming aan te komen, zeker als die in een drukke stad ligt.
Kortom…: met een TRAMS gemaakte afspraak (bijvoorbeeld in een plan van aanpak, project initiatie document, werkopdracht of ‘gewoon’ een mondeling gesprek slaag je, samen met je gesprekspartner(s), altijd…!
Eerlijk is eerlijk… Werkende afspraken (waar-)maken vraagt natuurlijk meer dan de TRAMS-afkorting. Denk (ook) aan de randvoorwaarden waaronder het kan (gaan) werken en met name wat het van de mensen vraagt die ze samen gaan maken (kennis, kunde, motivatie, beloning).
Arthur Coppens, consultant II bij KPN Consulting
Dit artikel is eerder gepubliceerd op het intranet van KPN Consulting Nederland.
Trams rijden niet op tijd maar op rails, dat ze door de hoge omloopsnelheid op tijd lijken te komen is eerder een kwestie van resources dan van planning.
Kijkend naar projecten zijn er ook rails maar liggen deze niet altijd parallel als ik kijk naar de stakeholders, ontsporende projecten zijn dan ook vaak een politieke kwestie. Als de rails er uiteindelijk liggen kunnen we de omloopsnelheid verhogen, bijvoorbeeld door sneller releases op te leveren maar hierbij moeten we ook weer niet teveel wagonnetjes los laten omdat er dan botsingen optreden.
Zoals wordt aan gegeven zijn er dan ook nogal wat onzekere randvoorwaarden die soms lopende het project eenzijdig aangepast worden, bijvoorbeeld de dienstregeling om zodoende niet afgerekend te worden op een verkeerde KPI. And last but not least, projecten zijn geen rondje om de kerk hoewel er nog wel vaak om de hete brei heen gedraaid wordt.
Als ik de verhalen van uit KPN mag geloven hebben ze de tram gemist.
Een goed planning is altijd aanpasbaar, echter wie goed plant zorgt voor een realistische inschatting van de benodigde tijd en daar gaat het maar al te vaak mis, mede omdat randvoorwaarden niet voldoende gedefinieerd zijn of men zich gewoon niet aan de afspraken houdt. Daar moet de hand in eigen boezem gestoken worden.
Goed om te zien dat het onderwerp begint te leven!
Dat is natuurlijk waar je als auteur op uit bent als je iets aandraagt. Niemand heeft de waarheid in pacht, maar een mening hebben is wel handig…
Om de discussies nog verder te stimuleren heb ik hieronder ook nog wat ‘prikkels’ opgenomen bij mijn stuk over de TRAMS afspraken:
– Hoe kan TRAMS helpen als je klant (de passagier) niet weet waar
hij/zij naar toe wil?
– Wat te doen als het geld op is, of de passagiers niet meer willen
uitstappen?
– Zijn de R en de A niet ook een beetje paradoxaal? Immers:
“Het eindstation blijft altijd gelijk”, maar bij uitstappen kom
je nooit aan op dit eindstation en bij overstappen ga je richting
een ander eindstation. Ben benieuwd hoe jullie dit zien en er bij
jullie afspraken mee omgaan?
– Kun je het vraagstuk oplossen als mensen zich structureel niet aan
de afspraken houden?
– Op het gevaar af de hele (PM) organisatie op mijn dak te krijgen…
Elke projectmanagement opdracht valt of staat met structurele
afstemming! Er is ALTIJD scope creep, er is ALTIJD voortschrijdend
inzicht. Ik zie regelmatig projectmanagers en senior consultants
een opdracht afronden met tevreden opdrachtgevers, goede marges EN
met gaandeweg wijzigende afspraken / scope. Vreemd? Ja, maar wel
prettig. Het gaat om het managen van verwachtingen. Overigens sluit
dat prima aan bij de letters R en A van de TRAMS checklist: recht
op het doel af maar wijzigingen moeten wel mogelijk zijn.
@Arthur: in ieder geval fijn dat je zelf ook reageert op de reacties op je artikel, dat kan helaas niet van alle auteurs gezegd worden.
Maar één zinsnede in je reactie triggerde me:
De naam projectmanager klopt niet volgens mij, moet dat niet zijn expectation-manager
(gebaseerd op citaat: Het gaat om het managen van verwachtingen) ???
Projectmanagement is theorie, verwachtingsmanagement praktijk zou ik haast zeggen 🙂
Vanuit mijn beleving vanuit de praktijk…..
Ik gebruikt in white papers doorgaans drie typen professionals. Professional IT-ers, Professionals die in de IT werken en dan natuurlijk de professionals die met IT werken.
Ik vind een beetje ‘kruisbesnuiving’ helemaal niet zo erg doorgaans. Ik verwijs dan graag naar mensen zoals Balkenende, Bos, Rutte, Klink, Donner, Kamp, Rutte, Asscher, Samsom e.d. mensen die zichzelf zo geweldig vinden en nooit iets echt verkeerd hebben gedaan ‘met de kennis van dat moment….’
Daaruit blijkt steevast weer dat er veel mensen zijn die op plaatsen zitten waar zij gewoon geen enkele materie kennis van hebben maar goh, tjé, hé, ik zit wel in het topje van de boom dus heb ik altijd gelijk en de rest van de wereld begrijpt mij niet zo goed etc. etc.
Willen we die lijn doortrekken naar IT in en met verschillende organisaties?
– Neen, dat je een Prince2, ISEB, TMAP, ITMS, M3, EKVDD, papiertje op zak hebt wil niets zeggen over je projectmatige en sturende kwaliteiten.
Wat dat betreft gaan de universele wetmatigheden voor beiden groepen op.
U heeft het over een tram.
Daar wil ik met alle liefde wel met u op inzoomen want die tram is een even prachtige metafoor die ik in seminars gebruik als mijn trein. Alleen een beetje anders dan u hier beschrijft.
Wilt u werkelijk weten wat IT en IT project managers is? Heel eenvoudig. Stelt u zichzelf twee eenvoudige stationnetjes voor. Eentje bij u voor de deur, en eentje voor uw werk. Nu stelt u zich exact hetzelfde voor alsof er helemaal niets ligt.
Opdracht:
Bouw een eenvoudig treinlijntje van deur tot deur.
Ingrediënten
Ondergrond, grind, rails, bovenleidingen, twee stationnetjes, één overweg, één elektrische locomotief, twee wagons naar keuze te weten goederen of personen, en uiteraard, een gesloten dienst en onderhoudsregeling om de boel in beweging te zetten en houden.
Als u daar een plannetje voor maakt, haal ik voor u een eenvoudige E2E procedure van de plank die er voor zorgt dat iedereen weet wat die moet doen op welk moment. Niemand hoeft echt iets te leren behalve….
Oh ja natuurlijk … weten wat IT is, hoe het werkt, hoe de wetmatigheden zijn en….. hoe je de vertaalslag maakt van IT naar non IT. Heb ik nog iets vergeten? Oh ja, kijk of de mensen die je waar dan ook neer zet dezelfde taal laat spreken of dat zij de vertaalslag kunnen maken van IT naar Non IT mensen.
In IT prject management werk je niet met ‘afspraken’, want daarom gaat het fout. In IT project management werk je met taken. Zo eenvoudig is het…. eigenlijk …. soort van… Ik heb daar vast wel ergens een white papertje of wat liggen.
Scheelt je in ieder geval weer een wiel uit te vinden.
@Arthur
Ik weet niet waar je heen wilt maar zoals ik afsluitend in mijn reactie aangaf, projecten zijn geen rondje om de kerk. En als er dan toch een acroniem heilig verklaard moet worden dan opteer ik hierbij voor KISS.
Vatten we Numo samen, een afspraak is een taak . . .
En wat verandert dat?
@Pavake
projektmanagement is wat geleerd is, verwachtingsmanagement zie je als er talent is . . .
@ Ewout
Mijn stem heb je, KISS moeten we heilig verklaren.
Wat doen we dan met de “ongelovigen”?
@Jan
1. Wie maakt met wie de afspraak en waarom?
2. Wie voert daaruit voortvloeiende taak uit?
Er was vorig jaar een leuke discussie over stakeholders door ‘requiremensen’ welke me hier wel leuk bij aan lijkt te sluiten. Op de daar gestelde vraag over de vertaalslag als de werkzaamheden uitbesteed worden naar een niet Nederlandstalig land heb ik helaas geen antwoord gekregen.
Ik ga erin mee dat de kern van elke vorm van samenwerken tussen mensen (en dan met name als ze daar afspraken over maken) terug te voeren is op de wil, kunde, vasthoudendheid en bereidheid tot aanpassen bij de gesprekspartners. Dat is zo voor IT-ers en zeker ook voor hun (professionele zaken-) partners: leveranciers, klanten, lijnmanagers en (eind-) gebruikers.
KISS is inderdaad een nobel principe, zeker ook voor ons IT-ers, naast bewegingen als Agile, SCRUM en Kanban. Het genoemde E2E principe brengt terecht het punt van duidelijke instructies voor betrokken uitvoerders naar voren. Ik vind trouwens ook dat het hebben van een certificaat geen garantie is of vormt voor het (doen) slagen van afspraken (in projecten en het dagelijkse werkleven). Zoals ik hierboven aangeef, staat of valt de kern van het verhaal (zeker ook) door wil, ambitie en volhoudingsvermogen van de betrokken personen!
Dat projecten niet als een rondje om de kerk zijn, dat (h)erken ik zelf ook. Toch zie ik ook bij tramrails (zeker bij rangeerstukken) complexe infrastructuren ontstaan waar de tram(bestuurder) een goede weg doorheen moet zien te vinden.
@ Jan van Leeuwen
Dat wanneer je afspraken maakt die niet coherent op elkaar aansluiten in IT projecten, je dan automatisch te maken krijgt met ‘grijze gebieden’ waardoor je kunt wachten op zaken die niet op elkaar aansluiten…. met daar weer alle gevolgen van dien weer uiteraard.
Het uitzetten van taken vereist materie inzicht en dat is zelden het geval bij ‘project managers’ die in de IT werken. Dat is het begin van de problemen.
Als afspraken niet werken binnen of buiten de projectensfeer zijn er twee zaken die er aan ten grondslag liggen. 1. Men kent klaarblijkelijk de betreffende (deel)organisatie niet genoeg waardoor…. 2. Men heeft te weinig materiekennis waardoor…
Iets anders kun je haast niet concluderen.