Wat je kunt stoppen met doen aan je projecten (met Patrice Embry)

Lees het transcript:

We proberen onze podcasts te transcriberen met behulp van een softwareprogramma. Vergeef ons eventuele typfouten, want de bot is niet altijd 100% correct.

Ben Aston:

Bedankt voor het luisteren. Ik ben Ben Aston en dit is de podcast van de Digital Project Manager.
Er wordt ons voortdurend verteld wat we allemaal zouden moeten doen, en ik ben een van die mensen die dat ook doet. Er is druk om jezelf te verbeteren, dingen goed te doen en vooral om gezien te worden terwijl je de juiste dingen doet. Maar moeten we dit allemaal voortdurend doen? Blijf luisteren naar deze aflevering om te ontdekken hoe je jezelf enorm veel tijd kunt besparen door bepaalde zaken uit je PM-routine te schrappen of te verminderen die je misschien niet voor elk project nodig hebt.
We gaan bespreken hoe je een deel van je leven kunt terugkrijgen en minder tijd op kantoor of achter je bureau kunt doorbrengen door zes dingen te schrappen waarmee je tijd kunt besparen. Deze podcast gaat echt over het afwerpen van de ketenen van wat we zouden moeten doen en van sommige zaken die we móéten doen, en over efficiënter omgaan met de manier waarop we werken.
Vandaag praat ik met Patrice Embry, die – en hiervoor moet ik haar complimenteren – waarschijnlijk de actiefste deelnemer is aan ons Slack-team. Als je je nog niet hebt aangemeld, zou je nu met Patrice kunnen praten. Ga naar het gedeelte community van de Digital Project Manager om je aan te melden. Patrice is er bijna altijd en praat voortdurend mee, dus ze is een goed persoon om te kennen.
Als korte introductie: Patrice is een freelance digitale PM. Ze is gecertificeerd scrum master niveau twee. Ze werkt al heel lang in de sector, bij allerlei verschillende bureaus en bedrijven. Luister naar enkele van onze andere podcasts voor meer inzicht in het soort werk dat ze heeft gedaan. Ze heeft aan van alles gewerkt, dus ze is een geweldig persoon om te kennen.
Welkom, Patrice.

Patrice Embry:

Hallo. Bedankt dat je me hebt uitgenodigd.

Ben Aston:

Graag gedaan. Patrice, kun je ons vertellen of je sinds ons vorige gesprek aan interessante projecten werkt?

Patrice Embry:

Ik heb net een app afgerond waaraan ik werkte. Die helpt mensen die op zoek zijn naar kortdurende, snelle opdrachten. Een beetje zoals Care.com, maar dan nog sneller, voor mensen die zulke kortdurende opdrachten echt uitgevoerd moeten krijgen. Het was een heel interessante app. Hij is nog niet helemaal klaar voor de wereld; hij bevindt zich nu in de bètafase. Maar het was een interessant project omdat ik met mensen van over de hele wereld werkte.
Ik had nog nooit met iemand uit Nigeria gewerkt, dus dit was de eerste keer dat ik in het Igbo hallo zei. Dat was erg leuk.

Ben Aston:

Dat klinkt als een frauduleus project. Niet het project zelf natuurlijk. Dat zijn duidelijk de klassieke Nigeriaanse oplichtingspraktijken. Zat het ontwikkelteam daar?

Patrice Embry:

Pardon?

Ben Aston:

Zat het ontwikkelteam in Nigeria?

Patrice Embry:

Ja.

Ben Aston:

O, echt?

Patrice Embry:

Ja. De front-endontwikkelaar zat in Nigeria. De back-endontwikkelaar zat in Mexico en onze technisch leider zat in Zweden. Dan waren er nog ik, buiten Philadelphia, en de klant in Boston. We zaten overal verspreid.

Ben Aston:

Dat zijn heel wat tijdzones om mee te werken.

Patrice Embry:

Ja, dat klopt.

Ben Aston:

Dat moet niet eenvoudig zijn geweest. Hoe heb je dat laten werken?

Patrice Embry:

Ik heb een tijdstip gevonden waar iedereen min of meer mee kon leven: acht uur ’s ochtends Eastern Time. Onze Europese vrienden vonden dat wat laat op de dag, het was behoorlijk laat voor onze Nigeriaanse collega en Mexico moest iets eerder opstaan dan hij wilde. Maar we hebben het laten werken.

Ben Aston:

Cool. Was de app bedoeld voor een start-up of voor…

Patrice Embry:

Ja. Het was, denk ik, een dienst die ontstond bij een vrouw die dit voor een paar mensen deed. Vervolgens vroegen een paar anderen: “Hé, kun je dat ook voor mij doen?” Dat ging maar door, totdat ze dacht: “Weet je wat, ik kan dit niet meer alleen coördineren.” Toen dacht ze volgens mij: “Laten we er een app voor maken.” Het project staat nog echt in de kinderschoenen, dus ik wil er niet te veel over vertellen. Maar zodra het live gaat, zorg ik ervoor dat ik iedereen erover vertel. Ik denk dat het een heel goede dienst voor mensen wordt.

Ben Aston:

Klinkt als een interessant project. Wat waren de grote uitdagingen waar je tegenaan liep? Was het eenvoudig of kwam je onderweg moeilijke momenten tegen?

Patrice Embry:

Het was een beetje lastig omdat de klant niet erg handig was met computers en ook niet bijzonder vertrouwd was met apps. Ze wist ongeveer hoe dingen normaal gesproken werken. Zoals je weet, hebben mensen in de technologiesector vaak wat meer inzicht in hoe dingen werken, dus er moest veel worden uitgelegd.
Het was een beetje alsof je aan een vriend uitlegt die niet elke dag op een computer werkt hoe bepaalde dingen werken. Dat speelde mee. Soms realiseer je je pas wanneer je echt bij een project betrokken bent welke dingen niemand ooit heeft bedacht. Het testen – en daarom bevindt de app zich nu in de bètafase – was zeer intensief. We zeiden steeds: “O ja, dit is een pad dat we nog nooit hebben gevolgd.” Dat maakte het uitdagend, maar het was ook erg leuk. Ik vond het prettig om met iedereen te werken en het is een heel mooi idee. Ik ben er behoorlijk tevreden over.

Ben Aston:

Welke hulpmiddelen gebruikte je om al deze mensen in verschillende tijdzones aan te sturen? Hoe verwerkte je de verschillende vereisten uit de eerste briefing, die nogal losjes leek, en hoe stuurde je vervolgens het project aan?

Patrice Embry:

Ja, die briefing was erg losjes. Er was niet veel extra geld beschikbaar, wat mooi aansluit bij waar we het vandaag over hebben. Ik had niet enorm veel uren om allerlei dingen te doen. Ik moest heel selectief zijn in wat ik wel en niet deed, omdat ik het budget voor mijn uren niet wilde overschrijden. Ik wilde zoveel mogelijk uren besparen voor de daadwerkelijke ontwikkeling.
We gebruikten Slack omdat het gratis was. We gebruikten Trello omdat het gratis was. We gebruikten veel Google-documenten omdat die gratis zijn. We moesten uitzoeken hoe we al die middelen voor ons konden laten werken zonder betaalde functies, omdat we zo efficiënt mogelijk moesten werken om dit project voor deze vrouw vooruit te helpen.

Ben Aston:

Hoe ben je aan dit project gekomen? Was het een aanbeveling via een vriend van een vriend? Want het klinkt als een start-up…

Patrice Embry:

Ja. Je kent me. Je zei dat ik voortdurend op Slack zit, maar jouw Slack is niet de enige Slack waarop ik voortdurend zit. Als freelancer moet je voortdurend zorgen dat je communicatielijnen met iedereen openstaan, zodat je zoveel mogelijk informatie kunt verzamelen. Ik praat met veel mensen over allerlei onderwerpen.
Ik kan me niet meer precies herinneren welke lange reeks gebeurtenissen me bij dit project bracht, maar het was waarschijnlijk iets als: “Hé, ik denk dat ik iemand ken die ik misschien op een andere plek heb gesproken. Weet iemand of iemand dit doet?” Het was waarschijnlijk zoiets. Ik netwerk veel, dus dingen komen op heel vreemde manieren op mijn pad.

Ben Aston:

Heb jij het projectteam samengesteld?

Patrice Embry:

Nee.

Ben Aston:

Was dat iets wat jij deed?

Patrice Embry:

Nee, dat deed ik niet. Ik werd in een groep mensen geplaatst en samen bepaalden we wat iedereen zou doen. Ik hoefde voor dit project geen mensen te zoeken. Ik was erg blij met het team waarin ik terechtkwam en ik zal in de toekomst met hen blijven communiceren. Hopelijk werken we allemaal nog eens aan een project samen, want ik waardeerde echt wat iedereen bijdroeg.

Ben Aston:

Dat is mooi. Ik vind het altijd interessant om aan dit soort projecten te werken, waarbij de klant soms minder vertrouwd is met technologie. Vaak betekent dat ook dat er veel flexibiliteit is. Het is geweldig om een klant te hebben die je vertrouwt en niet echt weet wat hij doet, maar zegt: “Jullie zijn de experts; zeg me gewoon wat we moeten doen.” Dan denk je: “Dit is het beste moment.” Je kunt veel van de juiste dingen doen.
Het nadeel is dat je soms de frustratie krijgt van: “Oké, probeer Ctrl+F5 eens.”

Patrice Embry:

Dat gebeurde vaak, ja. Maar weet je wat? Het is goed om daaraan herinnerd te worden, vooral wanneer je een app maakt voor het grote publiek. Niet iedereen begint met hetzelfde niveau van kennis over hoe dingen werken. Het was eigenlijk goed dat we terug moesten naar de basis, want daardoor beseften we dat we ook met de app zelf terug naar de basis moesten. We konden er niet zomaar van uitgaan dat mensen begrepen dat ze met hun vinger konden scrollen om de rest van het formulier te zien.
We moesten duidelijk maken dat ze moesten scrollen. Voor dit project pakte dat eigenlijk goed uit.

Ben Aston:

Goed. Laten we praten over wat je net noemde. We hadden het op Slack over de waarheid achter hoe we projecten daadwerkelijk beheren. Aan de ene kant is er de theorie. Zoals ik zei, publiceren we op de Digital Project Manager artikelen over hoe we projecten zouden moeten uitvoeren, over de juiste manier en over best practices die we in onze projecten kunnen toepassen.
Ik dacht dat het interessant zou zijn om te praten over de werkelijke manier waarop we projecten dagelijks beheren, wanneer er zoveel te doen is. Zeker wanneer je een goede opleiding in projectmanagement hebt gevolgd, bijvoorbeeld voor een PMP, en je de PMBOK, alle processen, werkstromen en registers kent die je zou moeten gebruiken. Dan krijg je al snel allerlei verschillende statusrapporten en wordt het één grote administratieve nachtmerrie.
Volgens mij is de waarheid dat we altijd overbelast zijn. Er is altijd documentatie die je zou kunnen bijwerken of iets anders dat je zou kunnen doen. Maar doen we dingen omdat ze de juiste dingen zijn om te doen, of besteden we te veel moeite aan de verkeerde zaken? We hadden het net over het idee van starten, stoppen en doorgaan. Waar zouden we mee moeten beginnen? Waar zouden we mee moeten stoppen of wat zouden we moeten verminderen? Waar kunnen we mee doorgaan?
Ik ben benieuwd naar jouw perspectief, te beginnen op hoofdlijnen: wat zijn de niet-onderhandelbare zaken? Wanneer je voor het eerst op een project komt – misschien zelfs het project waar je het net over had – wat moet er dan minimaal geregeld zijn, anders loopt het project vast of ontspoort het voordat het goed en wel begonnen is?

Patrice Embry:

Voor mij zijn dat altijd de planning en de vereisten. Daarna komt het budget. Het budget is voor verschillende projecten om verschillende redenen belangrijk, maar aan een planning kun je volgens mij nooit ontsnappen. Je hebt een redelijk gedetailleerde planning nodig. Ook aan vereisten kun je niet ontsnappen, want anders heb je geen idee wat je aan het doen bent en je team evenmin. Dat zijn de twee absolute vereisten. Naar mijn mening zijn dat de niet-onderhandelbare zaken.

Ben Aston:

Even voor de duidelijkheid: als je het over vereisten hebt, bedoel je dan niet een statement of work? In welke vorm staan die vereisten dan?

Patrice Embry:

Dat is een goede vraag, want ze hoeven niet per se in een document te staan. Maar je moet weten wat de scope is en wat er zelfs voorbij die scope ligt. Eén stap verder dan de scope: wat moet dit product kunnen? Wanneer ik een statement of work bekijk, wordt er meestal een aantal dingen als vanzelfsprekend beschouwd. Niet alles staat erin beschreven. Er komt nog een extra laag van zaken die moeten worden uitgevoerd, besproken of overwogen, plus functies die nodig zijn om de scope te realiseren. Daar heb ik het over.
Die zaken moeten worden gedefinieerd. Mensen moeten weten wat ze zijn. Ze sturen het werk van iedereen aan. Anders weet je werkelijk niet wat je aan het bouwen bent. Dat zijn de vereisten die ik bedoel.

Ben Aston:

Ja, dat klopt. Voor mij zijn het een raming, een planning en een statement of work wanneer ik voor het eerst op een project kom en iedereen op één lijn breng. Dat is de documentatie waar ik naar op zoek ben. Als je de planning en de vereisten niet kent, kun je het project onmogelijk beheren en controleren. Als je niet weet hoe het eruit hoort te zien, weet je ook niet of je op schema ligt.

Patrice Embry:

Hoe weten we anders wanneer het klaar is? Hoe weten we of het niet is stilgevallen? Ja, precies.

Ben Aston:

Toch zijn die zaken vaak verouderd wanneer je een project overneemt. Vooral de vereisten of het statement of work. Dan hoor je: “Daar hebben we over gesproken en we hebben afgesproken iets anders te doen.” Hoe zorg je er dan voor dat iedereen gedurende het project dezelfde uitgangspunten blijft hanteren?

Patrice Embry:

Ik herinner mensen elke week, of telkens wanneer we bijeenkomen om over het project te praten, aan de planning. Misschien is dat vaker dan één keer per week, misschien om de twee weken. Het hangt van het project af, maar ik herinner mensen altijd aan onze positie in de planning. Wat is onze volgende deadline en meestal ook de deadline daarna, zodat we weten waar we naartoe werken?
Ik herinner hen aan de einddatum en aan het doel waar we naartoe werken. Niet noodzakelijk de lanceringsdatum, maar bijvoorbeeld wanneer we klaar moeten zijn voor QA of UAT. Ik herinner iedereen daaraan en laat het altijd weten als er iets verandert. Wanneer we dreigen iets niet te halen, horen mensen het meest van mij.
Wat de vereisten betreft: ik probeer die zo goed mogelijk bijgewerkt te houden. Het is prettig wanneer ze in een systeem zoals Trello staan, waar je kunt blijven bespreken wat iets moet zijn, kunt zien hoe zaken zich ontwikkelen en kunt terugvinden wat we voor een functie uiteindelijk hebben afgesproken. Alles kan op één plek worden verzameld en doorzocht.
Als je zo werkt, moet je de vereisten actueel houden. Als je zulke hulpmiddelen niet gebruikt, betekent het dat je een vorm van documentatie moet bijhouden met afspraken met de klant, zaken die je hebt besloten om tijd te besparen en zaken die je later nog moet toevoegen. Het is voortdurend documentatie bijwerken, in welke vorm die ook staat.

Ben Aston:

Zeker. Vaak schrijf ik een statement of work en dien ik vervolgens wijzigingsverzoeken of updates daarop in, meestal als een Word-document wanneer het project een andere richting opgaat. Zo heb ik een handtekening van de klant bij: “Ja, ik weet dat we deze wijziging doorvoeren en ik keur die goed.”
Die hele papiertrail, vooral wanneer je meerdere klanten hebt of wanneer er verwarring is over wie het project werkelijk leidt, kan volgens mij erg belangrijk zijn.

Patrice Embry:

Absoluut.

Ben Aston:

Laten we het dan hebben over enkele zaken die misschien niet altijd volledig uitgewerkt of overontwikkeld hoeven te worden. Een van de dingen die je in het artikel noemt, zijn gedetailleerde budgetten en projectuitsplitsingen. Wil je daar wat meer over vertellen?

Patrice Embry:

In het begin van mijn loopbaan werkte ik op een plek waar alles precies op een bepaalde manier moest gebeuren. Ik was een onderdeel van een heel groot geheel met veel andere projectmanagers die allerlei taken uitvoerden. We waren met veel mensen en iedereen moest alles op dezelfde manier doen. Er was veel van: “Zo doen we dat.”
Pas toen ik voor kleinere bureaus ging werken en daarna freelancer werd, dacht ik: “Je kunt dit niet altijd allemaal doen, want dan wordt het erg moeilijk om je budget intact te houden en misschien heb je er ook de tijd niet voor.” Toen ik bij dat grotere bureau werkte en alles uitvoerde wat verplicht was, hoorde daar ook een zeer gedetailleerd budget bij. Het was ouderwets. Ik maak mijn budgetten nog steeds op een vrij traditionele manier. Ik zet ze in een spreadsheet met draaitabellen, voorwaardelijke opmaak en cellen die naar andere cellen verwijzen. Zo zie je het percentage dat klaar is, wat er nog moet gebeuren, hoe dat zich verhoudt tot het budget en hoe ver je van je prognoses afwijkt. De prognoses werden wekelijks per rol opgesteld.
Het is behoorlijk uitgebreid. Meestal werkt dat goed voor mij, omdat ik op elk moment elke vraag kan beantwoorden wanneer ik dat detailniveau van het budget bijhoud. Maar als het bijhouden van zo’n gedetailleerd budget veel meer uren van mijn tijd vraagt en de klant er niets om geeft, dan moet je nagaan wat nodig is. Als degene die je betaalt niet de klant is, maar je bureau of de partij waarvoor je werkt, moet je ervoor zorgen dat je alleen oplevert wat nodig is.
Voor mij zou dat betekenen dat ik geen budget en prognose meer zou maken met hetzelfde detailniveau als ik gewend ben. Het kostte wat tijd om me daar goed bij te voelen, maar soms hoef je een bepaald rapportageniveau niet te halen. Mijn advies aan mensen die zich afvragen: “Moet ik dit allemaal echt doen?” is om jezelf af te vragen wat je moet doen en hoeveel daarvan nodig is. Kun je minder doen? Schaadt meer doen je budget? Schaadt minder doen je project? Zoek dat uit en maak geen uitgebreide budgetuitsplitsingen uit plichtsbesef, maar omdat ze goed zijn voor het project.

Ben Aston:

Dat is nuttig. Stel je voor je projectmanagementtijd een percentage vast van het totale aantal uren van het team dat je aanstuurt, of doe je dat meestal per taak?

Patrice Embry:

Vroeger deed ik dat op basis van een percentage. Bij grotere bureaus werkte dat goed wanneer er ruimte was om zaken op te vangen waar je geen rekening mee had gehouden. Ik vond dat ik uiteindelijk naar elke taak moest kijken. Ik ben nogal nauwgezet met ramingen en heb daar een sterke mening over.
Ik bekijk meestal de taakverdeling van het volledige project. Als ik vervolgens een percentage voor mijn tijd gebruik, bereken ik dat per taak. Ik gebruik niet langer een percentage van het totaal, omdat dat voor kleinere bedrijven en voor mij als freelancer niet specifiek genoeg is om te dekken wat ik nodig heb.
Ik denk dat het prima is om met een totaalpercentage te werken als dat voor jou goed werkt. Voor mij dekte het de laatste tijd niet meer wat nodig was.

Ben Aston:

Ik begrijp het. Het was dus niet te veel, maar je had juist niet genoeg uren?

Patrice Embry:

Ja, ik had niet genoeg uren. Of beter gezegd: meestal had niemand genoeg uren. Het project was gewoon niet goed geprijsd. Daarom moet je ervoor zorgen dat je ramingen kloppen en dat je geld verdient aan het project. Misschien lag het niet aan de percentages zelf, maar aan het feit dat ze waren gebaseerd op een bedrag dat vanaf het begin niet juist was.

Ben Aston:

Dat zie ik ook. Ik ben gewend dat projectmanagement twintig procent van de totale projectkosten bedraagt en accountmanagement daar bovenop komt. De belangrijkste conclusie is volgens mij dat je je gedetailleerde budget en prognoses moet aanpassen aan de klant met wie je werkt. Je hoeft dit niet onnodig ingewikkeld te maken.
Het hangt ook af van de bereidheid van de klant om ervoor te betalen. Als je een klant hebt die veel risico’s wil vermijden en elk detail wil kennen van de middelen en hoe die zich over het hele project verdelen, dan is dat een kwestie van voorlichting. Dat kost geld.
Er is projectmanagementsoftware waarin je aan het begin al deze cijfers invoert en waarin tijdregistratie en het project samenkomen. Dan kan het systeem alles voor je doen. In de meeste projecten is het echter handwerk. We halen uren uit urenstaten, voeren die in een spreadsheet in en maken berekeningen. Dat is een grote, dure taak.
Als je voor een lichtere aanpak kiest en zegt dat je geen gedetailleerde budgetuitsplitsing gaat leveren, hoe zorg je er dan voor dat je op koers blijft? Wat is je lichtere werkwijze wanneer je niet zo gedetailleerd te werk gaat?

Patrice Embry:

In het verleden zou ik bijvoorbeeld de totale urenprognose hebben uitgesplitst en het budget hebben verdeeld over uren en prognoses per rol. Ik zou de werkelijke uren invoeren en vervolgens de prognoses voor de rest van het project aanpassen. Bijvoorbeeld: “Deze week heb ik te veel tijd gebruikt, dus ik moet die tijd ergens vandaan halen. Mijn prognoses voor de komende weken veranderen daarom een beetje.”
Dat zou het eerste zijn wat ik schrapte als ik niet genoeg tijd, budget of capaciteit had om een budget zo uitgebreid te beheren. Je hebt nog steeds je oorspronkelijke prognoses en kunt zien waar je staat, maar je past niet elke afzonderlijke prognose aan telkens wanneer je je budgetoverzicht bijwerkt. Voor mij gebeurde dat wekelijks en het kostte behoorlijk veel tijd.
Het voordeel is dat je heel vroeg weet waar problemen kunnen ontstaan en veel eerder aan de bel kunt trekken. Maar het kost ook tijd en geld. Er zijn andere manieren om waarschuwingssignalen te herkennen. Dat zou dus waarschijnlijk het eerste zijn wat ik schrap.
Ook alle berekeningen waarmee ik elk stukje informatie op vijf verschillende manieren kon uitsplitsen, zouden verdwijnen. Dan ga je terug naar de basis: liggen we op budget, dreigen we het budget te overschrijden, hebben we nog genoeg uren voor wat we moeten doen? Komt het percentage voltooid ongeveer overeen met het percentage van het budget dat is gebruikt? Ja? Prima, dan gaan we verder.
Maak de spreadsheet of het hulpmiddel niet ingewikkelder dan nodig en richt je op de basis.

Ben Aston:

Dat is erg nuttig. We hebben het over het aanpassen van onze aanpak aan verschillende projecten en klanten. Bij een groot project met veel middelen moet je er rekening mee houden dat je verbruik veel sneller oploopt. Als je bijvoorbeeld elke week vijftigduizend aan budget verbruikt, heb je na een halve week al vijfentwintigduizend uitgegeven. Je moet dus ook bij grote projecten nadenken over hoe je het budget controleert en rapporteert. De mate waarin je in de cijfers duikt, moet worden afgestemd op het totale budget.
Bij een kleiner team met slechts enkele mensen is de impact van langer wachten met het controleren van de gegevens natuurlijk minder groot.

Patrice Embry:

Ik zou nog steeds elke week alles controleren. Ik zou alleen niet volledig opgaan in de analyse. Ik zou de cijfers iets meer voor waar aannemen. Ik ben klanten en opdrachtnemers tegengekomen die aan mij uitbesteedden. Er was een klant en iemand die mij betaalde maar niet de klant was, meer een accountmanager. Die had iets voor een vaste prijs aan de klant verkocht en zei vervolgens tegen mij: “Het maakt me eigenlijk niet uit als we het budget overschrijden.” Dan denk ik: “Oké.”
Dat kan prettig zijn, maar zonder grenzen kan het ook volledig uit de hand lopen. Of iemand nu wilde dat ik een budget opstelde of niet, ik zou het toch doen, want het is onverantwoord om dat niet te doen. Ik moet kunnen laten zien wat iedereen heeft gedaan en hoeveel tijd dat kostte. Zelfs als iemand zegt: “Geld speelt geen rol.” Dat klinkt geweldig, maar het maakte mij juist wat angstig, omdat ik dacht: “Hoe weten we dan of we het goed doen?”

Ben Aston:

Het is ook bijna altijd misleidend. Wanneer mensen zeggen: “Geld speelt geen rol” of “We weten dat we het budget overschrijden, maak je geen zorgen”, is er een groot verschil tussen tienduizend en honderdduizend of vijfhonderdduizend boven budget gaan.

Patrice Embry:

Na een tijdje merk je het niet eens meer. Je kunt zo ver over budget gaan dat het letterlijk niet meer lijkt uit te maken, waarna iedereen maar wat doet. Dat is vreselijk. Ik heb aan zulke projecten gewerkt en het is verschrikkelijk.

Ben Aston:

Tot het team zegt: “O ja, we zijn drie maanden geleden al over budget gegaan.”

Patrice Embry:

Dan maakt het toch niet meer uit.

Ben Aston:

Dan blijft iedereen tijd aan het project toevoegen en wordt de situatie steeds erger. Zodra het resterende budget nul is, vraag je je af of je negatieve getallen moet gaan gebruiken. Iemand moet dat bijhouden.
We hadden het over statusupdates, een van je punten in het artikel. Hoe uitgebreid moet een statusupdate zijn? In een statusrapport dat we naar klanten sturen, vermelden we meestal de stand van het budget, hoeveel we die week hebben gebruikt, wat we doen en wat we de volgende week van plan zijn. Je kunt er ook budgetuitsplitsingen, prognoses, risico’s en problemen in opnemen. Eigenlijk kun je alles in een statusrapport zetten. Hoe stem je dat af?

Patrice Embry:

Het grappige is dat we als projectmanagers soms onbewust het gevoel hebben dat onze statusrapporten een weerspiegeling zijn van de waarde die we aan het project toevoegen. Als je statusupdate niet uitgebreid is, betekent dat dan dat je geen goede projectmanager bent?
Ik wil nooit dat iemand tegen me zegt: “Wat doe je eigenlijk met al die uren?” Soms stoppen we alles in statusrapporten om onze waarde te tonen, om te laten zien dat we alles bijhouden of om de waarde van het bureau aan te tonen. Maar het kost veel tijd en moeite om dat allemaal bij te werken, terwijl het misschien niet nodig is.
Bij de app waar ik onlangs aan werkte, wilde de klant alleen weten of alles goed ging, of we de afgesproken datum zouden halen en of we op haar wachtten. Ze wilde geen bottleneck worden. Meestal deed ze niet eens mee aan de statusgesprekken omdat ze andere dingen te doen had en het geen prioriteit voor haar was. Ze wilde slechts drie dingen weten: gaat het goed, halen we de afgesproken datum en heb je iets van mij nodig?
Ik stelde zulke statusrapporten op en dacht: “Waarom doe ik dit? Dit is niet nodig.” Ik schreef wat we de vorige week hadden afgerond en wat we deze week van plan waren, maar daar gaf ze niets om.
Ik zou graag denken dat ze me vertrouwde, maar waarschijnlijk had ze gewoon geen tijd. Toch houden we het erop dat ze me vertrouwde. Ze vertrouwde erop dat ik alles regelde en wilde alleen weten of het goed ging.
Dat is één type klant. Er zijn allerlei soorten klanten. De kern is dat je nadenkt over je klant en wat die belangrijk vindt. Vul het rapport niet met zaken om je waarde te bewijzen. Waarschijnlijk kun je behoorlijk wat uit je statusrapporten schrappen als je je alleen richt op wat jij of de klant nodig heeft.

Ben Aston:

Dat is geweldig advies. Vaak nemen we een statusrapport van een vorig project, veranderen de klantnaam en de datum en denken we: “Dit is een goed rapport, laten we dit gebruiken.” Vervolgens ontdek je dat je informatie hebt toegevoegd omdat de vorige klant daarom vroeg. Je denkt: “Dat was eigenlijk nuttig, laten we dat opnieuw doen.” Zo ontstaat een opgeblazen statusrapport. De klant is misschien niet geïnteresseerd in alle details, maar wil gewoon weten of alles goed gaat. We geven dan informatie die niet nodig is.
Ik denk dat je moet beginnen met de vraag hoe je het rapport tot het absolute minimum kunt terugbrengen. Als de klant meer wil weten, kan hij dat vragen en kun je het toevoegen. Maar wees ervan overtuigd dat dit alle informatie is die je hoeft te geven. Zodra je uren bezig bent met een statusrapport, is dat een waarschuwingssignaal dat er iets niet klopt.

Patrice Embry:

Ik heb klanten gehad die om een andere manier van budgetrapportage of om meer informatie vroegen. Dan zei ik: “Ik heb tijd begroot voor deze statusrapporten en besteed hier nu een bepaald aantal uren per week aan. Als je wilt dat ik zo doorga, is dat prima. Maar als je iets wilt toevoegen, kost dat minstens nog een uur per statusrapport, of een halfuur.”
Dat klinkt niet als veel, totdat je berekent hoeveel uren dat gedurende de rest van het project kost. Dan vraag ik: “Weet je zeker dat je dat wilt?” Meestal zeggen ze dan: “Kun je het één keer doen? Dan kijken we of we ermee doorgaan.” Of: “Het is niet zo belangrijk; ik dacht alleen dat het interessant zou zijn om te weten.” Op die manier kun je mensen soms van het idee afbrengen.

Ben Aston:

Dat klopt. Wanneer je uitlegt wat de gevolgen zijn van hun verzoek en zegt: “Als je elke week gedurende de komende vijfentwintig weken een extra uur wilt, besef je dan dat dit je vijfduizend kost?” Dan zeggen ze: “Nee, dat is het niet waard.”

Patrice Embry:

Precies.

Ben Aston:

Dan doen we het niet. De enige kanttekening is dat ik bij een risicovol project, een lastige klant of een project waarvan ik weet dat het mis kan gaan, de risico’s juist in het statusrapport zou benadrukken. We mogen niet zo weinig rapporteren dat we onszelf niet meer indekken en geen bewijs hebben dat we ooit hebben gewaarschuwd voor iets dat mis kon gaan.

Patrice Embry:

Absoluut.

Ben Aston:

Dat kan dus.

Patrice Embry:

De vuistregel is volgens mij dat je er heel zeker van moet zijn voordat je iets verwijdert. Je moet zeker weten dat je het niet nodig hebt en dat je het opnieuw kunt toevoegen als dat toch nodig blijkt. Je vertrouwen kan voortkomen uit eerdere ervaring met die klant, dat soort project of het werken als projectmanager. Laat je eigen comfortniveau je leiden. Zo voorkom je dat je iets schrapt wat je wel degelijk nodig hebt.

Ben Aston:

Zeker. Dat is een goede waarschuwing. Een ander punt in je artikel gaat over alle scrumceremonies. Bij scrum zijn er ceremonies en die maken scrum tot scrum. Als je scrum-mastertraining hebt gevolgd, leer je dat. Je besteedt er twee dagen aan. Het gaat om die ceremonies: scrumplanning, scrumreviews en retrospectives. Maar wanneer je ze allemaal inplant, kan zelfs een sprint van twee weken één of twee dagen aan vergaderingen kosten. Al die planning, reviews en ceremonies kunnen veel tijd opslokken.
Je suggestie is dat je ze misschien niet altijd allemaal hoeft te doen of dat je ze kunt samenvoegen.

Patrice Embry:

Ik ken mensen die heel sterk op Scrum gericht zijn en boos worden wanneer je voorstelt iets anders te doen. Maar volgens mij zijn de meeste gecertificeerde scrum masters het erover eens dat je niets moet doen wat niet nodig is voor een project. De vraag is alleen welke dingen dat zijn.
Als je eerst een sessie voor het opschonen van de backlog hebt, daarna een sprintplanningssessie en vervolgens een sprintreview, allemaal op verschillende dagen of tijdstippen, kan dat snel zwaar worden als je het budget niet hebt.
Ook hier draait het om tijd en budget. Als je beide hebt, ga ervoor. Als je die niet hebt, kun je de sessies voor het opschonen van de backlog, de planning en de reviews samenvoegen. Dat kan voordelen bieden omdat je momentum behoudt. In plaats van steeds te stoppen en later terug te komen voor een planningssessie, kun je de inzichten uit het opschonen van de backlog en de review meteen gebruiken voor de planning.
Gebruik je oordeel. Als je drie uur besteedt aan iets dat in negentig minuten kan, is het misschien tijd om die aanpak opnieuw te bekijken.

Ben Aston:

Het idee dat dit niet altijd afzonderlijke activiteiten hoeven te zijn, is erg nuttig. Dat geldt vooral voor retrospectives, waarin het gaat om voortdurende verbetering en het voortdurend aanpassen van de manier waarop we het project beheren.
In je artikel zeg je ook dat je het licht moet houden. Ik heb retrospectives meegemaakt waarbij je iedereen een enquête stuurt, feedback verzamelt en statistieken maakt zoals: 49% vond het project een ramp en 25%… Wat ga je daar eigenlijk mee doen? Wat ga je na dat moment concreet veranderen?
Dingen samenvoegen en ze afstemmen op wat er werkelijk is gebeurd, lijkt me verstandig. Soms doen we een retrospective en denken we: “Weet je wat? Deze sprint ging prima.”

Patrice Embry:

Alles is goed. Twee duimen omhoog.

Ben Aston:

Precies. Dan hoef je dit soort rapporten niet verder uit te werken. Ga gewoon verder. Je hoeft er geen uur extra aan te besteden. Soms raken we verstrikt in wat we denken te moeten doen.

Patrice Embry:

Ja. Het is hetzelfde als bij statusrapporten: misschien voelen we dat we daarmee onze waarde voor klanten bewijzen. Een retrospective kan ons het gevoel geven dat we onze bestaansreden moeten rechtvaardigen tegenover interne belanghebbenden, bureaueigenaren of bedrijfseigenaren. Vraag jezelf bij al die zaken af: “Hoe nuttig is dit? Is het vijf uur werk waard? Twee uur? Heb ik vijf uur, twee uur of dertig minuten? Ik heb dertig minuten.” Bepaal dan gewoon of het een goed project was en identificeer één duidelijk probleem als dat er was. Ga daarna verder.

Ben Aston:

Goed. Laten we tot slot praten over kick-offbijeenkomsten. In je artikel stel je voor dat je misschien geen kick-offbijeenkomst nodig hebt en in plaats daarvan een e-mail kunt sturen. Dat vind ik interessant. Hoe werkt dat? Je start een nieuw project, stelt een team samen, iedereen krijgt middelen toegewezen en dan stuur je een e-mail met: “Dit moet je doen”?

Patrice Embry:

Ja.

Ben Aston:

Tot over een week.

Patrice Embry:

Ja. Het klinkt misschien gek, maar ik begon dit te doen toen ik bij een farmaceutisch bureau werkte. We deden daar bij verschillende klanten veel dezelfde soorten projecten. Het was niet volledig volgens een vast patroon, maar er waren niet veel nieuwe, verrassende dingen die we voor elk communicatiemiddel deden. Dit werkte vooral goed voor drukwerkprojecten, waar ik een tijd aan heb gewerkt. De teams bestonden bijna altijd uit dezelfde mensen. Ze waren aan dezelfde klanten toegewezen en kenden hun rol. Dat was een van de dingen die ik in een kick-offbijeenkomst zou doen: ervoor zorgen dat iedereen zijn rol kende.

Ben Aston:

Juist.

Patrice Embry:

Iedereen kende zijn rol al. Er waren twee ontwerpers, altijd één ontwikkelaar en meestal twee accountmanagers. Iedereen wist wat hij moest doen. We kwamen bij elkaar en dachten: “Ik heb zoveel te doen; ik kan niet eens dertig minuten vrijmaken voor deze kick-off.” Dus vroeg ik: “Als iedereen zijn rol en deze klant al kent en iedereen al eerder een vergelijkbaar project heeft gedaan, wat moeten ze dan nog weten?” Ze moeten weten wat dit project anders maakt dan de andere vergelijkbare projecten. Die zaken beschreef ik. Ze moesten de planning kennen, iets wat ik toch al in een kick-off zou meenemen. Ik kon erover praten, maar ze wilden de planning kunnen bekijken en verwerken. Ik wilde hun ook meteen de eerste taken geven.
Als iedereen de rest al weet, kan dat dus in een e-mail. Ze vonden het eigenlijk prettig dat ik hen niet liet zitten om alles te bespreken wat ze al vaker hadden gehoord. Als je herhaalbare projecten doet met steeds dezelfde mensen, heb je misschien geen kick-offbijeenkomst nodig. Je kunt een kick-offmail sturen. Ik heb dat vaak gedaan en het werkte goed.

Ben Aston:

Ik zie dat wel werken wanneer je iets herhaalbaars doet. In mijn situatie is er meestal iemand nieuw bij het project betrokken of is er een nieuw element. Toch gaat het hier ook om de vraag: “Waarom doen we dit, omdat we het altijd zo doen?” In jouw voorbeeld gaat het om wat mensen echt moeten weten om met het werk te kunnen beginnen.
Een ander punt waarop we soms te veel tijd besteden en te veel uitwerken, is het schrijven van briefings. Je hebt het eigenlijk over een e-mail met daarin een briefing. Briefings zijn absoluut belangrijk en nuttig, maar in templates staan vaak onderdelen waarbij je denkt: “Ik moet weer precies hetzelfde kopiëren en plakken en slechts drie woorden veranderen.” Als je met hetzelfde team werkt, moet je het briefingsproces efficiënter maken en voorkomen dat je tijd besteedt aan het herhalen van informatie die iedereen al kent.

Patrice Embry:

Dat klopt.

Ben Aston:

Richt je gewoon op: “Dit proberen we te doen. Dit heb ik van jullie nodig. Dit is de taak die moet worden uitgevoerd. Is iedereen het daarmee eens?” Wees niet formulematig in de manier waarop je alles aanpakt met templates. De conclusie van ons gesprek is voor mij: behandel elk project als uniek. Het feit dat je vorige keer iets goed hebt gedaan en er veel moeite in hebt gestoken, betekent niet dat je exact hetzelfde proces, dezelfde documentatie en dezelfde grondigheid op elk project moet toepassen. Je kunt dingen anders doen. Je hoeft niet elke keer exact hetzelfde te doen. Stem je aanpak af op het project.

Patrice Embry:

Absoluut.

Ben Aston:

Goed. Patrice, bedankt dat je bij ons was. Het was geweldig om je erbij te hebben. Als je wilt deelnemen aan het gesprek van vandaag, laat dan een reactie achter bij Patrices artikel of ga naar het gedeelte community van thedigitalprojectmanager.com en praat daar mee. Tot de volgende keer, bedankt voor het luisteren.