Categorie: Projectmanagement

Laatst zag ik een documentaire over rally rijden. Nu is misschien niet iedereen fan van deze autosport waarbij auto’s met extreem hoge snelheden over stoffige wegen rijden waar u en ik waarschijnlijk nog niet eens stapvoets willen rijden. Maar iets weerhield me door te zappen. Een kwartier kijken naar hoe rallyrijders samenwerken gaf me antwoord op een projectmanagement vraag die me vlak daarvoor gesteld werd door een klant.

Hoe vaak moeten we het doen?
‘Net zo vaak als nodig is!’ Dat was in eerste instantie mijn antwoord en terwijl ik het zei besefte ik dat met dit antwoord mijn klant en eigenlijk niemand geholpen was. Kijkend naar de rallyrijders deed me beseffen hoe sterk en belangrijk de gestelde vraag was, want er wordt eigenlijk zelden inhoudelijk stilgestaan bij de vraag ‘Hoe vaak er in een project nu eigenlijk gerapporteerd moet worden?’
Mijn eerste antwoord was veel te impulsief, zeker omdat ik daar door de jaren heen over heb nagedacht en ook een set aan bruikbare criteria voor heb opgesteld. Criteria die, samen met het aanleren van een andere manier van kijken naar projecten, bepalen welke frequentie nuttig en nodig is.

Het parcours bepaalt
Hoe kunnen rallyrijders nu helpen inzicht te krijgen in de frequentie van projectrapportages? Nog niet zolang geleden sprak ik een klant die vertelde dat de manager die verantwoordelijk was voor het monitoren van de projecten een maandelijkse voortgangsrapportage van de projectleiders verlangde. De projectleiders dachten daar echter anders over. Zij vonden maandelijks buitensporig vaak; eens per twee of drie maanden was meer dan genoeg.
Diezelfde periode liep ik rond bij een andere klant waar de meningen van de projectleiders volledig uit elkaar lagen wat betreft voortgangsrapportages. Het ene kamp maakte helemaal geen rapportage (“Ze worden toch niet gelezen”), terwijl het andere kamp projectleiders rapporteerde in de frequentie van de wekelijkse stuurgroep-vergaderingen. Wie had het nu bij het juiste eind?
De rallyrijders maakten prachtig zichtbaar dat de frequentie van rapporteren afhankelijk is van de situatie. Stuurman, navigator en het technische team bij de service punten onderweg, communiceren intensief. In de auto gaat het over de staat van het wegdek, de hoogte van de snelheid, de weersomstandigheden, het aanwezige publiek en zo gaat dat nog even door. Drie bochten vooruit geeft de navigator aan wat de bestuurder kan verwachten, naar welke versnelling hij moet schakelen en met welke snelheid gereden kan worden. Maar wat bepaalt de situatie dan in de genoemde projectomgevingen?
In het eerste voorbeeld ging het over onderzoeksprojecten waarin met een doorlooptijd van een paar jaar twee mensen 1 a 2 dagen per week aan het project werkten. In het laatste voorbeeld werkten meer dan honderd mensen, waarvan het overgrote deel externe consultants, fulltime aan één project met een doorlooptijd van start tot finish van een negen maanden.
De rallyrijders gaven het antwoord. Het eerste parcours kent een lage snelheid. Het wordt afgelegd in enkele jaren door twee mensen in twee dagen per week. De kans dat zij van de weg raken is vele malen geringer dan in het laatste traject waar in een kort tijdsbestek vele manuren worden gemaakt. Tijdig bijsturen maakt daar het verschil tussen hard op koers blijven of gierend de bocht uit vliegen. Omstandigheden en risico’s bepalen de frequentie van informatie.

De bestuurder moet weten waar naartoe gestuurd kan worden
De rapportages die projectleiders geven zijn als de instructies die navigators in rally teams geven aan de bestuurders. Projectleiders weten, net als de navigator, exact waar men zich bevindt. Ze kennen de details van de af te leggen weg en moeten de bestuurder de informatie geven op basis waarvan niet alleen gestuurd wordt, maar ook op basis waarvan geschakeld, geremd en geaccelereerd kan worden.

Communiceren is de contactsleutel
Als de navigator niet communiceert is de kans dat de bestuurder foute beslissingen neemt groot. Want, niets zeggen houdt in dat er niet geremd of geschakeld hoeft te worden. Dat er geen gevaarlijke bochten, diepe kuilen, of obstakels zijn. Maar te veel communiceren werkt ook niet want dat leidt af van wat werkelijk van belang is.

Onzekere bestuurders en overijverige navigators
De rallyrijders hebben een manier van communiceren ontwikkeld waarin alleen het meest noodzakelijke op de meest effectieve wijze wordt doorgegeven. En dat is logisch, want in ralley-rijden wordt in fracties van seconden het verloop van de wedstrijd bepaald. In projecten zit gelukkig iets meer lucht, al kan de spanning ook hoog oplopen. Zo kom ik tegen dat de projectleiders rapporteren met de frequentie van de stuurgroep bijeenkomst. Dat lijkt logisch, maar persoonlijk ben ik er geen voorstander van. De stuurgroepen-leden zijn vaak drukbezette managers die alleen al agenda-technisch moeilijk regelmatig bij elkaar kunnen komen. Het verschuiven van vergaderingen heb ik te vaak gezien, terwijl de projecten gewoon doorlopen. Bijsturen kan dan net te laat komen.

Frequentie, relevantie en risico
Hoe komt de opdrachtgever nu op een regelmatig wijze aan de informatie over zijn/haar project? Even bijpraten? Maar hoe wordt de rest van de belanghebbenden dan geïnformeerd? Het belang iedereen op de hoogte te houden wordt ook in de rally docu duidelijk, want naast de bestuurder van de auto staat ergens langs het parcours een compleet technisch team klaar voor het servicen van de auto. Zij moeten vooraf weten wat ze kunnen verwachten zodat de juiste gereedschappen en onderdelen klaarliggen.
Sturen en bijsturen betekent belangrijke beslissingen nemen en dat kan alleen op basis van de juiste informatie. Waar de oliedruk te laag wordt bepalen de technici op afstand dat de snelheid lager moet wil de motor niet in de soep draaien. De bestuurder volgt.
In een projectomgeving betekent dit wat mij betreft dat niet de stuurgroep, maar de opdrachtgever de klant van de voortgangsrapportage is. Waar de stuurgroep op maximale snelheid door wil kan de klant vanuit een bredere kijk op afstand bepalen wat de beste snelheid is en welke snelheid van rapporteren daarvoor gewenst is.

Dashboard. Criteria voor bepalen van de frequentie
Op basis van eigen ervaringen heb ik in de loop van de tijd een richtlijn ontwikkeld die kan helpen om de frequentie van rapporteren te bepalen. Hieronder een korte toelichting en de bijbehorende tabel.

Conclusie
Vergelijken we een rally met een project, dan zien we dat we in beiden zo snel mogelijk, binnen de gestelde kaders, van start tot finish willen komen. Dat vraagt dat we ons continu bewust zijn waar we ons op het traject bevinden en wat ons te wachten staat. Communiceren van de juiste informatie is essentieel. Niet alleen voor het sturen, maar ook voor het gas geven, remmen opschakelen en terugschakelen. De gegevens van ons dashboard en de projectrapportages zijn de navigatie binnen een project waarmee wel iets moet worden gedaan.
Voor het bepalen hoe vaak projectleiders over de voortgang van hun projecten moeten rapporteren kunnen de bovenstaande criteria als uitgangspunt worden gehanteerd. Misschien kan je verschillende typen projecten in jouw organisatie onderscheiden; projecten die elk een eigen frequentie van rapporteren verlangen. Maar waak ervoor dat enerzijds de projectleiders niet ‘overvraagd’ worden en anderzijds hun opdrachtgevers en stuurgroepen geen gebruik maken van die rapportages. Rapportages zijn een prachtig communicatiemiddel*.

TIP: Voor de klanten van ProjectReports heb ik een voorbeeldprocedure voor het maken van voortgangsrapportages gemaakt. Klik hier om deze gratis te downloaden.

De muur tussen zeggen, verwachten en doen?

Vertrouwen geldt als een van de meest gewaardeerde competenties maar moet vooral niet worden verward met verwachting. Direct nadat Trump, tegen ieders verwachting in, tot de nieuwe president van de VS was gekozen vertoonde de muur van verwachtingen de eerste scheuren.

Gedurende de campagne was er veel ophef bij tegenstanders van Trump, deze is omgeslagen in veel ophef onder de voorstanders. Laatstgenoemden voelen zich verraden. Al snel na de verkiezing maakte ‘de president in spe’ de eerste benoemingen bekend. Mensen die niet passen bij het beeld dat hij heeft geschetst in zijn verkiezings-speeches. Datzelfde geldt voor die solide muur tussen de VS en Mexico. Deze muur, die de VS moest beschermen tegen al die illegalen, kan ineens ook wel een hekwerk worden. Wat er geroepen is strookt kennelijk niet met de verwachtingen die gewekt zijn. De praktijk moet dan bewijzen wat waar is. Nu lijken de Amerikaanse verkiezingen misschien een wereld verwijderd van onze eigen dagelijkse projecten. Toch raken ze elkaar vanuit de gedeelde vraag:” Welke informatie is nu echt betrouwbaar?”

De dunne lijn tussen beloven, roepen, doen en verhullen

Volgens goed gebruik rapporteren projectmanagers met enige regelmaat over de voortgang van hun projecten. Opdrachtgevers, stuurgroepen, directies, ze willen allemaal graag op de hoogte zijn van de vorderingen. Ook in deze context wordt van alles gerapporteerd. Vraag is alleen, hoe betrouwbaar? Geven voortgangsrapportages altijd de echte situatie en het echte gevoel weer? Wordt er eigenlijk wel aan de alarmbel getrokken als er iets scheef dreigt te gaan, of doen we dat pas als het al scheef gaat? Hoe staat het met onze project-rapportage-lef-en-realiteit? Werken we met kleuren, zijn de signaalkleuren van mijlpalen dan werkelijk de afspiegeling van de realiteit? Is iets echt rood, of geeft de situatie eerder aanleiding voor geel? Wanneer doe je concessies in rapportages of rapporteer je altijd zonder concessies, omdat in het verleden een van de opdrachtgevers weleens verrast werd doordat in het project ‘opeens’ een onaangename verrassing uit de hoge hoed kwam: de testresultaten waren zwaar teleurstellend, of vlak voor de eindstreep bleek dat er niet werd voldaan aan externe regelgeven waardoor toch extra tijd nodig was.

Geel en groen voor de ogen

Persoonlijk ben ik ervan overtuigd dat ik het beste transparant kan zijn in rapportages. Ik vraag liever zo vroeg mogelijk aandacht van het management voor een issue of risico zodat zij tijdig kunnen bijspringen. Toch heb ook ik niet een geheel schone lei.
Een flink aantal jaren geleden rapporteerde ik in een grote organisatie een project op geel. Tijdens het bespreken van de rapportage met de opdrachtgever, een van de directieleden, gaf de directeur mij uiteindelijk de opdracht om de status-kleur te veranderen in groen. De rapportage zou met een aantal andere projecten worden besproken in een directie-overleg en hij wenste niet met een geel gekleurd project de vergadering in te gaan. Duidelijk een gemiste kans om met de collega-directieleden correctieve maatregelen af te stemmen. Vermoedelijk zat er ergens in de cultuur van het bedrijf iets scheef en was men van mening dat een goede manager alleen succesvolle projecten had. Gelukkig heb ik deze situatie nooit meer meegemaakt en is sindsdien geel-geel en rood-rood gebleven.

Subjectief

Er kan eindeloze discussie gevoerd worden over de status-kleur. Van belang zijn echter twee dingen: maak heldere afspraken over wanneer een project, mijlpaal, risico, of issue geel of rood moet worden. En zorg dat iedereen zich vervolgens ook aan die afspraken houdt. Blijft staan dat de inschatting van de status van een project met alle issues en risico’s subjectief blijft. Het beste wat je kan doen is de relevante gegevens goed analyseren en vervolgens eerlijk rapporteren.

Tip:

Vraag aan de leden van je projectteam welke status-kleur zij het project toekennen. En bepaal dan pas wat je aan de opdrachtgever rapporteert.

Waarom, waarom, waarom? Wie kinderen heeft weet hoe persistent kinderen kunnen blijven hangen in de waarom-vraag. Ervaring leert dat na drie keer de waarom-vraag achter elkaar gesteld te hebben zelfs de slimste mensen geen antwoord meer hebben. Reden dat de waarom-vraag zeldzaam vervelend, zelfs irritant kan zijn. Maar, als continu lerende mensen weten we dat waarommen belangrijk is. Niet alleen voor de ontwikkeling van onze kinderen, maar ook voor onszelf: omdat we vervelende situaties graag willen vermijden.

“Waarom is die test van het nieuwe softwaresysteem met twee weken uitgelopen?” Toen mijn opdrachtgever die vraag stelde had ik gelukkig meteen mijn antwoord klaar. “De interface met ons financiële systeem was door de externe leverancier op het laatste moment opgeleverd maar bleek toen we gingen testen geen gegevens door te sturen, waardoor alle testers duimen zaten te draaien.” Ik legde mijn opdrachtgever uit dat er een fundamentele fout was gemaakt bij het bouwen van de interface en dat de ontwikkelaars twee weken nodig hadden om de interface goed werkend te krijgen. De opdrachtgever raakte geïrriteerd omdat door fouten van dezelfde leverancier al eerder vertraging in het project was ontstaan. De waarom-vraag is o zo makkelijk gesteld. Terecht of onterecht? Ik was blij dat ik in dit traject doorgevraagd had en wist wat de vertraging had veroorzaakt. In deze situatie had ik, bij het bekijken van de voortgangsrapportages een rood signaal binnengekregen. Alarm, een duidelijk waarom-vraag moment. Maar met regelmaat merk ik dat de kostbare tijd van voortgangsoverleggen verspild wordt vanuit een simpele waarom-vraag waarna de aanwezigen volledig in de details zakken en we meer achteruitkijken dan vooruit.

Gepland vooruit- en achteruitkijken

Ze zeggen weleens, ‘We gaan achteruit struikelend de toekomst in’. Te vaak wordt te lang stilgestaan bij terugkijken: “Waarom is die mijlpaal niet gehaald of dat product nog niet gerealiseerd? Waarom, waarom, waarom,…” Voel je hem al, dat kleine knagertje die al na een paar waaroms van binnen gaat jengelen met de opmerking: ‘Dit gesprek gaat ons niet naar voren brengen’.
Veel interessanter wordt het gesprek als je bespreekt: Wat is nodig om die mijlpaal van komende maand te realiseren? Met welke risico’s moeten we daarbij rekening houden? En wat kunnen wij daaraan doen om die risico’s te beteugelen?

Als projectmanager en ook als PMO’er (vroeger ‘medewerker projectbureau’ in de volksmond genoemd), constateer ik dat veel projectmanagers, inclusief ondergetekende, tijd verspillen door in voortgangsbesprekingen met de opdrachtgever de waarom- discussie ruimte te geven. Ernstiger wordt het als waarom-vragen de vergadering met het hele projectteam opeisen. Natuurlijk zijn er argumenten voor de verdieping, maar dan wel op het juiste moment.
Eerder haalde ik al aan dat waarom-gedrag prima is te verklaren door te wijzen op de behoefte fouten in de toekomst te willen voorkomen. Als dit zo sterk leeft in een team dat het de voortgangsoverleggen verstoort, dan wordt het tijd om hiervoor ruimte te creëren. Organiseer een aparte sessie waar het terugkijken en leren op de agenda staat. Mensen die volgens ‘Scrum’ werken herkennen dit als de ‘Retrospective’ en de PRINCE2-aanhangers kennen het als ‘Lessons Learned’.
Waarom-gedrag kan ook een voortgangsoverleg verstoren omdat mensen willen uitzoeken of de schuld bij een ander ligt, zodat ze weten dat ze zelf uit de vuurlinie blijven. ‘Barbertje moet hangen’, is zo’n uitspraak die we vroeger bij Nederlandse literatuur meekregen; we willen graag dat de veroorzaker van een probleem zichtbaar wordt. Maar wat de oorzaak ook mag zijn: het voortgangsgesprek met opdrachtgever of projectteam is het verkeerde moment.

Vooruitvragen

In het overleg met opdrachtgevers probeer ik ruimte te geven aan zowel het belang van de opdrachtgever als aan mijn eigen belang. De opdrachtgever wil geïnformeerd worden over de voortgang. Ik wil de acties en besluiten bespreken die nodig zijn om het project zo goed mogelijk over de eindstreep te brengen. Dus besteed ik de meeste tijd aan zaken die voor me liggen. Wat gaan we komende periode opleveren en hoe kan de opdrachtgever mij helpen om de risico’s te omzeilen? Welke acties en welke besluiten zijn daarvoor nodig? Wat ga ik doen en wat doet de opdrachtgever? Vergeet niet dat het ook zijn project is en dat hij daar best iets voor mag doen. Mijn advies is dan ook: kijk vooruit en vraag daarover aan de opdrachtgever wat je wilt weten en nodig hebt. Vraag vooruit!

Tip: Vraag vooruit. Bespreek de mijlpalen en risico’s die nog vóór je liggen. En als je ‘Waarom ging dat niet goed?’ te horen krijgt, stel dan voor om die vraag te parkeren tot een volgende bespreking: ‘Zullen we morgen dat eens evalueren?’

Waarom doe ik dit ook al weer? “Omdat we het zo afgesproken hebben!”. Dit was nou niet het beste argument om mij als projectmanager te motiveren om iedere week een voortgangsrapportage op tijd in te leveren. En toch probeerde de goedwillende medewerker van het projectbureau/PMO mij zo te overtuigen.

Ik ben zo druk

Al die jaren projecten van begin tot eind brengen lijkt voor sommigen eentonig en stressvol en dat is het ook als je niet constant ontwikkelt en blijft ontwikkelen. Zo had ik het als projectmanager druk, wat zeg ik, vreselijk druk om mijn project op tijd over de finish te krijgen. Uiteraard werkte iedereen daar hard aan. Ook ik was, zoals de meeste mensen die iets managen, bijna al mijn tijd kwijt aan overleggen. Maar hoe druk ik het ook had met allerlei ‘overleggen’, bijpraten met mijn teamleden en de stakeholders goed aangehaakt houden hebben altijd voorop gestaan, maar schiet er ook o zo makkelijk toch bij in. Tijden lang sprintte ik van overleg naar overleg. Niet slim, maar één voordeel had dat wel, ik had alle info top-of-mind. Ze konden me alles vragen; ik had altijd een pasklaar antwoord.

Tijdens mijn eerste projectjes was dit wel mijn setting. Ik vond het zalig al die hectiek. Rennen, rennen. En ’s-avonds met een gevoel naar huis dat ik heel druk – en goed – bezig was geweest. Als ik dan ’s-avonds nog mijn mailachterstand van die dag wegwerkte kwam ik nog weleens een mailtje tegen van een PMO’er: “Remco, waar blijft je voortgangsrapportage? De deadline was vandaag 12.00uur”. Voor mijn gevoel was het nog maar een paar uur geleden dat ik mijn vorige voortgangsrapportage had verstuurd. En daar ging ik weer. Na die lange werkdag nog even snel die rapportage maken voordat ik naar mijn tennisafspraak ging. Maar waar had ik de rapportage van vorige week ook al weer? Oh ja, in Excel kijken bij ‘Open recente bestanden’ en daar was ie gelukkig nog te vinden. Effe openen en snel aanpassen. De status kleurtjes voor tijd, geld en kwaliteit waren nog allemaal OK, dat wil zeggen Groen. Alleen dat nieuwe issue nog opvoeren. Vier regels toelichting en gaan met die banaan. Naar de tennisbaan.

Herken je deze werkwijze? Hopelijk niet. Maar mocht je het wel herkennen, dan weet ik zeker dat je niet de enige bent. En dan herken je misschien ook de volgende situatie:

Wat je misdoet doe je zelf, nog een keer.

De volgende ochtend was ik net begonnen met mijn teamoverleg toen de PMO’er kwam binnenlopen. Waarom ik het oude sjabloon had gebruikt. En of ik binnen 30 minuten een nieuwe versie wilde maken met het goede sjabloon en met dit keer wél het onderdeel Financieel geactualiseerd. Ik had toch immers afgelopen week gewoon doorgewerkt met het team? Oftewel ik kon mijn vergadering afbreken en voor een tweede keer de rapportage voor dezelfde week opleveren.

Als ik hier nu op terugkijk zie ik dat er meerdere dingen misgingen. Dat varieerde van de opslag van documenten, overschrijven van vorige rapportages, teveel overleg in verhouding tot nadenken en plannen, en zo kan ik er nog wel een paar noemen waar ik in andere blogs nog op zal ingaan. Maar waar het me nu vooral om gaat is dat ik in de beginfase als projectmanager de meerwaarde van het schriftelijk rapporteren niet inzag.

Tijdens mijn derde project kwam bij het omslagpunt. Tijdens een koude herfstavond thuis, in alle rust, mijn partner was weg, maakte ik de voortgangsrapportage. Ik realiseerde me opeens dat we de komende week een gebruikersbijeenkomst moesten voorbereiden die door alle hectiek nog geen aandacht had gehad (ik hoefde alleen maar even een Powerpointje te maken had ik destijds geroepen). Na de eerste schrik nam ik meteen de tijd om de hele rapportage helemaal opnieuw door te nemen. Dat leidde tot een aanpassing van de issues en een nieuw risico. Het leidde zelfs tot de wijziging van de statuskleur voor de voortgang. Die kon ik niet langer groen houden. Hij werd kanariegeel.

Het werd me helder dat ik er zelf voordeel van had als ik mijn voortgangsrapportages niet meer in alle hectiek snel tussendoor maakte, maar mezelf er bewust even voor afzonderde en er echt aandacht aan gaf. Het hielp mij toen en het helpt me nog steeds om beter te begrijpen hoe mijn projecten er nu echt voor stonden en voor staan. Tussen al die vergaderingen en crash-acties waarbij heftige issues worden opgelost ervaar ik het maken van de voortgangsrapportage tegenwoordig als een moment van rust; heel waardevol. Het geeft wat afstand tot het project, de bekende helicopterview, en leidt regelmatig tot een frisse blik. Als credo gebruik ik sinds kort (vrij vertaald naar Tele2):

Niet omdat het moet, maar omdat ik het kan!

Hoort u ze ook? Zelfs met een minder scherp gehoor en veel omgevingslawaai kan je ze horen, overal en steeds vaker, de lokroep van projectleiders. Elke organisatie kent projecten en met projecten ontstaat behoefte aan projectleiders. De een wordt als vrijwilliger aangewezen, de ander heeft er doelbewust via studie voor gekozen projecten in goede banen te leiden als professie.

Of het nu een websitebouwer is die praat over projecten, wegenbouwers, consultants, HR-managers, secretaresses, allemaal ‘doen’ ze projecten.

Wel een project, niet een project, wel een project niet een project

Een projectleider in de bouw verstaat heel iets anders onder een project dan een afdelingshoofd.

Vergelijken we projecten onderling dan zien we grote verschillen. De websitebouwer die in zijn eentje in WordPress in drie dagen tijd een website bouwt; de wegenbouwers die met honderden collega’s in een tijdsbestek van vier jaar een snelweg verleggen, de consultant die met een klein team experts een analyse doet en een rapport oplevert, de HR-manager die met het directieteam samen een reorganisatie aanstuurt en de secretaresse die een bedrijfsfeest organiseert. Allemaal belangrijke projecten voor degene die de verantwoordelijkheid draagt. Met als verschil het aantal betrokken mensen, de hoeveelheid geld, de doorlooptijd en omvang en soort risico’s. Eén ding hebben al die verschillende soorten projecten wel gemeen: er moet werk verzet worden. Er zijn acties nodig die op specifieke momenten afgerond moeten zijn om het project tot een succes te maken. De uitdaging voor jou als projectleider is om goed zicht te houden op de status van al die acties. Sterker nog, het is je hoofdtaak.

Het succes van projecten wordt dus vanuit ‘te verzetten werk’ bepaald. Logisch dat we met iedereen die meewerkt regelmatig bij elkaar komen en de voortgang bespreken. De lokroep van de projectleider haalt het team bij elkaar zodat we samen zichtbaar kunnen maken wat de status van de acties is.

Naarmate projecten groter en complexer zijn wordt het lastiger in een overleg alle acties te bespreken. Hoe meer mensen in een project werken hoe groter de uitdaging om goed zicht op de status van al dat werk te houden. Dat kan je dan eenvoudig niet meer uit het hoofd of in een schriftje doen. Alles draait dan om afspraken en een werkwijze die door alle leden van het projectteam wordt omarmd en gebruikt. Dat heb ik als junior wel geleerd.

De les van de gearchiveerde boterham

Jaren geleden, als junior projectmanager, had ik de schone taak door het verticaal stapelarchief van mijn collega te spitten zodat de directie tijdens zijn vakantie wist waar we nu eigenlijk stonden met een belangrijk project. De stapels papier waren normaal een no-go zone, maar nu moest het. De super senior projectmanager, met aanzien van iedereen in de organisatie, kon altijd direct de status vertellen en feilloos iets vinden. Maar nu was hij op een welverdiende vakantie van vier weken en ik was de pineut. In vier weken ben ik senior geworden. Het doorspitten van het verticaal stapelarchief, van vloer tot plafond en van muur tot muur heeft mij slapeloze nachten en tien jaar van mijn leven gekost, want de directie eiste antwoorden. Eén ding heb ik geleerd: wat logisch is voor de één hoeft niet te werken voor de ander. Het chronologisch doorstapelen van papier werkte niet, zeker niet als daar af en toe in alle hectiek ook de boterhammen met pindakaas en leverworst tussen zijn blijven slingeren. Ik wist in ieder geval dat op woensdag 5 maart 1995 een boterham met pindakaas de lunch was. Maar alle gekheid op een stokje: het op een uniforme en door iedereen onderschreven – en gehanteerde (!) – manier registreren van de status van acties is een no-brainer en is essentieel!!

Uniform op je eigen of een uniforme manier

Op zich is er niets mis met Excel, maar je wil niet weten hoe creatief mensen in Excel kunnen zijn. Het registreren van de status van acties voor kleine projecten kan op zich prima in een Excel lijst. Maar het nadeel daarvan is dat niet iedereen er tegelijk in kan werken. En bij het rondsturen met de vraag om de acties bij te werken ontstaan al snel tal van verschillende versies van het bestand. Dan ben je als projectleider de pineut en kost het weer extra tijd om dat overzicht samen te stellen. Zo’n Excellijst werkt ook lastig als je afhankelijkheden tussen verschillende acties wilt bewaken. Ieder project kent namelijk afhankelijkheden; projecten zonder afhankelijkheden bestaan niet.

Samenwerken in plaats van samen werken

Om goed de voortgang van je project bij te houden zal je dus al snel expert in Excel moeten worden, of grijpen naar andere tools. Je zal met je projectteam moeten kunnen samenwerken in een voor iedereen gelijke omgeving in plaats van dat je samenwerkt met een tool waar ieder teamlid alsnog zijn eigen draai aan kan geven. Werken vanuit één versie maakt al een wereld van verschil. De Control en de C en de V-toetsen zijn bij mij in de loop der jaren zo goed als versleten door het knippen en plakken vanuit de verschillende spreadsheets die ik van mijn teamleden ontving.

Oh ja, er is nog een andere functie van de lokroep van de projectleider. Op het moment dat iedereen in je team de techniek vóór zich kan laten werken, in plaats van dat ze mét techniek werken, kan er tijd besteed worden aan die andere kant waarvoor de lokroep het team samenbrengt: de inhoud, in plaats van discussies over de status van de acties

Naast de fysieke lokroep elkaar over de inhoud te ontmoeten wordt de lokroep van de projectleider over de status steeds vaker door software geroepen. Teamleden krijgen per e-mail of ander medium een signaal (vaak ‘notificatie’ genoemd). En als een status is bijgewerkt of een actie is afgerond klinkt het signaal door. Geen gejaag en geroep meer, maar het monitoren van voortgang geholpen door techniek zodat je op ieder moment weet waar jouw aandacht nodig is en je ook de opdrachtgever steeds van de actuele status van het project kan voorzien.