Lernen aus Projekten

Projek­te sind Ver­än­de­rung. Mit Pro­jek­ten betre­ten wir Neu­land. Inhalt­lich sowie­so, aber ganz oft auch metho­disch. Nie­mand soll­te also anneh­men, dass Pro­jek­te ohne klei­ne­re oder grö­ße­re Irr­we­ge ablau­fen. Kei­ne ein­fa­che Erkennt­nis gera­de für Unter­neh­men, deren Wert­schöp­fung zu einem gro­ßen Teil auf mög­lichst feh­ler­frei­er Pro­duk­ti­on basiert. Wer Pro­jek­te in ein Null-Feh­ler-Kor­sett zwängt, darf sich nicht wun­dern, dass sowohl die Ergeb­nis­se als auch der Weg zu die­sen wenig inno­va­tiv sind. Eine posi­ti­ve Feh­ler­kul­tur ist zwin­gend not­wen­dig für inno­va­ti­ve Ergeb­nis­se und inno­va­ti­ves Vor­ge­hen, muss aber unbe­dingt ein insti­tu­tio­na­lier­tes Ler­nen aus die­sen Feh­lern beinhalten.

The­re is a belief in the com­pa­ny that if you don’t fail often enough, you’re not try­ing hard enough.
Gopi Kal­lay­il, Chief Evan­ge­list bei Google

Inno­va­tio­nen set­zen das Zulas­sen oder sogar das Her­aus­for­dern von Feh­lern vor­aus. Umge­kehrt wird aber noch kein Pro­jekt und Unter­neh­men inno­va­tiv, weil es Feh­ler machen darf und macht. Im Gegen­teil. Es müs­sen schon die rich­ti­gen Feh­ler sein. Wobei schon Feh­ler im Sin­ne einer Abwei­chung von einem Soll­zu­stand gar nicht das rich­ti­ge Wort ist, son­dern wir im Kon­text von Inno­va­tio­nen und Pro­jek­ten lie­ber von Irr­tü­mern reden soll­ten, wie Mark Pop­pen­borg auf intrinsify.me kor­rekt anmerkt.

Irr­tü­mer zum Zweck der Inno­va­ti­on zu for­dern und zu för­dern ist das eine, den maxi­ma­len Nut­zen als Indi­vi­dueen und als Orga­ni­sa­ti­on aus die­sen zu zie­hen aber etwas ganz ande­res. Wo vie­le Pro­jek­te durch­ge­führt wer­den – und das ist heu­te in immer mehr Unter­neh­men in immer grö­ße­ren Umfang der Fall – gibt es viel zu ler­nen. Oder bes­ser gesagt: es gäbe viel zu lernen.

Lear­ning is not com­pul­so­ry… neither is survival.
W. Edwards Deming

Oft erschöpft sich das Ler­nen näm­lich aus halb­her­zi­gen Les­sons Lear­ned weit nach dem Ende des Pro­jekts, bei dem dann nur ein Teil des Teams und der übri­gen Stake­hol­der teil­nimmt, weil alle schon längst im nächs­ten Pro­jekt sind. Dabei geht es dann doch wie­der nur um das was schief gelau­fen ist und was man das nächs­te mal ver­mei­den will. Oder was man wie­der genau so machen will und ande­re auch genau so machen sol­len. Und schon sind wir bei den berüch­tig­ten Best-Prac­ti­ces.

Die Erkennt­nis­se aus den Pro­jek­ten wer­den zu sel­ten sys­te­ma­tisch erfasst und auf­be­rei­tet. Meis­tens gibt es über­haupt kei­ne Orga­ni­sa­ti­ons­ein­heit die sich dafür wirk­lich zustän­dig fühlt. Und wenn doch, dann ist die­se eher im Qua­li­täts­ma­nage­ment ange­sie­delt und führt mehr oder weni­ger for­ma­le Audits durch. Das gibt dann eine Bewer­tung des ein­zel­nen Pro­jekts und viel­leicht noch eine Kenn­zah­len-Über­sicht über den Zustand aller Pro­jek­te im Unternehmen.

Was oft fehlt oder im Tages­ge­schäft nicht mög­lich ist die qua­li­fi­zier­te Auf­be­rei­tung der Erkennt­nis­se aus der Viel­zahl der Pro­jek­te. Ein Schär­fen der Säge ist nicht vor­ge­se­hen, es muss gesägt wer­den. Viel­leicht wären die Erkennt­nis­se einer Gesamt­schau auch unbe­quem bis ernüch­ternd. Viel­leicht wür­de man Defi­zi­te in der Orga­ni­sa­ti­ons­struk­tur des Unter­neh­mes erken­nen oder im Pro­zess der Prio­ri­sie­rung von Pro­jek­ten. Und wer will das schon?