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

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.

▼ PDF