Tag Archives: Nederlandse bijdrage

Recensie: Portfoliomanagement implementeren. Hoe pakt u dat aan?

9789082030815-480x600René Hombergen schrijft op de laatste bladzijde van zijn boek Portfoliomanagement implementeren. Hoe pakt u dat aan? Een overzicht en een spel van alternatieven“Dit is zijn elfde boek, het getal van de gek, …”Of het van invloed is geweest weet ik niet maar ik vind het geen goed boek. Zowel inhoudelijk als redactioneel is er veel op aan te merken.

Laat ik beginnen met de redactionele kant. De auteur geeft zelf aan dat er zowel in 2012, 2014 als 2015 redactionele ronden hebben plaatsgevonden en daarna heeft het boek gerijpt tot medio 2017. Los van vele schrijf/drukfouten begrijp ik niet dat het 280 pagina’s tellende boek onderverdeeld is in 10 hoofdstukken waarbij het kleinste hoofdstuk 1 pagina en het grootste hoofdstuk 102 pagina’s omvat.

Aan het begin van een hoofdstuk een opsomming en toelichting van hoofdstukken die er gaan komen en aan het eind wederom een overzicht van komende hoofdstukken maar nu uitgebreider. Er wordt veelvuldig samengevat en nog eens samengevat wat er gaat komen en wat er zojuist besproken is. En dat werkt heel storend.

Ook de opbouw is op vele plekken ondoorzichtig of onsamenhangend. Een paar voorbeelden maar er zijn er veel meer. In hoofdstuk 4 Implementeren portfoliomanagement een paragraaf Randvoorwaarden en algemene tips. Daarbinnen een aantal randvoorwaarden en sub-paragrafen Overige randvoorwaarden en tips en Algemene voorwaarden vooraf. Vervolgens Algemene voorwaarden bij het implementatie-project en Algemene tips en dan is de volgende paragraaf Specifieke overwegingen en aanbevelingen. Snapt u het nog, ik was het spoor bijster. Elders wordt aangegeven dat er in totaal 12 vragen doorlopend genummerd komen verdeeld over vier onderwerpen. De Romeinse nummering begint bij i en loopt uiteindelijk door tot ix met verwijzingen in de vorm van normale cijfers. De ontbrekende vragen vind je in een eerdere paragraaf maar nu genummerd a), b) en c). Ook het eerste hoofdstuk Inleiding en overzicht is verwarrend. Het schema benoemdbenoemt 9 hoofdstukken maar het zijn er 10. Hoofdstuk 9 Samenvatting implementatie portfolio ontbreekt. Kortom broddelwerk van uitgeverij Elix!

Gaan we dan naar de inhoud dan zien we dat de auteur het boek in twee hoofddelen heeft onderverdeeld. De eerste hoofdstukken beschrijven portfoliomanagement op hoofdlijnen en de overige hoofdstukken gaan in op verschillende implementatiewijzen.

In het hoofdstuk Waarom portfoliomanagement beschrijft de auteur een aantal redenen voor invoering: verankering van de vernieuwing, optimale samenhang en integraal resourcemanagement. Ik had hier de aanleiding waarom ik portfoliomanagement zou willen implementeren verwacht zoals: projecten lopen uit, wat kunnen we daar aan doen? Geen idee waarom we dit project doen, wat levert het op? Draagt het überhaupt bij aan onze strategie? Et cetera. Maar dit is uiteraard mijn mening.

Kijk ik naar de door de auteur verschillende implementatiewijzen dan komen de volgende implementatiewijzen aan bod:

  • Techniek. Maak gebruik van de methode/techniek. Gebruik een template voor portfoliomanagement, vul de gegevens in … en waar het niet of niet voldoende lukt, verricht je nadere arbeid tot de poging geslaagd is. Of volg de processen van een standaard portfoliomanagementmethode.
  • Fasering, implementeren volgens tien achtereenvolgende stappen beginnend bij het opstellen van lijst van alle projecten en programma’s, een standaard methode gebruiken, sjablonen aanpassen, portfoliomanagementcyclus inrichten, governance, dashboard inrichten, vaststellen doelbijdrage projecten, gericht tot stand laten komen nieuwe projecten, evalueren doelbijdrage, beoordelen en bijstellen portfoliomanagement.
  • Inrichtingsprincipe, implementeren volgens zes parallelle routes, met soms verschillende snelheden: besturing, beleid, processen, informatie, mens en organisatie. Dit hoofdstuk is het verst uitgewerkt en biedt ook het meeste inzicht. Paragrafen over maakbaarheid, wenselijkheid en haalbaarheid kon ik waarderen.
  • Implementeren volgens 27 elementen, een 3-bij-3-bij-drie PPP matrix: kolommen project-, programma- en portfoliomanagement en rijen besturing (opdrachtgever, begeleiding, sponsor), organisatie (instelling, inrichting, periodiciteit), processen (aanpak, resourcemanagement, templates).

Ikzelf zou meer gegaan zijn voor de keuze big bang of evolutionair, waarbij de laatste mijn voorkeur heeft. Vervolgens de vraag, die de auteur ook stelt, pak ik het op als project of als programma. M.i. moet je het zien als een programma. Bij verschillende programmamanagementmethoden is onderdeel van de aanpak het maken van een target operating model of blueprint. MSP beschrijft zo’n blueprint in termen van processen, organisatie, technologie en informatiestromen maar je zou prima het 7-S model kunnen hanteren of de door de auteur voorgestelde zes inrichtingsprincipes. Bij het maken van stappen zal je echter wel de samenhang tussen de verschillende onderdelen moeten bewaken zodat je steeds een werkende capability oplevert. Daarnaast is uiteraard ook een business case van belang. Wat willen we bereiken met portfoliomanagement, hoe gaan we dat aantonen en hoeveel gaat dat kosten? Waarbij bij de kosten niet alleen gekeken moet worden naar de implementatie zelf maar ook de operationele kosten. Hoeveel medewerkers heb je nodig om portfoliomanagement te faciliteren en te onderhouden? Ook deze business case komt in het boek niet aan bod en dit kan juist veel portfolio offices behoeden voor de discussie dat ze alleen maar overhead zijn en bij een volgende bezuinigingsronde weggesaneerd worden.

Conclusie.Het boek in deze vorm kan ik niet aanbevelen. De inhoud van de hoofdstukken over de tien stappen en de zes parallelle routes wel. Het boek had veel aan waarde kunnen winnen als het hoofdstuk implementeren naar route als basis had gediend en in verschillende hoofdstukken was onderverdeeld, hier en daar wat meegenomen van de overige hoofdstukken en alle vooruitblikken en samenvattingen achterwege waren gelaten en de redacteur zijn/haar werk had gedaan.

Bestellen: Portfoliomanagement implementeren. Hoe pakt u dat aan?

Reactie René Hombergen:

“Leuk. Een recensie met een taalfoutje… een werkwoordsvorm met d waar het een t moet zijn. En flauw om dat te noemen? Wellicht. Als het daarbij blijft zeker. Zinvoller is het op de inhoud in te gaan. Henny heeft gelijk. Over het boek.

Dit boek mist een gedegen eindredactie. In die eindredactie mogen geen fouten voorkomen zoals een inleiding die spreekt over negen hoofdstukken waar het er tien zijn. Waar Romeinse en Arabische nummering en afnummering met letters verwarrend door elkaar heen lopen, is sprake van… blunders. Daar verliest een lezer zijn houvast. Als dan ook ankerpaaltjes van paragrafen en tussenkopjes niet helder zijn, ontstaat eerder een labyrint dan een helder verhaal van a tot z. Nu hoeft niet ieder managementboek een rekenkundig altijd kloppende opsomming te zijn… maar als kwesties ter overdenking worden opgeroepen moet dat niet door onoverzichtelijke redactionele onduidelijkheden geschieden. Dan moeten bewust vragen worden gesteld door de auteur aan de lezer.  

Wel mogen wat mij betreft hoofdstukken sterk in lengte wisselen… En daarmee niet in onderling gewicht. Een concluderend hoofdstuk in een audit met een enkele regel dat er geen fout is gevonden, is evenzeer van belang als een uitvoeriger hoofdstuk dat verhaalt van de gecheckte documenten, de  gehouden interviews en de gevolgde werkwijze.

Over vooruitverwijzingen en terugblikken wil ik helder zijn: dit is met name bedoeld voor jonge studenten nog niet thuis zijn in de materie en doorgaans minder in staat een boek als dit in één keer uit te lezen zoals een doorgewinterde professional als Henny zich gewoon is.

Een business case om portfoliomanagement te implementeren? Lijkt mij even overbodig als een business case om lijnmanagement over verschillende afdelingen te implementeren… Je wilt evenzeer simpelweg toezicht en proactieve sturing op je projecten. 

Henny rechtvaardigt graag een portfolio-office. Ik meen dat een dergelijk bureau snel een beheerinstrument wordt waar spreadsheets en tools de boventoon voeren… en de continue vraag ‘welke vernieuwingen brengen we naar het front?’ op de achtergrond raakt. Een war room portfoliomanagement om op het hoogste bestuurlijke niveau in een maandelijkse stand-up de programma’s uit de portfolio bij te sturen, bevalt mij meer…

Jammer is dat Henny minder aanhaakt bij de vele overzichts- en ludieke plaatjes in dit boek. Ons innerlijke oog en onze innerlijke glimlach willen ook worden gevoed…

Fijn is dat Henny in ieder geval de inhoud aanprijst voor een mogelijk stappenmodel om portfoliomanagement te implementeren en zeker voor de zes genoemde routes. Enkele grote, in portfoliomanagement gespecialiseerde Nederlandse advies- en managementbureaus hanteren immers ook deze routes.

 Henny’s conclusie klopt wat mij betreft: de inhoud verdient aanbeveling. En het boek verdient een gedegen eindredactie-ronde! Waarvan acte. Wordt (snel!) opgepakt. Wie weet wat het oordeel wordt in een volgende recensie…?”

Advertisements

Recensie: ISO 21500 in de praktijk

9789052541563-200x300ISO 21500 in de praktijk. De interne richtlijn voor projectmanagement geschreven door Anton Zandhuis, André Legerman en Rommert Stellingwerf beschrijft in het kort de structuur van de richtlijn inclusief een overzicht van de projectmanagement processen naar proces- en themagroepen en de procesgroep interacties met de belangrijkste input en output. Maar dat is niet het hoofdonderwerp. Dit boek schetst de achtergronden, het belang en de toepassing van ISO 21500. Kort samengevat wat moeten we met deze richtlijn.

Het boek neemt ons mee in de aanleiding voor de standaard. In 2016 word c.a. €22 triljard geïnvesteerd, waarvan veel middels projecten. Alleen al binnen de ICT zijn er een kleine 20 projectmanagement methoden. De ISO 21500 biedt één wereldwijde norm en taal waardoor onderlinge afstemming tussen projecten, ook al gebruiken ze ieder een eigen methode, mogelijk wordt. De basis ligt bij bronnen zoals de ANSI norm (gebaseerd op de PMBoK 3de editie), ICB 3, PRINCE2, en een aantal ISO, DIN en BSI normen. De ISO 21500 is een informatieve norm, een richtlijn en geen normatieve norm en daardoor dus niet bedoeld of geschikt voor certificatiedoeleinden.

Daarnaast wordt ingegaan op het algemeen belang en het belang voor organisaties van de norm en meer specifiek voor rollen binnen een organisatie (management, stuurgroep, opdrachtgever, opdrachtnemer, projectmanager, projectadviseur (PMO), projectteam, programmamanager, portfoliomanager en kwaliteitsmanager.

We krijgen een tien stappen plan en een aantal hints en tips om zelf ISO 21500 te implementeren en een bijbehorend fictief praktijkvoorbeeld.

Het boek wordt afgesloten met een toekomstverwachting van ISO 21500, een doorontwikkeling naar een familie van richtlijnen en een honderdtal vragen en antwoorden over ISO 21500.

Conclusie:Een informatief boekje over het waarom van ISO 21500. Het implementatieplan vraagt echter nog wel wat nadere uitwerking.

Bestellen: ISO 21500 in de praktijk

Recensie: Kanban in de praktijk

9789492790095-200x300Regelmatig loop ik tegen een stukje onbegrip over Kanban aan. Kanban wordt dan gezien als een hulpmiddel (bord) om visueel te maken waar men mee bezig, wat nog opgepakt moet gaan worden en wat al af is. Dit is ontegenzeggelijk een onderdeel van Kanban maar Kanban is veel meer. Sam Laing en Karen Greaves geven in hun boekje Kanban in de praktijk een helder overzicht wat Kanban nu precies inhoudt.

Het vlot leesbare boekje is in minder dan een uur uit te lezen. De auteurs stellen echter voor dat je het boekje in een aantal iteraties tot je neemt, er mee aan de slag gaat en verbeteringen in je eigen Kanban doorvoert en dan weer verder leest.

Het is dus een praktijkboekje dat je helpt om met je eigen team Kanban te kunnen toepassen. Als rode draad wordt het hoveniersbedrijf Growing Gardens opgevoerd dat een klein boekje over tuinieren gaat schrijven ter promotie van hun bedrijf.

De auteurs gaan uit van vijf Kanban principes of uitgangspunten die ieder in een eigen hoofdstuk uitgewerkt worden.

De vijf principes:

  • kanban in de praktijkVisualiseer je werk
  • Beperk de hoeveelheid onderhanden werk en maak het mogelijk dat teamleden werk naar zich toe trekken
  • Zorg voor doorstroom
  • Maak afspraken expliciet
  • Verbeter samen

Visualiseer je werk: Hier krijgen we een eerste opzet te zien van het bord dat de drie medewerkers van Growing Gardens gaan gebruiken met daarop de uit te voeren stappen/kolommen (te doen, schrijven, tekeningen, redactie en klaar). Onder te doen staan de taken (ieder hoofdstuk is een taak. En zo’n taak(kaartje) verschuift op het bord van links naar rechts). Vervolgens komen een serie tips aan bod m.b.t. het bord zelf maar ook het zichtbaar maken van de voortgang (wel opgepakt maar geen voortgang: een rode stip), een avatar om aan te geven wie aan welke taak werkt en wat per taak op een taakkaartje (of post-it) minimaal vermeld moet worden (beschrijving, startdatum, datum gereed). Afsluitend krijgen we een paragraaf met daarin een checklist die je zelf kan hanteren bij het toepassen van Kanban binnen je eigen team. Ook in de overige hoofdstukken wordt deze indeling van case, tips en eigen praktijk gehanteerd.

Beperk de hoeveelheid onderhanden werk en maak het mogelijk dat teamleden werk naar zich toe trekken: Als het schrijven van een hoofdstuk klaar is maar de volgende stap is nog niet begonnen dan kan je dat niet zien. Binnen Growing Gardens splitsen ze daarom de kolom schrijven in bezig en klaar voor tekeningen. Pas als daadwerkelijk begonnen kan worden met het maken van een tekening voor het betreffende hoofdstuk verschuift het kaartje naar de kolom tekeningen (Pull). Ook wordt onderkend dat het onhandig is als men met teveel taken tegelijkertijd bezig is. Door het aantal taken waaraan je werkt te verkleinen kan de doorstroom groter worden. Men noemt dat de Work-In-Progress (WIP) Limit per processtap. Verder worden begrippen als cyclusduur, levertijd en faalratio behandeld.

Zorg voor doorstroom: Binnen Growing Gardens liep men tegen vertraging aan. Niet iedereen had evenveel tijd beschikbaar, ook het maken van tekeningen duurde veel langer dan gedacht. Door de stap redactie naar voren te halen was tijdwinst te behalen. Daarnaast kun je ook expliciet maken dat een taak geblokkeerd is zodat dat voor iedereen zichtbaar is dat er wat moet gebeuren. Ter ondersteuning worden hier verder het gebruik van een dagelijkse standupmeeting en het toepassen van buffers op het bord besproken.

Maak afspraken expliciet: Binnen Growing Gardens stagneerde het werk. Werkzaamheden aan het boek werden steeds naar achteren geschoven. Door expliciet af te spreken dat er altijd een persoon minimaal twee uur per dag aan het boek te laten werken kwam er weer beweging in. Dit werken aan andere activiteiten is ook op het bord visueel te maken door daarvoor een eigen baan te creëren (swimlane) en afspraken te maken hoeveel tijd/werk per baan besteed mag worden. Verder zijn er afspraken te maken over hoe om te gaan met spoedgevallen, wanneer is iets ‘klaar’ (Definition of Done) et cetera.

Verbeter samen: Growing Gardens had haar boek afgerond en men bleef een bord gebruiken voor hun dagelijkse werkzaamheden. Duidelijk was dat ook dit bord regelmatig aangepast zou moeten worden en men sprak af om een keer per maand de werkwijze te evalueren (retrospective).

In bijlagen krijgen we uitleg over Personal Kanban en het vliegtuigspel om het effect van de WIP te kunnen ervaren.

Conclusie: Een vlot leesbaar, handig praktijkboekje voor diegenen die nog geen kennis van Kanban hebben en willen weten wat het is of beter nog ermee aan de slag willen gaan.

Bestellen: Kanban in de praktijk

Recensie NR. 4 – 2018 Vakblad Projectmanagement

Afbeelding1

Dit weekend nummer 4 van het Vakblad Projectmanagement – voor projectmanagers, door projectmanagers uitgegeven door KWD Resultaatmanagement gelezen. Wederom een scala aan interessante artikelen en columns.

Het hoofdartikel (Remmelt van der Wal) beschrijft hoe de projectmanager weerstand bij projecten begrijpt, herkent en er op een adequate manier mee omgaat. We krijgen een overzicht van verschillende oorzaken van weerstand inclusief de dominante driver (ratio of emotie), een drie-stappen model: waarnemen (symptomen van weerstand), analyseren (per fase oorzaken van weerstand) en vertalen (aanpak weerstand). Ook wordt een eenvoudige vragenlijst geboden om de weerstand te kunnen doorgronden.

Een aantal andere artikelen die hiermee in verband gebracht kunnen worden, betreffen Een dilemma voor projectmanagers – En je moet kiezen (Saskia Giebels) waarin je voor de keuze wordt gezet of de relatie of het resultaat belangrijker is of zijn er win-win situaties te vinden? Een volgend artikel Hoe om te gaan met dilemma’s (Peter M. Storm) laat zien dat er meerdere wegen zijn om met een dilemma om te gaan. Hoe karakteriseer je die wegen en onder welke omstandigheden is een bepaalde weg wel of niet geschikt. En het artikel Help, ik moet snel besluiten (Remmelt van der Wal) beschrijft het dilemma van de tijd nemen om een op feiten gebaseerd besluit te kunnen nemen versus het snel nemen van een besluit.

We krijgen ook deel 1 van een artikelenreeks over agile contracten (ook in nr. 2 stond een artikel over agile contracten). Dit artikel Agile contracteren – Hoe doe je dat? (Neeltje van der Veeken, Lammert Vinke en Erik van Daalen) geeft, gezien vanuit de leverancier, een aantal handreikingen die het agile contracteringsproces ondersteunen en die agile contracten verbeteren (Nb. PRINCE2 Agile en SAFe bieden beiden ook een aantal handvatten ter ondersteuning bij het opstellen van agile contracten).

Tenslotte nog een artikel (Luuk Ketel) hoe KWD omgaat met het Professionaliseren van projectmanagement. (Ps. Ik zou verwijzen naar de ICB4 i.p.v. NCB3) en een artikel Snel of zuinig (Peter M. Storm) waarin tijd en middel gedreven projecten met elkaar worden vergeleken.

We vinden ook een oproep om mee te werken aan een onderzoek naar agile team performance. Is agile softwareontwikkeling vaak minimaal 30% duurder dan traditioneel ontwikkelen, maar levert wel beter geaccepteerde software op?

De drie columns zijn zoals we gewend zijn weer ‘food for thought’. Peter Storm geeft het vervolg op zijn vorige column de toegevoegde waarde van de projectmanager en licht zijn standpunt – het gaat om synergie – nader toe. Ben Berndt brengt een nieuw begrip over het voetlicht: fairagile op basis waarvan hij de beschrijving van agile leiderschap uitbreidt met je houden aan afspraken, leren, je durven uiten ook wanneer je een fout maakt, de groep betrekken, de mening van eenieder horen en geen vooringenomenheid tonen maar wel respect. Tenslotte vraagt John Hermarij in zijn column Over veranderaars zich af of hij door de bomen het bos nog wel ziet. Agile heeft niets met agile te maken en projectmanagement niets met projectmanagement! Schieten we nu ook niet enorm door met agile zoals we dat in het verleden met projectmanagement gedaan hebben?

Het laatste onderdeel betreft het boek van het kwartaal waar ik zelf de inhoud voor mag aanleveren, maar om mijn eigen recensie te recenseren gaat toch wat te ver, dat laat ik graag aan anderen over.

Geen abonnee maar wel belangstelling voor het blad, en ik kan het van harte aanbevelen, dan is het een kwestie van abonneren. Zie: KWD Resultaatmanagement.

Recensie: Dit is agile – Van introductie tot implementatie

9789043025324-480x600Recentelijk heb ik een volwassenheidsnulmeting bij een financiële instelling uitgevoerd. Tijdens de interviews werd verwezen naar een, mij onbekend boek, ‘Dit is agile – Van introductie tot implementatie’, dat deze organisatie als leidraad gebruikt had bij het invoeren van agile. Uiteraard kon ik het niet laten om dit door Sander Hoogendoorn geschreven boek te recenseren.

Het boek beslaat tien hoofdstukken waarbij ik het in drie stukken heb opgedeeld.

In het eerste stuk, de eerste twee hoofdstukken, neemt de auteur ons mee in de wereld van niet werkende waterval projecten en hoe dat in een agile wereld zou verlopen. Wat zijn kenmerken van waterval projecten (aan de hand van Winston Royce’s whitepaper Managing the Development of Large Software Systems) en wat zijn de meest voorkomende problemen met waterval. In het tweede hoofdstuk krijgen we een beschrijving van agile. Wat betekenen de vier statements in het Agile Manifesto. Vervolgens gaat de auteur in op de kenmerken die een project agile maken en beschrijft agile in een notendop.

Het tweede deel omvat de kern van het boek en beschrijft in detail een aantal aspecten van agile:

  • Korte iteraties: de opbouw, het waarom en het nut van een vaste lengte voor de iteraties (heart beat).
  • Samenwerken in teams: kenmerken team: multidisciplinair, compact, meerdere teams, verantwoordelijk, zelfsturend, transparant, co-locatie? en meetings en technieken voor samenwerken: kick-off, daily stand-up, evaluatie, workshop, pair programming, side-by-side programming en pair testing.
  • Samenwerkende rollen: welke rollen? Elk project vraagt om: expertise, generaliserende specialisten, stabiliteit, balans en specialisten. De verantwoordelijkheden van klanten bij agile projecten worden belegd bij de projectsponsor, Product Owner (één, want meerdere product owners verwarren het team), gebruikers en domein experts. Het is het team dat het project uitvoert, de faciliterende projectmanager en de agile coach.
  • Agile requirements: welke eenheid van werk is de juiste, aan welke criteria moet zo’n eenheid voldoen (vgl. INVEST)? User Stories, Use Cases en Smart Use Cases (zie voor een toelichting onderaan deze post) worden beschreven als werkwijze om een requirement te beschrijven.
  • Schatten: schatten is van levensbelang voor projecten maar is heel moeilijk. De auteur geeft een veelvoud aan oorzaken waarom dit zo moeilijk is. Verder krijg je een uitleg wat het betekent als je in uren schat (absoluut) of in punten (relatief), hoe je de snelheid waarmee punten worden gerealiseerd kan meten en vaststellen (meten is weten).
  • Plannen: adaptief plannen, het gebruik van een project of product backlog en een iteratie backlog en het prioriteren. Verder komt het beheren van de backlog en het gebruik van dashboards, burn-down en burn-up charts.

Het laatste afsluitende deel pakt het implementeren van agile op aan de hand van verschillende licht- en middelgewicht aanpakken, zoals XP, Scrum, DSDM (nu AgilePM genoemd), Smart en Kanban en beschrijft de mogelijke hobbels en kuilen die overwonnen moeten worden. Denk hierbij aan: big up-front design of geen design, agile als excuus, dood door dogma, een groot project als pilot, re-architecting, one-size-fits-all agile, reverse enginering, death by planning, reviews, kind en badwater, monodisciplinaire teams, parttime agile en het handboek agile.

Conclusie. Het is al een wat gedateerd boek (eerste druk 2012) en dat verklaart m.i. waarom in het boek meer recentere agile aspecten niet of onderbelicht worden. Over het belang van kernwaarden, denk bijvoorbeeld aan de scrum waarden, wordt niet gesproken maar ook ontwikkelingen zoals DevOps en het schalen van agile en gebruik van scaling raamwerken komen niet bod. Verder jammer dat de auteur het belang van het agile principe: Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel niet beschrijft (wetende dat de Standish Group laat zien dat meer dan 60% van de opgeleverde functionaliteit niet of bijna nooit wordt gebruikt) en het gebruik van dit principe het succes van een project kan vergroten i.p.v. iteraties toevoegen om alle requirements op te leveren.

Neemt niet weg dat het boek een goed inzicht geeft hoe een agile software project kan werken en daarmee nog steeds de moeite van het lezen waard is.

Bestellen: Dit is agile – Van introductie tot implementatie

Mochten smart use cases onbekend zijn, zie hier een toelichting:

Ronde tafel opdrachtgeverschap

2018-03-21 14.28.01Afgelopen dinsdag bij Blue Bricks in Alphen aan de Rijn een levendige Ronde tafel opdrachtgeverschap bijgewoond. Zoals het ook al treffend in de naamgeving van Blue Brick’s oprijlaan tot uitdrukking komt is goed opdrachtgeverschap een cruciale randvoorwaarde voor projectsucces.

Na een voorstelrondje neemt Ronald van Steennis ons mee in de wereld van de opdrachtgever en gaat de discussie aan wat succesvolle projecten zijn. Hierbij wordt gekeken naar zowel het wel/niet halen van de gestelde doelen en het wel/niet accepteren van het opgeleverde systeem. Dit levert een viertal mogelijke situaties op waarbij slechts in 10% van de projecten gesproken kan worden over een succesvol project waarbij zowel de doelen zijn gehaald als het hebben van een geaccepteerd systeem. In 90% van projecten kunnen we niet spreken van succes. 20% van de projecten worden gezien als mislukte projecten, het systeem is niet geaccepteerd en het doel zou gehaald kunnen worden. 10% van de projecten wordt voortijdig gestopt. Dat wil niet zeggen dat het een mislukt project is maar het systeem is niet opgeleverd en het doel is niet bereikt. Daarnaast zien we de tijdbom projecten. Dit betreft 60% van de projecten waarbij het systeem wel is geaccepteerd maar het doel niet is bereikt. Er gaat een moment komen dat men zich realiseert dat het geen succes is.

Daarnaast beleven (perceptie) opdrachtgever en opdrachtnemer ieder op hun eigen manier succes. Voor de opdrachtgever gaat het uiteindelijk om het realiseren van de doelstellingen en voor een projectmanager gaat het in eerste instantie om het op tijd en binnen budget leveren van resultaten.

Ook zien we dat tijdens de uitvoering van een project zijpaden met eigen doelen kunnen ontstaan. Nieuwe stakeholders komen in beeld met hun eigen belangen. Het is het samenspel tussen opdrachtnemer en opdrachtgever om hierop te acteren.

IMG_0621Vele onderzoeken laten zien dat ontoereikend opdrachtgeverschap een belangrijke faalfactor is van projecten. Om inzichtelijk te maken welke verantwoordelijkheden bij de opdrachtgever liggen en welke bij de opdrachtnemer is het opdrachtgever poker ontwikkeld. Middels een set kaarten wordt de dialoog aangegaan om te kijken welke taken bij de opdrachtnemer horen en welke bij de opdrachtnemer. Vraag je dit aan de opdrachtnemer dan zullen vele taken bij de opdrachtgever terechtkomen en vraag je dit aan de opdrachtgever dan is dit precies andersom. Uiteraard hebben alle deelnemers de stapel met taken/verantwoordelijkheden verdeeld over zowel de opdrachtgever als de opdrachtnemer.

Ook zien we dat de positie van de opdrachtgever in de organisatie van belang is om de rol succesvol te kunnen invullen. De opdrachtgever heeft vanuit zijn/haar hiërarchische positie invloed op de actieve en passieve stakeholders. Als de opdrachtgever te laag in de organisatie zit, kan risico’s met zich meebrengen.

Tenslotte sluiten we de sessie af met de meest belangrijke vragen die de opdrachtgever regelmatig zal moeten stellen om daarmee de succeskans te verhogen.

  • gaan we doel halen?
  • wordt de oplossing geaccepteerd?

Conclusie een leerzame ronde tafel waarin veel ervaringen zijn uitgewisseld.

Recensie: Switch – Durf te veranderen

9789400505681-480x600In het boek Switch – Durf te veranderen werken de auteurs Chip en Dan Heath een fundamenteel raamwerk uit dat je kan helpen bij situaties waarin je gedrag moet veranderen (switch): stuur de bereider aan (geef kristalheldere instructies door de rationele kant van mensen aan te spreken), motiveer de olifant (betrek de emotionele kant van mensen erbij) en effen het pad (maak de verandering waarschijnlijker).

Aan ieder van de drie aspecten weidt het boek een deel. In het eerste deel – Stuur de bereider beschrijven de auteurs dat je op zoek moet gaan naar lichtpuntjes. Blijf niet hangen in mislukkingen maar onderzoek en kloon de successen. Geef vervolgens de bereider een startpunt en een eindbestemming en geef hem een ansichtkaart van de eindbestemming zodat de bereider weet waar hij/zij heen gaat en het geeft de olifant inzicht waarom de reis interessant is. En tenslotte schrijf je de te nemen cruciale acties voor.

In het tweede deel – Motiveer de olifant krijgen we vele voorbeelden hoe je de olifant kan doen geloven dat hij in staat is de verandering te veroveren. Het is de emotie die de olifant motiveert. En motivatie komt voort uit gevoel. Enerzijds kan je de verandering verkleinen en anderzijds kan je mensen laten groeien (of, beter nog, allebei).

In het laatste deel – Effen het pad krijgen we te zien wat het betekent als je de de omgeving verandert dit een effect heeft op het gedrag. Eenvoudige aanpassingen kunnen leiden tot enorme veranderingen. Zoek naar manieren om gewoontes aan te moedigen en tenslotte gebruik de mensen in de omgeving. Gedrag is besmettelijk, help het te verspreiden.

Switch (bereider, olifant, pad, 180321) v1.0

Conclusie: een must voor de veranderaar, je krijgt een veelheid aan voorbeelden en een gedegen onderbouwing van het driedelige switch raamwerk en daarnaast een aantal workshops waarmee je zelf aan de hand van een situatie moet nadenken hoe de drie switch onderdelen gehanteerd moeten worden (stuur de berijder aan, motiveer de olifant en effen het pad).

Bestellen: Switch – Durf te veranderen