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.
@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”).