De logica van projectmanagement

Je staat onder hoge druk om je project afgerond te krijgen. Gezien de middelen die je tot je beschikking hebt qua budget, tijd en mensen merk je dat het niet lukt op de manier zoals je het zou willen. Je vraagt aan je opdrachtgever om meer geld en meer tijd, maar krijgt ‘nee’ op het rekest. Er rest je niets anders dan in je project diverse bochten af te snijden en noodverbandjes aan te leggen.

Geen geld om het in één keer goed te doen, wel om het vijf keer te herstellen.

Uiteindelijk lever je het eindproduct op, on-time en on-budget. Maar je weet één ding zeker. Dit is niet goed verlopen. Ook weet je dat het herstel achteraf veel meer geld en tijd gaat kosten dan wanneer je het wel in één keer goed had mogen doen. Ziehier de logica van projectmanagement. Hoe komt het toch dat er in het bedrijfsleven en in de zorg vaak wel geld is om een krakkemikkige oplevering vijf keer te herstellen, maar zelden geld om het in één keer goed te doen?

Het Duivelskwadrant

Iedereen die geschoold is in projectleiding en -management weet dat tijd, geld, kwaliteit en functionaliteit de belangrijkste sturingsparameters in een project zijn. Gezamenlijk staan ze bekend als het Duivelskwadrant. Deze vier parameters hebben een grote afh ankelijkheid van elkaar. Verandert er één dan verandert minstens een van de andere parameters ook. Wanneer er bijvoorbeeld meer functionaliteit moet worden geleverd dan oorspronkelijk gepland, dan betekent dit dat het project meer tijd gaat kosten, of dat er ingeleverd wordt op kwaliteit. Wanneer de manager vindt dat het project in minder tijd klaar moet zijn, is dat alleen mogelijk als er minder functionaliteit of minder kwaliteit wordt geleverd. Aangezien tijd min of meer equivalent staat aan voor geld (‘tijd is geld’), wordt ook wel gesproken van de Duivelsdriehoek.

Sturing van projecten

In elk project zijn de sturingsparameters tijd en geld dominant, want deze zijn het meest zichtbaar. Helaas komen bij de start van het project de schattingen rondom de benodigde hoeveelheid tijd en geld veelal tot stand op basis van een schatting op de spreekwoordelijke achterkant van het sigarenkistje. Grove aannames, wishfull thinking en dagdromerij spelen in dit proces veelal een doorslaggevende rol. Zeker voor de parameter geld geldt vaak dat iemand een bedrag in zijn hoofd heeft ‘waarvoor het zeker allemaal moet kunnen’.

Ook bekend is de ‘truc’ om het geschatte benodigde budget kunstmatig laag te houden, zodat er een grotere kans is dat het project gestart mag worden. Een veel gehoorde frase is: ‘Als we het budget te hoog inschieten, mogen we zeker niet van start.’ Ondanks deze, laten we zeggen, weinig wetenschappelijke methode om diverse paramaters vast te stellen, worden deze grove aannames welhaast heilige grootheden zodra ze zijn opgenomen in projectplan. Daar komt nog bij dat de opleverdatum van het projectproduct vaak een zogenaamde ‘fantasy deadline’ is. Een ‘heilige’ datum zoals de eerste januari van het nieuwe jaar, of de eerste dag van een nieuw schooljaar, of de dag waarop een nieuw filiaal wordt geopend. Deze data worden duidelijk als mijlpaal herkend en krijgen mede daarom een duidelijke urgentie omgehangen. Feit blijft dat zo’n fantasy deadline zelden goed is doorgerekend om er zeker van te zijn dat het wel passend is voor scope van het project. De Overheid is berucht om het fenomeen ‘fantasy deadlines’: grote wijzigingen in de belastingwetgeving worden pas in het najaar door de Tweede Kamer ‘gejaagd’ en dan verwacht men dat de grote wijzigingen al op 1 januari van het aankomende jaar in de IT-systemen zijn ingebouwd, wat volstrekt onmogelijk is. Toch hebben de politici hun politieke voortbestaan aan die datum gekoppeld.

Onzichtbaar

De projectsturingsparameters tijd en geld zijn vooraf bekend en blijven gedurende het project continu zichtbaar, omdat ze gemonitord worden. Dit is veel minder sterk het geval voor de parameters kwaliteit en functionaliteit. Projectleider, het projectteam en de opdrachtgever sturen hier veelal niet of nauwelijks op. Kwaliteit speelt zich over het algemeen af ‘onder de motorkap’.

Het is zichtbaar voor de projectmedewerkers, lastig zichtbaar voor de projectleider, maar niet of nauwelijks zichtbaar voor de opdrachtgever. Bovendien blijkt onvoldoende of ronduit slechte kwaliteit meestal pas in de gebruiksen onderhoudsfase, als het project snel-snel is afgeraff eld. Voor functionaliteit geldt iets soortgelijks. De projectteamleden zien een tekort aan functionaliteit, maar een echt functionaliteitstekort wordt pas opgemerkt bij oplevering van het projectresultaat door de gebruikers. Zelfs wanneer er tussentijds gebruikerstesten plaatsvinden en gebruikers melding maken van ‘tekorten’, wordt dit vaak te laat serieus genomen. Dit heeft alles te maken met het wegfilteren en voor je uit schuiven van slecht nieuws.

Overigens komt het ook vaak voor dat ‘tekorten’ aan functionaliteiten gedurende het project ontstaan, doordat er tussentijds door opdrachtgever(s) steeds meer functionaliteit wordt toegevoegd. Dit wordt wel scopecreep genoemd. Als vooraf niet heel goed beschreven is wat de ‘scope’ van het project is (wat moet er af zijn, als het project is afgerond?), dan wordt vaak de projectleider opgezadeld met dit scopingsprobleem. “Ja hoor eens,” zegt een opdrachtgever dan, “het is toch logisch dat we deze eis hebben?! Als jij je beter had verdiept in onze business had je geweten dat dit tot de scope hoorde. Kijk maar hoe je het oplost, zolang het er straks maar in zit.”

Wegfilteren van slecht nieuws

Mensen zijn slecht in het objectief beoordelen van signalen. Als iedereen positief is, wat bij aanvang van een project vrijwel altijd het geval is, worden negatieve signalen over het verloop van het project gemakkelijk genegeerd. Hierboven gaven we al aan dat door gebruikers tijdens testen gesignaleerde tekorten gemakkelijk door projectleider en stuurgroep worden genegeerd met bezweringen als: “Och, dat komt nog wel goed, we hebben nog tijd zat om dit te repareren.” Of: “Gebruikers kunnen toch zulke enorme zeurpieten zijn.” Of: “Ja, wat willen ze nu? Dat we alle uitzonderingen in de processen gaan automatiseren? Dat doen we dus niet. We gaan voor de mainstream.”

Dit wegfilteren van slecht nieuws zorgt er wel voor dat signalen over tekortkomingen te laat door projectleden worden gemeld aan de projectleider en door projectleider te laat worden gemeld aan de opdrachtgever.

The day-after

En dan is het zover. Het geld is bijna op en de tijd is op: de deadline nadert. De stress die dit kan veroorzaken in de situatie dat nog lang niet alles is gebouwd en getest, staat in de inleiding van dit artikel beschreven. Het ‘het feest van de oplevering’ moet koste wat het kost doorgaan. Daarna krijgt het projectteam decharge en wordt elders ingezet. Het duurt niet lang of de geluiden over de tekortkomingen, die ook al tijdens het project te horen waren, worden steeds luider. Wat werd afgedaan als ‘gezeur van gebruikers’ en ‘uitzonderlijke situaties’ blijken nu vaak serieuze issues. Het grote verschil tussen de situatie tijdens het project en de situatie na oplevering, is dat het lijnmanagement in de business nu direct hinder ondervindt van de onvolkomenheden en stevig van zich laat horen.

Soms zijn de issues zelfs zo ernstig dat er niet eens fatsoenlijk te werken valt met het opgeleverde projectresultaat. In het ergste geval wordt het gebruik stilgelegd en wordt valt men terug op oude systemen en oude werkwijzen. Gelukkig is het vaak niet zó ernstig. Maar onmiskenbaar zijn er herstel- en verbeteracties nodig. Een nieuw project wordt gestart, een ‘verbeterproject’.

Het verbeterproject

Vaak wordt begonnen met een inventarisatie van de tekortkomingen. Soms is er een document van het vorige projectteam, een overdrachtsdocument, waarin het team beschreven heeft wat er allemaal nog niet (helemaal) gereed was gekomen. Soms zelfs met een bijgesloten planning en budget. Als er een nieuw team wordt gevormd om de verbeteringen door te voeren en ze gaan aan de slag met de erfenis van het vorige team, wordt een nieuwe ‘teleurstelling’ al bij voorbaat ingebouwd. Immers, het nieuwe team moet zich eerst inwerken en de materie eigen maken en kan dus nooit zo snel werken als het vorige team. Het risico is niet denkbeeldig dat dit nieuwe team, als de druk om snel op te leveren te hoog oploopt, ook begint met het leggen van noodverbandjes om de nieuwe deadline te kunnen halen. Binnen deze constellatie kan het zomaar gebeuren dat het volledige project qua tijd en budget meerdere keren ‘over de kop gaat’.

Herkenning

Bij de voorbereidingen van dit artikel en de vele gesprekken die we hadden, merkten we dat vrijwel iedereen dit fenomeen kent van wel geld om het vijf keer te herstellen en geen geld om het in één keer goed te doen. Het is dan ook de vraag of het een onvermijdelijk verschijnsel is van grote projecten. Kán een project wel in één keer goed gaan? Een project is immers per definitie ‘iets nieuws’ dat nog niet eerder is gedaan, dus er is geen ervaring.

Ook wordt vaak aangegeven dat ‘IT een jong vak is’ en dat het dus logisch is dat IT-projecten vaker fout gaan dan bijvoorbeeld grote bouwprojecten. Wij vragen ons af of dit wel waar is. Ook bij vakgebieden die al veel ouder zijn dan IT gaan dingen mis. Recent kwam een nieuw viaduct over een kanaal in het nieuws dat bij oplevering zeven centimeter te laag bleek. Dus klaarblijkelijk gaan er ook bij niet IT-projecten zaken flink mis.

Tips

Tot slot geven willen we een aantal tips die de kans op ‘herhaaldelijk falen’ aanzienlijk verkleinen. Het lijken ‘open-deuren’ maar wij zien in onze praktijk dat deze desondanks lastig intrapbaar blijken!

Tip: besteed veel tijd aan de voorbereiding
Vaak zijn opdrachtgevers erg optimistisch en ‘eager’ om met het project van start te gaan zonder voldoende duidelijkheid te hebben wat nu precies de scope is van het project; wat moet er af zijn als het project gereed is? Men zegt niet voor niets ‘asumption is the mother of all fuckups’. Vaak denkt men dat men het over hetzelfde heeft , maar vaak blijken de werelden mijlenver van elkaar af te liggen.

Tip: knip het project op in kleinere delen
Niet voor niets is Agile een succes. Knip het project op in kleinere delen en zorg ervoor dat ieder deel een werkend en bruikbaar geheel oplevert.

Tip: let op voor teveel ‘projectoptimisme’
Iedereen is optimistisch en kritische geluiden worden weg gefilterd. Wees hierop bedacht.

Tip: 'kwaliteit van mensen’
Uiteindelijk staat of valt ieder project met wat wij noemen ‘kwaliteit van mensen’. Durf lef te hebben. Durf te zeggen: “Zo kan het niet, dit is niet goed genoeg.”