Antipatronen ontmantelen

Antipatronen maken organisaties stram en belemmeren innovatie. Maar ze doorbreken kan een taai en lastig proces zijn. Hoe pak je dat aan?

Stel, een beheerteam blust continu brandjes en besteedt nauwelijks tijd aan proactief beheer. Een poging om het gedrag te veranderen heeft geen blijvend effect. Geen wonder, want dat is symptoombestrijding.

Stap 1 is herkennen dat er een antipatroon aanwezig is en dat dit geen probleem
van het team is, maar een organisatieprobleem dat veel breder speelt. Het is dus geen kwestie van mensen die iets verkeerd doen, maar een samenspel van krachten dat bepaald gedrag uitlokt en in stand houdt.

Stap 2 is daarom het uitvoeren van een krachtenanalyse. In kaart brengen hoe het antipatroon zichzelf in stand houdt, plaatst het gedrag van de betrokkenen in de juiste context. Brandjes blussen kost tijd en energie en gaat ten koste van aandacht voor preventie. Daarom ontstaan er steeds nieuwe branden. Bovendien werkt blussen verslavend: onder hoogspanning problemen oplossen geeft gewoon een kick. De inspanning en het effect van dergelijk werk zijn ook uiterst zichtbaar, wat schouderklopjes uitlokt van collega’s, maar ook van het management, zeker als er een ramp is afgewend. Samen kan dat leiden tot een cultuur waarin blussen als veel waardevoller wordt ervaren dan preventie.

Stap 3 is het krachtenveld aanpassen. Preventie moet stoer worden en brandjes blussen een uitzondering. Het kost tijd om zo’n verandering te bestendigen en het leidt onherroepelijk tot ontwenningsverschijnselen. Volhouden is het devies.

brandjes_antipatroon

Zeven waarschuwingssignalen voor innovatieve, risicovolle projecten

In ons artikel ‘Eerst proberen, dan doen‘ betogen collega’s Gert Florijn, Matthijs Maat en ik dat innovatieve, risicovolle projecten fundamenteel anders aangestuurd moeten worden dan  ‘normale’ projecten. Dit zijn zeven signalen die erop kunnen wijzen dat je met zo’n probeerproject te maken hebt.

1 Nieuwe wet- en regelgeving

IT-projecten starten vaak noodgedwongen voordat een op nieuwe wet- en regelgeving gebaseerde uitvoeringspraktijk is ontstaan. Het plaatsonafhankelijk bijhouden bij de basisregistratie personen, het toekennen en uitbetalen van PGB’s: uitzoeken en ervaren wat wel en niet werkt kost een nauwelijks te voorspellen hoeveelheid tijd, mede door de traagheid van regelgevings- en afstemmingsprocessen.

2 Nieuwe samenwerkingsverbanden

Zowel bij de aansturing als bij de uitvoering van IT-projecten zijn vaak meerdere partijen betrokken. Op vlakken zoals eisen en wensen, methodes en technologie is het ook zonder de verschillende belangen van verschillende organisaties al moeilijk genoeg om goed af te stemmen. Samenwerking tussen nieuwe partijen, of tussen partijen in nieuwe rollen, zorgt voor veel onzekerheid en dus risico’s.

3 Nieuwe methodes, tools en technieken

Ontwikkelingen gaan snel. Van iteratief ontwikkelen via XP en Scrum naar DevOps was een kwestie van jaren. Nieuwe ontwikkelhulpmiddelen en raamwerken volgen elkaar – zeker in de opensourcehoek – nog sneller op. Veel tijd gaat op aan het goed op elkaar laten aansluiten van methodes, tools en technieken. Bij elk nieuw element begint dat spel opnieuw.

4 Nieuwe technologie

Legacy is voor organisaties geen probleem, maar een oplossing. Bewezen technologie, voorspelbaar toepassen, is dat niet precies wat je wilt in een project? Nieuwe technologie lijkt een kans om iets beter, sneller of goedkoper te doen, maar is in de praktijk ook een risico.

5 Politieke zichtbaarheid

Hoe saaier het project, hoe groter de kans op een onverstoorde uitvoering in de luwte. Zodra een project speelbal wordt van de politiek – en daarvoor is de suggestie van een ‘mislukt project’ al voldoende – leidt de waan van de dag tot extra complexiteit.

6 Grote ambitie

Zeker in overheidsland doemt af en toe het idee van een nieuw integraal generiek hyperflexibel systeem op dat alle bestaande oplossingen kan vervangen. Dat leidt gemakkelijk tot tunnelvisie en vaak tot serieus falen.

7 Onduidelijk doel

Bij verrassend veel projecten is het achterliggende doel onduidelijk. Welk probleem is er eigenlijk? Hoe manifesteert zich dat voor de verschillende belanghebbenden? Zonder antwoord op dit soort vragen is het lastig te bepalen wanneer een oplossing goed genoeg – en een project klaar – is. Al deze zaken raken aan mensen, een factor met grote impact op de snelheid en kwaliteit van IT-projecten. Scrum is allang niet nieuw meer, maar begrijpt de beoogde product owner zijn rol wel? Is de functioneel analist bekend met de wetgeving? Hebben de ontwikkelaars ervaring met de raamwerken en tools? Het is moeilijk het belang van goede en ervaren mensen en ingewerkte teams te overschatten.

Eerst proberen, dan doen

Dit artikel verscheen in AGConnect. (PDF-versie.)

Vergroot de kans op succesvolle projecten

IT-projecten hebben een slechte reputatie. Ze duren te lang, kosten te veel en leveren te weinig op. Welbeschouwd is het een wonder dat er nog zoveel IT-projecten slagen. Wat de manier waarop grote IT-projecten worden aangestuurd, moet fundamenteel anders.

door Gert Florijn, Matthijs Maat en Eelco Rommes

Veel projecten worden gestuurd op een vooraf bepaalde begroting in tijd en geld: dít moet het resultaat zijn, het mag zoveel kosten en dán moet het af zijn. Dat kan werken, maar alleen als er een realistische planning en schatting is gemaakt en er onderweg niet te veel verandert. En dat is zelden het geval.
Te vaak is een projectbegroting gebaseerd op magisch denken: als we hard genoeg hopen, wordt het vanzelf waar. Neem de minister die onder druk in de kamer een datum noemt waarop ‘het probleem is opgelost’. Of een projectgroep die een bedrag in het ‘project initiation document’ zet waarmee de stuurgroep kan leven. Of de leverancier die een scherpe offerte afgeeft om concurrenten de loef af te steken. Met een goed beeld van het eindresultaat en van wat er nodig is om dat te bereiken, heeft zo’n begroting weinig te maken.

DOE-PROJECTEN

Niet dat schatten en plannen voor ieder IT-project onmogelijk is. Van een leverancier die in het derde ziekenhuis een ERP-implementatie uitvoert, mag je verwachten dat hij een beeld heeft van hoe lang zoiets duurt en wat het gaat kosten. Er is duidelijk met welk soort systemen er gekoppeld moet worden en wat de impact is voor medewerkers – en de leverancier brengt mensen mee die ervaring hebben opgedaan in vergelijkbare projecten.
Dat betekent niet dat zo’n project eenvoudig is. Er gebeuren altijd onverwachte dingen. Maar in de regel volstaan degelijk projectmanagement en aanverwante maatregelen daarvoor. Dit zijn ‘doe-projecten’: projecten met weinig onzekere factoren, die je met vertrouwen kunt aanpakken.
Veel IT-projecten kennen echter onzekere factoren die het schatten bemoeilijken. Een grote ambitie, een nieuwe leverancier, hippe technologie of veranderende werkprocessen zijn maar enkele voorbeelden. In zo’n situatie schieten de foutmarges in de schattingen omhoog. Stug vasthouden aan een vooraf bepaalde begroting leidt dan vanzelf tot mislukking. De controlemechanismes verder opschroeven werkt averechts: strenger toezicht, meer controle, vaker rapporteren, het stuurt het project alleen maar sneller zijn ondergang tegemoet.

PROBEERPROJECTEN

Voor zulke projecten is een aanpak nodig waarin je niet schematisch maar verkennend te werk gaat. Dat betekent: kleine stappen zetten. Alternatieven uitproberen om te kijken welke kansrijk zijn. Het doel bijstellen op basis van de opgedane ervaringen. Niet krampachtig doorgaan, maar (liefst vroeg) durven stoppen en de investering zien als vergoeding voor een leerervaring. En vooral: niet op dag één een einddatum en bedrag afgeven en je daarop blindstaren.
Dit gaat verder dan agile werken. De verkennende aanpak van ‘probeerprojecten’ betekent dat de opdrachtgever en andere belanghebbenden onzekerheid accepteren en daarmee om kunnen gaan. Het is cruciaal voor het succes van een project om te weten of je met een doe- of een probeerproject te maken hebt. Doe-projecten kun je gewoon doen – hoewel je onderweg scherp moet blijven op nieuwe onzekere factoren waardoor je afdwaalt naar onbekend terrein. Probeerprojecten moet je niet doen, maar proberen.
Dit moet ook terugkomen in de projectaanpak: goede (en continue) risico-inschattingen, inzetten van mitigerende maatregelen en regelmatige reflectie op fundamentele vragen: is de aanpak nog goed? Moeten we andere stappen nemen? Moeten we wellicht stoppen? Dat gaat niet zozeer om lef – stoppen moet een normale en realistische uitkomst kunnen zijn.
Het is ook cruciaal om te herkennen of de cultuur klaar is voor een probeeraanpak. Zo niet, vlucht dan niet in schijnzekerheid, maar neem onzekerheden weg tot er een doe-project overblijft dat wel planbaar is. Bijvoorbeeld door niet de nieuwste technologie te kiezen, maar genoegen te nemen met technologie waarmee de organisatie vertrouwd is. Door opnieuw met een bekende leverancier samen te werken. Of door het project op te breken in meerdere kleine projecten en die na elkaar uit te voeren. Elk kleiner doe-project kan een deelresultaat opleveren en onzekerheden verkleinen of wegnemen.
Weersta in elk geval de verleiding om een complex project op te breken en de kleinere projecten parallel uit te voeren in een programma. Dan neem je de onzekerheden niet weg, maar verplaats je ze naar het programmaniveau.

TE SNEL TE GROOT

Voor veel van de IT-projecten die als mislukt in het nieuws komen, is de vraag gerechtvaardigd of ze niet ten onrechte als doe-project zijn aangepakt. Vanaf dag één gingen ze in volle omvang voor jaren aan de slag, terwijl er zoveel onzekere aspecten speelden dat proberen beter op zijn plaats was geweest. In plaats daarvan is doormarcheren de norm, tot de begrote tijd en het geld op zijn en het hele project als falend IT-project wordt afgeblazen. Bij een probeeraanpak was er niets ‘mislukt’, maar hadden we tegen beperkte inspanning en kosten kunnen leren wat in ieder geval niet werkt. Om vervolgens constructief verder te zoeken naar oplossingen die wél succesvol zijn. Maar vaak wordt achteraf vooral naar zondebokken gezocht: de minister belooft beterschap, de projectgroep heft zichzelf op, de leverancier gaat op zoek naar zijn volgende klus.
Erkennen dat er onzekerheden zijn, is moeilijker dan het lijkt. In de politiek wordt professionele nuance nogal eens verward met een gebrek aan daadkracht. In de pers scoren pittige oneliners beter dan mitsen en maren. Kritisch tegengeluid laten horen is slechter voor je cv dan een gefaald miljoenenproject. In offertetrajecten leggen realistische bandbreedtes het af tegen een lage, vaste prijs. Zo blijven we de mislukte IT-projecten krijgen die we verdienen.