AgilePgM manual tabs

HWP Consulting received the ATO and trainer accreditation to give AgilePgM training classes. AgilePgM will be part of our Agile Programme Management training where we blend AgilePgM and Leadership into one training (There are still some open positions for the March 10-11, 2020 class I give together with Björn Prevaas (In Dutch. See:

I am happy to announce that as of now, AgilePgM candidates can make use of a simple aid to quickly find your way in the official AgilePgM manual during e.g. studying for your exam (there is no AgilePgM Practitioner examination yet). These tabs (place marks) are developed in line with the successful tabs I developed for the PRINCE2 manual.Agile PgM Manual tabs 2014 v1

To download: Agile PgM Manual tabs 2014 v1


A Bird’s eye view on the agile forest article published on PM World Journal

The PM World Journal has published the latest version of my Bird’s eye view in the agile forest article. For sure there will updates in the coming months.

Some years ago, you could say “Scrum is agile” and ask “is agile Scrum?” Now we know there is much more flesh on the bones. At this moment there are more than fifty known and less known agile approaches, frameworks or methods available. To get a first impression of the different approaches, I try to bring some structure in the jungle to approaches, methods and frameworks. In Figure 1, I position the best-known agile approaches in a structure. The approaches, frameworks or methods are positioned within the ‘One-time programs / projects’ sections or within ‘Business as usual’ / indefinite, or both.Agile (50 shades of grey Clarity User Society, 191105) v1.0On the other side the approaches, frameworks or methods are clustered around team, product or programme and portfolio level. In the dark blue boxes in Figure 1 we see agile approaches that are only applicable in IT-focused organizations. All other approaches can be used within IT and non-IT-oriented organizations (light blue coloured). I haven’t mapped all the known approaches, frameworks and methods in this figure, and to be honest, I think there is a lot of duplication and probably commercial drivers play a role too to ‘develop’ the next kid on the block without added value in comparison with the existing approaches, frameworks or methods

Have a look for the latest version: Portman, H. (2019). A bird’s eye view on the agile forest; PM World Journal, Vol. VIII, Issue X, November


Review Brave New Work

9780241361801-480x600In his book Brave new work, Aaron Dignan shows how he views evolutionary (agile) organizations and what you can do to become a more agile organization.

The book is made up of three parts. The first part – The future of our work shows how our work has changed as a result of technological progress and on the other hand that for many organizations this does not apply to management. An organization chart of an organization from 100 years ago is still comparable with many organizations of today. But there are also organizations that do it completely different. The illusion of control is exchanged for something much better. The author calls these pioneering organizations evolutionary organizations. Evolutionary organizations are people positive and complexity conscious and use these mindsets to collectively and continuously improve their shared operating system (how the organization works).

Based on comments throughout the book, evolutionary organizations can be characterized as follows:

  • grow without losing the culture they love
  • work fewer hours but get more done
  • protect the planet but maintain outsized profitability
  • create prosperity, not just for their shareholders but for employees, customers, and communities
  • know that if you treat people like mercenaries, they will become mercenaries. Treat them like all-stars and they will become all-stars
  • aspire to eudaemonic purpose-missions that enable human flourishing
  • ensure that everyone has the freedom and autonomy to serve the organization’s purpose
  • focus on their value-creation structure
  • favor units or “cells” of 10 to 150 people who are self-sufficient
  • are transparent
  • have a responsive structure in place
  • Have a certain level of maturity and competence
  • make better decisions faster
  • anyone can make a big decision, but first they must seek advice from colleagues who have experience with or will be affected by their choice
  • allocate resources dynamically
  • form and disband teams fluidly
  • innovate both product and process
  • converge on twelve domains (the OS canvas)

This last point, evolutionary organizations converge on twelve domains, is elaborated in part two – The operating system. These twelve domains form the Operating System Canvas (OS canvas).

The OS Canvas:

  • PURPOSE: How we orient and steer; the reason for being at the heart of any organization, team, or individual.
  • AUTHORITY: How we share power and make decisions; the right to make decisions and take action, or to compel others to do the same.
  • STRUCTURE: How we organize and team; the anatomy of the organization; formal, informal, and value-creation networks.
  • STRATEGY: How we plan and prioritize; the process of identifying critical factors or challenges and the means to overcome them.
  • RESOURCES: How we invest our time and money; the allocation of capital, effort, space, and other assets.
  • INNOVATION: How we learn and evolve; the creation of something new; the evolution of what already exists.
  • WORKFLOW: How we divide and do the work; the path and process of value creation.
  • MEETINGS: How we convene and coordinate; the many ways members and teams come together.
  • INFORMATION: How we share and use data; the flow of data, insight, and knowledge across the organization.
  • MEMBERSHIP: How we define and cultivate relationships; the boundaries and conditions for entering, inhabiting, and leaving teams and organizations.
  • MASTERY: How we grow and mature; the journey of self-discovery and development; our approach to nurturing talent, skills, and competence.
  • COMPENSATION: How we pay and provide; the ages, salaries, bonuses, commissions, benefits, perquisites, profits, and equity exchanged for participation in the organization.

QRC (Brave new work EN, 191101) v1.0To download: QRC (Brave new work EN, 191101) v1.0

Each domain of the OS canvas is further elaborated in its own chapter. You get an extensive explanation based on concrete examples. Many to be applied techniques and step-by-step plans are provided too. In addition, you will receive for each domain a questionnaire that can be put to the entire organization or to individual teams. The canvas can provoke incredible conversations and powerful stories to determine which elements in your culture need to be strengthened and what needs to be done differently. Each chapter is concluded with an explanation of the two mindsets. How can you incorporate a people positive and complexity conscious mindset in the domain described?

In the third part – The change, the central question is how an operating system transformation works. This is based on a continuous participatory change. Within this continuous participatory change are six important patterns (Do not mistake these for steps. They’re more akin to thresholds):

  • Commitment: When those with power or influence commit to moving beyond bureaucracy (autonomy, consent, transparency)
  • Boundaries: When a liminal space is created and protected
  • Priming: When the invitation to think and work differently is offered (complexity, emergence, self-organization, organizational debt, agility, leanness, motivation, self-awareness, mastery, trust, generative difference, psychological safety, and more)
  • Looping: When change is decentralized and self-management begins (sensing tensions, proposing practices, and conducting experiments)
  • Criticality: When the system has tipped and there’s no going back
  • Continuity: When continuous participatory change is a way of life, and the organization is contributing to the broader community of practice (the role of the leader: creating space, holding space).

Conclusion: A book that shows what it means to achieve more business agility without getting bogged down in a description of implementing a (scaling) agile framework, because that alone won’t get you there. A must read for managers, with many practical tools to get started.

To order: Brave New Work

Youtube: Talk at Google: We were joined by Aaron Dignan, the founder of The Ready, an organization design and transformation firm, and author of “Brave New Work” to discuss better ways of working and how to ignite the energy in an organization, building a company that runs itself.

Zie verder mijn blog voor een recensie van de Nederlandse uitgave.

Review: Exponential organizations

9781626814233-480x600Salim Ismail wrote, together with Yuri van Geest and Michael S. Malone, Exponential organizations – Why new organizations are ten times better, faster, and cheaper than yours (and what to do about it). These exponential organizations are able to show an exponential growth curve due to the integral application of communities, big data, smart algorithms and new, innovative technologies. The authors used research into hundreds of startups and interviews with CEO’s of the fast-growing companies (Airbnb, Netflix, Tesla, Waze, et cetera).

The book consists of two parts and an introduction. The first part explores the characteristics and implications of exponential organizations. The second part deals with the practical implementation and future vision of these organizations. You get tools to implement the exponential organization model in your own organization too.

Moore’s law will be known to many. Every eighteen months the price / performance of computing power doubles. And this has already been applicable for the last sixty years. However, this exponential doubling is much more common, but predicting a technology when it doubles is always dangerous. The Human Genome Project was set up in 1990 with the aim of completely unraveling a single human genome. According to various predictions, the project would take 15 years and cost $ 6 million. Every expert called the project a failure in 1997, pointing out that if only 1 percent were unraveled in 1997, it would take seven hundred years for the entire genome to be mapped. According to Ray Kurzweil, the 1% meant they were halfway. Double 1% seven times was 100%. The project was completed in 2001!

Almost by definition, exponential organizations (ExOs) all think big and this is reflected in the higher ambitious goal of the organization. The massive transformative purpose (MTP) statement is formulated for this purpose.

QRC (ExO EN, 191021) v1.0To download: QRC (ExO EN, 191021) v1.0

ExO’s are described by five external (SCALE) and five internal (IDEAS) elements. To classify as an ExO you need to have a Massive Transformation Purpose (MTP) and at least 3-4 of the ExO-elements. In the appendix you can find a questionnaire to calculate your own exponential score. SCALE- and IDEAS-elements are self-reinforcing and integrating.

The external elements (SCALE) to improve your performance are: Staff on demand, Community & Crowd, Algorithms, Leveraged assets, Engagement. ExOs scale up beyond the boundaries of their own organization by using or gaining access to people, assets and platforms to maximize flexibility, speed, agility and learning processes.

In addition, the controlling framework of the five internal elements (IDEAS) is described, which manages the abundant output of the external SCALE elements: Interfaces, Dashboards, Experimentation, Autonomy, Social.

In addition to the aforementioned characteristics, the authors have determined nine key dynamics at play for the ExO ecosystem:

  1. Information accelerates everything
  2. Drive to demonetization
  3. Disruption is the new norm
  4. Beware the “expert”
  5. Death to the five-year plan
  6. Smaller beats bigger
  7. Rent, don’t own
  8. Trust beats control, open beats closed
  9. Everything is measurable and anything is knowable.

In the second part the authors explain how to start an ExO by using examples and they offer a step-by-step plan:

  1. Select a massive transformative purpose (MTP)
  2. Join or create relevant MTP communities
  3. Compose a team
  4. Breakthrough idea
  5. Build a Business Model Canvas
  6. Find a business model
  7. Build the MVP
  8. Validate marketing and sales
  9. Implement SCALE and IDEAS
  10. Establish the culture
  11. Ask key questions periodically
  12. Building and maintaining a platform.

In addition to setting up, attention is also paid to how you can grow an organization in the mid-market company segment, exponentially. Through examples from TED, GitHub, Coyote Logistics, Studio Roosegaarde, GoPro and how they score on the ExO elements, you get a good overview of what is possible. Finally, a number of strategies are discussed with which large organizations can align themselves with ExO concepts while retaining their core activities transform leadership, partner with, invest in or acquire ExOs, disrupt and implement ExO lite internally.

By using examples from Bridgewater, Coca-Cola, Haier, Xiaomi, The Guardian, GE, Amazon, Zappos, Tangerine, and Google Ventures, among others, the authors explain how these strategies have been put into practice by showing their exponential score. The book concludes with a chapter on exponential executives including the CEO, CMO, CFO, CTO / CIO, Chief Data Officer (CDO), Chief Innovation Officer (CIO), COO, Chief Legal Officer (CLO), and the CHRO.

Conclusion. Is this era of agile transitions, a must read for senior management to understand that scaling of agile teams is not enough to survive in this twenty first century? The book offers a practical framework to experiment with one or more of the ExO elements.

To order: Exponential organizations

See my blog for the Dutch translation of this book.

Recensie DevOps …… in beweging

9789090318011-480x600 devopsJan Heunks heeft met het boek DevOps …… in beweging – De handvatten voor een optimale DevOps toepassing (2019) een lijvig boekwerk opgeleverd.

Het boek bestaat uit drie delen:

In deel 1 komt de toegevoegde waarde van DevOps aan de orde en geeft een eerste introductie op DevOps aan de hand van Continuous Delivery en de agile-, ITSM- en Lean IT-werkwijzen. Daarnaast wordt DevOps in relatie tot de waardeketen en de demand-supply-structuur uitgewerkt. Dit deel wordt afgesloten met een stukje historie (met in de bijlage een tijdslijn van DevOps-ontwikkelingen).

Het tweede deel is een theoretische verdieping op een aantal DevOps-kaders en gaat specifiek in op de belangrijkste bewegingen die gelden voor DevOps, zijnde de Lean IT-, Agile- en ITSM-beweging. Binnen Lean-IT komen begrippen zoals her House of lean, Toyota Production System, lean thinking, Continuous Improvement, Kaizen en respect for people aan bod. Bij de Agile-beweging vinden we agile-basis, Scrum, het Agile Manifesto, agile-essenties en agility. Bij ITSM krijgen we een samenvatting van het boek Visible Ops, ITIL en agile binnen IT. Ook DevOps als beweging wordt nader toegelicht. Doorstroming, feedback en continu leren en experimenteren, DevOps-principes en een paradigma-shift staan centraal.

Het derde deel moet inzicht leveren wat het betekent om DevOps in te voeren in een organisatie. Eerst worden bestaande principes, werkwijzen en toepassingen en in het bijzonder het leveren van IT-services, het leveren van nieuwe functionaliteiten en het adviseren over IT-services, van organisaties zonder DevOps besproken. Vervolgens wordt DevOps afgezet tegen de ‘primaire’ ITSM-processen, softwareontwikkeling en projectmanagement. Vervolgens wordt ingegaan op de aanpak waarmee DevOps geïntegreerd kan worden in een bestaande organisatiestructuur en hoe operational excellence bereikt kan worden middels optimale samenwerking binnen cross-functionele teams. Aan de hand van een zestal anti-typen en negen bruikbare typologieën van DevOps teamstructuren krijgt men een goed inzicht in mogelijke verschijningsvormen. Het deel wordt afgesloten met een hoofdstuk over DevOps volwassenheid.

Conclusie: Heel, heel veel theorieën, aanpakken, invalshoeken, feiten en inzichten rond het begrip DevOps. Ik geloof er echter niet in dat dit boek nu al bruikbaar is om te gebruiken als handvat bij je eigen DevOps-reis. Waarom zeg ik dat? Het boek is m.i. nog niet af. Ik denk dat dit boek een voorbeeld is van een boek dat in eigen beheer is uitgegeven (ik kon geen andere boeken vinden van de uitgever). Een redacteur had m.i. wonderen kunnen verrichten en de kwaliteit van dit boek enorm kunnen verhogen.

Persoonlijk had ik moeite met de vele lange ingewikkelde zinnen (ik heb zinnen gelezen met meer dan 63 woorden). Daarbij had ik regelmatig het idee dat het ‘Google Translate’-zinnen waren en ik mij afvroeg wat staat er nu? Storend vond ik de vele, overvloedige Engelse vertalingen die tussen haakjes stonden en die soms weer vragen opriepen (bv. output en outcome zijn bekende begrippen in de project- en programmawereld en worden hier gebruikt als vertalingen voor korte en lange termijn) of andersom kwam het geforceerd gebruik van het Nederlands de leesbaarheid ook niet ten goede. Bijvoorbeeld dubbelslagleren en dan tussen haakjes (double loop learning).

Verschillende figuren worden niet toegelicht of de verwijzing in de tekst naar de figuur ontbreekt. Ook had ik het op prijs gesteld dat een paginagroot figuur over het Phoenix project voorzien was van een verwijzing naar mijn eigen blog waarvoor ik die figuur gemaakt had, maar dat terzijde. Mijn belangrijkste bezwaar is verder de opbouw van het boek. Ik was regelmatig de draad kwijt. Bij verschillende hoofdstukken en/of paragrafen vroeg ik mij af waarom staat dit stuk hier of is dit stuk niet veel te diepgaand. Daarnaast had ik in het derde deel graag concrete aanbevelingen gezien. Nu krijg je wel een toelichting op een aspect bijvoorbeeld Bimodal IT of Brownfield & Greenfield, maar wat dit nu betekent als je DevOps gaat implementeren ontbreekt.

Bestellen: DevOps …… in beweging

Reactie Jan Heunks:

“Met de recensie op het boek ben ik zeker niet ontevreden. De samenvatting die de recensent van de drie boekdelen geeft is een prima weergave, zeker in relatie tot de boekparagrafen ‘woord vooraf’ en ‘om te beginnen’. In deze paragrafen wordt aangegeven dat de DevOps-context erg breed is en het antwoord wat DevOps feitelijk is, niet eenduidig is te beantwoorden en van veel factoren afhankelijk is.

Het zonder eindredactie en het in eigen beheer uitbrengen van een boek is een soort van avontuur en een keus, waarbij input leveren aan de snelgroeiende DevOps-community het uitgangspunt is geweest. De DevOps-reis is in ieder geval sterk afhankelijk van de volwassenheid van een organisatie, nog los van de verschillende soorten organisaties. Als concrete aanbeveling voor een DevOps-reis, iets waar de recensent mogelijk naar op zoek is, verwijs ik graag naar de roadmap-beschrijving (als ‘raamwerk’ en als ‘bestemmingsplan’) in het boek ‘Lean IT – de theorie en praktijk van Lean in een IT-omgeving’. Deze beschrijving is ook zeer behulpzaam bij een DevOps-transformatie.

Al bij al, DevOps is in beweging en iets dat in beweging is, ontwikkelt zich verder op basis van feedback en voortschrijdend inzicht.

Ik beschouw het als een compliment dat de recensie verwijst naar de grote hoeveelheid theorieën, aanpakken, invalshoeken, feiten en inzichten. Want, waar vind je een dergelijke uitgebreide beschrijving, samenhang en inzicht? De vakgenoten/reviewers die hebben bijgedragen aan het tot stand komen van het boek geven dit als volgt aan: er wordt in detail ingegaan op alle zaken die van invloed zijn voor de vorming van DevOps, het geeft overzicht in de DevOps-aspecten en de relatie met andere bewegingen, complexe materie wordt toegankelijk gemaakt, DevOps wordt tastbaar gemaakt met veel handreikingen, volledig en goed beschreven.

Dat sommige onderwerpen (te) diepgaand zijn beschreven en de plaats soms onlogisch lijkt, is herkenbaar. Dit is in het boek ook expliciet toegelicht, als volgt: sommige onderwerpen worden op meerdere plaatsen (in meer of mindere mate) beschreven of herhaald, binnen de dan geldende context; als een verdere verdieping of toelichting.

De aspecten Bimodal IT en Brownfield & Greenfield zijn in het boek toegelicht in het kader van tegenstellingen. De betreffende paragraaf wordt met een belangrijke conclusie afgesloten, die de recensent mogelijk over het hoofd heeft gezien: een kritieke succesfactor, in het kader van DevOps, is het niet vergeten van de menselijke factor omdat het onverstandig is medewerkers met beide tegengestelde werkvormen te laten werken. Dit kan als aanbeveling worden beschouwd, maar dat terzijde. Er worden overigens veel meer van dit soort aanbevelingen (cq succesfactoren) beschreven met de bedoeling dit als overweging mee te nemen in de DevOps-reis. Een lezersreactie: veel nuttige tips en aanbevelingen, dank hiervoor.

De termen output en outcome worden niet ‘vertaald’ in hetgeen de recensent aangeeft, maar worden in een context geplaatst als korte en lange termijn resultaat, oftewel het projectresultaat als output (een korte termijn resultaat) en de te behalen gewenste bedrijfsresultaten, als eindresultaat/outcome (het lange termijn resultaat).

Dat het boek niet bruikbaar is als handvat voor de eigen DevOps-reis beschouw ik als een mening van de recensent. Dat mag, echter verwacht geen concreet stappenplan of een kookboek-achtige beschrijving want die is er niet. Er zijn namelijk erg veel factoren die een succesvolle invoering van DevOps bepalen en even zoveel factoren om in overweging te nemen. Overigens begrijp ik de stellingname van de recensent maar al te goed. Echter, het doel van het boek is de lezer te helpen met het creëren van inzicht in de vele factoren die in meer of mindere mate van invloed zijn bij het behalen van succes met de DevOps-aanpak. Verder beoogt het boek om organisaties, die met de vraag worstelen op welke wijze een begin kan worden gemaakt met de invoering van DevOps, aanknopingspunten te geven waar rekening mee te houden. Twee concrete handvatten zijn blijkbaar door de recensent niet herkend: de DevOps business case en het DevOps Manifesto.

De recensent verwacht concrete aanbevelingen, met name in deel 3. Er zijn op veel plaatsen impliciet en expliciet DevOps-succesfactoren vermeld. De rode draad is dat het succes van DevOps voor een groot deel afhankelijk is van menselijke factoren, een omslag in cultuur en het begrijpen van principes. Ter ondersteuning is de inzet van bepaalde tools en technieken een prima overweging. Dit analoog aan het Shingo-model waaraan een aantal concrete leidende principes zijn verbonden. Dit is ook terug te vinden in het boek.

Een aantal waardevolle opmerkingen van de recensent, die zeker ter harte worden genomen, betreft het geforceerd gebruik van het Nederlands, de vele, overvloedige Engelse vertalingen die tussen haakjes staan en de lange ingewikkelde zinnen. Dit laatste is, ondanks de nodige aandacht die hieraan is besteed, bij een aantal zinnen blijkbaar over het hoofd gezien.”


Recensie NR. 8 – 2019 Vakblad Projectmanagement

Afbeelding1Het achtste nummer alweer. Een initiatief dat een paar jaar terug aan een onzekere toekomst was begonnen. Ondertussen kunnen we onzeker wel doorstrepen, het blad heeft in Nederland (en België?) haar positie ingenomen en staat als een huis. Een mooi moment om met een nieuw nummer te komen waar risico en onzekerheid als een rode draad doorheen lopen.

In het hoofdartikel Onzekerheid bij projectmanagers: een risico of bron van inspiratie stelt Luuk Ketel dat je van onzekerheden ook kunt leren. Onzekerheid is niet meetbaar, een risico wel en daarom moet je onzekerheden niet als risico behandelen. Zie onzekerheden als een drijfveer, als een stimulans om na te denken en het nemen van actie.

In het tweede artikel staat Praxis centraal. Een raamwerk waar ik persoonlijk moeite mee hebt. Een aantal onderdelen uit Hoofdzakelijk PRINCE2 en MSP en een beetje MoP zijn samengevoegd maar de finesses ontbreken. Ik ben het dan ook eens met de auteur Jack van Grunsven, die nadat hij eerst een overzicht geeft van Praxis, tot de conclusie komt dat Praxis vooral een goed toegankelijke website is. Noot recensent: Wil je de site gebruiken baseer je je dan op de Engelse versie. De Nederlandse versie vind ik te veel ‘google translate’.

In Hoe kweek je een zelflerend team? gaat Peter Storm in op het trainen van het aanpassingsvermogen van het team. Hierbij spelen de vier onderling samenhangende teamkwaliteiten nieuwsgierigheid & openheid, omgaan met stress, situationeel inzicht en een gezamenlijk mentaal model een rol. Jammer dat de rol van de scrum master hierin niet is meegenomen.

Ronald Kappert, Rob Develing en Rogier van der Heijden hebben onderzocht hoe de samenwerking tussen opdrachtgever en projectmanager beter vormgegeven kan worden. Hierbij is gebruik gemaakt van de Piramide van Lencioni en het Principal-Agent model. Dit onderzoek laat zien dat acht aandachtspunten kunnen helpen de samenwerking op te bouwen en te borgen en daarmee bijdragen aan het succes van het project:

  1. Vertrouwen in elkaar
  2. Bestaansrecht van het project
  3. (Gelijklopende) belangen
  4. Goede afspraken
  5. Zoek elkaar op
  6. Transparantie en open communicatie
  7. Onafhankelijkheid en ruimte
  8. Feedback geven en ontvangen

Ook gaan de auteurs in op signalen waaraan je kan zien dat de samenwerking niet goed gaat.

In het artikel Het organiseren van projecten wordt er niet makkelijker op gaat Rudy Kor in op het gedoe in en rond projecten. De onduidelijkheid over wie over wat mag beslissen? Hij kijkt naar zelfsturende teams, projectmanagers en projectleiders en wat ze zoal wel/niet mogen (moeten) doen.

Erik van Daalen gaat in het tweede artikel van een driedelige reeks over de rol van de projectmanager bij de totstandkoming van agile contracten in op agile procurement. De agile contract projectmanagement (ACPM) wordt beschreven aan de hand van vier elementen: kernwaarden, principes, proces en stuurknoppen. Ook komen verschillende succesfactoren (kennis en vaardigheden) aan bod die de projectmanager helpen om een ACPM-traject goed en succesvol te begeleiden.

In het artikel Worstelen met onzekerheid geeft Ben Berndt een impressie van wat er zoal is geschreven over onzekerheid. Zonder de pretentie volledig te willen (kunnen) zijn gaat hij in op een achttal relevante boeken of artikelen.

Remco te Winkel houdt een pleidooi voor de Agile Officer. Hij gaat in op de ontwikkeling en trendbreuken bij de ontwikkeling van een PMO en ziet voor het permanente PMO in een agile omgeving nog steeds ruimte. Agile portfoliomanagement blijft nodig, zij het dat het een meer continu iteratief proces wordt. Hij noemt de PMO’er in de agile omgeving de Agile Officer. Persoonlijk zou ik gewoon bij de portfoliomanager blijven die een veelal hybride portfolio zal managen naast medewerkers die het Center of Excellence bemannen.

In het artikel Omgaan met onzekerheid in een project stelt Peter Storm dat risico’s en onzekerheden niet gezien moeten worden als varianten van hetzelfde fenomeen. Bij het omgaan met risico’s staan feiten centraal, bij het omgaan met onzekerheden staat intuïtie centraal. Bij het beschrijven van mogelijke scenario’s kunnen zowel de risico’s als de onzekerheden worden meegenomen zodat ook de onzekerheden op tafel liggen en niet verstopt worden.

Van Leo Klaver een interview met Pauline Schömbs, een van de vrouwelijke KWD-projectmanagers. Pauline stelt direct dat er geen onderscheid is tussen man of vrouw bij het tot een goed einde brengen van een project. Het gaat om het resultaat maar de weg daarnaartoe verschilt. Een vrouwelijke projectmanager werkt anders en dat anders is waarnaar gezocht wordt in het interview. Een vrouw kijkt bijvoorbeeld anders naar situaties, zijn effectiever in het scheppen van vertrouwen en het creëren van een band met een opdrachtgever en durven eerder om hulp te vragen. Dit zijn aspecten waar een mannelijke projectmanager nog wat van kan leren. Anderzijds kan een vrouwelijke projectmanager leren van mannelijke projectleiders waarmee onderbouwd wordt dat ze elkaar goed kunnen ondersteunen.

In het laatste artikel Hoe zijn projecten te managen in een VUCA-wereld? gaan Rik Berbé en Ben Berndt in op het begrip VUCA. Zij beschrijven de uitdagingen weergegeven door de vier letters, al dan niet in projecten: volatiliteit, onzekerheid, complexiteit en ambiguïteit. Om deze uitdagingen het hoofd te kunnen bieden gaan ze vervolgens aan de hand van een casestudie (reis naar de zuidpool) in op een aantal eigenschappen/capaciteiten die essentieel zijn zoals sensitiviteit en adaptiviteit.

Uiteraard komen de drie projectfilosofen ook weer aan het woord. John Hermarij beschrijft risicovolle en kansrijke onzekerheden en houdt een pleidooi voor een opportuniteitsanalyse. Ben Berndt duikt in de paradoxale kenmerken van onzekerheden aan de hand van een verhaal van Reb Meir van Premishlan, de kloosterregels van Benedictus en hoe het VS-waterpoloteam onzekerheid aanpakt. Tenslotte kijkt Peter Storm naar verschillen tussen mannen en vrouwen, tussen rangorde en pikorde, tussen samenwerken en samenleven.

Van mijn hand is deze keer een recensie van het boek Kookboek voor bewuste verandering – sustainable change.

Conclusie. Wederom een lezenswaardig blad waarmee je het risico dat je te weinig weet van risico en onzekerheid kan mitigeren.

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.



Heart of Agile: a missing tree in my bird’s eye view on the agile forest

heart of agileOn linkedIn I received a remark that the Heart of Agile was missing in my bird’s eye view (kudos to Milvio D.).

The Heart of Agile is a radically simpler approach to achieve outstanding outcomes. The founder is Dr. Alistair Cockburn, one of the Agile Manifesto co-authors.

Whatever your initiative, it involves changing the world just a little bit. The world, however, is remarkably resistant to interventions. The best ideas fail because of misunderstandings of how the world will react, or because of errors in implementation.

The Heart of Agile simplifies two decades of practice into four critical imperatives that amplify your effectiveness:

  • Collaborate (collaboration, trust): closely with others to generate and develop better starting ideas. Communicate often to smooth transitions.
  • Deliver (learning, income): small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes.
  • Improve (experiment, change): the direction of your ideas, their technical implementation, and your internal processes.
  • Reflect (insights, improvements): periodically, along the way. Think about what you’ve learned in your collaboration and from your deliveries.

See for more detailed information.

In my bird’s eye view I positioned the Heart of Agile in the culture-targeted box.

Dia25See my blog for the complete Bird’s eye view on the agile forest article.