Een project­dashboard laten maken: zo pak je dat aan

De meeste project­dashboards ontstaan uit een gevoel: we hebben geen overzicht. Dat gevoel is echt, maar het is geen opdracht. Zolang niet duidelijk is welke vraag beantwoord moet worden, komt er een scherm met grafieken waar iedereen even naar kijkt en dat daarna langzaam veroudert.

De vraag is bovendien per rol verschillend. Een projectleider wil weten waar zijn project vastloopt en wie hij moet aanspreken. Een directie wil weten welke projecten uit de pas lopen en of de portefeuille als geheel nog haalbaar is. Een controller wil weten wat er verbruikt is tegenover wat er begroot was. Dat zijn drie verschillende schermen op dezelfde gegevens.

Begin daarom bij het besluit. Wat gaat iemand anders doen als het dashboard rood kleurt. Als daar geen antwoord op is, meet u iets wat niet tot handelen leidt en kunt u het beter weglaten. Die toets scheelt doorgaans de helft van de gewenste grafieken.

Voortgang in procenten is het meest gevraagde en minst betrouwbare cijfer in projecten. Het probleem is bekend: alles staat lang op negentig procent. Dat komt doordat mensen inschatten hoeveel werk ze hebben gedaan en niet hoeveel er nog komt, en het laatste stuk bijna altijd tegenvalt.

De bruikbare uitweg is meten aan iets wat af is of niet af is. Een onderdeel is opgeleverd of het is dat niet. Een mijlpaal is gehaald of gemist. Een taak is afgerond of loopt nog. Dat zijn harde feiten die niemand hoeft in te schatten, en het gemiddelde daarvan is een eerlijker beeld dan een percentage dat iemand invult.

Dat betekent wel dat uw projecten in voldoende kleine stukken moeten zijn opgedeeld. Een project met drie onderdelen van elk drie maanden geeft een dashboard dat kwartalen niets doet en dan ineens naar honderd springt. Wie op voortgang wil sturen, moet zijn werk zo opdelen dat er wekelijks iets afkomt.

Een planning alleen vertelt niet genoeg. Een project kan precies op schema liggen en tegelijk het budget hebben opgemaakt, of binnen budget blijven doordat er niemand aan werkt. Pas als planning, budget en bezetting naast elkaar staan, ziet u wat er werkelijk gebeurt.

Bezetting is daarbij het cijfer dat het vaakst ontbreekt en het meest verklaart. Projecten lopen zelden uit omdat het werk moeilijker was dan gedacht; ze lopen uit omdat de mensen die het moesten doen aan iets anders werkten. Een dashboard dat laat zien hoeveel uren er werkelijk naar een project gingen, verklaart de meeste vertraging zonder dat iemand het hoeft uit te leggen.

Voor budget geldt hetzelfde als bij werkbegrotingen in de bouw: tel verplichtingen mee. Een ingekochte dienst die nog niet is gefactureerd, is wel degelijk uitgegeven geld. Een dashboard dat alleen facturen telt, laat een project er ruimer uitzien dan het is, precies in de periode waarin bijsturen nog kan.

Een dashboard maakt zelf geen gegevens. Het toont wat er elders al gebeurt, en dat is meteen de belangrijkste ontwerpvraag: welke systemen gebruiken uw mensen toch al, en wat kunt u daaruit halen. Taken staan vaak in een werkverdeel­systeem, uren in een urenregistratie, kosten in de boekhouding en mijlpalen soms alleen in een spreadsheet.

Waar het misgaat is de verleiding om het dashboard zelf gegevens te laten verzamelen. Een scherm waarin een projectleider wekelijks een status invult, lijkt een eenvoudige oplossing en is de snelste route naar een dashboard dat niemand vertrouwt. Na drie drukke weken staat de helft op oud en is het beeld erger dan geen beeld.

Als een gegeven nergens vandaan te halen is, zijn er twee eerlijke keuzes. Of u laat het weg, of u regelt eerst dat het ergens wordt bijgehouden als onderdeel van werk dat toch al gebeurt. Wat u niet moet doen, is een extra invoerhandeling introduceren die alleen voor het dashboard bestaat.

• Inventariseer welke systemen er al zijn. Taken, uren, kosten en documenten. Begin bij wat er is in plaats van bij wat u wilt tonen.
• Haal op in plaats van te laten invullen. Elk veld dat iemand speciaal voor het dashboard invult, veroudert. Automatisch opgehaald niet.
• Zorg dat projecten overal dezelfde code hebben. Zonder gedeelde projectcode zijn uren en kosten niet aan hetzelfde project te koppelen.
• Toon wanneer gegevens voor het laatst zijn bijgewerkt. Een cijfer zonder datum wordt vertrouwd, ook als het van drie weken geleden is.
• Laat een gegeven liever weg dan het te schatten. Eén onbetrouwbaar cijfer op een scherm maakt de rest ook verdacht.

Het verschil tussen een dashboard dat gebruikt wordt en een dat na een maand wordt genegeerd, zit in wat er als eerste in beeld komt. Een volledige tabel van alle projecten met alle cijfers is volledig en onbruikbaar. Wie moet zoeken naar wat er aan de hand is, doet dat twee keer en daarna niet meer.

Toon daarom eerst de afwijkingen. Welke projecten lopen uit de pas, welke mijlpaal is gemist, welke post loopt over budget. Daaronder de rest, voor wie doorkijkt. Dat is dezelfde opbouw als een goede krantenpagina: het belangrijkste bovenaan, de volledigheid eronder.

Wees terughoudend met kleur. Als alles kleur heeft, betekent kleur niets meer. Gebruik rood en oranje alleen voor wat echt aandacht vraagt, en laat de rest neutraal. En koppel kleur aan een grens die vooraf is afgesproken, want anders wordt het per project een discussie of iets wel of niet rood hoort te zijn.

Veel organisaties willen uiteindelijk vooruitkijken: gaat dit project het halen, en wat gebeurt er met de rest van de portefeuille als we hier iemand weghalen. Dat is een zwaardere stap, omdat voorspellen betrouwbare historie vraagt en die is er in het begin niet.

De eenvoudigste bruikbare vorm van vooruitkijken is doortrekken wat er tot nu toe is gebeurd. Als er de afgelopen zes weken gemiddeld vier onderdelen per week zijn afgerond en er staan er nog veertig open, dan is dat een aanzienlijk eerlijker voorspelling dan een planning die iemand ooit heeft gemaakt. Die rekensom kan zodra u afgeronde onderdelen bijhoudt.

Wat u vooral niet moet doen, is voorspellen op basis van ingeschatte percentages. Dan vermenigvuldigt u een onbetrouwbaar getal met een aanname en presenteert u de uitkomst als prognose. Dat is precies de soort cijfers waardoor mensen dashboards gaan wantrouwen.

1. Benoem het besluit per schermWat gaat iemand anders doen bij rood. Zonder antwoord hoort de grafiek er niet op.
2. Kies uw voortgangsmaatAfgeronde onderdelen of gehaalde mijlpalen, nooit een ingeschat percentage.
3. Deel het werk klein genoeg opZodat er wekelijks iets afkomt en het dashboard beweging laat zien.
4. Haal gegevens op uit bestaande systemenTaken, uren en kosten, met een gedeelde projectcode zodat ze aan elkaar te koppelen zijn.
5. Zet planning, budget en bezetting naast elkaarPas in combinatie laat het zien wat er werkelijk aan de hand is.
6. Toon afwijkingen bovenaanEn de volledige lijst eronder, met de mogelijkheid om door te klikken naar de bron.
7. Spreek de grenzen af waarop iets kleurtVooraf, met de betrokkenen, zodat kleur geen discussie wordt maar een signaal.
8. Ga pas voorspellen als u historie hebtTrek door wat er werkelijk is gebeurd, in plaats van te rekenen met schattingen.

Het bouwen van de schermen is bij dit type project zelden de grootste post. Het geld zit in het ophalen en op elkaar aansluiten van gegevens uit meerdere systemen, en in het oplossen van het feit dat dezelfde projecten daar verschillend heten of anders zijn opgedeeld.

De tweede factor is het aantal rollen dat u bedient. Eén scherm voor projectleiders is aanzienlijk goedkoper dan drie schermen voor drie rollen met elk hun eigen rechten en hun eigen definitie van wat belangrijk is. Begin bij de rol die het vaakst een besluit neemt en breid uit als dat scherm wordt gebruikt.

De derde is of u alleen toont of ook voorspelt. Tonen is ophalen en presenteren. Voorspellen vraagt betrouwbare historie, rekenwerk en een uitleg waarom een prognose is zoals hij is. Als het budget beperkt is, kies dan tonen en stel voorspellen uit tot u weet of de gegevens het dragen.

Vraag een bouwer als eerste wat hij zou weglaten. Iemand die op elke gewenste grafiek ja zegt, bouwt een scherm dat volledig is en niet gebruikt wordt. Iemand die vraagt welk besluit met een grafiek genomen wordt en er vervolgens een paar afraadt, snapt waar dit type project op stukloopt.

Vraag daarnaast hoe hij omgaat met gegevens die ontbreken of verouderd zijn. Een dashboard dat een leeg veld als nul toont, liegt. Een dashboard dat laat zien dat een bron sinds vorige week niets heeft geleverd, is eerlijk. Dat verschil bepaalt of mensen de cijfers op termijn nog vertrouwen.

En spreek af dat u na een maand evalueert welke schermen daadwerkelijk zijn geopend. Dat is meetbaar, en het is de enige eerlijke toets of het dashboard zijn werk doet. Wat niet wordt geopend, haalt u weg in plaats van het te laten staan omdat het ooit is gevraagd.

• Vraag wat de bouwer zou weglaten. Iemand die alles bouwt wat u vraagt, helpt u niet aan een bruikbaar dashboard.
• Eis eerlijkheid over ontbrekende gegevens. Leeg is niet nul, en een verouderde bron hoort zichtbaar te zijn.
• Laat de projectcodering vooraf uitzoeken. Zonder gedeelde code sluiten uren en kosten niet aan op het project.
• Meet het gebruik na een maand. Welke schermen worden geopend, door wie en hoe vaak. Haal weg wat niemand bekijkt.
• Houd het aantal schermen laag bij de start. Eén scherm dat wordt gebruikt, is meer waard dan vijf die volledig zijn.

• Gids: KPI-dashboard
• Gids: managementdashboard
• Gids: kanban-app
• Gids: datavisualisatie