Tijdens het uitvoeren van audits krijg ik van opdrachtgevers regelmatig de vraag: ’hoe houd ik grip op mijn programma?’ Complexiteit en urgentie van de noodzakelijke verandering alsmede de introductie van de agile werkwijze en bijbehorende zelfsturende teams versterkt deze vraag. Dan wordt het inhoudelijk sturen en vragen van rapportages vaak afgedaan als een vorm van micromanagement. Of nog erger: de opmerking dat je geen vertrouwen hebt in de uitvoerende teams.
Vaak zie je dan ook nog een verschil tussen enerzijds de meer inhoudelijke opdrachtgever – met affiniteit voor ICT en het onderhavige onderwerp – en anderzijds de meer bestuurlijke opdrachtgever die zich laat informeren door de programma-omgeving. Bij veel bestuurlijke opdrachtgevers is het programma gewoon niet ‘hun ding’. Hierdoor ontstaat automatisch meer afstand, de drempel om informatie te vragen wordt hoger en men vertrouwt meer toe aan de programmamanager (“hij/zij regelt het wel”). Het resultaat is een sterke vertrouwensrelatie tussen programmamanager en opdrachtgever, wat leidt tot een cultuur waarbij zowel de opdrachtgever als de programmamanager naar de mond wordt gesproken. Ook zie je regelmatig gebeuren dat misinterpretatie van het agile gedachtengoed de inhoudelijke opdrachtgever op afstand zet. Inhoudelijke vragen worden veelal afgedaan als niet meer gewenst omdat het projectteam als zelfsturend team werkt. En zich dus voor vragen rechtstreeks tot de klant wendt. In deze blog reik ik drie zaken aan die je als opdrachtgever meer in control brengen en waardoor het vraagstuk ‘moet ik me laten informeren of moet ik inhoudelijk sturen’ minder relevant wordt:
- Inzage in de karakteristieken van het programma: wat behelst dit programma nu eigenlijk en wat verandert er allemaal?
- Organiseren van tegenspraak: hoe gaat het nu echt met het programma?
- Voorkomen van stapeling van complexiteit.
Inzage in de karakteristieken van het programma: Wat behelst dit programma nu eigenlijk en wat verandert er allemaal?
Een discussie die ik vaak tegenkom tijdens een audit is de vraag: ‘wat doet het programma allemaal en is het daardoor een project of een programma?’. Los van de MSP/Prince II technische inkleuring is het stellen van deze vraag vaak al een sterke indicatie van het gebrek aan zicht op en afbakening van het uiteindelijke resultaat. Immers zowel een project als een programma leidt tot een verandering, en kan leiden tot de realisatie van een of meer resultaten. Om de karakteristieken, maar vooral de complexiteit en de noodzaak van de gewenste verandering en resultaten te duiden hanteer ik dan ook graag onderstaande figuur.
Figuur 1: Verschillende aspecten van verandering (klik op de afbeelding om de afbeelding te vergroten.)
Bovenstaand diagram dwingt je namelijk om na te denken en per aspect aan te geven of en in welke mate deze voor het programma van toepassing is. Het antwoord op deze vraag leidt tot het inzicht: ‘welke verandering(en) en resultaten betreffende dit specifieke aspect zijn noodzakelijk voor de verandering binnen de organisatie’. De bundeling van deze antwoorden leidt vervolgens tot verrassende effecten en verscherpt het inzicht bij de betrokkenen in en rond het programma. Bijkomend effect is dat het beantwoorden van de vraag ‘is het een project of een programma?’ makkelijker wordt. Is er sprake van het nastreven van een verscheidenheid aan samenhangende (strategische) doelen dan hebben we het over een programma. Beoogt de verandering een uniek en concreet resultaat dan is er sprake van een project. Deze bewustwording helpt de opdrachtgever bij het bewaken van de scope van het project of programma. En biedt handvatten om inhoudelijke vragen te stellen over het programma en daar waar nodig bij te sturen.
Organiseren van tegenspraak: Hoe gaat het nu echt met het programma?
Als metafoor gebruiken wij hier het doorsnijden van de watermeloen (het programma). Een kernkwaliteit van een goede programmamanager is de organisatie in beweging krijgen. Dat doet hij door positief en enthousiasmerend over het programma te communiceren: ‘alles gaat goed!’ (de watermeloen is groen). Daar zit hem tevens ook het grootste gevaar. De programmamanager beschikt over de vaardigheid om overtuigend te argumenteren en focus en richting te geven aan zijn programma. Afhankelijk van de fase en de voortgang van het project of programma is tegengeluid dan steeds minder gewenst, of wordt soms zelfs helemaal geëlimineerd.
Dit tegengeluid duidt echter vaak op een gebrek aan informatie en het onjuist bedienen van de stakeholders van het project of programma (zij snijden de watermeloen door; er blijken wel degelijk rode stukjes te zijn). Dit zomaar de kop indrukken zorgt voor een omgekeerde reflex. Met als gevolg verminderde acceptatie van het resultaat of de verandering en daardoor discussie, vertraging en toenemende kosten.
Het organiseren van tegengeluid en het op de juiste wijze bedienen van de stakeholders is dan ook een van de succesfactoren van een project of programma. Immers zonder wrijving geen glans. Het organiseren van tegengeluid in het programma, zowel intern als extern, zorgt ervoor dat er goede vragen gesteld worden over de wijze waarop het programma in control denkt (zegt) te zijn over bepaalde onderwerpen. Door hierover te praten in termen van risico’s en maatregelen in plaats van absolute waarheden ontstaat er een goede dialoog op basis waarvan blijkt of het programma echt in control is: “Het risico wat je benoemt is terecht, wij hebben in het programma hiervoor de volgende maatregel bedacht:…”. Als de programmamanager dat niet wil of kan dan is dat een teken dat hij niet in control is en het dus terecht is dat je je als opdrachtgever zorgen maakt. Het organiseren van tegengeluid kan over de as van de inhoudelijke aspecten zoals hierboven in de afbeelding weergegeven, maar kan ook over de as van het proces waardoor gekeken wordt naar zaken als business case, projectgovernance, samenwerking, etc.
Goede tegenspraak leidt tot een substantiële bewustwording van het programma binnen haar omgeving. Het zorgt ervoor dat onzekerheden en onduidelijkheden benoemd worden in termen van risico’s, impact en maatregelen. Hierdoor ontstaat een sturingselement voor de opdrachtgever. Immers welke risico’s draagt het programma in zich, zijn er maatregelen gedefinieerd waaruit blijkt dat het programma in control is. Heeft de opdrachtgever grip op deze maatregelen, en iets te kiezen.
Stapeling van complexiteit
Zoals hierboven benoemd zorgt de programmamanager ervoor dat het programma leidt tot beweging en verandering in de organisatie. Vaak beschikt het programma hiertoe over een uitgebreid programmabudget. Te vaak worden vervolgens aanvullende veranderingen toegevoegd aan het programma.
Een veel gezien voorbeeld hiervan is het ‘out -of-support’ zijn van bepaalde software. Dit dilemma leidt tot een programma waarin de bestaande software met urgentie wordt vervangen en desgewenst de bedrijfsprocessen worden aangepast. Naast inhoudelijke complexiteit komt daar voor een dergelijk programma vaak ook nog aanvullende complexiteit bovenop. Immers het nieuwe beleid van de afdeling ICT is het naar de cloud brengen van dergelijke oplossingen. De oorspronkelijke maatwerk applicatie wordt daardoor vervangen door een zogenaamde Commercial of the Shelf-applicatie (COTS) met bijbehorende best practices. De stapeling in complexiteit die ontstaat is:
- Technologische transitie: De software gaat van beheer door de eigen ICT-afdeling servers naar een IAAS of SAAS oplossing maar dan in de cloud. Oftewel extern beheer.
- Organisatorische transformatie: onze bedrijfsprocessen die waren afgestemd op de huidige maatwerk applicatie moeten worden vervangen door zogenaamde best-practice bedrijfsprocessen. De beperkte aanpassingen die waren voorzien worden ineens substantieel.
Beide bovengenoemde veranderingen zijn op zichzelf al complex en leiden tot weerstand. Laat staan wanneer je deze combineert. Ik hanteer dan vaak de beeldspraak van het diagonaal oversteken van een druk kruispunt.
Om veilig (risico: kans op verongelukken) de overkant van een weg te bereiken legt de wegbeheerder een zebrapad aan (maatregel: verkeerstechnische oplossing met bijbehorende regeling). Beide veranderingen doen betekent diagonaal oversteken. Dit is levensgevaarlijk en soms zelfs verboden, de wegbeheerder heeft hier immers geen maatregelen voor.
Een vaak gehoorde opmerking vanuit het programma is dan: “het kan niet anders, het moet zo”. En dat is nu maar net de vraag. Beter is het te inventariseren welke complexiteit de beide veranderingen in zich dragen en op basis van noodzaak deze te spreiden, zoals in onderstaande afbeelding.
Figuur 2: Inzichtelijk maken stapeling complexiteit
In plateau I voert het programma de technologische transitie uit (we gaan naar de cloud) en een heel klein randvoorwaardelijk deel van de organisatorische transformatie. Hiermee houden we de ‘oude’ applicatie nog iets langer in de lucht zodat we deze gefaseerd in plateau II kunnen afbouwen waarin we de bedrijfsprocessen hervormen en daarmee de noodzakelijke organisatorische transformatie realiseren.
Het inzichtelijk maken van de complexiteit van de afzonderlijke assen (technologische transitie en organisatorische transformatie) en het sturen op maatregelen zorgt ervoor dat je als opdrachtgever grip houdt op het programma.
Tot slot
Uit bovenstaande voorbeelden blijkt: de keuze tussen inhoudelijk sturen of informeren bestaat niet. Belangrijker is er voor te zorgen dat je als opdrachtgever ervaart dat het programma in control is. De drie genoemde aspecten en de informatie die hierom heen ontstaan helpen je als opdrachtgever hierbij. Ook dragen ze bij aan het inzichtelijk maken van de complexiteit van de noodzakelijke verandering. Vraagstukken worden zichtbaar voor het programma en haar omgeving.
Joop Rasser is een ervaren programma-/interimmanager die gewend is te werken op het snijpunt van organisatorische en technologische verandering. Op basis van zijn kennis en ervaring wordt hij regelmatig gevraagd om programma’s en projecten te reviewen. Daarnaast is hij goed ingevoerd in verschillende toetskaders waaronder die van het Bureau ICT-toetsing.