# NUPP

Nagenoeg Universele Project Principes

[image]

Dit is een downloadbare versie van de online handleiding (https://omimo.org/nl/modules/nupp/), gemaakt op 2026‑07‑02. Op de website vindt u altijd de nieuwste versie.

NUPP komt voort uit OMIMO (https://omimo.org/nl/), een familie van open, minimalistische modules.

Deze handleiding kan vrij worden verspreid onder de Creative Commons Attribution 4.0 Internationale licentie.

OMIMO wordt medegefinancierd door de Europese Unie. De geuite standpunten en meningen zijn echter uitsluitend die van OMIMO en weerspiegelen niet noodzakelijkerwijs die van de Europese Unie of EPOS VZW. Noch de Europese Unie, noch de subsidieverlenende autoriteit kan hiervoor verantwoordelijk worden gehouden.

Vertaald door: Damien Camerman


## Inleiding

NUPP is een verzameling van Nagenoeg Universele Project Principes: die principes waar we goed aan zouden doen om ze in elk project te volgen, welke methodologie of benadering er ook wordt gebruikt. Ze hebben tot doel om de kans op slagen van het project te maximaliseren.

Elk van de beschikbare bronnen en methoden voor het uitvoeren van projecten steunt op sommige van deze NUP’s (Nagenoeg Universele Principes). De volgende punten moeten hierbij echter in gedachten gehouden worden:

  - Meestal steunen ze niet op alle NUP’s, en voor de gebruiker zou het beter zijn om het geheel aan principes te overwegen in plaats van slechts een subset.
  - De onderliggende principes worden in die bronnen en methoden vaak onvoldoende duidelijk gemaakt, en de meeste gebruikers verliezen zich in de praktische details zodat ze die principes vergeten en dingen beginnen te doen die er niet meer mee overeenstemmen.

NUPP is compatibel met alle veelgebruikte methoden, systemen, bronnen, en frameworks zoals PRINCE2^(®), PMBOK^(®) Guide, P3.express, PM², DSDM^(®), XP, en Scrum. Mogelijk is NUPP echter in contradictie met een interpretatie van één van deze systemen, en hier wordt de gebruiker aangemoedigd om zijn/haar interpretatie te heroverwegen.

NUPP is een verzameling van de volgende NUP’s:

  - NUP1 — Geef de voorkeur aan resultaten en feiten i.p.v. affiliaties
  - NUP2 — Behoud en optimaliseer energie en middelen
  - NUP3 — Wees altijd proactief
  - NUP4 — Onthoud dat een keten enkel zo sterk is als zijn zwakste schakel
  - NUP5 — Doe niets zonder duidelijk doel
  - NUP6 — Gebruik herhaalbare elementen


## NUP1 Geef de voorkeur aan resultaten en feiten i.p.v. affiliaties

[image]

We hebben allemaal de natuurlijke neiging om tot groepen te behoren, een neiging die vaak verder gaat dan zijn basisvorm, sterke verbondenheid creëert en problemen veroorzaakt. Door affiliaties verliezen we veel meer dan dat we winnen. We kunnen professionelere en effectievere experts worden als we onze identiteit en voorkeur niet beperken tot bepaalde groepen.


### Voorbeeld: Agile vs. Waterfall

Een groep zeer enthousiaste mensen die de moed hadden om een adaptieve ontwikkelingsaanpak in IT-ontwikkeling te proberen op een moment dat het de norm was om gebruik te maken van een voorspellende aanpak, kwam bij elkaar en ze noemden hun aanpak “Agile”. Dit was een geweldig initiatief om de keuzes niet te beperken tot wat noodzakelijk leek. Er zijn nog steeds veel enthousiaste en resultaatgerichte mensen in de Agile-gemeenschap, maar helaas zijn er ook mensen in deze gemeenschap die Agile tot een sekte maken en alle buitenstaanders als vijanden beschouwen. Dit levert op meerdere manieren problemen op, waaronder de volgende:

  - Het laat hen niet toe om te leren van iemand buiten hun groep
  - Het ontmoedigt buitenstaanders om van hen te leren
  - Het maakt het behoren tot de groep belangrijker dan het werkelijke doel, wat veel van haar leden ervan weerhoudt om de werkelijke betekenis van Agility te leren kennen

Dit probleem kan aanzienlijk verminderd, zo niet verwijderd worden, door “Agile” alleen te gebruiken als een label dat verwijst naar een ontwikkelingsaanpak in plaats van als een gemeenschap met leden; zodat daarbij mensen zichzelf als bedenkers, probleemoplossers en leiders beschouwen, die Agile eenvoudigweg zien als één van de tools in hun rugzak in plaats van als hun identiteit.

Er is geen Agile-watervaloorlog voor echte professionals.


### Voorbeeld: PRINCE2^(®) vs PMBOK^(®)

Er zijn veel professionals in de gemeenschap die zich associëren met PRINCE2^(®) of PMBOK^(®) Guide (meestal vanwege hun geografische locatie) en de andere niet kennen. We kunnen allemaal voorkeuren hebben voor bepaalde bronnen, maar we moeten ze niet beschouwen als onze identiteit, en wat nog belangrijker is, we moeten openstaan voor alle bronnen om ons perspectief en onze keuzes te verbreden.

De echte professional staat open voor alle ideeën, zoekt er naar, verdiept zich er in en gebruikt ze waar en wanneer nodig, zonder affiliaties.


### Voorbeeld: Voortdurend blijven leren

Affiliaties bevredigen de persoon door een gevoel van samenhorigheid, maar dwingen hem niet om te leren - sterker nog - soms ontmoedigen ze hem of haar zelfs om te leren uit angst om de groep te verliezen. Als onafhankelijk persoon, als expert zonder affiliaties, moet je die leemte in te vullen met leren, met permanent bijleren.

Waar wij vandaag in geloven is niet de waarheid. Het is slechts ons beste begrip ervan tot nu toe, dat moet worden verbeterd naarmate we verder gaan. Er is iets mis als iemands ideeën precies hetzelfde zijn als een paar jaar geleden. Dit is zelfs het geval voor NUPP: als je binnen enkele jaren terugkomt en precies hetzelfde ziet, moet je achterdochtig worden.


### Voorbeeld: Openheid

Als je bezwaar maakt tegen iemand, zorg er dan voor dat je je bezwaar richt op het idee en niet op de persoon. Dit helpt veel spanningen te voorkomen. Als iemand bezwaar heeft tegen of over je, probeer het dan niet te interpreteren als een oorlog tegen jezelf, maar als een discussie over je ideeën, en blijf er open voor staan. Luister niet om te reageren, luister om te begrijpen en werk samen met de andere persoon om het idee te verbeteren.

Sommige mensen kunnen zich bewust op jou richten in plaats van op het idee. In dat geval moet je hen helpen om zich op het idee te concentreren in plaats van op jou voordat je verder gaat, en proberen dit zo te houden gedurende het hele gesprek.


## NUP2 Behoud en optimaliseer energie en middelen

[image]

Middelen zijn beperkt. De middelen die beschikbaar zijn voor het project zijn beperkt, evenals de mentale energie die je hebt om goede beslissingen te nemen. Je moet deze middelen voor jezelf en voor het project behouden en optimaliseren en andere teamleden helpen om hetzelfde te doen.


### Voorbeeld: De 80/20 regel

In project management kan een groot deel van de mogelijke opbrengsten (ongeveer 80%) worden verkregen door het inzetten van een klein deel van de energie en middelen (20%). In de meeste gevallen is zich richten op 100% van de mogelijke opbrengsten zeer kostelijk en niet gerechtvaardigd. Deze regel moet in gedachten gehouden worden bij alles wat u doet en u doet er goed aan anderen aan te moedigen om hetzelfde te doen.


### Voorbeeld: Beslissingsmoeheid

We hebben slechts één bron van mentale energie om alle soorten beslissingen te nemen en om uiting te geven aan onze wilskracht. Als je een groot deel van deze bron gebruikt voor het nemen van onnodige of onbelangrijke beslissingen, heb je minder energie voor de belangrijke beslissingen, wat kan leiden tot slechte resultaten. Dit is één van de redenen waarom u micro-management moet vermijden (het “manage by exception” principe van PRINCE2^(®)).

Conflicten die over ideeën gaan kunnen nuttig zijn, maar conflicten die over mensen gaan, zijn meestal schadelijk voor het project en één van de gevolgen is dat het de mentale energie van de teamleden uitput. Als u een dergelijk conflict opmerkt, moet u uw best doen om de onderliggende oorzaak te vinden en op te lossen.


### Voorbeeld: Zorg goed voor jezelf!

De beslissingen die je neemt en de wilskracht die je tentoonspreidt, gebruiken je mentale energiebron. Aan de andere kant wordt deze bron gevuld met energie als je goed slaapt en eet. Zorg dus goed voor jezelf: zorg voor voldoende slaap en rust, en eet goed. Als je schadelijke gewoontes of slaapproblemen hebt, heb je daar niet alleen mee te maken; er zijn veel specialisten die je kunnen helpen dergelijke problemen op te lossen. Lichaamsbeweging kan ook helpen met deze energiebron, hoewel de onderzoeken hierover nog geen uitsluitsel geven.

Probeer de teamleden aan te moedigen om hetzelfde te doen als jij. Zorg er eerst voor dat ze in een duurzaam tempo en zonder al te veel overwerk werken. Probeer vervolgens, als je de keuze hebt, energieke, gezonde voeding en drankjes aan te bieden tijdens de werktijd.


### Voorbeeld: Werk-privé balans

Velen van ons houden van wat we doen, maar dat is op zich niet voldoende voor een leven met voldoening. Net zoals je je werk optimaliseert, zou je ook in je persoonlijke leven je ideeën moeten plannen en implementeren op een manier dat ze je leven vreugdevol en gelukkig leven maken. Als je gelukkiger bent, kun je ook succesvoller zijn op je werk. Probeer je teamleden aan te moedigen om hetzelfde te doen als jij.


### Voorbeeld: Motivatie

Motivatie is een complex concept. Er zijn een aantal interessante en nuttige bronnen over het onderwerp, en er zijn nog veel meer onwetenschappelijke bronnen. Desalniettemin moet je er meer over leren en er voortdurend bij stilstaan, want motivatie verhoogt de mentale energie van het team en daardoor ook de slaagkans van het project.

Motivatie kan zo eenvoudig zijn als mensen laten weten dat je hun goede werk waardeert door een vriendelijke glimlach of een eenvoudige “dank je wel”. Je moet echter voorzichtig zijn, want veel van de gebruikelijke vormen van motivatie, zoals kleine financiële beloningen, hebben een negatief effect.


### Voorbeeld: Samenwerking en teamwork

Mensen die samenwerken hebben soms de capaciteit om betere resultaten te creëren. Belangrijker nog is dat mensen sociaal zijn en graag deel uitmaken van een groep. Als je de negatieve aspecten van teamwerk kan elimineren en een prettige omgeving kan creëren, zullen de teamleden in het project gelukkiger zijn.

Je moet wel voorzichtig zijn, want mensen zijn verschillend, en sommigen hebben meer ontspanning, concentratie en tijd voor zichzelf nodig dan anderen; het is meestal een evenwichtsoefening.


### Voorbeeld: Eén-team cultuur

Er is een tendens bij verschillende stakeholders om groepen te creëren of te overwegen, en spanningen tussen deze groepen te veroorzaken; bijvoorbeeld mensen die zich richten op de zakelijke aspecten van het project versus mensen die het product bouwen. Deze spanning kost veel energie aan beide kanten en dat is een van de redenen waarom we moeten proberen een één-teamcultuur op te bouwen, waarin iedereen samen aan hetzelfde doel werkt.


### Voorbeeld: De wijsheid van de massa

Wanneer een groot aantal mensen met diverse achtergrond samenkomen en in een gefaciliteerde omgeving werken, bestaat het potentieel om zeer goede resultaten, ideeën en oplossingen te behalen, soms zelfs nog beter dan die behaald door individuele deskundigen.

Als u de mogelijkheid hebt, kunt u deze techniek regelmatig gebruiken en teamleden vragen u te helpen bij het oplossen van moeilijke problemen in het project. Naast de mogelijkheid om goede resultaten te behalen, stelt het teamleden ook in staat om te weten dat hun mening wordt gewaardeerd en dat zij een belangrijke rol spelen in het project, wat op zijn beurt hun niveau van energie verhoogt. Activiteit E02 van P3.express is een voorbeeld van het gebruik van de wijsheid van de massa in projecten.


### Voorbeeld: Chief Project Facilitator

Als je een projectmanager bent, hebben de meeste dingen die je doet een faciliterend aspect (of zouden ze dat in ieder geval moeten hebben). Aan de andere kant zou je kunnen opmerken dat de teamleden in het verleden slechte ervaringen hebben gehad met projectmanagers, en dat deze ervaringen van invloed zijn op hun relatie met u: een deel van hun energie wordt besteed aan het analyseren van uw gedrag op potentiële bedreigingen in plaats van u te vertrouwen. In dat geval kunt u uw titel veranderen van projectmanager in Chief Project Facilitator. Dat is immers wat je echt doet in het project.


## NUP3 Wees altijd proactief

[image]

Er zit een natuurlijke neiging in ons om reactief te zijn. Het kan ons helpen om onze energie te behouden bij het omgaan met onbelangrijke zaken, of het kan ons betere resultaten geven wanneer we te maken hebben met iets waarin we volledig incompetent zijn. Die situaties zijn anders dan onze projecten - daarin kunnen we immers betere resultaten bereiken door proactief te zijn.


### Voorbeeld: Planning

Als u naar een nieuwe locatie wilt rijden en u bent te laat, dan kunt u onmiddellijk beginnen met rijden om “tijd te besparen” en om eventuele problemen op te lossen wanneer deze zich voordoen. De proactieve aanpak is echter om wat tijd te nemen bij de start en uw navigatiesysteem zo in te stellen dat u de snelste route krijgt op basis van het verkeer, en mogelijke ongelukken en blokkades, en daarna te rijden; dat is tijd doorbrengen vóór de uitvoering, om later problemen te voorkomen en zo tijd te besparen op het einde van de rit.

In tegenstelling tot wat sommige mensen over Agile-projecten denken, is planning altijd noodzakelijk - men moet zich wel bewust zijn van de aard en het gewenste niveau van detail in de plannen. Plannen alvorens uit te voeren is een proactieve aanpak.

Denk aan het citaat: “Geef me zes uur de tijd om een boom om te hakken en ik zal de eerste vier uur besteden aan het aanscherpen van de bijl”.

Als deze situatie zich voordoet in een gemakkelijk te voorspellen project, dan kunt u 4 uur besteden aan het slijpen van uw bijl, omdat u er zeker van bent dat u een boom gaat hakken. In een Agile project weet je niet zeker of je een boom gaat hakken, kapotte takken gaat verzamelen, gras gaat oogsten, steenkool gaat hakken, of iets anders. Toch heb je nog steeds een algemene voorbereiding nodig voor al die dingen (bvb. weten waar de dichtstbijzijnde ijzerwinkel is), en je weet dat een specifieke voorbereiding nodig zal zijn (bvb. het slijpen) wanneer je je gaat focussen op een bepaalde oplossing; dat is plannen.


### Voorbeeld: Plannen van de planning

Het plannen van de manier waarop we het project gaan uitvoeren is een proactieve aanpak. Deze proactiviteit kan zelfs worden uitgebreid door de manier te plannen waarop we de uitvoering gaan plannen; dat is het management plan-concept van de PMBOK^(®) Guide, Management Strategies in PRINCE2^(®), en dit wordt ook benaderd in concepten van DSDM^(®).


### Voorbeeld: Doorlopende planning

De werkelijkheid komt zelden overeen met wat we gepland hebben, en dat is oké - maar daarom moeten we onze plannen voortdurend blijven aanpassen om ervoor te zorgen dat ze realistisch en praktisch blijven. Dat moeten we doen zodra aanpassing nodig is, en niet wanneer we in de problemen komen. Ook dat is een proactieve aanpak.


### Voorbeeld: Risicomanagement

Het hele concept van risicomanagement is gebaseerd op proactiviteit: wanneer we geconfronteerd worden met onzekere gebeurtenissen, is het niet goed om te wachten, te zien wat er gebeurt en er vervolgens op te reageren. Beter is om op voorhand na te denken over de mogelijkheden en effecten, reacties te overwegen en er iets aan te doen voordat het gebeurt.

Merk op dat wat we in projecten doen serieus is; het gaat soms over het leven van mensen.


### Voorbeeld: Definiëren van rollen en verantwoordelijkheden

Je kunt de leden van het projectteam laten werken zonder duidelijke op voorhand bepaalde rollen en verantwoordelijkheden, en vroeg of laat zal er een vorm van taakverdeling ontstaan, maar er zal veel kostbare tijd verloren gaan en deze aanpak garandeert ook geen resultaat. De proactieve aanpak is om in een vroeg stadium de rollen en verantwoordelijkheden te definiëren en deze aan te passen als dat nodig blijkt te zijn. Dit maakt het werken voor iedereen gemakkelijker en iedereen kan zich richten op het realiseren van iets, in plaats van bezig te zijn met het bepalen van wie wat doet.

Het aantal en de verscheidenheid aan rollen is afhankelijk van het type en de omvang van het project; het kan een eenvoudige invulling zijn zoals die in Scrum, iets gematigd zoals in P3.express, of iets veelomvattend zoals die in DSDM^(®) en PRINCE2^(®). Vergeet echter niet dat de rolbeschrijvingen in deze methoden alleen over managementactiviteiten gaan, en dat je ook altijd rolbeschrijvingen voor technische aspecten moet toevoegen.


### Voorbeeld: Beschikbare keuzes

Moet je het project voortijdig stopzetten of doorgaan met het project?

Er zijn zelden maar twee keuzes, ook al impliceert de bovenstaande vraag dat. U moet proactief te werk gaan en al uw keuzes in overweging nemen voordat u een beslissing neemt. Misschien kunt u het project herdefiniëren, misschien kunt u het project onderbreken tot er iets duidelijk wordt, of misschien kunt u de projectaanpak veranderen (bv. outsourcing), enz.


### Voorbeeld: Kritisch denken

We hebben allemaal veel vooroordelen die ons aan de ene kant helpen om te overleven, maar ons aan de andere kant voor de gek houden en ons daardoor slechte beslissingen laten nemen. Als het gaat over belangrijke beslissingen in het project, is het best om even stil te staan bij alle vooroordelen die onze beslissing zouden kunnen beïnvloeden vooraleer ze problemen veroorzaken.

Als referentie kunt u de lijst van cognitieve fouten in Wikipedia gebruiken (deze lijst is in het Engels).

Er zijn zelfs besluitvormingskaders die u kunt gebruiken om betere beslissingen te nemen. In het begin is het misschien afleidend en zelfs vervelend om ze te gebruiken, maar al snel went u eraan en profiteert u ervan zonder veel bewuste inspanning.


### Voorbeeld: Transparantie

We houden er niet van als het project vertraging oploopt of andere problemen heeft, maar dat betekent niet dat we dat moeten verbergen. U moet transparant zijn en de belanghebbenden op de hoogte brengen, omdat sommige van hen u kunnen helpen, en bovendien zullen zij vroeg of laat op de hoogte zijn van de problemen en de gevolgen ervan. Sommige gevolgen vereisen vroegtijdige acties van de belanghebbenden (bv. het accepteren van negatieve gevolgen).


### Voorbeeld: Effectieve communicatie

Het kan in veel gevallen voorkomen dat u rapporten naar belanghebbenden stuurt en dat ze u geen feedback geven. U kan denken dat alles in orde is omdat er geen negatieve feedback is, maar het kan best zijn dat dit niet het geval is. U moet proactief zijn en nagaan of ze het rapport echt hebben gebruikt en of het zijn doel bereikt heeft. Wat u hieruit leert kan u gebruiken om uw manier van communiceren aan te passen. Als u nalaat om dit te controleren, blijft een probleem misschien verborgen, en dit kan later resulteren in ernstige complicaties op een moment dat ze nog maar moeilijk op te lossen zijn.


### Voorbeeld: Neem verantwoordelijkheid

Het is gemakkelijk om anderen de schuld te geven van slechte resultaten. Stel bijvoorbeeld dat u wil dat uw organisatie u de volledige bevoegdheid geeft om alles in het project te veranderen zodat alles perfect kan worden georganiseerd zoals het hoort, maar u krijgt die niet en als gevolg daarvan mislukt het project. Dit getuigt niet van proactieve aanpak.

De proactieve aanpak is om verantwoordelijkheid te nemen en alles te doen wat u kan binnen de beperkingen die u zijn opgelegd. U kan niet verwachten dat de organisatie u volledig vertrouwt en u alle mogelijke middelen geeft in de hoop op goede resultaten, vooral wanneer zij al zoveel mislukte projecten heeft meegemaakt. Wat u moet doen is één kleine verbetering maken binnen de gestelde randvoorwaarden, die u dan kan gebruiken om vertrouwen te winnen, samen met een verhoging van de middelen en wat meer tolerantie voor de randvoorwaarden. Dat kan u dan weer gebruiken voor een iets grotere verbetering, en zo kan u doorgaan tot u uw streefdoel bereikt heeft.


## NUP4 Onthoud dat een keten enkel zo sterk is als zijn zwakste schakel

[image]

Er zijn verschillende aspecten aan projecten, en die hebben allemaal aandacht nodig; we moeten het project op een holistische manier bekijken. Zich concentreren op een ogenschijnlijk belangrijk domein (bvb. tijd) is niet genoeg, omdat alle domeinen interageren met elkaar. Het project zal dan ook niet goed verlopen tenzij ze allemaal voldoende aandacht krijgen.


### Voorbeeld: Het gaat om de deadline!

Laten we zeggen dat je iets aan het bouwen bent voor de Olympische Spelen. Dit project heeft dus een zeer strikte deadline, wat tijdsmanagement erg belangrijk maakt. Maar is dat echt zo? Wat als de kwaliteit zo laag is dat er na een tijdje opnieuw gewerkt moet worden? Dat zou gevolgen hebben op de timing, en we concluderen dus dat niet enkel tijd belangrijk is, maar ook kwaliteit. Stel dat je in een verbouwproject in de projectomschrijving o.a. een mooie afgewerkte tuin hebt staan. Je kan als buffer inbouwen dat als het project in tijdsnood komt, je de tuin kan overslaan en je oppervlakte gewoon kan bedekken met gras. Dit is perfect mogelijk, zolang dat die optie op tijd werd overwogen en dat de voorbereidingen werden getroffen. Dit maakt dat scope ook belangrijk is. Nu hebben we de scope, de tijd en de kwaliteit als centrale aandachtspunten.

Heb je gehoord van dat beroemde voorbeeld waarbij president Kennedy een conciërge in het NASA hoofdkwartier ontmoet en hem vraagt wat hij doet, en hij antwoordt: “Ik help een man op de maan te zetten”? Helpt dat soort mensen in het project ook niet om de deadline te halen?

Naarmate je verder gaat met deze denkoefening, merk je dat elk domein in het project bijdraagt aan tijdmanagement en dat je de deadline niet met een acceptabel niveau van zekerheid kunt halen, tenzij je aandacht besteedt aan alle domeinen.


### Voorbeeld: Selectief winkelen

Wanneer mensen geconfronteerd worden met een verscheidenheid aan methoden, beginnen ze soms aspecten te kiezen tussen de verschillende methodologieën (selectief winkelen, of “cherry picking”) en creëren ze een mix van alles wat interessant lijkt uit de verschillende systemen. Dit werkt meestal niet, omdat elementen niet geïsoleerd werken en met elkaar compatibel moeten zijn. Eventuele toevoegingen of wijzigingen aan een systeem moeten vanuit een holistische visie worden gedaan.

Daarom zien we soms tegenstrijdige elementen in verschillende methoden; voor iets dat goed werkt in het ene systeem, werkt het tegenovergestelde goed in een ander systeem. Het element op zich is op zich niet goed of fout.

De veiligste aanpak die je kan gebruiken is om één methodologie voor het project te kiezen, het op maat aan te passen aan jouw project, en er vervolgens voorzichtig nieuwe elementen aan toe te voegen door rekening te houden met de samenhang van het hele systeem.


### Voorbeeld: De anti-proces benadering

Eén van de grootste verwezenlijkingen van de Agile-methoden, is dat ze de aandacht hebben gevestigd op de menselijke aspecten. Het Agile Manifesto geeft meer waarde aan individuen en interacties dan aan processen en tools, hoewel dit misschien geen eerlijke vergelijking is. Bijna alle methoden zeggen dat menselijke aspecten belangrijk zijn, maar het echte verschil met Agile-methoden is dat menselijke aspecten daar een vast onderdeel zijn van de processen, in plaats van een eenvoudige suggestie. Het gaat dus niet om een competitie tussen menselijke aspecten en processen, maar eerder om de manier waarop menselijke aspecten in het systeem worden gezien.

Het lijdt geen twijfel dat sommigen proberen de menselijke aspecten te vervangen door meer gebruik te maken van geavanceerde processen, maar dat is geen goede manier van werken. Zelfs het tegenovergestelde bestaat: dat men die processen probeert te vervangen door menselijke aspecten, wat ook niet goed werkt.


### Voorbeeld: Dit zijn alle domeinen die u nodig hebt

Als u over de domeinen nadenkt, moet u oppassen dat u er geen van de domeinen mist. Maar welke hebt u dan allemaal nodig? Als u de fundamentele bronnen van informatie raadpleegt, zult u verschillende antwoorden krijgen; en toch is geen van hen de hele waarheid.

PRINCE2^(®) thema’s zijn domeinen, maar dat zijn slechts de domeinen die een sleutelrol spelen in de methodologie. De andere domeinen worden alleen maar geïmpliceerd.

De PMBOK^(®) Guide is geen methodologie en kan dit onderwerp veel beter behandelen met zijn tien kennisgebieden. Dit zijn echter interpretaties van alle domeinen vanuit het perspectief van de PMBOK^(®) Guide op het project, en niet zozeer vanuit een neutraal perspectief (waarmee we niet willen zeggen dat er noodzakelijkerwijs een neutraal perspectief is). Menselijke aspecten krijgen bijvoorbeeld niet veel aandacht in de PMBOK^(®) Guide.

Een goede bron van informatie over de domeinen is ICB. ICB heeft het echter niet over de domeinen, maar over de vaardigheden die nodig zijn in het project. Er is geen één-op-één relatie met de domeinen, maar deze bron is wel een grote hulp om de domeinen te identificeren.

Er is geen lijst van domeinen in NUPP, vooral omdat het een metasysteem is in plaats van een systeem, en ook omdat de categorisering van de domeinen afhankelijk is van het type project en zijn omgeving; een routinematig bouwproject kan bijvoorbeeld een ander perspectief vereisen dan een creatief onderzoeksproject.


## NUP5 Doe niets zonder duidelijk doel

[image]

U zou niets mogen doen dat geen duidelijk doel heeft. Stelt u zich twee parallelle werelden voor waar alles hetzelfde is, behalve datgene wat u overweegt te doen: hoe verschillend zouden die werelden zijn? Is het verschil de moeite waard om er aan te werken?

Als je geen duidelijk doel voor ogen hebt en alleen maar iets doet omdat alle anderen het doen, of omdat iedereen zegt dat het belangrijk is om het te doen, dan:

  - kan het zijn dat het in uw geval geen echt voordeel heeft, en dat u er dus niets uit kunt halen; of
  - het kan ook dat het bij u nog steeds potentiële voordelen heeft, maar omdat u het doel niet in gedachten hebt, kan het zijn dat uw manier van werken niet bijdraagt aan het realiseren van die voordelen.


### Voorbeeld: Portfolio’s en programma’s

Als u betrokken bent bij het selecteren en het initiëren van projecten, moet u ervoor zorgen dat u zich concentreert op de toegevoegde waarde en de problemen die moeten worden opgelost in plaats van op het product dat die dingen gaat realiseren. Het klassieke voorbeeld is de fabrikant van liften die vroeger klachten ontving over de snelheid van hun liften, en zo meerdere projecten had uitgevoerd om de snelheid te verhogen, zonder volledig succes. Dat ging door tot ze besloten om zich te concentreren op het probleem (de verveling of het ongemak van mensen) in plaats van op de “natuurlijke” oplossing (snellere liften). Als resultaat werden spiegels aan de liften toegevoegd, en het probleem werd eenvoudig en goedkoop opgelost.

Vergeet niet dat projectmanagement vooral gaat over het juist uitvoeren van de dingen, terwijl portfoliomanagement gaat over het uitvoeren van de juiste dingen. Het maakt niet uit hoe goed u uw projecten uitvoert; het zal niet goed werken als u de verkeerde projecten kiest. Het is allemaal een kwestie van het hebben van een duidelijk doel.


### Voorbeeld: Het project als geheel

De flexibiliteit van het product verschilt per project. In sommige IT-ontwikkelingsprojecten is het product volledig flexibel en hangt de uiteindelijke vorm af van de feedback die de incrementele groei van het product tijdens het project zal genereren, wat een adaptieve (Agile) aanpak vereist. Dit is in de praktijk een combinatie van de portfolio-, de programma- en de projectlagen, en vereist maximale aandacht voor het uiteindelijke doel. Het is een goed idee om het doel te documenteren en toegankelijk te houden; het is één van de doelen van de “productvisie”, zoals gebruikt in sommige Scrum-projecten. De aandacht voor de bedrijfswaarde in Agile projecten is hun manier om te zorgen voor afstemming met het doel.

In andere soorten projecten, waar het product relatief vast ligt en er andere mechanismen zijn om ervoor te zorgen dat het uiteindelijke product aan het doel voldoet, is het mogelijk voor de projectteamleden om een groot deel van hun focus te verschuiven van het doel naar het product (vandaar het “focus op producten” principe van PRINCE2^(®)). Maar er is nog steeds minimale aandacht nodig voor het doel om ervoor te zorgen dat wat gebouwd wordt aan het doel voldoet. Dit kan worden gedaan door het vergelijken van de geplande voordelen met de verwachtte voordelen (vandaar het principe van de “continued business justification” en het “business case” thema in PRINCE2^(®)).

Wanneer een project voor een externe klant wordt uitgevoerd, heeft de klant voor zichzelf een doel voor het project, en heeft uw bedrijf een ander doel. U moet beide begrijpen en gebruiken om echt te slagen.


### Voorbeeld: Monitoring van het project

Focussen op het uiteindelijke doel is noodzakelijk, maar dat doel kan te abstract zijn voor veel van de dagelijkse toepassingen. Daarom is een hiërarchie van factoren nodig om het praktischer te maken. Eerst worden de rechtvaardiging en de voordelen van het project gedefinieerd op basis van het uiteindelijke doel, en dan heb je expliciete en impliciete doelstellingen voor projectvariabelen (bv. tijd, kosten en kwaliteit) om aan de rechtvaardiging te voldoen, die ook op hun beurt aan het uiteindelijke doel zullen voldoen. Dit zijn doelen op lager niveau die nuttig zijn voor veel van onze dagelijkse taken.

Als het aankomt op monitoring, zal de low-level monitoring van het project worden gedaan met behulp van het laagste niveau van variabelen, omdat het niet altijd mogelijk is om het uiteindelijke doel te volgen. In dit geval moet u nog steeds de doelen voor ogen houden: wat is het doel van monitoring?

Een normaal en aanvaardbaar antwoord is om te bepalen of we op schema liggen, en zo niet, om een bepaalde reactie op gang te brengen die ons weer op schema brengt of de doelstellingen bijstelt en nagaat of het uiteindelijke doel nog steeds kan worden bereikt. Onze metingen moeten daarom in staat zijn om te helpen met dit lage doel, en de juiste metingen zijn voorspellingen voor de variabelen bij de voltooiing; bijvoorbeeld, wanneer zouden we het project kunnen voltooien? Hoeveel geld zouden we nodig hebben om het project af te ronden?

Alle andere metingen, zoals de geplande en werkelijke waarden tot nu toe, zijn slechts tussentijdse waarden die u nodig heeft om de voorspellingen te berekenen, niet de uiteindelijke waarden die u gebruikt voor managementdoeleinden.


### Voorbeeld: Documenten

Welke aanpak je ook gebruikt bij de ontwikkeling van het project, planning is altijd noodzakelijk. De belangrijke vraag is de mate van detail in elk type plan. Als er niet voldoende detail in het plan zit, zal het plan niet genoeg kunnen bijdragen en zal de uitvoering van het project gebaseerd zijn op ad hoc beslissingen in plaats van op geïntegreerde, holistische beslissingen. Aan de andere kant proberen veel mensen voorzichtig te zijn en te veel details toe te voegen, wat hun plan te moeilijk maakt om het voor te bereiden en te onderhouden, en te star voor de onzekerheden van het project. Het gevolg is dat het plan onrealistisch en nutteloos wordt.

De beste manier om te beslissen over de mate van detaillering is om voor elk element in het plan een doel voor ogen te hebben. Als u bijvoorbeeld overweegt om middelen aan het plan toe te voegen, moet u er een doel voor hebben: hoe ga je ze gebruiken? Hoe zullen ze het project helpen? Hoeveel moeite zal het kosten? En is het de moeite waard?

Soms gaat het erom te beslissen of je een bepaald element in je plannen wilt hebben, soms gaat het om de manier waarop je iets wilt plannen of voorbereiden. Of het nu gaat om een business case, een projectcharter of een rapport: u moet zich nog steeds afvragen waarom u dat document voorbereidt en hoe dit het project kan helpen.

Het zoeken naar een “sjabloon” is het tegenovergestelde van iets doen op basis van een doel.


### Voorbeeld: Statusrapporten

Het is gebruikelijk om in veel projecten lange statusrapporten te hebben. Op basis van deze NUP moeten we ons afvragen wat het doel van zo’n verslag is en hoe we dat doel kunnen bereiken, ongeacht wat de meeste andere mensen doen.

Dit kan er in veel gevallen toe leiden dat we zeer eenvoudige rapporten van één pagina opstellen die door de belanghebbenden echt gelezen en begrepen worden in plaats van lange rapporten. Dit is aandacht besteden aan het doel.

Als u echter rapporten van één pagina voorbereidt, kunnen sommige mensen bezwaar maken tegen u en denken dat u geen “goed” monitoringsysteem hebt. In de praktijk creëert dit een tweede doel voor u (naast het eerste doel, namelijk belanghebbenden helpen de status van het project te begrijpen), en om dat te bevredigen, kunt u eenvoudigweg een tweede type rapport maken dat erg lang is. U zult dat echter niet vermengen met het eerste rapport, omdat deze twee doelen niet hetzelfde zijn.


### Voorbeeld: Business case en projectcharter

Het opstellen van documenten zoals een business case en een project charter is voor de meeste mensen meestal een saaie, vruchteloze, bureaucratische noodzaak, terwijl deze documenten allemaal geldige doelen hebben die voor de meeste projecten gelden. Als u een “sjabloon” probeert te vinden en in te vullen, is het werk gewoon verspild; wanneer u daarentegen de echte doelstellingen van die documenten controleert, kijkt of en hoe ze nuttig kunnen zijn in uw project, en vervolgens de documenten voorbereidt op eender welke manier die u verkeur uitgaat, en u tracht op deze manier aan de doelstellingen van de oefening te voldoen - zo verkrijgt u behoorlijke en nuttige documenten.

Terwijl u nadenkt over de manier waarop u de documenten kunt voorbereiden om aan hun doelstellingen te voldoen, denkt u misschien niet aan elk scenario en mist u misschien iets. Om dat te voorkomen, kunt u controleren wat bronnen zoals PRINCE2^(®), PMBOK^(®) Guide, P3.express en DSDM^(®) suggereren, en deze suggesties kan u vervolgens evalueren op basis van uw doelstellingen.


### Voorbeeld: Na afloop van het project

Hoewel het project een specifiek doel heeft, en we het halen van dat doel gedurende het hele project mogen beoordelen, wordt de realisatie van het doel voornamelijk geëvalueerd op basis van de voorspellingen die tijdens het project worden gedaan. We mogen de evaluatie na afloop van het project echter niet vergeten. Het is belangrijk om de realisatie van de doelen na het project te controleren, omdat

  - we dan kunnen zien hoe de uiteindelijke doelen worden bereikt en daarvan kunnen leren voor toekomstige projecten, en
  - soms de doelen alleen bereikt worden als we na de voltooiing van het project nog enkele bijkomende taken uitvoeren, en het begrip van de noodzaak van die extra taken vraagt om monitoring.

Die monitoring na afloop van het project is een noodzakelijke stap bij een doelgerichte aanpak. Dit is vooral de verantwoordelijkheid van programma- en portfoliomanagementsystemen, en omdat de meeste bedrijven niet over dergelijke managementlagen beschikken, wordt deze stap meestal verwaarloosd. Daarom voegen methoden zoals P3.express en DSDM^(®) deze stap toe aan hun projectmanagementmethoden.


### Voorbeeld: Eenvoud

De wereld is complex en chaotisch, maar onze modellen benaderen delen van de wereld op een abstracte manier, en kunnen dus eenvoudig zijn. Daarenboven werken eenvoudige systemen meestal beter, omdat we ons op het hoofdidee kunnen concentreren.

Velen van ons proberen betere resultaten te bereiken door complexiteit aan onze systemen toe te voegen, in de hoop dat het zal overeenkomen met de complexiteit van de wereld, ook al maakt dit het systeem in de praktijk moeilijk werkbaar en blokkeert het ons meestal om aan het doel te voldoen.


### Voorbeeld: Maatwerk

Een stuk software voor het streamen van muziek vereist heel andere eigenschappen dan een stuk software dat gebruikt wordt voor apparatuur in een ziekenhuis of een vliegtuig waar het leven van mensen van afhangt, of een stuk software dat gebruikt wordt in een satelliet waar het vele jaren zou moeten werken zonder te crashen, en ze zijn allemaal verschillend van het bouwen van een zomervilla, een brandweerkazerne, en een verwerkingsfabriek.

Wanneer u de doelstellingen in gedachten heeft, zal u beter begrijpen hoe u de systemen en de documentatie voor verschillende projecten kunt aanpassen.


## NUP6 Gebruik herhaalbare elementen

[image]

Een ad hoc aanpak van het project kost te veel energie en middelen en loopt altijd het risico dat een aantal noodzakelijke elementen ontbreken. De beste manier om te vereenvoudigen is het gebruik van herhaalbare elementen, bij voorkeur in herhaalbare cycli.


### Voorbeeld: Kwaliteitschecklists

Een checklist is een eenvoudig voorbeeld van een potentieel herhaalbaar element dat veel mensen in hun persoonlijke en professionele leven gebruiken. Neem bijvoorbeeld de kwaliteitscriteria van een eindproduct:

  - Eerst kunt u een checklist van alle criteria maken, een vorm van planning.
  - Wat NUP6 aanbeveelt is om te proberen het te veralgemenen: zijn er andere, vergelijkbare eindproducten in het project? Bereid in dat geval een algemene kwaliteitchecklist voor die categorie van eindproducten voor en gebruik die voor al die producten. Als er enkele variaties zijn, houd dan de algemene lijst bij en voeg een paar extra items toe voor de specifieke eindproducten. Nu heb je herhaalbare checklists.
  - Als u eenmaal algemene checklists hebt opgesteld voor verschillende types eindproducten, kunt u elementen vinden die zich onder hen herhalen, wat een virtuele overlappende ‘ouder’-categorie voor hen suggereert. In dat geval kunt u, in plaats van de items van al die algemene checklists te herhalen, deze uitpakken en ze in een ouderchecklist plaatsen. Uiteindelijk heb je waarschijnlijk één algemene checklist voor het hele project. Scrum’s “definition of done” is een voorbeeld van het gebruik van checklists op projectniveau voor kwaliteit (tussen eventueel nog andere checklists). Door dit te doen, zal elk eindproduct behoren tot een hiërarchie van categorieën en moet het voldoen aan de items die voorkomen in de checklists van alle categorieën in hun keten.

Hierdoor wordt een item in de ouderchecklist herhaalbaar voor alle deliverables eronder, wat tijd en energie bespaart in planning en uitvoering.

Belangrijker nog: als u dit eenmaal voor één project doet, kunt u het op maat maken en gebruiken voor alle soortgelijke projecten in de toekomst, wat een herhaalbare vorm van planning is voor meerdere projecten.


### Voorbeeld: Processen en workflows

Sommige deliverables, of eraan gekoppelde doelen, hebben bepaalde stappen nodig die gestandaardiseerd en herhaalbaar kunnen worden. Als de deliverables bijvoorbeeld individueel moeten worden ontworpen en goedgekeurd, kunt u een eenvoudige workflow voorbereiden die hiervoor alle stappen, de betrokken mensen en de geschatte duur duidelijk maakt, zodat veel problemen worden vermeden. U moet er echter op letten dat u de workflows en processen niet te ingewikkeld maakt of overdocumenteert, omdat dit negatieve implicaties zal hebben. Alle mensen die betrokken zijn bij het project zouden de workflows en processen moeten zien als iets dat hun werk ondersteunt en alles gemakkelijker maakt voor hen, in plaats van als bureaucratische documentatie die hun echte werk blokkeert.

Agile projecten hebben herhaalbare elementen in hun iteratieve ontwikkelingsaanpak, waarbij bepaalde soorten ontwikkelingsactiviteiten worden herhaald voor elke functie; bijv. de gebruikelijke dagelijkse routine in XP (eXtreme Programming): het koppelen, het kiezen van een item, het ontwerpen op een whiteboard, het bouwen van de testscripts en de code, het integreren van de code, enz.

Naast de herhaalbare workflows die gebruikt kunnen worden voor technische activiteiten, kunt u ook herhaalbare elementen hebben voor de project management activiteiten. De processen in de PMBOK^(®) Guide, PRINCE2^(®) en DSDM^(®), de activiteiten in P3.express en de evenementen in Scrum zijn voorbeelden van dit concept.


### Voorbeeld: Cycli

Het is nuttig om herhaalbare elementen te hebben voor het beheer van het project. Men kan nog meer vereenvoudigen door deze in herhaalbare cycli te plaatsen. Deze cycli maken de dagelijkse activiteiten van mensen die betrokken zijn bij het beheer en de leiding van het project een stuk gemakkelijker. Voorbeelden van dit concept zijn cycli van procesgroepen bij gebruik in een project met meerdere fasen in de PMBOK^(®) Guide; stadia in PRINCE2^(®); dagelijkse, wekelijkse en maandelijkse cycli in P3.express; iteraties en tijdsblokken in DSDM^(®); en Sprints in Scrum.

Kortere cycli zijn gemakkelijker te begrijpen en te gebruiken dan langere cycli, bijvoorbeeld Sprints in Scrum in tegenstelling tot de fasen volgens de PMBOK^(®) Guide. Te korte cycli kunnen echter niet voldoende zijn om bepaalde soorten projecten te ondersteunen. Een oplossing kan het gebruik van meerdere cycli zijn, zoals DSDM^(®)’s gebruik van korte tijdblok-cycli in combinatie met langere iteratie-cycli, of het gebruik van P3.express’ van dag-, week- en maandcycli.


### Voorbeeld: Methoden

Het gebruik van een methodologie of een framework voor het uitvoeren van een project is een ander voorbeeld van het gebruik van herhaalbare elementen. Dit kan een bestaand systeem zijn zoals PRINCE2^(®), P3.express, DSDM^(®) of Scrum, of een systeem dat u zelf heeft aangepast of gebouwd. Doorgaans is het een beter idee om te beginnen met één van de bestaande methoden en deze aan te passen aan uw behoeften, dan om het vanaf nul op te bouwen.

Elk herhaalbaar element is abstract en moet worden aangepast om het te doen passen in de echte wereld. Er bestaat echter een spectrum van abstractie en behoefte aan maatwerk: kleine, relatief concrete kwaliteitschecklists staan aan de ene kant van het spectrum met de minste abstractie en behoefte aan maatwerk, terwijl aan de andere kant de methodologieën het meest moeten worden aangepast. U moet altijd rekening houden met de noodzaak van maatwerk, anders zal het herhaalbare element niet goed aansluiten bij uw behoeften.