Update: Lees ook het artikel "Agile Projecten: De veranderende rol van de Project Manager" voor een bredere uiteenzetting.
Ze zijn er nog, vorige week heb ik er nog eentje gezien. Een echte projectleider. Zo eentje die, wanneer je het hem, of haar, vraagt, een certificaat kan laten zien waarop duidelijk vermeld staat dat een Prince2 cursus met goed gevolg is afgerond.
De projectleider is een
uitstervend beroep. Althans, in de Software ontwikkeling. Gelukkig maar, want ze hebben er helemaal
niets te zoeken. Althans, in de Software ontwikkeling.
We denken dat we
projectleiders nodig hebben in de IT en dat komt vooral door die vermaledijde
waterval methode die we sinds mensenheugenis in onze IT-projecten toegepast
zien. Kolder natuurlijk, die waterval methode, er is nog nooit een project
opgeleverd dat binnen het geplande budget en in de geplande tijdspanne iets
bruikbaars heeft opgeleverd. Kan ook niet, want er is geen enkele gebruiker die
ook daadwerkelijk weet wat hij, of zij, wil. Laat staan dat de gebruiker weet wat
hij, of zij, nodig heeft.
Geen wonder dus dat we al
onze pijlen tegenwoordig op agile methoden richten, het liefste zoals ze dat
bij Spotify doen. In het kort:
Je hebt een idee, je ontwikkelt de software, je laat de gebruiker bepalen of het een goed idee was en je gaat verder met het volgende idee.
En hier gebeurt het dus.
Dit is waar aan het licht komt dat de projectleider niet in de IT thuishoort.
Want als je denkt dat deze cyclus een project is, dan heb je het flink mis. Ook
trouwens als je denkt dat een aantal van die cycli samen een project vormen.
Het fundamentele probleem
van een project is dat een project eindig is. Je begint aan een project en op
een gegeven moment is het project klaar. We zijn klaar als het project af is.
En dat is natuurlijk kolder voor IT-projecten want IT-projecten zijn nooit af.
Haha, denk je nu, dat is de bekende IT-grap, dat projecten altijd over tijd en
over budget gaan. Maar het is geen grap, want wanneer een IT-project klaar is, dan
begint het allemaal pas eigenlijk.
Wanneer het project
namelijk klaar is, wordt de software gebruikt en pas dan kunnen we eraan werken
het bruikbaar te maken. Kijken we nu naar de projectleider, dan is zijn, of
haar, werk gedaan als het project is opgeleverd. De projectleider wil dus
alleen maar de software aan een gebruiker geven. Binnen de tijd, binnen het budget.
Los van het feit of de software wel bruikbaar is.
De projectleider richt
zich dus op wat de gebruiker wil hebben en niet wat de gebruiker nodig heeft.
En dat is de fundamentele reden waarom IT-projecten onzinnig zijn, en waarom
projectleiders desastreus zijn.
Dat hebben we gelukkig al een tijdje in de gaten en daarom zijn we met agile begonnen een paar jaar geleden. Los van het agile manifesto[2] en de hype rondom Scrum, zijn we in de IT al meer dan 20 jaar heel actief in het iteratief ontwikkelen met een zo kort mogelijke development cyclus. En daarom zijn we sinds die tijd, tot ongeveer een jaar of 5 geleden, druk geweest met projecten die software iteratief opleveren. In plaats van lange waterval trajecten hebben de projectleiders hun projecten in kleine watervalletjes verdeeld. We zien dat iteratieve projecten minder uitlopen voor wat betreft tijd en geld. Maar nog steeds krijgt de gebruiker wat hij wil en niet wat hij nodig heeft. Of zij natuurlijk.
Het moge duidelijk zijn;
Zolang software ontwikkeld wordt in door projectleiders geleide projecten, dan resulteert
dat in gewenste, onbruikbare software.
En toen was er agile en Scrum en sindsdien krijgt de gebruiker wat hij
nodig heeft en niet per se wat hij wil hebben. Door niet van meet af aan vast
te leggen welke functionaliteit de software moet opleveren, maar gaandeweg de
scope bij te stellen en bestaande functionaliteit aan te passen tot iets
bruikbaars, hebben we agile projecten die iets bruikbaars opleveren.
De echt goede projectleiders weten om te denken naar deze nieuwe manier van werken. Het is het type projectleider dat niet meteen in de stress schiet als niet duidelijk is wat zijn team moet opleveren. De scope van het project, maar ook de duur, wordt daarmee bepaald door het budget. Het project is afgelopen als het geld op is. De projectleider wil, als hij, of zij, hart voor de zaak heeft, dus zoveel mogelijk functionaliteit voor dat budget opleveren.
En daarom is de projectleider niet meer nodig. Want het snijdt geen hout om projecten te scopen op basis van hoeveel geld er beschikbaar is. Dat moge duidelijk zijn.
Dan is er nog een ander
klein, piepklein, puntje van aandacht met dat nieuwe agile werken. Al vroeg, namelijk
zo snel mogelijk, staat er, in een echt agile project, iets in productie en
wordt het gebruikt door echte gebruikers. Dat moet misschien worden aangepast
omdat het niet bruikbaar is. En plotseling is de projectleider ook
verantwoordelijk voor het oplossen van productieproblemen.
Ze gaan teloor omdat
organisaties door hebben dat projecten in de IT uitermate onzinnig zijn. Er is
natuurlijk een hele groep organisaties die gewoon hip is en niet snapt waarom
ze het zijn. Een steeds grotere groep snapt het wel en richt zich wat wenselijk
is en niet meer op wat gewenst wordt.
IT-afdelingen
transformeren zich meer en meer van projectorganisaties naar productorganisaties.
Organisaties stappen af van Change-Run scheidingen en stappen over op DevOps[4].
Gespecialiseerde teams worden ontbonden en multifunctionele teams worden
ingericht. Er worden geen softwareprojecten gedaan, maar producten ontwikkeld
in software. Omdat er geen projecten meer worden gedaan zijn er geen
projectleiders meer nodig. In geen enkele vorm. Wel zijn er product eigenaren
nodig. Helaas voor al die zonder-werk-komen-te-zittende projectleiders, is een producteigenaar
niet zoiets als een projectleider. De producteigenaar is namelijk de eigenaar
van een product, die snapt het product, en begrijpt vooral wat wel en wat niet
bruikbaar is. Hij, of zij, is verantwoordelijk voor het product,
cradle-to-grave, van wieg tot in het graf dus.
Hij, of zij, heeft het
mandaat om te welke functionaliteit op welke wijze geboden wordt. Is ook nog
eens budgetverantwoordelijk voor het product. De producteigenaar is wordt niet
beoordeeld op de hoeveelheid functies die in de beschikbare tijd en met het
beschikbare budget in productie gehesen wordt, maar wat de waarde van zijn, of
haar, product voor de organisatie is. En die waarde kan alleen gemeten worden
wanneer het product daadwerkelijk gebruikt wordt.
Maar er is hoop voor de
projectleider. Er zijn namelijk aardig wat product eigenaren die het ook nog
niet snappen. Ze ontwikkelen hun product in een project, dat nog behoorlijk wat
trekjes heeft van een waterval traject. Of in ieder geval iteratief. En zo lang
product eigenaren nog niet helemaal snappen wat een MVP[5] is heeft
de projectleider nog werk. De huidige lichting producteigenaren zijn nog
onvoldoende ervaren in het opleveren van een iets. De projectleider, en zeker
een die bekend is met iteratieve trajecten, heeft hier dus een flinke streep
voor. Maar voor hoelang?
Het tij keert namelijk,
product eigenaren begrijpen meer en meer wat hun rol is en hoe zij deze het
beste in kunnen vullen. Organisaties komen erachter dat het niet verstandig is
om hun projectleiders om te scholen tot product eigenaren. Los van het
verfoeilijke Prince2, is het ook nog eens zo dat de projectleider onvoldoende
kennis en vaak geen affiniteit heeft met het product. Dat ‘ene iets’ waar een
organisatie geld mee verdient. Producteigenaren komen dus uit de business en
niet zoals de projectleiders, uit de IT. De projectleider is dus overbodig.
Daarmee is de teloorgang
van de projectleider dus onvermijdelijk. Niet een kwestie van of maar van
wanneer.
Zoals altijd, bedankt voor het lezen van deze post en ik hoop dat de post je aan het denken heeft gezet. Ik realiseer me dat ik nogal kort door de bocht ga en het allemaal redelijk zwart/wit neerzet. En zoals met alles op het internet moet je ook dit artikel met een dosis gezond verstand lezen. Moet je zelf de nuancering aanbrengen. Ik wil je uitnodigen om dat laatste te doen via de comments van deze post. Waarschijnlijk dat anderen het ook interessant vinden te weten hoe jij erover denkt, en uiteraard staat het buiten kijf, dat ik het interessant vind.
Zoals altijd, bedankt voor het lezen van deze post en ik hoop dat de post je aan het denken heeft gezet. Ik realiseer me dat ik nogal kort door de bocht ga en het allemaal redelijk zwart/wit neerzet. En zoals met alles op het internet moet je ook dit artikel met een dosis gezond verstand lezen. Moet je zelf de nuancering aanbrengen. Ik wil je uitnodigen om dat laatste te doen via de comments van deze post. Waarschijnlijk dat anderen het ook interessant vinden te weten hoe jij erover denkt, en uiteraard staat het buiten kijf, dat ik het interessant vind.
[1] Maar daar gaat dit artikel niet over, wil je
weten wat daar mis mee is, dan kan je mijn blog post over die architect lezen.
Die vind je hier: https://itarchitectureandstrategy.blogspot.nl/2015/02/how-youll-fail-as-it-architect-when-you.html.
[2] Kijk op http://agilemanifesto.org/ voor het manifesto. Lees het aandachtig voor je
je conclusies gaat trekken.
[3] Change-Run organisaties zijn het gevolg van het
niet begrijpen van Taylorism. https://en.wikipedia.org/wiki/Scientific_management, net als het agile manifesto.
[4] In een DevOps organisatie werken ontwikkelaars
(Dev) en beheerders (Ops) nauw samen. Zie ook: https://en.wikipedia.org/wiki/DevOps
[5] Een MVP, Minimum Viable Product, is een versie
van een product met de minimale set aan functionaliteit om toch nog waarde te
scheppen voor de gebruiker. Zie ook: https://en.wikipedia.org/wiki/Minimum_viable_product
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.