Tot zover is er in dit boek voornamelijk geschreven over het managen van een enkel project. In dit hoofdstuk wordt er dieper ingegaan op de vraagstukken die ontstaan wanneer een organisatie meer projecten tegelijk uitvoert. Dit vraagstuk speelt zich vooral af op het vlak van de relatie tussen het (hogere) management team en de projectleiders en staat verder los van de keuze voor een watervalmodel, agile of een andere projectmanagement aanpak.

Coördinatie van projecten

In eerdere hoofdstukken is beschreven dat de GOKIT factoren de parameters zijn waarop projecten gerapporteerd en gestuurd worden. Ook bij het afstemmen van meerdere projecten spelen deze GOKIT factoren weer een belangrijke rol:

Geld: om te zien of projecten financieel mogelijk zijn
Organisatie: om onderlinge afspraken te maken over de hiërarchie tussen projecten onderling en projecten en de overige afdelingen
Kwaliteit: om te zien of de doelstellingen van een project passen binnen de strategie van de organisatie
Informatie: Om af te spreken hoe, wat en wanneer er gerapporteerd wordt over een project aan het management team?
Tijd: om te schatten hoeveel inzet van mensen er nodig is in een bepaalde periode om tot een goede verdeling te komen van de medewerkers over de projectteams.

Voor aanvang van een project en na elke projectfase moet de projectleider een inschatting geven van de GOKIT factoren voor de rest van het project. Daarnaast evalueert hij na elke fase de GOKIT factoren tot dan toe. Deze gegevens worden overlegd aan een programmamanager of aan het management team om al dan niet gezamenlijk met de projectleider en externe partijen (klanten, financiers) besluiten te nemen over het project. Hieronder staan een aantal van de belangrijkste besliscriteria beschreven, met name op het vlak van de afstemming van projecten.

Geld
Bij de beoordeling van geldzaken door een programma manager gaat het om de volgende zaken:

• Is het project als geheel en de volgende fase in het bijzonder voldoende gefinancierd?
• Wat zijn eventuele financiële risico’s van het project? Moet er een go-no-go moment worden afgesproken?
• Hoe is de liquiditeitsprognose van het project? Ontstaat er een probleem als de inkomsten van een project later zijn dan de uitgaven (bijvoorbeeld als de subsidie pas betaald wordt na afloop van een langdurig project)?

Door alle budgetten op te tellen kan de programmamanager een jaarplanning maken van de projecten. Daarbij let hij er op of er voldoende projectomzet in de pijplijn zit zodat de projectmedewerkers gefinancierd zijn. Bij onvoldoende projectomzet, moeten er nieuwe projecten geworven worden. Bij teveel omzet zal er extra personeel ingehuurd moeten worden en/of moeten projecten worden uitgesteld of zelfs afgeblazen.

Het geeft een beeld of de projecten als geheel financieel rendabel genoeg zijn. Stel dat je als organisatie 10 projecten doet van elk 2000 uur. Je hebt 20 FTE aan projectmedewerkers in dienst. Verderop zullen we zien dat daarmee ongeveer alle uren van die medewerkers zijn verdeeld. Stel dat deze 20 FTE per jaar een miljoen kosten aan loonkosten. Wanneer deze projecten minder dan een miljoen opbrengen (aan subsidie, interne financiering, commerciële opbrengsten) is er een probleem. Mogelijk moeten de tarieven worden aangepast of moeten onrendabele projecten geschrapt worden.

Voor projecten geldt dat de afwijking tussen begroting en reëel benodigde bedragen groot kunnen zijn. Met name als er sprake is van gesubsidieerde projecten kan de afwijking substantieel zijn (zie Projectrapportage). Om dit soort onzekerheid op te vangen moet de programmamanager een bedrag reserveren voor het opvangen van tegenvallers bij één of meer van de projecten.
Begrotingen zijn soms ook te ruim. In dat geval is het wel zaak dat projectleiders bereid zijn om delen van hun budget in te leveren. Anders kunnen projecten alleen maar binnen budget blijven óf te duur zijn. Als te duur ingeschatte projecten een deel inleveren aan de projecten die aanvankelijk te goedkoop zijn ingeschat zou de organisatie gemiddeld (redelijk) neutraal moeten uitkomen.

Wat doe je als organisatie als je 100.000 euro subsidie hebt gekregen voor een project en het blijkt dat je maar 80.000 euro nodig hebt? Dat geld komt wel op, er zijn zoveel nuttige dingen die nog gedaan kunnen worden voor dat geld. Bijvoorbeeld dat andere project dat 150.000 euro kreeg, maar dat eigenlijk 200.000 euro nodig had. Gelukkig is niet te achterhalen wat die programmeurs allemaal deden in de uren die ze schreven op de projecten. Dus een beetje schuiven met uren en het klopt allemaal weer.

Logisch dat organisaties zo omgaan met hun gesubsidieerde projecten, ze kunnen niet veel anders. Het is een direct gevolg van het feit dat organisaties bij een aanvraag een totaal budget moeten opstellen waar ze later niet meer van mogen afwijken. Een gevolg van deze situatie is dat de (financiële) projectrapportages van gesubsidieerde projecten met een korrel zout genomen moeten worden. Vanuit het oogpunt van projectmanagement is dat jammer omdat nu niet goed te achterhalen is hoeveel projecten echt gekost hebben. Vanuit het oogpunt van accountability van het subsidiegeld is het ook geen goede zaak.

Tijd
Als alle begrotingen van de uren van de projecten die een organisatie in een komende periode gaat uitvoeren bij elkaar opgeteld worden, geeft dat een indicatie van de werkdruk. Op jaarbasis moet het totaal aantal FTE in dienst meer zijn dan alle uren opgeteld uit de projectplannen.

Bijvoorbeeld: 10 projecten ‘verbruiken’ samen 20.000 uur. In de organisatie werken 20 FTE. Per FTE wordt er in onze organisatie 1700 uur gewerkt. Daarvan is 70% vrij voor projecten en 30% voor algemeen werk (vergaderen, email, reistijd, overige werkzaamheden, studieverlof). Netto komt dat neer op: 20 x 1700 x 70% = 23800 uur per jaar beschikbaar voor projecten. In dit voorbeeld is er dus globaal gezien voldoende capaciteit om deze projecten uit te voeren komend jaar. Veel meer kan er niet bij zonder meer mensen in dienst te nemen (ook hier is een marge nodig).

Bovenstaande controle is een globale controle op jaarbasis. Daarnaast is een fijnere controle van de capaciteit nodig, gespecificeerd naar de taken of rollen die projectmedewerkers hebben. Die 20 FTE moet verder onderverdeeld worden naar verschillende rollen binnen een project (bijvoorbeeld: programmeurs, projectleiders, designers, systeembeheerders). Het kan best zo zijn dat er in totaal voldoende mensen in dienst zijn om de plannen voor komend jaar uit te voeren, maar bijvoorbeeld te veel projectleiders en te weinig programmeurs.

Tenslotte moet de werklast (aantal verwachte uren) van de projecten niet alleen per jaar overeenkomen met het aantal beschikbare uren van de medewerkers, dit moet ook gelden voor kortere periodes. Als in het bovenstaande voorbeeld alle projecten gepland zijn in de eerste drie maanden van het jaar, is er toch een knelpunt, alhoewel er voldoende mensen in dienst zijn op jaarbasis.
De operationele verdeling van mensen op maand of zelfs weekbasis gebeurt op basis van de plannen van de fases van de projecten of tijdboxen als het gaat om cyclische projecten. Daarnaast is een wekelijks of maandelijks overleg van programmamanager met alle projectleiders nodig om de mensen operationeel in te plannen.

Ten aanzien van tijd wordt een aantal klachten veelvuldig gehoord in projectorganisaties:

• Er is geen goed beeld van de werkdruk die er heerst. De sales afdeling of het management blijven er maar nieuwe projecten bij doen terwijl we nu al niet goed toekomen aan de projecten die we nu moeten uitvoeren.
• Als één van de projecten uitloopt, dan heeft dat heel veel gevolgen voor andere projecten. Omdat we de resources moeten delen, betekent dat vertraging in het eerste project ook alle andere projecten vertraagt.

De eerste klacht komt veel voor bij snel groeiende organisaties waar men vooral oog heeft voor het werven van zoveel mogelijk omzet. Door bovenstaande controle mechanismen in te voeren, ontstaat er overzicht over de capaciteit op jaarbasis en op operationele basis van maand tot maand of zelfs week tot week.

De tweede klacht heeft een paar oorzaken. Allereerst is het bij organisaties waar deze klacht voorkomt vaak zo dat men niet goed in staat is oude projecten af te sluiten. Elke keer als het project klaar zou moeten zijn, komt er weer een nieuwe eis van de klant, een nieuwe bug of een uitbreiding op het project. Om dit tegen te gaan is het belangrijk om bij het begin van het project zo duidelijk mogelijke afspraken te maken wanneer het project klaar is. Zie ook eerdere hoofdstukken over dit probleem.

Daarnaast geldt er bij de tweede klacht ook dat er sprake is van een (te) hoge werkdruk. Omdat het zo druk is, worden er geen marges tussen de projecten gepland. Hierdoor heeft een kleine uitloop van een vorig project direct gevolgen heeft voor volgende projecten.

Tenslotte kan gezegd worden dat het tweede probleem minder vaak voor komt bij organisaties die cyclisch projectmanagement toepassen, omdat daar met vaste tijdboxen gewerkt wordt.

Om de productiviteit te verhogen wordt personeel vaak op te veel projecten ingezet. Een poging de verloren uurtjes te vullen met andere projecten leidt echter tot ernstige vertragingen. Het volgende voorbeeld illustreert dat (overgenomen en aangepast uit Goldratt, 2002):
Stel dat iemand een project A moet uitvoeren dat bestaat uit drie taken a en een project B moet uitvoeren dat bestaat uit drie taken b. Elke taak kost 5 eenheden tijd.
Als hij ze uitvoert in de volgorde aaa, bbb dan is taak A klaar na 5 + 5 + 5 = 15 eenheden. Taak B is ook na 15 eenheden klaar, gemeten vanaf het moment dat project B start.

Als hij ze echter niet na elkaar maar tegelijk, dat wil zeggen door elkaar moet uitvoeren, ziet het plaatje er anders uit. Stel dat hij een taak a steeds afwisselt met een taak b. De volgorde van werken is dan ababab.
Nu duurt het 5 + 5 + 5 + 5 + 5 = 25 eenheden voordat A klaar is en ook 25 eenheden voordat B klaar is. Daarbij het feit dat het switchen tussen projecten zelf ook tijd kost nog niet meegenomen.

Volgens (Goldratt, 2002) is de praktijk dat veel personeel binnen organisaties ingezet wordt op veel verschillende projecten tegelijk een van de belangrijkste oorzaken van het feit dat projecten (veel) te lang duren. Projecten waar een doorlooptijd van drie maanden voor staat duren in de praktijk soms wel meer dan twee jaar. Als de projecten één voor één na elkaar werden gedaan, waren ze elk na ongeveer drie maanden klaar geweest.

Uit bovenstaand voorbeeld, maar bijvoorbeeld ook uit de kennis van de wachtrijtheorie blijkt dat het niet verstandig is om het personeel te vol te bezetten. Uit kostenoverwegingen op korte termijn zijn management teams er vooral op gefocust om iedereen zo veel mogelijk te laten werken. Hierdoor gaat er veel snelheid in projecten verloren. Het kan best zo zijn dat het verhogen van de bezettingsgraad van het personeel met 10% leidt tot een verhoging van de gemiddelde doorlooptijd van projecten met 40%. Deze kosten van vertraging zijn echter veel minder zichtbaar, zeker in non-profit organisaties.

Tijdschrijven
Het is aan de programmamanager om bij aanvang van een nieuw project bovenstaande controles op financieel vlak en op gebied van urencapaciteit uit te voeren. Dit moet hij tevens doen tussen de fases van een project, dan worden de begrotingen immers bijgesteld.
Maar niet alleen het vooruitkijken is van belang, ook het evalueren van de uiteindelijk gerealiseerde begrotingen (van tijd en geld) moet gebeuren. Zijn de projecten inderdaad rendabel of kostendekkend geweest, zoals begroot? Had dat ene project inderdaad 450 uur nodig of is dit anders gelopen? Deze vragen moeten gesteld en beantwoord worden om de kwaliteit van het projectwerk in de toekomst te verbeteren.
Om deze evaluatie te kunnen uitvoeren is de aanwezigheid van een tijdschrijfsysteem noodzakelijk. Ook voor de wekelijkse sturing van projecten door projectleiders is een tijdschrijfsysteem overigens wenselijk.
In organisaties is er vaak weerstand tegen een tijdschrijfsysteem. Mensen voelen zich gecontroleerd en hebben een hekel aan administratieve klusjes. Een andere bron van weerstand is wellicht dat opeens zichtbaar wordt dat er (vaak) zo weinig vooruitgang geboekt is. Het implementeren van een geschikt tijdschrijfsysteem is een project op zich.
Een belangrijk argument voor het invoeren van een tijdschrijfsysteem is de transparantie die ontstaat. Medewerkers klagen (vaak) over een te hoge werkdruk. Het gebruik van een tijdschrijfsysteem waarin zowel de urenplanningen als de urenverantwoording staat maakt die werkdruk zichtbaar. Wanneer er nu een project ‘over de schutting’ gegooid wordt door het management of door de sales afdeling kan het projectteam zwart op wit aantonen dat het de komende tijd vol zit en dat het nieuwe project nog even moet wachten.

Waar moet een tijdschrijfsysteem aan voldoen?

• Een tijdschrijfsysteem moet door de hele organisatie gebruikt worden, ook door de boekhoudafdeling.
• Een tijdschrijfsysteem moet overal benaderbaar zijn (bv.webbased).
• Projectleiders moeten snel de rapportages van uren kunnen zien (er mag niet meer dan 1 week tussen tijdschrijven en interne rapportage zitten).
• In het tijdschrijfsysteem moeten de (uren-)planningen verwerkt zijn.
• In het tijdschrijfsysteem moet geschreven kunnen worden op werkpakketten in projectfases van projecten. Het schrijven op algemene projectnamen is niet afdoende.

De projectleiders hemel
Voor veel projectleiders is het lastig om de teamleden binnen de begroting te laten werken. Uitvoerenden lijken niet veel om de klok te geven en ook al is er een afspraak dat een klus niet langer mag duren dan een paar uur, er is altijd wel een reden waarom het toch langer duurde.

Bij een architectenbureau hebben ze dit probleem aangepakt door de verantwoordelijkheden om te draaien. De technische tekenaars van dat bureau moeten als interne freelancers hun werk gaan werven bij de projectleiders. Hierbij is onderlinge concurrentie toegestaan. Dus als een tekenaar zegt dat hij het in minder tijd kan dan zijn collega, krijgt hij de klus. Bovendien is 8 uur ook echt 8 uur. Dus als het niet klaar is, moet de technisch tekenaar het in zijn eigen tijd afmaken. Heerlijk om daar projectleider te zijn, misschien wat minder prettig om projectmedewerker te zijn.

Organisatie van meerdere projecten naast elkaar
In (Wijnen, 2004, p. 187 en verder) wordt er onderscheid gemaakt tussen drie structuren van projectmanagement ten opzichte van de moederorganisatie:

• de overleg- of coördinatiestructuur;
• de matrixstructuur;
• de zuivere projectstructuur.

In de overleg- of coördinatiestructuur bestaat het projectteam meestal uit alleen de projectleider zelf. Deze projectleider heeft niet veel gezag over andere medewerkers. Hij is bezig met een licht project, vaak onderzoekswerk om een advies aan het management uit te brengen. Als deze projectleider de inzet nodig heeft van andere medewerkers in de organisatie dan kan hij ze informeel om hulp vragen of moet hij dat via hun bazen regelen.

Figuur 13: Een project door middel van de overlegstructuur. De projectleider (vaak staflid) staat geheel buiten de afdelingen.

Bij de matrixstructuur is de organisatiestructuur zodanig opgezet dat de teamleden zowel in een projectteam werken (parttime) als in hun functie binnen de lijnorganisatie (parttime). Ook als mensen binnen meer projecten tegelijk werken zou je kunnen spreken van een matrixorganisatie.
Groot voordeel ten opzichte van de overlegstructuur is dat er sprake is van een projectteam dat bestaat uit meerdere mensen. Hierdoor kan dit projectteam meer realiseren dan in de situatie van de overlegorganisatie, omdat daar de projectleider er voornamelijk alleen voor staat. De projectleider heeft meer gezag in deze situatie. Hij heeft daadwerkelijk de leiding over zijn team. Voor de teamleden kan er op dit punt wel verwarring ontstaan omdat ze nu twee bazen hebben: de projectleider en het hoofd van de afdeling waar ze in werken. Als medewerkers in meerdere projecten tegelijk werken kan het zelfs zo zijn dat ze meer dan twee bazen hebben.

Het is belangrijk dat de afdelingshoofden en projectleider(s) onderling duidelijke afspraken maken over de inzet van mensen. De praktijk leert nog wel eens dat dit niet gebeurt. Van alle kanten wordt er aan medewerkers getrokken en die doen (noodgedwongen) eerst het werk van de baas die het hardst schreeuwt. Dat dit niet altijd het werk is dat de hoogste prioriteit heeft voor de organisatie als geheel, moge duidelijk zijn.

Figuur 14: Projecten georganiseerd volgens het matrix model. Leden van een projectteam hebben twee bazen: de projectleider en het afdelingshoofd.

Bij de zuivere projectstructuur, worden de medewerkers uit de organisatie gehaald en werken zij voor de duur van het project alleen maar in het project. Deze vorm is het meest geschikt voor grote, zware projecten. Het projectteam is in hoge mate autonoom en de teamleden hebben alleen de projectleider als baas. Belangrijk nadeel van deze structuur is dat het duur en ingrijpend is voor de organisatie. Medewerkers worden namelijk gedurende lange tijd van hun oorspronkelijke werk gehaald.

Figuur 15: Schema van de zuivere projectstructuur. Het projectteam staat redelijk autonoom buiten de rest van de organisatie

Het hangt voornamelijk van de projecten af, welke organisatiestructuur het beste is. Voor kleine projecten is de overlegstructuur goed geschikt en voor grote, langdurige en zware projecten is de zuivere projectstructuur het best geschikt. In de praktijk worden veel projecten georganiseerd door middel van een matrixstructuur omdat veel projecten tussen deze twee uitersten in zitten. Bij het matrixmodel is de coördinatie van de projecten wel het lastigst.

Tenslotte: in dit hoofdstuk behandelen we maar een stukje van programmamanagement, namelijk hoe je meerdere projecten tegelijk aanstuurt. Het werkveld van de programmamanager is uitgebreider en omvat ook zaken als het integreren en aansturen van de lijnafdelingen in samenhang met de projecten, de focus houden op de langere termijn resultaten van een programma en meer strategische aspecten van een organisatie. In de training programmamanagement die we aanbieden wordt het hele werkveld  van een programmamanager behandeld.