Die Psychologie des IT-Projektmanagements

Wenn man IT-Pro­jek­te aus psy­cho­lo­gi­scher Sicht betrach­tet, dann scheint die ers­te und wich­tigs­te Fra­ge die nach der Bezie­hung zwi­schen Auf­trag­ge­ber und Auf­trag­neh­mer zu sein. Die­se Bezie­hung „trägt“ das Pro­jekt. Fragt man IT-Dienst­leis­ter nach den Erwar­tun­gen ihrer Auf­trag­ge­ber, dann lau­ten das am häu­figs­ten genann­te Stich­wort „Lösun­gen“, manch­mal ergänzt um die Adjek­ti­ve „schnel­le“, „fer­ti­ge“ oder „preis­wer­te“. Durch die Eigen­ar­ten der mensch­li­chen Kom­mu­ni­ka­ti­on ist aber kei­nes­wegs gesi­chert, dass der Auf­trag­neh­mer auch ver­stan­den hat, was der Auf­trag­ge­ber erwar­tet. Oft ist dies auch dem Auf­trag­ge­ber nicht ganz klar. Wenn dann noch der in der Pra­xis nicht unüb­li­che Umweg über Bera­ter hin­zu­kommt (der Auf­trag­ge­ber spricht mit sei­nem Bera­ter, und der Bera­ter beauf­tragt und steu­ert die Ent­wick­lung), kommt beim Ent­wick­ler mit eini­ger Sicher­heit etwas ganz ande­res an, als der Auf­trag­ge­ber gesagt hat.

IT-Bera­ter und oft auch Ent­wick­ler über­neh­men ganz bestimm­te Funk­tio­nen für den Auf­trag­ge­ber: Sie füh­ren nicht nur einen Auf­trag aus, son­dern sie hel­fen – manch­mal (a) bei der Klä­rung des­sen, was eigent­lich das Pro­blem ist, das es zu lösen gilt, und manch­mal (b) bei der Beant­wor­tung der Fra­ge, was die rich­ti­ge Lösung sei. Bei­des hat noch gar nichts mit der © eigent­li­chen Ent­wick­lung der Lösung zu tun. In allen drei Fäl­len wird eine Leis­tung erbracht, die man auch als „Hil­fe“ im eigent­li­chen Sin­ne des Wor­tes bezeich­nen könn­te.

Wenn es sich bei die­sen Leis­tun­gen tat­säch­lich um Hil­fe han­delt, dann, so lau­tet die Hypo­the­se die­ses Tex­tes in Anleh­nung an eine Ver­mu­tung Edgar Scheins (2010), ist auch die „tra­gen­de Bezie­hung“ zwi­schen Auf­trag­ge­ber und Auf­trag­neh­mer hel­fen­den Cha­rak­ters. Schein (ebd.) unter­schei­det drei Arten hel­fen­der Bezie­hun­gen:

Modus 1 – Spe­zia­lis­ten­hil­fe: Der Auf­trag­ge­ber weiß nicht nur, dass er ein Pro­blem hat, son­dern er weiß genau, wel­ches Pro­blem er hat. Er kann es genau beschrei­ben und kennt die ent­spre­chen­de Lösung. Die Auf­trag­ge­ber­sei­te wen­det sich an einen ent­spre­chen­den Spe­zia­lis­ten und kauft die Lösung dort ein. Braucht man also für die Erle­di­gung von Stan­dard­auf­ga­ben für sie­ben Arbeits­plät­ze die ent­spre­chen­de Stan­dard­soft­ware mit eini­gen spe­zi­fi­schen Anpas­sun­gen an die Gege­ben­hei­ten des Unter­neh­mens, so ist dies ein typi­scher Fall für Spe­zia­lis­ten­hil­fe.

Modus 2 – Das Arzt-Pati­ent-Ver­hält­nis: In die­sem Fall weiß der Auf­trag­ge­ber, dass er ein Pro­blem hat, aber er weiß ggf. nicht genau, was in die­sem Fall hilft. Auch hier wen­det sich der Auf­trag­ge­ber an Spe­zia­lis­ten, die jedoch nicht sofort die Lösung anbie­ten, son­dern zunächst eine Dia­gno­se erar­bei­ten, die dann die Grund­la­ge für die Lösung bil­det.

Modus 3 – Bera­tung und Lösungs­su­che als Pro­zess: In die­ser drit­ten Vari­an­te ken­nen weder die auf­trag­ge­ben­de noch die bera­ten­de bzw. auf­trag­neh­men­de Sei­te die genaue Natur des Pro­blems, geschwei­ge denn die Lösung. Die Aus­gangs­la­ge ist so kom­plex, dass nur ein gemein­sa­mer Pro­zess des Suchens, der Ana­ly­se und des Ent­wi­ckelns zur Lösung führt. Die Grund­la­ge die­ses Pro­zes­ses bil­det die hel­fen­de Bezie­hung zwi­schen den Betei­lig­ten.

Hier wer­den nun eini­ge der erheb­lichs­ten Kom­mu­ni­ka­ti­ons­stö­run­gen in IT-Pro­jek­ten deut­lich:

1. Bei­de Sei­ten agie­ren in Modus 1, spre­chen aber über völ­lig unter­schied­li­che Din­ge: Im Ide­al­fall weiß der Auf­trag­ge­ber, wel­ches Pro­blem er hat und wer ihm die Lösung lie­fern kann. Drückt er sich klar aus und tut der Auf­trag­neh­mer nur das, was tat­säch­lich bestellt wur­de, kommt es tat­säch­lich zum gewünsch­ten Ergeb­nis. Kennt der Auf­trag­ge­ber aber nicht alle Facet­ten sei­nes Pro­blems, und ent­wi­ckelt der Auf­trag­neh­mer – gleich­sam pro­phy­lak­tisch – Lösungs­sze­na­ri­en für den Fall, dass der Kun­de sie brau­chen könn­te, kommt es zu Stö­run­gen. Für den Auf­trag­ge­ber sieht die Lösung anders aus als das, was er erwar­tet hat. Dass sich die­se Erwar­tun­gen mit der Zeit ver­än­dert haben und von vorn­her­ein schon etwas anders lagen, als sie anfangs beschrie­ben wur­den, wird der Auf­trag­ge­ber­sei­te dabei nicht bewusst. Der Auf­trag­neh­mer­sei­te ist in die­sem Fall nicht bewusst, wie die Erwar­tun­gen tat­säch­lich lagen und wie sich die Lösung wäh­rend der Ent­wick­lung wie von selbst („Das könn­te der Auf­trag­ge­ber brau­chen.“ oder „Wenn wir das so her­um machen, ist es doch viel ein­fa­cher.“) und ohne Abstim­mung ver­än­dert hat. Das Ergeb­nis ist ein tie­fer Gra­ben zwi­schen ursprüng­li­cher Erwar­tung und fer­ti­ger Lösung.

2. Bei­de Sei­ten kom­mu­ni­zie­ren in unter­schied­li­chen Modi: Wäh­rend der Auf­trag­ge­ber in Modus 1 kom­mu­ni­ziert und Lösun­gen erwar­tet, ver­su­chen vie­le IT-Fach­leu­te in Modus 2 oder 3 zu kom­mu­ni­zie­ren und Fra­gen bezüg­lich der Anfor­de­run­gen zu stel­len. Kommt es zu Stö­run­gen, macht der Auf­trag­ge­ber nicht sel­ten sei­ne Erwar­tung deut­lich, dass er von kom­pe­ten­ten Bera­tern oder Ent­wick­lern eine funk­tio­nie­ren­de Lösung erwar­te. Schließ­lich bezah­le er dafür, weil er eben nicht das Fach­wis­sen habe. Damit wird jeder klä­ren­de Dia­log und jede Form der Hil­fe unter­drückt.

Die hier beschrie­be­nen Pro­ble­me stei­gern sich noch, wenn Irri­ta­tio­nen nicht zum Ler­nen aus Erfah­rung, son­dern zur Ver­här­tung der jewei­li­gen Stand­punk­te füh­ren. So mag sich bspw. ein Geschäfts­füh­rer zu Beginn eines Pro­jek­tes über mög­li­che Schwie­rig­kei­ten bei der Ver­än­de­rung der ERP-Soft­ware bewusst gewe­sen sein. Doch ange­sichts des stei­gen­den Drucks wäh­rend der Ein­füh­rung wer­den sein Denk- und Hand­lungs­wei­sen immer auto­ma­ti­scher, und Aus­sa­gen wie „Ich bezah­le Sie, und Sie sind die Exper­ten. Ich erwar­te von Ihnen, dass Sie die ver­trag­lich ver­ein­bar­ten Zie­le hal­ten.“ fal­len häu­fi­ger. Die Ursa­che für die­se Ver­här­tung kann in einem der mäch­tigs­ten psy­chi­schen Abwehr­me­cha­nis­men, der Pro­jek­ti­on, lie­gen.

Der Abwehr­me­cha­nis­mus der Pro­jek­ti­on bewirkt, dass eine Per­son Emp­fin­dun­gen und Wün­sche, die sie an sich selbst uner­träg­lich fin­det, zunächst leug­net. Bis hier­her ähnelt der Vor­gang der Ver­drän­gung. Das Spe­zi­fi­sche an der Pro­jek­ti­on ist, dass die (im Unbe­wuss­ten wirk­sam blei­ben­den) Gefüh­le und Impul­se unbe­wusst einer ande­ren Per­son zuge­schrie­ben wer­den. Bei­na­he klas­si­sche Bei­spie­le sind beson­ders domi­nan­te Men­schen, die ihre eige­ne Aggres­si­vi­tät leug­nen und dafür ande­re Men­schen als beson­ders domi­nant und aggres­siv kri­ti­sie­ren. Den Mecha­nis­mus der Pro­jek­ti­on gibt es auch in umge­kehr­ter Rich­tung (Intro­jek­ti­on), indem sich eine Per­son, um bestimm­te Situa­tio­nen zu bewäl­ti­gen, Gefüh­le und Ver­hal­tens­wei­sen ande­rer Per­so­nen in sich hin­ein­pro­ji­ziert und so emp­fin­det und han­delt, wie die ande­re Per­son ver­meint­lich emp­fun­den und gehan­delt hät­te.“ (Hei­dig et al. 2012, S. 38)

So kann der besag­te Geschäfts­füh­rer bei­spiels­wei­se sei­ne eige­nen Schwie­rig­kei­ten wäh­rend des Ein­füh­rungs­pro­zes­ses (etwa die Kon­flik­te mit den mitt­le­ren Füh­rungs­kräf­ten des Unter­neh­mens oder die anhal­ten­den Blo­cka­de­hal­tun­gen eini­ger Stand­or­te) in den Bera­ter oder den Geschäfts­füh­rer des mit der Imple­men­tie­rung des neu­en Sys­tems beauf­trag­ten Unter­neh­mens pro­ji­zie­ren. Der „Bene­fit“ für den Geschäfts­füh­rer liegt in der psy­chi­schen Ent­las­tung von den Kon­flik­ten und der erleb­ten Wir­kungs­lo­sig­keit. In einer sol­chen Kon­stel­la­ti­on kann die auf­trag­neh­men­de Sei­te nur ver­lie­ren, es sei denn, es kommt zu einer Klä­rung.

Wie aber kann so eine Klä­rung aus­se­hen?

In den meis­ten Fäl­len wer­den irri­tie­ren­de Erleb­nis­se über­gan­gen. Nach­dem ein Pro­jekt geschei­tert ist, heißt es jedoch oft: „Eigent­lich hät­ten wir es damals schon ahnen kön­nen…“ Der ers­te Schritt zur Klä­rung ist, der eige­nen Ver­wun­de­rung oder Irri­ta­ti­on Raum zum Wir­ken zu geben. Auch wenn dies erst ein­mal befremd­lich klingt – oft han­delt es sich beim Manage­ment von Pro­jek­ten weni­ger um ein tech­ni­sches, als viel­mehr um ein zwi­schen­mensch­li­ches Unter­fan­gen. Und in zwi­schen­mensch­li­chen Situa­tio­nen sind Irri­ta­tio­nen die ers­te und zu Beginn auch ein­zi­ge Infor­ma­ti­ons­quel­le. Die Kunst besteht nun dar­in, die­se Beob­ach­tun­gen und Wahr­neh­mun­gen in einen ziel­ori­en­tier­ten Klä­rungs­pro­zess ein­flie­ßen zu las­sen. In der Bera­tungs­psy­cho­lo­gie kennt man den Grund­satz „Stö­run­gen haben Vor­rang.“ Das gilt auch für das Manage­ment kom­ple­xer IT-Pro­jek­te. Die Grund­la­ge für die Klär­bar­keit schwie­ri­ger Sach­la­gen bil­det eine gewach­se­ne hel­fen­de Bezie­hung, wofür ande­re Kom­pe­ten­zen und Metho­den erfor­der­lich sind als man für Manage­ment oder Soft­ware­ent­wick­lung braucht. Die Fähig­keit, den eige­nen Irri­ta­tio­nen in wert­schät­zen­der Wei­se Aus­druck zu ver­lei­hen, Fra­ge­tech­ni­ken, kon­struk­ti­ves Feed­back, Betei­li­gungs­sze­na­ri­en zur Ein­be­zie­hung der Mit­ar­bei­ter­ebe­nen, Mode­ra­ti­ons­tech­ni­ken und pro­zess­ori­en­tier­te Soft­ware­ent­wick­lungs­me­tho­den wie Scrum füh­ren hier wei­ter.

Man braucht eine gan­ze Men­ge Durch­hal­te­ver­mö­gen, Feh­ler und Ver­bes­se­rungs­vor­schlä­ge immer wie­der anzu­spre­chen. Hilf­reich ist, dafür ein regel­mä­ßi­ges Set­ting zu schaf­fen (bspw. ein wöchent­lich statt­fin­den­des Mee­ting zur kon­ti­nu­ier­li­chen Ver­bes­se­rung mit den Fra­gen „Was lief gut?“ und „Wel­che Pro­ble­me gab es, und wie las­sen sich die­se Pro­ble­me lösen?“). Wenn die Rou­ti­nen („Das machen wir schon immer so!“) beson­ders gefes­tigt sind oder die Bezie­hung zwi­schen Auf­trag­ge­ber und Auf­trag­neh­mer nicht belas­tet wer­den soll, kann es hel­fen, die Rol­le des „Rufers in der Wüs­te“, also des­je­ni­gen, der sei­nen Irri­ta­tio­nen und Beob­ach­tun­gen Aus­druck ver­leiht, an eine Per­son zu dele­gie­ren, die nur die­se und kei­ne ande­re Funk­ti­on inne­hat.

Jörg Hei­dig




Schreibe einen Kommentar