nieuws

Functioneel specificeren: back to basics!

bouwbreed

Als je iets wilt laten produceren, moet je weten wat je wilt. Dat is een universele waarheid die evengoed geldt in de industrie, de utiliteitsbouw, de gebiedsontwikkeling en de infrastructuur. Toch wordt volgens Norbert van Doorn in die bedrijfstakken op verschillende wijze omgesprongen met het inschakelen van marktpartijen tussen het ontstaan van een idee of behoefte en de oplevering van het product.

Waar het in de industrie- en utiliteitsbouw al jaren gebruikelijk is om, onafhankelijk van projectorganisatievorm of contractmodel, een functioneel programma van eisen op te stellen, wordt bij gebiedsontwikkeling en infrastructuur deze stap nog vaak overgeslagen. Nu, bij de ontwikkeling van nieuwe samenwerkingsvormen tussen opdrachtgevers en opdrachtnemers, lijken de toverwoorden �functioneel specificeren� te zijn en kan het allemaal niet ingewikkeld genoeg�.

Het algemeen gebruikte procesmodel van projectmatig werken verdeelt het ontwikkel- en bouwproces in een aantal logisch opeenvolgende stappen. Voor de start van de realisatiefase moeten achtereenvolgens de definitiefase, de ontwerpfase en de voorbereidingsfase worden doorlopen.

De projectaanpak laat in het midden op welk moment welke contracten worden gesloten (met andere woorden op welk moment welke �bestelling� wordt geplaatst!) en onder welke voorwaarden. Het is een keuze van de opdrachtgever op welk moment hij welke opdrachtnemer waarvoor wil inschakelen en op basis van welke gegevens.

Integraal contract

Uitersten zijn het volledig uitgewerkte detailbestek (we noemen dit vaak �traditioneel�) en het �functionele PvE op één A4� helemaal voorin het proces (wat dan weer zeer innovatief wordt gevonden). Wat is nu een verstandige keuze? Dat hangt in de eerste plaats af van wat de opdrachtgever wil, zowel ten aanzien van het product als het proces. En vaak weet die opdrachtgever dat in het begin nog helemaal niet.

Veel opdrachtgevers zijn sterk afhankelijk geworden van hun technische adviseurs. Architecten en ingenieursbureaus ontwerpen er op los op basis van nog onduidelijke eisen en wensen van hun opdrachtgevers. De eerste ontwerpresultaten doorstaan dan ook vaak de toets van de opdrachtgevers niet, omdat deze pas naar aanleiding van de eerste schetsen écht gaan nadenken over eisen en wensen. Is dat erg? In een �traditionele� samenwerking niet: het ontwerp ontstaat in een min of meer parallel proces van nadenken over eisen en het ontwerpen van oplossingen. Hooguit is de efficiëntie niet optimaal.

Terug naar af

In contractvormen waarin de ontwerp- en uitvoeringstaken gecombineerd zijn opgedragen (zoals design- en constructvormen) werkt dit echter niet. Bij het veranderen of bijstellen van de eisen en wensen van de opdrachtgever is dan immers sprake van wijzigingen ten opzichte van het contract. En dus een opening voor nieuwe onderhandelingen over de voorwaarden. Geïntegreerde contracten maken een robuuste resultaatomschrijving met weinig ruimte voor wijzigingen noodzakelijk. Moeten we alles dan maar weer op de traditionele manier organiseren? En is dit terug naar af?

Het combineren van ontwerp en uitvoering (al dan niet gecombineerd met onderhoud en beheer en eventueel financiering) heeft voor veel projecten veel voordelen. Indien aanbieders voldoende vrijheden worden geboden kan beter gebruikt worden gemaakt van hun deskundigheid en ervaringen en is er meer ruimte voor innovatie en optimalisatie.

Het is daarvoor echter wel noodzakelijk om vroeg in het proces een tamelijk vastomlijnd beeld te hebben van de functionele eisen die aan het gewenste product worden gesteld. En deze bij voorkeur uit te kunnen drukken in concrete en meetbare specificaties. Voor sommige opgaven is dit lastig of zelfs onmogelijk: de functionele eisen staan niet altijd in het begin van het proces vast, en er kan sprake zijn van veranderende uitgangspunten.

Voorbeelden zijn projecten waarin de invloed van de omgeving nog groot is, projecten waarin de gebruikersprocessen en de omhullende huisvesting parallel worden ontwikkeld, of projecten waarbij esthetica of andere gevoelsmatige waarden leidend zijn. Dan is een open ontwerpproces wenselijk: een proces waarin opdrachtgever, gebruikers, beheerders en ontwerpers in onderlinge samenwerking en met minimale beperkingen stapsgewijs tot een gezamenlijk resultaat kunnen komen. Daar is niets �traditioneels� aan: misschien is het wel de meest vooruitstrevende, want meest klantgerichte, benadering van het bouwproces.

Eerst denken dan doen

Toch vraagt ook zo�n open ontwerpproces om een duidelijk startpunt. Als opdrachtgevers, gebruikers en ontwerpers vanuit het niets aan de slag gaan is het moeilijk om tot een beheerst en afgebakend proces te komen. Daarom is het ook in zo�n proces nodig om te starten met een, hoe beperkt ook, functioneel programma van eisen. Hierin wordt minimaal vastgelegd welk probleem opgelost moet worden of welke functies hiertoe moeten worden vervuld. Dit vormt het kader voor de ontwerpactiviteiten. Dit is niet anders voor gebouwen, dan voor fabrieken, gebieden, snelwegen etc.

Over functionele programma�s van eisen (fPvE) wordt te vaak onnodig ingewikkeld gedaan. Vooral door gespecialiseerde adviseurs. Een fPvE is niets anders dan een gedegen beschrijving van processen die plaats moeten gaan vinden en de eisen die dit stelt aan het te maken product. Het lastige is echter om functionele eisen duidelijk te omschrijven en meetbaar te maken en technische oplossingen zoveel mogelijk te vermijden.

Daarvoor is het belangrijker om kennis te hebben op het gebied van de gebruikersprocessen dan op het gebied van bouw- en installatietechniek. De schrijver van een programma van eisen, of dit nu de opdrachtgever is of een ingeschakelde adviseur, moet vanuit die procesdeskundigheid de bruggen kunnen slaan van gebruikersprocessen naar functies en van functies naar functiedragers, en daar concrete eisen voor kunnen formuleren.

Opdrachtgever

Uiteindelijk moet de opdrachtgever het voortouw nemen: het is niet meer dan logisch om bij het begin van een investeringsproject eerst eens goed na te denken over de eigenlijke vraag (de bestelling), en hierbij rekening te houden met de gebruikers, de beheerders en de betalers. Dit geldt zowel in een �traditioneel� geknipt bouwproces als in een meer geïntegreerde marktbenadering.

Daarbij geldt dat alle contracteringsmodellen elk hun eigen toepassingsgebieden kennen: laten we stoppen om met het onderscheid tussen traditioneel en innovatief. Het is beter om per project te spreken van passende en niet-passende contractvormen.

Welke contractvorm ook wordt gekozen, het functionele programma van eisen is altijd een belangrijk startpunt en een cruciaal communicatiemiddel. Het programma van eisen zoals we dit nu vooral in de industrie- en utiliteitsbouw kennen kan daarbij nog wel model staan voor projecten in de infrastructuur en de gebiedsontwikkeling.

Ir. Norbert van Doorn MBA is directeur van ProCap Projectmanagement BV en initiatiefnemer van PtP Bouw, het projecttalentprogramma voor de bouwsector. Daarnaast is hij onder meer lid van het algemeen bestuur van ONRI, de organisatie van advies- en ingenieursbureaus, en docent aan de TU Delft, faculteit Civiele Techniek en Geowetenschappen bij de sectie Bouwprocessen.

Ontwerpproces vraagt duidelijk startpunt

Reageer op dit artikel
Lees voordat u gaat reageren de spelregels