Informatieverspilling: te veel, te weinig of precies genoeg?

Januari 2009 - Bij het introduceren van een nieuw teamlid, laten we meestal eerst de gebruikelijke dingen zien – waar is de koffie, het toilet en de werkplek. We stellen hem aan de overige teamleden voor en laten een van de architecten of senior ontwikkelaars een uitleg geven van het systeem. De volgende stap is om de newbie; te voorzien van een enorme hoeveelheid documentatie om bekend te raken met het systeem. Omdat het teamlid nieuw is heeft hij waarschijnlijk nog geen toegang tot de informatie. We printen het uit, geven aan dat we altijd beschikbaar zijn om vragen te beantwoorden om vervolgens de newbie dagen of zelfs weken niet meer terug te zien.

In de tussentijd probeert de newbie boven de stapel documentatie zich te bekwamen in het systeem en vooral niet in slaap te vallen. Helaas is de documentatie niet meer actueel en tegenstrijdig en is door het gebrek aan systeemkennis niet duidelijk welke informatie relevant is.

Dit is een van vele vormen van informatieverspilling. De kosten die gepaard gaan met informatieverspilling zijn vaak niet direct zichtbaar, maar kunnen hoog oplopen. Zeker omdat informatie steeds belangrijker wordt in het besturen van en beslissen binnen een organisatie.

In dit Whitebook bespreek ik diverse vormen van verspilling. Het doel van het artikel is om u bewust te maken van verspilling binnen uw eigen organisatie of project. Ik zal een aantal mogelijke oplossingen bespreken. Vanuit agile frameworks zijn er al verschillende ideeën hoe informatieverspilling voorkomen kan worden die in dit artikel zullen terugkomen. Het biedt een andere blik op het omgaan met informatie en documentatie.

Verspilling

Vanuit de “Lean” filosofie kunnen we verschillende vormen van verspilling onderscheiden. Lean is een managementfilosofie die erop gericht is om verspillingen “Muda”, zaken die geen toegevoegde waarde leveren, te elimineren. De filosofie is oorspronkelijk ontstaan en ontwikkeld binnen de fabrieken van Toyota, maar wordt tegenwoordig steeds meer binnen kantooromgevingen toegepast.

Binnen lean worden zeven vormen van muda onderscheiden:

• Defecten: producten maken die niet goed zijn en dus geen geld opbrengen. 
• Overproductie: Teveel producten maken die blijven liggen en/of weggegooid worden. 
• Transport: producten, machines of mensen afstanden laten afleggen. 
• Wachten: producten, machines of mensen stil laten staan.
• Voorraad: voorraden, gereedschappen en machines in huis hebben.
• Beweging: onnodig bewegen van producten, machines of mensen.
• Te veel verwerking: producten beter maken dan waarvoor de klant betaalt.

Ook deze vormen van verspilling zien we terug in traditionele kantooromgevingen waar de focus ligt op informatie en niet op fysieke goederen. In dit artikel beperk ik me tot informatieverspilling binnen IT-projecten.

Defecten

Bij defecten kunnen we denken aan verkeerde data, informatie, rapportages. Het maken van sjablonen kan al veel defecten voorkomen. De sjablonen kunnen een basis vormen voor alle project documentatie. Belangrijk hierbij is dat er een doelgroep wordt genoemd. Als het niet helder is voor wie het document geschreven wordt, heeft het geen nut het document te schrijven. Benoem expliciet de verwachtingen van de beoogde doelgroep. Zorg er daarnaast voor dat duidelijk is welke (voor)kennis vereist is om het document te begrijpen. Bij het schrijven van een document moet het uitgangspunt altijd zijn: “Wie is de doelgroep?”, “Wat willen zij weten?” en “Wat kunnen zij begrijpen?

Overproductie

Ongecontroleerde processen, distributie van meer informatie dan nodig is. Het nieuwe teamlid leest de documentatie maar er ligt zoveel documentatie en het is erg gedetailleerd dat het niet bijdraagt aan zijn overzicht van de bestaande oplossing. In The Mythical man Month, beschrijft Frederick Brooks: “De meeste documentatie faalt in het geven van een overzicht. De bomen worden beschreven, de schors en de bladeren worden beschreven, maar er zit geen kaart bij van het bos.” (Brooks 1995)

     (bron: Geek & Poke)

Het is belangrijke om duidelijk focus in een document te brengen. Gerelateerde informatie moet in een apart document beschreven worden. Alle informatie die nodig is om de inhoud van het document te begrijpen moet erin verwerkt worden. Dit begint eigenlijk al met de titel van het document. De titel moet duidelijk aangeven wat er in het document beschreven wordt. Bij het schrijven van het document moet alles bijdragen aan het onderwerp van de titel.

Transport

Onnodig transport van informatie tussen mensen, organisaties of systemen. Het team waar we iemand aan willen toevoegen probeert naarstig alle documentatie actueel te houden. Ze proberen bij de domeinexperts en ontwikkelaars informatie in te winnen over de huidige oplossing. Eigenlijk betekent dit al dat de documentatie die nu gelezen wordt onmogelijk de huidige oplossing kan beschrijven.

Elk document moet één eindverantwoordelijke kennen. Dit hoeft niet te betekenen dat anderen er niet aan mogen bijdragen. De eindverantwoordelijke bewaakt de voortgang en is ook verantwoordelijk voor de coördinatie van andere bijdrages. Probeer de documentatie zo “licht” mogelijk te houden en bedenk dat allesomvattend documentatie niet bijdraagt aan het succes van het project. Het zal eerder de kans tot falen vergroten!

Wachten

Informatie die niet gebruikt wordt of nog verwerkt wordt. Bij het uitprinten van de documentatie om mee te geven aan het nieuwe teamlid moeten we eerst goed zoeken naar de laatste versie van de documenten. Het nieuwe teamlid kijkt met argusogen als hij ziet dat we in onze email gaan kijken naar een bijgewerkte versie die gestuurd was.

Voordat informatie gecreëerd wordt, moet al duidelijk zijn wat de vereisten zijn. De belanghebbenden zullen de vereisten tijdig bekend moeten maken. Zodra de informatie beschikbaar is moeten de belanghebbenden geïnformeerd worden. Hoe directer het contact tussen de belanghebbenden en de producent van de informatie, des te sneller dit zal gaan. Als het kan is het verstandig om belanghebbenden en producenten bij elkaar te brengen op dezelfde locatie.

Voorraad

Informatie die niet gebruikt wordt of nog verwerkt wordt. Bij het uitprinten van de documentatie om mee te geven aan het nieuwe teamlid moeten we eerst goed zoeken naar de laatste versie van de documenten. Het nieuwe teamlid kijkt met argusogen als hij ziet dat we in onze email gaan kijken naar een bijgewerkte versie die gestuurd was.

Voor verouderde informatie is het verstandig om een versiebeheersysteem te gebruiken. Documenten zullen vaak meerdere revisies ondergaan gedurende een project. Zorg ervoor dat het team en belanghebbenden alleen de meest actuele versie kunnen benaderen. Een centraal punt van toegang tot de documentatie is erg belangrijk. Dit maakt het eenvoudiger om te bewaken of er op een juiste manier gebruik van wordt gemaakt.

Beweging

Onnodige menselijke beweging (fysiek of gebruikersbeweging tussen hulpmiddelen of systemen). Zorg ervoor dat belangrijke project informatie duidelijk zichtbaar is voor iedereen. Vanuit Scrum en andere agile frameworks zien we vaak dat er een centrale plek gebruikt wordt om belangrijke informatie zichtbaar te maken. Denk hierbij bijvoorbeeld aan een muur of een whiteboard op de werkplek. Wanneer het team niet op een en dezelfde locatie werkt, zal deze informatie online of via een netwerk beschikbaar gemaakt moeten worden.

Te veel verwerking

Meer verwerking van de informatie dan er gevraagd wordt. Om excessieve goedkeuringen te voorkomen is het een instrument om de producent ervan te laten bepalen hoeveel beoordelingen er nodig zijn. De uiteindelijke goedkeuring staat niet ter discussie. Deze moet in ieder geval plaatsvinden. Deze beoordeling moet ruim voor de opleverdatum gepland zijn om wijzigingen nog mogelijk te maken.

Dan maar helemaal niet documenteren?

Informatieverspilling sluimert in elke organisatie. Gelukkig ontstaat er steeds meer een bewustzijn dat er op een nieuwe manier mee om moet worden gegaan. Helaas zien we in de praktijk dat veel organisaties agile als excuus gebruiken om niets meer te documenteren. Agile preekt om doordacht met documentatie om te gaan. Wanneer documenteren de beste manier is om een doel te bereiken dan moet het gedocumenteerd worden.

Conclusie

Door alert te blijven op de manier waarop gecommuniceerd wordt, kunnen veel onnodige kosten bespaard blijven. Het belangrijkste is communicatie en niet documentatie. Als het mogelijk is probeer het schrijven van documentatie te ontwijken.

Wanneer het schrijven van documentatie verplicht is of een doel dient zijn er een aantal belangrijke aandachtspunten:

• genereer systeem documentatie;
• laat de klant bepalen hoeveel documentatie nodig is;
• documenteer altijd (en alleen) met een duidelijk doel;
• behandel documentatie als een vereiste;
• bewaar de informatie op de meest geschikte plek;
• maak belangrijke informatie voor iedereen zichtbaar;
• focus op de behoefte van de afnemer van documentatie;
• hou de documentatie simpel genoeg, maar nooit te simpel;
• zorg ervoor dat belanghebbenden zich bewust zijn van de investering;
• maak iemand verantwoordelijk voor het bewaken van de documentatie en het beoordelen van documentatieverzoeken.

Referenties

• Agile Documentation – A Pattern Guide to Producing Lightweight Documents for Software Projects door Andreas Rüping, Wiley (19 September, 2003);
• Agile Modeling: Effective Practices for Extreme Programming and the Unified Process (Paperback) door Scott W. Ambler, Wiley; 1e editie (21 Maart, 2002);
• The Mythical Man-Month: Essays on Software Engineering door Frederick P. Brooks, Addison-Wesley Professional; 2e editie (12 Augustus, 1995).