We weten het nu wel. We moeten Agile worden. Maar wat betekent dat voor het managen van het portfolio? Moet dat dan helemaal anders. Nee, gelukkig niet. Portfolio Management draait nog steeds om de vraag “wat kunnen we nu het beste doen”. Alleen omdat de uitvoering anders is ingericht heeft dat ook effect op hoe we tot het antwoord komen.
In deze blog leg ik op conceptueel niveau het verschil tussen PPM (Project Portfolio Management) en APM (Agile Portfolio Management) uit.
Laten we bij het begin beginnen. Onderstaand staat sterk schematisch weergeven de huidige praktijk van project portfolio management:
Het begint allemaal met de dingen die we willen, dat zijn de bollen in het diagram. Uit deze dingen selecteren en prioriteren we de dingen die we willen gaan doen. We kijken dan naar de Business Case en aan de hand van het budget starten we één of meerdere initiatieven. Om het werk uit te voeren brengen we een projectteam tot stand. Deze manier van werken kent ook een aantal nadelen:
- We definiëren ‘de dingen die we willen hebben’ als kop-staart projecten met een vaste scope, budget en doorlooptijd. Maar wat als er wat veranderd? Dan moeten de plannen opnieuw en de business case eigenlijk ook.
- Een projectteam is een organisatie op zich. Met bijgevolg de wil om te blijven bestaan. Als het project toch geen goed idee blijkt te zijn kost het nogal wat moeite het project te stoppen.
- Het uitgangspunt is dat we mensen naar werk brengen. Maar die mensen hadden al werk en zo komen er sluipenderwijs steeds meer externen binnen. Om de gaten op te vullen of wellicht erger, om het project zelf te doen. Om dan na afloop van het project met alle kennis weer te verdwijnen.
Maar het allergrootste nadeel is dat we lang cyclisch werken. Budgetten en portfolio’s worden vaak voor een geheel jaar vastgesteld. En wie weet er nu anderhalf jaar van tevoren in de budgetronde hoe het jaar zich ontvouwt? Natuurlijk sturen we gedurende het lopende jaar bij, maar het is best een inerte zaak.
Kan het ook anders? Jazeker, als we nu eens uitgaan van een veranderfabriekje met teams die zelf goed kunnen nadenken. En we geven die teams brokjes met werk al naar gelang de situatie van ons vraagt. Dan krijg je het volgende:
Het eerste wat opvalt is dat we de bollen kleiner maken. En we beschrijven niet meer wat we willen hebben maar wat we willen kunnen. De teams zijn intelligent genoeg om uit te vissen hoe dat bereikt kan worden. Dit is geen zelfsturing maar geeft de teams wel autonomie. En dat vinden mensen over het algemeen erg prettig.
Daarna maken we een lijstje met de belangrijkste zaken bovenaan. Dat kan door slim te prioriteren. In Agile omgevingen gebruikt men hiervoor vaak de WSJF-techniek. Deze staat voor Weighted Shortest Job First en zorgt ervoor dat zaken met de meeste waarde voor het bedrijf en met de minste inspanning bovenaan het lijstje komen. Deze techniek in detail behandelen gaat iets te ver voor hier, maar er zijn genoeg internetpagina’s hierover te vinden.
De teams pakken steeds de bovenste zaken van het lijstje om aan te werken. In theorie is het op ieder moment mogelijk om het lijstje te opnieuw te prioriteren. In de praktijk zal dit gaan op de cadans van de releases.
De voordelen zijn evident:
- Een vast team of aantal teams wordt gevoed met werk dat er op dat moment toe doet. We brengen het werk naar de mensen.
- Door continu te prioriteren zijn we erg wendbaar. Ontwikkelingen binnen of buiten de organisatie vinden snel hun vertaling in het werk dat de teams doen. Is iets niet meer nodig? De volgende iteratie kan het van de lijst.
Maar hoor ik u denken, als we dit op grote schaal gaan doen, hoe hou ik het dan beheersbaar? Een goede vraag en die zal ik beantwoorden in een volgende blog.