PrOJect POrtfOlIO ManageMent Met een agIle-Insteek

Managen vanuit de kernwaarden en principes van Agile
Project Portfolio
Management
met een Agile-insteek
Het gedachtegoed van Agile vormt een waardevolle aanvulling voor de theorie en praktijk van Project
Portfolio Management (PPM). Agile Project Portfolio Management (APPM) zijn we in de praktijk echter nog
niet tegengekomen en ook in de theorie is het nog niet (goed) beschreven. Met dit artikel wil ik daarom een
fundament leggen voor verdere discussie over Agile en PPM. En dan heb ik het niet over het simpelweg
managen van een projectportfolio met (alleen maar) Agile-projecten, want APPM is meer. Het projectportfolio kan hierbij onder andere uit Agile-projecten bestaan, maar dat hoeft niet. Een projectportfolio met
Agile-projecten is immers ook prima te besturen met ‘gewoon’ PPM. Bij APPM gaat het erom dat het
projectportfoliomanagement mede gebaseerd is op de kernwaarden en principes van Agile.
P
rojectportfoliomanagement is het management van het
geheel aan programma’s en projecten binnen een
organisatie. Onder management versta ik in deze alle
zaken die komen kijken bij de besturing, het beleid, de
processen, de informatie, de mens (competenties en cultuur)
en de praktische organisatie (een PPM-bureau) van de
projectportfolio.
Voordat we de Agile-aanpak van PPM bespreken – of eigenlijk
het totnogtoe ontbreken van een uitwerking daarvan in de
literatuur –, gaan wij eerst dieper in op wat Agile is. Het
Engelse woord ‘agile’ betekent behendig of lenig.1 In de
softwareontwikkeling is het voor de eerste keer gebruikt als
naam voor een conceptueel raamwerk ten behoeve van het
projectmanagement.
auteur John van Rouwendaal ([email protected]),
project-, programma- en projectportfoliomanager
bij Arlande.
26
IPMA Projectie Magazine | 01-2012
Agile is formeel ‘geboren’ in 2001, in Utah (VS), als een
bepaalde set van waarden en principes ten behoeve van
softwareontwikkeling.2 ‘The Agile Alliance’ – bestaande uit
vertegenwoordigers van onder meer Extreme Programming,
SCRUM, DSDM, Adaptive Software Developement, Crystal,
Feature-Driven Development en Pragmatic Programming – tekende hier ‘The Agile Manifesto’ op.
Kernwaarden en principes
In dit manifest zijn de kernwaarden en principes vastgelegd die
het meest belangrijk worden geacht voor (software)projecten.
De vier kernwaarden zijn:
1. Personen en interacties (boven processen en tools).
2. Software die werkt (boven uitgebreide documentatie).
3. Samenwerking met de klant (boven contractonderhandeling).
4. Reageren op verandering (boven het volgen van een plan).
Werken vanuit het Agile-gedachtegoed komt neer op handelen
en denken vanuit twaalf principes:
1. De klant tevredenstellen door vroege en continue levering
van waardevolle software.
2. Veranderingen van requirements zijn welkom, zelfs laat in het
ontwikkelingsproces.
3. Frequent werkende software afleveren.
4. Businessmensen en ontwikkelaars dagelijks samenwerken
gedurende het project.
5. Projecten opbouwen rond gemotiveerde individuen.
6. De meest efficiënte en effectieve manier voor informatieoverdracht is face-to-face-conversatie.
7. Werkende software is de belangrijkste maatstaf voor
voortgang.
8.Agile-processen bevorderen voortdurende ontwikkeling.
9.Continue aandacht voor technische uitmuntendheid en
goed ontwerp.
10. Eenvoud – maximaliseren van niet gedane hoeveelheid werk
– is essentieel.
11. Zelforganiserende teams leveren de beste architecturen,
requirements en ontwerpen.
12. Het team reflecteert regelmatig over hoe het effectiever kan
worden en past zich dienovereenkomstig aan.
Agile onderscheidt zich van de als klassiek beschouwde
‘watervalontwikkelmethode’ doordat de nadruk ligt op het zo
snel mogelijk in korte overzichtelijke perioden (iteraties)
leveren van werkende sofware in plaats van eerst een lange
voorbereiding achter de tekentafel. Daarnaast wordt benadrukt
dat software ontwikkelen voor tachtig procent communiceren
is, met sponsors, met de business/users en binnen het team.
Agile in de praktijk
Het doorvoeren van Agile-waarden en -principes lost een aantal
praktische problemen op. Organisaties die om wat voor reden
dan ook niet in staat zijn om voorafgaande aan een ontwikkeltraject gedegen requirements op te stellen, kunnen daar
bijvoorbeeld met behulp van Agile-methodes gaandeweg het
proces wél aan toekomen. ‘Going agile’ kan ook helpen een
brug te slaan over de kloof die business- en IT-ontwikkelaars
vaak onderling ervaren.
Veel organisatie zijn vaak al gebaat bij het hanteren van een
beperkte set Agile-waarden en/of -principes. Helemaal Agile
gaan vereist een aanzienlijke investering in structuren en
culturen binnen een organisatie. De business case hiervoor is
dan ook niet altijd rond te krijgen. Net zoals mensen in de
sociale omgang enige ‘lenigheid’ moeten hebben, zo ook heeft
elke organisatie enige ‘agility’ nodig.
Invoering van Agile moet wel met overtuiging gebeuren, want
organisaties die eindigen als AINO (Agile In Name Only) doen
zichzelf te kort.
Is Agile PPM nieuw?
Ja en nee. APPM is nieuw aangezien voor de publicatie van dit
artikel bestond er nog geen gedegen fundament voor APPM. En
nee, APPM is niet nieuw, want er zijn weldegelijk pogingen
gedaan om APPM vorm te geven. Deze hebben echter niet het
gewenste resultaat opgeleverd. Hieronder enkele pogingen die
ten onrechte worden aangehaald als APPM.
Jochen Krebs
De eerste uitgebreide poging om Agile te vertalen naar PPM is
gedaan door Jochen Krebs in ‘Agile Portfolio Management’
(2009). Krebs hanteert een bottom-up-benadering en redeneert
‘project based’ en ‘development based’. Hij omschrijft Agile
Portfolio Management namelijk simpelweg als de link en
samenwerking tussen de business en Agile-ontwikkelteams. Hij
redeneert dus niet vanuit de gedachte dat je Agile-(project)
portfoliomanagement kan bedrijven, ongeacht de wijze waarop
ontwikkeld wordt. Dit strookt niet met de in de PPM-literatuur
heersende theorie dat je PPM dient te benaderen vanuit
businessoptiek, niet vanuit de projecten en al helemaal niet
vanuit softwareontwikkeling (onderdeel van of fase in projecten).
Krebs maakt in ‘Agile Portfolio Management’ nog een opmerkelijke sprong die sommigen zouden kunnen gebruiken om hem te
diskwalificeren als degene die APPM op de kaart heeft gezet. Hij
zet PPM af tegen twee andere vormen van portfoliomanagement,
namelijk: asset portfolio management en resource portfolio
management. Dit is niet gangbaar in de PPM-literatuur. Hij doet
PPM in ieder geval te kort door het te koppelen aan (IT) asset
portfolio management en positioneert het daarmee als ‘des IT’s’.
Deze positionering van Krebs betekent dat hij in zijn verhaal
niet diep kan ingaan op PPM. Uiteindelijk besteedt hij slechts
één hoofdstuk in zijn boek specifiek aan dit onderwerp.
Daarmee is zijn verhaal op dit punt erg oppervlakkig gebleven.
Robert K. Wysocki
In ‘Effective Project Management’ (2009; 5de editie) en
‘Executive’s guide to project management’ (2011) wijdt Wysocki
respectievelijk een paragraaf en twee hoofdstukken aan APPM.
Vergeleken met gewoon PPM noemt hij als enige verschil dat bij
APPM informatie over de lopende projecten input oplevert voor
het samenstellen van de projectportfolio. Bij PPM wordt
volgens hem eerst de strategic alignment gecontroleerd. Klopt
dit, dan krijgt het project een prioriteit toegekend en wordt het
vervolgens ‘selected’ (opgenomen in de projectportfolio).
Financiering is dan zeker, maar nog niet toegekend. Zodra die
rond is, wordt het project ‘active’ (lopend project).
Bij gewoon PPM ziet Wysocki alleen een lijntje van ‘selected’
naar ‘active’. Bij APPM tekent hij ook een pijltje van ‘active’ naar
‘selected’ en van ‘active’ naar het proces waaraan prioriteiten
worden toegekend. Met andere woorden: Bij de samenstelling
van de projectportfolio zou APPM wel rekening gehouden met
de lopende projecten en bij PPM niet. Zowel ‘The Standard for
Portfolio Management’ van het PMI3 als het ‘Management of
Portfolio’s’ van OGC4 gaan er echter vanuit dat je dit wel doet.
Daarnaast komt het simpelweg niet logisch over. Bij PPM neem
je toch altijd alle mogelijk informatie mee, en zeker die over je
lopende projecten. Wysocky biedt met zijn visie, net als Krebs,
dus geen solide basis om van ‘PPM met een daadwerkelijke
Agile-insteek’ te kunnen spreken.
In de ‘Executive’s guide to project management’ besteedt
Wysocki meer aandacht aan wat hij betitelt als APPM. Dit
definieert hij als volgt: “Agile portfolios are those whose
contents can change at regular intervals to take advantage of
market shifts, competitor actions, as well as the learning and
discovery that takes place among its current projects and newly
proposed projects”. Fraai aan deze definitie is de nadruk op
omgevingsvariabelen die aanpassing van de projectportfolio
kunnen veroorzaken, maar opmerkelijk is dat je hier het woord
Agile prima kunt weglaten. Aan zijn definitie (en zijn uitwerking
daarvan) is weinig Agile’s te ontdekken. Dit wordt nog eens
extra duidelijk als hij schrijft: “Agile refers to the contents of the
portfolio and not to the type of projects in the portfolio.”
Daarmee komt de aap uit de mouw. Hij wijkt af van wat de rest
van de wereld tegenwoordig verstaat onder ‘Agile’, namelijk
overeenkomstig een vastgestelde set van Agile-waarden en
-principes. Wysocky gebruikt agile hier in de vrij letterlijk zin
van ‘lenig’ of wat men voordat deze term in de mode raakte
waarschijnlijk betitelde als ‘flexibel’. Kort en krachtig een prima
uiteenzetting van ‘gewoon PPM’, maar degene die verder willen
met APPM zijn hiermee wederom niet geholpen.
>
01-2012 | IPMA Projectie Magazine
27
Johann Rothman
Een bekend pleitbezorger van Agile-benaderingen voor
projectmanagement en PPM is Johanna Rothman. Haar boek
‘Manage your project portfolio’ (2009) staat bol van de
aansporingen om vooral veel lean- en agile-werkwijzen te
adopteren. Bovenal biedt haar boek veel pragmatische
handvatten om met PPM aan de slag te gaan. Frappant is echter
dat Rothman Agile wel heel erg eng definieert, namelijk: “Agile
thinking is the frequent – no more than four weeks – release of
valuable chunks of product.” Dit resulteert op het eerste
gezicht dan ook in niet meer dan een uitleg van hoe de bij
Agile gebruikelijke techniek van iteratief werken te vertalen is
naar projectportfolio’s. Een zeer beperkte interpretatie van
Agile en de vertaling daarvan naar PPM. Alsof ze uit een doos
vol Agile-bonbons er maar eentje eet en de rest weggooit.
Anderen
In literatuur over het management van Agile-projecten5 wordt
hier en daar PPM aangestipt, maar de optiek is primair ‘project
based’. Als het hier al over Agile en PPM gaat, dan gaat het over
het management van een projectportfolio met Agile-projecten.
Een pleidooi voor het toepassen van Agile-waarden en
-principes op PPM hoeft uit deze hoek niet te worden verwacht.
Agile leidraad bij PPM
Agile projectportfoliomanagement (APPM) betekent dat bij het
inrichten en verrichten van PPM ook de vier kernwaarden en
twaalf principes van Agile gehanteerd worden als leidraad voor
het maken van praktische keuzes. Voor elke organisatie zal dit
anders uitpakken. Immers, PPM kent wel methodische
richtlijnen, maar moet altijd organisatiespecifiek worden
uitgewerkt. Hieronder geef ik een indicatie van wat de gevolgen
kunnen zijn van de Agile-kernwaarden voor PPM.
Personen en interacties
Bij implementatie van PPM wordt vaak ten onrechte gekozen voor
een ‘toolbased’ implementatieaanpak. De redenering is dan dat
het allemaal goed komt als de zwaarst mogelijk PPM-tool de
organisatie wordt binnengefietst. Iedereen kent wel de voorbeelden van mislukte trajecten waarbij het idee was dat de hele
organisatie opeens met complexe softwaretools en via ingewikkelde processen moest gaan werken. ‘Garbage in, garbage out’ en
overbureacratisering is dan meestal het gevolg, waardoor PPM kan
eindigen als het kind dat met het badwater wordt weggegooid.
Als van begin af aan ‘personen en interacties’ boven ‘processen
en tools’ staan, zullen zulke fouten niet gemaakt worden. Dan
wordt eerst PPM geïmplementeerd, met eenvoudige ondersteuning. Op basis van de behoeften van personen en hun
interacties worden vervolgens processen ontworpen en gaat
men een tool zoeken. Het oude adagium ‘eerst organiseren, dan
automatiseren’. Dit adagium erbij halen, wordt mensen vaak
niet in dank afgenomen. Door het ‘Agile’ te noemen kan
iedereen hier weer op een plezierige en moderne manier aan
worden herinnerd.
PPM dat werkt
Waar men het in de softwareontwikkelingshoek heeft over
‘software die werkt (boven uitgebreide documentatie)’, kan men
vanuit PPM geredeneerd spreken over ‘een projectportfolio die
resultaten oplevert (in plaats van oneindig veel projectdocumentatie)’. Het is veel belangrijker om resultaten/deliverables te
28
IPMA Projectie Magazine | 01-2012
kunnen oogsten, dan om een stapel perfecte Business Cases en
PID’s te hebben. En met de juiste mensen de juiste besluiten
kunnen nemen, is belangrijker dan het hebben van perfecte
portfoliorapportages en -processen. Uit dit principe vloeit
voort dat de organisatie gewoon moet beginnen met PPM en
vooral de aandacht moet richten op de resultaten die ze wil
bereiken met de projectportfolio. In de praktijk kristalliseren de
exacte informatie- en procesbehoeften zich dan later wel uit.
Samenwerking met de klant
Samenwerken met de klant is belangrijker dan contractonderhandeling. De klant van een projectportfolio is uiteindelijk het
topmanagement dat haar organisatiestrategie wil verwezenlijken met inspanningen in de lijn en operatie én door middel
van projecten. Maar PPM kent ook nog andere ‘klanten’.
Projectleiders vragen bijvoorbeeld informatie over de organisatiestrategie en besluiten van het topmanagement. Lijnmanagers
willen onder meer weten welke projecten wanneer welke
gevolgen voor hun operationele activiteiten kunnen hebben.
Afhankelijk van de inrichting van de organisatie zijn nóg meer
‘klanten’ te identificeren: Planning & Control, Architecten,
Informatiemanagement, Business Development, etc. Het is dan
de kunst om samenwerking zo in te zetten als fundament voor
PPM, dat je alle ‘klanten’ daadwerkelijk laat bijdragen aan het
managen van de projectportfolio. Dus niet managen vanuit een
ivoren toren op basis van ‘contracten’ (voortgangsrapportages,
Business Cases, PID’s, etc.). De resultaten van de projectportfolio moeten echt een gezamenlijke inspanning zijn. Dit is in de
praktijk nog een hele puzzel. Maar dit niet doen, maakt de kans
dat PPM tot een papieren tijger verwordt aanzienlijk groter.
Reageren op verandering
‘Reageren op verandering (boven het volgen van een plan)’.
Sommige organisaties vatten PPM helaas nog steeds op als slechts
een eenmaal per (boek)jaar terugkerende exercitie.6 ‘Er is budget
voor een afgebakende set aan projecten en andere zaken doen we
gewoon niet.’ Vanuit een control-optiek is dat niet verwonderlijk,
maar vanuit de business geredeneerd is het gekmakend. Prachtige
opportunities zouden dan moeten wachten tot de projectportfolio weer mag worden vastgesteld. Met de huidige time-to-market
is dit in veel sectoren niet houdbaar. Of projecten moeten worden
weggemoffeld in de dagelijkse operatie, hetgeen vanuit een
control-optie weer niet wenselijk is.
Adequaat en snel kunnen reageren op veranderingen dient
integraal onderdeel te zijn van PPM, en helemaal als je
enigszins ‘Agile’ wilt managen. Praktisch gezien betekent dit
bijvoorbeeld dat geen enkele business case als heilig te boek
mag komen te staan. Het kan echter ook leiden tot het
bedenken van spoedprocedures om vrijwel per direct projecten
te kunnen starten wanneer de markt dit vereist.
Agile principes en PPM
Werken vanuit het Agile-gedachtegoed betekent ook handelen
en denken vanuit twaalf principes. Ter illustratie bespreken wij
hier drie principes7 en hun mogelijke implicaties voor PPM.
Principe 5: Motivatie
‘Bouw projecten rondom gemotiveerde individuen.’ Een manier
om dit principe uit te werken in een PPM-context is het
vervangen van het woord ‘projecten’ door ‘projectportolio’. Het
devies is dan om PPM neer te leggen bij mensen die daarvoor
gemotiveerd zijn, hen daarbij te ondersteunen en het vertrouwen te geven dat het goed komt. Motivatie is een niet te
onderschatten noch te verwaarlozen factor bij PPM.
Als een lid van het topmanagement de projectportfolio in zijn/
haar portefeuille krijgt, maar niet gemotiveerd is daar wat van
te maken, dan is het onwaarschijnlijk dat het wat gaat worden.
Je hebt nu eenmaal ‘lijnmensen’ en ‘projectenvolk’. Degenen die
zich met PPM gaan bezighouden, moeten het wel leuk vinden.
Ze moeten er geschikt of zelfs voor ‘geboren’ zijn.
Zonder enthousiasme een projectportfolio te lijft gaan, kan op
een groter drama uitlopen dan zonder vuur de lijn managen.
De context waarin projecten plaatsvinden is doorgaans
dynamischer dan die van lijnactiviteiten, waardoor het heel
snel heel fout kan gaan. PPM vraagt dan ook om gemotiveerde
betrokkenen die dit dynamische en risicovolle speelveld leuk
vinden. De P van ‘Passion’ is één van de belangrijke P’s die PPM
kenmerken. Velen vinden deze term te Amerikaans, maar
iedereen zal erkennen dat enige passie wel handig is in de
functie van ‘CPO (Chief Project Officer)’ of projectportfoliomanager. Ook al heeft een organisatie haar zaakjes nog zo goed op
orde, helemaal ‘van 9 tot 5’ zal PPM nooit worden. Bovendien
kun je ongemotiveerde mensen oneindig ondersteunen, maar
het vertrouwen dat het goed komt met de projectportfolio
schenk je alleen aan iemand die laat blijken er wat moois van te
willen maken.
Principe 6: Face-2-face-conversatie
“Conversations are the seeds of change”, schrijft de Enterprise
Portfolio Management Council (EPMC, 2009) met betrekking tot
het belang van een sterke executive sponsor voor de implementatie van PPM-processen. Volgens de EPMC is het belangrijk om de
conversatie levend te houden en de ‘buzz’ op te bouwen die op
haar beurt het momentum opbouwt. Een erg actieve, gepassioneerde en betrokken sponsor kan extreem waardevol zijn bij het
levend houden van de conversatie. “What doesn’t gets talked
about, doesn’t get done” (Ford & Ford, 2002).
Agile benadrukt bovendien dat de conversatie niet alleen via
documenten, mails of mobiels moet plaatsvinden. Het is leuk als
de executive sponsor een ‘krulletje op een PID krabbelt’, maar
het is nog veel belangrijker dat deze persoonlijk langskomt om
een hart onder de riem te steken. De coach van een voetbalteam
zet zijn spelstrategie ook niet alleen maar even op de mail
richting de spelers. Face-to-face-conversatie is de meest
efficiënte en effectieve manier om informatie over te brengen.
Principe 11: Zelforganiserende teamsEen groot projectportfolio (meer dan honderd projecten) besturen, vereist het
opknippen van de besturing in deelportfolio’s, programma’s,
(regie)domeinen, buckets of hoe je het wilt noemen. Het is
ondoenlijk om in detail overzicht te houden over het verloop en
de samenhang van zo’n portfolio, en in één overlegorgaan alle
Business Cases, PID’s, voortgangsrapportages, exception
reports, etc. te bespreken. Werkverdeling is nodig, zodat het
topmanagement zich kan focussen op de hoofdlijnen van de
projectportfolio en managementlagen daaronder zich kunnen
toeleggen op het managen van deelportfolio’s. De besturingslaag tussen het topmanagement en de stuurgroepen van
individuele projecten moet dan natuurlijk ook echt iets te
managen hebben. Deze (middenkader)managers moeten van
het topmanagement voldoende mandaat (marges) en handvaten (strategische criteria) krijgen om als team binnen bepaalde
kaders zelfstandig een deelportfolio te kunnen organiseren en
besturen. Zij moeten daartoe bijvoorbeeld stuurgroepbesluiten
ongedaan mogen maken, duidelijk weten op basis van welke
strategiecriteria zij hun deelportfolio moeten afbakenen en niet
voor elke nieuwe projectbrief naar het topmanagement hoeven.
Het elfde prinicipe van Agile gaat er vanuit dat de beste
architecturen, requirements en ontwerpen voortkomen uit
zelforganiserende teams, net als de beste (deel)projectportfolio’s die de beste resultaten opleveren.
Concluderend
Met dit artikel hoop ik een fundament te hebben neergelegd
voor verdere discussie over Agile en PPM. In de literatuur was
hiervoor nog niets voorhanden. Het Agile benaderen van PPM
blijkt echter een waardevolle insteek. Agile benadrukt een
aantal zaken waarmee organisaties in hun praktijk van het
implementeren van PPM en het managen van een projectportfolio hun voordeel kunnen doen. Rest mij alleen nog iedereen
veel succes te wensen bij het ‘going agile’ met PPM. <
Noten:
1 http://nl.wikipedia.org/wiki/Agile-software-ontwikkeling
2 http://agilemanifesto.org
3 Vergelijk bijvoorbeeld met de Portfolio Governance Process
Flow Diagram.
4 Vergelijk bijvoorbeeld met de rol van het zogenaamde
‘portfolio dashboard’ in besluitvormingsprocessen, het proces
‘porfolio definition’ of het proces ‘portfolio delivery’.
5 Zie bijvoorbeeld: Sanjiv Augustine, Managing Agile Projects,
2005.
6 Vergelijk met hiervoor: Wyscoki.
7 Wij hebben overigens de navolgende principes gekozen
omdat deze ten opzichte van wat hiervoor reeds is geschreven
het meeste toevoegen. Bijvoorbeeld nogmaals ingaan op het
tweede principe (Agile processen omarmen verandering ten
behoeve van het concurrentievoordeel van de klant) voegt
niet veel toe, omdat dit deels al is besproken bij de kernwaarden over het reageren op verandering.
Bronnen:
- Jochen Krebs, Agile Portfolio Management, 2009, Microsoft
Press.
- Mikael Krogerus & Roman Tschäppeler, The Decision Book,
2008, Profile Books.
- EPMC, James Pennypacker & San Retna (ed.), Project Portfolio
Management, 2009, John Wiley & Sons.
- OGC, Management of Portfolios, 2011, TSO.
-P
MI, The Standard for Portfolio Management, 2008, 2-de editie,
Project Management Institute.
- Robert K. Wysocki, Effective Project Management, 2009, 5-de
editie, Wiley Publishing.
- Robert K. Wysocki, Executive’s guide to project management,
2011, John Wiley & Sons.
- J ohanna Rothman, Manage your project portfolio, 2009, The
Pragmatic Bookshelf .
01-2012 | IPMA Projectie Magazine
29