Det fascinerer mig til stadighed, hvordan serviceorganisationer implicit sætter lighedstegn mellem forandring og projekter. Antallet og omfanget af fortløbende projekter bliver synonym med, hvor forandringsvillig og forbedringsfokuseret organisationen er, og anseelige ressourcer bliver allokeret til at uddanne projektledere, søsætte og fortløbende kontrollere og lede projekter.

Traditionelt set forløber projekter således, at man starter i en planlægningsfase, hvor projektforløbet bliver kortlagt i eksempelvis et GANTT chart. Dette er køreplanen for projektet, og hver opgave i projektet bliver udført i henhold til ’milestones’ i planen. Planen kommer også til at virke som en pejlepind for, om vi ’på ret kurs’ eller ej, og successmålet er ofte, om vi overholder de deadlines, der er lagt ind i planen. Man starter altså med at planlægge og designe projektforløbet, hvorefter projektet eksekveres og måles/kontrolleres. Sidst men ikke mindst afsluttes projektet.

Forandringsprocessen starter således med planlægning, og her opstår – fra et systemisk perspektiv – et ganske interessant skisma. Dette første trin i forandringsprocessen antager nemlig implicit, at man 1) har indsigt i, hvilket problem, man prøver at løse, og 2) har indsigt i, hvad den rette løsning på problemet er.

Første gang jeg mødte John Seddon husker jeg, at han sagde til mig: ”Kristian, remember that you don’t know, what you don’t know”. Hvis du antager, at du står over for en problemstilling og designer løsninger på baggrund af ufuldstændig viden, risikerer du at handle på baggrund af en viden, du ikke er bevidst om ikke at kende til. Dette kan føre til omkostningstunge konsekvenser for en projektorganisation. Det kan betyde, at løsningen ikke er den rigtige, hvilket kan gøre situationen værre eller i bedste tilfælde forblive den samme, og dermed være spild af projekt og resurser. Det kan også føre til, at projektet ikke rammer projektets deadline, at budgettet overskrides eller at projektets oprindelige omfang ikke nås. Disse er alle kendetegnende for en traditionelt tilgang til ledelse og organisering af projekter.

Hvis man erkender, at man ikke ved, hvad man ikke ved, så er det første man må lære, hvad man skal gøre, for at forstå, hvilket problem, man faktisk står over for. Chris Argyris kaldte dette for double-loop learning. Double-loop learning beskrives som et individs, en gruppes eller en organisations evne til at stille spørgsmålstegn ved de værdier, antagelser, forudsætninger og politikker, der ligger til grund for de handlinger, som fører til oplevede problemer (problem defineret som forskellen mellem forventet og faktisk udfald). Denne form for læring er fundamental i forhold til den normale single-loop learning, hvor der blot fokuseres på at modificere de handlinger, som fører til uhensigtsmæssige konsekvenser.

Single-loop learning i et projektmiljø er ofte karakteriseret ved at man ændrer budget, tidsplan eller omdefinerer omfang som svar på, at der er problemer med at overholde disse tre faktorer. Det kan være, at man fyrer projektlederen eller ændrer projektstaben. Hvis et projekt ikke beviseligt opnår de forventede resultater, rationaliseres dette bort, eller der fremstilles mål, der på den ene eller anden facon retfærdiggør projektets indsats.

Double-loop learning i et projektmiljø betyder, at man må forstå og udfordre de fundamentale antagelser, der ligger bag ved den måde, man designer og leder forandring som projekter – de antagelser, der fører til handlinger, som i sidste ende ofte fører til symptomer, som fx sprængt projektbudget, overskredne deadlines og begrænset omfang af det oprindelige scope for projektet.  Dette betyder i første omgang at udfordre opfattelsen af de problemer, som projekter sigter på at løse – er de virkelige problemer eller blot symptomer på mere fundamentale antagelser i projektorganisationen. Det betyder, at man udfordrer antagelsen om, at forandring kan planlægges, med et fast langsigtet mål, og have et fast budget, og det betyder, at man udfordrer den måde arbejdet i projektet forløber.

For at kunne opnå double-loop learning, er det første man må gøre at få viden. Mere specifikt, viden om det nuværende projektmiljø som et system.  En hurtig lakmus test på, om man har et problem, er at tage de sidste 10 afsluttede projekter og afdække, hvor mange, der blev afsluttet inden for tidsplanen, inden for budgettet, med det oprindelige scope og opnåede de oprindelige målsætninger. Hvis svarene på denne analyse er deprimerende, kan det være tid til lidt double-loop learning.

Forandring fra et systemisk perspektiv starter altid med at ’få viden’. Vi kalder dette for Check. Det drejer sig om at få viden om den nuværende organisation som et system. Check i sig selv har således ikke en prædefineret målsætning ud over ’at få viden om systemet’. Med viden om, hvad der foregår i systemet og hvorfor, har man det fornødne indsigt, der skal til for at kunne handle på systemet. Med andre ord, man ved det, som man før ikke vidste, man ikke vidste. Herefter kan man eksperimentere med design af et nyt system, men igen uden at sætte målsætninger og benchmarks ud over ’lad os lære at blive så gode som overhovedet muligt’. Resultatet af dette i et projektmiljø er altid hurtigere, billigere og mere effektiv levering af løsninger af organisationens virkelige problemer, og dette opnås ved at fokusere på rejsen – læringen om systemet – og ikke destinationen – prædefineret løsning.