{"id":415,"date":"2013-10-22T08:40:50","date_gmt":"2013-10-22T07:40:50","guid":{"rendered":"http:\/\/www.bureauleeghwater.nl\/?p=415"},"modified":"2013-10-22T08:44:50","modified_gmt":"2013-10-22T07:44:50","slug":"project-risicobeheer-uit-de-praktijk-1","status":"publish","type":"post","link":"https:\/\/www.bureauleeghwater.nl\/?p=415","title":{"rendered":"Project Risicobeheer uit de Praktijk #1"},"content":{"rendered":"

Gezamenlijk een e-book project risicobeheer<\/a> schrijven, maakt dat we allerhande ervaringen\u00a0 uitwisselen. Daarom, onder het motto \u201cal doende leert men\u201d en \u201cer is geen falen, alleen maar feedback\u201d, hier een gevalletje waterschade.<\/i><\/p>\n

De situatie
\n<\/b>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<\/i> 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!<\/p>\n

Opmaat voor problemen
\n<\/b>Anders werken dan \u2018normaal\u2019 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.<\/p>\n

Het probleem
\n<\/b>Het projectteam heeft de software architectuur gestabiliseerd. \u00a0Meer 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\u00a0 terug in oude gedragingen en anderen geven de hoop op. Gaat het toch weer mislukken?<\/p>\n

Het verweer
\n<\/b>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<\/i> maar een desktop-client <\/i>en daartoe zijn andere communicatieprotocollen nodig. Verder is de gekozen oplossing extern getoetst door de leverancier van de middleware<\/i>. Er valt geen spelt tussen te krijgen en het projectteam krijgt groen licht om door te gaan.<\/p>\n

Gevolgschade
\n<\/b>Je zou kunnen denken: \u201cEind goed, al goed\u201d, 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.<\/p>\n

Leerpunten
\n<\/b>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?<\/p>\n

Achteraf is alles makkelijk maar we hadden ook:<\/p>\n

    \n
  1. De slechte relatie met de architectuurafdeling kunnen erkennen als projectrisico<\/li>\n
  2. Als vermijdende maatregel de software architect consequent de architectuurafdeling formeel en informeel te laten betrekken of informeren over de besluitvorming en de voortgang<\/li>\n
  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<\/li>\n<\/ol>\n

    Met een kleine investering waren we in gesprek gebleven, onze energie nuttiger\u00a0 kunnen gebruiken, een hoop euro\u2019s bespaard en had niemand gezichtsverlies hoeven lijden.<\/p>\n

    P.S.
    \nMocht je meer willen weten over het project risicobeheer e-book, klik ->>    hier<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    Gezamenlijk een e-book project risicobeheer schrijven, maakt dat we allerhande ervaringen\u00a0 uitwisselen. Daarom, onder het motto \u201cal doende leert men\u201d en \u201cer is geen falen, alleen maar feedback\u201d, 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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[21,20],"class_list":["post-415","post","type-post","status-publish","format-standard","hentry","category-blog","tag-architectuur","tag-risico"],"_links":{"self":[{"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=\/wp\/v2\/posts\/415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=415"}],"version-history":[{"count":10,"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=\/wp\/v2\/posts\/415\/revisions"}],"predecessor-version":[{"id":430,"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=\/wp\/v2\/posts\/415\/revisions\/430"}],"wp:attachment":[{"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bureauleeghwater.nl\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}