Red je project met een projectinitiatie-document (met Maik Stettner van FCV Interactive)

Lees het transcript:

We proberen onze podcasts uit te schrijven met behulp van een softwareprogramma. Vergeef ons eventuele typefouten; de bot heeft niet altijd 100% gelijk.

Ben Aston:

Bedankt voor het luisteren. Ik ben Ben Aston en dit is de podcast van The Digital Project Manager. Deze podcast wordt mogelijk gemaakt door Clarizen, de leider op het gebied van software voor enterprise-, project- en portfoliomanagement. Bezoek clarizen.com voor meer informatie.

Als er één ding is dat je over een project kunt garanderen, dan is het dat het nooit volgens plan zal verlopen. Maar waarom ontsporen projecten? Soms komt dat simpelweg doordat we te snel aan projecten beginnen. We zien de deadline steeds dichterbij komen en beginnen vervolgens in een soort blinde paniek aan het project. Wanneer dingen daarna misgaan, vragen we ons af waarom.

Hoewel we meestal alle projectachtergrond, de strategie, de details, de vereisten en de succesmetrics ergens achter in ons hoofd hebben opgeslagen, maken we vaak de fout om te denken dat iedereen die informatie ook kent. De realiteit is echter dat ons team het waarschijnlijk niet weet als het niet is vastgelegd.

Daarom bespreken we vandaag een hulpmiddel waarmee we ervoor kunnen zorgen dat iedereen aan het begin van het project op één lijn zit. Het is het projectinitiatie-document, of wat in onze wereld misschien vaker de projectbrief wordt genoemd. We geven je vandaag inzicht in hoe je een PID kunt maken en gebruiken om je projecten effectiever te maken.

Vandaag praat ik met Maik Stettner, een van mijn vrienden en collega's. Maik is een van onze vaste DPM-experts bij The Digital Project Manager. Welkom, Maik.

Maik Stettner:

Hallo. Hoe gaat het?

Ben Aston:

Goed. Fijn dat je er bent. Maik, laten we eerst over jou praten en iedereen iets over je achtergrond vertellen. We werken natuurlijk samen en doen dat inmiddels, is het vijf jaar?

Maik Stettner:

Ja, inmiddels ergens tussen de vier en vijf jaar.

Ben Aston:

Toen ik Maik aannam, dacht ik nog: “Ik weet niet of deze man dit wel kan.” Je kwam namelijk uit een iets andere achtergrond, niet uit de traditionele bureauwereld. Vertel eens over je verhaal. Hoe ben je projectmanager bij een digitaal bureau geworden?

Maik Stettner:

Alles bij elkaar heb ik ongeveer tien jaar ervaring in verschillende gebieden. Ik ben oorspronkelijk begonnen in gaming en publishing, waar ik releases van games in Europa en Noord-Amerika beheerde. Daarna ben ik andere gebieden ingegaan, zoals medische databases, maar over het algemeen bleef ik werken aan softwareontwikkeling en zaken die met projectmanagement te maken hebben, met verschillende teams enzovoort. In mijn loopbaan heb ik ook ervaring opgedaan bij bureaus met appontwikkeling en enige webontwikkeling. Toen we voor het eerst over samenwerken spraken, maakte ik eigenlijk de overstap naar volledige webontwikkeling en de bureauwereld.

Ben Aston:

Ja.

Maik Stettner:

Ik werk nu ongeveer vier jaar bij mijn huidige bedrijf, FCV. Ik leid daar het projectmanagementteam en ben in feite verantwoordelijk voor de volledige oplevering van projecten en voor het zorgen dat klanten tevreden zijn met de resultaten die we leveren.

Ben Aston:

Goed bezig. Voor de mensen die luisteren en misschien in een vergelijkbare situatie zitten: we krijgen vaak mensen die zeggen: “Ik ben projectmanager en heb ervaring met het beheren van software, maar ik overweeg de overstap naar een bureau en een digitale projectmanager te worden.” Hoe was die overgang voor jou? Wat waren de belangrijkste verschillen tussen de softwarewereld en de wereld van digitaal projectmanagement bij een bureau, bijvoorbeeld in de manier waarop je mensen of projecten moest aansturen?

Maik Stettner:

Allereerst zijn er veel overeenkomsten. Zaken die je tegenkomt bij andere softwareontwikkelingsbureaus of in andere projectmanagementgerelateerde gebieden, kom je ook bij een bureau tegen. Je hebt diverse teams, projecten ontsporen om allerlei redenen en je kunt dezelfde tactieken gebruiken om dat op te vangen.

Een van de belangrijkste verschillen voor mij was het begrijpen en toepassen van het idee van sterk gericht zijn op tijd en materiaal en op kleinere werkstappen in plaats van grotere opleveringen. Klanten willen, vooral in het werkveld waarin ik actief ben, meer transparantie en controle over kleinere stukken werk. Dat vraagt om uitgebreidere rapportage en meer inspanning om transparant te zijn en precies uit te leggen wat je doet om dat vertrouwen op te bouwen. Dat vergde wat aanpassing ten opzichte van werken bij een productbedrijf, waar je misschien naar een interne lancering toewerkt.

Dat was voor mij het grootste verschil. Tegelijkertijd was het interessant om te zien dat het eigenlijk niet uitmaakt of je aan een databaseproject, een game of een website werkt: je loopt tegen vergelijkbare problemen aan die van het ene gebied naar het andere kunnen worden overgezet. Als je de lessen uit je vorige baan toepast, zoals goede communicatie en de standaard best practices van een projectmanager, is de kans groot dat je succesvol bent, ongeacht wat je bouwt.

Ben Aston:

Vertel ons dan eens over je huidige rol. Je beheert niet alleen projecten, maar ook teams, waaronder het projectmanagementteam. Wat zijn binnen dat projectportfoliomanagement, waarbij je een hele reeks projecten met concurrerende resourcevereisten beheert, de typische uitdagingen in je rol als hoofd van het PMO-team?

Maik Stettner:

Mijn rol is inmiddels wat breder. Ik zorg er in feite voor dat alles blijft bewegen. Een van mijn belangrijkste aandachtspunten is resourceplanning: zorgen dat we de juiste mensen voor de juiste opdracht en de juiste periode hebben.

Vaak moet je compromissen sluiten wanneer zaken langer duren terwijl er al een ander project gepland staat. Dan moet je die aanpassingen beperken en ervoor zorgen dat klanten rechtstreeks contact met mij kunnen opnemen. Het risico van een bredere, meer strategische rol is namelijk dat je de enige andere persoon bent die verantwoordelijk is voor escalaties. Dat is geen rol waarin je uitsluitend wilt zitten, want dan krijg je alleen telefoontjes wanneer mensen boos zijn.

Het is goed om actief betrokken te blijven bij verschillende projecten om een vertrouwensrelatie op te bouwen en er tegelijk voor te zorgen dat de organisatie goed is ingericht. Dat geldt voor resourceplanning, operations en samenwerking in het algemeen, want we hebben meerdere kantoren.

Voor ons is het belangrijk dat mensen uit ons kantoor in Toronto goed kunnen samenwerken met ons kantoor in Victoria. Dat is het grootste deel van mijn focus. Tegelijkertijd heb ik nog steeds enkele klanten met wie ik nauw samenwerk en doe ik behoorlijk wat projectmanagement, omdat daar nog altijd mijn passie ligt. Ik werk gewoon graag voor mensen en ga dat niet opgeven.

Ben Aston:

Laten we teruggaan naar de uitdaging van resourceplanning. Iedereen die een projectmanagementteam leidt of resourcemanager is, krijgt hiermee te maken. Stel dat je twee projectmanagers hebt die allebei vrijdag een deadline hebben en dezelfde resources nodig hebben. Wat is dan je triageproces? Wat is je aanpak voor projectportfoliomanagement om te bepalen wie voorrang krijgt?

Maik Stettner:

Eerst kijk ik meestal naar de prioriteit van het project. Hebben we een deadline? Hebben we iets aan de klant beloofd? Moet het op een bepaalde datum live? Ik kijk dus of er speelruimte is in de planning.

Ook speelt mee of iets bijvoorbeeld contractueel is vastgelegd. We moeten ervoor zorgen dat alles wordt gedaan. Wil het project alleen maar vooruit en de klant een plezier doen? Dat is prima als we tijd hebben, maar als het andere project over drie dagen live gaat, kunnen we daar waarschijnlijk niemand weghalen.

Dat is de basis. Idealiter gebeurt dit niet, omdat de projectmanager bepaalde uitloop zou moeten voorzien en buffers zou moeten inbouwen. Misschien klinkt dit vreemd, maar ik verwacht ook dat mijn team voor de benodigde resources vecht.

Vaak zijn mensen te aardig en zeggen ze: “Je mag deze persoon wel een dag hebben.” Uiteindelijk wordt dan ieders werk uitgesteld. Ik houd er niet van om resources zomaar af te pakken, maar tijdens resourcevergaderingen verwacht ik wel dat iemand opkomt voor de tijd die nodig is en het probleem bij de resourcemanager neerlegt, zodat die hulp kan regelen of kan bepalen hoe het evenwicht wordt hersteld.

Ben Aston:

Misschien is het een Canadees resourceprobleem.

Maik Stettner:

Zeker een Canadese patstelling.

Ben Aston:

Canadezen zijn te aardig, en als Europeanen mogen wij dat volgens mij zeggen. Of mogen alleen Canadezen grappen maken over die idioten?

Maik Stettner:

Precies. In Europa kijk ik daar zeker anders tegenaan.

Ben Aston:

Ik ben altijd geïnteresseerd in tools. Heb je onlangs een hulpmiddel ontdekt of zijn jullie iets gaan gebruiken waarvan je dacht: “Dit is geweldig. Waarom zijn we hier niet eerder mee begonnen?” Wat zit er in jouw toolkit dat volgens jou goed werkt?

Maik Stettner:

Bedoel je specifiek voor resourceplanning?

Ben Aston:

Resourceplanning of projectmanagementtools in het algemeen.

Maik Stettner:

We gebruiken eigenlijk een vrij standaardpakket voor tijdregistratie en Microsoft Project. Dat is voor klanten vaak overweldigend. We experimenteren nu veel met cloudproducten. Project heeft bijvoorbeeld een Office 365-versie. We kijken ook naar software voor tijd- en resourcebeheer. Ik heb nog geen perfecte oplossing gevonden, omdat ons proces behoorlijk aangepast is en helaas deels handmatig verloopt.

Persoonlijk denk ik dat de ideale tool voor wat wij nodig hebben niet bestaat. Mijn doel zou zijn om iets te bouwen of aan te schaffen en het vervolgens aan te passen aan de individuele behoeften.

Ben Aston:

Wat ontbreekt er volgens jou in bestaande tools om ze bruikbaar te maken? Of is het proces zo ingewikkeld dat de tools het nog niet aankunnen?

Maik Stettner:

Niet per se. Het is eigenlijk vrij eenvoudig. Ik zoek vooral een tool die eenvoudige tijdregistratie en het boeken van uren, of urenstaten van mensen, koppelt aan resourceplanning. Iets zoals Resource Guru of andere tools waarmee je kunt vastleggen wat je nodig hebt, maar die vervolgens ook aansluiten op het financiële aspect. Bij werken op basis van tijd en materiaal is de eenvoudige berekening het aantal uren maal het factureringstarief. Daarna wil je de volledige rapportageketen daarop baseren.

Het klinkt eenvoudig, maar er zijn veel zaken om rekening mee te houden, zoals de waarschijnlijkheid dat projecten verschuiven en hoe systemen daarmee omgaan. Dat kan rapportages verstoren en zoveel extra handmatig werk veroorzaken dat de statistieken niet meer kloppen. Ik heb de perfecte oplossing nog niet gevonden.

Ben Aston:

Laten we praten over het artikel dat je schreef over projectinitiatie-documenten, of PID's. Zoals ik in de introductie zei: projecten gaan mis en vaak komt dat doordat we ze niet goed starten. We nemen aan wat het team weet, of geven het een heleboel documenten met de boodschap: “Ga naar de gedeelde schijf en lees ze. Alles staat erin.” We denken dat iedereen zich wel inleest en op snelheid komt, en zijn verbaasd als het project spectaculair mislukt. Maar vaak komt dat doordat mensen het project niet begrijpen.

Hoe kunnen we dit beter doen? Hoe schrijven we betere projectbriefings of maken we, in projectmanagementtaal, een projectinitiatie-document? Kun je wat achtergrond geven over jouw proces voor het starten van projecten en uitleggen waar het projectinitiatie-document of de projectbrief daarin past? Wanneer maak je het en hoe kom je tot dat document?

Maik Stettner:

Stel dat je een nieuwe klant hebt. Je bent enthousiast omdat het algemene contract is ondertekend, waarschijnlijk een master service agreement op hoofdlijnen waarin staat dat jouw bedrijf en het andere bedrijf gaan samenwerken. De volgende stap is voor mij altijd bepalen hoe we dat vertalen naar concrete stappen en voorwaarden.

Meestal denk je dan aan een werkbeschrijving. Het probleem is dat alles in zo'n vroeg stadium nog heel globaal is en slechts een benadering vormt van wat je uiteindelijk gaat doen. Het projectinitiatie-document en kick-offmeetings zijn goede hulpmiddelen om de klant beter te leren kennen en te ontdekken of er andere factoren of drijfveren zijn waarmee in de eerste werkbeschrijving geen rekening is gehouden.

Nadat de eerste werkbeschrijving is opgesteld, eventueel nog als concept, beslist het team binnen ons bureau wat we gaan doen. We houden een interne kick-off om iedereen mee te nemen en daarna een externe kick-off met de klant. Daarin leggen we op hoofdlijnen uit wat we gaan doen, wie het team is, hoe we samenwerken en wat de huidige scope is.

Het projectinitiatie-document of de projectbrief is voor mij de volgende stap om dat concreter te maken. In dit vroege stadium moet je het wel als een levend document behandelen, omdat nog niet volledig duidelijk is hoe alles precies zal verlopen. Het is een uitstekend hulpmiddel om zakelijke context te geven en ervoor te zorgen dat de basisparameters van het project duidelijk zijn voor zowel de klant als het interne team.

Ben Aston:

Je begint dus met een werkbeschrijving of een juridische overeenkomst tussen jou en de klant. Dat vormt de basis, en de projectbrief komt daarbovenop of werkt ermee samen om een aantal zaken duidelijker te definiëren.

In je artikel beschrijf je wat erin moet staan: context, specifieke projectparameters, een projectstructuur, wie wie is binnen het project en risicomanagement. Laten we met de context beginnen. Hoe geef je context zonder mensen te verwarren of met informatie te overladen? Hoe bepaal je wat ruis is en wat nuttig is?

Maik Stettner:

Het gaat vooral om de vraag waarom de klant het project uitvoert en welke problemen op hoofdlijnen moeten worden opgelost. Zijn er zakelijke drijfveren? Willen ze hun verkoop verhogen, een publiek informeren of een merk vernieuwen? De belangrijkste vraag is: hoe definiëren we succes? Hoe weten we aan het einde, op dit nog vrij hoge niveau, of we zijn geslaagd?

Dat kan zo eenvoudig zijn als betere verkoopgesprekken. Of bijvoorbeeld een zelfbedieningswebsite die content uit een contentmanagementsysteem haalt. Het is belangrijk om het kader te schetsen, zodat het team weet waar het naartoe werkt. Ook als de stappen nog niet volledig zijn uitgewerkt, helpt dit om de activiteit als geheel vorm te geven.

Als je bijvoorbeeld aan een rebrandingproject werkt met als doel een bedrijf opnieuw te positioneren, kan iemand aan het einde vragen: “Waarom zijn mijn verkopen niet gestegen?” Dan kun je teruggaan naar de oorspronkelijke context en uitleggen dat dit niet het doel van het project was. Misschien heeft het project er indirect een positieve invloed op, maar het was geen focus.

Het is goed om vast te leggen wat aanvankelijk is besproken en de klant op één lijn te brengen over het algemene doel.

Ben Aston:

Dat helpt. Context is vooral belangrijk wanneer je iets nieuws creëert. Bij onderhoudswerk hoef je misschien niet de volledige strategie te kennen, maar als je iets nieuws maakt, zijn het waarom van de klant, het probleem dat je probeert op te lossen, de bedrijfsdoelen en het beeld van succes essentieel. Die achtergrond helpt het team de oplossing vorm te geven. Laten we het hebben over projectparameters. Welke grenzen probeer je binnen de projectbrief vast te leggen?

Maik Stettner:

Je wilt experts niet beperken. Maar als je ze volledige vrijheid geeft, werken ze misschien aan een heel ander project dan jij voor ogen had. Daarom is het belangrijk om het kader en de basisbeperkingen te geven, bijvoorbeeld budget, tijdlijn en het algemene schema. Idealiter heb je dit samen met een deel van het team geschat, zodat het niets nieuws voor hen is.

Het is waardevol om dit samen te bespreken. Het is geen beperking, maar wat is afgesproken: dit leveren jullie voor een bepaald budget aan de klant. Als iemand meer tijd nodig heeft, moet het team bepalen hoe het toch kan werken. Voer die discussie op hoofdlijnen en wek niet de indruk dat je het leven van het team moeilijk maakt. Help hen juist om hun werk te doen en zorg dat ze weten dat je hen steunt bij mogelijke budgetverhogingen, risico's en wijzigingen in de planning.

Het team moet net als de klant vertrouwen hebben in de oplevering en enthousiast zijn om aan het project te beginnen.

Ben Aston:

Je noemt ook een projectstructuur, een work breakdown structure en een resourceplan. Hoe maak je aan het begin van een project, wanneer nog veel onduidelijk is, een eerste plan? Hoe kom je tot een ruwe planning voordat het project is gestart?

Maik Stettner:

Eerlijk gezegd is het op dat moment waarschijnlijk een best mogelijke inschatting. Je baseert je op de werkbeschrijving, bestaande informatie of de raming die het team heeft opgesteld. Er staan nog veel zaken open: reageert de klant snel, hoeveel revisierondes zijn nodig en zijn die voldoende gedefinieerd? Het plan dat je maakt, kan dus anders uitpakken.

Maar juist daarom helpt zelfs een benadering van het plan het bureau en andere projectteams om de juiste resources te reserveren en het team stabiel te houden. Een ambitieus eerste plan waarvoor je nog goedkeuring van de klant nodig hebt, kan na de eerste of tweede meeting worden bijgesteld. Het helpt je om zaken vanuit jouw perspectief in kaart te brengen en de complexiteit van de oplevering te begrijpen.

Heb je bijvoorbeeld een ontwerper nodig aan wie je nog niet had gedacht? Als je het team daar vroeg over laat praten, begrijp je als projectmanager beter wat nodig is om het project te leveren. Daardoor kun je de juiste vragen stellen en de klant goed begeleiden. Zelfs een ruwe planning is beter dan geen planning, omdat mensen erover praten en het plan naarmate de tijd vordert gedetailleerder en realistischer wordt.

Ben Aston:

Een plan hebben is dus beter dan helemaal geen plan, omdat je het altijd kunt ontwikkelen. Wanneer je met een team aan een projectbrief begint zonder plan, zijn afhankelijkheden en de rol van de klant niet doordacht. Dan begin je met weinig vaart. Als je met een plan komt, kunnen mensen daarop reageren en zeggen: “Maik, je bent gek. Hoe gaan we dat ooit doen?” Dat geeft in elk geval een startpunt voor discussie in plaats van een leeg vel papier. Zelfs een verkeerd plan is beter dan geen plan.

We hebben het projectbrief of projectinitiatie-document besproken. Dat klinkt als een heel formeel document, maar het hoeft geen groot officieel document te zijn. In essentie geef je context, parameters en een plan. Welke vormen kan een projectbrief aannemen en hoe zie je de rol ervan tijdens de levenscyclus van het project veranderen?

Maik Stettner:

De handleiding die ik heb samengesteld is een voorbeeld van wat je kunt opnemen. Er is zeker een minimum aan informatie dat in een projectinitiatie-document of projectbrief moet staan, maar er zijn ook andere manieren. Je kunt bijvoorbeeld risicomanagement in een apart document onderbrengen, of een RACI-matrix koppelen aan statusrapportages.

Het hoeft niet altijd uiterst formeel te zijn. Belangrijk is dat iedereen het ermee eens is. Of het nu op SharePoint of BaseCamp staat en vervolgens wordt aangepast, zolang er maar gesprekken over plaatsvinden. Als later blijkt dat bij het bepalen van de scope het verkoopaspect is vergeten, moet je dat vastleggen. Uiteraard heeft dat gevolgen voor de scope.

Zolang het maar een document is, desnoods een formele e-mail, waarin zaken schriftelijk zijn vastgelegd en waar mensen mee instemmen, is dat voldoende. Het hoeft niet door alle partijen ondertekend en afgestempeld te worden, maar iedereen moet het minimaal erkennen en ermee akkoord gaan, omdat het bepaalt wat wordt opgeleverd en waartegen wordt gewerkt.

Ben Aston:

Als je na het luisteren denkt: dit klinkt goed, maar waar beginnen we? Maik heeft een uitstekend sjabloon gemaakt dat je kunt gebruiken voor je projectbrief of projectinitiatie-document. Bekijk het artikel om het te downloaden. Maik, bedankt dat je dit vandaag wilde doen. Het was geweldig je erbij te hebben.

Maik Stettner:

Dank je wel dat ik erbij mocht zijn.

Ben Aston:

Graag gedaan. Als een van onze DPM-experts zal het je goed doen om te weten dat Maik binnenkort verschijnt in onze cursus Meesterschap in digitaal projectmanagement, die in september begint. Als je niet weet waar ik het over heb, maar wel projectmanagementtraining nodig hebt, neem dan een kijkje. Het is een intensieve cursus van zeven weken met interactieve videolessen, wekelijkse opdrachten, groepsdiscussies en de mogelijkheid om coachingssessies te volgen. Ga naar digitalprojectmanagerschool.com en schrijf je in voordat de cursus vol zit.

Wil je bijdragen aan het gesprek over projectinitiatie-documenten of projectbriefings? Ga dan naar de bronnensectie van digitalprojectmanager.com en word lid van ons Slack-team. Daar vind je allerlei interessante gesprekken. Vergeet ook niet om op het artikel te reageren en het te delen. Tot de volgende keer: bedankt voor het luisteren.