Management of Portfolios, Programmes, and Projects: A practical guide for leaders and decision-makers

Happy to see that TSO published my latest book.

Looking for guidance and overviews of PRINCE2, PRINCE2 Agile, MSP, MoP, P3O, MoR, AgileSHIFT, P3M3 than this book will help.

Do you come across daily challenges when managing portfolios, programmes, or projects? No matter what role you have in the portfolio, programme, or project team, you will find practical solutions in this guide to help you perform more effectively and achieve your strategic objectives

Key features include

  • health checks for portfolios, programmes, and projects, including management offices
  • checklists to assess the maturity of your organization
  • guidance on best practice for portfolio, programme, and project management (PRINCE2, PRINCE2 Agile, MSP, MoP, P3O, MoR, AgileSHIFT, P3M3)
  • key topics and challenges you may face as a manager
  • roles and responsibilities involved in directing portfolios, programmes, and projects
  • a glossary of specific terms
  • a roadmap to quickly find solutions
  • appendix summarizing roles and responsibilities

Key questions include:

  • Why hasn’t a strategic objective been met? 
  • Why has a project missed deadlines, become more costly, or failed to produce benefits?
  • How can you communicate or collaborate with a project manager or a team working remotely?
  • Is risk management in place?
  • Are the right stakeholders involved?

To order Management of Portfolios, Programmes, and Projects: A practical guide for leaders and decision-makers: TSO

Agile Portfolio Management Topics: Data gedreven portfoliosturing

Rini van Solingen en ik schrijven een boek over agile portfoliomanagement. wij spreken hiervoor met verschillende bedrijven om vast te stellen hoe portfoliomanagement in de praktijk wordt toegepast,

wat er goed gaat en waar de volgende stappen liggen. Wij doen daarbij aanvullende literatuurstudie en bundelen dit met hun ervaringen. Alle interessante bevindingen delen we niet pas aan het eind in het boek, maar ook al tussentijds in blogposts en/of artikelen. 

Aanbeveling: Voed portfoliomanagement met échte data

Neem portfoliobeslissingen op basis van data en bewijs, in plaats van op basis van meningen en aannames. Het kort cyclische ritme van agile teams biedt de mogelijkheid data snel te leveren. In de praktijk is dat soms wel aanwezig, maar vaker niet dan wel. Portfoliobeslissingen zijn dan hele grote experimenten waarbij pas na de lange en grote investering duidelijk wordt of de keuze juist was. 

Echter, agile teams zijn in staat snel experimenten uit te voeren op strategisch ideeën. Hierdoor ontstaat een korte feedbackloop tussen portfolioniveau en uitvoeringsniveau en wordt de kwaliteit van portfoliobeslissingen snel sterk verbeterd. Portfoliomanagement kan dan bottom-up worden verrijkt. OKR’s bieden bijvoorbeeld goede handvatten daarvoor met de passende mate van onzekerheid. De te gebruiken data kan op een transparante wijze en voor alle betrokkenen in de organisatie toegankelijk worden gemaakt. En aanvullend is een obeya een hulpmiddel dat hierbij goed kan helpen en zorg draagt voor inzicht, transparantie en daadkracht.

Hulpmiddel: Sturen met behulp van OKR’s

OKR’s helpen om op een gestructureerde wijze naar doelen toe te werken. OKR is de afkorting van Objectives & Key Results en is een raamwerk om strategische doelen mee te stellen en te verbinden met de praktijk. OKR is in de jaren ‘70 ontwikkeld door Intel en wordt binnen vele organisaties gebruikt. Eerst bepaal je de doelstellingen (objectives) en leg je de link met meetbare resultaten (key results). Vervolgens beschrijf je activiteiten om deze doelstellingen te behalen door het realiseren van die meetbare resultaten.

Binnen organisaties worden OKR’s op verschillende niveaus ingericht waarbij OKR’s op een lager niveau bijdragen aan OKR’s op het bovenliggende niveau. Bijvoorbeeld organisatie, team en persoonlijk niveau. Op deze wijze kunnen organisatiedoelstellingen vertaald worden naar team-, en individuele doelstellingen. Doelstellingen worden idealiter zo SMART mogelijk gedefinieerd. Het is aan te bevelen om het aantal doelstellingen en bijbehorende key results te beperken (vuistregel max 5 doelstellingen en 3 key results per doelstelling).

Hulpmiddel: Inzicht, transparantie en daadkracht middels een obeya

Obeya betekent letterlijk ‘grote ruimte’ in het Japans. Een obeya, of (virtuele) ruimte wordt gebruikt om de link te leggen tussen de strategie en doelstellingen van een organisatie en de activiteiten die nodig zijn om die doelstellingen te realiseren. Het hebben van een obeya maakt consistente, coherente en effectieve besluitvorming mogelijk en werkt motivatie verhogend voor alle betrokkenen.

In het boek Leiderschap met Obeya laat Tim Wiegel zien dat in een obeya de vijf belangrijkste verantwoordelijkheden gevisualiseerd worden in verschillende borden: Leid succesvolle strategieën, lever waarde, acteer en reageer, verbeter prestaties en los problemen op. Hij benadrukt daarnaast dat het alleen hebben van deze informatieborden niet tot resultaten leidt. Daarnaast is het cruciaal dat teams een aantal gedragsprincipes volgen waaronder: denken in systemen en eigenaarschap en het doorlopend blijven verbeteren.

Commentaar/aanvullingen

Trots op een eigen hulpmiddel of aanbeveling met agile portfoliomanagement? Wij horen graag.

Article The evolution of agile frameworks

Nice to see that the Finnish magazine PROJEKTI Maailma 2 2022 posted my article The evolution of agile frameworks. The article reflects the keynote speech during 3PMO-tapahtuma 8.6.2022

Review The Professional Agile Leader

The professional agile leader – The leader’s journey toward growing mature agile teams and organizations by Ron Eringa, Kurt Bittner and Laurens Bonnema provides a detailed understanding of the leader’s role in an agile transformation.

When talking about reasons why so many agile transformations fail, I often show a picture of two rhinos colliding, and saying that this is the reason why. Next, I add two text boxes over the rhinos with company culture and agile culture. I can now refer to this book if you want an in-depth explanation of this clash.

The book is divided in eight chapters. the first chapter zooms in on the situation where you see yourself as an organization being overtaken by competitors. You may be very efficient but too unwieldy to respond quickly to the many changes that come your way. One solution is to take over another company that is already much more agile. This is also the case in the book where Reliable Energy takes over Energy Bridge and we follow the CEO who wants to make her organization more agile.

The second chapter shows what it means to form empowering cross-functional teams who discovered their purpose and the role of the leader. Key is that the teams must form themselves and that this takes time.

In the third chapter the emphasis is on the impact. Forget output but focus on the impact by framing goals in terms of customer outcomes instead of things that are produces. From plan-driven goals to goal-driven planning (tactical – intermediate – strategic goals).

Chapter four shows how teams and their leaders are changing by becoming more feedback driven. This is all about decision latency, levels of delegation, decentralized decision-making, and intrinsic motivation.

In chapter five we see the issues leaders are facing when they are halfway their agile transformation. This refers back to the clash between the rhinos at the start of this review. The original way of working with checks and balances versus the agile mind mindset and what that means to the people involved. Self-managing teams require leaders with a catalytic leadership style (collective focus: sharing, enabling, diversity, acceptance and supportive).

Chapter six shows that in an agile organization less and less hierarchical leaders are needed but all the more agile leaders. Where leadership should be seen as an activity and not a role. How to grow new leaders, how to grow mature teams and to escape the silos by breaking them down.

In chapter seven the authors explain that Kotter’s dual operating system cannot be used for ever. At a certain point you must decide to fully go for the agile way otherwise you will fall back to the old ways of working. I am not sure if this is what Kotter has in mind with his dual operating system.

The final chapter puts the agile culture in the spotlights. The social behavior and norms that people in the organization exhibit, including their beliefs and habits. Without this agile culture your agile transformation will fail and be aware this transformation will never end.

Conclusion

a compact and easy to read book that explains the role of a leader in an agile transformation in a clear, straightforward, and practical way. the case used of a merger of two companies as a common thread makes very clear the issues and friction a leader faces in an agile transformation.

I missed the agile leader’s role in sharing knowledge and lessons learnt by setting up communities of practice (CoPs), chapters, guilds et cetera. The issues and what to do about them when multiple teams are necessary to work on a single product are presented very simplistically but this is probably beyond the scope of this book.

In my opinion an absolute must read if you are in the middle of or want to start an agile transformation.

To order: The Professional Agile Leader: managementboek.nlbol.com

Recensie Vakblad Projectmanagement en agilemanagement NR. 17 – 2022

Binnenkort verschijnt het 17e nummer van het vakblad projectmanagement en agilemanagement. De rode draad in dit nummer is leren. Leren van elkaar door de vele voorbeelden hoe anderen het doen of ervaren maar ook leren van de natuur.

In het redactioneel hoofdartikel Horen is vergeten, zien is onthouden, doen is begrijpen gaat Luuk Ketel in op de leercultuur binnen KWD. Delen van kennis zowel naar binnen (eigen medewerkers) als naar buiten (o.a. Dit vakblad, de KWD-boekenreeks en de jaarlijkse vakdag). En passant komt de vraag naar voren of projectmanagement nu wel of niet een vak is?

Luuk Ketel en Leo Klaver interviewen Hans van Griensven, luitenant-generaal (b.d.) over Opdracht Gerichte Commandovoering in het leger dat veel gelijkenissen met projectmanagement en agile werken in zich heeft. Uiteraard komt ook zijn visie op de missie in Afghanistan aan de orde. N.b. Vergelijk ook intent based leadership van de duikbootkapitein David Marquet in Turn the ship around). 

Vervolgens gaan Luuk Ketel en Leo Klaver in gesprek met Saskia van den Muijsenberg over Biomimicry en wat de projectmanager daarmee kan. Biomimicry staat voor: leren van de natuur. Als je kijkt naar het aanpassingsvermogen van de natuur, het rekening houden met elkaar, de processen en het innoveren dan liggen vergelijkingen met agile werken voor de hand.

Ronald Kappert gaat in zijn artikel Hoe staat het met Open Source software? in op het toepassen van (gratis) open source software in projecten aan de hand van een beperkte enquête onder ruim 50 projectmanagers. Waarom willen klanten juist wel of juist geen gebruik maken van open source software? Welke redenen hanteren projectmanagers zelf bij het actief inzetten van open source software. Daarnaast komen een aantal voorbeelden van open source software langs.

Bart van den Hooff geeft in De rol van gewoontegedrag bij het uitfaseren van legacy-systemen (legacy discontinuance) twee case studies bij een grote hypotheekverstrekker en een telecombedrijf. Er worden bij beide cases drie verschillende rollen van gewoontegedrag bij uitfaseren van legacy-systemen onderkend: als rem, als brug en als motivator. Iets waar projectmanagers zich bewust van moeten zijn om daar optimaal op in te kunnen spelen.

Harry Valkink en Giovanni Dhondt beschrijven in Veranderen op een agile manier: zelfde uitdagingen, andere oplossingen drie mythes uit hun boek De tien mythes van Agile werken: 1) er is geen planning nodig, 2) business cases en budgetten doen er niet meer toe, 3) de product owner bepaalt de prioriteit ten aanzien van de functionaliteit. Zie ook mijn recensie van De tien mythes.

In Certificeren van een team is geen gekke gedachte als het om veiligheid gaat legt Leo klaver een gesprek vast tussen Luuk Ketel, Roel Gloudemans en Ard van der Lee. Security anno 2022 gaat aanmerkelijk verder dan data en is niet alleen ict-gerelateerd. Wordt security wel altijd als belangrijk gezien? Wat kunnen teamleden van elkaar leren op het gebied van security? Wat betekent dit voor de projectmanager? Hoe neemt de projectmanager dit mee bij de opzet van zijn/haar project? Hoe borgt de projectmanager security kennis in het projectteam? Is certificering van het gehele team een oplossing? In het artikel worden ook een aantal vragen aan projectmanagers gesteld waarop je als lezer feedback kan geven zodat ook anderen van jullie ervaringen kunnen leren.

In het artikel Van Dev en Ops naar DevOps en DevSecOps vertellen André Pals en Luuk Ketel hoe ze als projectmanagers tegen DevOps aankijken. Kijkend naar het hebben van een continuous delivery pipeline met automated testing, continuous integration (CI) en continuous deployment (CD) en wat dat oplevert. Hulpmiddelen die enorm veel tijd besparen en het mogelijk maken om een of meerdere keren per dag iets in productie te nemen. N.b. Er zijn ondertussen verschillende DevOps trainingen en certificeringen, bijvoorbeeld die van DASA of SAFe DevOps. Verder niet in het artikel genoemd maar je ziet ondertussen ook bewegingen naar o.a. DevBusOps en DevDataOps.

Jos van der Heijden bespreekt in zijn artikel Hoe meet je opbrengsten en kosten van een agile project de huidige stand van zaken m.b.t. het meten van de werkelijke kosten en opbrengsten aan de hand van een intern onderzoek onder projectmanagers. En het antwoord is dat er nog veel te weinig wordt gemeten. Een gemiste kans om als organisatie te kunnen leren. KWD gaat onderzoeken of er een aanpak is op te zetten om kosten en opbrengsten van een agile project in kaart te brengen. Mensen die mee willen denken worden uitgenodigd. Nb. Interne uitkomsten zijn in lijn met mijn eigen verwachtingen. Benefits management was bij traditionele aanpakken al een zwakke plek in veel organisaties. De transitie naar agile werken vraagt al meer dan genoeg van het management om het te laten werken, dus de tijd om ook benefits/value management op te pakken krijgt nog niet de noodzakelijke prioriteit. Wellicht ter inspiratie voor het KWD onderzoek:

John Hermarij, in dit nummer de enige projectfilosoof, gaat in zijn column Jacht op certificaten in op het belang van het kunnen omgaan met het onverwachte. Iets waar geen certificaten voor te halen zijn maar wel bepalend is voor het succes van je project.

Tenslotte ook deze keer weer een recensie van mijn eigen hand. Deze keer bespreek ik het boek De cultuurladder – De sleutel tot een presterende organisatie, geschreven door Marcel van Wiggen, Gerard Vriens en Frits Galle. Veel bedrijven worstelen met de clash tussen de bestaande organisatiecultuur en de benodigde agile cultuur. De auteurs dragen een praktisch model aan om tot een gewenste organisatiecultuur te komen, dat ik heb samengevat in een quick reference card. 

ConclusieWeer een tijdschrift vol interessante artikelen waarmee je als projectmanager je voordeel kan doen. Ik leerde weer een aantal nieuwe termen zoals bijvoorbeeld biomimicry en kreeg nieuwe inzichten bij het omgaan van het uitfaseren van legacy-systemen, open source software, het effect van security op projectmanagement, en DevOps. Om nog meer van elkaar te kunnen leren zou de redactie in ieder blad een beperkt aantal vragen aan de lezers kunnen stellen. Wil je het volgende nummer ontvangen dan wordt verwacht dat je regelmatig de vragen beantwoordt. In het volgende nummer wordt dan de feedback samengevat.

Geen abonnee maar wel belangstelling voor het blad, en ik kan het van harte aanbevelen, dan is het online te lezen of in hardcopy voor abonnees die aan de doelgroep voldoen. Zie: KWD Resultaatmanagement.

Recensie Aan de slag met design thinking

Het boek Aan de slag met design thinking – met 20 creatieve technieken van Eveline van Zeeland beschrijft de bekende dubbele divergeren en convergeren diamant van design thinking met daarin de stappen empathize, design, ideate, prototype/test om van probleem naar oplossing te komen (een andere bekende maar hier niet beschreven aanpak is de spiraal). 

Het boek begint met een algemene beschrijving van design thinking en volgt vervolgens in vijf hoofdstukken de vijf stappen empathize, design, ideate, prototype en test. Aansluitend wordt de implementatie en de rapportage over het design thinking traject beschreven.

Binnen de verschillende stappen wordt een veelheid aan tools en technieken beschreven waaronder bullet journaal, frames, lotusbloementechniek, walking brainstorm, dot democracy, customer journey mapping, denkhoeden, empathy mapping, et cetera. Ook komen een groot aantal verschillende vormen van prototypes aan bod zoals wireframe, playmobiel, video prototyping, etc.

Ieder hoofdstuk wordt afgesloten met een overzichtsplaat en een aantal vragen om mee aan de slag te gaan. Het boek is verder doorspekt met quotes en fraaie foto’s. Daarnaast worden met QR-codes verdiepingen aangeboden. Grootste minpunt is het ontbreken van een voorbeeld dat als rode draad door alle stappen heenloopt.

Bestellen Aan de slag met design thinking: Managementboek.nlbol.com

Review PMO Services and capabilities

The book PMO Services and Capabilities – Including an overview of AIPMO’s competence framework – Competences per PMO service – Techniques and tools per PMO service is written by Robert Joslin. This book is unique as it addresses in a systematic and structured way for each PMO service including the associated attributes how to implement service to provide the right service to the right people at the right moment.

Each organizational unit is unique, each organizational unit needs its own set of PMO services.

The book is divided into two parts:

  • The first small part contains a high level overview of AIPMO’s services lifecycle framework (service strategy, service design, service pilot and implementation, service operations, service transform or retire) as part of AIPMO’s methodology on how to build and implement a PMO services and capabilities catalog
  • The second main part lists the PMO services that are in service groups and listed under the 22 service domains.

There are over 220 PMO services described in this book. The book is based on a three-level categorization system that allowed services to be grouped (service groups) with a service domain. A service domain is related to an area of experience. There are 22 service domains explained.

Each service domain is broken down into one to three service groups (in total approximately 60). A service group is related to one of the three main activity types that the PMO is expected to do:

  • Design – a PMO can provide the standards, tools, templates, processes, procedures, help, guidance, framework that defines how work will operate within that particular service domain
  • Operate – a PMO can operate (or perform) some of the work on behalf of other people within the project (program or portfolio) team. If the PMO does not perform this service then, if this is performed at all, then this will be done by another member of the project (program or portfolio) team
  • Monitor – a PMO can review the work done by others and provide and independent quality assessment and check. They can provide reporting across the service domain and highlight items that require escalation.

Not all of the PMO activities fall neatly into the 3 groupings. For some of the services activities are categorized in a more relevant way. This has been done for ease of comprehension as it fits more naturally into how the service domain operates.

The 22 service domains explained in the book are: integration management, stakeholder management, communications management, governance, frameworks and methodologies management, PPM tools management, consultancy, portfolio management, benefits management, financial management, schedule management, risk management, quality management, supplier management, capability and capacity management, configuration management, change management, issue management, administrative management, innovation management, knowledge management and PMO self-development.

To give an example for the portfolio management service domain, its domain services and services.

Within each service group there are one or more services. A service is the lowest level of offering that a PMO can provide. The service domains are grouped into four clusters (conceptualization, planning, execution and safeguarding the future).

Each service has 2 audiences:

  • The PMO How the service should be performed and some hints and tips that the PMO should consider when performing the service.
  • The customer Why do you want to get this service, what would you expect to be delivered from this service, and why would you benefit.

For each service you get a description, what it provides for the customer, why is it being offered to the customer, SIPOC (Supplier, Input, Process, Output and Customer), demand triggers, measurement indicators, tips and tricks, needed capabilities (organizational enabler capabilities, personal capabilities, service domain capabilities, techniques, tools) and references to related services. Each service ends with suggestions for further reading.

Conclusion: I have never seen such a complete overview of PMO services for a single PMO. 1,7 kg heavy, 22 service domains with in total 60 service groups and more than 220 services. On the other hand, it isn’t complete. For sure there will be PMO’s offering services that are not explained in this book. New developments take place. E.g. the rise of Value Management Offices with their own specific services. But this is something the author mentions too and solutions to cover this will be offered in the near future. The book is structured as a reference work and will bring a lot of value for those involved in PMO’s. If you are involved in a PMO setting this is definitely a must have. 

The only struggle I have is to find the place where a service is explained. Table 2.1 shows the service group mapping, but the services themselves aren’t mentioned. I would suggest replacing the domain number with the chapter number used in part 2 where all the services are explained. See also my example regarding portfolio management.

I am looking forward to some other titles AIPMO is preparing. E.g. Project, Program, Portfolio, and PMO Competences Frameworks: Designing for Successful Outcomes.

To order PMO Services and capabilities: bol.com, amazon

Recensie Projectmanagement en agile in de praktijk

Ed Schouten heeft met het boek  Projectmanagement en agile in de praktijk – Het beste van twee werelden, het zoveelste boek over projectmanagement en agile geschreven. Te weinig vernieuwend wat mij betreft.

Het boek bestaat uit vier, eigenlijk vijf delen. Eerst wordt de wereld van projecten verkend en worden de tien meest bekende faalfactoren van projecten besproken. Daarna komen de vier delen aan bod. 

Het eerste deel beschrijft het scannen, focussen en vormen om te komen tot een effectieve aanpak waarmee je het project opzet, uitvoert en afrondt. 

Deel II beschrijft de meer traditionele projectmanagementaanpak waarbij vooral gebruik gemaakt wordt van PRINCE2 en de fasering van het projectmodel van de ICB4 (projectvoorbereidingsfase, projectdefinitiefase, projectuitvoering en projectafsluiting).

Het derde deel beschrijft de agile aanpak in zijn algemeenheid en meer in bijzonder een aantal agile raamwerken zoals Scrum, LeSS, Nexus, spotify-model, SAFe, AgilePM en PRINCE2 Agile (Nb. Dank voor de verwijzing naar mijn eigen boek Scaling Agile in organisaties waarin ik onder andere deze methoden uitgebreid beschrijf).

In dit deel ook een paar pagina’s over de best of both worlds. Gegeven de ondertitel van het boek had ik hier een volledig deel over verwacht en dat had het boek onderscheidend kunnen maken.

Het laatste deel gaat over sociale vaardigheden voor projecten zoals communiceren, presenteren, overleggen en beslissen, leidinggeven en motiveren, samenwerken in een topteam, omgaan met tegengestelde belangen en het effectief omgaan met je tijd. Superbelangrijk als je een goed resultaat wilt neerzetten maar ook hierover is al zoveel geschreven.

Kortom te weinig vernieuwend, een gemiste kans om het beste van twee werelden handen en voeten te geven. Daarnaast heb ik een aantal keren mijn wenkbrauwen gefronst. Klopt het wel wat er staat. Een paar voorbeelden. Er worden een aantal faseringsmodellen gegeven waarbij de kwaliteit van de plaatjes ontoereikend is. Het figuur parallelle fasering is het verkeerde plaatje (kopie van lineaire fasering). Het plaatje versiefasering en de tekst sluiten niet op elkaar aan en het timeboxing plaatje suggereert dat je in een timebox eerst alles ontwerpt, vervolgens realiseert en uiteindelijk test. In de praktijk lever je op deze manier niets op. Het iteratieve van kleine stukjes ontwerpen, realiseren en testen ontbreekt in dit plaatje. Ook staat een aantal keer in het boek dat iedere sprint een Minimum Viable Product (MVP) oplevert. Dit is onjuist! 

Bestellen Projectmanagement en agile in de praktijk:  Managementboek.nlbol.com

Review Remote Team Interactions Workbook

The book Remote Team Interactions Workbook – Using Team Topologies Patterns for Remote Working written by Matthew Skelton and Manuel Pais explores several aspects of team-first remote work including highlighting poor team interactions, the usage of the team-API pattern to define and communicate the focus of teams, to remove team-level dependencies, to design inter-team communications and make use of the three team interaction modes from Team Topologies to help.

The book is divided in five chapters. The first chapter gives an overview of the mindset and skills you and your organisation will need to succeed in a remote-first world. The following chapters each describe techniques to track and manage inter-team relationships, to maintain high trust within teams and groups and to make the team interactions more purposeful. The final chapter focusses on some next steps to increase maturity of your remote team interactions.

The first chapter explores some of the techniques that can help organizations adopt an effective remote-first approach. But without good psychological safety and an effective set of “ground rules” and practices for teams for working together, the techniques will not help. Some of the discussed techniques are:

  • Cognitive load assessment
  • Use the team API approach to define and communicate responsibilities and team focus
  • Track dependencies using simple tools and remove blocking dependencies
  • Over-communicate using just enough written documentation.

The second chapter explores techniques to track and manage inter-team dependencies that work in a remote context. Starting point is the team API including the roadmap for  upcoming work as well as communication preferences (channels, time slots, response times). Besides an example you can download a Team API template. Tracking dependencies can be used to assess how dependencies should change (reduce, eliminate blocking ones, …). Final topic in this chapter is about building networks by using coffee, talks, CoPs, guilds and internal conferences.

The next chapter provides some techniques for maintaining high trust within teams and groups in a remote-first world based on group size. How much trust can exist within groupings od a certain size? The anthropologist Robin Dunbar found that the size of physical and online social networks where people can have meaningful relationships is in the order of 150 people. Dunbar sees the following trust boundaries: 5, 15, 5,0, 150 and 500 people. For online spaces (chat tools, documentation tools) these trust boundaries are applicable too. Make sure that each online space grouping should have people with a shared focus on a related flow of change. When using chat tools agree on team-focussed conventions (e.g., channel names).

Chapter four explains some techniques to help make the team interactions more purposeful (whether remote or in person), including detecting ineffective team interaction modes (collaboration, X-as-a-service, facilitating). To be effective, it is essential for the purpose and channel of any communication to be clear and obvious (team-specific channels, community channels, topic channels).

The final chapter gives some suggestions for further activities and patterns to make remote-first, team-centric work as effective as possible:

  • Setup an internal platform survey
  • Define and validate a set of user personas for developers and other engineers
  • Define naming and usage conventions for chat tools
  • Use the team API with multiple teams to define and clarify team boundaries
  • Devise and share an execution plan.

Conclusion 

This book contains lots of examples and hands on material to use Team Topologies patterns for remote working. It describes techniques to track and manage inter-team relationships, to maintain high trust within teams and groups and to make the team interactions more purposeful. It’s a workbook. On several places you find the header ‘Now your turn’ where you get instructions and templates to look at your own situation. It helps you to bring the Team Topologies book into practice within a remote working environment. 

To order Remote Team Interactions Workbook: bol.com

Recensie Vakblad Projectmanagement en agilemanagement NR. 16 – 2022

Volgende maand verschijnt alweer het 16e nummer van het vakblad Projectmanagement en agilemanagement. De rode draad door dit nummer is standaard of maatwerksoftware. Waneer wel, wanneer niet en hoe ga je daar dan als projectmanager mee om. De artikelen betreffen veelal interviews. 

In het redactionele hoofdartikel beschouwt Luuk Ketel de inhoud van dit nummer en gaat in op het hergebruik (re-use) van software en de voor en nadelen van het implementeren en gebruiken van standaard pakketten. Dat doet mij denken aan een al oud maar veel gebruikt principe “Repair before Reuse before Buy before Build”.

In het artikel Modularisering van het IT-landschap: Van rigiditeit naar wendbaarheid houdt Bart van den Hooff een pleidooi voor een gelaagde architectuur, waarbij de kern van de architectuur standaardfuncties zoals Finance en HR middels ERP-achtige systemen afdekken. Aan de ‘buitenkant’ van zo’n architectuur vinden we vaak de modularisering. Hier zijn flexibiliteit en wendbaarheid de leidende principes. Het gaat hier om de processen die concurrentievoordeel opleveren, waarbij snelle aanpassing aan veranderende vereisten uit de omgeving cruciaal is. Hierbij zal vaak gebruik gemaakt worden van cloud platformen om de standaard binnenkant met de flexibele buitenkant te koppelen. 

Peter Storm doet een oproep aan projectmanagers: doe onderzoek naar faalfactoren in de praktijk en deel deze. Het percentage falende projecten daalt nauwelijks. De lijst van top-tien faalfactoren verandert weinig. Hoe kan dat? Overal waar men erin slaagt om die lerende aanpak te koppelen aan de ontwerpende aanpak zal men aanzienlijke verbeteringen kunnen bereiken in het managen van projecten.

Luuk Ketel en Leo Klaver hebben Lucas Jellema, CTO bij AMIS, geïnterviewd. In dit interview gaat Lucas in op het gebruik van standaard en maatwerksoftware en welke rol de projectmanager daarbij speelt. Denk hierbij aan het betrekken van architectuur, het specificeren en het gebruik van de DoR en DoD, de ToC waarbij juist ook de operationele kosten helder moeten zijn.

Deze keer hebben Luuk Ketel en Leo Klaver mij ook geïnterviewd naar aanleiding van mijn opmerking bij de recensie van het vorige nummer over modellen. Ik heb al meer dan 150 modellen zien langskomen die door projectmanagers kunnen worden gebruikt in (agile)projecten. En het houdt hierbij niet op. In het interview wordt verder ingegaan op het waarom en het nut van al die modellen en wat de toekomst gaat brengen.

Jaap Stoppels bespreekt het artikel: ‘Projectmanagement, governance, and the normalization of deviance’ geschreven door Jeffrey K. Pinto. Het gaat over ethiek en cultuur in organisaties met de gevolgen daarvan voor projectresultaat. ‘The unexpected becomes the expected, which becomes the accepted’ ofwel, wat te doen als overtreding de norm wordt. Geïnstitutionaliseerde overtreding rond projecten komt vooral voor bij te rooskleurige projectvoorstellen, in de samenwerking tussen klant en leverancier en pessimistische projectplanningen. Afsluitend worden een aantal oplossingen aangedragen om hier wat aan te doen.

Het volgende artikel geeft een gesprek weer met Karel de IT-projectmanager binnen KWD, die zojuist een pakketimplementatie heeft afgerond en binnenkort begint met een nieuwe implementatie. In het artikel worden een aantal agile technieken en werkwijzen toegepast bij een pakketimplementatie. M.i. wordt in dit artikel het begrip MVP niet correct gebruikt. Een MVP gebruik je om een hypothese te toetsen. Hierbij wordt een minimale inspanning geleverd zodat zo snel en goedkoop mogelijk kan worden vastgesteld of de hypothese correct is. Daar waar in dit artikel MVP staat had beter MMP kunnen staan. Het Minimum Marketable Product is het kleinste (deel)product dat waarde oplevert voor de klant.

Leo Klaver interviewt Peter Storm, emeritus-hoogleraar Projectmanagement over zijn vak en zijn specialisme: Projectmanagement. ‘Soms vergeten we de essentie van projectmanagement: het managen van transformaties’, zegt Peter Storm die als redactielid afscheid neemt en nu echt met pensioen gaat. Peter ziet zichzelf als een projectfluisteraar. Hij probeert te onderzoeken wat er aan de hand is met een project door daar contact mee te maken. Hij kan binnen drie minuten een ernstige omissie in een projectplan aanwijzen. Wat kan risicomanagement hier betekenen en speelt de keuze voor agile of waterval hier ook een rol of is dit niet altijd een keuze? 

Ruud de Gast, Delivery manager bij Low Code Company, is door Luuk Ketel en Leo Klaver geïnterviewd over de trends in het land van maatwerksoftware en wat de betekenis is van deze trends voor projectmanagement en -manager. Een dominante trend kwam naar voren: Low Code. Laat u zich daarbij niet misleiden door het woordje ‘Low’, onder de motorkap van deze software-ontwikkeltaal gebeurt veel. Ik zou het een 5e of 6e generatie ontwikkeltaal noemen. ‘Few Code’ had wellicht een betere benaming geweest daar je met Low Code maar weinig regels hoeft te schrijven om een werkende applicatie te ontwikkelen. Het interview laat zien wat Low Code en het Low Code Platform Mendix is. Wat mij betreft wordt het wel heel rooskleurig voorgesteld (bijna een advertorial, de interviewers hadden wat kritischer mogen wezen). Voor dat je het weet laat je middels Low Code een maatwerk-applicatie ontwikkelen terwijl een standaardpakket volstaat. Dat de meeste bedrijven unieke processen moeten hebben gaat er bij mij niet in. Zie ook de visie van Karel in het laatste artikel.

John Hermarij, de laatst overgebleven projectfilosoof, borduurt deze keer in zijn column voort op de de definitie van een project ‘een tijdelijke onderneming met een uniek eindresultaat’. Hij stelt dat die de lading de vlag niet meer dekt. Moet het uniek zijn of juist niet uniek maar eerder complex en/of gecompliceerd?

Met het artikel Welke beïnvloedingstrategie leidt tot gewenst projectresultaat? geven Jonne Tillema en Erik van Daalen een aantal praktische handvatten om volgzaamheid te laten ontstaan i.p.v. weerstand voor het resultaat dat behaald moet worden. Wees je bewust van de sociale omgeving waarin je als projectmanager verkeert. Die omgeving is van invloed op het resultaat dat je in je project wilt bereiken. twee factoren die vormend zijn voor sociale omgevingen van gebruikers: gevoel voor noodzaak en de machtsverdeling, worden toegelicht. Vervolgens worden een vijftal strategieën besproken die afhankelijk van de sociale omgeving kunnen worden toegepast (macht strategie, planmatige strategie, onderhandelingsstrategie, programmatische strategie en interactieve strategie).

In het laatste artikel Wat maakt uw bedrijf zo uniek? komt Karel weer aan het woord. Karel de IT-projectmanager heeft net twee weken besteed aan het opstarten van zijn nieuwe opdracht, het implementeren van een nieuw standaard softwarepakket. Hij gaat de discussie met de opdrachtgever aan. Als iedere klant zijn eigen proces krijgt kan er geen sprake zijn van standaardisatie en blijven de operationele kosten hoog. Hij wil weten wat Vooruit BV naar eigen zeggen zo uniek maakt? Is er echt maatwerksoftware nodig? Kunnen de basisprocessen niet gestandaardiseerd worden en daaromheen flexibiliteit creëren om klantwensen tegemoet te komen?

ConclusieWeer een tijdschrift vol interessante artikelen. Interessante beschouwingen over het wel of juist niet gebruiken van standaard of maatwerksoftware en hoe de projectmanager daarmee om kan gaan. Ook worden er weer een aantal praktische handvatten voor de projectmanager gegeven.

Geen abonnee maar wel belangstelling voor het blad, en ik kan het van harte aanbevelen, dan is het online te lezen of in hardcopy voor abonnees die aan de doelgroep voldoen. Zie: KWD Resultaatmanagement.