Experimente statt Einheitsbrei

Wo vie­le Pro­jek­te durch­ge­führt wer­den, ent­steht schnell ein gewis­ser Drang zur Ver­ein­heit­li­chung der Metho­dik. Der Wunsch nach wie­der­hol­bar guten Pro­jek­ten ist auch ver­ständ­lich, Stan­dar­di­sie­rung und Patent­re­zep­te garan­tie­ren aber maxi­mal Mit­tel­mä­ßig­keit. Aus Tüten­sup­pe wird eben kein Fünf-Ster­ne-Menü. Das reicht viel­leicht für das klei­ne Pro­jekt zwi­schen­durch, aber nicht für die kom­ple­xen Her­aus­for­de­run­gen unse­rer Zeit. Pro­jekt­ma­nage­ment braucht Frei­raum für Expe­ri­men­te, Adap­ti­on und Varia­ti­on statt iso-zer­ti­fi­zier­tem Einheitsbrei.

Es muss ja nicht jeder das Rad neu erfin­den. So lau­tet das Cre­do der zwang­haf­ten Stan­dar­di­sie­rer. Als gäbe es für alles einen ein­zi­gen bes­ten Weg zum Ziel. Und doch wur­de gera­de das Rad in den letz­ten Jahr­tau­sen­den immer und immer wie­der neu erfun­den, ver­bes­sert und für ver­schie­de­ne Ein­satz­ge­bie­te adap­tiert. Ver­bes­se­rung muss den Stan­dard in Fra­ge stel­len. Oder umge­kehrt: Rigi­de Stan­dards ver­hin­dern Verbesserung.

For every com­plex pro­blem the­re is an ans­wer that is clear, simp­le, and wrong.
H. L. Mencken

Das bedeu­tet nicht, dass jeder per­ma­nent alles in Fra­ge stel­len soll. Selbst­ver­ständ­lich muss berück­sich­tigt wer­den, was in einem ähn­li­chen Kon­text bereits funk­tio­niert hat. Wenn bereits gute Räder für Kies­we­ge exis­tie­ren, muss man sie wirk­lich nicht neu erfin­den. Dem Griff in den Metho­den­bau­kas­ten vor­an geht also eine Bestim­mung der Situa­ti­on. Somit kann es auch nie den einen rich­ti­gen Stan­dard und den einen rich­ti­gen Satz an Metho­den geben. Metho­den müs­sen viel­mehr immer im Kon­text ihrer Ent­ste­hung und bis­he­ri­gen Ver­wen­dung gese­hen wer­den.

Wer als Werk­zeug nur einen Ham­mer hat, sieht in jedem Pro­blem einen Nagel.
Paul Watz­la­wick

Metho­den­bau­käs­ten stel­len ein Ange­bot an Bewähr­tem dar, auf das auf­ge­setzt wer­den soll. Es ist aber stets zu prü­fen, ob die Metho­den noch auf die jewei­li­ge Situa­ti­on pas­sen. Besteht dar­an berech­tig­ter Zwei­fel, dür­fen und sol­len sie ihrem Sinn nach ange­passt wer­den. Die­se Adap­ti­on und Varia­ti­on erfor­dert von den Han­deln­den Erfah­rung, um die Situa­ti­on rich­tig ein­zu­schät­zen. Mehr noch braucht es aber Mut, weil von Bewähr­tem abge­wi­chen wird und man sich damit angreif­bar macht. Wer mit Bewähr­tem schei­tert, kann sich zum Opfer der Umstän­de sti­li­sie­ren (die er frei­lich nicht erkannt und sein Han­deln ent­spre­chend ange­passt hat); wer aber auf­grund sei­ner Ein­sicht einen neu­en Weg ein­schlägt und dabei schei­tert, muss sich für die Abwei­chung recht­fer­ti­gen (jeden­falls in einer nega­ti­ven Feh­ler­kul­tur die geprägt ist von Angst und Schuld).

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

Die Kunst besteht nun dar­in, die Varia­tio­nen zu erken­nen und wie­der in den gemein­sa­men Metho­den­fun­dus zurück­zu­füh­ren. Nie­mals dür­fen Stan­dards nur als Vor­ga­be einer zen­tra­len Gover­nan­ce-Abtei­lung gese­hen wer­den, die kraft höhe­rer Ein­sicht die­sen einen Weg der Pro­jekt­durch­füh­rung in Stein gemei­ßelt hat. Wenn es die­ser zen­tra­len Abtei­lung über­haupt bedarf, dann nur um den Metho­den­bau­kas­ten leben­dig zu erhal­ten. Die Haupt­auf­ga­be bestün­de also weni­ger dar­in, abs­trak­te Vor­ga­ben zu machen und ihre iso-kon­for­me Ein­hal­tung zu kon­trol­lie­ren, son­dern viel­mehr im Com­mu­ni­ty-Manage­ment und Know­ledge-Manage­ment: Aus einer hohen Ver­net­zung der Han­deln­den in den Pro­jek­ten eine Kul­tur des offe­nen Aus­tauschs auf­bau­en und so das Wis­sen und die Erfah­rung an zen­tra­ler Stel­le für alle gut ver­füg­bar machen.