Testen met AIPreview
Open in TheBrain

Handleiding MKo - test 261001

Hieronder staat versie 0.1. Ik heb hem bewust geschreven als werkhandleiding: vijf pagina’s die je bij de start van vrijwel ieder project of werk naast je kunt leggen en daadwerkelijk kunt doorlopen. De onderliggende gedachte is jouw systeemgerichte werkwijze, maar zonder dat iemand eerst een theoretisch handboek hoeft te lezen.

BLAUWDRUK – OPSTARTEN EN BEHEERST REALISEREN VAN EEN PROJECT / WERK

Praktische handleiding | versie 0.1 | 260930

Doel

Deze blauwdruk helpt een projectteam om bij de start van een project of werk eerst gezamenlijk de opgave en het systeem te begrijpen, voordat oplossingen, documenten, planning en contractering leidend worden.

Hoofdregel

Eerst begrijpen → dan organiseren → dan specificeren → dan realiseren → aantonen → leren.

De centrale vraag gedurende het gehele project luidt:

Hoe organiseren wij dat de beoogde transformatie van de bestaande toestand (Tb) naar de gewenste toestand (Td), inclusief alle tijdelijke toestanden (Tt), aantoonbaar beheerst wordt voorbereid, gecontracteerd, gerealiseerd en overgedragen?

PAGINA 1 – BEGRIJP DE OPGAVE

1. Begin bij de bedoeling

Start niet met een planning, ontwerp, contract of aanbestedingsdocument.

Stel eerst gezamenlijk vast:

Waarom bestaat deze opgave?

Beantwoord minimaal:

Maak daarbij onderscheid tussen:

DOEL → FUNCTIE → OPLOSSING

Voorkom dat een reeds bedachte oplossing ongemerkt als projectdoel wordt beschouwd.

2. Definieer de transformatie

Beschrijf de opgave als:

Tb → Tt₁ → Tt₂ → … → Td

Waarbij:

Tb = bestaande toestand

Wat hebben we nu?

Td = gewenste toestand

Wat moet uiteindelijk functioneren?

Tt = tijdelijke toestand(en)

Welke tussenstadia ontstaan tijdens de realisatie?

Beschrijf Tb en Td zo veel mogelijk functioneel.

Vraag vervolgens:

Kan het systeem gedurende iedere tijdelijke toestand nog verantwoord functioneren?

Denk daarbij onder andere aan:

Een project is niet alleen succesvol wanneer Td goed functioneert.

Ook de weg Tb → Td moet beheerst zijn.

3. Bepaal wat succes betekent

Leg vóór verdere uitwerking vast:

Wanneer vinden wij dit project geslaagd?

Maak succes waar mogelijk aantoonbaar.

Niet alleen:

“Het werk is gereed.”

Maar bijvoorbeeld:

“Het systeem vervult de afgesproken functies, voldoet aantoonbaar aan de eisen, resterende risico's zijn geaccepteerd en beheer kan het systeem verantwoord overnemen.”

RESULTAAT PAGINA 1

Na pagina 1 moet het projectteam gezamenlijk kunnen uitleggen:

WAAROM → WAT → Tb → Tt → Td → WANNEER SUCCESVOL

STOP wanneer hierover geen gezamenlijk beeld bestaat.

PAGINA 2 – BEGRIJP HET SYSTEEM

4. Bepaal het System of Interest

Stel vast:

Wat beschouwen wij binnen deze opgave als het systeem dat wij veranderen?

Dit is het System of Interest (SoI).

Teken letterlijk een grens rond het SoI.

Vraag vervolgens:

5. Kijk vervolgens naar het System of Systems

Een project staat nooit op zichzelf.

Plaats het SoI daarom in zijn omgeving: het System of Systems (SoS).

Breng minimaal in beeld:

Vraag:

Waar is ons project afhankelijk van een systeem waarover wij zelf niet volledig beschikken of beslissen?

Juist daar ontstaan vaak belangrijke raakvlakken en risico's.

6. Zoek actief naar wat we nog niet zien

Maak een eerste inventarisatie van:

RISICO'S – KANSEN – RAAKVLAKKEN – AANNAMES – ONZEKERHEDEN

Beperk dit niet tot het eigen projectteam.

Vraag expliciet:

Wie kan iets zien wat wij zelf niet zien?

Betrek daarvoor bijvoorbeeld:

Een belangrijk uitgangspunt is:

Een onbekend risico wordt niet beheerst doordat het niet in het risicodossier staat.

Organiseer daarom tegenspraak.

7. Maak afhankelijkheden zichtbaar

Leg de belangrijkste relaties vast:

OBJECT ↔ FUNCTIE ↔ EIS ↔ RISICO ↔ ACTOR ↔ VERANTWOORDELIJKE

Hiermee ontstaat de eerste projectarchitectuur.

Het doel daarvan is niet een mooie plaat.

Het doel is zichtbaar maken:

wat met wat samenhangt en waar verlies van samenhang kan ontstaan.

RESULTAAT PAGINA 2

Het projectteam beschikt minimaal over:

SoI + systeemgrens + SoS + actoren + raakvlakken + risico's/kansen + onzekerheden.

STOP wanneer kritische systeemgrenzen, verantwoordelijkheden of raakvlakken onbekend zijn.

PAGINA 3 – ORGANISEER HET PROJECT

8. Organiseer verantwoordelijkheid vóór werkzaamheden

Voor ieder essentieel onderdeel moet duidelijk zijn:

WIE → DOET WAT → WANNEER → MET WELK MANDAAT → EN WELK BEWIJS

Maak onderscheid tussen onder andere:

Voorkom:

“Wij zijn er gezamenlijk verantwoordelijk voor.”

Gezamenlijke betrokkenheid mag nooit leiden tot onduidelijkheid over integrale verantwoordelijkheid.

9. Organiseer GO / STOP

Beantwoord voor iedere kritische systeemtoestand:

Wie mag besluiten dat we doorgaan?

Maar vooral:

Wie heeft het mandaat om STOP te zeggen?

Een STOP moet mogelijk zijn wanneer bijvoorbeeld:

De centrale governancevraag luidt:

Wie is gedurende iedere systeemtoestand integraal verantwoordelijk voor het aantoonbaar beheerst functioneren van het geheel, en wie heeft het mandaat om STOP te zeggen wanneer dit niet kan worden aangetoond?

10. Richt de besluitvorming in

Leg vooraf vast:

SIGNALEREN → BEOORDELEN → BESLUITEN → UITVOEREN → VERIFIËREN → VASTLEGGEN

Bepaal:

Daarmee ontstaat een gesloten regelkring.

RESULTAAT PAGINA 3

Voor ieder kritisch onderdeel is duidelijk:

eigenaar → verantwoordelijkheid → mandaat → besluit → bewijs → GO/STOP.

STOP wanneer verantwoordelijkheid bestaat zonder passend mandaat, of werkzaamheden plaatsvinden zonder duidelijke verantwoordelijkheid.

PAGINA 4 – VERTAAL DE OPGAVE NAAR BEHEERST WERK

11. Van bedoeling naar eisen

Werk systematisch:

BEHOEFTE → FUNCTIES → EISEN → OBJECTEN → WERKPAKKETTEN

Vraag bij iedere eis:

Voorkom eisen waarvan later niemand meer weet waarom ze bestaan.

12. Structureer het werk

Gebruik waar passend:

SBS – System Breakdown Structure

Wat vormt gezamenlijk het systeem?

WBS – Work Breakdown Structure

Welke werkzaamheden zijn nodig om de transformatie te realiseren?

Koppel vervolgens:

SBS ↔ WBS ↔ eisen ↔ risico's ↔ verantwoordelijkheden ↔ planning ↔ verificatie

Hierdoor wordt zichtbaar of onderdelen tussen organisaties, disciplines of werkpakketten verdwijnen.

13. Kies bewust wat je aan de markt vraagt

Bepaal vóór contractering:

Wat moet OG zelf organiseren en wat kan/mag ON organiseren?

Maak bewust onderscheid tussen:

Stel bij iedere overdracht van verantwoordelijkheid de vraag:

Heeft degene die verantwoordelijk wordt ook de informatie, tijd, middelen, bevoegdheden en contractuele ruimte om die verantwoordelijkheid daadwerkelijk te dragen?

14. Bepaal vooraf het bewijs

Niet achteraf vragen:

“Kunnen we aantonen dat het goed is?”

Maar vooraf:

“Welk bewijs willen we straks zien?”

Leg per kritisch onderdeel vast:

EIS → METHODE → MOMENT → VERANTWOORDELIJKE → BEWIJS → ACCEPTATIE

Denk aan:

RESULTAAT PAGINA 4

Er bestaat een aantoonbare lijn:

bedoeling → functie → eis → object → activiteit → verantwoordelijkheid → bewijs.

STOP wanneer werkzaamheden worden gestart terwijl niet duidelijk is wat uiteindelijk moet worden aangetoond.

PAGINA 5 – BEHEERS, BESLUIT EN LEER

15. Bestuur op systeemtoestanden

Beoordeel gedurende de realisatie niet uitsluitend:

“Liggen we op planning?”

Maar vooral:

“Is de actuele systeemtoestand aantoonbaar beheerst?”

Toets bij iedere belangrijke overgang:

Ttₙ → Ttₙ₊₁

minimaal:

Pas daarna:

GO → volgende systeemtoestand.

16. Beheers afwijkingen en wijzigingen

Iedere afwijking is informatie over het functioneren van het systeem.

Gebruik daarom:

SIGNALEREN → REGISTREREN → ANALYSEREN → OORZAAK → EFFECT → BESLUIT → MAATREGEL → VERIFIËREN → SLUITEN

Vraag niet alleen:

“Hoe lossen we dit probleem op?”

Maar ook:

“Waarom kon ons systeem dit probleem laten ontstaan?”

Daarmee verschuift verbeteren van symptoombestrijding naar systeemverbetering.

17. Draag aantoonbaar over

Een werk is niet gereed omdat de fysieke werkzaamheden zijn beëindigd.

Overdracht vindt plaats wanneer:

Pas dan:

Td = aantoonbaar bereikt.

18. Sluit de regelkring

Na afronding:

Wat dachten we?

↓

Wat gebeurde werkelijk?

↓

Waarom was er verschil?

↓

Wat hebben we geleerd?

↓

Wat veranderen we structureel?

↓

Waar leggen we dat vast?

↓

Hoe zorgen we dat een volgend project hiervan profiteert?

Een les die alleen in het hoofd van een medewerker zit, is nog geen organisatiekennis.

DE BLAUWDRUK IN ÉÉN REGEL

BEGRIJP → BEGRENS → ORGANISEER → SPECIFICEER → CONTRACTEER → REALISEER → VERIFIEER → BESLUIT → DRAAG OVER → LEER

Of nog compacter:

DENKEN → DOEN → AANTONEN → LEREN

De uiteindelijke toets voor ieder project of werk luidt:

Hebben wij aantoonbaar georganiseerd dat de beoogde transformatie Tb → Tt → Td gedurende de volledige levenscyclus beheerst kan plaatsvinden — inclusief de risico's die wij vandaag nog niet kennen?

Ik zou deze versie 0.1 eerst inhoudelijk als referentiebasis bevriezen en hem nog niet mooier of uitgebreider maken. De interessante volgende stap is daarna juist het omgekeerde: deze vijf pagina's terugbrengen tot één A3-projectarchitectuur, zodat jouw TheBrain-structuur en deze handleiding feitelijk twee weergaven van hetzelfde besturingssysteem worden.