Hoe past mijn initiatief binnen de digitale context van mijn bedrijf? #ITGovernance

1 Inleiding en leerdoel

We kunnen niet voldoende herhalen dat een digitaal initiatief of een project niet op een eiland wordt uitgevoerd. Binnen een bedrijfscontext bestaan er processen of afspraken die (digitale) projectideeën doen ontstaan. Verder zal een digitaal initiatief altijd sterk verbonden zijn met de IT-ambities en de IT-werking binnen de onderneming. Het is dus logisch dat we bij die processen even stilstaan. Die processen zijn namelijk een gegeven waarmee voor, tijdens en na het project dient te worden rekening gehouden.

Een project leiden betekent ook dat je als projectmanager continu weet wat de status van je project is. Het opvolgen en rapporteren van je project vraagt veel aandacht van de projectmanager en het ganse projectteam.

Beide facetten die we hierboven benoemden, vallen onder de noemer ‘governance’.

Governance omvat de processen en afspraken die gemaakt worden binnen en rondom het project en die vooral tot doel hebben om het initiatief te beheren en te beheersen.

In de voorgaande editie van dit boek was dit onderwerp vervat in het hoofdstuk rond projectopvolging. Het is echter noodzakelijk dit ruimer te beschrijven. In de hedendaagse onderneming werkt men elke dag rond verbeteringen, veelal – maar niet altijd! – ondersteund door goede digitale oplossingen en technologieën. Daarom dat we ook aandacht willen schenken aan die dynamische bedrijfscontext waarbij vanuit ideeën wordt gewerkt tot aan een geïmplementeerde oplossing via identificatieworkshops, beoordelings- en prioriteringssessies, plannings- en portfoliomeetings enz. De samenwerking en interactie binnen de organisatie voor, tijdens en op het einde van het project, is minstens even belangrijk en wordt dikwijls verwaarloosd. De voornaamste raakvlakken en onderwerpen worden belicht in dit hoofdstuk.

Op het einde van dit hoofdstuk: kan ik goede praktijken toepassen om de status van mijn project te rapporteren;

… ben ik vertrouwd met het belang van veranderingsaanvragen én bewaak ik mijn project door daarop correct te reageren; ken ik als projectmanager de verwachtingen van de IT-afdeling en begrijp ik hoe me op hun werking af te stemmen; heb ik goede noties van de governance binnen een onderneming die relevant is voor mijn project.

2 Projectopvolging als deliverable voor de projectmanager

2.1 Opvolging organiseren

Controle of opvolging in de praktijk is een dagelijks aandachtspunt voor elke projectmanager. Aangezien we van bij de start van het project (initiëren) veel inspanningen hebben geleverd om het project op de rails te krijgen, moeten we nu alle facetten ook opvolgen.

Iedere projectmanager dient voor zijn project de best mogelijk organisatie te vinden die toelaat controle te krijgen. De informatie dient vlot en efficiënt doorheen het volledige projectecosysteem te stromen tot bij de stakeholder die er nood aan heeft. Om een goed zicht te hebben en te houden op het project is het dus een noodzaak de informatiestroom zo te organiseren dat de projectmanager of bij uitbreiding het projectmanagementteam op het knooppunt zit van alle cruciale informatiestromen. Op die manier krijgt de projectmanager of zijn projectmanagementteam alle info in handen om een degelijk en waarheidsgetrouw statusrapport te kunnen samenstellen.

Het meest gebruikte hulpmiddel om statusinformatie te verzamelen is ‘vergaderen’. We kunnen daarmee instemmen, maar het is wel van groot belang dat de verschillende meetings op elkaar zijn afgestemd opdat elk forum of elke vergadering de juiste inputs krijgt en de juiste outputs genereert. In paragraaf 3 ‘De efficiënte projectmeeting: hoe draag je bij tot een vlotte projectopvolging?’ lichten we toe hoe een efficiënte projectmeeting kan worden aangepakt. Daar leer je dan ook wat nuttige inputs en relevante outputs kunnen zijn.

Vergaderen als enige hulpmiddel is jammer genoeg niet voldoende. Zo zal men snel vaststellen dat niet iedereen even geïnteresseerd in een vergadering zit, dat het altijd dezelfde personen zijn die spreken of voorbereid zijn, dat de korte tijd in de vergaderruimte onvoldoende blijkt om een stand van zaken op te pikken van bepaalde teamleden enz. Vanuit organisatorisch perspectief is het bijgevolg ook zeer belangrijk dat de projectmanager voldoende tijd vrij maakt om ‘in de buurt te zijn’, ‘zich op de projectvloer te begeven’ en informeel te overleggen met zijn team.

2.2 Bepalen van controlepunten

De centrale vraag die we ons in dit hoofdstuk stellen is of we (bijna) knock-out tegen het canvas liggen of nog fit en gezond rechtstaan. Gaan we nog in een rechte lijn naar onze doelstellingen?

In de praktijk stellen we vast dat veel projectmanagers wel de moeite doen om enkele meetpunten te identificeren, maar dat ze die jammer genoeg zeer subjectief beoordelen. Er is uiteraard niets mis met het hanteren van een TLR-rapport (traffic light reporting of rapportering via groen/oranje/rood zoals een verkeerslicht) of het gebruik van smileys; maar hoe accuraat is de kleur van de smiley bepaald? Zit er een opvolgingsmodel achter of werd de status ‘op gevoel’ gegeven? Het is die subjectieve aanpak die vaak later in het project leidt tot enkele gevreesde statements: ‘We zullen de geplande opleveringsdatum niet halen’, ‘Het project vraagt vandaag een budgetverhoging van 15 %’, ‘We hebben vastgesteld dat het team niet de kwaliteit heeft geleverd die we voorzien of beloofd hadden’, ‘Die issues hadden we niet zien aankomen en we staan vandaag dus met de rug tegen de muur ’ enz.

Er zijn echter domeinen binnen de scope van de projectmanager die meer vragen dan een subjectieve benadering. Daartoe wensen we enkele hulpmiddelen aan te reiken.

Hoofdstuk 16 Hoe past mijn initiatief binnen de digitale context van mijn bedrijf? #ITGovernance

De vraag die we ons als projectmanager moeten stellen is wat we willen rapporteren. Wat zijn met andere woorden de meetpunten die ik aan mijn management wil doorgeven om te kunnen bepalen of het project nog op de goede weg is.

Het referentiekader om die vraag te beantwoorden zit vervat in het constraintoverzicht dat werd besproken in het hoofdstuk ‘Hoe gaan we van initiatie tot oplevering? #faseren’. We geven dat schema nogmaals weer:

Figuur 1 Zes constraints als leidraad voor controlemeetpunten.

De projectmanager bepaalt voor elk project individueel (want elk project is uniek!) voor elk van die zes invalshoeken de juiste meetpunten of controlepunten.

Projectcontrolepunten (of project-KPI’s/ key performance indicators) zijn meetpunten die opgevolgd worden doorheen het volledige project en moeten het toelaten een statusevaluatie te maken. Die controlepunten worden vastgelegd in het projectmanagementplan en wijzen op de performantie van de projectuitvoering.

De volgende tabel geeft enkele voorbeelden van meetpunten die kunnen worden opgevolgd en gerapporteerd.

Tabel 1 Overzicht van mogelijke controlepunten ter objectivering van de projectstatus.

Rapporteringsas Meetpunt Betekening en interpretatie

Scope Deliverablelijst Overzicht van alle beloofde deliverables, inclusief owner, hun status en verwachte opleveringsdatum.

Scope Change requests:

‒ aantal geïdentificeerd

‒ aantal aanvaard

‒ aantal goedgekeurd

‒ aantal afgekeurd

‒ scope creep assessment

Opvolgen van change requests is cruciaal voor de scopebewaking. Daarom dient dit item ook op de managementradar te worden geplaatst.

Risico Risk register summary

Risico Risk response assessment

Risico Risk/ issue ratio

Resources Resource beschikbaarheidsstatus

Aantal geïdentificeerde risico’s, inclusief hun kwalitative analyse (rating) en eventueel kwantitatieve analyse.

Evaluatie van toegepaste risk response-strategieën, gekoppelde acties en hun doeltreffendheid.

Aantal risico’s dat werd omgezet in een issue is een maatstaaf van de kwaliteit van het projectrisicobeheer.

Vergelijking tussen resourcenoden en beschikbare resources. Die maatstaf laat toe:

‒ te evalueren of we over- of understaffed zijn;

‒ te bekijken welke skills we missen.

Resources Team motivation/ team spirit status Indicatie van de moraal van het team, eventueel per subteam als de prioriteiten en werkdruk erg verschillen. Aangezien het team van cruciaal belang is voor de oplevering, mag een soortgelijk meetpunt niet vergeten worden.

Cost Algemeen overzicht van:

‒ Budget

‒ Approved change requests

‒ Actuals

‒ ETC

‒ EAC

‒ Variantie

Time Overzicht van gedane taken volgens de tijdlijn.

Time Overzicht van de uit te voeren taken volgens de tijdlijn.

Time Faseoverzicht

Algemeen Belangrijkste issues

Algemeen Belangrijkste genomen beslissingen

Algemeen Belangrijkste te nemen beslissingen

High-level financieel overzicht van het project.

Overzicht van verschillende fases van het project en hun voortgang (vaak gekoppeld met deliverablelijst).

Als we deze controlepunten willen opvolgen en beoordelen, is het belangrijk referentiewaarden aan te geven. Zo kan het interessant zijn om aan te geven vanaf wanneer we alarm moeten slaan met betrekking tot het aantal overdue acties of het aantal change requests dat wordt behandeld zonder goedkeuring.

2.3 Status opmeten en interpreteren

Bovenstaande meetpunten laten toe een goed beeld te krijgen van de voortgang. Maar zowel op het vlak van time en cost kan het nog beter of accurater. Het projectmanagementplan en de baselines die we uitgewerkt hebben, zullen ons referentiepunt worden. Op die manier doen we aan kwantitatieve statusmeting.

2.3.1 Cost en schedule performance

Een eerste stap in het objectief meten van de status heeft betrekking op de manier waarop we omgaan met de tijd en het budget die ons ter beschikking worden gesteld. Dat omschrijven we als cost en schedule performance. De evaluatie zelf is eenvoudig als we tijdens de planningsactiviteiten het stappenplan hebben gevolgd.

De cost performance berekent de ratio tussen de actuele uitgaven en het voorziene budget op het moment van de statusopname. De actuele kost kan worden berekend op basis van de inkomende facturen van leveranciers, timesheets van het projectteam enz. De voorziene kost kunnen we terugvinden in ons projectplan.

De schedule performance analyseert de voortgang vanuit een tijdsperspectief. De GANTT-chart of de milestone chart van het project leert ons wat we op het moment van statusopname al hadden moeten realiseren. Dat wegen we af ten opzichte van de effectieve realisaties.

De tijdsanalyse moet echter verder gaan dan enkel een analyse van het heden. Het is ook noodzakelijk dat we kijken hoeveel werk er nog op de plank ligt en of het überhaupt nog realistisch is dat werk tegen de voorziene deadlines klaar te krijgen. Dat noemen we een schedule feasibility analyse. De belangrijkste inputs om die analyse mogelijk te maken zijn enerzijds de estimated time to completion (ETC) voor de betrokken werkpakketten en anderzijds de resourcekalender, die weergeeft wat de beschikbaarheid van de betrokken resources is.

Een eenvoudig voorbeeld toont het nut van die analyse aan.

Vaak krijgt de projectmanager te horen dat een taak voor de helft klaar is ( percentage of completion: 50 %). Met wat geluk kan de medewerker zelfs aangeven dat er nog voor bijvoorbeeld vijftien dagen werk te presteren is (ETC). Als de deadline voor die activiteiten binnen twintig kalenderdagen valt, lijkt er misschien geen probleem qua haalbaarheid. Het is op dat moment echter van groot belang dat we evalueren of alle betrokken resources nog voldoende beschikbaarheid hebben om gedurende de twintig dagen die ons nog resten, de resterende vijftien dagen werk te presteren. In sommige periodes (vakantie, zomer, eindejaar) zijn resources niet beschikbaar of zijn ze toegewezen aan meerdere projecten, waardoor we niet mogen uitgaan van een voltijdse aanwezigheid. Het achterblijven van de beschikbaarheidsanalyse leidt in zeker 60 % van alle projecten tot lastige situaties.

2.4 Statusrapporteren in een projectcontext

Statusrapporteren is een tijdsintensieve activiteit voor elke projectmanager. Zowel de voorbereiding, de presentatie, de bespreking en de debriefing (aan het team na een stuurgroep bijvoorbeeld) vragen volle aandacht en bijgevolg veel energie. Als projectmanager moet je er ook in slagen de boodschap goed af te stemmen op het publiek. Op een teammeeting waar je de gang van zaken toelicht, vertel je als projectmanager andere zaken dan tijdens een stuurgroep.

Probeer voor stuurgroepen ook altijd af te stappen van de pure eenrichtingsboodschap. Statusrapporteren is nuttig, maar je brengt het management van de klant niet samen om een eenrichtingsverhaal te vertellen. Benader stuurgroepen dan ook zoveel mogelijk als beslissingsmeetings. Een stuurgroep kan aangegrepen worden om bepaalde issues de nodige managementaandacht te geven. Op die manier wordt de stuurgroep ook een escalatiekanaal. Een stuurgroep wordt ingericht om te ‘sturen’. Grijp dan ook de kans om het management achter het project te scharen en keuzes ten voordele van het project te maken. Om die reden is het ook aan te raden input zoals presentaties enz. minimaal 24 uur op voorhand te verdelen. Dat laat de mensen toe zich voor te bereiden en zich te informeren.

We worden dikwijls geconfronteerd met lange, uitgebreide statuspresentaties. Daar is op zich niets mis mee, maar we dringen er wel op aan om minimaal voor het volledige project en idealiter voor de belangrijkste werkstromen een samenvattende dashboard slide te voorzien die de belangrijkste boodschappen meegeeft. Hieronder worden enkele voorbeelden getoond van zo’n samenvattend projectdashboard uit de praktijk.

Het is verder ook belangrijk dat duidelijk wordt gecommuniceerd wat de aandachtspunten zullen zijn voor de komende reportingperiode. Omdat het project een looptijd heeft die meerdere maanden of jaren overspant, heeft het geen zin om voor het volledige project alle details op elke statusmeeting onder de aandacht te brengen. Het volgende voorbeeld toont goed aan hoe we vanuit het globaal milestoneplan focussen op wat er de komende rapporteringsperiode onze aandacht verdient.

Ook voor projectrapportering zien we een digitaliseringsgolf. Er zijn vandaag veel goede tools beschikbaar die een (groep van) projectmanagers toelaten om de status van hun project vlot te onderhouden in een onlineplatform. Afhankelijk van de scope van het project zijn bepaalde tools beter geschikt. Voor maatwerk, ontwikkeling of agile-gerichte initiatieven wordt veelal gesteund op JIRA of Azure DevOps als platform. De sterkte van dat platform zit in het gemak om een verfijnde scope van features & functions (zie eerdere hoofdstukken) gemakkelijk te visualiseren in KANBAN (in het hoofdstuk ‘Welke agile manieren van werken zijn er? #agile’ komt KANBAN uitgebreid aan bod) borden en die te verslepen in functie van hun voortgang of status.

Het voorbeeld hierboven toont enkele principes: de projecttaken of deliverables zijn de individuele ‘kaartjes’ (de rechthoekjes);

– de fase waarin een taak zich bevindt, wordt gevisualiseerd in de kolommen (Backlog, Analyze, Develop, enz.);

– de status van een deliverable zie je in de kleur van de omlijning.

Deze vorm van weergeven is erg handig tijdens projectmeetings. Deliverables worden kort besproken en onmiddellijk kan de status of de fase van de deliverable geactualiseerd worden door te verslepen of aan te vullen. Het vermijdt ook het opmaken van slides en verhoogt het informatiegehalte in de projectmeeting of stuurgroep. Men kan namelijk eenvoudig en snel navigeren, of doorklikken om meer info op te zoeken. Deze tools ondersteunen de agile manier van werken heel sterk en bewijzen zo onmiddellijk hun nut voor digitale initiatieven.

3 De efficiënte projectmeeting: hoe draag je bij tot een vlotte projectopvolging?

Zoals eerder is aangegeven, is het organiseren van statusmeetings een van de meest gangbare hulpmiddelen om de temperatuur van het project te nemen. Veelal is het voor de projectmanager zeer duidelijk wat hij wil leren tijdens deze meeting, maar blijft deze teleurgesteld achter omdat het objectief van de meeting niet werd gehaald. Er werd dan bijvoorbeeld te weinig geleerd over de status of de voortgang van het project. Waren de deelnemers onvoldoende voorbereid? Was het niet duidelijk wat ze dienden aan te leveren zodat tijdens de meeting kan worden aangevoeld wat de status van het project is? Waren de afspraken uit de vorige meeting niet nagekomen (omdat er bijvoorbeeld niemand het verslag had gelezen)? De juiste verwachtingen vooraf uitklaren met het projectteam is een mogelijke oplossing. In dit hoofdstuk willen we vanuit onze ervaring voor zowel de projectmanager als voor de teamleden een houvast aanreiken die kan helpen de projectstatusmeeting efficiënt en effectief te laten verlopen.

Zowel de projectmanager als de projectmedewerker brengen op een statusmeeting enkele nuttige puzzelstukjes samen. Voor ons dient een statusmeeting drie grote onderwerpen af te dekken: opleveringsstatus, RIAD-log en change requests.

3.1 Opleveringsstatus

Vanuit de buik van het project moet de projectmedewerker in staat zijn om op een correcte manier de voortgang te rapporteren. Het is handig daarvoor twee eenvoudige vragen in het achterhoofd te houden:

Realisaties/achievements : wat zijn de drie belangrijkste dingen waarop de projectmedewerker de afgelopen periode heeft gewerkt?

Vooruitblik/outlook: wat zijn de drie belangrijkste dingen waarop de projectmedewerker de komende periode zal werken?

Als de rapporteringsintervals niet al te groot zijn, dan kunnen die drie belangrijkste dingen al veel leren over de voortgang.

Verder verwijzen we nogmaals naar het eerder gemaakte statement dat het de medewerkers zijn die het best geplaatst zijn om in te schatten hoeveel werk er geleverd is (percentage of completion) en hoeveel werk er nog uit te voeren blijft (ETC). De projectmanager dient zijn team dan ook voldoende te instrueren om met die info naar de meeting te komen.

3.2 RIAD-log

Het RIAD-log is een centraal managementinstrument dat elke projectmanager zou moeten implementeren. RIAD is een acroniem voor risico’s; – issues; acties; – decisions (beslissingen).

Die vier elementen zijn cruciaal in de sturing van het project.

Het risicoregister is de centrale cockpit van het risicobeheer. Daarin vinden we overeenkomstig het riskmanagementplan voor elke risico de oorzaak, het effect, de kans, de impact, de rating, de te volgen strategie (response), de geïmplementeerde acties en een verwijzing naar een individueel riskformulier als dat binnen het project wordt voorzien.

Issues en acties zijn zeer gelijklopend, maar we verkiezen ze gescheiden te rapporteren en op te volgen in het project. Issues zijn nauw verbonden met risico’s, maar daarnaast dient elk pijnpunt dat het project bemoeilijkt, genoteerd en uitgeklaard te worden. Issues zijn feiten waarmee we geconfronteerd worden en die verder onderzoek vragen. Ze creëren een horde of moeilijkheid in het project. Uit het hoofdstuk ‘Hoe kan ik risico’s en hun impact inschatten? #anticiperen’ weten we dat risico’s zich onderscheiden van issues door de onzekerheid. Risico’s zijn geen vastliggende feiten.

Acties zijn specifieke activiteiten die op detailniveau uitgeschreven moeten worden. Trap niet in de val om alle acties die voortkomen uit de WBS of uit de planning in het algemeen op te nemen. Het gaat hier altijd om ad hoc geïdentificeerde acties, die doorheen het project bijzondere aandacht vereisen.

Beslissingen worden eveneens vanuit best practice-perspectief opgenomen en opgevolgd. Eerst wordt een beslissingsnood genoteerd. Later wordt die aangevuld zodra een beslissing werd genomen. De reden dat beslissingen, net zoals veronderstellingen, moeten worden bijgehouden, is vanwege de traceability. Een beslissing uit het verleden kan in de toekomst terug in vraag worden gesteld. Als de beslissing echter een fundament was voor de weg die het project heeft gevolgd, is het belangrijk dat de projectmanager kan teruggrijpen naar de historiek om zijn projectobjectieven veilig te stellen.

Hoofdstuk 16 Hoe past mijn initiatief binnen de digitale context van mijn bedrijf? #ITGovernance

Onze ervaring leert dat het een hoge toegevoegde waarde heeft om alle projectmedewerkers samen verantwoordelijk te maken voor het aanvullen, actualiseren en onderhouden van die centrale log file. Het is de rol van de projectmanager en collega’s van het PMO om de mensen aan te sporen om die log file op regelmatige basis na te kijken, maar het kan niet de bedoeling zijn dat ze optreden als administratieve support voor het project. Daarom dringen we aan op een gedeelde verantwoordelijkheid. Aangezien de opvolging van het RIAD-log opgenomen is als kwaliteitsmaatstaf van het project, worden medewerkers zeker voldoende herinnerd aan hun noodzakelijke bijdrage. Medewerkers weten dat de log file idealiter voor de statusvergaderingen wordt geactualiseerd.

Als de teamleden hun rol spelen en inderdaad de RIAD-logfile vooraf correct updaten, kan de projectstatusmeeting zich richten op de uitzonderingen, zoals de zaken die over tijd zijn, complexer dan gedacht, niet worden opgepikt of een foutieve prioriteit hebben gekregen. Die aanpak leunt aan bij de principes van ‘management by exception’ en laten toe kostbare projecttijd te sparen voor zowel de projectmanager als de teamleden.

3.3 Change requests

Het samenbrengen van het team, volledig of per werkstroom, is de ideale gelegenheid om beslissingen top-down te communiceren, maar is ook het ideale forum om vanuit de business nieuwe vragen van de klant op tafel te leggen. De statusmeeting is de kans voor het team om het projectmanagementteam te informeren over nieuwe aanvragen.

4 Plannen wijzigen: omgaan met change requests

We zijn dit hoofdstuk begonnen met één centrale vraag, namelijk hoe we op een continue manier de status van ons project kunnen kennen. Voorgaande paragrafen hebben ons op weg geholpen om grip te krijgen en te houden op de status van het project. Maar ‘meten is weten’ en dat leidt er dikwijls toe dat we onze plannen moeten bijschaven. Voorbeelden zijn dat we niet werken aan het juiste ritme, dat er een noodzaak is om het team uit te breiden of slechte teamleden te laten gaan, dat de klant bijkomende vragen heeft gesteld die van naderbij bekeken moeten worden alvorens er aan gewerkt mag worden, dat de oplossing die we voor ogen hadden, niet voldoet en we onze oplossing moeten bijsturen enz.

Om change requests op een professionele wijze te benaderen en projecten goed te bewaken, implementeren veel bedrijven een CCB, een Change Control Board. Dat forum wordt in het leven geroepen om change requests te evalueren en al dan niet goed te keuren. Vooraleer een change request op een CCB komt, heeft die aanvraag echter al een heel proces doorlopen. Figuur 8 toont een klassieke change request-procesflow.

Door het volledige proces heen worden verschillende cruciale stappen doorlopen die moeten verzekeren dat er geen foutieve beslissing wordt genomen en dat de aanvraag enkel in het projectmanagementplan wordt geïntegreerd wanneer het echt noodzakelijk is. Zo maakt een change request-procedure veelal een onderscheid tussen een aanvaarde change request en een goedgekeurde change request. Een aanvaarde change request is een change request waarbij de lanceringsprocedure correct wordt gevolgd, de juiste template werd gebruikt en alle noodzakelijke info werd aangeleverd. Een goedgekeurde change request heeft het volledige proces doorlopen en de CCB acht het nodig en mogelijk die te integreren in het project.

Initieer change door klant/stakeholder

Change request template gebruikt?

Nee (template vereist)

Change board

Communicatie impact change / vraag tot goedkeuring

Klant akkoord?

Integreer change request in projectmanagementplan

Start change request procedure

Change log (geactualiseerd)

Impactanalyse Kritieke change?

Projectmanagementteam akkoord? Verzoek tot sluiten?

Klant akkoord met sluiting

Documenteer reden / aanpassing Impactanalyse en communiceer met de klant

Aanvrager review / Goedkeuring

Communiceer finale impactanalyse

Projectmanagementplan (geactualiseerd)

Escalatie naar projectmanagementafstemmeeting (of hoger comité)

Close change

De projectmanager moet bewaken dat de inhoud van het project niet wordt gewijzigd zonder goedkeuring. In realiteit wordt er één scenario toegestaan waarbij de projectmanager niet hoeft te wachten op een CCB-beslissing om de change in gang te zetten. Enkel en alleen in geval van een urgente of emergency change, kan de projectmanager zijn akkoord geven. Die emergency moet op zich echter wel goed bekeken worden, maar het spreekt voor zich dat een projectmanager zijn project niet in gevaar kan brengen door een spoedverandering niet toe te staan op het eindproduct (als het bijvoorbeeld al in productie gebracht werd tijdens een vorige release). Wanneer de applicatie opgeleverd is en er worden dan kritieke issues vastgesteld die de business drastisch beïnvloeden, is het aanvaardbaar dat de projectmanager zijn akkoord geeft om een wijziging door te voeren. Er kan op dat moment niet gewacht worden op een formele goedkeuring. De businessimpact is in de evaluatie cruciaal. De change request zal parallel wel een goedkeuringscyclus doorlopen. Dat idee sluit namelijk naadloos aan bij de goede praktijken van IT-servicemanagement.

5 Digitale Initiatieven en de ideeëncyclus binnen het bedrijf

In het hoofdstuk ‘Welke rollen en factoren leiden tot een succesvolle oplevering? #organiseren’ verwezen we al naar de plaats van initiatieven binnen de organisatie. De structuur en cultuur van de organisatie kan een startpunt zijn van projecten via goede verbeterideeën bijvoorbeeld. Daarnaast werd ook eerder verwezen naar de link tussen strategie en een portfolio van initiatieven om die strategische doelstellingen te realiseren.

Elk bedrijf heeft vandaag het lef om zichzelf geheel of gedeeltelijk in vraag te stellen. Elke dag wordt er gezocht naar manieren die de werking kunnen verbeteren, die aanleiding kunnen geven tot groei of tot het (gemakkelijker) bereiken van de doelstellingen. Vandaag hebben heel veel bedrijven dan ook op een bepaalde manier een proces rond continue verbetering (‘continuous improvement’ ) geïmplementeerd. We zien dat dat proces vaak aan de start ligt van een digitaal initiatief.

Rond continuous improvement willen we volgende punten belichten:

– Constant zoeken naar verbetering is een filosofie die al lang bestaat in de wereld van kwaliteitsbeheer.

Hoewel in veel initiatieven IT of een digitale oplossing kan helpen om de verbetering te realiseren, zullen niet alle ideeën leiden tot digitale initiatieven. Een projectje kan ook zijn doel bereiken zonder een technologieonderdeel. Het herbekijken van een aankoopproces of het opmaken van een nieuwe template zijn daar voorbeelden van.

– De hele organisatie aanmoedigen om mee na te denken over een betere werking is erg goed. Het is daarbij belangrijk dat de instroom van ideeën gemakkelijk is én dat er nadien een goede opvolging is.

Het opvolgen van nieuwe ideeën vraagt tijd. Voorzie die tijd bij de juiste teams en zorg dat de juiste businessteams mee worden ingeschakeld om een eerste analyse te doen. Zo kun je beter beoordelen of het idee echt iets zal opleveren.

– De beoordeling van ideeën – liefst na een eerste analyse – gebeurt het best door een generiek team, dus niet enkel door de directie en zeker niet enkel door de manager van de betrokken afdeling. Door een generiek team – dus samengesteld uit medewerkers van alle niveaus en alle afdelingen –te laten oordelen, wordt veelal het evenwicht bewaakt binnen de portfolio van initiatieven.

De weerhouden ideeën – groot of klein – zijn elk individuele initiatieven. Al die initiatieven samen noemen we de (project)portfolio. Er bestaan verschillende methodieken om die lijst van initiatieven te scoren, prioriteit te geven en daadwerkelijk te starten. Hoe dat effectief gebeurt, kan elk bedrijf voor zichzelf vastleggen. Die manier van werken wordt veelal (lean) portfoliomanagement genoemd. Het woord ‘lean’ verwijst naar het regelmatig en laagdrempelig beoordelen en opstarten van initiatieven. Die filosofie staat in contrast met de klassieke manier waarbij projecten per (kalender)jaar worden benoemd en gestart. Door op jaarbasis te plannen en op jaarbasis bijvoorbeeld bepaalde budgetten te voorzien, ondermijn je de dynamiek van het bedrijf. Je wilt namelijk niet altijd een jaar wachten om aan een nieuw idee aandacht te schenken of eindeloos te discussiëren om een initiatief alsnog binnen de portfolio te activeren.

Met bovenstaande aandachtspunten willen we enerzijds het gemak maar anderzijds de nood aan opvolging onderstrepen. Het kan nuttig zijn om een duidelijke werkstroom te schetsen wanneer men de organisatie wil mobiliseren om ideeën voor te stellen. Duidelijkheid rond de afwikkeling en verdere stappen zal helpen om draagvlak te creëren binnen de onderneming. Het voorbeeld in figuur 9 is afgeleid van een verbetercyclus zoals die werd voorzien binnen een familiale onderneming in de vastgoedsector. We doopten dit het 4i-model, vernoemd naar de vier grote stappen die we doorlopen met een verbetervoorstel: Image, Investigate, Implement en Integrate.

Het is erg interessant om de zoektocht naar verbetermogelijkheden te ondersteunen. De ideetjes ontstaan namelijk niet altijd op goed geluk of dat zou te lang duren. Daarom voorzien veel bedrijven tegenwoordig procesbeheerteams die effectief als missie hebben om in nauw contact te treden met de business en samen met hen sessies te organiseren om een (deel van een) proces onder de loep te nemen. We spreken dan over een verbeterworkshop. Die aanpak leunt sterk aan bij het idee van de PDCA-cyclus (plan / do / check / act) zoals we die kennen binnen het kwaliteitsbeheer of bij de principes rond design thinking, waar we in groep – vaak met de klant – gedrag of gebruik analyseren en trachten pijnpunten weg te werken.

6 Digitale Initiatieven en IT-beheer binnen het bedrijf

Als een initiatief een digitale of IT-component heeft, is het cruciaal dat door het volledige intiatitief heen nauw wordt samengewerkt met de IT-afdeling. Veelal zal de IT-afdeling bepaalde afspraken volgen m.b.t. de technologieën die kunnen worden ondersteund, de partners met wie op een betrouwbare manier kan worden samengewerkt, de principes rond (cyber)security en toegangsrechten, enz. Hoewel die afspraken bestaan, betekent dat niet dat elke afwijkende keuze niet zal worden toegelaten. Het is wel een goede praktijk dat binnen de technologieafdeling wordt nagedacht over deze architectuurprincipes.

Dit boek is geen handboek rond (IT)-architectuur of IT-beheer. Maar we vinden het wel van belang om inzicht te geven in de gebruikelijke afhankelijkheden en interacties met enerzijds business, maar ook met de verschillende rollen binnen de IT-afdeling. De volgende figuur kan daarin een leidraad zijn.

In de praktijk zien we graag dat binnen de functionele afdelingen meer eigenaarschap wordt genomen en zeker wordt nagedacht over verbetermogelijkheden. Daarom dat we ‘ detect & demand ’ (het identificeren en aanvragen van verbetermogelijkheden) expliciet vermelden aan de businesskant. In het deel ‘Projecten initiëren’ kwam dat al duidelijk naar boven. Tegenwoordig zijn de technologieafdelingen vooral gefocust op het ontwerpen en bouwen van de oplossingen. Dat komt ook duidelijk aan bod in het deel ‘Projecten leiden’ van dit boek bijvoorbeeld. Op de scheiding tussen die twee speelt de solution architect of businessanalist een centrale rol. Die expert maakt de vertaalslag, in nauwe samenwerking met de rollen rondom, van de businessvraag (‘demand’) naar de oplossing (‘solution’). Daarbij onderstrepen we nogmaals de link naar de architectuur. Dat is de bovenste groep.

Merk op dat er verschillende architecten bestaan op de verschillende domeinen. De interactie tussen het (digitale) initiatief en de architecten verloopt veelal via een architectuurforum of architectuurboard. Op dat forum presenteert het projectteam zijn ideeën of uitgewerkt voorstel. Tijdens het overleg worden de opties bekeken en wordt een richting gekozen. Om dat overleg te vergemakkelijken, kan vanuit het architectuurforum een template of checklist worden aangeleverd. Voor (grote) initiatieven is het raadzaam tijdig de architecten te consulteren, zodat moeilijke keuzes goed begeleid kunnen worden en geen rework nodig is.

De overgang naar operations en de ‘go-live’ van het project werd al besproken in het hoofdstuk ‘Hoe leveren we onze oplossing op? #turnover’. We herhalen wel de aanbeveling om tijdig en proactief vanuit het project contact te nemen met de IT-afdeling om de support- of operationele fase samen voor te bereiden. Die voorbereiding kan gemakkelijk twee maanden in beslag nemen en het is cruciaal dat het IT-team (servicedesk enz.) klaar is om na de opstart de juiste ondersteuning te kunnen leveren en dat de juiste partners eventueel via goede contracten zijn bevestigd. We zien het als de verantwoordelijkheid van de projectmanager om ook dat aspect juist te laten landen en zo zijn project correct af te ronden.