„Hinter den Kulissen der Organisation“, so lautet der Titel eines Klassikers der systemischen Beratung, das 1977 von der sogenannten Mailänder Gruppe veröffentlicht wurde. M. Selvini Palazzoli, et al.; Hinter den Kulissen der Organisation, Klett-Cotta, 1995
„Diagnose“, in: Wolfgang Pfeifer et al., Etymologisches Wörterbuch des Deutschen (1993), digitalisierte und von Wolfgang Pfeifer überarbeitete Version im Digitalen Wörterbuch der deutschen Sprache, <https://www.dwds.de/wb/etymwb/Diagnose>, abgerufen am 25.06.2021.
Siehe: H. Moosbrugger, A. Kelava, Testtheorie und Fragebogenkonstruktion, Springer-Verlag Berlin-Heidelberg, 2012
Siehe: E. Motzel, T. Möller, Projektmanagement Lexikon, Wiley-VCH, 2017
K.-W. Freiherr von Rotenhan, C. Zahrnt, Qualität, in Kompetenzbasiertes Projektmanagement (PM4), Band 2, Hrsg. GPM, S. 1271
E. Motzel, T. Möller, Projektmanagement Lexikon, Wiley-VCH, 2017, S. 36
Siehe www.gpm-ipma.de/know_how/pm_assessments.html
Lewin, K. (1943). Psychology and the process of group living. Journal of Social Psychology, 17, 113–131. Reprinted in The complete social scientist: A Kurt Lewin reader, (Gold, Martin, Ed) (1999) (pp. 333–345). Reprinted (in part) in Cartwright, 1951, Chapter 7.
K. Doppler, C. Lauterburg, Change Management, Campus Verlag, Frankfurt, N.Y., 1994, S. 92)
G. Lomnitz, Autorität-mehr als nur ein Schlagwort, in Projektmagazin 10/2014
J. Hansel, G. Lomnitz, Projektleiter-Praxis, 4. überarbeitete Auflage, S. 128, Springer-Verlag Berlin Heidelberg, 2003
F. Glasl, Konfliktmanagement, S. 25, Verlag Paul Haupt, Bern, Stuttgart 1980
Siehe: F. Glasl, Konfliktmanagement, S. 97, Verlag Paul Haupt, Bern, Stuttgart 1980
G. Lomnitz, Damit es im Projektteam rund läuft – Teamprozesse verstehen und steuern, Projekt Magazin 21/2020
E. Canetti, Masse und Macht, Frankfurt 1980, S. 317
Siehe Dietrich. Dörner, Hitlers Handeln, in Richtiges und gutes Management: vom System zur Praxis; Festschrift für Fredmund Malik, Haupt Verlag, Bern 2005, S. 222ff
Dieser bekannte Aphorismus stammt von dem Maler und Dichter Francis Picabia.
 |
wichtig |
 |
Empfehlung |
 |
Checkliste |
Seit etlichen Jahren habe ich mich immer wieder mit der Idee beschäftigt, über meine mehr als 30jährigen Praxiserfahrung als Projektdiagnostiker ein Buch zu schreiben. Ich fand die Idee auch interessant, weil nach meinen Recherchen über Projektdiagnose bisher noch kein Buch veröffentlicht wurde. Über Review und Audit ist recht viel veröffentlicht worden, aber über Projektdiagnose, so wie ich sie in diesem Buch vorstelle, ist bisher noch nichts. Wohl sind über das Thema Organisationsdiagnose zahlreiche Artikel und Bücher erschienen, die teilweise in Zusammenhang mit Organisationstheorien, Organisationsentwicklung bzw. Change Management stehen. Einige Grundlagen, Regeln und Methoden aus diesen Bereichen sind in dieses Buch eingeflossen.
Doch zwischen Wunsch und Wirklichkeit klafft manchmal eine größere zeitliche Lücke. Durch meine Arbeit, durch viele Reisen und meine fotografischen Ambitionen blieb die Idee lange Zeit auf der Strecke. Dann kam die Pandemie, die mir die Gelegenheit bot, mich endlich meinem Vorhaben, über Projektdiagnose zu schreiben, zu widmen. In vielen Stunden habe ich altes und neues Material aus meiner Arbeit sowie Artikel und Bücher rund um die Themen Organisations-, Teamdiagnose sowie Projektmanagement gesichtet. Was für ein Luxus, genügend Muse zu haben, endlich ein Buch ohne Zeitdruck zu schreiben und nicht wie bei den beiden anderen Büchern und Artikeln oft in Konkurrenz zur täglichen Arbeit die Zeit abzuknapsen.
Mein Dank gilt meiner lieben Kollegin Dr. Andrea van Aubel, die mich vor vielen Jahren bei der Ausarbeitung des IPO-Modells zur Analyse von Projektteams inspiriert hat. Unsere Zusammenarbeit hat sicher zum Entstehen des Buches beigetragen.
Herzlich bedanken möchte ich mich bei Rainer Bösch, Ivoclar Vivadent AG, Director R&D Multiproject Management, mit dem ich mich seit Jahren über Projektverläufe und deren Hintergründe im Unternehmen austausche.
Ganz herzlich bedanken möchte ich mich bei Martin Hülsmann, Head of Operational Re-Engineering, Mubea Fahrwerksfedern GmbH. Über einen langen Zeitraum haben wir gemeinsam Projekte bei einem global operierenden Zulieferer für die Automobilindustrie in China, USA, Indien und in europäischen Ländern diagnostiziert. Dank ihm habe ich die raue Welt des Projektmanagements kennengelernt.
Herr Professor Heinz Schelle hat mir bei der Suche nach einem Verlag spontan den Kontakt zum Herausgeber des Buches ermöglicht. Dafür möchte ich mich herzlich bei ihm bedanken.
Mein Dank gilt Herrn Professor Steffen Scheurer, Chefredakteur der PROJEKTMANAGEMENT AKTUELL und Mitherausgeber dieser Reihe.
Herzlich bedanken möchte ich mich bei Dr. Jürgen Schechler, Leiter des UVK Verlags, der mir mit Rat und Tat bei der Erstellung des Buches zur Verfügung stand.
Nicht zuletzt gilt mein Dank allen Kunden, die mir ihr Vertrauen schenkten und schenken, hinter die Kulissen der Projekte in ihre Organisation zu schauen.
Nur wer nicht sucht, ist vor Irrtum sicher.
(Albert Einstein)
Um Irrtümer, möglichst frühzeitig, zu erkennen, muss man Augen und Ohren öffnen, nachdenken, nachfragen, um die Sichtweisen der beteiligten Personen zu erfahren und zu verstehen. Verstand und Intuition sind notwendig, um das Projektgeschehen fundiert zu erfassen. Diese Eigenschaften und Tätigkeiten sind für Projektdiagnosen, so wie sie in diesem Buch vorgestellt werden, unverzichtbar.
Mit Projektdiagnose betrete ich in gewisser Weise Neuland, denn über dieses Thema sind bisher noch keine Veröffentlichungen erschienen, weder in Form von Artikeln noch als Buch. Das gilt nach meinen Recherchen sowohl für die deutschsprachige als auch für die angelsächsische Projektmanagementliteratur. Dagegen gibt es zahlreiche Veröffentlichungen zum Thema Organisationsdiagnose und Teamdiagnose aus den Gebieten der Organisationsentwicklung, der Betriebswirtschaft und der Psychologie. Manche Ideen aus diesen Bereichen sind in das Buch eingeflossen. Im Internet taucht der Begriff Projektdiagnose einige Male auf, wobei es sich sehr schnell herausstellt, dass Diagnose mit Monitoring oder Risk-Assessment gleichgesetzt wird. Damit wird man meines Erachtens dem Thema Projektdiagnose aus zwei Gründen nicht gerecht:
Monitoring gehört zu den permanenten Aufgaben der Projektleitung. Projektdiagnose dagegen ist eine spezielle Aufgabe, die für ein Projekt erforderlich sein kann, aber längst nicht in jedem Projekt durchgeführt werden muss.
Diagnostiker:innen analysieren von außen mit der notwendigen diagnostischen Distanz das Projektgeschehen und sie sind nicht verantwortlich für die Steuerung des Projektes. Die Verantwortung für die Steuerung des Projektes liegt bei der Projektleitung und bei den Entscheidungsträgern des Projektes und nicht bei den Projektdiagnostiker:innen. Allgemeiner formuliert, Diagnostiker:innen arbeiten am System und nicht im System. Auf dieses Thema gehe bei der Fragestellung „kann die Projektleitung das eigene Projekt diagnostizieren?“ noch ein.
Wie gesagt, ich betrete in gewisser Weise Neuland, denn manches, was Sie in diesem Buch lesen können, finden Sie in der einschlägigen Projektmanagementliteratur. Möglicherweise kennen Sie die klassischen Diagnosefelder mit den dazugehörenden Fragen. Die Methoden der Datensammlung dürften denjenigen bekannt sein, die sich mit der Ausarbeitung von Fragenbögen oder der Durchführung von Interviews beschäftigt haben. Möglicherweise neu könnten die ausführlichen Erläuterungen zur Auftragsklärung im Rahmen der Projektdiagnose sein, wobei manche Übereinstimmung mit dem Thema Auftragsklärung in Projekten besteht. Ich hoffe, dass Ihnen die Erklärungen über die grundlegenden Voraussetzungen für fundierte Projektdiagnosen (Kapitel 4) neue Erkenntnisse bieten. Dieses Kapitel liegt mir besonders am Herzen, weil ich die Inhalte für unverzichtbar halte, um Projekte professionell zu diagnostizieren. Auch die für Projektdiagnosen unverzichtbaren Ausführungen zur Psycho-Logik von Problemen lassen sich in Beiträgen über Projektreviews und Audits nicht finden. So ist dieses Buch eine Mischung von bekanntem Projektmanagement Wissen und solchen Themen, die weit über das gängige Projektmanagement Know-how hinausgehen.
Warum habe ich mich für den Titel „Projektdiagnose – auch hinter die Kulissen des Projektes schauen“1 und nicht für Projektreview entschieden? Möglicherweise hätte ich früher den Titel Projektreview gewählt. Doch im Laufe der Jahre erschien mir der Begriff Projektreview zunehmend unpassend, weil mit Review meistens die klassischen Fragen zur Projektanalyse verbunden sind, die sich überwiegend auf die Hard Facts beziehen. Selbstverständlich wird in Reviews auch nach der Zusammenarbeit im Team oder den Entscheidungsprozessen im Steering Committee gefragt. Doch bleiben diese Fragen an der Oberfläche und das genau ist nicht der Anspruch, an dem sich eine fundierte Projektdiagnose bewerten lassen muss. Projektdiagnose hat die Aufgabe, die Ursachen für Fehlentwicklungen fundiert zu analysieren. Das bedeutet: Diagnostiker:innen dürfen nicht an den Symptomen hängenbleiben, sondern sie müssen auch hinter die Kulissen des Projektes und notwendigerweise auch hinter die Kulissen der Organisation schauen. Um dieses Ziel zu erreichen, müssen sowohl die Logik der Probleme als auch die Psycho-Logik des Projektgeschehens ermittelt, analysiert, bewertet und kommuniziert werden.
Um Missverständnisse zu vermeiden, weise ich darauf hin, dass sich die Inhalte des Buches nicht mit Methoden zur Analyse fachlicher, technischer Probleme in Projekten beschäftigen.
Das Buch soll Ihnen Grundlagen, Methoden, Regeln und Techniken für die diagnostische Arbeit bieten. Die Beispiele und Empfehlungen beruhen auf meiner jahrzehntelangen Erfahrung als Projektdiagnostiker in unterschiedlichen Branchen und Kulturen. Überwiegend beruhen meine Erfahrungen auf Diagnosen von Forschungs- und Entwicklungsprojekten, IT- und Prozessoptimierungsprojekten, Marketingprojekten und Change Management-Projekten. Nur durch diese Erfahrungen war es mir möglich das Buch zu schreiben, das ich als Arbeitsbuch für die Praxis der Projektdiagnose verstehe.
Seit über 25 Jahren leite ich Seminare und Workshops zum Thema Projektdiagnose und immer wieder stellen mir die Teilnehmenden folgende Fragen. Sie spiegeln einen großen Teil der Herausforderungen wider, mit denen sich die Diagnostizierenden auseinandersetzen müssen, um ihre Aufgaben erfolgreich zu bewältigen.
Woran kann ich erkennen, ob eine Projektdiagnose erfolgreich war?
Wann ist der richtige Zeitpunkt für eine Projektdiagnose?
Wer erteilt den Auftrag für die Projektdiagnose?
Wie können Projektdiagnosen am besten angekündigt werden?
Woran kann ich erkennen, ob Entscheider:innen an einer Lösung wirklich interessiert sind?
Wer kann Projektdiagnosen durchführen?
Kann die Projektleitung für das eigene Projekt eine Diagnose machen? Besteht nicht ein Rollenkonflikt?
Was muss ich wissen und können, um erfolgreich Projekte zu analysieren? Wie sieht das Anforderungsprofil der Diagnostiker:innen aus?
Diagnose durch Kolleg:innen? Geht das und wenn ja, wie?
Wer muss in die Diagnose einbezogen werden?
Wie mache ich aus den vielen Daten einen aussagefähigen Bericht?
Wer erhält wann welche Ergebnisse?
Wie vermittle ich politisch brisante Themen, vor allem dann, wenn Führungskräfte die Probleme verursacht haben?
Wie viel Zeit benötigt man für eine Projektdiagnose?
Wie teuer sind Projektdiagnosen?
Welche Fragen müssen und können im Interview gestellt werden?
Wie gelange ich in Interviews zu den eigentlichen Kernproblemen?
Welche Fragetechniken führen zum Erfolg?
Wie gehe ich mit Widerständen im Interview um?
Wie schafft man im Vorfeld der Diagnose Akzeptanz für die Maßnahme?
Gibt es Standardverfahren für Projektdiagnosen?
Welche Rolle spielt die Unternehmenskultur?
Wie können die Ergebnisse von Projektdiagnosen in der Organisation umgesetzt werden und wer ist dafür verantwortlich?
Wann ist die Diagnose beendet?
Ich hoffe, dass Ihnen dieses Buch konkrete Antworten und Anregungen bietet, um Projektdiagnosen professionell zu planen und durchzuführen.
In den Kapiteln 3, 5, 6, 7, 8 wird das Handwerkszeug der Projektdiagnose von der Auftragsklärung bis zur Präsentation der Diagnoseergebnisse erläutert. In diesen Kapiteln geht es um Methoden, Fragen, Regeln, Empfehlungen und nicht zuletzt um Modelle, die Sie für Projektdiagnosen nutzen können. Die Checklisten und Tipps können Sie im Sinne eines Handwerkskoffers nutzen. Kapitel 2 beschäftigt sich mit der Frage, was Projektdiagnose bedeutet. Im Kapitel 4 werden grundsätzliche Aspekte der Projektdiagnose beschrieben, die deutlich über das rein Handwerkliche hinausgehen. Ich empfehle, sich gerade mit diesen Inhalten genauer zu beschäftigen, denn sie bilden das Fundament für die Diagnose. Im Kapitel 9 stelle ich ein Anforderungsprofil für Projektdiagnostiker:innen vor.
Was bedeutet Projektdiagnose?
Abgrenzung der Projektdiagnose von Review, Audit und Projektmanagement-Assessment?
Was unterscheidet wissenschaftlich fundierte psychologische Diagnosen von Projektdiagnosen?
Projektdiagnosen – wann sind sie sinnvoll und wann nicht?
Übersicht über den Diagnoseprozess
Erfolgreiche Projektdiagnose steht und fällt mit einer profunden Auftragsklärung. Das Was und das Wie der Auftragsklärung werden in diesem Kapitel ausführlich erläutert.
Auftragsklärung beginnt mit der Diagnose der Vorgeschichte
Inhalte der Auftragsklärung
Die Inhalte eines Diagnoseauftrags werden beschrieben. Besonderen Wert habe ich auf die Themen „Ziele der Projektdiagnose“, „die Systemgrenze klar definieren“ und „Rollen im Diagnoseprozess“ gelegt.
Die einzelnen Elemente eines Diagnoseauftrags kann man nachlesen, doch am Ende des Tages kommt es darauf an, wie gut die Auftragsklärung gelungen ist. Deshalb werden eine Reihe konkreter Empfehlungen vermittelt, wie Diagnostiker:innen sich im Rahmen der Auftragsklärung verhalten müssen. Hier liegt letztlich der Schlüssel zum Erfolg.
Dieses Kapitel mit seinen theoretischen Aussagen bildet die Basis für die diagnostische Arbeit und für die weiteren Kapitel. Ohne dieses Wissen können Projekte nicht fundiert, vertiefend analysiert werden. Die Methoden und Regeln lassen sich nicht sinnvoll anwenden. Je besser Sie diese Grundlagen verstanden und verinnerlicht haben, desto sicherer werden Sie die Methoden und Techniken der Projektdiagnose nutzen können.
In diesem Kapitel werden die Diagnosefelder mit den dazugehörenden Fragen vorgestellt. Unter Diagnosefelder verstehe ich die inhaltlichen Schwerpunkte der Diagnose, u.a. Projektziele, Informationsfluss, Entscheidungsprozesse oder Zusammenarbeit im Team. Die Diagnosefelder und Fragen sind in folgende Abschnitte unterteilt:
Klassische Diagnosefelder mit den entsprechenden Fragen
Fragen zur Psycho-Logik der Probleme
Diagnostiker:innen bleiben nicht an den Symptomen hängen, sondern sie gehen in die Tiefe und untersuchen auch die psychologischen und politischen Einflüsse auf die Projektarbeit, denn nur so ergibt sich ein ganzheitliches Bild.
Die Diagnose des Projektteams wird in einem eigenen Abschnitt erläutert. Dargestellt werden die Einflüsse der Strukturelemente und des Verhaltens auf die Zusammenarbeit sowie deren Wechselwirkungen.
Organisationen sind Druckweitergabe-Systeme, d.h. Druck wird von einem Subsystem auf ein anderes bzw. auf mehrere Subsysteme verlagert, was selten aus böser Absicht passiert. Daraus ergibt sich für Projektdiagnose eine klare Schlussfolgerung: Wer ein Projekt oder ein Projektteam diagnostizieren will, muss die Problem-, Konfliktverlagerungsprozesse verstehen.
Dieses Kapitel beschäftigt sich mit den Methoden, Instrumenten und Techniken der Datensammlung. Die Schwerpunkte liegen beim Fragebogen und beim Einzelinterview mit ihren Grundlagen, Regeln und Tipps. Zu Beginn gehe ich auf die Planung der Datensammlung ein, ein Thema, was auf keinen Fall vernachlässigt werden darf.
Planung der Datensammlung
Dokumentenanalyse
Fragebogen
Einzelinterview und Gruppeninterview
Hearing
Diagnoseworkshop
Wie kann die Datenmenge sinnvoll geordnet und analysiert werden, um die Stärken und Schwächen des Projektes zu verstehen? Erst durch eine fundierte Analyse und daraus resultierende Empfehlungen wird die Arbeit der Diagnostiker:innen fruchtbar. In diesem Kapitel werden die Schritte der Datenaufbereitung mit Praxistipps dargestellt.
Clustern
Diagnosebericht ausarbeiten
Beispiel eines Diagnoseberichtes
Die Ergebnisse der Projektdiagnose müssen gut vorbereitet dem richtigen Adressatenkreis präsentiert werden. Der Erfolg der Diagnose darf nicht durch ein unprofessionelles Datenfeedback gefährdet werden. Erläutert werden die einzelnen Bausteine des Datenfeedbacks.
Formen des Datenfeedbacks
Vorbereitung der Präsentation
Durchführung der Präsentation
In diesem Kapitel wird ein Anforderungsprofil für Projektdiagnostiker:innen vorgestellt. Dabei geht es um drei Bereiche, die für die Qualifikation bedeutsam sind.
Persönlichkeitsmerkmale
Rollenbewusstsein
Know-how (Qualifikation im engeren Sinn) mit einem Qualifikationsprofil
Zu guter Letzt finden Sie nicht ganz ernstgemeinte Tipps im Sinne von paradoxen Verschreibungen, wie Sie es schaffen, Projektdiagnosen zum Scheitern zu bringen.
Das Buch wendet sich an Praktiker:innen in unterschiedlichen Rollen, die sich genauer mit dem Thema Projektdiagnose beschäftigen möchten. Darüber hinaus ist es auch für Lehrende und Studierende geschrieben.
Projektleitung, Teilprojektleitung und Projektmitarbeiter:innen
Auftraggeber:innen von Projekten
Mitglieder von Steering Committees und anderen Gremien
Führungskräfte
Projektportfolio Manager:innen
Projekt Controller:innen
Revisor:innen
Qualitätsmanager:innen
Interne und externe Berater:innen
Professor:innen
Studierende
In diesem Kapitel wird Projektdiagnose in Abgrenzung zum Projektreview und Projektaudit vorgestellt und die wesentlichen Merkmale einer Projektdiagnose beschrieben.
Das Wort DiagnoseDiagnose leitet sich vom altgriechischen diágnosis ab, bestehend aus diá (durch) und gnósis und bedeutet Unterscheidung, Erkenntnis, Urteil.1
Aus dieser Erklärung lässt sich eine klare Folgerung ableiten: Die Projektdiagnostiker:innen müssen die gesammelten Informationen klar unterscheiden und verstehen können, um zu einem Urteil, einer Bewertung zu gelangen.
Diagnose beinhaltet also drei Kernpunkte, die für alle Arten der Diagnosen gelten und somit auch für die Projektdiagnose:
Datensammlung
Daten über den Zustand eines Projektes müssen ermittelt werden, wobei es sich stets um Hard Facts und Soft Facts handelt. Der Umfang der Datensammlung wird wesentlich durch das Ziel und die Systemgrenze der Diagnose bestimmt. Dieses Thema wird im Kapitel 3 „Auftragsklärung“ behandelt.
DatenanalyseDatenanalyse
Die ermittelten Daten müssen eingeordnet, gewichtet und analysiert werden. Diagnose kann als Informationsverarbeitungsprozess verstanden werden. Als Frage formuliert: Wie entstehen aus einer Vielzahl von Daten (Aussagen, Meinungen, Zahlen, Schriftstücke) relevante Informationen? Die Bedeutung einer gründlichen Datenanalyse sollte allen klar sein, die Projekte diagnostizieren oder beauftragen wollen. Eine fundierte Datenanalyse hängt nicht nur vom handwerklichen Können ab, sondern auch von der Bereitschaft, gründlich zu arbeiten, d.h. sich Zeit nehmen für die Analyse. Hier trennt sich in der Praxis oft die Spreu vom Weizen. (Siehe Kapitel 7 „Datenaufbereitung – von der Analyse zum Bericht“.)
Datenbewertung und Empfehlungen
Auf den Punkt gebracht, eine Projektdiagnose ohne Bewertungen und Empfehlungen ist nicht denkbar, Diagnostiker:innen müssen sich durch ihre Bewertungen und Empfehlungen positionieren. Ihre Sichtweisen fließen zwangsläufig in die Bewertungen ein, deshalb kann eine Projektdiagnose nie objektiv sein, aber sie muss neutral sein. Auf dieses wichtige Thema gehe ich an verschiedenen Stellen des Buches weiter ein (siehe Abschnitt 2.2 und vor allem Abschnitt 4.2).
Mit dem Datenfeedback, der Präsentation der Diagnoseergebnisse, endet die Diagnose. Für Entscheidungen über mögliche Maßnahmen ist das Management verantwortlich und nicht die Projektdiagnostiker:innen. Diese Rollenklärung muss im Rahmen der Auftragsklärung gründlich besprochen werden.
Der DatensammlungDatensammlung muss eine sorgfältige Zielklärung vorausgehen. Alle Beteiligten sollten das gleiche Verständnis haben, was durch die Diagnose erreicht werden soll und was nicht. Soll die Diagnose ausschließlich oder überwiegend Informationen über die fachliche Situation des Projektes (Grad der Zielerreichung, Risiken im Projekt) oder die Einhaltung von Richtlinien des Projektmanagement-Handbuchs liefern oder sich auch mit der Zusammenarbeit im Projektteam, dem Informationsfluss im Projekt oder den Entscheidungsprozessen im Steering Committee beschäftigen?
Wenn es „nur“ um die Untersuchung der fachlichen Probleme oder um die Einhaltung des Projektmanagement-Prozesses geht, so sollte man von Audit oder Review sprechen, und nicht von Projektdiagnose.
Zur DatensammlungDatensammlung gehören immer zwei Fragestellungen:
Welche Daten werden benötigt, um ein möglichst klares Bild über den Zustand des Projektes zu erhalten?
Mit welchen Methoden werden die Daten am besten ermittelt?
Generell werden in der Projektdiagnose Hard- und Softfacts ermittelt. Viele Daten können schwarz auf weiß auf Faktenbasis gesammelt werden, wie der Grad der Zielerreichung, Termine/Meilensteine, Budget oder die Verfügbarkeit der Projektmitarbeiter, um nur einige zu nennen. Nach Hardfacts zu fragen ist in der Regel für die Diagnostiker:innen psychologisch unproblematisch, weil es sich um sachliche Themen handelt. Das bedeutet nicht, dass diese Informationen immer zur Verfügung stehen oder man valide Antworten erhält. Doch diese Problematik steht auf einem anderen Blatt. Die Herausforderungen liegen darin, inwieweit die Interviewer:innen fachlich in der Lage sind, (1) die richtigen Fragen zu stellen, (2) die Antworten zu verstehen und (3) diese zu bewerten. Die Ermittlung der fachlichen Situation gehört nicht zur Projektdiagnose, sondern in den Aufgabenbereich von Reviews, Audits oder Risk Assessments.
Doch die Situation kann sich schnell ändern, wenn die Diagnostiker:innen sich mit der Zusammenarbeit im Steering Committee, mit den Ursachen schleppender Entscheidungen in einer Sparte, Interessenkonflikte zwischen Organisationseinheiten oder mit dem fachlichen Urteilsvermögen des Sponsors beschäftigt. Möglicherweise sticht man in Wespennester und aktive oder passive Abwehrreaktionen treten auf. Bestrebungen, die Diagnose negativ zu beeinflussen sind nicht ungewöhnlich, wenn die Diagnostiker:innen auch hinter die Kulissen des Projektes schauen, um den Problemen auf den Grund zu gehen. Eine fundierte Projektdiagnose erfordert, dass man nicht an Symptomen wie unklare Priorität, Terminverzögerungen oder schlechter Informationsfluss hängenbleibt, sondern auch die tieferen Ursachen von Fehlentwicklungen ermittelt und analysiert werden. Mit der Auflistung der Probleme oder Konflikte ist es sicher nicht getan, sondern Diagnostiker:innen müssen auch aufzeigen, wie und warum bekannte, in manchen Fällen schon längst bekannte Probleme nicht gelöst werden (siehe Kapitel 5.2.3.4). Bei der Projektdiagnose geht es immer um die Logik und die Psycho-Logik der Probleme. Mit anderen Worten, auch der Umgang mit Problemen ist Bestandteil der Diagnose.
Klare Ziele für die Diagnose sind eine unabdingbare Voraussetzung für die Datensammlung.
Die Einflüsse von Hard- und Softfacts müssen ermitteln werden.
Diagnostiker:innen müssen sich sowohl mit der Logik als auch mit der Psycho-Logik von Problemen im Projekt beschäftigen. Projektdiagnose zeichnet sich dadurch aus, dass man nicht an den Symptomen hängenbleibt, sondern durch gekonntes Fragen zu den tieferen Ursachen vordringt. Mit dem Abhaken eines Fragenkatalogs ist es sicher nicht getan.
Diagnose ist eine Intervention in ein bestehendes Kraftfeld in der Organisation, sie ist auch eine psychologische und politische Angelegenheit.
Zu wissen, welche Fragen zu stellen sind, ist eine Sache, eine andere, wie man fragt, mit welchen Methoden die Daten am besten gewonnen werden können. Mit am besten ist zweierlei gemeint:
Die richtigen Fragen stellen
Diagnostiker:innen sollten wissen, welche Diagnosefelder für die Untersuchung des Projektes berücksichtigt werden müssen und welche Fragen zu stellen sind. Kapitel 5 beschäftigt sich ausführlich mit diesem Thema.
Zu wissen, welche Fragen zu stellen sind, ist eine notwendige, doch keine hinreichende Bedingung. Für eine erfolgreiche Datensammlung kommt es wesentlich darauf an, die Fragen richtig zu stellen, die Daten mit den geeigneten Methoden zu sammeln. Sollen die Meinungen der Projektbeteiligten mit Hilfe eines Fragebogens ermittelt werden? Sind nur Einzelinterviews oder auch Gruppeninterviews sinnvoll? Lohnt sich ein Diagnose-Workshop mit dem Kernteam oder dem Steering Committee? Für die Datensammlung können verschiedene Methoden genutzt werden. Es gibt nicht den einzig richtigen Weg für die Datensammlung, sondern der effektive und effiziente Einsatz der Methoden muss von Fall zu Fall genau überlegt werden. Dennoch gilt, Interviews sind für die Datensammlung unverzichtbar und nicht durch Fragenbögen ersetzbar.
Projektmanagement-Know-how allein reicht definitiv nicht aus, sondern theoretisches Verständnis über Organisationen, Teams, Prozesse und die psycho-soziale Dynamik in Systemen sind unverzichtbar. Ein tieferes Verständnis über Strukturen und Verhalten in sozialen Systemen im Allgemeinen und in Projekten im Besonderen gehört zum Repertoire der Diagnostiker:innen. Die Abwertung von Theorie im falsch verstandenen Sinne als praxisferne Gedankenspiele ist unangebracht, denn um ein qualifiziertes Gesamtbild zu entwickeln, benötigen die Diagnostiker:innen Ordnung in ihren Gedanken und Handlungen.
Datenanalyse erfordert Gründlichkeit und Ernsthaftigkeit, um die teilweise sehr verschiedenen Aussagen aus den Befragungen zu verstehen und thematisch einzuordnen. Mit fehlender Sorgfalt wird man der verantwortungsvollen Aufgabe nicht gerecht.
Die gewonnen Informationen erhalten erst dadurch ihre Aussagekraft, wenn Maßstäbe bestehen, von denen aus entschieden werden kann, was gut oder schlecht, richtig oder falsch ist, beibehalten oder geändert werden muss, ökonomisch vertretbar oder nicht vertretbar ist. Diagnostiker:innen benötigen Kriterien für ihre Bewertung. Im Gegensatz zu wissenschaftlich fundierten Diagnosen handelt es sich jedoch nicht um objektive Kriterien.
1. In einem Software-Beratungsunternehmen äußerten sich mehrere Projektmitarbeiter und die Projektleitung sehr kritisch über die Qualität der von ihnen entwickelten Software. Sie kritisierten die Entscheidung der Geschäftsleitung, einige vehement, dass die Software mit diesen Qualitätsmängeln zu früh an den Kunden ausgeliefert werden soll. Im Diagnosebericht wurde auf Basis des Kriteriums „hohe Qualität ist positiv“ empfohlen, die Mängel zu beseitigen und erst dann die Software dem Kunden zu übergeben. Die Empfehlung wurde von der Geschäftsführung mit dem Argument abgelehnt, solche Probleme wären in der Softwareentwicklung normal und neue Projekte bei wichtigeren Kunden könnten nicht warten. Die Entwickler:innen würden zu einseitig technisch und zu wenig betriebswirtschaftlich denken.