Op de vraag wat dan die juiste stuurinformatie is ontstaat een interessante discussie. Het komt erop neer dat meestal wordt gestuurd op de bekende indicatoren zoals tijd, geld en kwaliteit, terwijl dit eigenlijk alleen consequenties zijn van wat er zich eerder afspeelt in het project. Zijn de tekeningen en de vergunningen op tijd? Zijn de juiste mensen en middelen beschikbaar? Wat zijn de resultaten van de uitgevoerde testen? Hoeveel wijzigingsverzoeken zijn ingediend of staan uit, et cetera? Per (type) project zou je moeten kijken welke informatie een goede indicator is voor de voortgang en de bestedingen. Om goed zicht te krijgen op deze indicatoren kun je het beste gebruik maken van slip-charts. Dit zijn overzichten zoals die ook worden gebruikt door Scrum/agile teams (burn-down charts).

Status voortgang en de projecteindeverwachting

Een andere vraag is of je wel kunt sturen op basis van wat iemand zegt? Of is het beter een verdiepingsslag te maken? Helaas wordt de voortgang die wordt gerapporteerd niet altijd gerelateerd aan de planning. Personen zijn vaak te nauw betrokken bij de situatie om de problemen te zien. Het ontbreekt aan regelmatige opnames van de stand van zaken: meten is weten. Er zijn geen tussentijdse kwaliteitsreviews; het is onduidelijk of het opgeleverde product ook daadwerkelijk goed is en wordt geaccepteerd. Tenslotte willen personen geen problemen rapporteren. Er is angst om te falen. Men is bang voor de consequenties of men wil tijd creëren om zelf eerst de problemen op te lossen. Allemaal redenen om vraagtekens te zetten bij de gerapporteerde voortgang. 

“Realiseer je dat ook opdrachtgevers eigenlijk alleen groen en geen oranje en zeker geen rood willen zien”

Naast de inhoudelijke rapportage van de voortgang en de projecteindeverwachting is het ook van belang te rapporteren op hygiënefactoren. Wanneer is de informatie voor het laatst aangepast? Wanneer zijn het projectplan en het faseplan voor het laatst geactualiseerd. Wanneer is de projecteindeverwachting nog bijgesteld? Het kan niet waar zijn dat voor projecten die soms meer dan een jaar lopen de projecteindeverwachting nooit wijzigt gedurende de looptijd van het project. Het is ook onwaarschijnlijk dat bijna alle projecten exact conform budget worden opgeleverd. 

De sturing van agile teams vraagt weer om een andere aanpak. Hierbij moet je onderscheid maken tussen teams verantwoordelijk voor het onderhoud en beheer van bepaalde applicaties (DevOps) en teams die moeten leveren in een projectcontext. In de eerste situatie zal de ‘bewaking’ zich beperken tot het in de gaten houden van de omvang van de product backlog, of de teams zich houden aan de overeengekomen werkwijzen en de kwaliteit van de opgeleverde producten op het eind van de opeenvolgende timeboxes. 

In welke situatie zou je in moeten grijpen? 

Dat is een laatste vraag die wij stelden. Net zoals je waarschuwingsfactoren kunt benoemen voor hygiënefactoren, kun je ook menselijke waarschuwingsfactoren benoemen. Kijk daarbij bijvoorbeeld naar hoeveel beweging er is in het team en of er problemen zijn in de relatie met de klant of andere belanghebbenden. Als je merkt dat er veel geklaagd wordt, men vaak afwezig is of dat er veel teamwisselingen zijn, moeten echt direct de alarmbellen afgaan. 

Bij projecten gaat het altijd om de klantbeleving. Bert geeft het sprekende voorbeeld dat de tijd- en budgetoverschrijding van de verbouwing van het Rijksmuseum niet heeft geleid tot een gevoel van wanprestatie. Luisteren naar wat de klant en de gebruikers willen, het meebewegen met de ontwikkelingen en het blijven leveren van toegevoegde waarde zijn daarbij van het grootste belang. Wat telt is dat (alle) belanghebbenden op het eind van het project tevreden zijn met het geleverde resultaat.