Informatiemanagement
Een project doen betekent iets nieuws maken of op een nieuwe manier iets maken. Nieuwe ontwikkelingen leiden tot nieuwe informatie. Al deze informatie moet worden verwerkt, beheerd en gedistribueerd.
Omdat veel van de informatie nodig is om verder te werken aan het projectresultaat moeten medewerkers aan het project op de hoogte zijn van wat binnen het project ontwikkeld wordt. In het bijzonder moeten wijzigingen in de stand van zaken tijdig worden doorgespeeld aan de teamleden die met deze informatie verder moeten werken.
Soorten informatie
Gedurende de loop van het project worden nieuwe producten ontwikkeld, nieuwe technieken uitgedacht. Dat soort ontwikkelingen levert informatie op. Daarnaast is er sprake van beheersinformatie: hoever zijn we, wat is er af, wat zijn de knelpunten, wat heeft het gekost, maar ook: hoever moeten we nog, wat zal het nog gaan kosten, hoeveel tijd hebben we nog nodig. Ook is er informatie die vooral na de realisatiefase nodig is: historische informatie voor het moederbedrijf en de opdrachtgever, documentatie voor de gebruiker. Hoewel die informatie pas in een later stadium nodig is, kan er niet mee gewacht worden tot het projectresultaat is opgeleverd. Veel informatie is tegen die tijd niet meer te achterhalen.
Al die informatie kunnen we op de volgende manier indelen (uiteraard zijn diverse andere indelingen mogelijk):
Gegenereerde informatie
- inhoudelijk
-
- over het product
-
- naar de opdrachtgever
- naar de gebruiker
- naar de beheerder
- van het product
-
- voorlopige spec's
- definitieve spec's
- beheersinformatie
-
- verleden (wat is af)
- toekomst (wat moet nog)
- budget en kosten
- planning
- buiten het project
-
- verouderd (niet meer bruikbaar)
- historisch archief (wellicht herbruikbaar)
Elk van deze informatiestromen zal nu kort beschreven worden:
- Informatie die uit het project naar buiten stroomt, wordt binnen het project niet meer gebruikt. Dat kan zijn omdat de informatie verouderd is. Veel van die informatie moet toch bewaard worden. Dat kan mislukkingen betreffen (doe het nooit meer zo), elementen die binnen het onderhavige project niet bruikbaar zijn, maar wellicht in een ander project wel, informatie over gebruikte technieken en ontwikkelde deelresultaten (dat kan een duplicaat zijn van informatie die wel in het project verder gebruikt wordt) en beheersinformatie (wat kost het aan tijd en geld om een activiteit uit te voeren). Deze informatie wordt dan onderdeel van de historische informatie van de projectorganisatie, waar toekomstige projecten uit kunnen putten.
- Inhoudelijke informatie beschrijft het te bereiken resultaat. De kern daarvan wordt gevormd door de deelinformatie van het product, waarmee binnen het project verder wordt gewerkt. De eisen of requirements, bouwtekeningen, afspraken over definities en interfaces en dergelijke, vormen vitale informatie voor de projectmedewerkers. Voor deze informatie is vooral van belang dat zij actueel is, de huidige stand van zaken aangeeft en dat duidelijk is welke informatie definitief is en waar nog wijzigingen verwacht kunnen worden.
Een ander deel van de inhoudelijke informatie is niet direct bedoeld voor de teamleden, maar handelt over het product en is bedoeld voor degenen die het resultaat later moeten gaan gebruiken. Dat betreft uiteraard de gebruikershandleiding, maar ook specificaties over de technische werking die onder andere voor onderhoud en verdere ontwikkeling van belang zijn. Zonder deze documentatie is het resultaat niet bruikbaar en het vervaardigen ervan moet dan ook als een integraal onderdeel van het project gezien worden. Ook is het niet aan te raden het maken van deze documentatie te laten rusten tot het eind van het project. Veel zaken zijn dan weggezakt en het waarom van sommige specificaties is niet meer te achterhalen. Bovendien verkijken velen zich op de hoeveelheid werk die samenhangt met het maken van gebruikersdocumentatie. Als het “tastbare” resultaat af is, is het moeilijk de teamleden nog te motiveren veel werk te steken in deze documentatie. - Tenslotte is er de beheersinformatie, de informatie over het verloop van het proces. Er moet verantwoording afgelegd worden over het verleden. Hoeveel tijd is er besteed, hoeveel geld uitgegeven en wat is er gerealiseerd. Deze informatie vormt weer het uitgangspunt voor de toekomstgerichte beheersinformatie: wat moet er nog gebeuren, hoeveel tijd en geld zal dat kosten en wat zal het opleveren. De combinatie van informatie uit verleden en naar de toekomst vormt op de mijlpalen de basis voor de voortgangsbeslissingen.
Een informatieplan
Bij het maken van het projectplan moet niet alleen vastgesteld worden wat met het project beoogd wordt, maar ook hoe daar binnen het projectteam aan gewerkt zal worden. Dat is wat anders dan de vraag die centraal staat in de voorbereidingsfase. Daar wordt vastgesteld hoe het ontworpen eindproduct zal worden gerealiseerd. Bij het ontwerpen van de werkwijze binnen het project hoort ook de vraag hoe met informatie om zal worden gegaan. Het maken van een dergelijk plan is één van de centrale taken van de projectleider, bij grotere projecten bijgestaan door zijn of haar staf.
Welke vragen moeten opgelost worden bij het opstellen van een informatieplan? Ten eerste moet een projectarchief worden opgezet. In dat archief moet de laatste stand van zaken beschreven staan, zodanig dat elk teamlid de voor hem belangrijke informatie kan terugvinden. De indeling van het archief is dus belangrijk, deze moet onder andere gebaseerd zijn op indelingen binnen de projectorganisatie (fasering, work break-down, deelprojectgroepen of onderaannemers). Ook moet worden vastgesteld welke verantwoordelijkheid de verschillende teamleden en deelgroepen hebben bij het aanleveren van informatie. Die informatie moet voldoen aan bepaalde standaarden om onderlinge vergelijking mogelijk te maken. Daarbij moet speciale aandacht besteed worden aan de onderlinge relaties tussen deelprojecten en verschillende activiteiten. De rapportagestandaarden moeten mede gebaseerd zijn op een relatieschema (dat ook onderdeel is van het projectarchief) waarin terug te vinden is op welke wijze activiteiten aan elkaar gerelateerd zijn.
Verder moet aandacht besteed worden aan de vraag voor wie alle informatie bedoeld is. Intern, binnen het project is daarbij het relatieschema van groot belang. Daarnaast is er beheersinformatie die in eerste instantie de projectleider aangaat, maar wellicht ook de financiële afdeling (gemaakte kosten) en de verschillende resourcemanagers die mensen en materieel moeten leveren voor het project (bij het wijzigen van tijdplanningen). Ook de opdrachtgever heeft behoefte aan informatie, maar op een zodanig aggregatieniveau dat beslissingen optimaal ondersteund worden. In het bijzonder is het belangrijk om vast te stellen welke informatie nodig is voor de beslispuntdocumenten. Bij veel projecten zijn er nog andere externe groepen die geïnformeerd moeten worden. Denk aan de overheid in verband met vergunningen, het publiek in verband met inspraak of publiciteit rond het project.
Al de genoemde groepen hebben behoefte aan deelinformatie. Soms zal het uit oogpunt van geheimhouding omgewenst zijn om alle informatie overal naar toe te sturen, maar belangrijker is dat informatie gedoseerd moet worden. Elke groep heeft maar een deel van de informatie nodig en een teveel aan informatie maakt het moeilijk om de juiste acties te ondernemen.
Status van informatie (vrijgave)
Tenslotte willen we nog de status van de informatie noemen en de bevoegdheden om informatie te wijzigen. Tijdens een project verandert er veel. Voorlopige schetsen worden definitieve ontwerpen, definities worden aangepast, ideeën veranderen. Voor de betrokkenen is het belangrijk te weten of informatie definitief is, of dat er rekening gehouden moet worden met wijzigingen. Dat houdt ook in dat informatie altijd gedateerd moet worden en voorzien van een versienummer. Als niet na te gaan is welke informatie het meest actueel, is zullen verschillende betrokkenen een verschillend beeld hebben van de “werkelijkheid”.
Niet iedereen mag zomaar informatie wijzigen. Wijzigingen hebben altijd consequenties, meerdere personen en groepen kunnen daarmee geconfronteerd worden. Daarom zal men bij het maken van een informatieplan altijd een procedure moeten ontwerpen voor het maken van wijzigingen. In het algemeen is daarbij sprake van twee verschillende procedures.
Resultaten waarvan bekend is dat het ontwerp al klaar is (vrijgegeven) mogen niet meer gewijzigd worden. Is dat toch nodig, dan moet er een zware procedure doorlopen worden. Immers, andere teamleden en/of onderaannemers mochten aannemen dat ze van het ontwerp uit mochten gaan. Er moet dus goed onderzocht worden welk ander (deel)resultaat wellicht invloed ondervindt van de verandering.
Resultaten die nog niet uitontworpen zijn (in ontwikkeling) mogen zonder meer gewijzigd worden, mits dat geen invloed heeft op eisen en normen. Dat is noodzakelijk omdat anders teamleden niet door kunnen werken. Immers, ontwerpen houdt in dat er voortdurend gewijzigd wordt. Andere teamleden en/of onderaannemers mogen dus niet uitgaan van resultaten in ontwikkeling.
Deze constatering betekent ook, dat het “vrijgeven” van een deelresultaat (het ontwerp “voor gereed verklaren”) een vrij zware procedure is. Immers, van dat moment af mag het betrokken deelresultaat niet meer gewijzigd worden, ervoor weten anderen niet waar ze zich met betrekking tot dit deelresultaat aan moeten houden.
Om aan al de genoemde voorwaarden te kunnen voldoen, zal men meestal uitgaan van gestandaardiseerde formulieren, waarop wordt aangegeven welke vaste elementen elke stukje informatie zal moeten bevallen.
De opbouw van een projectarchief
Het archief waarmee het project wordt begonnen is noodzakelijkerwijs erg vaag. Het te realiseren product is alleen in algemene termen te beschrijven. Soms is er nauwelijks sprake van een product in die beginfase. Zo kan er sprake zijn van een non-frozen design: men weet wel welk eindresultaat bereikt moest worden, maar de manier waarop dat gedaan moet worden en de eisen die daaraan gesteld worden, zijn nog erg vaag. Toch moet een systeem opgesteld worden waar alle latere gegevens “ingehangen” kunnen worden. Een gebruikelijke methode daarvoor is een hiërarchische opbouw.
Bij een hiërarchische opbouw begint men het projectresultaat op te delen in enkele grote stukken, “objecten”. Elk van die objecten kan in de loop van het project onderverdeeld worden naarmate beter duidelijk wordt wat ze inhouden. Een dergelijke indeling maakt ook de onderlinge relaties goed beheersbaar. Men dient bij de vrijgave van elk (deel)object vast te stellen of dit (deel)object alleen binnen zijn hoofdgroep relaties heeft of ook daarbuiten. De al gedefinieerde relaties worden niet aangetast, alleen aangevuld.
Beslispuntinformatie
Speciale aandacht moet geschonken worden aan de informatie die de projectleider, de opdrachtgever en andere betrokkenen nodig hebben voor het doorlopen van beslispunten of mijlpalen. De informatie moet op deze invalshoeken toegespitst worden. Het is daarbij belangrijk om enerzijds beknopt te zijn (de besluitvorming kan erg kostbaar worden als alle betrokkenen een dik dossier moeten doorworstelen, of de informatie wordt domweg terzijde gelegd) en anderzijds volledig ten aanzien van de te nemen beslissingen.
Het is nodig vooraf vast te leggen welke elementen de beslispuntdocumentatie zal moeten omvatten. Een eerste benadering daarvoor vinden we als we kijken naar wie er betrokken zijn bij de beslissing. Dat zijn in ieder geval de projectleider en opdrachtgever. Daarnaast kunnen er inhoudelijke specialisten bij zijn die een oordeel kunnen geven over de kwaliteit van het geleverde werk, bijvoorbeeld de afdeling Kwaliteit, de afdeling Productie (is een product produceerbaar), de afdeling Inkoop (zijn alle gebruikte onderdelen verkrijgbaar), de afdeling Marketing (is er een voldoende markt voor het gedefinieerde product), de afdeling Engineering (kan het product de gevraagde prestaties leveren). Een laatste categorie betrokkenen wordt gevormd door de managers die aan het project moeten toeleveren. Zij moeten beoordelen of de mankracht en middelen die de projectleider vraagt ook geleverd kunnen worden in de betrokken periode. Dat moet niet alleen mogelijk zijn, deze managers moeten zich ook commiteren aan de genomen besluiten.
Welke onderdelen het beslisdocument moet omvatten hangt af van de fase waarin het project verkeert. De aandacht zal in de loop van de tijd verschuiven van de definitie van het eindresultaat naar de praktische realisatie ervan en de nazorg. Per mijlpaal moet aangegeven worden over welke punten een beslissing genomen moet worden en wie daarbij betrokken zijn.
Informatie over het eindresultaat
Het projectresultaat kan niet of gebrekkig gebruikt worden als niet bekend is hoe het werkt en waarom dat zo is. Bovendien zal er meestal onderhoud en verdere ontwikkeling aan het resultaat gepleegd worden. Ten behoeve van gebruik en onderhoud is ook informatie nodig. Grofweg kunnen we daarbij drie categorieën geadresseerden onderscheiden. De opdrachtgever moet inzicht hebben in het product dat hij geleverd krijgt, niet alleen wat het is en hoe het werkt, maar ook waarom dat zo is. De gebruiker moet weten hoe met het resultaat om te gaan en vaak daarvoor opgeleid worden. Degene die onderhoud moet plegen, moet de werking van de verschillende delen kunnen nagaan en bekend zijn met mogelijke storingen. Voor verdere ontwikkeling moet hij weten hoe de verschillende onderdelen zijn opgebouwd en hoe ze met elkaar te maken hebben.
Bovendien zijn er vaak wettelijke eisen aan het bewaren van informatie. Bij latere problemen moet getraceerd kunnen worden wat de geschiedenis van onderdelen en de ontwikkeling daarvan.
Bij veel projecten komt deze informatie, die vooral na de realisatie gebruikt wordt, in het gedrang. Teamleden zijn zo gespitst op het eindresultaat in engere zin dat het beschrijven ervan wordt uitgesteld. Het is ook vaak moeilijk om het moment te zien waarop documentatie van een object afgerond kan worden. Bij configuration management zal dat moment grofweg liggen bij het opnemen van een object in de configuratie. Start men veel eerder dan zal de documentatie voortdurend wijzigen, stelt men het uit dan is veel informatie niet meer te achterhalen, door wisselingen in het team of doordat men domweg niet meer weet waarom bepaalde beslissingen genomen zijn.
Het vervaardigen van documentatie dient een integraal onderdeel te zijn van het projectplan en wordt opgenomen in het informatieplan. In veel gevallen zal dat betekenen dat specifieke resources voor de documentatie benodigd zijn. De ingenieur die een apparaat ontwerpt, is vaak niet de juiste persoon om aan gebruikers uit te leggen hoe ze ermee om moeten gaan. Wellicht is een onderwijskundige nodig om vanuit het product en de documentatie een cursus in het gebruik op te zetten.
Als het maken van documentatie wordt uitgesteld tot na de realisatiefase is het vaak erg moeilijk om nog tot een goede documentatie te komen. Het team wordt wellicht al ontbonden, er is geen budget meer, de motivatie om de klus te klaren neemt af en veel gegevens zijn niet meer boven tafel te krijgen. Dit alles wordt versterkt door het ervaringsfeit dat veel projectmedewerkers een hekel hebben aan documenteren. Het wordt gezien als een bureaucratische klus en bureaucratie is strijdig met projectmatig werken.
De projectleider zal strikte regels voor het documenteren op moeten stellen om een goede documentatie te verzekeren.
Het bovenstaande wekt wellicht de indruk dat gebruikers- en onderhoudsdocumentatie alleen van belang is bij fysieke resultaten, bij apparaten. Echter, het verhaal gaat onverkort op voor projecten als reorganisatie en automatisering. Als de organisatiestructuur projectmatig wordt vernieuwd, is het van groot belang dat wordt vastgelegd wat de bedoeling was en waarom voor de uiteindelijke oplossing gekozen werd. Veranderingen die met groot enthousiasme worden ingezet, hebben de neiging te verwateren en zonder een goede beschrijving is de kans groot dan men langzaam weer afglijdt naar de oude situatie. Ook is onderhoud bij dit soort resultaten van groot belang. Bij de invoering van een nieuwe organisatiestructuur leert men dingen die tijdens het project niet onderkend werden. Bovendien verandert de wereld en een behaald resultaat zal niet eeuwig geldig blijven. Voor een bijstelling is het van belang te weten waarom men indertijd gekozen had voor een bepaalde aanpak.
Betrokkenen bij de informatieoverdracht
In dit stuk concentreren we ons op de informatiestromen. Daarbij staat de projectleider centraal. Hij ontvangt informatie en hij verspreidt informatie. Daarmee kunnen we in grote lijnen de volgende informatiestromen onderscheiden:
Informatie van projectleider naar:
- opdrachtgever/hoger management: hoever zijn we, hoe gaan we verder, hoe zal het eindigen
- medewerkers: wat is de bedoeling, wat wordt van jou verwacht, hoe organiseren we dat
- stakeholders: wat is de bedoeling, wat levert het (voor jou) op, wat verwacht ik van jou
Informatie naar projectleider van:
- opdrachtgever/hoger management: wat willen we, wat hebben we daar voor over, hoe willen we je steunen
- medewerkers: wat is gepresteerd, wat hebben we nodig, hoe voelen we ons daarbij
- stakeholders: wat is ons belang, wat vinden we van het werk en het resultaat, welke informatie/expertise willen we daaraan toevoegen
Stakeholders interpreteren we hier als: iedereen die vindt dat hij iets met het project te maken heeft en iedereen waarvan het project vindt dat hij iets met het project te maken zou kunnen hebben. Dat zijn bijvoorbeeld de (toekomstige) gebruikers van het projectresultaat, degenen waarvan het werk of de privé-sfeer door het projectresultaat verandert, mensen die een (politieke) mening hebben over het projectresultaat, vertegenwoordigers van wet en regelgeving.
Er is dus sprake van meerdere informatiestromen, afhankelijk van het doel en de betrokken personen. Al deze informatiestromen moeten aan bepaalde eisen voldoen, willen ze hun doel bereiken.
Hoe ziet goede informatie er uit
Informatie is geen doel op zich, de informatiestromen helpen om het project in goede banen te leiden. Als we kijken naar de eisen die we aan de informatiestromen stellen, dan moeten we ons steeds de vraag stellen: “werkt het, dient dit een soepel verloop van het project?”.
Een goede informatiestroom heeft de volgende kenmerken:
- identificeerbaar (van wie, aan wie, datum, versie, doel)
- bondig (kort maar duidelijk voor de geadresseerde)
- toegespitst op de ontvanger (welke informatie heeft deze ontvanger nodig)
- operationeel (wat wordt met deze informatie gedaan, hoe is het project erbij gebaat)
- makkelijk hanteerbaar (kunnen geadresseerden met een minimale inspanning de informatie gebruiken)
- juist, nauwkeurig en tijdig (gerelateerd aan het doel van de informatie).
Mondelinge en schriftelijke informatie
Als we moeten kiezen tussen mondelinge en schriftelijke informatieoverdracht letten we ook weer op het doel van de informatie. Schriftelijke informatie is veruit superieur als het gaat om snelheid en nauwkeurigheid van de overdracht. Een mens neemt schriftelijke informatie 5 tot 10 maal zo snel op als mondelinge informatie. Bij schriftelijke informatie kan de lezer zijn eigen tempo bepalen, stukken overlezen, later nog eens nakijken, etc.
Mondelinge informatie is belangrijk op drie gronden:
- als ik zeker wil weten dat de andere de informatie krijgt (toegestuurde stukken worden niet per se gelezen)
- als er een directe discussie over de informatie nodig is (hoewel ook dan vooraf toegestuurde schriftelijke informatie belangrijk kan zijn)
- als er emoties een rol spelen, met mondelinge informatie is het gemakkelijker om nadrukken te leggen, een emotionele relatie met de ontvanger van de informatie te krijgen, bezieling en overtuigingskracht uit te stralen, commitment te krijgen, etc.
Deze drie redenen om mondeling te communiceren bepalen elk weer op welke wijze we gaan communiceren.
Zeker weten dat de andere het stuk gelezen heeft
Vaak worden stukken rondgestuurd, al dan niet met de vermelding van het doel daarvan, waarna men veronderstelt dat de ontvanger ook de inhoud van het stuk kent. Bij projecten zijn er altijd groepen mensen waarvan de reactie op sleutelstukken (specificaties, tijdschema’s, ontwerpen, resource-overzichten) van essentieel belang is voor de voortgang van het project. In die gevallen is het vaak verstandig om persoonlijk met mensen te gaan praten. De kosten (in tijd) van dit soort persoonlijke gesprekken vallen in het niet bij de kosten die ontstaan als achteraf blijkt dat sleutelfiguren niet weten waarover beslist is.
Dat mensen geen kennis nemen van stukken is niet alleen te wijten aan tijdsdruk of slordigheid. Sommige mensen proberen bepaalde ontwikkelingen van zich af te houden omdat ze het er –terecht of onterecht- niets mee te maken willen hebben.
Wijzen op cruciale punten
Ondanks het feit dat we stukken afstemmen op de lezersgroep zal het toch altijd zo zijn dat sommige delen van de informatie voor de lezer belangrijker zijn dan andere. Met name willen we op cruciale punten van de informatie advies, instemming of medewerking hebben. Bij mondelinge informatie kunnen we daarop wijzen en aansluitend om een reactie vragen.
Vragen om instemming
Met de rondgang van stukken “ter goedkeuring” gaat veel tijd verloren. Als we de stukken mondeling toelichten kunnen we die instemming direct vragen. Wellicht moet de formele goedkeuring (“de paraaf”) alsnog schriftelijk geschieden, maar als we alvast weten dat we de goedkeuring probleemloos krijgen (of dat die ons zeker onthouden zal worden) kunnen we alvast aan het werk, zonder veel risico.
Uitleg geven (snapt hij het)
In veel gevallen moeten betrokkenen oordelen over zaken waar ze inhoudelijk weinig verstand van hebben (de boekhouder over een computerprogramma, de directeur over een technische ontwikkeling, een opdrachtgever voor een huis over de noodzaak van heien, etc.). Bij een mondelinge toelichting kunnen gemakkelijker vragen gesteld worden. Vragen stellen over schriftelijke stukken heeft een hogere drempel.
Het stellen van vragen is belangrijk, omdat anders wellicht op verkeerde gronden een instemming wordt gegeven, want mogelijkerwijze leidt tot een gebrek aan acceptatie als het resultaat wordt opgeleverd.
Natuurlijk kosten gesprekken over dit soort zaken tijd, maar het gaat er om tijd te sparen op het totaaltraject van het hele project: goed doorpraten van stukken in een vroeg stadium leidt ertoe dat in latere fasen gemakkelijker medewerking wordt gekregen, dat er minder protesten zijn en dat er minder wijzigingen in een laat stadium worden voorgesteld.
Directe discussie
Directe discussie zien we bij allerlei vergaderingen: met het team, met de opdrachtgever, bij het raadplegen van adviseurs, e.d. In feite staat de informatie in dit soort situaties nog niet vast. De bedoeling van de discussie is juist om een aantal zaken helder te krijgen, hetgeen vervolgens schriftelijk wordt vastgelegd. Dat betekent dus ook dat de resultaten van een dergelijk overleg goed genotuleerd moeten worden. Wil de discussie snel tot resultaat leiden, dan zal dat snel moeten gebeuren. We moeten er naar streven om een verslag de volgende dag (in concept) naar de betrokkenen te versturen, zodat twee dagen later definitief vaststaat wat er besloten is. Pas dan kan er actie worden ondernomen op de besproken punten.
Als emotie een rol speelt
Schriftelijke stukken zijn koel, rationeel. Als we dat over willen brengen is dat uitstekend. Deze uitstraling van stukken is een van de redenen dat bij de rechtspraak zoveel schriftelijk wordt afgehandeld: de emoties worden gescheiden van de feiten.
In veel gevallen spelen emoties echter wel een belangrijke rol. Mensen reageren vaak “politiek”, er wordt met macht gespeeld, overtuigingen zijn veel minder rationeel dan we geneigd zijn te denken. Met name in een machtscultuur en een taakcultuur speelt dit een rol. Als we in deze omstandigheden onze belangen (en die van het project) willen verdedigen, zullen we met die emoties rekening moeten houden.
Een mondelinge toelichting op de plannen moet overtuigingskracht uitstralen, we moeten onze eigen positieve (of negatieve) emoties op de andere partij laten overslaan. We letten op de non-verbale communicatie van onze gesprekspartner om te zien waar we een extra argument nodig hebben, welke punten benadrukt moeten worden en waar we uitleg moeten geven.
Schriftelijke informatie
Schriftelijke communicatie moet aan een aantal eisen voldoen. We zullen deze achtereenvolgens kort bespreken.
Archivering
Zowel de zender als de ontvanger van de informatie moeten de stukken zo op kunnen bergen dat ze terug te vinden zijn en dat stukken met elkaar in verband gebracht moeten kunnen worden. Er moet dus een voor alle partijen inzichtelijk systeem bestaan. In veel gevallen wordt er gekozen voor een centraal archief dat berust bij de projectleider of bij het projectenbureau. Als dat archief klopt is dat het punt waarop alle betrokkenen terug kunnen vallen. De indeling van het archief hangt meestal samen met de indeling in deelprojecten.
Identificatie
Van elk stuk moet duidelijk zijn van wie het afkomstig is, voor wie het bestemd is en wanneer het gemaakt (of verstuurd) is en welke versie het is. Dit zijn heel bekende eisen, maar talloze stukken voldoen daar niet aan. Sinds de meeste stukken per computer gemaakt worden is het heel gemakkelijk om te werken met een sjabloon waarin een vaste plaats voor deze gegevens gereserveerd is, bv.:
- afzender:
- geadresseerde:
- datum:
- versie:
- vervangt versie:
Bij technische tekeningen kennen we dit systeem rechtsonder op de tekening. Echter, een dergelijk systeem garandeert nog niet alles. Ik heb diverse tekeningen gezien waarin de meeste vakjes niet ingevuld waren. Dat betekent òf dat er onzinnige vakjes op het papier stonden, òf dat mensen er slordig mee om gaan. Ik vermoed dat beide een rol spelen.
Met deze primaire identificatiegegevens zijn we er nog niet. Als iemand een stuk ontvangt, wat moet hij er dan mee. We moeten dus aangeven welke reactie we op het stuk willen hebben. Er bestaan diverse ontwerpen van geleidebriefjes die daar standaarden voor geven, bv.
- ter informatie
- reactie vòòr datum: ….......
- agendapunt __ datum: …........
- vervangt stuk: …...........
- uw advies over pag ….
- ter goedkeuring vòòr datum …...
- retour vòòr datum: …......
We kunnen dit aanvullen door in het stuk aan te geven welk deel vooral van belang is (gebruik een merkstift of geef dit in de inleiding aan).
Omvang
Een stuk moet vooral kort zijn. Niemand leest gemakkelijk lange rapporten. We aarzelen om er aan te beginnen, we kunnen er de weg niet in vinden, we weten de hoofd- en bijzaken niet te onderscheiden en dus komt er geen helder oordeel uit. Daartegenover staat dat een stuk duidelijk moet zijn. Dat kost soms extra ruimte.
We kunnen de balans tussen kortheid en duidelijkheid verbeteren door een stuk in te delen. Methoden zijn:
- werk met korte paragrafen en geef een inhoudsopgave
- maak een korte hoofdtekst en verwijs voor nadere uitleg naar bijlagen
- werk met een brede marge en geef in de marge aan wat de hoofdpunten uit het betoog zijn
- maak verschillende versies voor verschillende geadresseerden; het kan gaan om een verschillende tekst, maar er kan ook een andere keuze uit de onderdelen van de tekst gemaakt worden.
Weet voor wie je schrijft
Wat is de bedoeling van je stuk? Wil je uitleg geven, een reactie uitlokken, anderen overtuigen, steun krijgen? Stel je bij het opstellen van een stuk een aantal vragen als:
- wat weten de lezers en wat moeten ze leren uit dit stuk
- welke expertise hebben de lezers en wat moet ik ze uitleggen
- welke vragen worden in dit stuk beantwoord
- welke vragen worden in dit stuk gesteld
- welke reactie wil ik van de lezer
Bouw je stuk op als een antwoord op deze vragen. Het hoeft helemaal niet slecht te zijn als je de vragen expliciet in je stuk stelt en ze vervolgens beantwoordt.
Wat wordt met de informatie gedaan
Waarom schrijf je een stuk? Hoe wordt het project verder geholpen door het schrijven van dit stuk? Sommige stukken zijn puur informatief voor het verloop van het project: teamleden moeten weten hoe ze verder moeten en wat de stand van zaken is. Andere stukken zijn informatief voor de opdrachtgever: wat doen we met zijn geld en wat hebben we daarmee bereikt. Weer andere stukken zijn vooral voor het archief bedoeld: hoe hebben we dit project aangepakt, wat was daar goed of fout aan. Tenslotte hebben we nog stukken die vooral een PR-functie hebben naar de “stakeholders”: hoe loopt het project en wat zullen de gevolgen zijn voor de stakeholders.
Schrijf je stuk met in je achterhoofd “wat wordt er met dit stuk gedaan”. Als er niets mee wordt gedaan hoef je het ook niet te schrijven. Als er wel wat mee wordt gedaan moet het daar goed op aansluiten: effectief en efficiënt.
Juist, nauwkeurig en tijdig
Hoewel deze eis een open deur lijkt, wordt er toch vaak niet aan voldaan. De eisen lijken bij nader inzien ook een beetje strijdig. Als je juist en nauwkeurig wil zijn heb je wellicht te weinig tijd om tevens tijdig te zijn. De juiste oplossing is om een rapport of ander stuk niet pas te schrijven als het nodig is, maar de informatie steeds te verwerken als die ter beschikking komt. Het schrijven van het rapport is dan niet meer dan het ordenen en het formuleren van wat tussenzinnen.
Uiteraard zijn de eisen juist, nauwkeurig en tijdig gerelateerd aan de eerder behandelde onderwerpen. Ook hier gaat het er weer om wat er met het stuk gedaan moet worden. Een speciaal geval betreft de notulen of besluitenlijsten van vergaderingen. Op vergaderingen wordt afgesproken wat er vervolgens uitgevoerd moet worden. Dat kan pas als de genomen besluiten bekend zijn gemaakt. Dat moet:
- tijdig, het liefst dezelfde dag nog, het werk wacht er op
- nauwkeurig, in termen van SMART: er mag geen misverstand zijn over wat besloten is
- juist, het vervolg van het project is afhankelijk van de juistheid van de weergave.
