Al een aantal jaren ben ik werkzaam als projectmanagementprofessional. Dat doe ik enerzijds in de rol van interim projectmanager, en anderzijds in de rol van adviseur. In die laatste rol ben ik betrokken bij het (verder) optimaliseren van projectmanagementorganisaties en -processen bij opdrachtgevers.
Net als vele anderen groeide ik op met SDM en Prince2, om na verloop van tijd te ontdekken dat er een mooie aanvulling op Prince2 bestond, genaamd PMBoK. Tijdens het implementeren van projectmanagementorganisaties en -processen bij opdrachtgevers hanteren we dan ook in de basis een combinatie deze twee aanpakken, aangevuld met maatwerk. Dat maatwerk zit aan de voorkant (hoe laten we business needs de initiators zijn voor projecten?), in de project governance (hoe realiseer ik de benodigde betrokkenheid van ‘de business’ en het bijbehorende eigenaarschap?), en aan de achterkant (hoe realiseren we daadwerkelijk business benefits met onze project deliverables?). Tenslotte, en dat is misschien wel het leukst van alles wat ik doe, word ik regelmatig gevraagd om (beginnende) projectmanagers te begeleiden en te coachen.
Containerbegrip of methode?
De laatste tijd is er veel aandacht voor ‘Agile’. En net zoals ik op enig moment PMBoK ben gaan omarmen (naast mijn eerste liefde Prince2), zo ben ik mij als onafhankelijk projectmanagement professional uiteraard ook gaan verdiepen in Agile. Dat was in eerste instantie nog niet zo eenvoudig. Want als ‘ze’ ergens in geslaagd zijn, dan is het wel in het optrekken van een mistgordijn rondom Agile. Want is Agile nou een containerbegrip of een methode?
Om het gemakkelijk te maken luidt het antwoord op deze eenvoudige vraag: beide. Eerst het containerbegrip. Agile is de verzamelnaam voor een cluster van projectmanagementmethodes die vanuit een zelfde filosofie en visie zijn opgebouwd. Zo hanteert Agile als vertrekpunt, in tegenstelling tot (laten we ze gemakshalve maar even zo noemen) de traditionele methoden, dat niet de scope van het project vaststaat, maar dat tijd en geld vaststaan. Binnen die vastgeklikte tijd en geld constraints, wordt gekeken wat er aan scope (‘features’) gerealiseerd kan worden…
Deze filosofie wordt duidelijk wanneer we het concept van de binnen Agile-methodes gehanteerde time-boxes nader bekijken. Time-boxes zijn vooraf gedefinieerde ‘tijdseenheden’ (meestal 2-4 weken) waarbinnen ‘iets opgeleverd moet worden’. Lukt dat niet, dan wordt niet getornd aan de time-box of het beschikbare budget, maar dan wordt datgene opgeleverd, wat wél haalbaar is. Dit is hetgeen dat vooraf geprioriteerd is met behulp van de MoSCoW-aanpak: Must have, Should have, Could have en Won’t have-right-now. Een resultaat bestaande uit enkel Must haves, is een resultaat waarmee de business in ieder geval vooruit kan: fit for purpose.
Een ander in het oog springend kenmerk van Agile-methodes is het ogenschijnlijke gemis aan ‘command and control’ zoals we dat kennen vanuit de (komt-ie weer:) traditionele methodes. Daarvoor in de plaats predikt Agile ‘empowerment’ van de projectteams en een ongekende dosis wederzijds vertrouwen tussen enerzijds de opdrachtgever en de projectmanager en anderzijds de projectmanager en zijn teams. Deze teams bestaan in de Agile filosofie uit zowel de business als de it en gaan samen producten (‘deliverables’) ontwikkelen. Om dit te bewerkstelligen, vraagt Agile om een specifieke ‘mindset’ van de betrokkenen, zowel business als it. Dit is slechts een kleine greep uit de kenmerken van Agile, en daarmee uit de verschillen tussen Agile en de traditionele methoden.
Veel Agile-methoden zijn voortgekomen uit de frustraties die ontstonden als gevolg van mislukkende ‘waterfall’- projecten. Deze aanpak, bij velen ongetwijfeld bekend, beschrijft een getrapte aanpak van software ontwikkeling: van behoeftebepaling, via analyse, ontwerp, bouw en testen, naar ingebruikname. Een aanpak waarbij de gebruikers aan het begin van het traject mogen vertellen wat ze willen en op het einde van het traject verblijd worden met een uitkomst, die vaak alweer achterhaald is… Zo’n aanpak werkt anno 2015 niet meer (voldoende). En dus kwam de industrie met alternatieven zoals Scrum, RUP en XP. Stuk voor stuk methoden die op incrementele en iteratieve wijze, in een samenspel tussen bouwers en gebruikers, stapsgewijs stukken software vrij geven voor ingebruikname. Stuk voor stuk voorbeelden van specifieke Agile-methoden.
DSDM, Atern en AgilePM
Naast de drie genoemde methoden is er één methode, die pretendeert niet specifiek voor software ontwikkeling bedoeld te zijn, namelijk DSDM, later Atern, inmiddels AgilePM genoemd, of simpelweg… Agile. Ziedaar, ‘Agile’ toegepast voor de specifieke methode en als containerbegrip (volg je het nog?). Dus: AgilePM, of kortweg Agile, is een voorbeeld van een Agile projectmanagementmethode. Maar dan eentje ‘voor algemeen gebruik’. En dus vragen veel bedrijven zich inmiddels af: moet ik nog wel in Prince2 (of PMBoK) blijven investeren, of moet ik radicaal over naar AgilePM?
Nee, we moeten zeker niet ‘en masse’ over naar AgilePM. Omdat het mijn stellige overtuiging is dat het gebruik van AgilePM in zichzelf nog geen garantie is voor succesvollere projecten dan Prince2 of PMBoK. Waarom ik dat denk? Om te beginnen, omdat AgilePM nou eenmaal die stevige footprint in de softwareontwikkeling heeft. Dat het daar beter werkt dan traditionele waterfall methodes, daar twijfel ik geen seconde aan. Maar dat AgilePM ook per se succesvoller is (dan Prince2 of PMBoK) bij de migratie van jouw datacenter van de ene sourcingspartner naar de andere, dat moet de praktijk nog uitwijzen.
Doorslaggevend daarin gaat het volgende aspect zijn: naast de specifieke projectinhoud, speelt de projectmanagement-volwassenheid van jouw organisatie een nog veel belangrijkere rol. Nee, nee, ik ga hier geen lans breken voor scans en volwassenheidsniveau-metingen, maar in algemene zin geldt dat de ene organisatie PM-volwassener is dan de andere. Dat de ene organisatie projectmanagement méér als primair bedrijfsproces beschouwt dan de andere. Dat in de ene organisatie de business zich meer bewust is van haar rol en verantwoordelijkheden binnen projecten, dan in de andere. Mindset, weet je nog? Welnu, het is met name deze projectmanagement-volwassenheid, die mij sterkt in mijn geloof: AgilePM is (nog) niet voor iedereen weggelegd.
Roeland Ravesteijn is managing partner bij Aranea, adviseur project- en programmamanagement, docent bij diverse hogescholen en honorary lecturer aan de Universiteit van Liverpool
Vanuit de IT bekeken heb je aan een verzameling van methodieken weer niet zo veel omdat je je dan eerst als PM of PL een nieuwe materie eigen moet gaan maken en dat terwijl de gehanteerde methodieken vaak nog niet eens fatsoenlijk zijn uitgenut.
Die weerzin komt vanuit het gegeven waarom je eigenlijk telkens weer iets moet gaan bedenken dat een veel grotere impact heeft dan simpelweg met een ‘soort van Lean’ het bestaande verbeteren voor de organisatie. Immers, de ene organisatie is de ander nu eenmaal niet en het is dan ook maar weer telkens de vraag of er uiteindelijk een toevoegend niveau word bereikt.
Lineariteit vs Dynamiek
Het probleem IT en de rest van de wereld is altijd dezelfde gebleven. En daar liggen dan weer de wetmatigheden aan ten grondslag die sinds de weefmachine nog steeds volkomen onveranderd zijn. Ga je daar aan tornen dan is dat garantie voor heel veel hele hoge rekeningen.
Dit laatste niet omdat ik daar telkens op wijs, voor waarschuw, maar omdat het nu eenmaal steeds weer praktijk is.
Scalability, Adaptability
Voor je weer een nieuwe, vaak commercieel geschoeide, methodiek promoot, zou je eerst eens naar de praktijk moeten kijken en wat blijkt, heel erg vaak? Dat mens zijn zo een eigen dynamiek heeft. Mensen willen vaak niet veranderen en als je het hebt over project management, dan is dat voor heel veel mensen een andere planeet, net als IT dat voor heel veel gebruikende mensen is.
De truc, tenminste, dat is mijn bescheiden ervaring telkens, is de bestaande methodieken, wanneer nodig en wenselijk, meer te actualiseren en daarna deze schaalbaar en meer toepasbaar maken voor organisatie en verschillende stromen binnen die organisatie.
Dan win je telkens weer aardig zonder al te rigoureuze gevolgen die dan weer een aparte dynamiek binnen een organisatie met zich mee brengt.
My 2bit
“DSDM, later Atern, inmiddels AgilePM genoemd, of simpelweg… Agile”
of toch maar PRINCE2 of PMBok ? Wrom trouwens nie PRiSM met lean en six sigma met wat XP/RAD/RUP erbij ? Zo’n Agile footprint, wijzigt die ook na elke sprint ? Haha op je PM schreden terug komen..
Boeit ook eigenlijk niet, als het mis gaat zeg je als PM dat de organisatie nog niet volwassen genoeg was 🙂