Projectmanager in de spagaat: Management van Creativiteit Toen Quincy Jones in de jaren vijftig een tournee maakte met zijn big band in Europa, ging het project halverwege de rondreis failliet. Hij besefte toen dat een goed muzikant ook een goed manager moet zijn. Na dit inzicht werd hij later een van de meest succesvolle bandleiders en componisten ter wereld. De andere kant van dit verhaal bestaat ook. Wie de radio en televisie volgt, zal talloze voorbeelden horen en zien van glad gemanagede projecten die hits produceren van dertien in een dozijn. Bij deze producties is de creativiteit ver te zoeken. Dit doet de vraag rijzen hoe een creatief project het best gemanaged kan worden, om zowel de artistieke kant als de zakelijke kant van een creatie te bewaken. Om dat te onderzoeken is er eerst gekeken naar hoe (zakelijke) projecten volgens het boekje gemanaged moeten worden.Verschillende instrumenten van projectmanagement, zoals te vinden in de PRINCE2, TOCi of DSDM1 methodieken zijn toepasbaar om projecten beter te managen. In de praktijk wordt er echter in de creatieve industrie2 weinig van deze instrumenten gebruikt gemaakt. Er lijkt veel weerstand te bestaan tegen formeel projectmanagement binnen creatieve organisaties en vaak wordt als argument genoemd dat het de creativiteit en daadkracht van de projectteams aantast. Toch kampen creatieve bedrijven, net zoals bij projecten in de zakelijke wereld, met (enorme) uitloop van projecten en (enorme) kostenoverschrijdingen. Het is dus de vraag of de projectmanagement methodes geschikt zijn om deze problemen aan te pakken in de creatieve industrie. En als ze dan toepasbaar zijn, op welke manier ze niet de creativiteit aantasten. In dit artikel wordt een typisch verloop van een creatief project geschetst en worden de dilemma’s benoemd die binnen zo’n project in verschillende fasen ontstaan. Vervolgens worden oplossingsstrategieën aangedragen, al dan niet afkomstig uit de projectmanagementmethodiek, voor die knelpunten. Ook wordt er uitgelegd welke methodieken juist niet werken en waarom. Het artikel is als zodanig nuttig voor projectleiders3 die leiding moeten geven aan een groep creatieve mensen, als voor managers en fondsverstrekkers, die moeten besluiten over de projecten alsmede voor partijen die met een creatief team moeten samenwerken. De inzichten die verwerkt zijn in dit artikel zijn afkomstig van de ervaringen met diverse vernieuwende nieuwe mediaprojecten maar zijn mogelijk ook toepasbaar in andere creatieve projecten4. Onder creatieve projecten wordt binnen het kader van dit 1
Zie www.dsdm.org Onder de creatieve industrie wordt hier verstaan de bedrijven en organisaties die zich bezig houden met het maken van nieuwe producten, gebaseerd op nieuwe concepten, waarbij de vernieuwing centraal staat. De grondslag is vaak artistiek, niet commercieel. Een groot deel van de culturele sector valt binnen deze definitie van creatieve industrie. 3 Waar in dit artikel over de projectleider in de mannelijke vorm geschreven is, wordt natuurlijk ook de vrouwelijke projectleider bedoeld. 4 Creatieve projecten kenmerken zich door hoge mate van vernieuwing. Bij software ontwikkeling is daar ook sprake van en het valt daarmee ook onder de noemer van ‘creatief projecten’. In de praktijk wordt software ontwikkeling echter door velen gezien als ‘engineering’, waarmee gesuggereerd wordt dat er veel meer zekerheid is dan in een ‘creatief project’. Dit verkeerde uitgangspunt zorgt ervoor dat veel software ontwikkelingsprojecten niet goed gemanaged worden. 2
artikel verstaan projecten die een concreet product opleveren dat nog niet eerder gemaakt is, waarbij de vernieuwing centraal staat. Er is dus sprake van een hoge mate van onzekerheid. Het verkennen van ‘onbegane paden’ mag binnen het kader van deze definitie van ‘creatieve projecten’ als doel op zich gezien worden. Het grootste probleem van de projectmanager van creatieve projecten is het dilemma van ‘creativiteit versus management’. De creativiteit in zijn puurste vorm is vernieuwend, chaotisch, onvoorspelbaar en zeker ook gepassioneerdheid. Het ‘management’ in zijn stereotype houdt van controle, beheersing en is zakelijk. Het beeld van de kunstenaar die koste wat kost voor zijn droom gaat versus de manager die binnen zijn budget wil blijven en tastbare resultaten wil zien. Ter illustratie: stel je hebt een creatief team bestaande uit programmeurs, vormgevers, conceptbedenkers en content makers (schrijvers, fotograven, en dergelijke). Een ieder die met een team van een dergelijke samenstelling heeft gewerkt zal het volgende beeld herkennen: het is aan de ene kant vaak moeilijk om het team bij elkaar te krijgen voor een vergadering, teamleden komen te laat of dagen gewoon niet op. Aan de andere kant is dit team wel bereid om een nacht door te werken aan de creatie, als de inspiratie daar is. Goede ideeën komen vaak pas om drie uur ’s nachts. Als de projectmanager te veel op zijn managersrol gaat zitten dan knijpt hij de creativiteit af, wat resulteert in een (artistiek) oninteressant product en spanningen in het projectteam. Als hij te veel meegaat met de creatieve dromerigheid is het risico dat er aan het einde van de rit geen concreet product is geleverd en/of dat de kosten en de doorlooptijd uit de hand zijn gelopen. Ook in dit geval zullen spanningen in het team ontstaan. Dit dilemma is de evenwichtsbalk waarop de projectmanager van creatieve projecten voortdurend moet balanceren. Hoe kan de projectleider dit dilemma benaderen? Binnen de softwareontwikkeling zijn er globaal twee benaderingen van projectmanagement. De eerste is een lineaire benadering waarbij het project in een aantal opeenvolgende fasen wordt opgedeeld en er naar een nader te definiëren eindproduct wordt toegewerkt. De tweede benadering is een cyclische waarbij er door middel van een aantal prototypes naar het uiteindelijke eindproduct wordt toegewerkt5. In theorie is de cyclische benadering beter geschikt voor projecten waarbij het einddoel nog niet duidelijk is, zoals bij creatieve projecten het geval is. Van prototype naar prototype ontstaat het eindproduct, zonder dat alle details van te voren bedacht hoeven te worden. Bij een lineaire methode moet je op een gegeven moment, vrij vroeg in het project, het einddoel vastleggen. Dit is lastig bij een vernieuwend project: je maakt iets nieuws en je weet dus nog niet waar het op uit zal komen. Belangrijke voorwaarden voor het succesvol toepassen van cyclische methodes is dat de betrokken organisaties deze projectmanagement methode goed gewaarborgd hebben in hun organisatie. Een goede administratieve ondersteuning is nodig. Verder is het van belang dat het management en de betrokken partijen zich ook aan de cyclische projectmanagement discipline, met alle overlegstructuren en besluitvormingsprincipes houdenii. Met andere woorden: cyclisch projectmanagement vraagt een veel grotere organisatiegraad dan lineaire projectmanagement. En daar zit nu het probleem voor de 5
Voorbeelden van cyclische projectmethodes zijn DSDM en Xprogramming
creatieve industrie: deze blinkt niet uit in sterke operationele en administratieve organisatie. Binnen creatieve organisaties ligt de nadruk op de creatieve inhoud en wordt er vaak geen prioriteit gegeven aan operationeel management.6 Dit blijkt onder andere uit het ontbreken van administratieve systemen zoals een urenregistratiesysteem of een systeem voor personeelsplanning. Dit maakt het sturen en beheersen van projecten er niet gemakkelijker op binnen zo’n organisatie. De projectmanager zal met het management van de betrokken organisaties overeenstemming moeten vinden voor het inrichten van een projectmanagementstructuur. Als die structuur echter als te beklemmend wordt ervaren door het creatieve team of door het management 7 zal dat het project niet ten goede komen. Dit zal van organisatie tot organisatie en van team tot team verschillen en het vraagt van de projectmanager eigenlijk ook een deel verandermanagement omdat hij zal moeten beginnen met het implementeren van een geschikte projectstructuur. Cyclisch projectmanagement zal dan vaak een brug te ver blijken. Lineair projectmanagement bleek bij de projecten die de basis vormden voor dit artikel wel haalbaar en bracht al een duidelijke verbetering ten opzichte van de situatie voordat er überhaupt projectmanagement werd toegepast. Het eerste wat een projectleider van een vernieuwend nieuwe media project dient te doen is een fasering aanbrengen in het project. Hiervoor is onderstaande (lineaire) fasering nuttig gebleken: 1. 2. 3. 4. 5. 6.
Conceptfase Offerte/ Acquisitie fase Ontwerpfase Productie fase Test fase Onderhoudsfase
Hieronder worden nu de fases besproken en worden veel voorkomende knelpunten beschreven en mogelijke oplossingen gegeven.
6
De culturele sector moet zich profileren op inhoud, waardoor er meestal geen focus op (operationeel) management gelegd wordt. Een eventuele financiering van de organisatie op basis van subsidies versterkt dit effect, omdat subsidies op inhoudelijke doelen worden verstrekt en niet op operationele prestaties van een organisatie.Voor veel internetbedrijven geldt daarnaast dat ze korter dan tien jaar bestaan en daardoor vaak nog niet een volwassen organisatievorm hebben bereikt. 7 Ook bij het management kan veel weerstand bestaan tegen projectmanagement structuren. Bijvoorbeeld omdat werknemers dan voor een project gereserveerd worden, terwijl het management liever (op ongeplande basis) aanspraak op werknemers wil kunnen maken voor andere werkzaamheden. Vaak wil het management de ontwikkelaars op (te)veel projecten tegelijkertijd inzetten.
1. Conceptfase: Knelpunt: welke relatie wordt er aangegaan? In de conceptfase wordt er een idee geboren voor een nieuwe media product, bijvoorbeeld een internet gebaseerd spel dat gekoppeld wordt aan sms functionaliteit en de geografische locatie van spelers. Dit kan zowel in de geest van een creatieve nieuwe media ontwikkelaar die een financier zoekt, als in de geest van een klant, die een creatief team zoekt dat zijn of haar idee kan realiseren. Of in de geest van twee partijen die daarmee een samenwerking aangaan, zoals een museum dat een samenwerkingsverband aangaat met een creatief webbureau voor een nieuwe educatieve webapplicatie. Het onderscheid tussen deze drie situaties zal essentieel blijken voor het verdere verloop van het project. 2. Offerte/ Acquisitiefase Knelpunt : Goede inschatting van de kosten De nieuwe media die zijn eigen idee wil ontwikkelen zal moeten trachten zijn concept te ‘verkopen’ aan fondsen, zoals het Mondriaan fonds, Digitale Pioniers, het VSB fonds, sponsors of andere financiers. Het nadeel van deze werkwijze is dat het geld verkregen wordt op basis van een concept en niet op basis van een goed uitgewerkt ontwerp van de nieuw te ontwikkelen webapplicatie. Hierdoor is er geen goede inschatting te maken van de reëel te verwachten projectkosten, het is immers nog niet duidelijk hoe het eindproduct uiteindelijk zal worden, laat staan hoeveel werk dat zal behelzen. De haalbaarheid van de uitvoering van het concept is daarmee in feite onzeker. Omdat een concept nog in zeker mate vaag is over de concrete realisatie, worden er bij de financiering vanuit fondsen vaak weinig harde eisen gesteld ten aanzien van hetgeen geleverd moet worden. Als de projectleider na afloop van het project kan beredeneren dat het project heeft voldaan aan de verwachtingen in het concept, loopt de financiering meestal geen gevaar. Het is de vraag of deze vrijheid de kwaliteit van het te realiseren project ten goede komt, al wordt er wellicht door de fondsen bewust voor gekozen om kunstenaars in hoge mate vrij te laten in hun uitvoering. Een grote verbetering bij het aanvragen van financiering zou optreden als het mogelijk zou zijn om eerst het functioneel ontwerp8 uit te werken en dat voor te leggen voor financiering. Als het functioneel ontwerp bekend is, is een betere inschatting te maken van de hoeveelheid te verwachten werk en daarmee samenhangende kosten. Bovendien is duidelijk waar de op te leveren applicatie aan moet voldoen. Het vervelende daarbij is dat het uitwerken van het functioneel ontwerp tot ongeveer 70% van de hoeveelheid werk van het project kan omvatten. Het projectteam moet dus al het grootste deel van het project uitgevoerd hebben voordat het duidelijk is of er financiering mogelijk is, wat in de praktijk vaak onhaalbaar is. Een aardige manier om dit dilemma enigszins te omzeilen is de manier waarop Cinekid in samenwerking met het Amsterdams Fonds voor de Kunsten in een aantal 8
Een functioneel ontwerp is een document waarin het concept nader wordt uitgewerkt en nauwkeurig is beschreven wat te ontwikkelen software kan, hoe de vormgeving van de software is en hoe de interactie tussen de gebruikers en de software is. Een voorbeeld van een functioneel ontwerp is te vinden op: http://www.joelonsoftware.com/articles/WhatTimeIsIt.html
rondes ideeën voor projecten honoreert. In de eerste ronde kunnen ontwikkelaars een concept voor een webapplicatie voor de jeugd inleveren. Dan krijgen de beste vier concepten een (weliswaar beperkt) budget om de concepten om te zetten in functionele ontwerpen. Uit die vier functionele ontwerpen wordt tenslotte één partij gekozen die geld krijgt om zijn functionele ontwerp te mogen uitvoeren. Beperking in dit model blijft echter wel dat er vooraf een bedrag vaststaat waarbinnen de kosten van het project moeten blijven. Hierdoor blijft het risico dat het project aan het einde wordt afgeknepen of dat de makende partij met een tekort blijft zitten omdat de hoeveelheid werk veel meer bleek dan verwacht. Is er duidelijk sprake van een klant-leveranciersrelatie, anders dan wanneer er sprake is van financiering door een fonds of sponsor, dan is het uitgangspunt van het project anders. De klant heeft een idee en wil zijn idee gerealiseerd zien. Als een webbureau de prettige positie heeft dat hij kan afspreken met zijn klant dat ze per uur betalen voor de ontwikkeling, ontstaat er enkel een probleem als de kosten van het project zo uit de hand lopen dat de klant niet meer wil betalen. In de praktijk echter, zal een klant graag een vast bedrag voor het project willen afspreken en in ieder geval een inschatting van de kosten vooraf willen hebben. Ook hierbij is het weer lastig dat de kosten beraamd moeten worden op basis van een concept. Het zou wenselijk zijn om die te beramen op een functioneel ontwerp, wat enige weken tot maanden werk kan zijn. In deze situatie is het makkelijker om met de klant af te spreken om eerst een ontwerp te maken tegen een vooraf afgesproken bedrag en vervolgens op basis van dit ontwerp de uiteindelijke prijs af te spreken. Hierbij kan er dan nog geschoven worden in de geoffreerde kosten, door bepaalde delen van het ontwerp soberder of juist uitgebreider uit te voeren. Wel moet goed afgesproken worden dat indien de klant besluit om na de ontwerpfase te stoppen dat hij niet (zonder meer) met het functioneel ontwerp naar een derde partij mag gaan om het daar te laten bouwen. Op een idee rusten immers geen auteursrechten maar op de uitwerking daarvan in een ontwerp zeer ze In de laatste samenwerkingsvorm besluiten twee of meer partijen een nieuwe media project te gaan uitvoeren. Dit is wellicht de meest lastige situatie omdat de verwachtingen over en weer niet zonder meer duidelijk zijn. Er moeten duidelijke afspraken gemaakt worden over zaken als: wie van de partijen zorgt er voor de financiering? Wie is er verantwoordelijk voor welke werkzaamheden? Wie beheert het budget? Wie is er verantwoordelijk voor en draait op voor budgetoverschrijdingen? Wie is de eigenaar van het intellectueel eigendomsrecht (o.a. de ontwerpen, de software)? Wie neemt de beslissingen in het ontwerpen van de software? Wie is er verantwoordelijk voor het beheer van de software na het aflopen van het project? Wat gebeurt er met eventuele opbrengsten van de software? Het moge duidelijk zijn dat deze lijst niet uitputtend is en dat ook hier weer het probleem is dat veel van bovenstaande vragen pas beantwoord kunnen worden als er een goed functioneel ontwerp op tafel ligt, wat feitelijk pas in het midden van het project is. Het is immers onmogelijk te spreken over onderhoud van software als nog niet eens duidelijk is wat de software omvat. In deze projecten is de relatie tussen de partijen het allerbelangrijkste en zal er veelal op basis van goed vertrouwen samengewerkt moeten worden. Bij aanvang van het project is het goed te bedenken welke relatie het team heeft met andere partijen. De projectleider dient duidelijkheid te scheppen in de verantwoordelijkheden per fase van de betrokken partijen. Indien mogelijk probeert hij de
kosten van het project in te schatten aan de hand van een ontwerp en niet aan de hand van een concept. 3. Ontwerpfase Knelpunt: Niemand wil een functioneel ontwerp maken Veel software wordt gemaakt zonder functioneel ontwerp. De reden dat creatieve teams liever geen functioneel ontwerp uitwerken, ligt waarschijnlijk in de weerstand tegen administratief werk. Het maken van een functioneel ontwerp vergt nauwkeurig schrijfwerk waarbij de ontwerpbeslissingen en gemaakte ontwerpen en afspraken van het team vastgelegd moeten worden. Het maken van een functioneel ontwerp lijkt het project hierdoor onnodig te vertragen. Het tegenovergestelde is echter waar. Het functionele ontwerp is een lijst met afspraken wat de software wel en niet moet kunnen. Als er geen functioneel ontwerp is, is er een groot risico dat het project niet goed afgesloten kan worden en dat er talloze losse eindjes zullen blijven. De verwachtingen tussen de partijen zijn wellicht verwoord maar nooit opgeschreven en tegen het einde van het project (tegen het einde van het budget) blijkt dan dat de klant of projectpartner toch iets heel anders bedoelde dan wat de designers en programmeurs gemaakt hebben. Gevolg: ontevreden klant of projectpartner, herstelkosten en uitloop van het project. In de praktijk wordt vaak de volgende werkwijze gevolgd: in plaats van eerst de ideeën op papier te zetten en uit te werken, gaan de makers met de ideeën aan de slag. Van het eerste prototype wordt er telkens naar een nieuw verbeterd prototype gewerkt. Gevolg: door niet expliciet van tevoren vast te stellen welke van de functionaliteiten belangrijk zijn en welke minder, zijn de oorspronkelijk gewenste functionaliteiten door vele compromissen en ad hoc beslissingen steeds verder uit het oog verloren. Van binnen lijkt de software op een bord spaghetti. Deze zogenaamde ‘rapid prototyping’9 methode is derhalve niet aan te bevelen, tenzij er sprake is van een zeer kleine projectgroep, waar de communicatielijnen kort zijn, of bij kleine projecten waarbij er geen grote vernieuwing wordt toegepast (bij het maken van een ‘standaard’ website, zonder al te veel technologische uitdagen.). De verwachtingen zowel op functioneel gebied als op technische gebied zijn in dit laatste geval wel grotendeels duidelijk. Het managen van de verwachtingen is belangrijk aspect wat de projectleider voortdurend moet toepassen gedurende het project. Het functioneel ontwerp helpt daarbij ten aanzien van wat er gemaakt wordt. Daarnaast zal de projectleider ook ten aanzien van de hoeveelheden te verzetten werk de verwachtingen moeten managen. Klanten denken met name nog al eens makkelijk over hoe snel een functionaliteit gerealiseerd kan worden in een applicatie. ‘Kan je even een tekstje erbij plaatsen of een knopje toevoegen’ zijn veel voorkomende vragen van klanten, als blijkt dat er iets vergeten is in het ontwerp (met de nadruk op het woordje ‘even’). Bij veel projecten zijn er klanten die op een gegeven moment roepen, meestal als het project even tegenzit, dat ze een handig neefje hebben die 9
‘rapid prototyping’ is een element uit de DSDM (cyclische) projectmanagement methode en werkt alleen goed Indien de gehele DSDM methode toegepast wordt. In de praktijk echter worden de elementen van DSDM die het overleg tussen de partijen en de kwaliteitsborging regelen niet toegepast, waardoor rapid prototyping resulteert in een snelle start maar een uiteindelijk onbeheersbaar project.
beweert dat hij zo’n soort website ‘in een weekeindje in elkaar draait’. Dergelijke klanten moeten dan maar naar dat neefje gaan, is het enige juiste antwoord van de projectleider. Het neefje zal zeker niet alle facetten ‘onder de motorkap’ van de website overzien. De reden dat de verwachtingen van klanten en makers over de productie inspanning vaak uit elkaar komen te liggen, ligt in het feit dat aan de buitenkant veel werk niet zichtbaar is. Een website in platte HTML is een geheel andere applicatie dan een content management systeem10, al zien ze er aan de buitenkant op het internet mogelijk hetzelfde uit. Of een website vier keer per jaar of vier keer per dag veranderd moet worden, heeft een enorme impact op de hoe de applicatie ontworpen moet worden en dus op de hoeveelheid programmeerwerk. Zo zijn er talloze aspecten die een projectmanager op tafel moet krijgen voordat er maar een letter code geprogrammeerd gaat worden. Maar belangrijker nog, de projectleider moet goed aan de klanten uitleggen waarom bepaalde ontwerpkeuzes en veranderingen veel of weinig werk zijn. Doet hij dat niet, dan leidt dat vroeg of laat tot wantrouwen bij de projectpartners. De klant begrijpt dan niet waarom ogenschijnlijk eenvoudige dingen zo lang duren. In de ontwerpfase moet er tijd geïnvesteerd worden in een goed ontwerp, vooral met het oog van het managen van de verwachtingen over en weer. De programmeurs moeten goed te weten te komen wat er allemaal onder die motorkap gemaakt moet worden (en de projectleider moet goed aan de klant uit kunnen leggen dat bepaalde ontwerpkeuzes soms veel werk behelzen).
10
Een content management systeem is software waarin de gehele informatiestroom, beheer en presentatie van content gefaciliteerd is en wordt veelal gebruikt door uitgeverijen Tekstschrijvers hoeven bijvoorbeeld dan geen html code te kennen, maar kunnen hun teksten direct in het systeem voor publicatie op het internet toevoegen.
a. Oud design managenergy.tv
b. Nieuw design managenergy.tv
c. in HTML
d. in Content Management Systeem
figuur 1: Het is ook moeilijk uit te leggen. De overzetting van a naar b kostte 3 uur door het gebruik van CSS stylesheets. Het resultaat was direct zichtbaar voor de klant. De overzetting van c naar d kostte drie weken. De website werd van HTML overgezet in een content management systeem. De klant zag geen enkele verandering aan de buitenkant.
Na het opleveren van het functionele ontwerp zijn de programmeurs in staat een technisch ontwerp11 te maken. Pas na het realiseren van het technisch ontwerp is het moment daar dat de kosten van het project reëel ingeschat kunnen worden. Er zal dan vaak opnieuw onderhandeld moeten worden over het project en wat er wel en niet haalbaar is binnen het gestelde budget. Overigens is het een illusie te denken dat alles goed beschreven kan worden in een functioneel ontwerp. Tijdens het maken van de software zal door het bouwen van de software blijken dat er nieuwe inzichten en wensen ten aanzien van het ontwerp ontstaan. Deze nieuwe wensen zullen onderhandeld moeten worden tussen de betrokken partijen. Doordat het functioneel ontwerp een stevige basis is voor het project, zal dit minder een probleem zijn, dan wanneer er helemaal geen functioneel ontwerp is.
11
Een technisch ontwerp is een document waarin de (software) architectuur en technische randvoorwaarden van de te ontwikkelen applicatie worden vastgelegd.
4. Productiefase Knelpunt: Hoe tot een betrouwbare planning te komen Knelpunt: Weerstand tegen administratieve last Knelpunt: Het ontbreken van operationele focus bij creatieve bedrijven Als eenmaal besloten is wat er gemaakt gaat worden en vastgelegd door middel van een functioneel ontwerp, kunnen vormgevers en programmeurs aan de slag. De standaard methode om een dergelijke productieproject te plannen zou volgens de theorie van projectmanagement de toepassing van een Gantt-diagram zijn in combinatie met het bepalen van het kritieke pad. In de praktijk blijkt dat voor het plannen van softwaretrajecten niet goed toepasbaar. Het eerste wat nodig is voor het maken van een Gantt-diagram, is een inschatting van de tijden van de deeltaken. Een bekende vuistregel is dat als een programmeur gevraagd wordt hoe lang iets duurt, die tijd door de projectleider vermenigvuldigd moet worden met twee om tot een goede inschatting te komen. In de praktijk is dat ook wel eens een factor vier of zes of helemaal het tegenovergestelde: factor één achtste. Daarmee wordt de planning van een Gantt-diagram vrijwel waardeloos; de tijdsinschattingen variëren te sterk van de werkelijk benodigde tijd. Daarnaast is het een probleem dat het moeilijk te meten is hoe ver een deeltaak voldaan is. Stel dat er een deeltaak is gedefinieerd het ‘programmeren van de gebruikersinterface’, waar twee weken voor is gepland. De programmeur kan na een halve week niet goed aangeven of hij al op 50% van het werk zit, of voor- of achterloopt op het schema. Meestal blijkt pas na de twee weken dat hij nog niet klaar is en moet het resterend werk van die deeltaak opnieuw ingeschat worden en het Gantt-diagram bijgesteld. De derde reden dat een Gantt-diagram niet werkt is dat programmeurs niet goed uitwisselbaar zijn. Je kan twee Java programmeurs in huis hebben met vergelijkbare kwaliteiten. Stel dat een programmeur een week op vakantie gaat of ziek is. Inzet van de tweede programmeur om zijn taken over te nemen blijkt altijd niet productief. De tweede programmeur kent het project niet en de hoeveelheid tijd nodig om in het project (functioneel en technisch ontwerp) en in de code van de andere thuis te raken duurt doorgaans langer dan de week vakantie of ziekte van de eerste programmeur. Ook het inschakelen van extra programmeurs als een deeltaak te langzaam gerealiseerd wordt, heeft vaak niet het gewenste versnellende effect. De eerste programmeur is namelijk tijd kwijt aan het inwerken van zijn ‘versterkingen’. Gevolg is dat een extra programmeur vaak maar een hele kleine of geen enkele versnelling van de productie oplevert.
figuur 2. Gantt diagrammen niet geschikt voor softwareontwikkelingen De kracht van Gantt-diagrammen is de mogelijkheid om het kritieke pad te bewaken en daarmee de doorlooptijd van het project te beheersen. Maar door de onmogelijkheid om vertragingen in het kritieke pad op te vangen, is het nut van Gantt-diagrammen bij softwareontwikkeling sterk gereduceerd. De projectleider moet voortdurend het Ganttdiagram bijstellen zonder dat hij in staat is de doorlooptijd (en daarmee samenhangende kosten) daadwerkelijk te beïnvloeden. Het bijstellen van de planning wordt zo meestal een wekelijks terugkerende frustrerende vaststelling dat het project wederom verder uit zal lopen. De laatste reden dat de Gantt-diagrammen niet nuttig zijn gebleken bij softwareontwikkeling, is omdat bij (kleine) softwarebedrijven de ontwikkelaars meestal aan drie, vier of soms zelfs meer projecten tegelijkertijd werken. Afgezien van het feit dat dit vanuit een operationeel standpunt onwenselijk is omdat het de doorlooptijd van projecten ernstig verlengtiii, maakt het ook het plannen van de projecten praktisch onmogelijk. De werkzaamheden van de ontwikkelaars bevinden zich vrijwel altijd op het kritieke pad van een project. Als ze aan meerdere projecten tegelijkertijd werken, betekent dat ze zich op meerdere kritieke paden tegelijk bevinden van de verschillende projecten. Hiermee zijn de planningen van alle projecten aan elkaar gekoppeld. Als er ergens in een project een deeltaak langer duurt of korter (wat dus voortdurend zo is, omdat de taken niet goed te voorspellen zijn) dan veranderen alle planningen van alle projecten. Hierdoor is er zoveel onzekerheid dat de projectmanager feitelijk chaos aan het plannen is (wat hem dus ook niet lukt). De oplossing van het planningsprobleem zit in het kleiner maken van de deeltaken12. Hierbij moeten de programmeurs en designers zelf de het technisch en functioneel ontwerp opknippen in taken van maximaal twee uur. Het gevolg is dat een programmeerklus opgedeeld wordt in een tien- tot honderdtal kleine deeltaken. De kleine deeltaken blijken vaak wel goed inschatbaar qua tijd, waardoor de doorlooptijd van het hele project ook beter ingeschat kan worden. Met het opdelen van het programmeerwerk in kleine deeltaken wordt de programmeur tevens gedwongen zijn werk goed in te delen, wat op zich al een versnellend effect heeft op het werk.
12
Deze aanpak is ontleend aan de ‘Extreme Programming” methode. Zie www.xprogramming.org
figuur 3. Een voorbeeld uit de Xplanner. Een lijst van deeltaken, met een schatting van de oplevertijd per deeltaak. De groene deeltaken zijn gerealiseerd met daarbij een opgave van de daadwerkelijk benodigde tijd.
De deeltaken worden vervolgens door middel van een ticketsysteem13 één voor één afgewerkt, waarbij de programmeur naast zijn eigen inschatting ook aangeeft hoeveel tijd de taak uiteindelijk heeft gekost. Hierdoor heeft de projectleider een goed inzicht in de voortgang van het project. Eventueel kunnen de deeltaken weer in een Gantt diagram geplaatst worden, maar in de praktijk blijkt dat niet veel meerwaarde te hebben, met name omdat het kritieke pad veelal zonder Gantt diagram ook wel duidelijk is14. Een belemmering voor het werken met ticketsystemen is dat er van het team administratieve taken worden verwacht. De programmeurs en designers zullen moeten inschatten hoeveel werk ze moeten leveren per deeltaak en daarna moeten bijhouden hoeveel werk het daadwerkelijk is geweest. Het blijkt dat er veel weerstand is binnen creatieve teams tegen het doen van dergelijke administratieve handelingen. Hier moet de projectleider dus een list bedenken. Kan hij de ontwikkelaar toch overhalen de administratieve handelingen te doen? Is er iemand anders die het voor de ontwikkelaar kan doen (misschien de projectleider zelf)? 5. Testfase Knelpunt: programmeurs testen niet tijdens het programmeren Knelpunt: de tijd is om Knelpunt: wat verwacht de relatie? Het belang van goed testen van de software behoeft geen nadere toelichting. Hoe software getest moet worden, valt buiten het kader van dit artikel. Het moment van testen is wel belangrijk. Hoe eerder je fouten opspoort hoe lager de herstelkosten. Een van de 13
Een voorbeeld van een dergelijk ticketsysteem is xplanner. Zie www.xplanner.org Dit komt omdat een webapplicatie productie vrijwel altijd verloopt volgens de vaste stappen: design maken, programmeren, testen. Een programmeur zal bij voorkeur niet beginnen voordat het design af is en er wordt niet getest voordat de code geschreven is. Dit betekent dat vrijwel alle taken op het kritieke pad liggen. 14
uitgangspunten van de projectmethode Xprogramming is dan ook dat er voortdurend getest moet worden tijdens het ontwikkeleniv. De projectleider doet er verstandig aan om dit uitgangspunt met zijn team te volgen. Maar in weerwil van de goede bedoelingen zal het in de praktijk vaak anders gaan: de programmeur staat onder hoge druk om te produceren en zal daarom niet de tijd hebben om zijn eigen code (goed) te testen. Daarnaast zijn er ook veel programmeurs die eenvoudigweg geen zin in hebben om hun eigen code te testen. Een andere realiteit van softwareontwikkeling is dat op het moment dat de ontwikkelde software zijn eindtest moet ondergaan dat het budget vaak op is en dat de geplande doorlooptijd al ver overschreden. Maar ook als het project goed is beheerst en er voldoende tijd is voor de eindtest, is het belangrijk dat er in een vroeg stadium in het project overeenstemming is over het kwaliteitsniveau van de software. Moet de webapplicatie 100 of 100.000 simultane klanten kunnen bedienen? Welke platforms en browsers ondersteunt de software? Hoe snel moet de software werken? Enzovoort. Het is niet reëel te verwachten dat een creatief vernieuwend project, vaak met beperkt budget, een honderd procent betrouwbaar eindproduct kan opleveren. Dit is veelal een bron van conflicten tussen de betrokken partijen, omdat klanten en projectpartners vaak wel een goed werkend eindproduct verwachten. Feitelijk moet de projectmanager van het begin van het project af aan duidelijk aan de partners communiceren dat er een prototype ontwikkeld zal worden met de daarbij behorende beperkingen. Voor het realiseren van een volledig betrouwbaar eindproduct is een nieuw, ander project nodig, met een nieuw projectteam. Natuurlijk zijn er uitzonderingen waarbij er wel in één keer heel betrouwbare software ontwikkeld is binnen een creatief project, maar het is beter aanvankelijk de verwachtingen te temperen over de mogelijke uitkomst. 6. Onderhoudsfase Knelpunt: Creatieve mensen willen geen onderhoud doen Als de software uiteindelijk getest en goed bevonden is, gaat de nieuwe software gebruikt worden, al dan niet onder het mom van prototype. Hierbij treedt het laatste dilemma van de projectmanager op: creatieve mensen willen geen onderhoud plegen, maar zij zijn wel diegenen die de software gemaakt hebben en de programmacode kennen. De projectleider zal dus óf met het projectteam moeten afspreken hoe het onderhoud en eventuele ondersteuning intern geregeld wordt óf hij zal naar een externe onderhoudspartij op zoek moeten. Dan is het zaak dat de overdracht naar de onderhoudspartij goed geregeld is, wat om bovengenoemde reden in de praktijk lastig is bij nieuw ontwikkelde software. Ook bij de onderhoudsfase is het belangrijk om in een vroeg stadium van het project de verwachtingen van de betrokken partijen op tafel te krijgen: Hoe lang gaat de software gebruikt worden? Is een helpdesk gewenst? Hoe snel moet een storing verholpen worden? Hoeveel uptime is gewenst? Hoeveel geld is er eigenlijk gereserveerd voor onderhoud en beheer? Enzovoort.
Conclusie: De projectleider van creatieve projecten staat voor een lastige taak. Naast de normale problemen van een projectmanager heeft hij enkele extra uitdagingen: vaak weinig budget, onduidelijkheid over verantwoordelijkheden en verwachtingen tussen de projectpartners, geen ontwerp van het te realiseren eindresultaat, gebrekkige organisatiestructuren van de betrokken organisaties en weerstand bij het team tegen administratieve taken. Om het project tot een goed einde te brengen moet hij voortdurend laveren tussen beheersing van het project en vrijheid geven aan de inspiratie. Bestaande methodes van projectmanagement zijn vaak te rigide om te gebruiken bij creatieve projecten, maar elementen uit de methodes zijn weldegelijk bruikbaar. In het artikel staan een aantal van die elementen beschreven die de projectmanager kunnen helpen bij het laveren. Het toepassen van bovenstaande elementen leverde ook daadwerkelijk drastische verbeteringen op in termen van kosten en doorlooptijd. Projectmanagement van creatieve projecten is door het benodigde laveren meer een kunst dan een wetenschap. Het zou interessant zijn om meer ervaringen te inventariseren van projectmanagers die leiding hebben gegeven aan creatieve projecten om zo de kunst van elkaar af te kijken. Curriculum Vitae van de auteur: Wouter Baars (1969) is freelance projectleider. Hij voltooide zijn studie technische bedrijfskunde aan de Technische Universiteit van Eindhoven. Daarnaast studeerde hij enkele jaren Jazz trompet aan het Sweelinck Conservatorium. Hij werkte als projectleider voor en met onder andere KPN, Waag Society, de Europese Commissie een aantal musea in Nederland en Noterik multimedia. Naast zijn werk als projectleider schrijft hij over management en geeft hij les in projectmanagemet bij LearnIt. i
Goldratt Eliyahu M. (1997). Critical Chain. A Business Novel. The North River Press Stapleton, Jennifer. (1997) DSDM Dynamic System Development Method. De methode in de praktijk. Addison Wesley Longman Limited. Pagina 144-145 iii Goldratt Eliyahu M. (1997). Critical Chain. A Business Novel. The North River Press, Pg. 121 iv Apandi Diaz, Tatiana (2003). Extreme Programming Pocket Guide by Chromatic. O’Reilly & Associates, Inc. USA. Pg.2 en verder ii
