De projectlijnen inkleuren (met Maik Stettner van EA Games)

Lees het transcript:

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

Ben Aston

Welkom bij de DPM-podcast, waarin we verder gaan dan theorie en deskundig PM-advies geven voor het leiden van betere digitale projecten. Bedankt dat je luistert, ik ben Ben Aston, de oprichter van The Digital Project Manager. Laten we eerlijk zijn: ben je klaar om je projecten binnen budget op te leveren? En volgens planning? Ben je ook klaar om de scope op te leveren die je hebt beloofd? Weet je dat niet zeker? Hoe weet je dat dan en hoe doe je dat? Daar gaat de podcast van vandaag eigenlijk helemaal over: projectbeheersing.

Het zijn eigenlijk gewoon de lijnen die we rond onze projecten trekken om ons te helpen de parameters van het project te kennen. Waar we moeten inkleuren. En ze helpen ons te weten wanneer we buiten die lijnen van ons project inkleuren.

Deze aflevering wordt gesponsord door Resource Guru, de tool voor resourceplanning die wordt gebruikt door teams bij bedrijven als Apple, Ogilvy, Deloitte en Publicis. DPM-luisteraars krijgen levenslang 20% korting op hun account met de kortingscode DPM2018.

Lees meer bij Resource Guru

Vandaag praat ik met Maik Stettner. Maik is onlangs benoemd tot development director voor EA Games, daarvoor werkte hij bij FCV, en hij leidt daar het team. Hij is ook een van onze vaste DPM-experts bij de opleiding van The Digital Project Manager. En wanneer je een team van PM's leidt, is een van de dingen waar je echt gepassioneerd over raakt projectbeheersing. Maik heeft daar volop ervaring mee. Je wilt echt dat je team binnen budget oplevert. Je wilt echt dat je team die deadlines en die mijlpalen haalt, anders beginnen de zaken uiteen te vallen en moet je ingrijpen. Daarom praten we vandaag over hoe we onze projecten beter kunnen beheren en welke beheersmaatregelen we kunnen invoeren. Ten eerste weten we zo of we op koers liggen. En ten tweede geeft het ons opties voor wanneer we van koers beginnen af te wijken.

Ik hoop dat dit goed klinkt. Maik, hallo en welkom bij de show.

Maik Stettner:

Hé Ben. Bedankt voor de uitnodiging.

Ben Aston:

Goed je weer te spreken. Maik, vertel ons eens wat over … Je gaat nu eigenlijk van rol veranderen: van FCV, waar je leiding gaf aan een team PM's, naar development director bij EA Games. Weet je al wat dat precies betekent?

Maik Stettner:

Daar kom ik heel snel achter. De focus ligt nog steeds op projectmanagement. Omdat ik natuurlijk van een bureauachtergrond overstap naar de gamesindustrie bij Electronic Arts, heb ik in mijn loopbaan eerder in verschillende sectoren gewerkt, dus games zijn niet helemaal nieuw voor me. Ik kijk ernaar uit om er weer in te duiken. Vanuit projectmanagementperspectief is het behoorlijk complex. Het is dus best uitdagend en dynamisch, en waarschijnlijk ga ik dit hele projectbeheersingsidee daar ook voor gebruiken.

Ben Aston:

Mooi. En als je nadenkt over een nieuwe rol en het leren van verschillende tools en werkwijzen: is er iets dat je recent hebt ontdekt of gebruikt waarvan je denkt: “Ja, dit wil ik zeker meenemen naar mijn nieuwe rol”? Nieuwe tools of benaderingen die je hebt gebruikt?

Maik Stettner:

Ik heb het gevoel dat ik in elke functie waarin ik heb gewerkt altijd nieuwe aspecten en perspectieven heb geleerd over hoe je problemen kunt aanpakken. Vooral wanneer je in software of digitaal projectmanagement werkt, kom je vergelijkbare problemen tegen, maar er kunnen alternatieve manieren zijn om ze op te lossen. Dat kan via tools zoals tools voor het volgen van problemen, die na verloop van tijd steeds beter worden, of via tools die de analyses opleveren die je nodig hebt om ad-hocbeslissingen te nemen. Ik denk niet dat ik echt één tool kan noemen, behalve eigenlijk de gebruikelijke verdachten. Maar vanuit mijn perspectief is het best interessant om te beseffen dat veel problemen — of je nu een app, desktopsoftware, website, game of wat dan ook bouwt — behoorlijk vergelijkbaar zijn. Ook de manier waarop je ze oplost, is goed met elkaar te vergelijken.

Ben Aston:

Ja, een interessant inzicht dat ik heb opgedaan sinds ik ben begonnen met interimwerk, is dat je soms denkt dat je weet hoe je iets moet doen — bijvoorbeeld resourceplanning, waarvoor je een tool als Resource Guru kunt gebruiken, of andere tools zoals Harvest, dat een tool genaamd Forecast heeft — maar vervolgens probeer je een nieuwe tool te gebruiken, of een tool te gebruiken zoals het andere bureau dat doet, en ontdek je dat het een totaal ander verhaal is. Dezelfde tool kan op zoveel verschillende manieren worden gebruikt dat het soms behoorlijk lastig wordt.

Maar ik denk dat wat je zegt over gegevens en analyses ontzettend belangrijk is. En dat sluit volgens mij aan bij het artikel dat je hebt geschreven over projectbeheersing. Wanneer we leiding geven aan een team van projectmanagers of met projectmanagers werken, willen we er zeker van zijn dat we niet voortdurend alleen op onze intuïtie vertrouwen, of op het gevoel dat iets op koers ligt of dat het project goed loopt. Gegevens zijn zo cruciaal, toch?

Maik Stettner:

Zeker. Vooral in mijn rollen als manager van PM's heb ik niet altijd volledig zicht op het detailniveau waarop de PM die aan het project werkt dat wel heeft. Ik ben dus behoorlijk afhankelijk van het bekijken van die gegevenspunten: hoe ontwikkelt het budget zich, hoe is het verbruikstempo en ga zo maar door. Op basis daarvan kan ik meestal beslissingen nemen, in samenwerking met bijvoorbeeld de projectmanagers of het team dat eraan werkt.

Ben Aston:

Dit zijn dus in wezen onze projectbeheersingsinstrumenten. Wanneer we nadenken over programmamanagement of over het managen van een team projectmanagers, kijken we naar deze gegevens. En dit zijn de soorten artefacten die de projectmanagers in ons team produceren. Vertel eens over projectbeheersing. Hoe zou je projectbeheersing definiëren of begrijpen? Het zijn de dingen die we gebruiken om onze projecten te beheersen, maar wat zijn het precies? Of wat kunnen ze zijn?

Maik Stettner:

Het is een wat intimiderende term. Voor mij beschrijft projectbeheersing in feite alle tools die je nodig hebt om de juiste informatie te krijgen, zodat je gefundeerde beslissingen kunt nemen. Het gaat dus om alle gegevenspunten die je kunt verzamelen om beslissingen te nemen over zaken als kosten, tijd, scope enzovoort. Uiteraard hangt dit rechtstreeks samen met klantinteracties en met alle dynamische beslissingen die je in een project moet nemen. Is het team groot genoeg? Heb ik iemand extra nodig? Liggen we op schema? Blijven we binnen budget? En ga zo maar door. Het is dus eigenlijk een raamwerk op hoofdlijnen voor het beheren van projecten en het nemen van gefundeerde beslissingen.

Ben Aston:

Welke documenten vind je daarvoor het nuttigst? We kunnen allerlei verschillende documentatie produceren. Als we het terugbrengen tot de basis: wat zijn volgens jou de nuttigste documenten, of wat vind jij het nuttigst als PM die zelf een project beheert, en misschien ook als programmamanager of delivery director die teams van PM's aanstuurt?

Maik Stettner:

Het meest standaarddocument dat ik iedereen aanraad, is het opstellen van een eerlijk statusrapport. Dat is in feite een rapport over het project met alle relevante kengetallen van het lopende project: totale projectkosten, resterend budget, het verbruikstempo, wat er de afgelopen maanden is bereikt, en actiepunten, risico's, blokkades en besluiten op hoofdlijnen. Bij projecten waaraan ik heb gewerkt en met teams waarmee ik heb gewerkt, maakten we doorgaans wekelijks statusrapporten. We zorgden er ook voor dat ze altijd met de klant werden gedeeld. Zo kon de klant beslissingen nemen op basis van een transparant beeld van de stand van het project. Het is dus een heel essentieel en eenvoudig hulpmiddel voor de projectmanager om ook …

Eigenlijk ook een vorm van zelfcontrole: aan het begin van de week een statusrapport opstellen, controleren hoe de kengetallen ervoor staan, hoe het budget verloopt en waar we ons in de planning bevinden. En dat op hoofdlijnen samenbrengen. Het bijvoorbeeld met de klant doornemen en terugkerende vergaderingen plannen die vaak niet langer dan een half uur hoeven te duren. Ze fungeren als regelmatige check-in en helpen een relatie met de klant op te bouwen. Dat hoeft niet alleen op afstand; het kan ook persoonlijk. Het is eigenlijk altijd goed om dit soort dingen persoonlijk te doen om een relatie met de klant op te bouwen. Zo creëer je een niveau van vertrouwen en transparantie, waardoor kansen maar ook problemen en blokkades in die regelmatige vergaderingen worden besproken.

Ben Aston:

Je maakt dus de documentatie en probeert vervolgens deze regelmatige check-ins met de klant te houden. Tijdens deze statusvergaderingen maken we de statusrapporten. Maar wat deel je nog meer? Het is één ding om intern te proberen de projecten zelf te beheersen, maar het is iets anders om die gegevens met de klant te delen. Wat zijn voor jou, naast statusrapporten, de andere basisdocumenten voor het beheren en beheersen van projecten met de klant?

Maik Stettner:

Een essentieel hulpmiddel om de algehele controle over een project te behouden, is een wijzigingsverzoek, of eigenlijk het wijzigingsverzoekproces met onze formulieren voor wijzigingsverzoeken. Telkens wanneer de vastgestelde scope verandert en je bijvoorbeeld extra inspanning moet leveren, of het projectteam moet bijsturen om aan de tijdsverwachtingen te voldoen, moet dat worden gedocumenteerd. Vaak is een wijzigingsverzoek in projecten een verboden term en ben je een beetje bang om hem te gebruiken omdat je vreest dat de klant boos wordt. Maar het is eigenlijk heel normaal.

Wijzigingsverzoeken hoeven niet per se gevolgen te hebben. Alleen al om het vast te leggen kan het nuttig zijn; het kan nog steeds binnen budget vallen en geen gevolgen voor de planning hebben. Toch is het zeker een goed idee om het te documenteren en de klant eraan te laten wennen dat er zoiets bestaat als een wijzigingsverzoekproces. Want als er ergens in het project een besluit wordt genomen dat gevolgen heeft voor het budget, is het goed om dat grondig te doen, te documenteren en iedereen een wijzigingsverzoek als dit te laten goedkeuren.

Ben Aston:

Een ander document waar je over praat, en dat volgens mij ook een vorm van projectbeheersing is, is het RAID-logboek. Dat is opnieuw een belangrijk aspect van projectbeheersing. Maar als je echt maar één document zou mogen kiezen om projecten te beheersen, welk document zou je dan gebruiken?

Maik Stettner:

Nummer één is een goed, degelijk statusrapport. Een RAID-logboek gaat meer in detail en afhankelijk van de complexiteit van je project heb je het misschien niet in die mate nodig. Maar een statusrapport hoort elementen hiervan vast te leggen. Als je risico's, blokkades of bepaalde andere zaken hebt, zorg er dan voor dat je daar ruimte voor hebt in je statusrapport, zodat iedereen er zicht op houdt. Maar regelmatige vergaderingen met de klant, de belangrijkste KPI's en kengetallen aan de klant tonen en hen vervolgens door het huidige proces en de voortgang leiden: dat is voor mij de belangrijkste graadmeter.

Ben Aston:

Het is dus een kwestie van balans, toch? Hoeveel controle geven we onszelf eigenlijk en hoeveel controle kunnen we creëren door deze documentatie op te stellen? Het komt tot op zekere hoogte terug bij het agile-debat, of bij de manier waarop sommige mensen dit ervaren. We willen ons niet vastzetten in documentatie rond vereisten of beheersing, want dat kan het project beperken. Maar hoe vind je de balans tussen al je tijd besteden aan het controleren van het budget, elke week je statusrapport bijwerken en vergaderingen houden? Je creëert zo veel werk voor jezelf. Hoe bepaal je hoeveel te veel is en hoeveel precies genoeg is om het project onder controle te houden en de klant op de hoogte te houden?

Maik Stettner:

Vanuit mijn perspectief probeer ik een nieuw project tamelijk zelfzuchtig te benaderen, in die zin dat ik begin met een projectstatusupdate, of hoe je het ook wilt noemen, die redelijk eenvoudig door mij te produceren is. Ik kan die waarschijnlijk samenstellen met bestaande software die ik heb, bijvoorbeeld resourceplanningssoftware zoals Resource Guru, tijdregistratiesoftware of wat het bedrijf ook gebruikt. Daarmee kan ik de basiskengetallen verzamelen. Afhankelijk van het project is dat misschien al genoeg om te beginnen. Sommige klanten hebben misschien iets meer nodig en verwachten een gedetailleerder beeld. Maar om als PM een overzicht te houden van de interne kengetallen en ook iets aan de klant te kunnen presenteren, is dit al een heel goed startpunt. Het kost echt niet zoveel tijd om dit regelmatig samen te brengen.

Uiteindelijk wil je niet te veel werk voor jezelf creëren, want dan is de kans groot dat je het gewoon niet gaat doen en dat het tussen de mazen door glipt wanneer het druk wordt of wanneer het project al je aandacht nodig heeft. De algemene rapportage enzovoort staat dan niet meer centraal.

Ben Aston:

Dat is een heel goed punt: doe precies genoeg om het project te beheersen. En wat volgens mij misschien nog belangrijker is, is de regelmaat waarmee we het doen. Het is mooi om aan het begin van het project het ultieme statusrapport te hebben en geweldige projectbeheersing op te zetten. Het maken van die sjablonen en bepalen hoe je de gegevens gaat vastleggen is de eerste stap, maar als het vervolgens uren duurt om alle gegevens te verzamelen om alle verschillende velden in je documentset voor projectbeheersing in te vullen, werkt dat tegen je. Het duurt dan te lang om het te produceren, je doet het niet en houdt je projecten niet goed bij.

Maik Stettner:

Precies. Je moet ook onthouden dat het twee kanten op werkt. Aan de ene kant moet jij als PM weten wat er gebeurt om gefundeerde beslissingen te nemen. De klant wil weten wat er gebeurt, maar ook het interne team verdient die informatie. Een van de beslissingen die je als PM moet nemen, is hoe je dat doet. Ik denk niet dat ik mijn team ooit door een droog statusrapport heb geleid. Ik heb altijd andere manieren gevonden om budgetbeperkingen, planningen enzovoort aan het team te laten zien. Maar het is belangrijk genoeg kennis en kengetallen te hebben om iedereen geïnformeerd te houden, zodat iedereen aan hetzelfde project werkt.

Ben Aston:

Dat is een geweldig punt. Dit is niet alleen voor onze klanten, maar ook voor onze teams. Zo weten onze teams ook wat de beperkingen van de projecten zijn. Als het project onder hoge druk staat en we als team moeten samenwerken om een efficiëntere manier van werken te vinden, is die informatie opnieuw nuttig — niet alleen voor de klant, maar ook voor het team. Je kunt dan zeggen: “Hé mensen, we zullen hier wat moeten bijsturen. Misschien kunnen we niet zoveel afronden als we hadden gehoopt. Dus kom op, laten we samenwerken en ons aanpassen.”

En ik denk dat het hebben van die gegevens, waar je het hier over hebt, niet betekent dat je lastig doet of dat je je als projectmanager aanstelt. Het betekent dat je zegt: “Kijk mensen, dit is het statusrapport en het laat zien dat we veel te snel budget verbruiken. We hebben opnieuw te veel tijd aan UX besteed. We hebben opnieuw te veel tijd aan ontwerp besteed. We hebben niet genoeg budget om dit goed te testen als we dit niet afronden.” Dat is heel concreet.

Je hebt in je artikel ook gesproken over het proces om projectbeheersing op te zetten en vervolgens te gebruiken om projecten te beheren. Je had het over evalueren, plannen, reageren en verbinden. Kun je ons door dat proces leiden en uitleggen hoe je dat laat werken?

Maik Stettner:

Zeker. Als PM moet je altijd weten waar de zaken staan om gefundeerde beslissingen te kunnen nemen. Deze stappen zijn daar min of meer op gebaseerd. Je begint dus met evalueren. Je wilt weten waar je project staat en waar het zich bevindt in het projectplan. Lig je op koers om de verwachte output te behalen? Ga je je doel bereiken? Niet alleen vanuit KPI-perspectief: als PM moet je onder de motorkap kijken, vragen stellen en begrijpen wat je team doet. Je moet op hoofdlijnen expert worden in alle verschillende disciplines waarmee je werkt, zoals UX, ontwerp, ontwikkeling en QA. Zo kun je beoordelen of je in bepaalde onderdelen van een project misschien wat hoeken kunt afsnijden, of juist niet. Dat ontdek je alleen als je er echt induikt, met mensen praat en op een gedetailleerder en granularer niveau begrijpt wat je moet doen. Vervolgens neem je op basis daarvan beslissingen.

Dat brengt ons bij de tweede stap: plannen. Zoals we weten, moeten we vaak verschillende zaken op elkaar afstemmen en veranderen er dingen, zoals de timing, scope enzovoort. Je plant dat uit en bepaalt de volgende stappen met het team op basis van de kennis die je hebt. Als PM krijg je beide kanten mee: de klantkant en de interne kennis van het team. Vervolgens maak je in feite dat masterplan om het project naar de eindstreep te brengen.

Op basis daarvan is de volgende stap reageren. Voer je wijzigingen uit op basis van het plan. Dat betekent bijvoorbeeld dat je de klant informeert, ervoor zorgt dat het proces wordt aangepast als dat nodig is, en de documentatie en systemen voor het volgen van problemen, zoals Jira, bijwerkt. Je werkt planningen bij en zorgt ervoor dat alle aanpassingen zijn doorgevoerd.

De laatste stap die ik had uitgewerkt, was verbinden. Als PM ben je de lijm die het team bij elkaar houdt. Idealiter moet iedereen op hoofdlijnen weten wat jij weet. Zorg er dus voor dat je je kennis met het team deelt, zodat iedereen het volledige plaatje heeft. De klant moet op de hoogte zijn en het team moet op de hoogte zijn. Beheer die wijzigingen vervolgens zodanig dat je ze ook daadwerkelijk kunt opleveren.

Ben Aston:

Wat ik hoor, is dat dit eigenlijk uit twee verschillende onderdelen bestaat. Vanuit projectmanagementperspectief is de informatie die je noemt echt belangrijk. Die gegevenspunten geven ons de mogelijkheid om te beoordelen waar de projecten staan. En ze geven ons op zeer korte termijn, op hoofdlijnen, de mogelijkheid om projecten te beheersen: hoe prioriteren we resources? Hoe prioriteren we projecten om ze op te leveren? De gegevens geven ons dat overzicht op hoofdlijnen.

Maar ik vind het goed wat je zegt over de andere aspecten van projectbeheersing. Dit gaat niet alleen over gegevens verzamelen. Het gaat over het starten van een gesprek, onze teams bij die discussie betrekken en samen nadenken over het beheersen van het project, over de beste manier om zaken op te leveren, en over een meer agile aanpak waarbij we onze projecten gaandeweg aanpassen en intuïtief blijven werken. In plaats van alles vast te zetten, onze statusrapporten te draaien, te ontdekken dat we boven budget zitten en het daarbij te laten. Ik vind het goed dat je dit als een gesprek benadert.

Maar voor mensen die er nooit over hebben nagedacht om goede statusrapporten voor hun klanten of projecten te maken: je hebt dat proces zojuist doorlopen. Wat is voor jou de eerste stap om je projecten onder controle te krijgen? Wat is het eerste waar mensen aan moeten denken, zelfs als ze nog geen statusrapport of een van deze beheersingsinstrumenten maken, wanneer ze nadenken over het goed organiseren van de oplevering en het beheersen van projecten? Is er een goed startpunt dat je zou aanraden?

Maik Stettner:

Voor mij draait het er echt om een goed beeld te krijgen van wat je moet doen om dit op te leveren. Zowel vanuit het perspectief van de klant als intern. Een deel hiervan kan heel eenvoudige logistiek zijn. Wat verwacht de klant? Zijn er drijfveren? Is er misschien een vaste datum waarop je klaar moet zijn, omdat er een campagne loopt of omdat er een directiepresentatie is waarvoor je contactpersoon het tegen die tijd nodig heeft? En intern moet je een heel duidelijk beeld krijgen van het team dat je nodig hebt en hoe het gaat werken. Begrijp op zijn minst op hoofdlijnen hoe al die zaken bij elkaar komen. Met ervaring helpt dat je als projectmanager om op hoofdlijnen in te schatten wat het plan zal zijn en welke globale controlepunten je in het proces nodig hebt.

Uiteindelijk helpt een statusrapport je vooral om jezelf op koers te houden en die controlepunten niet te vergeten. Dat is volgens mij de kern. Het is een combinatie van KPI's, zachte vaardigheden en over het algemeen een nuchter overzicht van het project behouden, zodat je precies blijft begrijpen waar je staat, ook wanneer het project ingewikkelder is. Vervolgens neem je ook voor jezelf gefundeerde beslissingen om de tools te vinden die je daarbij helpen.

Ben Aston:

Ik vind goed wat je daar zegt. Gegevens betekenen eigenlijk niets tenzij we ze ergens tegen kunnen afzetten. Het is mooi om statusrapporten te verzamelen, maar als we geen projectplan hebben om ze mee te vergelijken, zijn die gegevens min of meer betekenisloos. Zorg er dus voor dat je een goed plan hebt; daarna kun je ertegen meten. Wat ik heb gemerkt toen ik met PM's van andere bureaus sprak, is dat iets wat vaak ontbreekt urenregistratie is. Het precies bijhouden van hoeveel tijd aan verschillende taken voor een project wordt besteed. Hoewel tijdregistratie een van de pijnlijkste dingen is die je iemand kunt vragen, is het invoeren ervan — als je nog geen tijdregistratie gebruikt — samen met het opstellen van een projectplan een manier om je tijd tegen het project af te zetten. Dat geeft je vervolgens een zekere mate van controle over het project. Dat is dus echt degelijk advies. Bedankt, Maik. Fijn dat je vandaag bij ons was.

Maik Stettner:

Graag gedaan, Ben.

Ben Aston:

Als een van onze DPM-experts zal Maik ook verschijnen in onze komende cursus, die in september begint. De cursus heet Mastering Digital Project Management. Dit is een intensieve cursus van zeven weken in digitaal projectmanagement. Je leert hoe je digitale, complexe projecten effectief beheert. De cursus bevat videolessen, opdrachten en groepsdiscussies, en er is een optie voor coachingsessies. Ga dus naar thedpmschool.com en schrijf je in. Er zijn nog enkele plaatsen beschikbaar. De cursus begint op 10 september. Maar als je wilt bijdragen aan dit gesprek over projectbeheersing — hoe kunnen we onze projecten beter beheersen? Welke documentatie gebruik jij? — ga dan naar de sectie met bronnen van thedigitalprojectmanager.com om je bij ons Slack-team aan te sluiten. Daar vind je allerlei interessante gesprekken. Reageer op het bericht, praat erover op Slack en laten we samen uitzoeken hoe we onze projecten beter kunnen beheersen.

Maar tot de volgende keer: bedankt voor het luisteren.