Categorie archief: Blog

Projectrisico of voorwaarde

Er zijn van die projectrisico’s die politiek gezien onwenselijk zijn. Vaak stellen ze ongewenst iets aan de kaak of is er sprake van conflicterende belangen.

In de praktijk worden dan de volgende ‘pragmatische’ oplossingen toegepast

  1. Struisvogelen
  2. Herkaderen

1. Struisvogelen
Bij de struisvogel tactiek gaan we deze risico’s gewoon negeren. We doen alsof we niet weten dat ze er zijn en we zien wel wat we doen als de problemen zich aandienen.

2. Herkaderen (reframing)
Bij herkaderen benoemen we deze risico wel, maar verpakken we ze anders.  We maken het minder erg door er een ander label aan te geven. Goede labels zijn dan voorwaarde of randvoorwaarde.

Het risico van beide tactieken is dat je als projectleider wordt opgezadeld met een probleem. Bij struisvogelen had je het namelijk moeten weten en bij herkaderen wist je het en heb je er niets aan gedaan. Het voordeel van herkaderen ten opzichte van struisvolgelen is dat je het project nog kan teruggeven, al wordt dit zelden gewaardeerd.

Het alternatief
Eigenlijk is er geen alternatief. Wat je kunt doen is

  • Blijf zo lang mogelijk gewoon alle risico’s benoemen, desnoods in etappes
  • Blijf zo lang mogelijk weg bij struisvogelen en herkaderen
  • Tracht in plaats van het risico te herkaderen naar een voorwaarde eerst het risico zelf anders te verwoorden
  • Rapporteer expliciet over de ‘voorwaarden’ in de voortgangsrapportage. Behandel ze alsof het risico’s zijn en maak trends of signalen die aangeven dat het de verkeerde kant op gaat inzichtelijk.

 

10 redenen om niet aan projectrisicobeheer te doen.

Ieder mens doet de hele dag aan risicobeheer en de meeste mensen zijn er dan ook erg goed in. Denk bijvoorbeeld aan woon-werkverkeer.  Een wonder dat je soms veilig thuis bent gekomen. Of denk aan een verzekering. Bij navraag is het op projecten echter meestal  niet nodig. Hieronder 10 redenen om niet aan projectrisicobeheer te doen.

  1. We hebben er geen tijd voor. Het is al druk genoeg
  2. We denken hier in oplossingen en niet in problemen
  3. We zitten niet te wachten op nog meer bureaucratie
  4. Problemen opwerpen is slecht voor mijn carrière
  5. Risico’s wegnemen kost tijd en budget en daar hebben we de ruimte niet voor
  6. We werken ‘Agile’ en dan is het niet nodig
  7. Weer iets dat het management van ons verlangt. Het waait wel weer over
  8. We lossen het wel op door te wachten totdat een ander project in de problemen komt
  9. We nemen risico’s wel op als randvoorwaarden in het plan van aanpak
  10. Ik durf die risico’s wel te nemen

Laat hieronder (drog)redenen achter die jij hebt gehoord om niet aan projectrisicobeheer te doen.

De prijs van zoeken naar zekerheid bij projecten

Opdrachtgevers verlangen bij projecten vaak zekerheid over de opleverdatum en het budget. En op zich is dat ook niet vreemd. Wat echter vaak over het hoofd wordt gezien, is dat zoeken naar zekerheid ook een prijs heeft in de vorm van veiligheidsmarges.

Voor het uitvoeren van een activiteit geldt in de regel de volgende waarschijnlijkheidsverdeling.

2013511_CCPM_1De y-as geeft de waarschijnlijkheid weer  van een tijdschatting voor het uitvoeren van de activiteit. De x-as geeft de benodigde tijd weer voor het uitvoeren van de activiteit.  De 50% stippellijn laat het punt zien waarop  er  50% kans is dat de activiteit eerder of precies op tijd klaar is. De 80% stippellijn laat het punt zien waarop er 80% kans is dat de activiteit eerder of op tijd klaar is. De veiligheidsmarge is het tijdsverschil tussen die twee punten.

De waarschijnlijkheidsverdeling laat verder zien dat om het verschil tussen 50% en 80% te overbruggen  er ca. 3x zoveel tijd nodig. De prijs van 30% mee zekerheid is dus 200% extra doorlooptijd.

Op zich is er niets mis met veiligheidsmarges. De meeste mensen zullen zichzelf terecht een ‘goede’ kans willen geven om een activiteit tijdig te kunnen uitvoeren en dan is een beetje speling best handig. Er ontstaat pas een probleem wanneer veiligheidsmarges impliciet ofwel niet inzichtelijk zijn. Impliciet veiligheidsmarges hebben namelijk de neiging  onbewust en onbedoeld te worden gebruikt voor ‘regulier’ werk met als gevolg dat er effectief geen veiligheidsmarge meer is.

Nu bestaat een project uit een set aan activiteiten. Stel je voor wat er gebeurt met de doorlooptijd en het benodigde budget als voor al deze activiteiten een impliciete tijdbuffer van 200% wordt opgenomen. Niet alleen duurt een project dan onnodig lang, het wordt ook nog eens heel duur. En vaak hoeft er maar iets te gebeuren en het project zit ondanks een ruime (impliciete) veiligheidsmarge in zwaar weer.

De les is dus om veiligheidsmarges of buffers altijd expliciet te maken, bijvoorbeeld zoals wordt voorgesteld door Critical Chain Project Management.

Kort door de bocht wordt er In Critical Chain Project Management een initiële planning gemaakt op basis van 50% waarschijnlijkheid. Vervolgens wordt er een tijd- of projectbuffer vastgesteld op 1/3 van het totaal of anders gezegd 50% van de benodigde doorlooptijd.

2013511_CCPM_2Het idee is vervolgens dat 50% van de taken eerder of precies op tijd worden uitgevoerd en dat de resterende 50% van de activiteiten meer tijd in beslag zal nemen. De projectbuffer zorgt dan voor afdoende veiligheidsmarge om mogelijke uitloop op te vangen.

Omdat we niet vooraf weten welke taken meer tijd in beslag nemen, wordt er actief gemeten aan het consumeren van de projectbuffer. Deze manier van werken zorgt er onder andere voor dat veiligheidsmarges expliciet worden gemaakt met postieve gevolgen voor de mate van beheersing. Verder  kan de doorlooptijd van projecten aanzienlijk worden bekort.

Risk Management, Lean en Karoshi

Een tekort aan beschikbaarheid van personeel is een bekend projectrisico.  Vaak komt het aan op knokken om capaciteit en soms is de aanleiding minder ‘plezierig’. Neem bijvoorbeeld langdurige ziekte- of sterfgeval.

Wat minder bekend is, is  dat dit in de hand kan worden gewerkt door de manier van werken. Nu ben ik zelf een voorstander van moderne methoden en technieken zoals Scrum, Agile en Lean maar ik weet ook dat er gevaren aan kleven. En van Lean is dit zelfs onderzocht.

Binnen de Lean en Agile stromingen is het gebruik van Japanse termen nogal in zwang. Om er een paar te noemen: Kanban, Kaizen, Muda, Muri en Mura.  Ik wil er daar graag een aan toevoegen: Karoshi .  Karoshi betekent kortweg dood door overwerk

Karoshi is geen grap en het kan iedereen overkomen.  Zo was er in mijn naaste omgeving een dominee die 24 uur ten dienst stond van zijn gemeente met meer dan 1000 zielen. Een en al overwerk, want was hij niet z’n preek aan het schrijven, dan was er wel iemand overleden, geboren, moest er een huwelijk worden geregeld of had er iemand geestelijke bijstand nodig. Uiteindelijk is de beste man inderdaad overleden aan acuut hartfalen.

Al in 1997 is een verband geconstateerd tussen Karoshi en Lean,  in het bijzonder het doorslaan in het elimineren van ‘waste’ (verspilling).  Met doorslaan bedoel ik dat alles wordt gezien als ‘waste’ inclusief: onderhoud, opleidingen, risicobuffers, toiletbezoek,  lopen van en naar de printer, wachten in de lift, vakantie, feestdagen en ga zo maar door. Alles wat niet essentieel is voor productie moet weg!

Toyota, het succesverhaal voor Lean, schijnt al een limiet te hebben gezet op het maximaal toegestane aantal overuren. Maar Japan is natuurlijk geen Nederland. Uit Brits onderzoek blijkt dat echter dat structureel 3 tot 4 uur overwerk per dag leidt tot 60% meer risico op hart en vaatziekten.

Wat kunnen we hiervan leren? Op zijn minst dat structureel overwerk aantoonbaar vragen is om moeilijkheden is. Ik durf nog wel verder te gaan, want ik vermoed dat onderweg naar Karoshi de stress zover is opgelopen dat er een hoop verkeerde beslissingen zijn genomen. Met andere woorden, een gebrek aan slack  is een groot projectrisico.

Gebruik projectevaluaties voor het identificeren van projectrisico’s

Wanneer je het lastig vindt om projectrisico’s te identificeren of wanneer je vindt dat projectevaluaties alleen voor het archief worden uitgevoerd, lees dan verder want deze is speciaal voor jou.

Projectevaluaties zijn een fantastische bron voor risico’s voor je volgende project want de problemen waar projecten mee te kampen hebben, hebben de neiging zich te herhalen.

Doe het volgende:

  1. Verzamel 5 tot 10 projectevaluatie van recente projecten
  2. Controleer ieder project op afwijkingen ten opzichte van het initiele plan of verwachtingen
  3. Bepaal van iedere afwijking de grootste oorzaak
  4. Leg deze oorzaak vast als risico in een nieuwe risico log.
  5. Ga door totdat je een top 20 hebt
  6. Gebruik deze risico log vervolgens als sjabloon voor je nieuwe project.

P.S.
Wanneer je je collega’s blij wilt maken, doe dan een projectevaluatie en actualiseer het risico log sjabloon voor een volgend project.

Project Risicobeheer uit de Praktijk #1

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

Bevorder Samenwerking met Project Risk Management

Een  projectmanager is in de regel verantwoordelijk voor project risicobeheer. In de praktijk komt het echter vaak voor dat projectmanagers er in de uitvoering alleen voor komen te staan. De projectmanager is immers verantwoordelijk en dus kijkt iedereen naar hem of haar. Ik gok dat je dit wel eens hebt gezien of wellicht zelf hebt meegemaakt.

Project Risk Management kan echter ook een goede manier zijn om samenwerking te bevorderen. Op die manier voorkom je meteen dat je er alleen voor komt te staan.

Een voorbehoud: Ik ga er vanuit dat project risicobeheer afdoende is ingericht op jouw project. Mocht je dit niet zeker weten, doe dan de Project Risk Management Test om te weten waar je staat.

Project Risk Management bestaat op hoofdlijnen uit 4 stappen die periodiek worden doorlopen tijdens een project:

  1. Inventariseer
  2. Analyseer
  3. Plan
  4. Monitor

Inventariseer
Het doel van deze stap is om risico’s te identificeren. In mijn ervaring is het prima als een projectmanager zelf een eerste slag slaat naar de risico’s, bijvoorbeeld door de opdrachtgever te vragen welke risico’s in beeld waren bij het definiëren van het project. Het risico is dat het hierbij blijft of dat alleen de meest vanzelfsprekende risico’s worden gespot (bijvoorbeeld geen mensen of geen middelen).

Naar mijn mening krijg je een beter resultaat wanneer je al tijdens deze stap samenwerking organiseert, bijvoorbeeld door middel van een risico-inventarisatie workshop samen met projectteamleden en/of stakeholders.

  • Formeer de deelnemers aan de workshop in teams.
  • Vraag de teams om vanuit een bepaald standpunt risico’s te inventariseren.
  • Vraag de teams om manieren om het project te laten mislukken.
  • Wissel de resultaten onderling uit

Analyseer
Het doel van deze stap is om meer informatie te vergaren over risico’s zodat je een plan kunt maken maken om ze onder controle te brengen. Deze stap kun je alleen doen, maar het is meestal veel effectiever om het samen te doen met het projectteam, eventueel aangevuld met belanghebbenden.

  • Laat in teamverband what-if scenario’s uitwerken
  • Doe risk poker als techniek om per risico de kans en impact relatief in te schatten.
  • Laat in teamverband per risico indicatoren bepalen waarmee de status van een risico kan worden gemonitord
  • Laat in teamverband kandidaat maatregelen identificeren ter voorkoming of beperking van risico’s
  • Geef teams dezelfde opdracht, wissel de resultaten onderling uit  en laat ze vervolgens de beste oplossingen kiezen

Plan
Het doel van deze stap is de resultaten van de risicoanalyse om te zetten in een plan waarmee de risico’s planmatig onder controle kunnen worden gebracht. Het is prima als een projectmanager zelfstandig een contour maakt voor een risicobeheerplan of –aanpak. Voor de  uitvoering van het plan is het echter veel beter om verantwoordelijkheden (en bevoegdheden) te delegeren.

  • Laat in teamverband ieder risico voorzien van concrete maatregelen ter voorkoming van negatieve impact (mitigation)
  • Laat in teamverband ieder risico voorzien van concrete maatregelen ter beperking van negatieve impact (contingency)
  • Zorg ervoor dat projectteamleden of belanghebbenden de verantwoordelijkheid krijgen voor het uitvoeren van maatregelen ter voorkoming en ter beperking.
  • Per risico ontstaat nu een koppel; een verantwoordelijke die een risico moet beperken en een verantwoordelijke die het risico moet voorkomen. Maak dit koppel verantwoordelijk voor het actief monitoren van de status van het risico
  • Zorg voor afdoende mandaat in geval een risico niet kan worden voorkomen en moet worden beperkt.

Monitor
Het doel van deze stap is om vast te stellen of het project afdoende snel in een veilige toestand wordt gebracht. Dit kan schriftelijk worden  afgedaan maar in mijn ervaring is het beter om ook hier de samenwerking op te zoeken.

  • Laat de koppels elkaar periodiek rapporteren over de status van ‘hun’ risico’s
  • Bespreek de risico’s periodiek met het projectteam en belanghebbenden, bijvoorbeeld als belangrijk onderdeel van een voortgangsoverleg
  • Beloon openlijk iedereen die tijdens het project nieuwe risico’s identificeert

P.S.
Het is zeker niet de bedoeling dat een projectmanager zijn verantwoordelijkheid voor risicobeheer gaat afschuiven. Delegeren kan, afschuiven niet.

Project Succes Beheer

De verloop van een doorsnee project gaat als volgt. We beginnen goed. Er is een prima idee, er wordt een plan gemaakt en daarna wordt enthousiast begonnen het plan tot uitvoering tot brengen.  Vervolgens gaat er van alles mis en komen de meeste projecten in de problemen met de bekende beelden en klachten: te laat, te duur, kwalitatief onvoldoende en halfbakken oplossingen.

Project risk management of project risicobeheer is een bekend middel dat juist helpt te voorkomen dat er iets mis gaat of om negatieve invloeden in te dammen. Veel projecten doen dan ook risicobeheer maar desondanks gaat er nog steeds veel verkeerd.  Voor een deel zit dit in de mindset of focus.

Neem alleen al de naam. Project risicobeheer. Onder beheren wordt onder meer verstaan: administreren, besturen, exploiteren, rantsoeneren, uitbaten en verzorgen. Naar mijn mening allemaal werkwoorden die helemaal niet goed passen bij het doel. De naam maakt dat de  focus eerder ligt op het in stand houden van risico’s in plaats van het onder controle brengen en wegnemen van risico’s. En in de praktijk zie je dat ook gebeuren. Er wordt een risicolijst opgesteld, met een beetje mazzel worden er maatregelen bepaald en daarmee is de kous in de meeste gevallen wel af.

Bij autorijden geldt dat de kijkrichting bepaald waar je naar toe gaat. En dat geldt voor veel meer zaken; je krijgt meer van waar je je op focust.  Ik stel dan ook voor om project risicobeheer af te schaffen en om een nieuwe discipline te introduceren.  Project Succes Beheer.

Het doel van project succes beheer is om steeds die maatregelen te nemen die ervoor zorgen dat een project succesvol begint en succesvol eindigt, juist als er onderweg iets mis mocht gaan.

Risicoloos project? Laat dan maar zitten

Jaren geleden kreeg ik “Slack” in mijn handen geduwd, het boek van Tom DeMarco uit 2001. Het is naar mijn mening nog steeds een zeer relevant boek vanuit het oogpunt van innovatie en project management.

Het volgende citaat kan ik alleen maar onderschrijven, zeker in deze tijd.

“If you identify any project as risk-free, or even relatively risk-free, cancel it. You’re going to need the resources and calendar time to do something transformational.”[Tom DeMarco, Slack, p210]

Mocht je wel risicovolle projecten doen, dan is risk management een must. Mocht je willen weten of je risicobeheer goed hebt ingericht, doe dan de risk management test.

There is No Architecture, Only Business

Ik had de eer de afsluitende keynote te mogen doen op het Agile Software Architecture Symposium op 11 september 2013.  In tegenstelling tot mijn naamgenoot uit Amsterdam die huizen en gebouwen ontwerpt, ben ik geen architect en durf ik mezelf ook geen software architect te noemen. De vraag was dus wat kun je 100+ (software) architecten vertellen over hun vak. Na wikken en wegen werd het een zoektocht op basis van mijn eigen ervaringen met (software)architecten. De uitdagende titel van de presentatie is:
There is No Architecture Only Business.

Tijdens de presentatie ga ik in op de volgende onderwerpen en/of stellingen:

  • Het imago en veel voorkomend onwenselijk gedrag van software en enterprise architecten
  • Wat architectuur eigenlijk is en welk doel het dient
  • De onzinnige tegenstelling tussen Emerging Architecture vs. Big Design Upfront
  • Potentiële negatieve gevolgen van ontwikkelen op basis van Agile/Scrum voor Total Cost of Ownership (TCO)en Cost of Quality (COQ)
  • Waarom (software) architectuur in isolatie geen bestaansrecht heeft
  • Waarom over feedback als verbeter- of optimalisatiemiddel alleen niet afdoende is
  • Dat architectuurinitiatieven altijd een business doel dienen

Wanneer je nieuwsgierig bent naar de slides, volg dan de link
==> There is No Architecture Only Business.