Gezamenlijk een e-book project risicobeheer schrijven, maakt dat we allerhande ervaringen  uitwisselen. Daarom, onder het motto “al doende leert men” en “er is geen falen, alleen maar feedback”, hier een gevalletje waterschade.

De situatie
Een projectteam is druk in de weer om een vastgelopen softwareproject weer op de rit te krijgen. Er is inmiddels een nieuwe gedragen visie, een helder plan van aanpak en een kansrijke software architectuur. Er is succesvol een aantal proof of concepts ontwikkeld. Het projectteam pakt de zaken wel iets anders aan dan men is gewend binnen de lijnorganisatie. Zo wordt op een iteratieve multidisciplinaire manier gewerkt. Ook zijn vele taken, die normaal handmatig worden uitgevoerd geautomatiseerd, waaronder automatisch bouwen, deployen en testen. Binnen een paar weken gloort er onder de projectteamleden na maanden van stilstand zowaar iets van hoop. En natuurlijk is er ook een risico log opgesteld. So far so good!

Opmaat voor problemen
Anders werken dan ‘normaal’ kan weerstand oproepen bij mensen die niet direct onderdeel zijn van het projectteam. Zeker als het projectteam zaken voor elkaar krijgt die al jaren niet voor mogelijk worden gehouden. Denk aan een eigen projectruimte, nieuwe ontwikkeltools, nieuwe ontwikkelmachines en controle op test- en acceptatieomgevingen. Daar bovenop werkt het projectteam met een ontwikkelaanpak die verdacht veel lijkt op standaard die door een groot deel van de organisatie als niet werkbaar wordt beschouwd. Tot slot doet het projectmanagement team goed werk, want het projectteam ondervindt vooralsnog geen last van deze weerstand. Met de resultaten in de hand weet het projectmanagement team dat ze het gelijk aan haar kant heeft, maar er is een verschil tussen gelijk hebben een gelijk krijgen.

Het probleem
Het projectteam heeft de software architectuur gestabiliseerd.  Meer dan 50% van de functionaliteit is inmiddels gereed en het projectteam is fluitend op weg naar de eindstreep. En dan wordt de projectmanager op het matje geroepen bij de directie. Het hele pand weet wat er aan de hand is, behalve de projectmanager en het projectteam. Wat is er aan de hand. De architectuurafdeling heeft geconstateerd dat het projectteam totaal verkeerd bezig is. Er wordt niet onder architectuur gewerkt en het systeem mag op deze manier nooit operationeel worden gemaakt. Alle software waarbij sprake is van communicatie met andere systemen, moet helemaal opnieuw worden geschreven. Het projectmanagement team heeft geen idee waarop deze constatering is gebaseerd en heeft alle vertrouwen in een goede afloop. Omdat het probleem op straat ligt, lukt het het projectmanagement team echter niet om de rust te bewaren binnen het projectteam. Sommige projectteamleden vallen  terug in oude gedragingen en anderen geven de hoop op. Gaat het toch weer mislukken?

Het verweer
Het lukt om alle constateringen inhoudelijk van tafel te vegen. De architectuurafdeling heeft namelijk iets over het hoofd gezien. Het projectteam ontwikkeld namelijk geen web-client maar een desktop-client en daartoe zijn andere communicatieprotocollen nodig. Verder is de gekozen oplossing extern getoetst door de leverancier van de middleware. Er valt geen spelt tussen te krijgen en het projectteam krijgt groen licht om door te gaan.

Gevolgschade
Je zou kunnen denken: “Eind goed, al goed”, maar niets is minder waar. Het duurt drie weken voordat het projectteam weer op volle snelheid ligt en de relatie met de directie en de architectuurafdeling is geschaad.

Leerpunten
Terugkijkend was de relatie met de architectuurafdeling vanaf de start van het project niet goed. Ze hadden geen tijd en ze vonden de oorspronkelijke software architectuur prima. Het projectteam had ze inhoudelijk gezien ook niet nodig. Maar een project dat zich gedraagt als een speedboot tussen de olietankers, trekt natuurlijk wel de aandacht. Vanuit het oogpunt van project risicobeheer kun je zeggen dat de slechte relatie met de architectuurafdeling is genegeerd. Had het anders gekund?

Achteraf is alles makkelijk maar we hadden ook:

1. De slechte relatie met de architectuurafdeling kunnen erkennen als projectrisico
2. Als vermijdende maatregel de software architect consequent de architectuurafdeling formeel en informeel te laten betrekken of informeren over de besluitvorming en de voortgang
3. Als beperkende maatregel de senior supplier (stuurgroep) een exceptie te laten voorbereiden, om indien nodig, met de eerste versie van het systeem te mogen afwijken van de referentie software architectuur

Met een kleine investering waren we in gesprek gebleven, onze energie nuttiger  kunnen gebruiken, een hoop euro’s bespaard en had niemand gezichtsverlies hoeven lijden.

P.S.
Mocht je meer willen weten over het project risicobeheer e-book, klik ->>hier