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önnte.

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 Beziehungen:

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 Spezialistenhilfe.

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 bildet.

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 Beteiligten.

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

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 unterdrü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, liegen.

„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 aussehen?

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 weiter.

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 innehat.

Jörg Hei­dig

Von Jörg Heidig

Jörg Heidig, Jahrgang 1974, nach Abitur und Berufsausbildung in der Arbeit mit Flüchtlingen zunächst in Deutschland und anschließend für mehrere Jahre in Bosnien-Herzegowina tätig, danach Studium der Kommunikationspsychologie, anschließend Projektleiter bei der Internationalen Bauausstellung in Großräschen, seither als beratender Organisationspsychologe, Coach und Supervisor für pädagogische Einrichtungen, soziale Organisationen, Behörden und mittelständische Unternehmen tätig. 2010 Gründung des Beraternetzwerkes Prozesspsychologen; seit 2016 Leitung des Görlitzer KIB-Instituts. Lehraufträge an der Hochschule der Sächsischen Polizei, der Dresden International University, der TU Dresden sowie der Hochschule Zittau/Görlitz.