Gedurende het grootste deel van zijn geschiedenis als formele discipline hield projectmanagement zich bezig met een afgebakend probleem: lever, gegeven een gedefinieerde scope, een vast budget en een afgesproken planning, het gespecificeerde product op. De competentie was er een van beheersing. Afwijking van het plan was de vijand, en het vakmanschap van de manager lag in het onderdrukken ervan. Dat model is niet verdwenen, en voor werk dat werkelijk afgebakend is blijft het deugdelijk. Wat wel is veranderd is het aandeel van betekenisvol werk dat aan die beschrijving voldoet. Organisaties besteden nu fors aan verandering waarvan de scope aan het begin niet te kennen is, waarvan de waarde afhangt van hoe mensen erop reageren, en waarvan het succes niet af te lezen valt van een gantt-diagram. Dit werk aansturen met de reflexen van scopebeheersing levert iets op dat erger is dan mislukking: het levert projecten op die op tijd klaar zijn en niets veranderen.

Verschillende drukfactoren zijn samengekomen om dit zichtbaar te maken. Digitaal werk heeft de afstand tussen een besluit en de gevolgen ervan verkort, waardoor een programma dat er drie jaar over doet om zijn eerste bruikbare increment op te leveren nu concurreert met partijen die per kwartaal iets uitbrengen. Besturen zijn sceptisch geworden over transformatie-uitgaven die geen rendement kunnen aantonen, en financiële functies vragen steeds vaker niet wat er is opgeleverd maar wat er in de cijfers is veranderd. Tegelijkertijd zijn agile-methoden, na zich op het niveau van een enkel team te hebben bewezen, opgeschaald naar de coördinatie van tientallen teams, vaak zonder de bijbehorende governance. Het resultaat is een wijdverbreide en ongemakkelijke toestand: organisaties die drukker dan ooit zijn met veranderinitiatieven, en minder overtuigd dan ooit dat de verandering ook daadwerkelijk aankomt.

Hier verdient het bijvoeglijk naamwoord in integraal project- en programmamanagement zijn plaats. Het werk van levering laat zich niet netjes scheiden van de strategie die het dient, het operating model waarin het moet landen, of de mensen wier gedrag moet veranderen wil er enige baat ontstaan. Levering behandelen als een op zichzelf staande technische functie, die een scope krijgt aangereikt en gevraagd wordt die uit te voeren, is precies de gewoonte die kostbare irrelevantie voortbrengt. Een integrale benadering houdt de strategische intentie, de verandering in werkwijzen en de mechaniek van levering in één kader, en weigert toe te staan dat een ervan wordt geoptimaliseerd ten koste van de andere. Het verantwoordelijkheidsgebied van de manager is daarom breder dan het plan; het loopt van de doelstelling die de onderneming nastreeft tot het moment waarop die doelstelling meetbaar wordt gehaald.

De verschuiving is dan ook die van levering als een daad van productie naar levering als een daad van overtuiging en bijsturing. Een programma is niet langer een machine die requirements omzet in producten; het is een argument, voortdurend getoetst, over hoe een reeks investeringen het gedrag van klanten, medewerkers en systemen zal veranderen. Dit is geen verzachting van de discipline. Het is een verharding ervan, want een uitkomst is een veel veeleisender iets om verantwoording over af te leggen dan een product. Iedereen kan bevestigen dat een systeem live is gegaan. Veel minderen zijn bereid achter de bewering te staan dat het de moeite van het bouwen waard was.

Een project levert een product; een programma levert een uitkomst. Het onderscheid is er niet een van omvang. Een project is een tijdelijke inspanning die een gedefinieerd resultaat voortbrengt: een systeem, een migratie, een heringericht proces. Het wordt beoordeeld op scope, kosten en tijd, en het kan volledig geslaagd zijn terwijl het niets van betekenis bereikt. Een programma is een gecoördineerde set projecten en veranderactiviteiten die wordt ondernomen om een strategische uitkomst tot stand te brengen die geen enkel project alleen kan leveren. Zijn munteenheid is niet het resultaat maar de verandering in de toestand van de organisatie. Beide verwarren is de meest voorkomende categoriefout in het vakgebied, en het is kostbaar, omdat het ertoe leidt dat men een programma bestuurt alsof het een groot project is, waarbij men optimaliseert voor de voltooiing van onderdelen terwijl het geheel wegdrijft van de bedoeling.

Baten zijn de rekeneenheid. Een baat is een meetbare verbetering die een belanghebbende de moeite waard acht: lagere kosten om te bedienen, kortere tijd tot een besluit, minder verloop, hogere conversie. Resultaten zijn slechts het middel waarmee baten mogelijk worden; op zichzelf brengen ze geen baten voort. Een nieuw platform maakt een sneller proces mogelijk, maar de besparing wordt pas gerealiseerd wanneer het oude proces wordt afgeschaft en mensen daadwerkelijk op de nieuwe manier werken. Deze kloof, tussen de geleverde capaciteit en de gerealiseerde baat, is waar de meeste waarde verloren gaat, en het is precies de ruimte die een programma bestaat om te managen. Een programma aan zijn baten houden betekent erop staan dat iemand verantwoordelijk blijft over die kloof heen.

Governance is het toewijzen van beslissingsbevoegdheden, niet het inplannen van vergaderingen. Het doel van een stuurgroep is het nemen van de besluiten die individuele projectmanagers niet kunnen nemen: herprioriteren, stopzetten, financieren, risico aanvaarden namens de organisatie. Een governance-inrichting die de voortgang beoordeelt maar geen koers kan wijzigen, is geen governance; het is toeschouwerschap. De toets van elk bestuur is eenvoudig en onverbiddelijk: welk besluit heeft het genomen dat anders niet zou zijn genomen, en had het de bevoegdheid om dat besluit te laten standhouden tegen de functionele belangen die het anders zouden willen. Waar die bevoegdheid ontbreekt, verhuizen de echte besluiten naar de wandelgangen en de zijgesprekken, en verdampt de verantwoording met hen mee.

Het plan is een hypothese, en het programma is het experiment. Een planning geeft uitdrukking aan een reeks overtuigingen over hoe het werk zich zal ontvouwen en hoe waarde zal oplopen. Die overtuigingen zijn vanaf de eerste dag in detail onjuist, en de discipline van levering bestaat er niet in het plan te verdedigen maar sneller van de afwijking te leren dan die afwijking zich opstapelt. Daarom moet de uitkomst, en niet het plan, het vaste punt zijn. Plannen zijn instrumenten die moeten worden herzien naarmate bewijs binnenkomt; de uitkomst is datgene wat die herziening dient. Een team dat het verschil niet kan zien, zal zijn planning verdedigen lang nadat de planning is opgehouden iets werkelijks te beschrijven.

Agile op schaal, en zijn ongemakken. Het afgelopen decennium hebben frameworks voor het coördineren van vele agile-teams zich ontwikkeld van nieuwigheid tot standaard in grote organisaties. Hun bijdrage is reëel: ze maken afhankelijkheden zichtbaar, synchroniseren de planning tussen teams, en verkorten het interval tussen intentie en werkende software. Hun risico is even reëel. Geschaalde agile kan, in nieuwe bewoordingen, precies de commandostructuren reproduceren die het moest vervangen, met kwartaalplanningsevenementen die functioneren als nauwelijks verhulde waterval-poorten en een backlog die eenvoudigweg een zeer lang requirementsdocument is geworden. De organisaties die er baat bij hebben zijn die welke de intentie overnemen, snellere feedback en gedecentraliseerde besluiten, in plaats van alleen de ceremonies.

Van projectfinanciering naar productfinanciering. Er voltrekt zich een stille maar ingrijpende verschuiving in de manier waarop verandering wordt gefinancierd. Het traditionele model financiert een project: een vast bedrag voor een vaste scope, uitbetaald tegen een businesscase die is geschreven toen het minst bekend was. Een groeiend aantal organisaties financiert nu in plaats daarvan duurzame teams rond een product of een dienst, waarbij capaciteit aan een uitkomst wordt toegewezen en in de loop van de tijd wordt bijgestuurd. Dit verandert de taak van de manager van het leveren van een scope naar het besturen van een stroom van waarde, en het lost het kunstmatige moment op waarop een project eindigt en de baten ervan stilletjes andermans probleem worden. Het dwingt ook een moeilijker gesprek over prioritering af, want een vast team moet worden verteld wat dit kwartaal het belangrijkst is in plaats van jaren geleden een afgesproken scope aangereikt te krijgen.

Batenmanagement wordt weer serieus genomen. Na jaren waarin batencases werden geschreven om goedkeuring te verkrijgen en nooit meer werden bekeken, beginnen besturen om bewijs van realisatie te vragen, niet louter van levering. Dit heeft een werkelijk lastig vak nieuw leven ingeblazen: het definiëren van maatstaven die toe te schrijven zijn, ze eerlijk baselinen, en ze volgen tot voorbij go-live in de periode waarin de waarde daadwerkelijk verschijnt. Serieus gedaan legt het ongemakkelijke waarheden bloot over welke investeringen zich terugbetaalden en welke niet, wat precies de reden is waarom het zo lang werd verwaarloosd. De organisaties die ermee volhouden ontwikkelen iets zeldzaams: een institutioneel geheugen van wat verandering werkelijk waard is.

De faciliterende programmaorganisatie. De PMO legt langzaam zijn reputatie als rapportagefabriek af. De nuttiger variant fungeert als een dienst aan de levering: het onderhoudt een waarheidsgetrouw beeld van afhankelijkheden en capaciteit, cureert standaarden die teams daadwerkelijk willen gebruiken, en geeft besluitvormers de analyse die ze nodig hebben om goed te kiezen. Het onderscheid tussen een organisatie die helpt en een die controleert is niet cosmetisch; het bepaalt of teams informatie naar het centrum leiden of er zorgvuldig omheen. Een organisatie die teams vertrouwen ontvangt slecht nieuws vroeg, terwijl er nog tijd is om ernaar te handelen.

Plaats beslissingsbevoegdheden waar de informatie is. De meest voorkomende structurele fout in een programma is een discrepantie tussen waar de kennis zit en waar de bevoegdheid zit. Besluiten die een gedetailleerd, actueel begrip vereisen drijven omhoog naar commissies die maandelijks vergaderen en het minste weten; besluiten die organisatorische bevoegdheid vereisen worden geduwd naar mensen die ze niet kunnen laten standhouden. Een deugdelijk ontwerp duwt routinekeuzes naar de teams die het dichtst bij het werk staan en reserveert voor het centrum alleen de besluiten die werkelijk een ondernemingsbrede blik vereisen: financiering, sequencing, en het aanvaarden van risico dat grenzen overschrijdt. Het doel is zo weinig mogelijk besluiten in het centrum te nemen, en die weinige besluitvaardig te nemen.

Ontwerp voor dunne plakken waarde. Een programma moet zo worden ingericht dat waarde kan worden geleverd en getoetst in de kleinste increments die het domein toelaat, in plaats van opgestapeld tot een enkele grote release. Dunne plakken zijn niet louter een leveringsgemak; ze zijn het mechanisme waarmee de uitkomsthypothese wordt getoetst aan de werkelijkheid terwijl er nog tijd en geld is om te reageren op wat wordt geleerd. Een programma dat achttien maanden lang geen bruikbaar increment kan voortbrengen is geen programma; het is een weddenschap, eenmaal geplaatst en laat afgerekend, op aannames die niemand kan corrigeren tot het geld op is.

Behandel afhankelijkheden als eersteklas objecten. In een portfolio van enige omvang is de bindende beperking zelden het werk binnen een team; het is de koppeling tussen teams. Afhankelijkheden die laat worden ontdekt worden de planning. Een ontwerp dat ze serieus neemt maakt ze vroeg expliciet, wijst ze eigenaren toe, en behandelt een onbeheerde teamoverstijgende afhankelijkheid als een risico van de eerste orde in plaats van een administratief detail. Veel van wat in grote programma's voor vertraging doorgaat is eenvoudigweg afhankelijkheid waarvoor niemand verantwoordelijk was totdat ze toesloeg, en het remedie is organisatorisch in plaats van technisch: iemand moet eigenaar zijn van de naad.

Beperk het werk in uitvoering op portfolioniveau. Organisaties beginnen gewoontegetrouw meer dan ze kunnen afmaken, vanuit de theorie dat beginnen gratis is. Dat is het niet. Elk initiatief dat loopt verbruikt aandacht, coördinatie en de schaarse tijd van de weinigen die de systemen begrijpen die ertoe doen. Een portfolio dat het aantal gelijktijdige programma's begrenst, en afmaakt voordat het begint, levert per jaar meer verandering dan een dat alles begint en weinig voltooit. De discipline is om nee te zeggen tegen goede ideeën, en ze expliciet uit te stellen in plaats van ze stilletjes uit te hongeren.

Governancetheater. Stuurgroepen die de status beoordelen zonder beslissingsbevoegdheden te bezitten, zodat de keuzes die ertoe doen elders worden genomen, later, en zonder verantwoording. De stukken zijn onberispelijk, de aanwezigheid is senior, en er wordt niets besloten. Het teken is dat geen enkele vergadering ooit het plan wijzigt; het bestuur bestaat om te worden geïnformeerd, en zijn leden verwarren geïnformeerd zijn met in control zijn. Programma's die op deze manier worden bestuurd falen niet luidruchtig. Ze drijven af, op kostbare wijze, terwijl iedereen die aanwezig is gelooft dat iemand anders stuurt, tot het geld op is en de evaluatie vaststelt dat er nooit één enkel besluit is genomen.

Productfixatie en de surrogaatbaat. Het programma rapporteert groen omdat zijn resultaten op schema liggen, en niemand merkt dat de resultaten nooit de bedoeling waren. Nauw verwant is de surrogaatbaat: een maatstaf die is gekozen omdat hij gemakkelijk te tellen is in plaats van omdat hij de uitkomst weerspiegelt, zodat het programma optimaliseert voor adoptiestatistieken of transactievolumes terwijl de waarde die de onderneming werkelijk wilde ongemeten en, vaak, ongerealiseerd blijft. Beide fouten delen een wortel, namelijk een gevestigde voorkeur voor het telbare boven het betekenisvolle, en beide laten iedereen succes rapporteren terwijl de uitkomst stilletjes uitblijft.

Afhankelijkheidsontkenning. Het plan van elk team is op zichzelf geloofwaardig en in combinatie onmogelijk, omdat de afhankelijkheden ertussen zijn vastgelegd als aannames in plaats van beheerd als toezeggingen. Het programma ontdekt dit bij de integratie, het duurst denkbare moment om het te leren, wanneer de speling al is verbruikt en de mensen die de koppeling hadden kunnen oplossen alweer aan ander werk zijn begonnen. Ontkenning is hier zelden bewust; het is het natuurlijke gevolg van teams die optimistisch en afzonderlijk plannen, en vervolgens hopen dat de naden zullen houden. Hoop is geen coördinatiemechanisme.

Portfoliovastloop en de controlerende organisatie. De organisatie begint meer dan ze kan afmaken, waardoor elk initiatief traag beweegt en de weinigen die de kritieke systemen begrijpen fractioneel over alle initiatieven zijn verdeeld. De voortgang stokt niet uit gebrek aan inspanning maar uit gebrek aan afmaken. Waar de programmaorganisatie hierop reageert door de rapportage aan te scherpen en naleving te eisen, wordt zij datgene waar teams omheen werken: informatie wordt vormgegeven voor de audit in plaats van voor het besluit, en het beeld dat het centrum van de werkelijkheid heeft wordt gestaag minder waar, zelfs terwijl zijn dashboards steeds uitvoeriger worden.

Wij beginnen elke opdracht met het vaststellen van de uitkomst en het bewijs dat die zou aantonen, voordat er enige discussie is over scope, methode of tooling. Dit betekent dat we samen met de verantwoordelijke bestuurder opschrijven wat meetbaar anders moet zijn wanneer het programma klaar is, en de baseline afspreken waartegen dat verschil zal worden beoordeeld. Het is weinig glamoureus werk, en het is waar de meeste uiteindelijke waarde óf wordt veiliggesteld óf verloren gaat. Een programma dat zijn beoogde uitkomst niet kan verwoorden in een zin die een bestuurslid zou herkennen is niet klaar om te beginnen, ongeacht de druk om te beginnen, en een van de nuttigere dingen die wij doen is weigeren het te starten totdat het dat wel kan.

Vervolgens ontwerpen wij de governance vóór de levering, omdat de vorm van de besluitvorming de vorm van al het overige bepaalt. Wij brengen in kaart wie welke beslissingsbevoegdheden bezit, zorgen ervoor dat de mensen met bevoegdheid ook toegang hebben tot de informatie, en verwijderen de lagen die alleen bestaan om te worden geïnformeerd. Wij verkiezen een klein aantal fora die daadwerkelijk kunnen besluiten boven een groot aantal dat louter rapporteert. Waar een organisatie al agile-teams heeft, werken wij met die structuur mee in plaats van ertegen, en voegen de teamoverstijgende coördinatie en batendiscipline toe die schaal vereist zonder de autonomie te smoren die teams in de eerste plaats effectief maakt. Waar traditionele planning werkelijk bij het werk past, gebruiken wij die zonder verontschuldiging.

Bij de levering sturen wij op flow en op baten, niet op een bevroren plan. Wij staan op dunne increments die werkende verandering vroeg aan echte gebruikers voorleggen, wij maken afhankelijkheden expliciet en van iemand, en wij beperken de hoeveelheid werk in uitvoering zodat het portfolio afmaakt wat het begint. Onze programmaorganisaties zijn gebouwd om de levering te dienen: om een waarheidsgetrouw beeld van afhankelijkheden, capaciteit en batenrealisatie bij te houden, en om besluitvormers de analyse te geven die ze nodig hebben in plaats van de naleving die ze best kunnen missen. Wanneer een maatstaf de verkeerde kant op beweegt, behandelen wij dat als informatie om naar te handelen, niet als een getal om weg te verklaren, en liever brengen wij in maand twee een ongemakkelijke waarheid aan het licht dan tot maand twintig een comfortabele fictie te verdedigen.

Gedurende het geheel houden wij het programma aan zijn uitkomst. Dat betekent bereid zijn de mensen die het werk hebben opgedragen te vertellen wanneer een stroom producten voortbrengt die de cijfers niet zullen bewegen, en die stroom te stoppen of om te buigen voordat er meer wordt uitgegeven. Het is altijd gemakkelijker een programma draaiende te houden dan het eerlijk te houden, en het tweede van die twee is de dienst die naar ons idee de moeite van het kopen waard is. Het is wat wij bedoelen wanneer wij ons werk als integraal in plaats van louter competent omschrijven.

Wat een programma dat de organisatie verandert scheidt van een dat haar louter bezighoudt is zelden de methode en bijna altijd de discipline om de uitkomst vast te houden terwijl al het overige mag bewegen. Wij brengen de senioriteit om het moeilijke gesprek met een bestuur aan te gaan, de analytische strengheid om te bepalen of baten reëel of nominaal zijn, en de leveringservaring om governance, afhankelijkheden en portfoliolimieten in de praktijk te laten werken in plaats van op papier. Wij zijn even goed thuis binnen een traditioneel planningsregime als binnen een geschaald agile-regime, omdat onze toewijding aan de verandering geldt, niet aan een framework, en wij de methode kiezen die het werk werkelijk nodig heeft in plaats van de methode die in de mode is.

Er is ook een praktisch uitvloeisel dat verandert wat het werk mag aannemen. Wanneer een opdracht een capaciteit vereist die nog niet bestaat, hoeft die niet te wachten op een inkoopcyclus of de roadmap van een leverancier. Het Nashua 360 Enterprise Platform is gebouwd om vrijwel elke functie in hoog tempo te accommoderen, via extreme vibe coding: wat nodig is wordt in gewone taal beschreven en snel gegenereerd, maar altijd binnen vaste architectuurprincipes en onder strenge kwaliteitsborging, zodat snelheid nooit ten koste gaat van samenhang, veiligheid of controle. Het effect is strategisch in plaats van louter praktisch. Het verschuift de make-or-buygrens, houdt optionaliteit goedkoop, en laat de architectuur de strategie volgen in plaats van dat de strategie zich plooit naar wat toevallig op de plank lag.

Het gevolg, voor de organisaties waarmee wij werken, is dat een programma verantwoordelijk wordt voor datgene wat het gefinancierd kreeg om te bereiken. Producten worden nog steeds geleverd, en goed geleverd, maar ze worden geleverd in dienst van een uitkomst die iemand kan meten en waarachter iemand kan staan, wat uiteindelijk de enige verdedigbare reden is om überhaupt een programma te draaien.