Projectmanagement (2021)

Wat is een project?

• Een project is een gecoördineerde inspanning om tot een bepaald resultaat te komen
• Het heeft veel te maken met plannen en planmatig werken

Begin & einde

Een project heeft een begin en een einde:

• Als een project geen einde heeft, wordt dat heel raar qua managing: Bv. een Trello-board dat eindeloos groeit - en daardoor onbeheersbaar wordt
• Als een activiteit eindeloos doorloopt, is het dus geen project
• Niet duidelijk of iets wel of niet eindeloos doorloopt, maar toch lijkt het een project? Geef het een timestamp. Bv. Administratie2020 is opeens wel een project, want het is nu eindig geworden.

Ik ken geen goede naam voor activiteiten in een bedrijf, die geen projecten zijn. Operationale activiteiten? Of gewoon de omschrijving van de activiteiten, zoals BizDev of Dagelijkse overhead?

Fases

• Tijdens m'n studie in Delft leerde ik, dat projecten uit fases bestaan, en dat je die fases lineair doorloopt
• De laatste fases waren zoiets als oplevering en afronding. De eerste fase had misschien iets met definitie of opstart te maken
• Ik geloof niet in het lineair doorlopen van een project. Vooral rondom software-ontwikkeling, worden sommige fases iteratief herhaald
• Vaak maak ik geen onderscheid in fases.

Projectnamen

Niets zo onhandig, als refereren naar een grootheid zonder naam. Daarom geef ik projecten vrijwel meestal een naam. En dan liefst korte namen, waaraan ik gelijk kan zien dat het een project betreft. Voorbeelden:

BoekBij MediaWikiUpdate FloatDrone BrushTour ForkBrush Amz.CamOp

Knak.JD Knak.TP BB BizDev3.2 BizDev4.1

Waar ik die namen zoal gebruik:

• Titels van Trello-borden
• Urenadministratie
• Namen van mappen en/of bestanden (projecten zijn voor mij primair georganiseerd middels mappen & bestanden)
• Namen van emailmappen. Overigens: Je kunt geen punten gebruiken in de namen van emailmappen. De naam van de emailmap voor BizDev4.1 wordt dan BizDev4_1 of BizDev41 - Dat is nog nooit een issue geweest.

Helaas heb ik de gewoonte om de namen van projecten nogal eens aan te passen. Ik denk dat dit een slechte gewoonte is, want het leid tot verwarring en is zonde van de tijd.

Basis: Mappen & bestanden

Begin 2020 heb ik me verdiept in wat voor mij de beste manier is om gegevens te beheren. Dingen die je offline bewaard en dingen die je online bewaard, kun je namelijk niet naadloos met elkaar integreren. Conclusie: De basis bestaat voor mij uit mappen & bestanden.

Hier zie je hoe ik een project in subprojecten indeel - Dit werkt super en is redelijk zelf-documenterend (itt. bv. Trello!). Het is ook heel gemakkelijk om eventuele subsubprojecten aan te maken: Gewoon mappen-in-mappen

Verdeel & heers - Opsplitsen in projecten

Ik vind het vaak lastig om een 'brei' aan werkzaamheden en doelen op een effectieve manier onder te brengen in projecten. Daarbij is het doel, om het beheersbaar te maken:

Zorg voor onderscheid - Vermijd ambivalentie

De reikwijdte van een project moet glashelder en intuïtief duidelijk zijn. Illustratie:

Hoort taak XYZ bij ProjectA of ProjectB?

en de tegenhanger hiervan:

Waar stond in hemelsnaam taak XYZ???

Op het moment dat het onderscheid tussen projecten niet duidelijk is, vind ik het heel lastig werken. Het kost me dan veel moeite om op gang te komen, en dat is killing voor mij.

Voorbeeld (okt. 2020)

• Voor een klant had ik projecten xInstantiate en xGrow. Dat eerste project betrof klonen van een bestaande site naar nieuwe sites. Dat tweede project betrof onderhoud en verbeteren van bestaande sites
• In de praktijk was het onduidelijk of een bepaalde taak betrekking had op nieuwe sites of bestaande sites
• Voorbeeld: Verbeteren van taalfouten in de bron-site, viel dat onder xInstantiate (want daar was het voor bedoeld), of xGrow, want het betrof immers werkzaamheden aan een bestaande site.

Uiteindelijk heb ik deze twee projecten samengevoegd onder de naam xGrow (ik heb dus de bestaande naam van een van de projecten gebruikt).

Houd het klein & beheersbaar

In weerwil van wat hiervoor stond: Projecten maar eindeloos groot laten worden, is ook niet te doen:

• Al is het maar, omdat Trello (wat ik toevallig vaak gebruik voor projectmanagement) te onoverzichtelijk wordt
• Op het moment dat een project te rigide wordt, omdat alles met alles lijkt samen te hangen, is het project misschien te groot geworden
• Op het moment dat de structuur van een project (=boards in Trello) te ingewikkeld wordt, is een project misschien te groot geworden - Loosely coupled vs. tightly integrated

Een truuk die soms helpt in deze situatie: Project opsplitsen in bv. ProjX2020Q2 en ProjX2020Q3, etc.

Wanneer is een project te groot?

In het vorige hoofdstuk werd gesproken over het opsplitsen van projecten in kleinere projecten, en de risico's die dat met zich meebrengt. Hier kijken we naar de tegenovergestelde situatie: Wat is het probleem als projecten te groot zijn. Hiermee wordt niet bedoeld dat een project te complex of groot is om door mij in m'n eentje nog gemanaged te worden. Het gaat om de scope van een project die te groot is.

Een paar indicaties dat een project misschien te groot is gedefineerd. Merk op dat ze bijna allemaal met Trello te maken hebben: Da's een belangrijke practische tool voor mij:

• Te veel scrollen binnen lijsten in Trello: Meestal heb ik in Trello een lijst werkvoorraad, of backlog. Op het moment dat deze lijst te groot wordt (dus dat je flink moet scrollen), is het een indicatie dat een project te groot is
• Te veel werkvoorraad-lijsten in Trello: Als ik aparte lijsten heb zoals Werkvoorraad - Added wk 41-43, Werkvoorraad - Added wk 44-46, etc. dan is een project misschien te groot
• Te veel oude items in Trello: Als in lijsten (vooraal Werkvoorraad en zoiets als Brainstorm of Grote lijnen) veel items staan die niet meer actueel zijn, of waarvan ik niet weet wat er bedoeld is, is een project waarschijnlijk te groot
• Eindeloos lijsten in Trello: Als er eindeloos lijsten zijn met opgeleverde taken (bv. OK - Wk 12, Ok - Wk 13, etc.) en ik me het leblazerus moet scrollen van rechts naar links als ik een nieuwe lijst heb aangemaakt, is een project misschien te groot
• → Geen overzicht meer: Als ik de samenhang tussen bepaalde items niet meer kan zien. Voorbeeld okt. 2020: Project Brushtour bevat oa. werkzaamheden die betrekking hebben op gSh & gMC, maar ik heb daar geen goed overzicht van, omdat het in Trello in één board zit met nog een hoop andere bezigheden → Op 30 okt. 2020 apart project van gemaakt. Ik ben benieuwd.
• Status moeilijk te achterhalen: Dit is een variatie op het punt hiervoor: Als ik van een bepaalde activiteit of persoon, niet meer wat wat de status is. En vooral: Als ik daar niet gemakkelijk achter kan komen. Goed voorbeeld: Tekstschrijven in schermafdruk hiernaast.

Casus: Okt. 2020

Waarschijnlijk een goed voorbeeld van een project dat te groot is: Dit zijn de mappen met taken of actiepunten. Wat je hier zoal tegenkomt: Google Ads - In Trello raakte ik het overzicht kwijt Tekstschrijven - Ik kan de status niet achterhalen Site-vertalingen Nieuwe sites Hosting.

Van Google Ads een apart project gemaakt, inclusief gMC, gSH en gSC (Google Search Console)

Van Tekstschrijven een apart project gemaakt. Maar of dat wijsheid is? gSC speelt hier ook een rol, maar zit al in Google Ads. Ik laat het maar zo Eigenlijk gebeurt er niet zo veel in dit project. Beetje overkill om in m'n projecten-spreadsheet hier een aparte rij voor te hebben

Projectafronding

Een voorlopig lijstje (januari 2021):

• Maak bestand ReadMe.txt aan, in de root van het project. De eigenlijke evaluatie en projectafronding zit vooral in dit bestand. Als een txt-bestand te beperkt is, dan een tekstverwerkersbestand gebruiken
• Inventaris: Waar staat alles. Denk aan bestanden; Trello; wiki; webservers; site-instanties, meer?
• Leerpunten & volgende keer: Misschien wel het belangrijkste
• Verplaats de mappen & bestanden naar zoiets als Projecten - niet-actueel
• Sluit het Trello-board. Gooi het niet weg, want sinds 2020 mag je nog maar een paar gratis boards hebben
• Verplaats sites van webservers naar een map in de root van het project. Schoon webserver op
• Archiveer database-backups in een projectmap. Verwijder de databases van de database-servers

Zie ook

• Scrum