Aanpak complexe projecten: “Just do it”

Werken met de standaardmethoden Prince2 en DSDM is geen garantie voor een succesvol softwareproject. In veel gevallen, concludeert Marcel Noordzij, gaat er veel tijd verloren met praten en het schrijven van rapporten. Als de omstandigheden complex en niet standaard zijn, zegt Noordzij, is het verstandig zonder standaardmethoden “direct te beginnen”.




Werken met de standaardmethoden Prince2 en DSDM is geen garantie voor een succesvol softwareproject. In veel gevallen, concludeert Marcel Noordzij, gaat er veel tijd verloren met praten en het schrijven van rapporten. Als de omstandigheden complex en niet standaard zijn, zegt Noordzij, is het verstandig zonder standaardmethoden ‘direct te beginnen’.



De juiste manier om projecten aan te vliegen binnen de ICT wereld is een eeuwige bron van discussie. De afgelopen jaren is het aantal projecten dat volgens een van de gangbare methodieken als Prince2 en DSDM is aangevlogen sterk gegroeid. Methodieken die pretenderen een succesvol project te leveren. Het is helaas niet alles goud dat er blinkt. Het is niet voor niets dat toch nog vele projecten jammerlijk falen of grote uitloop hebben qua tijd en/of kosten. Maar weinig projecten halen de gestelde deadlines en blijven binnen het budget. Voor de standaardprojecten waarbij geen tot minimale verrassingen zijn, tijd in overvloed is en de budgetten tot de hemel rijken biedt een van de methodieken met grote zekerheid de juiste aanpak. Indien hieraan niet voldaan is, dan zullen er andere wegen gevolgd moeten worden om tot het gewenste resultaat te geraken. Hoe dit in zijn werk gaat komt in dit artikel aan de orde.



De uitdaging van vervanging


De vervanging van kernsystemen is voor bedrijven een van de meest uitdagende ICT projecten die er zijn. De afhankelijkheid is groot en de in jaren opgebouwde functionaliteit en stabiliteit zijn cruciaal voor functioneren van de organisatie. De systemen zijn vaak maatwerk. Daarbij komt dat niet alle roep om vervanging gestuurd wordt vanuit de gebruiker of de organisatie maar in een aantal gevallen van technologische aard is. Een goed voorbeeld van het laatste is het out-of-support nemen van systemen door leveranciers die in inmiddels lang vervlogen tijden een groot aantal systemen verkocht hebben, die ondertussen niet meer ondersteund worden. Daar sta je dan als bedrijf. Een goed werkend systeem, zeer stabiel, zorgdragend voor het voortbestaan van de organisatie, maar door ontbrekende support of zelfs onderdelen een tikkende tijdbom. Maar dat is nog niet alles. De gebruikers zijn tevreden en willen helemaal geen nieuw systeem en leven met de vraag "Waarom niet wat uitdeuken, spuiten en oppoetsen?". Daarboven komt dan nog de organische groei van de te vervangen applicatie, waarin het volledige bedrijfsproces inclusief uitzonderingen is verwerkt. Helaas, de specificaties zijn we vergeten te maken of bij te houden. Eén groot drama, of zullen we het uitdaging noemen.



De methodische aanpak faalt


Het water staat tot aan de lippen en het besef bij het management wordt steeds groter dat het systeem vervangen moet worden. De standaardwerken worden uit de kast getrokken en het oog valt op een van de ‘veilige’ methodieken. De projectorganisatie wordt opgetuigd om te onderzoeken wat het probleem nu daadwerkelijk is en met een voorstel te komen hoe het project verder aan te vliegen. Als het mee zit wordt er binnen het project ook ruimte gemaakt voor de applicatie experts, zodat er naast alle ‘chiefs’ ook nog een ‘indiaan’ is. Discussie na discussie volgt en er wordt enorm veel tijd verstookt met praten en het schrijven van rapporten. De tijd tikt door en 99% van de gevallen is de conclusie dat een eerste stap in het project het boven water krijgen van de specificaties is. Iets wat met gezond boerenverstand ook bedacht had kunnen worden.
Nu begint het spel pas echt. Volgens de methodiek moeten eerst alle projecteisen boven water zijn voordat er echt iets gedaan moet worden. Zonder planning geen project en zonder specificaties geen planning. Tja, daar sta je dan. Een tikkende bom, een tijdklok die nog enkele minuten aangeeft en een methodiek die zegt dat alvorens de bom ontmanteld kan worden eerst duidelijk moet zijn wat er precies in zit. Oftewel gaan we in onze eerste poging het bestaande systeem te vervangen lekker methodisch te werk en proberen de specificaties boven water te krijgen. Na enkele weken cq. maanden blijkt dat dit toch lastiger is dan verwacht, sterker nog het lukt niet, want de oorspronkelijke bouwers zijn niet meer aanwezig of willen geen prioriteit geven aan het leveren van de specificaties. Na deze ‘vruchtbare’ periode van tijdverlies komt het project tot de conclusie dat de specificatie niet veel verder komt dan ‘de functionaliteit uit het systeem moet vervangen worden’. En voila, de vicieuze cirkel is geboren. We kunnen niet verder omdat de methodiek ons zegt dat er meer duidelijk moet zijn, maar we krijgen niet meer duidelijkheid binnen de termijn die beschikbaar is. Het project faalt zonder echt te zijn begonnen. Eenzelfde resultaat treedt op bij de innovatieve projecten, waar door de langdurige onderzoeken en het mislukken of uitstellen van veelbelovende innovatieve trajecten het aantal ideeën binnen de organisatie snel doodbloedt. "We kunnen wel ideeën hebben, maar ze worden toch nooit gerealiseerd…".



Hoe moet het dan wel…


Een korte analyse van de methodische aanpak toont dat het ontwijken van de vicieuze cirkel de oplossing biedt. Natuurlijk is niet alles verkeerd, maar in trajecten waar teveel variabelen en onbekendheden waar ook tijdsdruk en moeten slagen om de hoek komt kijken is een juiste mix vereist.
Elk project zou na een inventarisatie van maximaal een maand moeten beginnen met de vraag "Waarom zullen we niet gelijk beginnen?". En dan niet als ervaren projectmanager op jacht gaan naar allerlei bezwaren waarom niet, maar eerder naar redenen waarom het inderdaad een goed plan is om direct te beginnen. Welke mogelijkheden worden geschapen als direct begonnen wordt, welke moeilijkheden ontstaan en hoe kunnen deze weggewerkt worden.



Motivatie en teambuilding gaan als vanzelf


Door een gerichte selectie van de projectleden, die qua persoonlijkheid het best omschreven kunnen worden als individualistische teamspelers ontstaat een hechte groep van personen die elkaar waarderen om hun kennis en ervaring. Stel de doelen duidelijk en maak elk van de teamleden eigenaar, dus verantwoordelijk, voor een bovenmatig groot deel van het probleem. En automatisch ontstaat een groep met een gemeenschappelijk doel voor ogen en de wil om te slagen.
Een indirect effect van een versnelde start is dat richting de organisatie een boodschap van slagvaardigheid wordt uitgestraald. Wat de organisatie weer stimuleert actief mee te blijven denken en werken.



De deadline wordt met grotere zekerheid gehaald


Een niet onbelangrijk neveneffect van de wil om te slagen is de bereidheid om indien nodig een stapje extra te doen. Belangrijker is echter dat continu stappen in het project parallel worden uitgevoerd. De tester, informatieanalist en ontwikkelaar werken tegelijkertijd aan hetzelfde onderdeel, waardoor grote versnelling en efficiency voordeel gehaald wordt.



De gerealiseerde oplossing is technische beter en meer flexibel


Inherent aan de aanpak is dat wat vandaag bedacht wordt, morgen anders kan zijn door vernieuwde inzichten. Iedereen in het project is dan ook doelbewust bezig met het inbedden van voldoende flexibiliteit om wijzigingen eenvoudig te absorberen. Voeg daarbij de pragmatiek van ‘gewoon doen’ en de ervaring leert dat het opgeleverde eindproduct kwalitatief beter is. Een groot ‘acceptatievoordeel’ kan behaald worden door in een zeer vroeg stadium de gebruikers te betrekken en mee te laten lopen in het ‘analysetraject’. De oplossing kan zo zeer sterk op de gebruikerwensen aangesloten worden, waarbij gebruik gemaakt wordt van de reeds aanwezige flexibiliteit in het projectteam en de oplossing.



Vertrouwen geven heeft een positieve weerslag


Een lastig element in de aanpak is dat deze sterk bouwt op het geven van vertrouwen. Niet alles is bekend, waardoor het niet eenvoudig is om volledig vertrouwen te geven. Bedenk echter dat als iemand vertrouwen geschonken krijgt de automatische reactie die van commitment is. Het vertrouwen beschamen is iets wat niet snel gedaan wordt. Combineer het vertrouwen geven met het delegeren van verantwoordelijkheid en de projectleden zetten vele stappen extra.



Focus, focus, focus


Een groot aantal van de projectstappen binnen deze aanpak zijn ook aanwezig binnen de standaard methodieken. Door puur te focussen op het minimaliseren van de tijdverslinders en uit te gaan van de kracht van elk van de projectleden is er eenvoudig sneller, goedkoper en zekerder resultaat te behalen. De kern van het project moet bestaan uit personen met een juiste attitude en spirit. In feite zal het project gedragen worden door ‘solisten’ met een sterk vermogen in teamverband te werken, die helaas dun gezaaid zijn en veelal bij kleine specialistische bedrijven te vinden zijn. Naast een duidelijke doelstelling is de selectie van projectmedewerkers een van de cruciale factoren binnen het project.



De projectorganisatie is anders


Voor de organisatie die mee ‘durft’ te gaan in deze aanpak is zeker de eerste keer eng. Het is niet eenvoudig de gebaande paden te verlaten en voor een groot aantal bedrijven en de standaard projecttijgers kan het wel eens teveel gevraagd zijn. Er zijn een aantal betrokkenen in het project voor wie de wereld er anders uit gaat zien en die zich flink anders moeten gedragen dan zij in vorige projecten hebben gedaan.
De opdrachtgever zal blind moeten vertrouwen op de blauwe ogen van de projectmanagers binnen het team. Problemen zullen optreden, maar zullen gewoon door het project opgelost worden. De hang naar een methodische aanpak wordt veelal gevoed door de wens van zekerheid en duidelijkheid. Beide zijn in deze aanpak groter dan bij een methodische aanpak, waar de basis bestaat uit schijnzekerheid met alle kwalijke gevolgen die hieraan gekoppeld zijn. Daarnaast wordt het project gekenmerkt door de aanwezigheid van sterke persoonlijkheden die soms iets te duidelijk zijn, maar wel inzicht en duidelijkheid verschaffen.
De architect(en) zijn meer dan alleen architect. Zij zorgen voor de architectuur van de gehele applicatie en hebben inzicht in zowel de business als technische ins- en outs. Daarnaast hebben zij een grote zeggenschap in hoe het traject gaat verlopen en keuzes die onderweg gemaakt worden. In feite vormen zij de dragers van het project en is de projectmanager niet meer dan een faciliterende rol waarmee deze het erg lastig kan hebben.
De rol van projectmanager wordt teruggebracht naar de essentie. Het wordt weer een puur administratieve rol waar de kernwoorden vertrouwen, delegeren en vooral mensen manager zijn. De projectmanager is niet de inhoudelijke, nog de technische kenner en heeft als hoofdtaak zorgen dat de overige teamleden hun werk kunnen doen.
De rol van business specialist is gelijk aan die van de architecten, in feite is de business specialist onderdeel van het architectenteam. Gezamenlijk vormen zij de kern die beslissingsbevoegd is om zowel technische als business issues ‘on-the-spot’ op te lossen.
De testers, ontwikkelaars en analisten binnen het project zijn gedwongen nauw samen te werken en meer te bieden dan binnen een methodische aanpak. Veel sessies om specificaties te vergaren zullen uitgevoerd worden in teamverband waarbij elk van de disciplines de verantwoordelijke voor dat deel afvaardigt.
De belangrijke groep binnen het project zijn de gebruikers. Voor hen wordt de applicatie gebouwd en zij zijn zeer actief betrokken. Het moet de gebruikers duidelijk zijn dat zij serieus genomen worden, en dat er hierdoor ook verwachtingen zijn aangaande hun betrokkenheid.

Opbranden is een reëel gevaar


De belangrijkste keerzijde is dat het ‘vragen’ van commitment kan leiden tot zoveel inzet dat projectleden opbranden. De wil om te slagen en het vertouwen niet te beschamen kan in individuele gevallen te groot zijn. Het devies luidt hier goed op te letten tijdens de selectie van de projectleden en de vinger aan de pols te houden gedurende de loop van het project.



Geen methodiek, geen boekwerk


De aanpak voor deze ‘complexe’ projecten is in feite heel simpel, "Just Do It". Het bestaat bij de gratie van flexibiliteit en gewoon de dingen doen, die niet in academische regels te vangen zijn. De houding en persoonlijkheid van alle betrokkenen zorgen voor het succes. Elke richtlijn die exact aangeeft hoe bepaalde processtappen of de organisatie ingericht moeten worden, is per definitie een gevaar om de aanpak succesvol te laten zijn. Gewoon beginnen is wel iets gechargeerd. Natuurlijk wordt eerst (lang genoeg) nagedacht alvorens echt in het diepe te springen. ICT is ook ondernemen en beperkte risico’s horen erbij. Het devies luidt dan ook om voldoende tijd te spenderen en de duidelijk valkuilen in kaart te brengen zonder daarbij door te draven. Zowel niet naar het positieve (alles) als naar het negatieve (niet denken, maar doen) kant. Na een korte introductieperiode kan het project echt van start.