De verschillende strategieën voor projectmanagement blijven onze lezers bezighouden. Zo ook Paulus Meijs, die in dit artikel zijn steen bijdraagt. Naast het reageren op eerder gepubliceerde stellingen voegt hij een aantal nieuwe toe.
De reactie van Sybren Brouwer (Autorijden om benzine te verbruiken, Computable 11-2-05) op het artikel “Ontwikkel in dienst van productie” (Ferdinand Geuther, Computable 28-1-05) illustreert de kloof tussen verschillende culturen. In dit geval betreft het niet zozeer de kloof tussen ict en business, zoals belicht in de artikelen ‘Prince II ontbeert communicatiestrategie’ (Theo Koster, Computable 25-1-05) en de reactie daarop van Evert Offereins (‘Het gat tussen ict en de business’, Computable 18-2-05). De reactie van Brouwer laat zien dat er ook grote verschillen bestaan tussen verschillende bedrijfsculturen (met hun bijbehorende ict-afdelingen). Hier worden twee uitersten getoond: aan de ene kant de ‘productiecultuur’, die de mentaliteit ademt van ‘poten in de modder’, en ‘hoe hou ik de tent zo goed mogelijk draaiende’; aan de andere kant een ‘correctheidscultuur’, waar meer tijd en ruimte is voor kwaliteit en zorgvuldigheid.
Flexibiliteit
Ik denk dat beide auteurs gelijk hebben met het punt dat ze naar voren willen brengen. Bij ‘productie’ van Geuther dat niet alleen de primaire functionaliteit in het oog gehouden moet worden, maar dat er ook aandacht moet zijn voor de besturings- en onderhoudsfunctionaliteit. Dit zijn aspecten die in een productie- en deadlinegedreven omgeving gemakkelijk kunnen ondersneeuwen. Het is wel ingewikkeld om deze extra functionaliteiten in een business case gerechtvaardigd te krijgen, maar anderzijds leidt dat er wel toe dat juist de componenten met de meeste duidelijk toegevoegde waarde zullen worden geselecteerd. Daarom lijkt het mij onwaarschijnlijk dat alle drie aspecten evenveel gewicht verdienen (punt vijf). Het is wel nodig dat er een minimum voor elk aspect moet worden gereserveerd. Verder is het te betwisten dat veel moeite moet worden gedaan om zoveel mogelijk bijzondere gevallen mee te nemen (punt acht). In het verleden heeft dat er toe geleid dat systemen extra complex werden, en de extra functionaliteit niet eens gebruikt werd. Het is een beter streven om het systeem een zekere mate van flexibiliteit mee te geven, functies waar uitzonderingen op een minder standaard en mogelijk bewerkelijker manier toch verwerkt kunnen worden, zoals bij dat punt ook met ‘een apart proces’ wordt aangegeven.
Kwaliteit
De reactie ‘autorijden’ van Brouwer benadrukt terecht het belang van kwaliteit. In een omgeving waar ruimte voor zo’n streven naar kwaliteit is, zijn de opmerkingen van Geuther mogelijk open deuren, of minimumeisen, maar er zijn voldoende bedrijven, zeker in de productiesector, waar het doel van Geuther nog een schone droom is. Ik ondersteun ook het belang van risicoanalyse, maar ik heb het in mijn twintig jaar ervaring pas éénmaal concreet in praktijk gezien in een project waar ik aan meewerkte. Op grond van die risicoanalyse is het project destijds ook nog prompt afgeblazen. Ik vrees dat het woord risicoanalyse in veel ‘productiebedrijven’ meer een theoretische term blijft, dan dat er aandacht aan wordt besteedt. Ik vermoed dat beide benaderingen nog wel wat van elkaar kunnen leren, al denk ik dat de culturen te verschillend zijn om tot een uniforme aanpak te komen.
Eerder moet per situatie worden afgewogen welke strategie het meest passend is bij de gegeven cultuur, zoals ook door John Roos (‘Resultaat binnen het bereikbare’, Computable 11-2-05) wordt aangegeven. Verder is het wel belangrijk dat er communicatie over (het belang van) de verschillende aspecten plaats blijft vinden, wat mij terugbrengt naar het begin van mijn betoog. In veel projecten en bedrijven is het van belang om de communicatie op gang te brengen en te houden, of dat nu vanuit project, beheer, ict, klant of bedrijf is.
Mislukte communicatie
Als een project mislukt, ligt dat meestal niet aan de communicatie, maar juist en vooral aan de mislukte communicatie. Cijfers geven aan dat het tot negentig procent van de hoofdoorzaken van mislukken behoort.
Hoewel de projectcommunicatie formeel binnen Prince2 vooral een zaak is van de stuurgroep, zou ik er desalniettemin voor pleiten om de communicatie juist (ook) door projectleden te laten plaatsvinden, en dan bij voorkeur een participerende gebruiker, zoals de ‘senior user’ bij Prince2 (wel in de stuurgroep), of de ‘ambassador user’ uit DSDM. Als het goed is, zijn zij juist door de dagelijkse omgang met het project zodanig enthousiast, dat zij dat goed kunnen uitdragen, en daarmee de misschien iets minder professionele communicatievaardigheden ruimschoots kunnen compenseren.
Kortom, alle genoemde artikelen illustreren maar weer eens het belang van wederzijdse communicatie. Proberen te leren van elkaar geeft ons extra mogelijkheden, die mogelijk weer in de eigen praktijk zijn toe te passen. Op zijn minst geeft het soms weer eens een frisse kijk op de praktijk van alledag.< BR>
Paulus Meijs, informatie-analist
