Een korte geschiedenis van projectmanagement

Projecten zijn zo oud als de mensheid en het realiseren van grootse bouwwerken zoals de Piramides van Egypte, de Chinese Muur, de Borobudur tempel op Java of het Paleis op de dam moeten georganiseerd hebben plaatsgevonden. Helaas is er weinig bekend van hoe de organisatie van dergelijke werk geregeld was of welke technieken er voor het management van deze projecten gebruikt werden.

Modern projectmanagement

Verschillende auteurs (1) vinden dat modern projectmanagement ergens is gestart begin 20e eeuw. Sinds die tijd is er wel documentatie van de werkwijze bij projecten. Bekende projecten uit de recente geschiedenis waarbij er duidelijke ontwikkelingen te zien zijn in het vakgebied komen vooral uit de Verenigde Staten.

Tot de jaren vijftig zijn dit projecten die vooral over de bouw van infrastructuur gingen (de bouw van fabrieken, steden, rails, havens, wegen en telecommunicatiemiddelen). Bekende voorbeeldprojecten uit die tijd zijn onder andere de bouw van de Hoover Dam (1936) en het Manhattan project (1945) (5). In de periode daarna tot medio jaren tachtig zijn bekende projecten het Apollo project van de NASA en het Polaris project (het bewapenen van onderzeeërs met kernrakketten) van de U.S. Navy.

Grote en snelle ontwikkelingen

Na de jaren tachtig barst de informatietechnologie-revolutie los met grote en snelle ontwikkelingen op hard- en softwaregebied. De veranderingen zorgen ervoor dat er veel projecten starten. Daarnaast biedt de nieuwe informatietechnologie nieuwe mogelijkheden om projecten te gaan managen: de hulp van software bij de communicatie, het plannen en beheersen van een project.

De opkomst van Scrum en Agile

Daarnaast ontstaan er ook nieuwe uitdagingen. Vooral bij het ontwikkelen van software blijken de oude technieken van projectmanagement te star. Waarbij het bouwen van infrastructuur en ‘harde’ tastbare resultaten het nuttig bleek om vooraf een goed ontwerp te maken is het bij het bouwen van software nodig om tijdens de bouw het ontwerp te kunnen wijzigen. Software is nooit af en verandert in de loop van de tijd. Denk aan alle versies van bijvoorbeeld Windows die er de afgelopen jaren zijn ontwikkeld. En die ontwikkeling loopt nog steeds door.

Extreme programming en Scrum

Planning game cards

Vanuit die gedachte zijn rond de jaren 90 iteratieve projectmanagement methodes ontwikkeld zoals Extreme Programming en Scrum. Pas na 2000 is de verzamelnaam agile in gebruik geraakt voor deze en nog een aantal nieuwe methodes die uitgaan van de basisprincipes zoals verwoord in het Agile Manifesto (6).

Agile Manifesto

Belangrijke pijlers van het manifest zijn onder andere: werken in relatief kleine groepen met de nadruk op intermenselijke communicatie, het opleveren van het project in relatief kleine delen waarbij er na elke oplevering besloten wordt om het ontwerp en de werkplan aan te passen. Daarbij wordt er gewerkt in relatief korte tijdframes van in de regel niet meer dan een paar weken per iteratie. In Scrum heet zo’n iteratie een ‘Sprint’.

Agile voor geen ICT projecten

Vervolgens werd er in de periode na 2010 ontdekt dat Agile ook goed toegepast kan worden in projecten die niet over softwareontwikkeling gaan (zie bijvoorbeeld (7) en (8)). Agile werken vond zijn weg naar onder andere communicatieprojecten, marketing, HR, binnenhuisarchitectuur, projecten in de zorg en in het onderwijs.

Grotere groepen

In de oorspronkelijke Agile methodes werkt men het liefst in relatief kleine teams van niet meer dan ongeveer 10 personen. Bij veel organisaties en grote projecten lukt dat niet met zo’n klein team. Denk aan het wijzigen van software op honderden werkplekken bij een belastingdienst of het op de markt brengen van een nieuw product in honderden landen.

Raamwerk

Omdat sommige projecten nu eenmaal om de inzet van meer mensen vragen zijn vanaf de periode 2010 raamwerken bedacht om met grotere groepen mensen toch nog ‘agile’ te kunnen werken. Bekende scaled agile raamwerken zijn onder andere SAFe, LeSS, Spotify, Scrum at Scale en Nexus (9). Ook wordt er geëxperimenteerd met zogenaamde ‘hybride’ methodes waarin men traditionele structuren met een agile aanpak combineert (10).

Concluderend

Kijkend naar de jonge geschiedenis van modern projectmanagement dan heeft het een sterke oorsprong in engineering: het bouwen van min of meer technische objecten. Projecten gaan allang niet meer alleen over het bouwen van harde objecten zoals infrastructuur, ze gaan over het inrichten van nieuwe bedrijfsprocessen, over het bouwen of implementeren van informatiesystemen, over het veranderen of realiseren van nieuwe organisatieonderdelen.

Maar ook over – pogingen tot – het veranderen van gedrag van mensen zoals het klantvriendelijker maken van een afdeling. Of zelfs het ontwikkelen of uitdragen van visies kunnen onder de noemer van ‘projecten’ vallen. Het moge duidelijk zijn dat deze voorbeelden op een schaal van heel ‘harde’ naar zeer ‘zachte’ projecten lopen.

Oorspronkelijke technieken beter of slechter?

Opmerkelijk genoeg wordt in de vele projectmanagement opleidingen, boeken en certificeringen die er beschikbaar zijn veel teruggegrepen op de oorspronkelijke technieken van projectmanagement die ooit bedacht zijn voor engineering. Maar werken die technieken nog wel? Het bouwen van een wolkenkrabber in de jaren 30 is een heel ander project dan het ontwikkelen van nieuwe medicijnen anno 2022.

Agile versus traditioneel

Een van de vragen die nu regelmatig gesteld wordt en ook onderwerp is van soms felle discussies op de diverse online forums is: is Agile een betere methode dan de traditionele aanpak? De consensus is dat Agile en ‘traditioneel’ projectmanagement beide hun plek hebben: softwareprojecten heeft meestal de voorkeur voor Agile, het bouwen van een viaduct niet.

Boeken over projectmanagement

Maar de vraag welke methode het beste bij welke soort project gaat veel verder dan het onderscheid tussen Agile of traditioneel. Eigenlijk zou je per techniek moeten kijken in hoeverre die werkt of niet: heb je bij project X wat aan een gannt chart? Heb je bij project Y wat aan een fasering, en zo ja welke fasering? Welke mate van controle is wenselijk en haalbaar bij project Z?

Geciteerde werken:

  1. The History of Project Management. Seymour, Tom Joseph. sl : International Journal of Management & Information Systems, 2014, Vol. Volume 18, Number 4.
  2. Kwak, Y.H. en Anbari. The Story of Managing Projects by Carayannis. [boekaut.] Anbari. The Story of Managing Projects by Carayannis. sl : Quorum Books, 2003, Vol. Chapter 2.
  3. Kent Beck, James Grenning, Robert C. Martin, e.a. Manifesto for Agile Software Development. Manifesto for Agile Software Development. [Online] 2001. https://agilemanifesto.org.
  4. Ruler, Betteke van. Reflectieve Communicatie Scrum. Reflectieve Communicatie Scrum. Amsterdam : ADFO Groep, 2013.
  5. de Boer, Petra, Bruggink, Martin en e.a. Scrum In Actie. Scrum In Actie. sl : Business Contact, 2015.
  6. Portman, Henny. Scaling Agile In Organisaties. Scaling Agile In Organisaties, wegwijzer voor Projectmanagers en Agile Leaders. Houten : Van Haren Publishers, 2017.
  7. Baars, Wouter. Project Management Handbook. Project Management Handbook. The Hague : DANS, 2006.
  8. Weggeman, Mathieu. Essenties van Leidinggeven Aan Professionals. Essenties van Leidinggeven Aan Professionals. Schiedam : Scriptum, 2021.
  9. P. Zuiker, Ernst Harting. Projectmatig Creeren 2.0. Projectmatig Creeren 2.0. sl : Scriptum Books, 2006.
  10. Gert Wijnen, Peter Storm. Projectmatig werken. Projectmatig werken. sl : Spectrum, 2009.
  11. Wikipedia. PRINCE2. Wikipedia. [Online] 19 Maart 2021. [Citaat van: 5 Mei 2021.] https://nl.wikipedia.org/wiki/PRINCE2.

Leave a Reply

Je e-mailadres zal niet getoond worden. Vereiste velden zijn gemarkeerd met *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>