De auteurs van het artikel “Doelverschuiving bij overheidsprojecten” constateren dat projecten bij de overheid altijd tot een lijdensweg verworden. Menselijke tekorten leiden er toe, zo begrijp ik het artikel, dat de doelstellingen en de scope van projecten steeds veranderen. Hun oplossing is dat de projectleider strakker de regie over de scope van een project zou moeten voeren. Hij moet met de vuist op tafel de scope van het project bewaken. Dat is, wat mij betreft, precies de verkeerde reactie.

Het is intrigerend dat de auteurs zich vooral richten op automatiseringsprojecten. En inderdaad, daarvan is het beeld dat die projecten zich nogal eens buiten de planning plegen te begeven. In dat opzicht lijken ze nogal op andere grote projecten, zoals infrastructuurprojecten. Hiervan is ook al vaak geschetst dat ze financieel en qua tijd uit de hand lopen. Als we de vergelijking doortrekken zien we ook daar dat dit vaak wordt toegeschreven aan menselijke tekorten. De politieke bestuurders zijn kortzichtig (gericht op herverkiezing), steeds nieuwe belangengroepen krijgen een stem en het eigenbelang regeert. Kortom, de overheid is onbetrouwbaar en het komt nooit tot stenen stapelen.

Het probleem aan strakker sturen is dat de wereld helaas de afgelopen decennia ingewikkelder is geworden. Steeds meer is de overheid slechts een van de partijen die rondom complexe vraagstukken aan het stuur zit. Het oplossen van problemen vergt steeds vaker het inzetten van meerdere partijen. Die complexiteit vertaalt zich in steeds veranderende voorkeuren van partijen. En daarin schuilt, voor de goede ver-staander, juist de kracht van dat soort processen.

Iedere betrokkene herdefinieert steeds opnieuw zijn belangen en ideeën en daarmee kan tot een optimaal eindresultaat worden gekomen. En dat kan behoorlijk afwijken van de origineel gestelde doelstellingen. De reflex om daar met harde hand op te gaan sturen is een klassieke, maar geen slimme oplossing. In auto’s zit de goede chauffeur niet voor niets met de handen losjes aan het stuur.

De slimme projectleider is een procesmanager en maakt steeds gebruik van de partijen om het eindresultaat te verbeteren. Soms leiden dat soort interactieve processen natuurlijk tot een grauw ogend gemiddelde uitkomst, maar strakker sturen helpt hier niet. Als de weg van een project afbuigt en de projectleider blijft strak sturen, dan raakt de projectleider van de weg.

Dat is een inzicht dat, om terug te keren naar het begin, ook in de infrastructuurwereld is doorgedrongen. Natuurlijk moeten projectleiders en bestuurders daar duidelijkheid scheppen, maar dat doen ze wel nadat iedereen uitgebreid aan het woord is geweest. Alleen dat leidt tot een voor partijen acceptabel eindresultaat.

Die constatering leidt tot een zekere bescheidenheid. De succesvolle projectleider - en de succesvolle adviseur - is geen held die met de vuist op tafel slaat en resultaten afdwingt, maar een handige verbindingsman die partijen verleidt tot het samen werken aan een project met inderdaad wisselende doelstellingen. De helden moeten misschien op zoek naar een ander tijdperk om aan hun lijdensweg te ontsnappen.

Niels Kastelein is werkzaam bij Berenschot.

Hoewel hier over overheidsorganisaties wordt gesproken, is dit probleem ook herkenbaar in andere sectoren.
Mijn ervaring is dat je eerst moet vaststellen of de projectvorm de juiste methode is om het probleem aan te pakken. Meestal zijn er veel verschillende belangen (personen of afdelingen, mogelijk ook andere organisaties), die je niet zomaar op een lijn krijgt. Vaak betreft het processen, die voortdurend aan verandering onderhevig zijn.
Automatisering is bijvoorbeeld een middel om processen te sturen. Als je doel is om meer met minder te doen (de efficiencyslag), moet je dan in eerste instantie aan een project denken of aan het sturen van een omslag? Mogelijk , dat onderdelen in projectvorm kunnen worden uitgevoerd, omdat het projectmatig werken heel efficient kan zijn. Ik mis in het verhaal de rol van de manager. Wat is zijn/haar belang ? Is hij/zij betrokken bij het project? In hoeverre verstoort (het meewerken aan)het project het dagelijkse werk? Welke noodzaak is er om het project te steunen, c.q. voorrang te geven?
Wat moet of kan de projectleider doen? Misschien moet de functie een andere naam hebben in de beginfase. (Voor de formatie is er immers ook een informateur aan het werk?). De businesscase en de initiatiefase vergen de meeste tijd. Helaas echter worden die stappen vaak met zevenmijlslaarzen genomen. Bij voorbaat haal je dan het doel niet.
Vriendelijke groet
Joke van Galen

Mijn insteek is altijd om de mensen in het project (waar altijd wel een automatiserings deelproject inzit tegenwoordig) te motiveren tot ze roze zien en hun tegelijkertijd de vrijheid te geven om het einddoel links of rechtsom te bereiken (met inachtneming van de kwaliteitseisen natuurlijk).
Looptijd en dus oplevering is altijd een streven. Is er wel sprake van een project als men exact kan aangeven wanneer het klaar is?
Indien het allemaal zo voorspelbaar geworden is dan is het in mijn ogen gewoon een Taak die uitgevoerd moet worden.
Dat is inderdaad in de automatisering vaak niet zo, maar er zijn zat zaken in de IT wat gewoon een Taak kan zijn en waar tijd dus nooit een onberekenbare faktor kan zijn.
Men moet goed definieren wat men met het woord "project" bedoelt voordat men uitspraken daarover gaat generaliseren.

www.netsib.com

Complimenten voor de bijdrage van Verbekermoes en Puyt. Zij leggen een aantal zaken bloot die volgens mij in menig groot project een rol spelen, maar bijna nooit worden uitgesproken. Les één bij het soort projecten waarover zij schrijven is telkens: stel doelstellingen bij aanvang vast en commiteer de belangrijkste stakeholders aan deze doelstellingen. Ik maak vaak mee dat de doelstellingen aan het begin niet helder zijn en dat prioriteiten daardoor gedurende het project gaan schuiven.

Kastelein heeft groot gelijk dat in de ‘echte’ wereld belangen en posities om welke reden dan ook zullen gaan schuiven. Hierbij wordt vaak eufemistisch van ‘voortschrijdend inzicht’ gesproken. Je dan via dialoog tot een nieuw machtsevenwicht en een nieuwe werkbare oplossing komen. Flexibel meebewegen en inspelen op context en belangen is inderdaad een belangrijke vaardigheid voor adviseurs en projectleiders.

De analyse van Kastelein gaat echter mis in zijn vergelijking tussen adviseurs en projectleiders. Projectleiders, anders dan adviseurs, worden ingehuurd en betaald om dingen ‘voor elkaar te krijgen’. Simpel gezegd moeten zij ‘een product opleveren volgens vooraf gestelde specificaties’ (de eerder genoemde doelstellingen). De rol van een adviseur is dus anders dan die van de projectleider. De adviseur heeft over het algemeen meer vrijheidsgraden om tussentijds bij te sturen.

Bovendien hebben Verbekermoes en Puyt het niet voor niets over automatiseringsprojecten. Anders dan andere verandertrajecten hebben deze projecten een nogal dwingend karakter. Vaak heeft dit te maken met de technische vereisten. Deze projecten hebben een vrij lage tolerantie ten opzichte van tussentijdse verschuivingen in doelstellingen en prioriteiten.

Enige overdenkingen voor verbetering:

- Stel vooraf doelstellingen vast en commiteer de belangrijkste stakeholders.

- Leg verantwoordelijkheden zo veel mogelijk in de lijn. Waarom zou de lijnverantwoordelijke niet zelf de rol van projectleider op zich nemen (deskundige van buiten meer als coach en begeleider dan als projectleider?).

- Richt je als projectleider naar het machtscentrum. Als er geen duidelijk machtscentrum is, moet je proberen en één te creëren.

- Projectleider moet discussie over doelstellingen expliciteren wanneer hij merkt dat belangen van stakeholders gaan schuiven. Mikken op een bewegend doel is prima, maar stakeholders moeten dan wel zelf hun verantwoordelijkheden nemen: veranderende doelen betekent ook een andere invulling van het verandertraject.

- De stuurgroep moet zich verplicht bij iedere meeting de vraag stellen: 1. Voor welke doel was dit project een middel? 2. Komen we dichter bij het doel?

Het artikel van Verbekermoes en Puyt is een zeer boeiend stuk met een heldere analyse, al deel ik niet de conclusie dat de projectleider de belangrijkste actor is om dit te voorkomen. De projectleider moet dit probleem slechts tijdig signaleren en op de agenda zetten bij zijn opdrachtgever. Niet met het doel daarmee onrendabele investeringen te voorkomen, want dat is het openbaar bestuur eigen (bedoel ik niet cynisch). Immers een al te duidelijke routekaart maakt het de politieke oppositie wel heel makkelijk om de route te voorzien van strategisch geplande obstakels. Openbaar bestuurders zullen dus steeds van compromis naar compromis laveren, waarbij ze op elk beslispunt proberen om aan de belangrijkste machtcentra tegemoet te komen om weer even vrij baan te krijgen voor een volgende stap. Daardoor is het niet gebruikelijk in openbaar bestuur om de baten van een project als meetbare grootheden te definiëren en nog minder gebruikelijk om een batenrealisatieplan te maken, waarin staat wie welke acties onderneemt om met projectresultaten de beoogde baten op geplande momenten te verzilveren. Elk expliciet meetbaar punt is een stok om mee te slaan.

Het gevolg daarvan is een context waarin openbaar bestuurders alleen nog kunnen worden afgerekend op hoe zij omgaan met input (het proces) dan op de waarde van de output die ze produceren (resultaat). Voorbeeld: Hoogervorst wordt harder aangesproken op hoe hij omgaat met de evt. tijdelijke chaos dan op het werkelijke effect van de nieuwe zorgwet. Op het eerste kan hij politiek sneuvelen, over het tweede ontstaan hooguit wollige debatten. Een project en het product dat het voortbrengt zijn onderdelen van het proces naar een niet expliciet meetbaar (politiek) doel. Het bestuurlijk debat richt zich vooral op dat proces en dus op het project en het product. Compromissen worden dan ook voortdurend op die twee variabelen gesloten. Die context kan de projectleider nooit veranderen, dat is de heersende modus operandi in openbaar bestuur waarop het ambacht van projectmanagement geen invloed heeft. Slechts maatschappelijke bewegingen zouden dat kunnen beïnvloeden.

De projectmanager zou wel kunnen proberen te zorgen dat projecten niet te groot en te breed worden opgezet. Die grootte en breedte zijn nl ideale vrijheidsgraden voor opdrachtgevers (en valkuilen voor projectmanagers) om doelverschuivingen in te verstoppen. Maak van een groot project een programma van meerdere volgtijdelijke of parallele projectjes en activiteiten, waarbij voor elk project(je) de producten, eventueel direct toerekenbare baten en GOKIT vastgezet worden op het moment voor de start van het betreffende project(je), en laat de ambetelijk opdrachtgever en openbaar bestuurder het batenrealisatieplan uitwerken. Daarmee speel je veel korter op de bal, en is een veel zuiverdere besturing mogelijk. Immers, de gelegenheid voor legitieme en transparante bijsturing is aanwezig en de ruimte voor het verstoppen van doelverschuivingen en bijbehorende financiële zwarte gaten ingeperkt. Uiteraard is deze aanpak nog steeds geen Haarlemmer olie, maar wel een effectieve manier om te voorkomen dat chauffeur en bijrijder beiden tijdens de reis steeds stiller worden en hopen dat de ander als eerste zal melden dat hij vermoed dat al vlak na het vertrek de eerste verkeerde afslag is genomen en dat daarna bij voortduring is gedaan en de eindbestemming eerder steeds verder verwijderd ligt dan naderbij komt. Bij een route van punt naar punt en vooraf slechts de globale eindbestemming kan steeds bij elke punt opnieuw bepaald worden hoe vanaf daar het best naar de eindbestemming kan worden gegaan en eventueel of een andere eindbestemming wellicht wenselijker is. Deze programmagewijze aanpak is een vorm waarin eenmalige doelen in een hybride van proces en project gestructureerd worden benaderd. Daarin wordt bijsturing, al dan niet door politiek korte-termijn-belang, als legitieme actie onderkend maar wel transparant gestructureerd ingevuld.

Mark van Rosmalen is werkzaam bij Verdonck, Klooster & Associates als project- en programmamanager en is gecertificeerd MSP-practitioner

Budget overschrijdingen (tijd of geld): wie heeft wáár belang bij? Even kijken naar de Stakeholders in een willekeurig project van enige omvang:
•Projectontwikkelaar(s)
•Opdrachtgever(s): bij voorkeur één, maar soms meerdere
•Opdrachtnemers (conglomeraat van leveranciers met één rojectnemer)
•de Burger (lees belastingbetaler)

Alleen al de mogelijke mengvormen maken de situatie zeer complex.
Leveranciers zijn normaal gesproken elkaars concurrent, maar zijn gedwongen samen te werken in een project. Een van de leveranciers doet een stap naar voren en accepteert eindverantwoordelijkheid voor het project, meestal tegen een percentage van de totale projectwaarde.
Als het allemaal nog niet complex genoeg is, kan een bijzondere situatie ontstaan: co-makership.
Dat is het geval als de opdrachtgever(s) iets willen dat voor de opdrachtnemers vernieuwend is.
In de industriële sector is zoiets héél gewoon. Dan worden risico’s gedeeld en het “eigendom” wordt onderdeel van de prijsonderhandelingen. Maar elk van de betrokken partijen heeft andere belangen en ook nog andere doelen. Dit alleen al maakt projecten tot een complex iets, waarbij “wat moet gebeuren” bijna per definitie pas kan ontstaan door er samen in te gaan en vooral in dialoog te blijven over wat met de nieuwe inzichten gewenst c.q. betaalbaar is. Ook de adviseur mag leren van het project, alleen NIET op kosten van de opdrachtgever en natuurlijk wel even eerlijk zeggen.

Ik vond de Case “automatisering continue stroom beleidsvoorstellen” een stervoorbeeld van hoe het NIET moet. Sterker nog: niet MAG!!! (ik snap best dat niet alles in drie regels te vatten is, maar daarom is het juist leuk, omdat het DWINGT tot essentie !!!)

Wat er WÈL staat:
•het werkproces transparanter
•reductie van papier
•doorlooptijd werkproces
•het zelfde werk met minder mensen

De laatste: “het zelfde werk met minder mensen” is een absolute projectkiller. Vooral in een ambtenarenomgeving zal dit, zodra het bekend wordt in de organisatie, met alle geoorloofde (!!!) vormen van verzet te maken krijgen. Lijdelijk verzet, natuurlijk, anders ontaardt het in WERKEN.

Hetzelfde kan ook anders worden geformuleerd: “meer throughput met dezelfde mensen”
Voordelen:
•betere service aan je “klanten”
•minder verstoringen (= minder “herstelkosten”)
•aan de capaciteit verander je (vooralsnog) niets (rust in de toko)

Wat er NIET staat:
•uniformering/standaardisering documenten (hier zit waarschijnlijk een veelvoud van de “winst”)
•workflow: automatisering logistiek proces (dramatische verhoging van de “servicegraad”)

Volgens mijn bescheiden inzicht (20 jaar ervaring aan de projectnemerskant) staat hier HET recept voor een debacle. Hier hadden organisatie adviseur, IT-advisor en andere desk-undigen NÓÓIT akkoord mee mogen gaan. Disaster looking for place to happen.

Voortschrijnend inzicht
Leveranciers van software als SAP, Baan etc. hebben de meeste “branches” wereldwijd al enkele honderden (en een aantal branches al duizenden malen) “gezien”. Daarmee hebben ze een geconcentreerde kennis in huis van “hoe er gewerkt wordt” en na verloop van tijd ook “hoe het anders zou kunnen” of . . . wel degelijk KAN. Deze kennis komt terecht in hun “verticale applicaties” of “brancheoplossingen”. Natuurlijk luisteren ze beleefd het verhaal van de Gemeente St. Annaparochie, Appelscha of Oekel en ze laten de mensen zelfs beleefd uitspreken. Maar als je 5000 gemeentes wereldwijd hebt geautomatiseerd, geloof me nou, weet je ECHT waar de schoen wringt. Zelfs als dat nu nog niet zo is maar in de toekomst zeker wel. Wat nu? Moet de Gemeente Barneveld nu zijn werkwijze aanpassen aan het pakket? Of kan het pakket worden aangepast aan de werkwijze als gevolg van de absoluut unieke situatie in Barneveld? De softwareleverancier wordt er niet warm of koud van. Hij heeft drie mogelijkheden:
•Hij verkoopt een standaard oplossing (kassa, maar wel snel graag voor zo’n kleine opdracht)
•Hij maakt maatwerk als de klant BLIJFT doordrukken. (uren x tarief is OOK omzet plus een relatie voor het leven)
•Hij heeft er geen trek in en gaan naar de volgende afspraak (sorry, maar u begrijpt . . .)

De wet van de accelererende achterstand.
Heel Europa ligt vol met koperdraad. Vervangen van oude- door nieuwe technologie kost hier drie keer héél veel geld:
•vervroegde afschrijving van “wat er ligt”
•kosten van de nieuwe oplossing
•voor westerse tarieven

In Oost-Europa of Azië ligt NIETS. Als dáár iets moet gebeuren, gaat dat in één keer van stenen tijdperk naar de stand van de éénentwintigste eeuw:
•geen afschrijving van oude troep
•kosten van een nieuwe oplossing
•voor een “introductieprijsje” (jullie willen hier toch zo graag naar binnen?)

Terug naar de Gemeente X
Tijdens het opstarten van het project léért de organisatie. Echt waar: het gebéúrt. Ook zonder organisatieadviseur, IT deskundige of logistiek specialist. De zuivere lucht van de niet-rokerwerkplekken zal worden vervuld van vele AH- en O-jee Erlebnisse. Gaande het project ontstaat nieuw inzicht in processen, werkwijzen, technieken en systemen. Dat is nou net het leuke van zo’n langlopend project, toch? Dat helpt den Menschheidt vooruyt, toch? Hoezo “moving targets”? Da’s toch logisch?

Dimensies van een project
Een project van einige omvang kent vele dimensies. Een héél belangrijke, wellicht de belangrijkste, is die van “tijd”. Alle andere dimensies veranderen in de loop van een project. De één wat meer dan de ander, maar veranderen DOEN ze. Technologische mogelijkheden van gisteren zijn anders als die van vandaag of morgen. Regelgeving, consumentengedrag, omstandigheden (denk aan politiek) veranderen met de dag. Juist dáárom haal je die deskundigen naar binnen. Van hen verwacht de opdrachtgever input over “wat zou kunnen” of “what-if”. Juist dáárvoor wordt die sky-high fee betaald.
Om het risico te verkleinen, om de output te vergroten, om de flexibiliteit etc etc etc.

Als je dan als organisatieadviseur, projectleider, IT-adviseur of willekeurige andere stakeholder gaat piepen over doorlooptijd, kosten of opleverdatum dan ben je niet bij de les. Dan kan je niet roepen “Dat konden we niet voorzien”, anders mag je honorarium PLUS een GIGA-schadeclaim terugbetalen. Ja, die Gemeentes moge dan in de ogen van de “afgestudeerden-op-het-onderwerp” wel simpel zijn, maar ze zijn NIET GEK!!!. Overigens ben ik een voorstander van die schadeclaims: houdt de adviserende stakeholders lekker scherp of minstens uit hun luie stoel. Naar de groene tafel met die hap.

Hoe dan wel?
Samenwerken is het toverwoord. Disciplines overlappen binnen elk project: van klein tot groot.
Op de overlappende gebieden ontstaat vaak iets waar de klant bij in slaapvalt, pisgiftig van wordt of . . . . . gewoon een ander “blik open trekt”: de strijd om het “beter weten”. Alle betrokken disciplines overlappen elkaar. Godzijdank, anders hebben we een probleem nog vóór we gestart zijn. Samenwerken, dus, heren en niet piepen. Vooral niet piepen.

Jos Steynebrugh
Marketing Consulent
Change Enhancement