Waarom ligt er bij it-projecten nog steeds zo’n grote nadruk op de techniek? Dat was toch commodity geworden horen we steeds uit de it-sector zelf? Wanneer gaat die focus er dan eens af en gaan projectorganisaties inzien dat succes van een project op de eerste plaats afhangt van de veranderbereidheid en het verandervermogen bij eindgebruikers?
De businesscase mag dan bejubeld worden in de boardroom, maar daarmee zijn gebruikers nog niet overtuigd. En zij bepalen of de verandering echt plaatsvindt, niet het management. Vergeet al die nullen en enen, management of change gaat over percepties en context. En elk it-project waarin dat niet nadrukkelijk wordt meegenomen is op voorhand al gedoemd te mislukken.
Troost
Het was laatste weer raak in de media: alarmerende berichten dat ict-projecten bij de overheid te vaak mislukken. Een troost voor getergde ambtenaren: in het bedrijfsleven is het niet veel beter. Maar de Wet Openbaarheid van Bestuur is daar niet van toepassing, zodat mislukkingen minder snel zichtbaar worden. Kernvraag is natuurlijk wanneer een it-project geslaagd is. Leveranciers zullen zeggen: als het op tijd is afgerond conform de eisen in het contract met de klant. En veel van hun klanten zullen dat zelfs beamen.
Het moge waar zijn, maar de echte waarde van een project komt pas tot uiting als de doelstellingen uit de business case zijn gehaald. En onderzoek toont aan dat dat slechts in 5 procent tot 10 procent van de gevallen lukt. Waarom? Omdat programmamanagers en projectleiders sturen op harde criteria zoals processen, deadlines en kosten. Daar worden ze immers op afgerekend. Daardoor vergeten ze stelselmatig om de ‘zachte’ kant mee te nemen: de context en percepties van medewerkers, ofwel de beelden en overtuigingen in hun hoofd, de achtergrondconversatie. En die zijn cruciaal om naast het halen van de harde doelstellingen ook de organisatie zelf klaar te krijgen voor de verandering.
De kosten van een project gaan voor de baat uit. Die baten komen dan ook pas nadat het project netjes afgerond is. Daarom juist moet de organisatie zelf actief mee worden genomen. Zowel in de projectdoelstellingen als in de projectaanpak. Maar omdat dit zo lastig concreet te maken is (we hebben het inmiddels over percepties die lastig meetbaar zijn), wordt dit vaak niet gedaan. Toch moet daarop het accent liggen om verandering tot stand te kunnen brengen. Doelstellingen bij een project moeten worden geformuleerd op het niveau van kennis, houding en/of gedrag bij eindgebruikers. Want als perceptie en context bij mensen niet veranderen, dan zal hun gedrag ook niet wezenlijk veranderen.
Die perceptie en context hangen nauw samen met de begrippen moeten, willen en kunnen. Laten we deze begrippen even nadere beschouwen voordat we ze aan elkaar relateren.
Moeten
Bij ‘moeten’ draait het om de overweging bij de medewerker of de beoogde verandering wel echt noodzakelijk is. Dat beoordeelt hij vaak op basis van de overtuiging en het gedrag van zijn directe manager. Stel dat jouw it-organisatie heeft besloten om kosten te besparen en de kwaliteit te verhogen door processtandaardisatie in te voeren. Een rationeel besluit want het was de afgelopen jaren een spaghetti geworden van unieke processen, verschillende standaarden et cetera, et cetera. Maar de werknemers die dit te horen krijgen zullen zich afvragen: wat wordt dan dat standaardproces en levert dat op wat goed is? Is het wel echt nodig? Het wordt helemaal hachelijk als de directe manager ook z’n wenkbrauwen opheft en aangeeft dat er andere, belangrijkere prioriteiten zijn. Hoeveel energie zit dan achter deze verandering, vanuit de medewerker gezien? En tot welke veranderingsbereidheid leidt dat?
Willen
Willen draait om de vraag ‘what’s in it for me’? Wat is voor mij de toegevoegde waarde van deze oplossing? Door de gebruiker een vergezicht te bieden en in stapjes de gekozen kant op te bewegen ziet hij de wereld veranderen in zijn voordeel. Hij zal kleine tegenslagen makkelijker accepteren en zich blijven richten op het eindresultaat. Want dat maakt ook voor hem het werk een stukje leuker, mooier en beter. Als bovengenoemd voorbeeldproject leidt tot efficiënter werken maar er daardoor ook banen op de tocht komen te staan, kun je zoveel argumenten noemen als je wil, maar dan gaan de hakken in het zand. Bovendien lopen ratio en emotie niet altijd in pas. Rokers weten dat het slecht voor hen is, maar stoppen toch niet. Medewerkers snappen dat het nodig is te veranderen, maar het voelt gewoon niet goed. En dan heb je een uitdaging. ‘Snappen’ en ‘voelen’ moeten allebei goed scoren om een hogere veranderingsbereidheid te krijgen.
Kunnen
Binnen het begrip ‘kunnen’ stelt men zich de vraag of de handelingsmogelijkheden van de oplossing voldoende zijn om het werk te kunnen doen en of men zelf in staat is om daarin te kunnen functioneren. Directies gaan daar vaak te snel van uit. Terug naar het voorbeeld: Laten we aannemen dat iedereen snapt dat de verandering ‘moet’; overtuigd is dat het goed is voor hun professionele ontwikkeling en de manager ook duidelijk gecommitteerd is. Dan nog kan er een perceptie zijn dat het gekozen model niet genoeg handelingsmogelijkheden heeft voor het werk dat gedaan moet worden. Of de medewerker is van mening dat hij het eenvoudigweg niet kan, bijvoorbeeld omdat opeens verlangd wordt op een hoger conceptueel niveau te gaan werken (nieuwe competenties & raci’s – (responsible, accountable
Zetten we de drie begrippen in een schema zoals hieronder afgebeeld dan blijken er in de praktijk drie implementatiescenario’s te zijn die steeds weer opduiken:
- Het moeten scoort laag – De dovende kaars: In dit scenario zijn mensen bereid en in staat te veranderen maar ontbreekt een echt noodzaak of drijfveer. Een verandering van onderaf die de boardroom vaak niet haalt en daarom uitgaat als een kaars. Geen urgentie, geen focus.
- Het willen scoort laag – Trekken aan een dood paard: De noodzaak tot veranderen is aanwezig, de medewerkers zijn er ook toe in staat maar de hakken staan in het zand, bijvoorbeeld omdat ze er gewoon niet in geloven.
- Het kunnen scoort laag – Wensdenken: Er is een duidelijke noodzaak, de mensen willen graag maar zijn niet bij machte om de verandering zelf te realiseren.
- Moeten, willen & kunnen scoren goed –Succes: Als de juiste percepties op noodzaak, overtuiging en vaardigheden aanwezig zijn is de kans op succes het grootst. Dat wil zeggen: ervaring leert dat als op deze drie componenten 60 procent van de betrokkenen positief scoren de kans op succes het grootst is.
Geen rocket science
Elke organisatie en elke situatie is anders. Een standaardoplossing voor jouw uitdaging heb ik dus niet. Maar zeker is dat hij ergens langs deze assen ligt. Altijd. Voordat je begint aan een change project doe je er dus goed aan professionals in te schakelen binnen of buiten je organisatie, die je helpen te inventariseren hoe bij medewerkers op deze drie assen wordt gescoord. Daar zijn voldoende wetenschappelijk instrumenten voor. Ik werk er dagelijks mee en het is beslist geen rocket science. Ze geven helder inzicht in vervolgacties en dragen bij aan succes. Dat is bewezen. Organisaties, die bij change management actief sturen op verandering van perceptie en context hebben een slagingskans van 50 procent tot 75 procent. Heel wat meer dan de 5 procent tot 10 procent slagingskans bij organisaties die alleen focussen op processen, tooling, en structuren. Natuurlijk moet dat op orde zijn om te slagen. Maar staar je er niet blind op en neem jhe personeel mee in het veranderproces vanaf de allereerste dag. Als zij aan jouw kant staan, is succes alleen nog maar een kwestie van implementeren.
Robert Jan Simons, partner bij Umbrio
De teneur van het artikel bevalt mij, zo ook de bruikbare opdeling in 4 implementatiescenario’s.
Wat mij minder bevalt is dat ook hier weer een spraakverwarring optreedt rond begrippen en definities.
De Business Case ligt bij de Business, niet bij de projectmanager. Aan de BC hoort een Business Risk ten grondslag te liggen, eveneens een business-aangelegenheid.
Het realiseren van de benefits, organisatieverandering en doelstellingen is géén onderdeel van het IT-project maar van het business-project. De projectmanager heeft daar geen deel aan, de programmamanager per definitie wél. De programmamanager stuurt in principe niet op harde criteria
Aan de kant van de Opdrachtgever wordt te snel overgegaan tot het inschakelen van professionals. Het Business project wordt daarmee ‘weggelegd’. Het op afstand plaatsen vermindert de noodzaak dat de Opdrachtgever het zélf blijft begrijpen en verzwakt daarmee de sturing op de Business Case.
Ik geloof zeker dat het op juiste manier managen van veranderingen bijdraagt aan het succes van projecten. Waar ik benieuwd naar ben is waar de cijfers van 10% – 15% en 50% -75% vandaan komen. Oftewel: Waar is de bronvermelding?
Vanuit de veranderkundige bril ben ik het volledig eens met de moeten-willen-kunnen benadering. Een van de oorzaken waarom projecten m.i. fout gaan is dat I(C)T projecten als zodanig NIET KUNNEN en NIET MOGEN bestaan. Elk project dient een aanleiding met voldoende business importantie te hebben om als zodanig uitgevoerd te kunnen en mogen worden. Ook een project als b.v. vervanging van XP desktops is een business project: de continuïteit van werkprocessen van gebruikers is daar immers van afhankelijk en is als zodanig van belang voor elk bedrijf.
Evenmin is het verstandig projecten te laten ontwikkelen door project- en/of programmamanagers: deze beroepsgroep heeft een inclinatie richting het positief krijgen van de business case, zodat zij hun professie vervolgens kunnen uitoefenen. Als zij de business case opstellen moeten ze dan ook zwaar uitgedaagd worden om deze te onderbouwen, en dan bij voorkeur door iemand anders dan de belanghebbende opdrachtgever.
Beter is het om projecten te ontwikkelen vanuit een gedegen architectuur aanpak. Goede architecten denken integraal in de driehoek tijd-geld-kwaliteit en balanceren de belangen van alle stakeholders.
Een van de belangrijkste vragen die een architect al heel vroeg aan de orde dient te stellen is “Kunnen we dit” en “willen we dit” (In Togaf termen: “Assess readiness for business transformation”.
Als deze vragen positief beantwoord worden is er een gerede kans dat het project gaat slagen. Dat ben ik eens met de auteur. Maar de beantwoording van deze vragen dient te gebeuren VOORDAT een project uberhaupt start.
Frans Loth, Principal Architect.
Merkwaardig. Elke week weer zo’n artikel hoe eenvoudig project management wel niet zou zijn. 5 stappen die je wel moet doen, of 6 juist niet. Agile zijn, vergeet mandaat niet en budget. En is het allemaal wel SMART. Of werken de tools wel mee ? Intiutief werken ? nee juist wetenschappelijk verantwoord..
Deze keer :
Moeten, willen en kunnen de betrokkenen hun (project)werkzaamheden verrichten ? Dat zou de vraag zijn. Mate waarin dat zo is bepaalt het succes. Ik denk dan, dat weet toch iedere boerepielemuis ?
Een ding blijft. De conclusie zal iets zijn dat het bedrijf waar de auteur werkzaam is, tegen betaling een oplossing biedt.
Duidelijk en goed artikel over verandermanagement. Simpel en helder.
IT-projecten houden zich nauwelijks bezig met verandermanagement van medewerkers of organisaties.
Bedrijven hebben klanten. Klanten betalen de rekeningen. IT, van architect tot programmeur van tester tot beheerder moeten zich in dienst stellen van het klantbelang. Zolang IT organisaties zich daar niet bewust zijn gaat het mis. Het maakt niet of een programmamanager of een architect “projecten ontwikkeld”, zolang het klantbelang maar bij iedereen bekent is.
Elke verandering is niet altijd een verbetering, maar elke verbetering is wel een positieve verandering.
Zoals genoemd is een succesvol project een project waarin de businesscase behaald is met de beoogde samenwerking, communicatie, flexibiliteit en verwachtingen.
Het principe is eenvoudig, maar het managen van de diverse krachtenvelden in een project niet. Daarom is het managen van verwachtingen en het creëren van draagvlak ontzettend belangrijk voor het resultaat.
Vanuit de business geredeneerd: IT projecten bestaan niet. Er bestaan alleen verandertrajecten met een IT component. Want wie verandert er? Juist: de business.
Als binnen een organisatie IT van elk verandertraject een IT project (lees: feestje) maakt, is de kans op succes onmiddelijk een stuk kleiner.
Ik mis nog het adagio “eerst organiseren, dan automatiseren”, kom je ook al een stuk verder mee.
En ik mis het onderscheid tussen verandertrajecten en echte IT projecten, d.w.z. binnen de IT omgeving zelf. Doorgaans zijn dat wel succesvolle trajecten, want IT’ers weten vaak zelf maar al te goed wat ze willen.
Jammer dat de rol van opdrachtgever onderbelicht wordt in dit artikel. Een project is een onderdeel van een investeringstraject. Aan dit laatste ligt de businesscase ten grondslag. Dat is dus geen onderdeel van het project.
Waar het om gaat, en daar wordt in het artikel ook even op gewezen, is dat de doelstelling van de businesscase wordt gehaald. Maar je moet je realiseren dat de doelstelling van een project wat anders dan de doelstelling waar het resultaat van het project een bijdrage aan levert. De laatste doelstelling is gedefinieerd in de businesscase. De justificatie van elk project. Deze justificatie leg je niet in handen van een projectmanager. Een fout die helaas te vaak wordt gemaakt.
Communicatie professie is hierbij het antwoord. Vanuit de communicatierol kan de verbinding worden gelegd tussen de verandering en IT.
Het waarom en een vaardigheid in empathie brengt deze twee samen. Business is IT in dit dynamische technologie tijdperk. De programma of project manager is dus ook business en IT.
Goed artikel, helder en leesbaar. Project- en programmamanagers, zowel vanuit de klantzijde als van de opdrachtnemerzijde, zijn naar mijn idee ook té vaak gefocust op waar daadwerkelijk op afgerekend kan worden. Harde targets. Een van de belangrijkste schakels van ‘De Business’ – de gebruikers – wordt hierbij vaak vergeten. Hoewel dit niet een 100% verantwoordelijkheid is van de projectmanager, heeft hij/zij hier wel een sturende rol in, of kan deze in elk geval nemen. Want het kan dan wel interessanter zijn (lijken) om vooral alleen met het (hoger) management van de opdrachtgever te praten, de meest waardevolle hands-on informatie komt toch van de werkvloer.