Product, tijd, geld: de basis van projectmanagement bij de Overheid?

Waarom wordt een project gestart?

Een project gaat om verandering en wordt gestart omdat de huidige situatie beter kan of niet meer voldoet. Een project heeft als doel om toekomstige voordelen te faciliteren. Wat heb je eraan als een project keurig op tijd en binnen budget de gevraagde scope/kwaliteit oplevert maar het product geen toegevoegde waarde (meer) blijkt te hebben? Het heeft dus zin om te sturen de relatie tussen de verwachte opbrengsten en de gevraagde kwaliteit/scope zodat er weloverwogen beslissingen genomen kunnen worden over wijzingen vanwege veranderende omstandigheden.

Want elk project heeft onzekerheden. Een project heeft als kenmerken dat het uniek is; nog nooit eerder onder dezelfde omstandigheden uitgevoerd. Daarmee is een project moeilijker te plannen dan het dagelijkse routinematige werk. Sturen op onzekerheden (risico’s) is daarom ook van groot belang. Het concept van Product, Tijd, Geld is uitstekend toe te passen op de inkoop van standaardproducten. Wanneer een product vooraf niet volledig te specificeren is, wordt sturing op Product, Tijd en Geld ingewikkelder. Ook de vaak terugkerende roep om resultaatverplichting door leveranciers zou volgens dit model te regelen zijn, maar is in de praktijk slechts haalbaar wanneer specificaties vooraf te specificeren zijn. Bij veel “ICT-projecten” blijkt vooraf specificeren niet of nauwelijks voldoende mogelijk.

Te verwachte opbrengsten en risico’s zijn daarom naast de IJzeren Driehoek ook belangrijke aspecten voor effectieve sturing. Het voldoet meestal niet om een project te zien als een kostenpost. Het is vaak effectiever om een project te zien als een investering. Dit is de essentie van de Business Case aanpak. Helaas is ook het omgaan met Business Cases bij de Overheid niet ontwikkeld. Dat bleek bij de discussie over Joint Strike Fighter en dat bleek ook recentelijk weer eens uit het verslag van Operatie BRP.

Opdrachtgever en opdrachtnemer

Wanneer een project in de problemen komt, wordt vaak gewezen naar de leverancier, de opdrachtnemer. Vragen over professionaliteit en zelfs integriteit komen aan de orde. Maar ligt het zo eenvoudig? Is resultaatverplichting altijd mogelijk?

Wanneer (een deel van) een project wordt uitbesteed, wordt een contract opgesteld waarin de IJzeren Driehoek centraal staat. Dit is echter alleen mogelijk wanneer de risico’s te overzien zijn. Voorbeelden hiervan zijn vaak buiten projecten te vinden: inkoop van bulkgoederen en standaardproducten.

Wanneer er echter sprake is van situaties waar tijdens een project veel wijzigingen zullen plaatsvinden en/of er veel onzekerheden zijn, dan is uitbesteding van (een deel van) een project vaak veel minder zinvol en toepasbaar. Voorbeelden hiervan zijn project met een ICT-component en risicovolle constructieprojecten zoals de Noord/Zuidlijn.

In dit soort projecten vallen scope en kwaliteit meestal niet eenduidig van tevoren vast te leggen. Wanneer het mogelijk blijkt om ook risico’s volgens een contract bij de opdrachtnemer te beleggen, zal de opdrachtnemer een (forse) risico-opslag berekenen. En zelfs dan kan het nog, meestal voor de opdrachtnemer, fors misgaan. Maar ook zal de opdrachtgever last krijgen van deze constructie. In het gunstigste geval zal het beperkt worden tot de risico-opslag maar ook deze extra kostenpost zal ten laste komen van de business case.

Het komt helaas vaak voor dat er toch een op de IJzeren Driehoek geïnspireerd contract wordt afgesloten waar prijs het belangrijkste aspect is voor de opdrachtgever, maar kwaliteit en scope onvoldoende beschreven (kunnen) worden. Dit is vaak aan de orde bij overheidsaanbestedingen. Het gevolg is dat de opdrachtnemer zich even vaag committeert. Tijdens het project zal de opdrachtgever een hoge prijs betalen want bij het minst of geringste zal de opdrachtnemer een beroep doen op een clausule voor meerwerk tegen een hoge tarieven.

Sturing op tijd, geld en kwaliteit/scope heeft alleen nut binnen een contract tussen een opdrachtgever en een opdrachtnemer. Maar dan moet het contract ook goed doordacht en specifiek zijn. Wanneer dit niet mogelijk is, zal de opdrachtnemer zelf intensief moeten sturen en zal de opdrachtnemer ingezet worden op basis van inspanningsverplichting. Het maakt hierbij niet veel uit of de opdrachtnemer een externe, commerciële partij is of een interne partij, zoals de afdeling ICT geleid door een CIO. Het is zelfs vaak meer risicovol wanneer de opdrachtnemer een interne partij is. Bij een commerciële partij is het volledig duidelijk dat er sprake is van tegenstrijdige belangen. Wanneer er sprake is van een interne leverancier worden tegenstrijdige belangen veelal genegeerd wat onvermijdelijk leidt tot politieke spelletjes. Binnen een bureaucratie zoals de Overheid wil een CIO tenslotte ook zijn macht vergroten en dit lukt vaak het beste door het budget van de afdeling te laten oplopen door grote projecten en meer verantwoordelijkheden op te eisen.

Sturen op Tijd en Geld.

Er is een alsmaar toenemende trend om alleen aandacht te besteden aan tijd en geld. Ook in de door de IT-sector gepropageerde moderne Agile-aanpak is hiervan sprake: Timeboxing.

Wanneer een project mislukt, wordt gewezen op overschrijdingen van tijd en budget. Deze houding, focus op tijd en geld alleen, is echter vaak zeer destructief en vaak juist een reden voor het mislukken van projecten.

Het gevolg van sturen op alleen tijd en geld zorgt er per definitie voor dat kwaliteit/scope ondergeschikt worden. Dit leidt weer tot lagere opbrengsten (doelen worden niet bereikt) en/of tot vele wijzigingsverzoeken en herstelwerkzaamheden tijdens het project waardoor tijd en geld juist uit de hand lopen. Ook zal gebrekkige kwaliteit hogere kosten na het project tot gevolg hebben door hogere productiekosten en hogere kosten van onderhoud en beheer.

Een voorbeeld hiervan is wederom de Operatie Basisregistratie Personen (oBRP) van het Ministerie van BZK.

De IJzeren Driehoek is dus niet altijd toepasbaar

De IJzeren Driehoek, of een variant daarop, wordt gezien als een fundament van projectmanagement. Het concept is echter niet altijd toepasbaar. Slechts wanneer de eisen en wensen duidelijk en meetbaar te specificeren zijn, kan dit concept worden toegepast in een (contractuele) relatie tussen opdrachtgever en opdrachtnemer. Wanneer dit niet het geval is, zal vooral de opdrachtgever zich moeten wenden tot andere, bredere sturingsmechanismen.

Uw visie?

Wat denkt u? Heeft u een mening (of vraag), wilt u reageren? Heel graag!

Daarvoor heeft u hieronder de gelegenheid. Alvast bedankt!