Hoe vaak ik al niet met een programma-manager om de tafel heb gezeten die niet meer wist waar te beginnen om zijn programma weer in goede banen te gaan leiden.

• Mensen die met allerlei activiteiten zijn gestart die niet iets opleveren wat aan programmadoelen kan worden gekoppeld.
• Mensen die werken aan producten terwijl de benodigde input voor dat werk er nog helemaal niet is.
• Tijd en geld worden weggegooid waar iedereen bij staat. Als de programma-manager terug kijkt naar de afgelopen weken ziet hij tot zijn spijt dat hij vele acties heeft ondernomen die geen enkel effect hebben gehad. Of hij heeft ingrepen geplaatst en producten laten maken die nu al weer in de kast zijn geplaatst.
• Steeds meer mensen om het programma heen krijgen het gevoel dat het programma stuurloos is geworden en een zigzagkoers vaart.

Een centrale vraag die ik als enterprise architect met de programma-manager dan probeer te beantwoorden, om het programma weer op de rails te krijgen, is: Wie doet nu wat en waarom en wie maakt welk product en wie gaat er dan wat mee doen?

Met het antwoord op deze vraag kan de programma-manager er beter aan werken dat er alleen dingen worden gedaan die zin hebben in het licht van de programmadoelen en er aan werken dat iedereen in het programma de benodigde input krijgt voor zijn werk. Beter laat dan nooit. En wie weet: gaan we het programma nog op tijd en binnen budget succesvol afronden.

Om de centrale vraag te kunnen beantwoorden is een gemeenschappelijk beeld bij de opdrachtgever, belanghebbenden en stuurgroep van de huidige situatie en gewenste situatie van de programmaomgeving essentieel. En wat doe ik dan: Ik zeg dat er een schets moet worden gemaakt. Er moet een programma-activiteitenschets worden gemaakt die is gebaseerd op de bouwplaat van de programmaomgeving.

Voor de man met de hamer is alles een spijker. Ik denk dat analoog hieraan aan de oplossing van veel problemen pas goed kan worden gewerkt met grove schets van de oplossing geprojecteerd op een detailtekening het probleemgebied. Schetsen, schetsen, schetsen. De complexiteit van zo’n beetje elk programma en elke verandering is zo groot geworden dat het niet meer te doen is om aan problemen te werken zonder daar de goede schetsen en tekeningen voor beschikbaar te hebben.

Voor het reguliere werk dat op afdelingen plaatsvindt, vinden we het maar al te normaal dat er een procesbeschrijving en procesvisualisatie van is. We willen immers efficiënt met onze resources omgaan.

Ook ik maak overigens fouten. Een die fout die ik in het verleden heb gemaakt is om wel de bouwplaat te maken, maar niet de programma-activiteitenschets.

Een schets van het activiteitenmodel van de programmaomgeving ontbreekt bijna altijd. Dit terwijl er in elk programma eigenlijk altijd afstemmingsproblematiek is omtrent producten, opleveringen, afspraken, kwaliteit, validatie en RACI.

Bij alle klantorganisaties waar ik tot nu toe ben geweest heb ik veelal het initiatief genomen om een schets te maken van de activiteiten die binnen de verschillende programma’s en projecten afspelen. Samen met de afdelingen uit de staande organisatie moesten er dan activiteiten worden uitgevoerd in een consistent samenhangend geheel van activiteiten om uiteindelijk tot een goed eindresultaat te kunnen komen.

De programma-activiteitenschets heeft altijd veel effect gehad.

Met een dergelijke schets werd dan inzichtelijk gemaakt welke activiteiten, rollen en producten niet goed genoeg waren afgesproken of sowieso ontbraken, of welke competenties niet naar behoren waren ingevuld. Dit is vaak het geval in bijvoorbeeld een multiprogramma omgeving.

Wat is de truc om een programma-activiteitenschets te kunnen maken die veel waarde en impact heeft?

De truc is: architectuur!

Stel, vanuit de architectuur is er een bouwplaat gemaakt van de te bebouwen programmaomgeving die in feite een puzzel is van het gewenste of te realiseren eindresultaat ( een veranderde besturing of dienstverlening, procesinnovatie of een ontwikkeld informatiesysteem, een zwaardere infrastructuur, of een geheel van deze vijf ).

Deze bouwplaat heeft als het goed is de te ontwerpen en te bouwen onderdelen (de puzzelstukjes) in zich. Van elk onderdeel dient er in de programmaomgeving uiteindelijk een product (als document of met bijbehorende documenten) te worden gemaakt. De onderdelen op de bouwplaten moeten stuk voor stuk aan de programmadoelen en doelstellingen kunnen worden gekoppeld. Als dat kan, dan kunnen de documenten en de producten ook aan de programmadoelen worden gekoppeld.

Je kunt dus de alle documenten die in een programma moeten worden gemaakt in principe spiegelen aan de bouwplaat. Je kunt aangeven in welke volgorde onderdelen die op de bouwplaat staan gemaakt moeten worden. Je kunt aangeven in welke volgorde documenten moeten worden gemaakt. Het werkt met een bouwplaat ook lekker om dat je vanuit een gemeenschappelijk begrippenkader werkt aan integraliteit en er voor kan zorgen dat de documenten, die nu in de bouwplaat op elkaar worden afgestemd, elkaar ook nog eens op een juiste wijze gaan beïnvloeden. Een extra dimensie die je goed aan de bouwplaat kunt toevoegen is dat een onderdeel van grof naar fijn kan worden ontwikkeld en dat documenten ook van grof naar fijn onderdelen kunnen beschrijven en visualiseren.

De leukste dimensie die je kunt toevoegen is de dimensie van principes. Elk onderdeel dat moet worden ontworpen en gebouwd kun je principes meegeven vanuit de architectuur. Het zou zo maar de kwaliteit van de gerealiseerde onderdelen kunnen vergroten.

Als we de bouwplaat en de programmadocumenten in beeld hebben, dan kunnen we aan elk product en document de bijbehorende rollen, personen en werk koppelen. Immers de producten en documenten komen niet uit de lucht vallen: Daar moet wel wat voor gedaan worden.

Tenslotte kunnen we de activiteiten, taken, handelingen, rollen, verantwoordelijkheden, bevoegdheden, producten en relaties in samenhang op een programma-activiteitenschets plaatsen. De programma-manager heeft nu een activiteitenmodel in handen die hoort bij de bouwplaat. Nu kan hij gecontroleerd aansturen op de nieuwe vereiste werkelijkheid in het programma.

Hé, architectuur lijkt wel een stuurinstrument ;-)

Er is alleen één ding: Er moet wel een architect rondlopen die een bouwplaat kan maken van de programma omgeving en een activiteitenschets van het programma.

Comments (2)

Only registered users can write comments.
Please login or register.

Share / deel