Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

TRAMS-afspraken werken wél!

 

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4972725). © Jaarbeurs IT Media.

?


Lees meer over


Partnerinformatie
 

Reacties

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.

@Arthur Koppens
Ik ben bang dat daar een kern van de problemen liggen zoals jij in je reactie de tramchauffeur naar voren brengt die.....

De kans op fouten in IT zijn alleen maar mogelijk wanneer men of geen materie kennis bezit, of men denkt, ik heb een papiertje dus ik kan een IT traject runnen. Daar zit hem een beetje de crux. Een tramchauffeur hoeft alleen maar zijn 'trampapiertje' te halen, zijn route te kennen en in het ergste geval een wissel handmatig om zetten.

Dat is iets anders met materie IT. Daar heb je gewoon geen wissels. Ik denk dat de perceptie van velen daar al mank aan het gaan is.

Als er al geen eenduidig proces is die disciplines op elkaar laat aansluiten of als er geen éénduidig en overkoepelende E2E is, is het gewoon wachten op 'herrie'. Dat is gewoon een belofte.

@Numo

nog nooit gehoord van een gannt-chart? Zo kontroleer je of alles coherent aan elkaar sluit.

De basis van alle planning in de IT is de analyse, wanneer je die niet doet dan helpt niets, dat klopt.

@ jan van Leeuwen
Ik geloof niet dat u a. het artikel goed heeft gelezen en b. mijn reflecties daarop. Ik zie niet wat een gannt te maken heeft met het zorgen voor een heldere en gesloten communicatie en uitvoering tussen verschillende disciplines binnen IT programma's en projecten zoals
dhr. Arthur Koppens in zijn publicatie beschrijft.

Bij projektplanning gebruik je een gannt om
"een heldere en gesloten communicatie en uitvoering tussen verschillende disciplines binnen IT programma's en projecten"
te faciliteren en te dokumenteren.

Wanneer we hier over IT projekten, taken en afspraken discusseren dan is een projektplan toch het minste wat je mag verwachten. Een gannt-chart is een van de weergave-vormen van een projektplan waar de samenhang tussen verschillende taken goed zichtbaar is.

Zorgen voor een goede communicatie doe je met principes van groepsdynamica wat los staat van IT maar daar ook heel goed toepasbaar is.

@Jan

De intentie van Gantt charts is natuurlijk wat anders dan hoe ze in de praktijk nog weleens gebruikt worden. De 12 aan elkaar geplakte A4-tjes op de muur zijn soms net als de architectuurplaat er naast, een statische representatie van de dienstregeling die geen rekening houdt met de 'vallende blaadjes' op de rails. Een goed projectplan omvat dan ook een communicatieplan want in tegenstelling tot de architectuurplaten is de Gantt chart naar mijn opinie niet een praatplaat.

Tramtrajecten zijn blijvend, statisch en ouderwets.
Ze vormen een langdurige oplossing voor een overzichtelijk logistiek probleem.

Projecten zijn per definitie tijdelijk, dynamisch en zijn meestal complex.

Projectmethoden als PRINCE2 en Scrum beschrijven prima zaken als Mandaat, afspraken, verwachtingsmanagement, timeboxing, dynamische planning met na elke fase/iteratie toetsing aan businesscase etcetera.

Maar het TRAM verhaal doet het natuurlijk prima in de powerpoint presentaties en artikelen. Discussie na afloop, iedereen beetje gelijk. Succes verzekerd.

@ Ewout
het gehele projektplan is een momentopname, inklusief de Ganntchart.
Het is de planning van dat moment.

Die is natuurlijk aanpasbaar. Echter geeft het een indruk hoe taken samenhangen.

Een communicatieplan klinkt mooi, maar waar mensen met elkaar communiceren is aandacht voor meta-communicatie gevraagd. Regels voor de manier waarop je met elkaar in projektgroepen communiceert zorgen er voor dat de alfa-dieren elkaar niet in de haren gaan en de waardevolle bijdragen van de gamma's ook gehoord worden.

@ArthurCoppens Je stelt in de inleiding dat afspraken binnen projecten zelden gehaald worden naar tevredenheid van de klant. Gaat dit over IT projecten? Ik vraag me af wat nu de toegevoegde waarde van al die acroniemen is? Het lijkt me meer een opsomming van logische vragen vooraf (wat wil je, is het haalbaar, realistisch etc) en achteraf (was dit wel wat je wilde en is het geslaagd?). De TRAMS is naar mijn mening ongeveer hetzelfde als de andere acroniem maar verwarrend door het gebruik van terminologie van de tram. Dan vind ik de opsomming van de rumba en smart begrijpelijker en directer.

Een Gannt diagram heet dat dus, nooit eerder van gehoord maar wel eerder gezien, lijkt heel handig het geeft richting. Tenminste, als het een logisch verhaal is.

Ben ook voor nastreven van KISS maar denk dat ook het moelijk is en in de praktijk lang niet altijd het geval.

@ Mauwerd, je hebt ongetwijfeld een punt. Persoonlijk is het voor mij niet zo zeer het scoren van een punt. Waar het mij telkens weer om gaat zijn basaal twee zaken.

Wetmatigheden en werking van IT
Die blijven vanaf de allereerste dag helemaal dezelfde en ongewijzigd. Welk dekentje men daar dan ook overheen wenst te leggen. Als dat dekentje niet consistent is met de materie IT, hoe deze werkt, en vooral hoe je met een vehikel als IT om moet gaan, heb je aan geen enkel dekentje iets.

IT Professionals, Professionals in IT en Professionals met IT....
Meer smaakjes heb je professioneel gezien niet maar de verschillen zijn evident groot. IT professionals houden projectmatig, doorgaans, rekening met de wijze waarop je met IT om moet gaan. Niet iederere IT professional is even communicatief 'fehig' om de vertaalslag te kunnen maken maar weten gewoon dat het 'zo' moet.

Professionals werkend in de IT kennen vrijwel de werking van de materie IT niet, ook de wetmatigheden niet maar bedenken wel van alles dat niet in lijn is met voornoemde met alle gevolgen van dien. En die gevolgen zijn vaak aanzienlijk. het bepaald namelijk niet alleen het aanzien van IT als vehikel, het bepaald namelijk ook nog eens de gegarandeerde extra kosten van o.m. verlies aan tijd, productiviteit en heel veel onzinnige discussie.

In het licht van dit artikel
Prachtig dat je roept waarom trams wel of niet zouden werken. Zoals ik in mijn eerdere reflectie al aan gaf, de fout kom ik al tegen bij de trambestuurder in het artikel.

Automatiseren is namelijk WETEN(!!!) welke stap er op wel moment plaats zal nemen. Daar heb je als het goed is over nagedacht. Dit omdat de materie IT alleen maar zo kan werken.

Heb je daar geen weet van, dan krijg je te maken met heel veel situaties waar een trambestuurder uit moet stappen om een wissel om te zetten. Proves my point. Daar is IT voor om dat niet te hoeven doen. Het enige wat je hoeft te weten is hoe het werkt en je daar naar aanpassen.

Of je daarbij de tram of de trein neemt, is dan helemaal niet zo spannend meer in één keer. Wel wat het de organisatie aan het einde van de rit oplevert.

Ik zie in enkele reacties de vraag terugkomen over in hoeverre een afkorting (TRAMS of welke andere dan ook) het verschil zal maken.

Een terechte vraag, dat heb ik ook zelf met het stukje over 'randvoorwaarden' aangegeven.

In de afkorting(en) zit een zekere mate van 'een open deur'. Dat was ik me bij het schrijven van deze opinie al bewust. Tegelijk valt me elke dag weer op hoe lastig het blijkt te zijn tot werkende afspraken / taken te komen. Ik vraag me dus in essentie af 'waarom we die open deur dan toch niet gewoon doorgaan'.

Ik ben met de eerdere respondenten eens dat iets als een GANTT chart (als onderdeel van een projectplan[ning]) zeker verheldering kan bieden.

Meta communicatie (naast feedback en kwaliteitskringen) draagt ertoe bij dat de afspraken werkbaar zijn en dat waar verbetering nodig is deze ook daadwerkelijk wordt doorgevoerd.

Inhoudelijke kennis als belangrijke randvoorwaarde onderken ik ook. Dat heb ik in mijn stukje proberen aan te dragen bij de randvoorwaarden (citaat: "wat het van de mensen vraagt die ze samen gaan maken (kennis, kunde, motivatie, beloning").

Ik ben benieuwd of iemand nog een aanvulling heeft?

Diverse respondenten plaatsen terecht een kritische voetnoot bij de kracht van (alleen) de metafoor. Ik vind dat zij helemaal gelijk hebtben, een richtlijn werkt immers pas vanaf het moment dat alle betrokkenen geloven in de insteek en er naar voller vermogen invulling aan geven.

De invulling van de gevraagde rol van elke betrokkene maakt het onderscheidende verschil. De buitenkant van het verloop van de afspraak zegt niet alles, pas als je echt 'naar binnen' kijkt ontdek je hoe de zaken er voor staan.

Daarnaast lees ik enkele kritieke parameters die ons aller aandacht verdienen wil TRAMS werkbaar zijn en blijven, dank voor deze aanvullingen!

Denkertje:

Waarom rijden trams op tijd?

Waarom rijden treinen toch beduidend minder vaak op tijd?

Waarom rijden metro's dan net weer beter op tijd?

Ze doen in wezen het zelfde: mensen en vracht van plek A naar B brengen. Alleen met een ander gebied waarin ze opereren en wellicht andere verschillen.

Ik ben benieuwd wie hier over meedenkt om het een en ander nader uit de doeken te doen.

Hartelijk dank voor alle feedback/ vragen/ tips tot nu toe, echt gaaf dat een opiniestuk een dergelijke repliek los kan maken, zo blijft het een boeiende en vruchtbare discussie!

Kortom: kom maar lekker door met de feedback. Wordt het verhaal nog beter en hopelijk trekken we er allemaal - een beetje - lering uit!

Hartelijke groet,
Arthur Coppens.

@ Arthur Coppens,

Een reactie naar mijn hart. Dat is wat ik veel (Non) IT professionals telkens weer duidelijk maak als basis principe in en met IT. Misschien dat je een blik wil werpen op 'de Civile Matrix' die dat juist zeer eenvoudig illustreert.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×