Informatiestromen tijdens de projectfase - Vakblad Od I Overheidsdocumentatie

In een serie van vier artikelen wordt vanuit het perspectief van het realiseren van projecten in de openbare ruimte aandacht gegeven aan de vraag: “Hoe zorgen we ervoor dat we gedurende de gehele levens cyclus van objecten in de openbare ruimte ons kunnen verantwoorden en we kunnen beschikken over de juiste informatie, nu én in de toekomst?” Dit tweede artikel gaat over de informatiestromen die tijdens de projectfase plaatsvinden.

Om te beginnen: wat zou je willen weten? Om deze vraag te kunnen beantwoorden neem ik het voorbeeld dat ik het beste ken: de Noord/Zuidlijn. Waar moet je geen gaatje in de grond maken om niet door het dak van de tunnel te schieten? Waarom heeft een en ander wat langer geduurd en waarom is het een stukje duurder geworden? En als je in de omgeving van het traject woont of werkt, wat staat je te wachten?

Organisatie
Om deze vragen te kunnen beantwoorden en te managen wordt steeds vaker naar het voorbeeld van Rijkswaterstaat gewerkt met ‘Integraal Projectmanagement’. Een werkwijze waarmee nu tijdens de realisatiefase in vrijwel alle grote projecten in Nederland wordt gewerkt. De voorbereidingsfase waarin de politiek wordt voorbereid op de grote project keuzes laat ik in dit verband buiten beschouwing. Hier behandel ik alleen de fase van de technische realisatie, nadat alle politieke voorbereiding al is afgesloten. Er is een opdracht: “Realiseer deze lijn, tunnel en hiervoor is X miljoen/ miljard beschikbaar.”

Deze opdracht wordt vertaald in een projectplan en er wordt een projectorganisatie opgetuigd. Gebaseerd op rollen. Het gehele project wordt aangestuurd door een IPM’er, een integrale projectmanager, die alle aspecten van het project coördineert en hiervoor op elk van de aspecten een verantwoordelijke heeft aangesteld. Hij/zij vormt samen met deze verantwoordelijken, de onderstaande specialisten, een managementteam dat het project aanstuurt en coördineert.

Dit (management)team ziet er als volgt uit:

Ten eerste een technisch manager die alle aspecten van ontwerp tot oplevering technisch aanstuurt. Hiervoor heeft hij/zij een team van civieltechnische, elektrotechnische en andere specialisten. dat op basis van eisen een ontwerp maakt dat de basis is van een of meer uitvragen aan de markt (aannemers of aannemerscombinaties).
Ten tweede een omgevingsmanager die inventariseert welke effecten het beoogde project heeft op haar omgeving en hoe met deze effecten rekening gehouden kan worden. Hij/zij stelt hiervoor een stakeholdersanalyse op, waarin alle betrokken partijen worden geïnventariseerd. Tegelijk worden alle eisen geïnventariseerd. Wat vraagt de wet, wat zijn de belangen en wensen/eisen van de stakeholders, binnen welke periode moet dit worden gerealiseerd en wat mag dat maximaal kosten? Dit wordt vertaald in een KES, een set van klanteisen dat als basis dient voor het opstellen van de systeemeisen. Met andere woorden: hoe vertaal je de klanteisen naar de eisen die de basis vormen voor de achtereenvolgende technische ontwerpen? Een traject waarbij enerzijds intensief tussen omgevingsen technisch management, maar anderzijds ook met de toekomstige gebruikers/ de ambtelijke opdrachtgevers wordt gecommuniceerd. De omgevingsmanager is ook verantwoordelijk voor de ‘alternatieve wegenplannen’, de wijze waarop de gevolgen van het project voor de omgeving worden opgevangen. Denk aan afsluiting van wegen. Hoe worden aanpalende winkels gedurende deze periode toch voorzien van voorraad, wat betekent dit voor hun omzet en worden zij gecompenseerd? Als er wegen worden afgesloten, zijn er dan alternatieve routes? En last but not least, hoe wordt hierover gecommuniceerd en afgestemd met andere verantwoordelijken?
De derde cruciale poot van het IPMteam is het contractmanagement. Een steeds belangrijkere rol. De overheid die in toenemende mate zich omvormt van een engineer met grote inhoudelijke kennis tot een inkoper. Steeds meer kennis en kunde wordt bij de markt gehaald. Een ontwikkeling die zich vertaalt in andere contractvormen. Traditioneel werd gewerkt met bestekken, waarbij ongeveer op schroef en boutniveau werd aangegeven wat de overheid wenste. De markt was uitvoerende partij. De overheid wist tot in detail wat zij wilde en vroeg dit uit aan de markt. Sinds een aantal jaren, met name vanuit Rijkswaterstaat (RWS), wordt steeds gewerkt met contracten, waarbij de overheid functioneel uitvraagt en de verantwoording hiervoor ook bij de markt legt.
Een voorbeeld. RWS wil een verbinding van A naar B. Naar verwachting gaan in de komende jaren tweehonderdduizend auto’s per dag gebruik maken van deze weg en hierbij wordt op twee plekken contact gemaakt met water. RWS vraagt: “Doe een aanbieding om dit op te lossen en ontzorg ons hierbij voor de komende dertig jaar.” Wat voor weg het wordt, welke soorten beton, asfalt worden gebruikt is aan de aannemer. De aannemerscombinatie is zelfs niet verplicht om bruggen te bouwen. Ze kunnen ook kiezen voor een tunnel. De enige eis is dat de oplossing voldoet om dagelijks tweehonderdduizend automobilisten van A naar B te laten gaan, waarbij het onderhoud bij de aannemer ligt. Wordt gekozen voor dure bouw en goedkoop onderhoud of omgekeerd? Dat is aan de aannemer. Ook hierop zijn, ten gevolge van faillissementen van enkele grote aannemers, ontwikkelingen gaande waarbij de overheid meer verantwoording neemt, maar dit even om het belang van contractmanagement te schetsen.
De laatste poot is projectbeheersing. De manager hiervan stuurt op geld, risico, informatie en tijd. Planning, budget, risicomanagement en interne coördinatie van informatiestromen behoren tot deze discipline.

Communicatie
Het project bestaat uit grofweg twee aspecten. Wat er gerealiseerd wordt, het object – in al zijn ontwikkelingsstadia – en hoe dit gebeurt: tegen welke (meer) kosten en binnen welke tijd. En de samenhang hiertussen. Om deze processen goed te kunnen besturen is (over)zicht van de communicatie, formeel en informeel cruciaal

Figuur 1: Communicatielijnen tussen de verschillende partijen

Tijdens het project wordt er op verschillende niveaus met elkaar gecommuniceerd. Op het hoogste niveau worden de bestuurders en in hun kielzog de volksvertegenwoordigers periodiek bijgepraat. Zodat eventuele tussentijdse tegenvallers (meerwerk, langere doorlooptijd) niet uit de lucht komen vallen en er in goed onderling overleg extra middelen en tijd beschikbaar gesteld kunnen worden of dat het project tussentijds gestopt kan worden. Dit informeren gebeurt door ambtelijke opdrachtgevers met soms de integrale projectmanager voor de technische onderbouwing.

Hiermee komen we dan meteen op de tweede formele communicatielaag, die tussen de ambtelijke opdrachtgevers en de ambtelijke opdrachtnemers. Ambtelijke opdrachtgevers zijn veelal die ambtenaren die eindverantwoordelijk zijn voor het dagelijkse beheer van de assets. De ambtelijke opdracht nemers vormen de ambtelijke organisatie die direct de technische realisatie aanstuurt. Lees: dit zijn vaak de gemeentelijke ingenieursbureaus. Dit geldt met name voor de ingenieursbureaus van de G4. Kleinere gemeenten laten dit vaak over aan de markt.

De feitelijke realisatie gebeurt door marktpartijen, daarbij in meerdere of mindere mate aangestuurd door deze ingenieurs bureaus. Dit is de derde formele communicatielaag.
Om te voorkomen dat er een bombardement van mailverkeer ontstaat en er meerdere DMS’en gebruikt worden waarin de verschillende afspraken worden vastgelegd, wordt sinds een jaar of tien bij grote projecten bij RWS, ProRail en de grotere gemeenten steeds meer gewerkt met de open standaard VISI. Aanvankelijk ontstaan naar aanleiding van de bouwfraude. Toentertijd was er een enorme behoefte aan transparantie, maar tegelijk bleef er ook een vreselijke afkeer ten aanzien van bureaucratie. Op basis van een zeer eenvoudig principe, namelijk de basis van elke formele communicatie tussen mensen, is een systeem ontworpen op basis van rollen, taken, verantwoordelijkheden en bevoegdheden. Middels een zogenaamd raamwerk, waarbij de belangrijkste rollen zijn gedefinieerd en waarbij de manieren waarop de verschillende partijen communiceren zijn vastegelegd, wordt dit systeem ingericht.
Uitgangspunt: de professional moet zijn werk kunnen doen, maar moet tegelijkertijd verantwoording kunnen afleggen. Altijd en overal. Het werkt als een soort mail, waarbij echter het grote verschil is, dat het altijd een eenopeen relatie is, waarbij altijd duidelijk is wie wat moet doen en achteraf nagegaan kan worden wie wat waarom gedaan heeft. Accountants en rechters zijn er gek op. Een dossier is altijd op orde en de professional wordt niet lastig gevallen met overbodige bureaucratie. VISI wordt nu vooral gebruikt in de communicatie tussen markt en overheid. Er zijn echter ook voorbeelden waarbij deze ingezet gaat worden in de communicatie tussen Ambtelijk Opdrachtgever en de Ambtelijke Opdrachtnemer. Ook hier is groeiende behoefte aan transparantie. Het is nu nog primair een instrument van de contractmanager, die wil weten of het contract juist wordt uitgevoerd en waar behoefte is aan meerwerk of andere afwijkingen van het contract.

Maar vanuit de techniek wil men ook weten of de diverse stadia van ontwerp die leiden tot de basis van de uitvraag op instemming kunnen rekenen van de ambtelijke opdrachtgever en geen discussies veroorzaken aan het eind van het project. Er worden her en der experimenten gestart om ook in deze communicatie gebruik te maken van deze tooling.

Het interne projectdossier
De ambtelijke opdrachtnemer heeft, naast de formele communicatielijnen, een intern projectdossier, gebaseerd op de IPMrollen zoals hiervoor beschreven.
Aan de hand van dit dossier kan de ontwikkeling van het project in al haar aspecten worden gevolgd. Juridisch, communicatief en technisch. Dit dossier bevat vooral ‘eindproducten’, omdat de primaire informatie in specifieke softwarepakketten wordt opgebouwd. Denk aan plannings pakketten, financiële pakketten en tekenen reken pakketten. De (tussen)producten worden geplaatst in het interne projectdossier.

Figuur 2: Overzicht informatiestromen rond projectdossier

Vooral deze laatste pakketten vereisen een nietstandaard DMS-omgeving. Het moet een DMS-omgeving zijn, die ‘technische formaten’ aan kan. Denk hierbij aan tekenprogrammatuur, zowel tweedimensionaal op basis van vectoren als driedimensionale modellen, (Bouw Informatie Modellen) – BIM is meer dan driedimensioneel tekenen, maar daarover later meer.

In dit dossier worden delen (aspecten) van het bouwmodel opgenomen in de verschillende fases. Van broninformatie tot definitief model (de basis voor het contract).

Het gehele model wordt gebouwd/draait buiten het DMS met speciale software, maar wordt gevoed met diverse informatie uit het projectdossier. Een voorbeeld: een aspectmodel van een deel van een tunnel met daarin de branddeuren. De informatie over de brandweerbaarheid van de bruggen is opgenomen in het projectdossier en is vervolgens gekoppeld aan het bouwmodel. Hierdoor kunnen binnen het model de onderliggende data en documenten worden aangeroepen.
En op basis van deze producten wordt gecommuniceerd met de markt en de ambtelijke opdrachtgever.

Uiteindelijk bevat het interne project dossier ook het eind product dat de projectorganisatie heeft gevraagd van de markt: het opleverdossier. Maar daarover in een volgend artikel meer. Daarbij dan ook over hoe dat proces verloopt.

Theo.Kramer@amsterdam.nl, Theo Kramer is informatiespecialist bij het ingenieursbureau van de gemeente Amsterdam

Meer weten?