Honderden jaren lang zijn projecten uitgevoerd door projectorganisaties, zonder dat deze organisaties zich er van bewust waren dat ze iets bijzonders deden. Het was gewoon werk en hoe dat georganiseerd werd was niet zo belangrijk. Tegenwoordig moet alles georganiseerd, gestructureerd en via een standaard methode. Eigen inbreng en creatief inrichten zijn uit den boze. Is dit wel zo goed, slaan we niet een beetje door?
Halverwege de vorige eeuw werden veranderingen steeds projectmatiger aangepakt bij grote bedrijven. Methodieken bestonden toen niet echt. Een project droeg bij aan het voortbestaan van het bedrijf en daarom moest het gebeuren. Wie het organiseerde of betaalde was niet zo belangrijk, het belang zat hem in de resultaten. De JBF-methode (Jan Boeren Fluitjes) was gemeengoed en ieder deed de projecten naar gelang de cultuur van het bedrijf of bedrijfsonderdeel het verwachtte of vereiste.
Tegenwoordig kun je geen project meer uitvoeren, zonder dat er een projectmanagementmethode aan te pas komt. Alles wat we doen moet keurig binnen kaders en binnen methoden verantwoord worden. Methoden als PRINCE2, PMBOK, IPMA en MPM worden vereist als je als projectmanager aan de slag gaat. Natuurlijk is een hoeveelheid basiskennis helemaal niet verkeerd, maar is het nou werkelijk zo dat projecten alleen maar slagen als je een methode kiest om het project aan te sturen?
Wat is er veranderd?
De omslag in het denken over en uitvoeren van projecten is gekomen toen (grote) bedrijven onderling gingen vergelijken wat de resultaten en kosten waren van vergelijkbare projecten. Dit was mogelijk doordat steeds meer gegevens openbaar werden en het communicatiemodel in de wereld veranderde door allerlei technieken.
Voor de komst van computers was het heel lastig om centraal gegevens te vergelijken, alles werd geregeld op de achterkant van een sigarendoos en projectdocumentatie bestond alleen in fysieke vorm. Vergelijken van projecten binnen je eigen bedrijf was al een hels karwei, laat staan het vergelijken van jouw projecten met die van andere bedrijven.
De grootste omslag kwam toen grote bedrijven er achter kwamen dat ze allemaal vergelijkbare projecten uitvoerden, maar dat de uitkomsten en kosten flink verschilden. Toen ontstond de gedachte om vrij van de inhoud te kijken naar de manier van organiseren en leiden van projecten: het begin van de methodieken.
Door de wijde uitzaaiing van internet en de onmetelijke mogelijkheden van het delen van kennis is het inmiddels ondenkbaar dat enig zichzelf respecterend bedrijf niet kiest voor een projectmanagementmethode bij het inrichten van projecten.
Je zou dus zeggen dat daarmee het bewijs geleverd is dat een methode het project helpt.
Helpt een standaardmethode?
Als trainer van diverse methoden is het natuurlijk het meest logisch om deze vraag met ‘ja’ te beantwoorden. Ontegenzeggelijk ís voor het uitvoeren van projecten een basis nodig en helpt het om kaders te stellen. Als je daarvoor handvatten gebruikt die in methoden onderwezen worden is daar helemaal niets mis mee en dat juich ik zelfs toe. Beter goed gejat dan slecht verzonnen zeg ik altijd maar.
Reden dat ik niet direct volmondig ‘ja’ zeg als antwoord op de vraag is de ontstaansgeschiedenis van de methoden. Elke methode is in principe een verzameling van ‘Best Practices’, geïnterpreteerd door een aantal knappe koppen die allerlei projecten hebben onderzocht en vanuit al deze ‘JBF-projecten’ een aantal gemeenschappelijke eigenschappen hebben gedestilleerd. Dit samengevoegd, met een mooie saus, een pakkend verhaal en hele mooie grafieken en platen leveren bij elkaar een ‘nieuwe’ methode.
Dit vertelt mij dat het dus heel goed mogelijk is om zelf als bedrijf een methode te ontwikkelen die voor dat bedrijf de beste manier is om de projecten in goede banen te leiden.
Standaardmethode versus bedrijfsmethode
Voordelen standaardmethode: Een standaardmethode wordt breed toegepast en heeft zich in de praktijk bewezen. Hierdoor hoeft er binnen het bedrijf zelf minder nagedacht te worden over de praktische invulling van projectmanagement. Dit zit immers in de methode zelf.
Er zijn voldoende trainers en professionals beschikbaar voor het bedrijf om in te huren als het bedrijf zelf niet de capaciteit heeft om de methode te implementeren of om projecten uit te voeren. Hierdoor is het aantal uit te voeren projecten niet gelimiteerd door de bedrijfscapaciteit.
Nadelen standaardmethode: Een standaardmethode is globaal voor veel bedrijven toepasbaar. Dat betekent dat het niet op alle punten naadloos in de organisatie past en er dus aanpassingen aan gedrag, cultuur en organisatie nodig zijn om de standaardmethode volledig toe te passen. Om deze reden worden ook vaak onderdelen van de gekozen standaardmethode weggelaten, waardoor de effectiviteit en efficiëntie van de methode negatief wordt beïnvloed.
De standaardmethode hoeft niet meer verder ontwikkeld te worden door het bedrijf zelf, dit gebeurt immers door de beherende instantie. Hierdoor is de noodzaak om actief met projectmanagement bezig te zijn minder groot. Het bedrijf ontwikkelt zich dan niet in volwassenheid rondom projectmanagement.
Als projecten niet goed lopen, dan wordt vaak gewezen op het disfunctioneren van de methode en wordt niet de hand in eigen boezem gestoken. Ook dan ontwikkelt het bedrijf zich niet in volwassenheid rondom projectmanagement.
Voordelen bedrijfsmethode: Is ontwikkeld door het bedrijf zelf, rekening houdend met de cultuur, organisatie, werkwijzen, werkgebied en behoeften van de organisatie. Het past dus naadloos in de organisatie en heeft een hoge acceptatiegraad bij het management.
De methode blijft binnen het bedrijf in ontwikkeling, dit betekent veel aandacht voor projectmanagement en bij het ontwikkelen van de methode groeit ook de volwassenheid van de organisatie.
Nadelen bedrijfsmethode: Is toegespitst op het bedrijf en nieuwe projectmanagers zullen volledig ingewerkt moeten worden in de methode.
Als het bedrijf verandert (cultuur, organisatie, werkwijzen, management, werkgebied) loop je het gevaar dat de methode niet mee verandert, waardoor de uitvoering van projecten minder efficiënt of effectief is binnen de vernieuwde organisatie.
Weinig flexibiliteit in capaciteit. Het aantal uit te voeren projecten wordt beperkt door de beschikbaarheid van kundige projectmanagers binnen het bedrijf.
Conclusie
Zoals altijd is er geen eenduidig antwoord te geven op de vragen die hierboven gesteld worden. Elk bedrijf moet voor zichzelf vanuit zijn eigen unieke positie de afwegingen maken die leiden tot een keuze. Ik hoop dat deze uiteenzetting een beetje helpt om voor jouw bedrijf de juiste keuze te maken.
Jammer dat dit een: “Het kan vriezen, het kan dooien” stukje geworden is waarbij de voor- en nadelen niet echt goed tegen elkaar afgezet worden.
Ik betwijfel zelfs of een voordeel als niet hoeven nadenken bij een standaard methodiek feitelijk niet gewoon een nadeel is. Dat maakt tenslotte van de projectmanager een procesmanager.
En genoemde nadeel bij (eigen) bedrijfsmethode lijkt me een voordeel omdat de projectmanager hier meer op vaardigheden en kennis functioneert dan een boekje.
@Wijnands, mooi overzicht. Als aanvulling op de voor- en nadelen, wil ik meegeven dat een zelf ontwikkelde bedrijfsmethode een nadeel kan zijn als het bedrijf bijvoorbeeld wil gaan uitbesteden of als deze een ketenpartner is en nauw moet samenwerken met anderen die de bedrijfsmethode niet kennen. Dan er zijn minder gezamenlijke begrippen en dergelijke, wat kan leiden tot meer misverstanden of irritaties tussen de partners. De begrippen en modellen van de standaardmethoden zijn tegenwoordig algemeen bekend.
Verder mis ik een punt van afweging. Een project is per definitie anders van aard dan een reguliere opdracht. Een project is éénmalig en niet alles kan uitgevoerd worden op basis van eerder opgedane ervaring, et cetera. De gekozen methode moet dan ook de mindset ondersteunen dat men aan een project werkt. Een not-invented-here gevoel over een gekozen methode, is risicoverhogend. Dat betekent dat een gekozen standaardmethode redelijk goed moet aansluiten bij de bedrijfscultuur, dan wel dat de organisatie eerst vertrouwd gemaakt moet worden met de methode. Dan krijgt de methode niet zo snel de schuld (zoals je schreef, je moet hand in eigen boezem kunnen steken).
@Ewout, volgens mij weet je ook wel dat echte bedrijfsmethoden net zo goed in een boekje staan. En bij sommige multinationals zijn de beschrijvingen ervan ook nog eens erg omvangrijk.
John,
Uiteindelijk zijn standaard methodieken commercieel gemaakte bedrijfsmethodieken. Begrippen en jargon als argument gebruiken duidt dan meer op beroepsdeformatie dan een zinvolle invulling. Want als communicatie het probleem is dan vraag ik me af of het paard niet achter de wagen gespannen wordt.
@Ewout,
“Begrippen en jargon als argument gebruiken duidt dan meer op beroepsdeformatie dan een zinvolle invulling.”Wat is er tegen betere communicatie met mensen die gewend zijn om een ander jargon te gebruiken dan jij en een ander begrippenkader hebben? Slechte communicatie kan schijnproblemen opwekken (zie ook mijn laatste punt) en echte problemen juist maskeren. ICT is ten slotte vooral mensenwerk. Over beroepsdeformatie gesproken.
“Want als communicatie het probleem is dan vraag ik me af of het paard niet achter de wagen gespannen wordt.” Nee, het gaat niet om communicatie als probleem, maar om het voorkomen van problemen. Zo blijkt in de praktijk dat voorlichting en eventueel kleine aanpassingen van definities en het net anders benoemen van zaken, als smeerolie werkt.
Ewout, je schrijft dat collega Wijnands een “Het kan vriezen, het kan dooien” stuk heeft geschreven. Die mening mag je hebben, maar lever dan de argumenten en verbeter e.e.a. als je dat kan. Maar fingeer daarbij niet wat de ander geschreven zouden hebben.
Bijvoorbeeld Wijnands schrijft “Hierdoor hoeft er binnen het bedrijf zelf MINDER nagedacht te worden over de praktische invulling van projectmanagement.”Jij maakt er van “…een voordeel als NIET hoeven nadenken bij een standaard methodiek…”
Dat is inhoudelijk toch heel wat anders. QED
John,
Dat ik in mijn reactie chargeer, het scherper stel dan er geschreven staat is goed opgemerkt maar vergeet dan niet de boodschap. Want juist met gegeven argumenten wordt de projectmanager een procesmanager, een schakel in plaats een leider.
En stellen dat communicatie problemen voorkomen kunnen worden door eerst voorlichting te geven en definities aan te passen lijkt me toch echt het paard achter de wagen te spannen:
1. Je moet eerst alle projectleden, stakeholders en opdrachtgevers trainen.
2. Bij herdefinieren maak je een van de standaard afgeleide bedrijfsmethodiek.
Misschien allemaal te billijken als je een projectorganisatie hebt maar dat is weer in tegenspraak met je opmerking dat een project een eenmalige gebeurtenis is. Wordt het de dagelijkse praktijk dan zitten we alweer gauw in een (herhaalbaar) proces.
Dus ja, het kan vriezen of dooien lijkt me nog steeds de beste voorspelling.
@Ewout, volgens mij gaf Wijnand gewoon aan dat je altijd moet nadenken bij de keuze voor een methode. Hij gaf daarbij enkele overwegingen mee. Dat is en blijft echt heel wat anders dan “het kan vriezen of dooien”; hoe je er ook omheen draait.
Overigens een projectmanager moet niet alleen een leider zijn, maar ook een analist, procesmanager, een planner, een communicator, et cetera. Een projectmanager die niet een schakel wil zijn, is niet meer dan idiote solist die hoopt dat er aan het einde van de rit nog volgelingen zijn die willen helpen om anderen de schuld te geven. Zo’n solist kan geen relaties met anderen ontwikkelen, geen informatie met anderen delen, geen beslissingen met anderen nemen, geen mensen positief beïnvloeden, et cetera. Kijk naar die mislukte leiders uit de financiële wereld. Ze komen niet verder dan JBF.
Verder adviseer ik je om meer in PM te verdiepen. Een project heeft per definitie een eenmalig karakter, ondanks de gemeenschappelijke delers met andere projecten en met reguliere productie, die dan weer tot GBV, standaard- en bedrijfmethoden kunnen leiden.
Sorry John,
Door te stellen dat een projectmanager een manusje van alles moet zijn doe je m.i. afbreuk aan je eigen verhaal. Die vaardigheden leer je nl. niet met de methodieken, kan het weten want zelfs daarin ben ik gecertificeerd. Nu ben ik ook van mening dat een projectmanager een project(team) moet leiden, niet het zelf in eigen persoon zijn.
Ervaring met projectmanagers die het zelf beter denken te weten is nl. dat dit meestal de solisten zijn, zeg maar jouw voorbeeld uit financiele wereld. Goed dus in ‘Excel management’ maar niet echt excelleren op het resultaat. En ongeacht de methodiek die je hanteert gaat het bij projecten uiteindelijk daarom.
Lees ook nog eens mijn reactie die ik bij andere discussies gegeven heb. Want zolang percentage succesvolle projecten, ondanks alle methodieken niet is toegenomen blijft de keus meer gevoel dan feit.
P.S.
Als richtlijn heb ik er niets op tegen, als religie ageer ik er tegen.
@Ewout, nu snap ik een beetje welke allergie je hebt en waar deze je hindert.
Van geloof moet ik ook weinig hebben en ook heb ik PM certificaten, net als vele duizenden anderen. Laat me echter liever niet door allergieën leiden.
De meeste projecten – en niet alleen die in de ICT – mislukken geheel of gedeeltelijk. Maar 1/5e deel wordt binnen tijd en budget opgeleverd. Een juiste keuze voor een PM methode/methodiek is maar één van de succesfactoren die tot een succesvol afgerond project leiden. De opdracht moet SMART geformuleerd zijn. Je moet de juiste mensen hebben. Instrumentgebruik moet niet te krap, maar zeker ook niet te ruim worden ingezet; a fool with a tool is still a fool. Commitment /draagvlak is ook cruciaal. Controle daarop ook, want actoren van de zijde van zowel de opdrachtnemer als van de opdrachtgever, hebben vaak hun eigen redenen om een project te rekken, of om een fase niet af te ronden. Door projectsaboteurs wordt Prince2, Prince In Name Only, dijt een project uit tot een programma binnen een programma, kan een project stilletjes een volstrekt andere opdracht krijgen, et cetera.
Ben het niet eens met je “manusje van alles” opmerking. Werkzaamheden moet je als projectmanager zoveel mogelijk delegeren, maar geen management taken zoals het aansturen van informatiestromen, van mensen en van het maken van afspraken. Als je dit soort taken bij anderen plaatst, dan ben je niet zozeer bezig met het leiden van het project, maar met het baas spelen over een staf die het project moet managen. Voor die taken /taakjes, heb je ook voldoende tijd als je de teamleden hun werk laat doen.
Kom zelf uit het tijdperk dat Prince nog ontwikkeld moest worden en velen nog dachten dat kennis van een ontwikkelmethode voldoende was om een project te kunnen leiden. ICT-opleidingen waren beperkt, infrastructuur dito en vaak instabiel. We werkten zonder een uitgewerkte PM methode, en al zeker niet volgens een internationale standaard. Opdrachtgevers snapten niet de consequenties van hun eigen opdracht. Desondanks deden we het niet veel minder dan de nieuwste generatie ICT-ers met al die nieuwe mogelijkheden.
Dat het percentage succesvolle projecten de laatste decennia niet gestegen is, ligt niet zozeer aan de PM methode. In 9 van de 10 keren heeft de projectorganisatie gefaald, waarbij 1 op de 3 keer het projectmanagement zelf (van de ene en/of de andere zijde). Het gaat om menselijk falen dus. Daar kan men van leren, maar dat gebeurt meestal alleen op individueel niveau en zelden op organisatieniveau. Kennismanagement binnen organisaties wordt gefrustreerd door reorganisaties en fusies. Ervaren mensen worden vervangen door nieuwelingen die in dezelfde valkuilen stappen omdat ze te weinig begeleid worden. Junior PMs komen vaak op te moeilijke opdrachten vanwege de verkeerde tarievenring, enz. Dat lijkt veel op de rest van onze maatschappij, niet?
John,
Naast menselijk falen zijn er nog wel wat redenen voor mislukking aan te dragen. Een factor die volgens mij altijd een grote rol speelt is de ‘politiek’ welke met cultuur en dus indirect ook met mensen te maken heeft. Het verwachtingsmanagement wat misschien weer goed aan sluit bij je laatste vraag.
Kennismangement is trouwens weer een andere discussie, het proberen te vangen hiervan in methodieken lijkt me namelijk een kansloze exercitie. Ervaring leer je namelijk niet uit boeken maar verkrijg je door vaak je neus te stoten. Dat gezegd hebbende ben ik nu wel benieuwd waarom auteur niet deel neemt aan deze discussie.
@Ewout, sabotagepolitiek en -cultuur behoren tot de bekende factoren van menselijke falen door projectmanagement en organisatie. Die aandachtspunten zouden in het verwachtingsmanagement meegenomen moeten worden, zoals elke PM-methode voorschrijft. Heb pakweg een dozijn PM cursussen gehad en er werd altijd aandacht geschonken aan verwachtingsmanagement aan de hand van praktijkvoorbeelden. Maar in de praktijk het gebeurt amper. Een paar zinnen in een PM document en dat is het dan.
Heb jaren bij een bedrijf gewerkt waar verwachtingsmanagement serieus werd opgepakt. Niet toevallig was kennismanagement daar belangrijk, want een groot deel van de winst werd in de maakindustrie verdiend. Dan is het behouden van opgedane ervaring via kennismanagement onmisbaar. Men vergeet helaas dat kennismanagement de basis is van de ontwikkeling van allerlei methoden en best practices in en buiten de ICT.
Een ISO certificaat is tegenwoordig meer een marketinginstrument, en niet bedoeld voor te leveren kwaliteit.