“Players win games, teams win championships.” – Bill Taylor

Observaties

Iedereen heeft wel eens met een team gewerkt wat veel beter of juist veel slechter presteerde dan andere teams. Zowel zakelijk als privé heb ik met veel verschillende groepen gewerkt en daarbij zijn een paar opvallende zaken:

1. Als je mensen de kans geeft dan wil iedereen liever zijn teamleden plezieren door goed werk te leveren dan teleurstellen.
2. Zoals uit het citaat wel blijkt kan een uitstekende speler wel fantastisch resultaat leveren, maar heb je het hele team nodig voor de eindoverwinning. Het moet daarom voor alle teamleden duidelijk zijn wat hun bijdrage inhoudt, en vooral wat de onderlinge afhankelijkheden zijn.
3. Mijn rol is meer die van “facilitator”, dan van “slavendrijver”. Mensen willen over het algemeen graag excelleren in hun werk en grootse prestaties neerzetten. Mijn taak zit vooral in het scheppen van de voorwaarden zodat de teamleden vol aan de slag kunnen en het duidelijk overbrengen van de doelen die we gesteld hebben. Alle verstoringen van buitenaf probeer ik weg te nemen en alle vraagstukken die buiten het team opgelost moeten worden vallen onder mijn aandachtsgebied.
4. Persoonlijke relaties zijn het meest belangrijke  onderdeel van teams. Niet alleen mijn relatie met de teamleden, maar ook de onderlinge relaties. De persoonlijke band die teams hebben is vaak sterker en doet meer voor de teamprestatie dan enige beloning of straf die het team wordt voorgehouden. Andersom kan het ook zo zijn dat er teamleden zijn die niet met elkaar overweg kunnen. Het achterhalen van deze weerstanden en zorgen dat het team hiermee om kan gaan zijn voor mij belangrijke aandachtspunten.

Theorie

Uiteraard kan dit alles niet zonder een stuk theorie. Volgens mij heeft iedereen ondertussen al wel van de piramide van Maslov gehoord. Deze is ondertussen beroemder dan die van Austerlitz of zelfs Cheops. Hoe vallen bovenstaande observaties nu in deze piramide. Ik heb hierbij voor het gemak de orginele piramide genomen, niet de latere versie met nog meer lagen.

De primaire behoeften vallen buiten het werk. Het werk biedt wel een salaris waarmee in ieder geval aan een aantal van deze behoeften voldaan kan worden.

Een veel belangrijker punt is de zekerheid. Hier spelen zaken als relaties of, in dit geval, het horen bij een team. Het bewaken van de onderlinge banden en verstandhoudingen, een belangrijke taak voor mij, kan ervoor zorgen dat deze zekerheid geboden wordt. Pas als het team ook goed als een team kan werken, kan aan de volgende tree gewerkt worden.

Voor acceptatie geldt dat er behoefte is aan positief contact. De teamleden vinden het niet alleen prettig met elkaar te werken, maar waarderen elkaars werk ook. Dit komt enerzijds doordat er begrip is voor de onderlinge afhankelijkheden en anderzijds volgt dit uit het leveren van goed werk en vooral ook de terugkoppeling hierover.

De erkenning volgt deels weer uit deze terugkoppeling en uit de duidelijkheid die geboden wordt over een ieders taak binnen het grotere geheel. Voor een ander deel komt deze vanuit buiten het team. Doordat het team als geheel een betere prestatie levert, volgt er erkenning van buitenaf.

De bovenste tree, zelfontwikkeling, is vaak lastiger in te vullen. Eerst moeten de teamleden zich veilig genoeg voelen zodat ze ook een echte groei in kunnen zetten. Niet alleen de veilige paden volgen en werkzaamheden uitvoeren die ze al kennen, maar ook nieuwe taken oppakken en tot een goed einde brengen. Dit lukt alleen als het team in zijn geheel vertrouwen in elkaar hebben en ze ook merken dat “de buitenwereld” dit vertrouwen ook heeft. Kortom, ook in deze behoefte kan pas voorzien worden als in de onderliggende behoeften voorzien is.

“Life is really simple, but we insist on making it complicated.” – Confucius

Een goede methode om een besluit uit te kunnen stellen is: meer mensen toevoegen aan het overleg. Maar wat nu als er al een (grote) groep is en we willen toch vlot tot besluiten komen? Laat de hele groep in één keer meewerken aan het besluit. Stel de verschillende keuzes op, leg deze aan de groep voor en laat de groep de prioriteiten bepalen.

Om een groep ook tot een gezamenlijk besluit te laten komen is het niet noodzakelijk om dit soort lijsten (gezamenlijk!) per punt te beoordelen. Laat iedereen de keuzes indelen in drie niveaus. Aangezien “Laag” voor veel mensen negatief overkomt is een indeling in “Hoog/Middel/Laag” geen goed idee. Kies liever voor “Goud/Zilver/Brons”.

Het simpelste is het om iedereen de punten zelf in de drie groepen te laten indelen. Geef hierbij een duidelijke omschrijving van de gevolgen voor een keuze, zodat mensen ook weloverwogen een keuze kunnen maken. Uitgaand van softwareontwikkeling kan een mogelijke indeling de onderstaande zijn.

	Goud Deze keuzes moeten in de eerste versie zitten, anders heeft het programma geen nut. Bijvoorbeeld omdat het programma niet werkt, geen functionaliteit biedt of ingaat tegen standaarden/werkwijzen.
	Zilver Deze keuzes zouden in een tweede versie kunnen zitten. Dit is noodzakelijke functionaliteit voor het beter/sneller werken met de nieuwe applicatie. Min of meer de reden voor het (laten) ontwikkelen van de nieuwe applicatie.
	Brons Dit zijn de krenten in de pap. Zonder deze functionaliteit kan de applicatie uitstekend functioneren, maar het toevoegen van deze functionaliteit zou bijvoorbeeld de productiviteit verhogen.

Dezelfde indeling kan ook gebruikt worden bij het selecteren van software. Goud staat dan voor functionaliteit die de applicatie absoluut moet hebben (of technische eisen waaraan de applicatie absoluut moet voldoen). Zilver geeft vervolgens de keuzes aan die wenselijk zijn. Brons tot slot geeft ook hier de krenten in de pap aan. Functionaliteit die, bij gelijke geschiktheid, de doorslag zou kunnen geven maar die niet gemist zou worden.

Valkuilen

De bekendste valkuil is uiteraard dat alles in de “Gouden” categorie moet vallen. Dit kan uiteraard werkelijk het geval zijn, maar meestal is het angst voor het mislopen van functionaliteit. Er kunnen bijvoorbeeld regels opgesteld worden waarbij iedereen een gelijke verdeling moet maken over de drie categorieën. Of dit mogelijk is hangt sterk van de keuzes en de groep af.

Een tweede valkuil is het samenvoegen van de diverse keuzes. Als één iemand binnen de groep een item perse in “Goud” wil hebben terwijl de rest van de groep dit niet zo ziet kan er uiteraard gediscussieerd worden totdat de keuze door de omgeving al genomen is. Een beter alternatief is het toevoegen van dat item aan “Goud” met de aantekening dat dit item op de nominatie voor “Zilver” staat. Zo wordt er binnen de drie categorieën weer aan een onderverdeling gewerkt, wat eigenlijk niet wenselijk is maar de besluitvorming fors kan versnellen.

“Nothing is particularly hard if you divide it into small jobs.” – Henry Ford

Henry Ford stelde al dat het opdelen van taken een positief resultaat kan hebben. Wat (destijds) voor het bouwen van een auto aan een lopende band gold, kan uiteraard niet zomaar overgezet worden naar de kenniswerker van tegenwoordig. Toch is het goed om ook bij onze werkzaamheden te zoeken naar mogelijkheden om functiescheidingen aan te brengen. In dit artikel wil ik het specifiek over de lagen in het (ICT-)beheer hebben.

De meest eenvoudige laag voor de meeste organisaties is de hardware. Vaak worden hier gespecialiseerde bedrijven voor ingehuurd of wordt deze volledig buiten de deur geplaatst (al dan niet in de ‘cloud’).

De volgende laag is minder eenduidig. In deze laag zit bij sommige bedrijven alleen nog maar de besturingssystemen (engels: Operating Systems, bijvoorbeeld Windows, Linux, AIX). Bij de meeste bedrijven is sprake van virtualisatie (virtuele machines). Hierdoor kunnen op dezelfde hardware meerdere virtuele machines draaien, kan één virtuele machines op meerdere fysieke machines draaien en allerlei andere varianten.

In de volgende laag volgen voor sommige organisaties de problemen. Om te kunnen komen tot besparingen is het raadzaam wat veel van deze organisaties presenteren als één homogene laag (“applicatiebeheer”) uit elkaar te trekken. Hierdoor komt als eerste een laag met technisch applicatiebeheer (TAB):

In de TAB-laag worden applicaties geïnstalleerd en voornamelijk beheerd. Het gaat hierbij met name om updates en patches maar ook de performance van de applicaties. De volgende laag is dan functioneel applicatiebeheer (FAB):

In deze laag wordt het functionele applicatiebeheer uitgevoerd. Het grote verschil tussen functioneel- en technisch applicatiebeheer ligt in de benodigde kennis van de beheerders. Bij technisch beheer is meer computerkennis nodig. Technisch applicatiebeheerders kunnen daardoor ook eenvoudiger ingezet worden voor het beheer van meerdere, verschillende applicaties. Bij functioneel applicatiebeheer is meer kennis van de primaire processen nodig. Een piekbelasting binnen TAB kan daardoor gewoonlijk binnen de aanwezige groep beheerders worden opgevangen terwijl voor pieken binnen functioneel applicatiebeheer eerder externe inhuur (of een betere planning) nodig zal zijn.

Tot zover de functies die binnen de IT-afdeling uitgevoerd worden. Er is echter een duidelijke reden voor alle hardware en applicaties: de business. Al deze systemen worden aangeschaft, ingericht en onderhouden ter ondersteuning van de (primaire) business-processen. De business bepaalt en onderhoud de eigen wensen in de laatste laag, het functioneel beheer (FB):

Gecombineerd geeft dit de onderstaande schematische weergave, waarbij de diverse lagen uiteraard qua invulling per bedrijf kunnen verschillen. Klik op de afbeelding voor een groter formaat.

“Project management is like juggling three balls – time, cost and quality. Programme management is like a troupe of circus performers standing in a circle, each juggling-three balls and swapping balls from time to time.” – G. Reiss

Er bestaat veel verwarring over de samenhang en verschillen tussen portfoliomanagement, programmamanagement en projectmanagement. Ik zal hier in het kort ingaan op de samenhang. Later kom ik terug op de verschillen.

Laten we als eerste kijken naar een willekeurig bedrijf. Binnen dit bedrijf worden diverse activiteiten uitgevoerd. Dat symboliseer ik hier met een grote cirkel:

Binnen dit bedrijf worden een aantal projecten uitgevoerd. Deze symboliseer ik hier met horizontale balken:

En de programma’s worden gesymboliseerd met verticale balken:

Dit levert tot slot het gehele portfolio op:

In de afbeelding komen de volgende zaken terug:

• Binnen een project vallen activiteiten.
• Een project kan weer bestaan uit sub-projecten.
• Binnen een programma vallen activiteiten en mogelijk één (of meer) projecten. Het is nadrukkelijk dus niet zo dat een programma een combinatie is van meerdere projecten, zoals nogal eens gedacht wordt.
• Projecten kunnen voor meerdere programma’s van toepassing zijn.
• Het portfolio bestaat uit alle activiteiten, projecten en programma’s.

Conclusie
Als projectmanagement het jongleren van 3 ballen is, en programmamanagement een groep jongleurs in een circus die ook nog eens ballen uitwisselen, dan kan portfoliomanagement gezien worden als de circusdirecteur die bepaalt welke jongleurs mogen optreden en hoe de ballen uitgewisseld worden.

De toekomst

In de toekomst wil ik hier regelmatig artikelen plaatsen over zaken die mij interesseren. Deze zullen voornamelijk liggen op het gebied van interim-, project-, progamma- en portfolio-management. Als er vragen zijn, stel ze dan gerust…