Spring naar inhoud

Picture1_small

Vorige week werd ik aangesproken op mijn titel onder mijn handtekeningenblok in de e-mail en op mijn uitingen binnen I-IR. Daar moest ik even over denken en ja dat leidt dan tot een blogje. Ik heb namelijk ook vorige week opnieuw geleerd dat bij dilemma’s vooral transparantie mee helpt aan oplossen maar ook dat we vaak een andere oplossingsstrategie kiezen dan we ons initieel voornamen. Mijn functie onder mijn handtekening was 'Programma Manager TVS' en de opmerking was dat de indruk ontstond dat ik persoonlijk verantwoordelijk ben voor het succes van TVS en het maken daarvan.   Mijn eerste reactie was ook even "Ik negeer de boodschap en doe even niks" mijn tweede "Ik pas mijn handtekening aan en negeer de zaak" en mijn derde en uitgevoerde strategie is "Ik bekijk het eens van een andere kant en rationaliseer (ik licht toe en pas aan)" Mijn opdracht is het "voortbrengen" van 3 grote releases van het IV landschap TVS (Toelagen Vaststellingen Systeem), COPAFIJTH breed. Mijn officiële rol binnen Toeslagen is de BedrijfsProcesReleaseManager. Ik heb geen hiërarchische verantwoordelijkheid, de projectmanagers die dingen doen, uitvoeren, vallen onder andere afdelingen, stuurlijnen, managers. Dus mijn mandaten liggen in de lijn van monitoren, sturen, verantwoorden enzovoort. Verder ben ik in het rijksloongebouw Programma Manager binnen BZK Mijn opdrachtgever is de voorzitter van het Dagelijkse Bestuur, zijn rol Implementatie Manager voor .... Daarboven zit nog een Program Board waar een aantal Algemeen Directeuren van de diverse groepen in zitten. Mijn opdrachtgever zit daar als vertegenwoordiger van de gehele 'uitvoering' in. Ik zie mijn opdrachtgever als Executive misschien zelfs als SRO maar formeel is hij het niet. Kortom er zitten meerdere dimensies aan. Na enige reflectie denk ik dat de juiste kreet die ik intern de BD dien te hanteren de release manager is, een prima rol beschrijving. Voor het tweede stukje denk ik, ja die indruk is er al gauw. Ik praat vol passie en overtuiging over deze klus. Het is leuk, het is dynamisch, het is moeilijk, ik neem dagelijks een pittige beslissing, ik stuur keihard op het resultaat. Namelijk nieuwe processen, ketens, ICT, werkinstructies en noem het maar op. En ik maak daar uiteindelijk zelf nul procent van. In dit grote stuk ben ik qua uren of capaciteit minder dan 1 % van de totale hoeveelheid betrokken mensen. Maar ik ben natuurlijk wel extravert en meer dan bereid om over grenzen heen te stappen om het resultaat te bereiken. Nu weet ik dat ik naar allerlei betrokken mensen waar ik contact mee heb, regelmatig mijn waardering laat blijken. Er wordt hard gewerkt, het is lang niet makkelijk, zelfs soms zeer fluïde. Laat ik voor de rest van de omgeving het nog maar eens onverbloemd zeggen, de mensen die TVS maken zijn het succes en verdienen in deze een groot compliment. Ben ik overall blij met de terugkoppeling, zonder had ik het me niet beseft en er zeker niet zo nadrukkelijk over nagedacht. Zeker in de zendende boodschap zou de balans meer naar een wij-boodschap toe moeten. Eens kijken of mij (sorry nog één keer dan,  :-)) dat gaat lukken. -- ES --  

Binnen I-InterimRijk kennen we het fenomeen dwarskijkersadvies. En de afgelopen week heb ik zo'n advies contra gelezen en besproken met de uitvoerders. Jongens, jongens wat is dat moeilijk. Je krijgt de opdracht om gericht op een aantal vragen antwoorden te geven. En ondertussen krijg je in een week tijd erg veel inzicht en heb je meer antwoorden dan gevraagd.

Dwarskijker_small

Mijn constatering is dat je altijd feiten zichtbaar maakt die achter de vragen en antwoorden liggen. Projecten, programma's vragen in een dwarskijkersadvies vaak praktische vragen zoals "kan de planning .....", "is de business case .....". Maar de werkelijke oorzaken liggen vaak op een heel ander vlak. In een verkeerde ophanging, een onmogelijke governance, een mission impossible qua techniek. En met de ervaring en het gericht interviewen worden dergelijke aspecten altijd zichtbaar. Een dwarskijkersadvies levert altijd antwoorden en bewustwording op de gestelde vragen.De meerwaarde is dat je ook nog een antwoord krijgt op de achterliggende vraag en zelfs vaak op nog daarachter liggende problematiek Maar naar mijn idee is er een tweede gebied waar een advies een grote toegevoegde waarde heeft. Met een dwarskijkersadvies kan een directeur, programmamanager, direct betrokkene vaak de discussie starten op een aantal onderwerpen die buiten zijn directe aansturing liggen. Neem rijkswetgeving en gemeentelijke uitvoering. Met het decentraliseren van veel wetgeving moet er aandacht besteed worden aan de samenwerking, aan het mandaat wie er beslissen mag, wie er over de specificaties gaat, wie de eigenaar is c.q. wordt, wie er betaald, wie is er verantwoordelijk bij een blunder die een eindklant, burger, benadeeld? Als ik er wat langer bij stil sta dan gelden deze vragen algemeen bij alle ketenprogramma's maar ook bijvoorbeeld bij fusies In de hectiek van realisatie, zeker als er nog weinig tijd is, bepaalt het antwoord (of eigenlijk het ontbreken ervan) op dergelijke vragen hoeveel verstoring er kan optreden. En geloof me als de doorlooptijd, budget, commitment, .... krap is, dan komen die issues voorbij. En conform Murphy's Law op het ongunstigste moment. Die voorfase moet allerlei randvoorwaarden regelen. In alle gevallen waarin je programma je eigen organisatie ontstijgt is het zelfs een kritische succesfactor. Helaas zie ik teveel dat zij alleen in naam of als lijstje in een programmaplan terugkomen. De oorzaken daarvoor zijn divers, van onderschatting tot aan bestuurlijk lastig. Het repareren van de opzet, sturing, ambitie, doorlooptijd, budget ...... is moeilijk als de realisatie fase ingegaan is. Daarnaast is een programmamanager een gedelegeerde verantwoordelijke. Het is dus moeilijk om erkenning te krijgen voor het feit dat het alsnog regelen van de kritische randvoorwaarden nu tijd kost maar een veelvoud aan overschrijdingen voorkomt. En dat is de tweede grote kracht van een dwarskijkersadvies.   ---- ES 23 sept ----

Voor de vakantie de algemene start-up van de nieuwe NTS release gedaan. Meer sturen op de tussen- en eindproducten was de belangrijkste verandering aan het PID. Vandaag de HLR 'verder' doorgekanteld naar output sturing. Eigenlijk alleen nog maar vertellen over het wat, hoe en waarom niet van te maken (tussen)producten.   Dat zo'n kanteling mogelijk is komt doordat we precies weten welke producten we gaan maken in welke fases door welke partij. Bij een release is dat natuurlijk makkelijker als bij nieuwbouw, maar ik denk dat deze strategie breed toe te passen is. Er is ook een valkuil bij een dergelijk strak georganiseerde voortbrenging, als je niet oppast ben je alleen nog maar aan het sturen op het proces en raakt de "waarom doen we dit dynamiek" te ver op de achtergrond. Daarom in de start-up fase langer stil gestaan bij de vraag welke tussenproducten wel, niet te maken en vooral hoe die tussenproducten moeten leiden tot een permanente eindproducten. Om die eindproducten gaat het immers. Na deze exercitie, gesteund door de aanpak en fasering, heb je een productenlijst per fase in een periode.  Voila de door mij zo geliefde drieluik " Wie doet wat, waarom (niet). Nu heb ik nog twee uitdagingen te gaan. De master- en detailplanning. De masterplanning is nog een weerspiegeling van activiteiten niet zozeer producten. In de ultieme vorm is de masterplannig een lijst met opleverdata van producten. De mate van detail is de andere uitdaging. Inhoudelijk betrokken bestuurders willen graag zien, voelen, proeven (bij wijze van spreken) hoe het gaat. Op onderwerpen die hun aandacht  hebben wordt vaak veel detail gevraagd op de activiteiten voortgang. In combinatie met diep sturen is er dan voldoende borging op de kwaliteit van het product. Mijn persoonlijke mening is dat in de vorige zin eigenlijk staat sturen op output maar dan via een omweggetje.   Ik ga de komende week met dit fenomeen aan de slag. Daar komt vast nog een blogje uit. Wordt vervolgd... --- ES 31 augustus ---

Het werk Ik loop al een tijd mee in de ICT. Mijn banen, functies zitten al 10 tot 15 jaar in de driehoek, organisatie, proces, ict. Soms als product manager soms als relatie manager soms als project of programma manager. De grote constante is ICT enerzijds en de menselijke kant anderzijds. Ik ben in zoverre autodidactisch dat ik veel weet van een breed palet aan ICT en gerelateerde zaken door het mezelf eigen te maken. Ik ontdek graag nieuwe dingen. Mijn eerste fascinatie was techniek, toegepast maar ook wel wiskundig, statistisch. Ben al snel geïnteresseerd geraakt in methodieken, tools maar zeker de laatste 10 jaar ook meer en meer in de psychologie en de menselijke interactie. Lees graag, vindt het leuk om voor een onderwerp een paar goede boeken te kopen. En viola. Ik vind het leuk om iets toe te passen en uit te proberen. Een mooie cirkel, "Leren en Proberen" Onzichtbaar leren Als je naar mijn CV kijkt dan zie je dat ik met een periode van een jaar of 5 een dip in mijn cursussen, opleidingen heb gehad. Alles aan nieuwe zaken waar ik interesse voor had was, voor mijn gevoel, niet echt als kant-en-klare brok beschikbaar. Of onderdeel van een veel breder traject, of te algemeen naar mijn smaak. Daarnaast had ik een ander 'project' lopen waar veel inleren, tijd en inspanning inzat (2 kids ;-)). Ik heb dus 'niks' nieuws geleerd. Tenminste als je mijn CV er op naslaat. Het tegendeel is waar. Het was het moment waar ik overstapte van LogicaCMG naar het ministerie van Defensie. Ik werd onderdeel van een nieuwe besliscultuur, ik moest leren hoe te acteren in een deels militair deels burgerbestuur, ik ging (weer) van inhoud naar accountmanagement. Ik heb geleerd hoe memo's, beleidsvoornemen en LOI's te schrijven voor de ambtelijke staf. "Stafwerk" wordt het binnen Defensie genoemd. Vorm, opzet, toon, onderbouwing. Het zal vast een onderdeel zijn van de middenkader vorming. Large Account Management van Miller/Heiman deden we binnen de afdeling waar ik zat. Ik gebruik tot op vandaag wat van de achterliggende concepten en een enkel template. Het was ook het begin van het doorvoeren van demand en supply in de DTO organisatie zelf. Waarom, wat is het, hoe (mis/ge)bruiken we het. Veel, heel veel geleerd of heet het "gegroeid" als je het in de praktijk doet. Gecertificeerd zijn Dat verzamelen van kennis gaat bij mij altijd wel door. Maar sinds het einde van 2011 ben ik ook weer aan het leren. Cursusmateriaal, les, oefeningen, een examen en een accessment aan het eind van dit jaar. Het doel is gecertificeerd te worden voor IPMA. Vanuit mijn nieuwe werkgever I-InterimRijk is het beleid dat project- en programmamanagers gecertificeerd zijn. Ik vind dat om 2 redenen een puik plan. Bij certificering moet je aantonen een bepaald niveau, werkwijze en kennis te hebben, te gebruiken. Hoe je die kennis verzameld hebt, is niet relevant. Dus mooi meegenomen voor een autodidact als ik. Ook het feit dat certificering tijdelijk is, is geweldig. Je moet over een tijdje opnieuw aantonen dat je kennis en kunde op de dan geldende norm ligt. Het toont aan dat je meegroeit, niet stil staat. Een drie-eenheid Voor mij is de drie-eenheid: gecertificeerd, ervaring in je CV c.q. je referenties en als derde betrokkenheid in vakgroepen, studies, lezingen of artikelen een mooie mix die goed aansluit bij mij als persoon. Het geeft daarnaast, bij mijn bazen en toekomstige opdrachtgevers, een goed beeld wat ik kan c.q. waard ben in plaats van wat ik aan cursussen gedaan heb.
--- ES ---    

De term "Buy before Make" is wel bekend in Rijksoverheid IT trajecten. En laten we elkaar in de ogen kijken en toegeven dat het implementeren van standaard software voor primaire systemen bij de Rijksoverheid geen gemakkelijke klus is. De succesverhalen van implementaties waar men het aandurfde om met standaard functionaliteiten, en geen tot minimaal maatwerk, ook werkelijk een draaiend systeem op te leveren zijn minder aanwezig dan de verhalen van heroriëntatie op de architectuur, functionaliteit en een boel meerwerk in maatwerkprogrammatuur. Het is, denk ik, een veel geschonden uitgangspunt. Van een collega onderdeel binnen Justitie heb ik de term "Resue before Buy before Make" geleend als één van de uitgangspunten in een Project Start Architectuur. Nu doen onliners het altijd goed mede omdat iedereen er zijn, haar eigen beeld bij heeft. Voor de één is Reuse de ervaring delen. Of hergebruik van een softwarelicentiecontract. Laat ik dat een lichte vorm van Reuse noemen. Ergens in het middensegment van Reuse zijn er dan constructies als het trekken van een kopie van een omgeving en als kloon gaan gebruiken voor je eigen doeleinden. Als je in zo'n constructie ook nog kans ziet om uit te komen op één bronsysteem en veel functionaliteit die identiek is, dan is het al 'echte' Reuse. De maximale vorm van Reuse is dat een bestaand systeem ook door een tweede, derde rijksoverheid onderdeel gebruikt wordt. Dat klinkt vreemd in de oren want de primaire processen zijn toch allemaal anders, uniek, een eigen wet of uitvoeringsbeleid dienende etc. En anders kan het toch ook niet omdat de gegevens, de toegang, het gebruik gescheiden moet zijn en blijven. Technisch is dat binnen veel ERP, CRM, LOG, PM, SAL systemen allang mogelijk. Denk aan de oude klassieke salarissystemen of heel modern aan CRM ala Saleforce. De kracht schuilt hem in het scheiden van de "Know en de Flow" (jawel, opnieuw een geleend citaat). Gebruikersrecht van licenties, de samenhang van een applicatielandschap, de basisinrichting van losse applicatiecomponenten, mogelijkheden tot “customizing”, opleiding, data conversie enzovoort zullen aspecten zijn van Reuse. Het aanbiedende Rijksonderdeel zal werkzaamheden, activiteiten uitvoeren c.q. binnen haar eigen, bestaande contracten met leveranciers uitbesteden. Ik stel dat ontheffing-gevend, subsidie-verstrekkend, visum-aanvragend, bezwaar-aantekenend, verklaring-afgevend prima in één systeem kunnen mits er sprake is van een aanvraag, informatie verrijking, analyse, besluitvorming, afhandeling (al dan niet bezwaar) en de know (materiekennis, wetgeving, waarden en grenzen) formeel is vast te leggen. Goed, laten we voor deze overpeinzing de fit-for-purpose en de technische uitdagingen als opgelost beschouwen. Waarom passen we dit dan nog niet toe? Eén reden is dat een dergelijke Reuse ook wel een Product of Dienst genoemd kan worden en Rijksonderdelen geen leverancier zijn. Ze zijn een uitvoerend orgaan of een beleidsdirectie of .... Het is niet hun taak en hun ambitie. Er zijn Rijksonderdelen die dit type dienstverlening wel tot hun kernactiviteit mogen rekenen. Shared Service Centers en grotere departementale IT leveranciers. Als agentschap hebben zij op dit moment nauwelijks groeimogelijkheden met bezuinigingen op vte's en budget. Kortom er is geen 'natuurlijke' aanbieder. En de commerciële aanbieders dan? Goede vraag voor een andere keer... Ik zou hier een stelling willen neerzetten: "Maximale vormen van Reuse binnen de rijksoverheid betekenen een vergaande vorm van inbesteden". Reuse raakt enerzijds een applicatielandschap, de inrichting en anderzijds applicatie en technisch beheer, housing en hosting. Reuse houdt niet op na de inrichtingfase maar begin dan pas echt. In dit soort gevallen zal er een operationele samenwerking ontstaat tussen Rijksoverheden. De praktijk van één grotendeels gemeenschappelijke Informatie Voorziening betekent namelijk ook afstemmen, het delen van kosten, oog voor elkaar belang, gelijkheid in relatie, flexibiliteit in bestuur en leiding, enzovoort, enzovoort.  En dat is in mijn optiek de tweede reden waarom dergelijke complexe samenwerkingen nog zo weinig voorkomen. Een dergelijke evolutie van een model van eigen naar 'natuurlijk, langdurig' hergebruik vergt externe prikkels en tijd. Die externe prikkels zijn er, van besef tot aan concrete besparingen. De tijd loopt vanzelf..... Binnen mijn huidige opdracht is "Resue before Buy before Make" een topic en alleen daarvan wordt ik heel gelukkig... --- ES ----

Een nieuwe opdracht, altijd spannend en ook altijd weer moeilijk. En met reden. Het is geen kleine opdracht, je bent aangenomen vanwege je meerwaarde, je kennis, je overtuigingskracht, je … En dan moet je dat ook waarmaken.
Het inwerken gaat snel. Er is veel informatie aanwezig voor een al ingepland review. Toch vond ik de eerste maand uitdagend, zelfs moeilijk. Je bent, in je hoofd, zeer druk bezet. Al pratend, lezend, schrijvend zie je 100 detailzaken waar je beslist iets mee moet als overall programma manager. Maar belangrijk, belangrijker voor mij is ook het goed vaststellen: “Wat gaan we doen, waarom, waarom niet, wie gaat het doen?”. De vragen werden na 2 weken uitgebreid met “Wat verwacht de opdrachtgever, de directie, wat zijn nu de grootste zorgen van de directie, hoe voelen de betrokkenen zich, begrijpen we met zijn allen wat de missie is?”
En dus gaat de aanpak van een heel-resultaat-gericht-plan (type voorwaarts mars) naar een iets-meer-overdenken-motiveren-plan (wat gaan we samen doen). Hoewel klassiek, is mijn grootste uitdaging toch de betrokkenheid van midden management en de gebruikers. In mijn geval mede omdat de nieuwe, gewenste manier van werken proces georiënteerd is. En de huidige, bestaande manier product gericht is. We beseffen dat dit een verandering is. De discussie is in hoeverre je deze verandering een onderdeel van je programma maakt of een parallel spoor in de organisatie. Zonder die verandering zal de introductie van nieuwe IV moeizaam zijn, van specificatie fase tot aan acceptatie en in productie name. Zonder nieuwe IV is er geen prikkel voor een verandering van bedrijfsprocessen.
Mijn voorkeur heeft het om die verandering onderdeel te maken van het vernieuwingsprogramma overall. De redenen zijn praktisch.

1.       Continue afhankelijkheden tussen de IT en IV veranderingen. Over en weer kritische randvoorwaarden;
2.       Bij 2 gescheiden trajecten is er naast een dubbele sturing toch ook veelvuldige afstemming nodig;
3.       In mijn omgeving is de totale omvang van de organisatie zo dat meerdere rollen toch ingevuld worden door dezelfde persoon;
4.       Ik denk dat de vernieuwing van de IV een katalysator is voor de veranderingen in bedrijfsprocessen.

En dus ben ik als programma manager dan liever opdrachtnemer met het stuur in handen dan de bijrijder.
Onderdeel van die taak zal ook het formuleren zijn wat we aan activiteiten, taken, werk moeten doen in het verandertraject. En ik zal vooraf een omslagpunt moeten inbouwen. Wat als de doorlooptijd c.q. het gebrek aan resultaten het IT traject gaat beïnvloeden? Een nieuw risico en de bewaking ervan.
Work in progress, --- ES ---

Sinds 2 mei ben ik op uitleenbasis betrokken bij I-Interim Rijk. Wat is I-Interim Rijk en welke kant gaan we op? Ik lees en hoor 2 meningen die ik ter wille van de discussie wat zwart-wit neer zet:

  1. Detachering, een pool van mensen die op tijdelijke basis gedetacheerd bij andere Rijksonderdelen dan waar ze in dienst zijn (IF-regeling).
  2. Deskundigen die het Rijk c.q. de Rijks-CIO moeten helpen de  IV portfolio te verbeteren en de ICT programma’s succesvoller te laten zijn.

Er is niks mis met detachering, erger nog het economisch voordeel is zo groot voor de collega’s als opdrachtgevers dat misschien de tweede doelstelling wat ondergeschikt lijkt te raken. En die tweede doelstelling is natuurlijk waar ik enthousiast van raak. Deskundigen die helpen de zaak te verbeteren. Dat roept bij mij al gauw een beeld op met heel veel gevoelens, randvoorwaarden, uitdagingen, niet alleen uitvoerder zijn maar ook kunnen ‘bij-‘sturen, en andere instelling en het positief beïnvloeden van veel organisaties en mensen, enzovoort enzovoort. Ik overdenk dit eigenlijk al sinds ik als programmamanager aan Justitie en Veiligheid ben uitgeleend. Als ik onderdeel ben van een “Rijksdeskundige die  …. succesvol …. “ waarom zou ik dat wel zijn en mijn collega programma / project managers uit de commerciële markt mogelijk niet. Vakinhoudelijk ben ik niet anders, niet beter dan vele goede collega’s. En daarom is het voor mij maar hopelijk ook voor jullie allen interessant dit uit te pluizen. Als ik me beperkt tot één van de vele aspecten die dit beïnvloeden, dan zou mijn eerste stap zijn:
“wat maakt IV programma’s / ICT projecten succesvol”
En daar daag ik jullie uit om mee te onderzoeken en in deze discussie verwijzingen te publiceren naar case studies en ander onderzoek. Ik zou op basis van dit naspeuren willen bouwen aan praktische later misschien fundamentele kennis hoe de  IV portfolio te verbeteren en de ICT programma’s succesvoller te laten zijn. --- ES ---