---

Bij Blue besteden we veel tijd aan het nadenken over projectmanagement. Het is cruciaal voor wat we doen en het succes van wat we aan onze klanten leveren. Zonder een solide begrip van projectmanagement, hoe kunnen we dan mogelijk projectmanagementsoftware bouwen?

Elke keer dat we aan een nieuw project beginnen, of dat nu een nieuwe functie, een upgrade van de backend-engineering, een marketingcampagne of een wervingsactie is, beginnen we met het analyseren van het project zelf en hoe het wordt uitgevoerd. Dus, met een grote hoeveelheid ervaring en inzichten, hebben we besloten om enkele eerste beginselen van projectmanagement te formaliseren.

Hoewel het gebruikelijk (en acceptabel) is om een project te navigeren met een meer informele, persoonlijke intuïtie, is het nauwelijks een schaalbare aanpak — en niet zonder zijn nadelen.

Een Project

Laten we beginnen met het definiëren van een project.

Een project is een tijdelijke inspanning met een gedefinieerde start en einde om een uniek product, dienst of resultaat te produceren. Dit is hoe de meeste mensen over projecten denken. Maar er zijn ook enkele andere, meer formele eigenschappen van projecten die belangrijk zijn om te overwegen:

• Een project heeft eindige middelen (tijd, geld, mensen);
• Een project wordt ondernomen om specifieke doelstellingen te bereiken;
• Een project heeft een gedefinieerde scope (dus er zijn duidelijk dingen die het niet zal doen);
• Een project is onderhevig aan onzekerheid en risico's.

Nu we een beter begrip hebben van wat een project is, kunnen we verder gaan met de eerste beginselen — de kernbouwstenen die een project nodig heeft om succesvol te zijn. Deze omvatten:

• Een projectmanager;
• Een doelstelling;
• Een lijst van dingen die gedaan moeten worden — dit wordt vaak een plan genoemd;
• Iemand die is toegewezen om elke taak uit te voeren;
• Tijdslijnen voor elke taak;
• Een communicatiestrategie met een regelmatige cadans van updates en vergaderingen, en een plan voor waar informatie zal worden opgeslagen.

We hebben ontdekt dat deze zaken doorgaans van toepassing zijn op alle projecten en, als ze goed worden uitgevoerd, 99% van alle problemen binnen projecten wegnemen.

Een Projectmanager

Het eerste dat een project nodig heeft, is iemand die verantwoordelijk is voor het succesvol afronden ervan. Dit lijkt misschien een voor de hand liggende uitspraak, maar het is de moeite waard om te benadrukken.

Deze persoon is de projectmanager. Zij zijn verantwoordelijk voor het waarborgen dat de doelstellingen van het project worden gehaald en dat het project op tijd, binnen budget en volgens de vereiste kwaliteitsnormen wordt afgerond. Vaak worden velen van ons de facto projectmanagers zonder dat ze een getrainde projectmanager zijn. Als jij dat bent, dan heb je geluk, we hebben daar een gids voor geschreven!

Het is de moeite waard om te overwegen wat een projectmanager wel en niet zou moeten doen. Immers, zij hebben veel verantwoordelijkheid, en ze moeten deze verantwoordelijkheid serieus nemen.

Vaak kan projectmanagement een aanzienlijk deel van het projectbudget in beslag nemen — doorgaans tussen de 2% en 10%, afhankelijk van hoe risicovol het project is. Hoe meer risico, hoe meer projectmanagement nodig is om ervoor te zorgen dat alles op koers blijft en het project niet faalt.

Omdat ze een manager zijn, moet de projectmanager zich richten op hoe doelen te bereiken via andere mensen. Ze moeten ervoor zorgen dat het projectteam effectief is en dat ze harmonieus samenwerken naar het gemeenschappelijke doel. De projectmanager is degene die ervoor moet zorgen dat iedereen zijn werk doet en dat ze het goed doen.

De projectmanager is ook verantwoordelijk voor de communicatie met de belanghebbenden van het project en hen op de hoogte houden van de voortgang.

Net zoals we bespraken in Prioritering voor Leiders, moeten projectmanagers zich voortdurend richten op het punt van beperking. Als het te veel tijd kost om goedkeuring van belanghebbenden te krijgen, moeten ze zich hypergericht richten op het verkrijgen van die toezegging. Ze moeten zichzelf voortdurend afvragen: “Wat houdt ons tegen om de projectdoelstellingen te voltooien, en hoe kan ik het probleem zo snel mogelijk oplossen?”

In sommige opzichten is projectmanagement synoniem met communicatie. Gedetailleerde ideeën opschrijven is een waardevolle vaardigheid voor een projectmanager, omdat het het aantal benodigde vergaderingen drastisch vermindert — teamleden kunnen zelf de benodigde informatie vinden.

Een Doelstelling

Een andere kernbouwsteen van een project is dat het project een duidelijke en meetbare doelstelling nodig heeft. Zodra het project is afgerond, zou het triviaal moeten zijn om naar de resultaten te kijken en te weten of het project zijn doelen heeft bereikt of niet.

De doelstellingen moeten worden gepubliceerd zodat elk teamlid er toegang toe heeft. Dit is belangrijk omdat het betekent dat besluitvorming kan worden gedistribueerd en gedecentraliseerd, aangezien elk teamlid naar zijn kleine deel van het werk kan kijken en dit kan koppelen aan de overkoepelende doelen van het project. Dan kunnen ze problemen aankaarten als er een misalignment is of hun aanpak in hun kleine deel van het project aanpassen om de grotere doelstellingen het beste te dienen.

De doelstellingen van een project moeten SMART zijn:

• Specifiek. Projecten hebben vaak hoge niveau doelstellingen die meer lijken op missie- of visieverklaringen. Een voorbeeld van een slechte doelstelling is “verbeter de klantenservice”. Dit is niet specifiek genoeg. Iets als “We streven ernaar om 90% van de klanten binnen 30 minuten te antwoorden tegen het einde van Q4” is veel specifieker.
• Meetbaar. Wanneer je specifieke doelen stelt, los je doorgaans tegelijkertijd het meetprobleem op, omdat het dan gemakkelijk is om te beoordelen of het doel is bereikt.
• Haalbaar. Doelstellingen maken alleen zin als ze haalbaar zijn. Maar dit is geen excuus om gemakkelijke doelstellingen te creëren. Een goede doelstelling moet een element van uitdaging hebben — uitdagend genoeg om te kunnen worden bereikt, maar niet onmogelijk of zeer onwaarschijnlijk.
• Relevant. Dit klinkt misschien zeer vanzelfsprekend, maar je zult verrast zijn hoe vaak dit gebeurt. De projectdoelstellingen moeten haalbaar zijn door het uitvoeren van het project. Je kunt geen doelstellingen stellen die niet kunnen worden gecontroleerd door het projectteam dat het specifieke werk van het project uitvoert. Bijvoorbeeld, teams die werken in de productieafdeling van een bedrijf kunnen de winkelervaring van klanten niet beïnvloeden.
• Tijdgebonden. Goede doelstellingen moeten een soort timing hebben. Dit kan moeilijk zijn, vooral bij moderne softwareprojecten waar het werk dat gedaan moet worden niet altijd duidelijk is, zodat tijdslijnen extreem moeilijk te schatten kunnen zijn. Soms kun je er ver naast zitten, en is het niemand's specifieke schuld. Dat gezegd hebbende, zorgt het hebben van tijdslijnen ervoor dat de algehele scope van het project binnen bepaalde grenzen blijft. Als je een maand hebt om een probleem op te lossen versus een jaar, zul je heel verschillende oplossingen bedenken.

De doelstellingen moeten aan alle teamleden herhaald worden tot ze er (figuurlijk) ziek van zijn: ze zouden (figuurlijk) ziek moeten zijn van de projectmanager die constant de doelstellingen bespreekt. Enkele real-time (of zo dicht mogelijk bij real-time) dashboards die de voortgang volgen, kunnen ook van onschatbare waarde zijn om ervoor te zorgen dat iedereen is afgestemd op de doelstellingen en weet hoe het project ervoor staat.

Een Lijst van Dingen die Gedaan Moeten Worden

We raden sterk aan om een plan “een lijst van dingen die gedaan moeten worden” te noemen, omdat dit het planningsproces ontrafelt.

Plannen zijn vaak gissingen, maar ze zijn nog steeds waardevol. Dit komt omdat het planningsproces zelf helpt om duidelijkheid te scheppen over wat we weten en wat we nog niet weten.

Faalt in plannen, plant om te falen.

De essentie van een plan is om een gedetailleerde lijst te krijgen van alle stappen om van het begin van het project naar de succesvolle afronding ervan te gaan. Sommige acties vereisen dat eerdere stappen zijn voltooid, en dus kun je eindigen met een reeks gekoppelde taken, vaak afhankelijkheden genoemd. Andere acties kunnen parallel worden uitgevoerd en blokkeren elkaar niet.

De projectmanager moet zich altijd richten op de belangrijkste acties die andere acties blokkeren, aangezien dit definieert wat bekend staat als het kritieke pad van het project. Dat wil zeggen, de minimale hoeveelheid tijd waarin het project kan worden voltooid als alle afhankelijkheden achter elkaar zijn opgesteld.

Werken aan het plan vanuit beide uiteinden van het project kan enorm helpen bij het opbouwen van een effectief plan. Dit betekent dat je vanaf het begin begint en naar het einde gaat, maar dan ook vanaf het einde begint en terugwerkt om te begrijpen wat nodig is om het project af te ronden en de doelstellingen te behalen.

Dit laatste deel van het omkeren van het planningsproces zal doorgaans gemiste taken aan het licht brengen.

Maar, het planningsproces is niet compleet totdat we begrijpen wie verantwoordelijk is voor elke taak en hoe lang elke taak zal duren om te voltooien.

Deze punten moeten gelijktijdig worden behandeld omdat ze zo nauw met elkaar verbonden zijn. Je kunt geen schattingen voor werk maken zonder de experts te betrekken die de specifics van die taken kennen, en zelfs dan moet je je middelen in de gaten houden. Een individu kan zelden effectief aan meerdere dingen tegelijk werken, dus je moet begrijpen of het projectplan waarschijnlijk knelpunten zal hebben. Dit is waar één persoon niet alle toegewezen taken kan voltooien omdat ze simpelweg niet genoeg tijd beschikbaar hebben.

Iemand Toegewezen om Elke Taak uit te Voeren

Elke taak in een project moet een specifieke persoon hebben die verantwoordelijk is voor het voltooien van die taak. Als je merkt dat je meerdere individuen aan dezelfde taak moet toewijzen, heb je vaak niet op een gedetailleerd genoeg niveau gewerkt om taken te onderscheiden.

Bijvoorbeeld, in veel industrieën zijn er ontwerp- en bouwfasen; dit kan in de productie, de bouw of zelfs software zijn. Je zou dit moeten opsplitsen zodat je de specifieke taken van de ontwerper en de specifieke taken van de bouwer kunt toewijzen. Je zult vaak een heen-en-weer zien tussen de twee disciplines, wat je kunt meenemen. Een voorbeeld kan er als volgt uitzien:

1. Ontwerpfase 1 door Ontwerpers
2. Haalbaarheidscontrole 1 door Bouwers
3. Ontwerpfase 2 door Ontwerpers
4. Haalbaarheidscontrole 2 door Bouwers
5. Beoordeling door Senior Belanghebbende
6. Finalisatie van het Ontwerp door Ontwerpers
7. Laatste Controles door Bouwers
8. Goedkeuring door Belanghebbenden

Dit toont een realistisch op-en-neer tussen de verschillende betrokken partijen, in plaats van een “Ontwerpfase” alleen toegewezen aan het ontwerpteam tot de voltooiing van de ontwerpfase.

Tijdslijnen voor Elke Taak

Dit kan het moeilijkste deel zijn van het creëren van een plan — hoe meten we hoe lang elke taak zal duren? Zoals eerder besproken, moeten tijdslijnen niet top-down maar bottom-up worden gedaan. Dit betekent dat elk item wordt geschat door de persoon die het werk gaat doen (of in ieder geval een kennisrijke collega) en dat al deze schattingen worden opgeteld en berekend in een algemene tijdlijn.

Dat gezegd hebbende, is het nuttig om een algemene hoge niveau tijdlijn te hebben voordat de gedetailleerde schattingen worden gemaakt, omdat het schatten van hoe lang iets zal duren en het beslissen over de specifieke aanpak om de taak op te lossen in wezen hetzelfde zijn.

Dus als een project genereuze hoge niveau tijdslijnen heeft, kunnen individuele experts dat in hun schattingen meenemen en proberen oplossingen voor de lange termijn te optimaliseren in plaats van hoeken af te snijden om ervoor te zorgen dat de tijdslijnen worden gehaald. Als het project een gehaaste tijdlijn heeft, weet elke expert dat ze mogelijk compromissen moeten sluiten.

Een ding dat vaak wordt vergeten tijdens het creëren van projectplannen, is dat belanghebbenden de voortgang moeten beoordelen en beslissingen moeten bevestigen die moeten worden meegenomen. De beste manier om dit te doen is om naar het vorige project te kijken dat dezelfde set belanghebbenden omvat en te begrijpen wat een typische doorlooptijd is voor hen om feedback te geven.

Een ander gevaar hier is dat als er maandelijkse stuurgroepvergaderingen zijn met belangrijke belanghebbenden, wat gebeurt er dan als een projectlevering niet op tijd kan worden ingediend voor een van die vergaderingen? Gaat het project op pauze tot volgende maand wanneer de belanghebbenden weer samenkomen, of zal dit tussendoor worden behandeld en goedgekeurd (of teruggestuurd met feedback) tussen de maandelijkse stuurgroepen?

Een Communicatiestrategie

Wanneer dit soort problemen zich voordoen, bevestigen ze dat de aanpak van communicatie binnen een project van het grootste belang is.

Meestal is het probleem niet dat er een slechte strategie is, maar dat er helemaal geen strategie is. Dus communicatiekanalen openen zich op een informele en ad-hoc manier, en “goed genoeg” wordt de standaard.

Het probleem hiermee is dat dingen niet altijd volgens plan verlopen. Mensen veranderen, kennis gaat verloren, en naarmate het project groter wordt en steeds meer mensen zich aansluiten, kan de communicatielast snel exploderen.

Dus, duidelijk, de tools zelf zijn niet zo belangrijk; het is gewoon een feit dat naarmate je voorbij een niet-triviaal aantal mensen (zeg, 10) schaalt, teamwork steeds moeilijker wordt.

Dat komt omdat teamcommunicatie niet lineair schaalt in verhouding tot het aantal mensen in het team.

Bijvoorbeeld, als je een team van 2 mensen hebt, is er één communicatiedraad (tussen de twee individuen). Gooi er een andere persoon bij; nu heb je drie communicatiedraden. Dus, terwijl de teamgrootte met 50% is toegenomen, zijn de communicatiedraden met 300% toegenomen.

Laten we zien hoe dit groeit:

• 2 teamleden = 1 communicatiedraad
• 3 teamleden = 3 communicatiedraden
• 5 teamleden = 10 communicatiedraden
• 8 teamleden = 28 communicatiedraden
• 10 teamleden = 45 communicatiedraden
• 15 teamleden = 105 communicatiedraden
• 20 teamleden = 190 communicatiedraden
• 30 teamleden = 435 communicatiedraden
• 50 teamleden = 1.225 communicatiedraden
• 100 teamleden = 4.950 communicatiedraden

Dit kan worden uitgedrukt met de volgende vergelijking:

n(n-1)/2

Waarbij n het aantal mensen is dat betrokken moet zijn bij het project.

Zoals je kunt zien, groeit dit aantal exponentieel naarmate de teamgrootte toeneemt. Als je een team van 10 mensen hebt, moeten er 45 potentiële communicatiedraden worden beheerd. Maar als je een team van 50 mensen hebt, zijn er 1.225 potentiële communicatiedraden — dat is 27 keer meer! En als je een team van 100 mensen hebt, zijn er 4.950 mogelijke communicatiedraden — dat is 110 keer meer!

Het is belangrijk op te merken dat dit niet alleen een probleem is met grotere teams, maar met elk team waar individuen zich niet op dezelfde locatie bevinden. Dit komt omdat het aantal mogelijke communicatiedraden niet beperkt is door de fysieke nabijheid van de teamleden.

Bijvoorbeeld, je hebt een team van 10 mensen, maar ze bevinden zich allemaal op verschillende delen van de wereld. In dit geval zijn er nog steeds 45 potentiële communicatiedraden die moeten worden beheerd — ook al zijn de teamleden niet fysiek dicht bij elkaar.

En het kan erger worden. De bovenstaande berekening gaat uit van slechts één communicatiemethode. Als we rekening willen houden met verschillende communicatiemethoden, zouden we de vergelijking als volgt moeten herschrijven:

n(n-1)/2

Waarbij n het aantal communicatiekanalen is.

Laten we het aantal communicatiedraden hierboven opnieuw bekijken, maar deze keer aannemen dat n bestaat uit:

• E-mail
• Groepschat
• Persoonlijke chat
• Opmerkingen in een projectmanagementsysteem
• Bellen
• Notities/Opmerkingen in documenten

Als we de cijfers invullen, krijgen we het volgende:

• 2 teamleden = 6 communicatiedraden
• 3 teamleden = 18 communicatiedraden
• 5 teamleden = 60 communicatiedraden
• 8 teamleden = 168 communicatiedraden
• 10 teamleden = 270 communicatiedraden
• 15 teamleden = 630 communicatiedraden
• 20 teamleden = 1.140 communicatiedraden
• 30 teamleden = 2.610 communicatiedraden
• 50 teamleden = 7.350 communicatiedraden
• 100 teamleden = 29.700 communicatiedraden

Het is beangstigend hoe snel het aantal communicatiedraden groeit — en als remote werk grotere vergaderingen gemakkelijker mogelijk maakt die in het echte leven niet praktisch zouden zijn, dan is het een dubbelzijdig zwaard.

Dus, kortom, een strategie is cruciaal om de communicatie-explosie te vermijden die kan gebeuren met zelfs een relatief klein aantal teamleden.

En hoewel het idee van een “communicatiestrategie” complex en groot kan klinken, hoeft het dat niet te zijn. Het belangrijkste is om een paar principes vast te stellen, belangrijke communicatiekanalen te benoemen en misschien ook aan te geven wat niet te doen.

Een paar fundamentele principes om te overwegen:

• Houd informatie open. Ga ervan uit dat alles maanden/jaren later gemakkelijk vindbaar en deelbaar moet zijn. Zorg ervoor dat iedereen in het projectteam toegang heeft tot alle benodigde informatie, en wees voorzichtig met het benoemen van bestanden en documenten met dit in gedachten.
• Faal aan de kant van duidelijkheid. Stel je voor dat iemand nieuw het projectteam komt versterken. Documenteer informatie duidelijk en beknopt om ervoor te zorgen dat ze kritische beslissingen gemakkelijk kunnen begrijpen.
• Houd notulen van vergaderingen. Zorg ervoor dat alle belangrijke vergaderingen worden vastgelegd en gemakkelijk vindbaar zijn.

Wat betreft communicatiekanalen, hoe minder, hoe beter. We zouden voorstellen om het te beperken tot het volgende:

• Een projectmanagementsoftware om taak specifieke discussies te hebben.
• Vergaderingen (persoonlijk of op afstand) met notulen en ergens om alle projectnotulen op één plek te vinden.
• Documenten: dit kunnen opmerkingen en discussies binnen Google Docs of specifieke tools zijn (bijv. Figma voor UX-ontwerp) die opmerkingen toestaan.

Het is ook acceptabel om groepschat aan deze lijst toe te voegen — maar dan moet het zorgvuldig worden beheerd, omdat het een enorme vergadering kan worden die de hele dag (en elke dag!) zonder een duidelijk doel of agenda duurt.

De projectmanager moet deze regels duidelijk vaststellen en een stralend voorbeeld zijn van hoe samen te werken, terwijl ze af en toe een stok (figuurlijk, niet letterlijk!) gebruiken om projectteamleden terug te brengen naar correcte communicatie.

Laatste Gedachten

Ongeacht iemands niveau van expertise, is het altijd waardevol om een stap terug te doen en een onderwerp of proces op het fundamentele niveau te bekijken. Dus, door diep in het onderwerp projectmanagement te duiken, hebben we de belangrijkste eerste beginselen geïdentificeerd die nodig zijn om een project succesvol uit te voeren.

Elk project moet een projectmanager hebben: zij zorgen ervoor dat het project duidelijke doelstellingen heeft, die zijn opgesplitst in taken die moeten worden voltooid om het einddoel te bereiken. De projectmanager moet vervolgens een teamlid aan elke taak toewijzen. Samen kan het team de tijdslijnen voor elke individuele taak en voor het gehele project identificeren.

Het zijn vaak de schijnbaar vanzelfsprekende dingen die problemen kunnen veroorzaken, eerder dan geavanceerde onderwerpen, die meer aandacht krijgen — bijvoorbeeld communicatie. Dit is waarom er een goed gedefinieerde communicatiestrategie moet zijn, zowel binnen het projectteam als extern, met de belanghebbenden.

Projectmanagement is een complex onderwerp, dus dit is geenszins een uitputtende gids. Er zijn nog steeds enkele factoren om te overwegen die we niet in dit eerste overzicht hebben behandeld, zoals budgetten, methoden om conflicten tussen opties op te lossen, en hoe ver delegatie binnen een project moet worden genomen.