Czytaj książkę: «Projektdiagnose»
Gero Lomnitz
Projektdiagnose
Auch hinter die Kulissen des Projektes schauen
UVK Verlag · München
Umschlagmotiv: © iStockphoto Ridofranz
© UVK Verlag 2021
— ein Unternehmen der Narr Francke Attempto Verlag GmbH + Co. KG
Dischingerweg 5 • D-72070 Tübingen
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetztes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Internet: www.narr.de eMail: info@narr.de
ISBN 978-3-7398-3099-5 (Print)
ISBN 978-3-7398-0143-8 (ePub)
Inhalt
Vorwort
Dank
1 Ziele des Buches1.1 Praxisfragen1.2 Übersicht über die einzelnen KapitelSchwerpunkte Kapitel 2: Was bedeutet Projektdiagnose?Schwerpunkte Kapitel 3 AuftragsklärungSchwerpunkte Kapitel 4 Grundlagen der ProjektdiagnoseSchwerpunkte Kapitel 5 Diagnosefelder mit den dazugehörenden FragenSchwerpunkte Kapitel 6 Methoden der DatensammlungSchwerpunkte Kapitel 7 Datenaufbereitung – von der Analyse zum BerichtSchwerpunkte Kapitel 8 Datenfeedback – Präsentation der ErgebnisseSchwerpunkte Kapitel 9 Anforderungsprofil für Diagnostiker:innenKapitel 10 Tipps, damit Projektdiagnosen scheitern1.3 Zielgruppe
2 Was bedeutet Projektdiagnose?2.1 Projektdiagnose2.1.1 Daten sammeln2.1.2 Datenanalyse2.1.3 Datenbewertung und Empfehlungen2.2 Wissenschaftlich fundierte psychologische Diagnosen und Projektdiagnosen – ein kurzer Vergleich2.3 Projektreview, Audit, PM-Assessment – Begriffsklärung2.3.1 Projektreview und Projektaudit2.3.2 Projektmanagement-Assessment2.4 Anlässe für Projektdiagnosen und Reviews2.4.1 Anlässe für Reviews2.4.2 Anlässe für Projektdiagnose2.4.3 Wann sollte eine Diagnose nicht durchgeführt bzw. vorzeitig beendet werden?2.5 Der Diagnoseprozess von der Auftragsklärung bis zur Präsentation der Diagnoseergebnisse – Überblick
3 Auftragsklärung3.1 Initiierung – Vorgeschichte der Diagnose verstehen3.1.1 Worauf sollten Diagnostiker:innen im Vorfeld achten?3.2 Auftragsklärung3.2.1 Was muss ich klären?3.2.2 Wie erreiche ich einen klaren Auftrag?
4 Was Sie wissen sollten, bevor sie mit Diagnosen beginnen – Grundlagen der Projektdiagnose4.1 Nichts ist so praktisch wie eine gute Theorie4.2 Diagnose bedeutet Konstruktion von Realität4.3 Die eigene Fokussierung reflektieren4.3.1 Fokussierung nach fachlichen Aspekten4.3.2 Fokussierung unter psychologischen Aspekten4.4 Konsens und Dissens4.5 Stärken und Schwächen4.6 Oberflächlich oder zu detailliert?4.7 Neutral oder parteiisch?4.8 Sympathie und Antipathie4.9 Hierarchische Einflüsse4.10 Schuldfragen und/oder Interaktionsansatz?4.11 Optimistisch oder pessimistisch?4.12 Offen oder (zu) vorsichtig?4.13 Gelassen oder getrieben?4.14 Die eigenen Annahmen kritisch hinterfragen4.15 Um ein Problem zu lösen, muss man sich vom Problem lösen.4.16 Eigene Unsicherheiten wahrnehmen und reflektieren4.17 Diagnose ist eine Intervention in ein bestehendes Kraftfeld4.18 Hard Facts und Soft Facts sind wichtig4.19 Strukturen und Verhalten und deren Wechselwirkungen4.20 Widersprüche, paradoxe Situationen4.21 Zwei Ebenen der Projektdiagnose
5 Diagnosefelder mit den dazugehörenden Fragen5.1 Zum Einstieg: Diagnose des „Systems Familie“5.1.1 Einige Fragen zur Diagnose einer Familie5.1.2 Erläuterung5.2 Diagnosefelder und Fragen für die Projektdiagnose5.2.1 Klassische Diagnosefelder und Fragen5.2.2 Fragen aus dem Bereich der Psycho-Logik5.3 Diagnose des Projektteams5.3.1 Welche Strukturelemente beeinflussen die Arbeit des Projektteams?5.3.2 Welche Verhaltensmerkmale müssen bei der Teamdiagnose beachtet werden?5.3.3 Welche Wechselwirkung bestehen zwischen Strukturelementen und Verhalten?5.4 Problemverlagerung in Projekten
6 Methoden der Datensammlung Grundsätze, Methoden und Regeln6.1 Planung der Datensammlung6.1.1 Beteiligte vor der Datensammlung informieren6.2 Dokumentenanalyse6.3 Fragebogen6.3.1 Vorbereitung des Fragebogens6.3.2 Empfehlungen für die Ausarbeitung des Fragebogens6.3.3 Formen des Fragebogens6.3.4 Gliederung eines Fragebogens6.3.5 Aufwand6.3.6 Vor- und Nachteile von Fragebögen6.4 Einzelinterview6.4.1 Vorbereitung6.4.2 Breite und Tiefe im Interview6.4.3 Wie steige ich in ein Interview ein?6.4.4 Empfehlungen zur Mitschrift6.4.5 Einzelinterview – Regeln und Empfehlungen6.4.6 Vor- und Nachteile des Einzelinterviews6.5 Gruppeninterview6.5.1 Tipps zum Gruppeninterview6.5.2 Vor- und Nachteile des Gruppeninterviews6.6 Hearing6.7 Diagnose – Workshop6.7.1 Tipps zur Vorbereitung und Durchführung von Diagnose Workshops6.7.2 Vor- und Nachteile von Diagnose-Workshops6.8 Teilnehmende Beobachtung
7 Datenaufbereitung – von der Analyse zum Bericht7.1 Schritte der Datenaufbereitung – Clustern7.1.1 Zusammenfassende Empfehlungen7.2 Diagnosebericht7.2.1 Kriterien eines guten Diagnoseberichtes7.2.2 Gliederung eines Diagnoseberichtes
8 Datenfeedback – Präsentation der Ergebnisse8.1 Ziele der Präsentation8.2 Vorbereitung der Präsentation8.2.1 Teilnehmerkreis festlegen8.2.2 Verteilung der Dokumentation klären8.2.3 Themenauswahl mit dem Auftraggeber klären8.2.4 Vorgehen und Dauer besprechen8.2.5 Ort und Arbeitsmittel festlegen8.2.6 Rollen im Rahmen der Präsentation vereinbaren8.2.7 Einladung für die Präsentation verschicken8.3 Durchführung der Präsentation
9 Anforderungsprofil für Diagnostiker:innen Mindset und Skills 9.1 Persönlichkeitsmerkmale 9.2 Rollenbewusstsein 9.3 Know-how 9.4 Qualifikationsprofil
10 Tipps, damit Ihre Projektdiagnosen scheitern Paradoxe Verschreibungen
Register
Bedeutung der Symbole
 | wichtig |
 | Empfehlung |
 | Checkliste |
Vorwort
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.
Dank
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.
1 Ziele des Buches
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.
1.1 Praxisfragen
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.
1.2 Übersicht über die einzelnen Kapitel
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.
Schwerpunkte Kapitel 2: Was bedeutet Projektdiagnose?
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
Schwerpunkte Kapitel 3 Auftragsklärung
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.
Schwerpunkte Kapitel 4 Grundlagen der Projektdiagnose
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.
Schwerpunkte Kapitel 5 Diagnosefelder mit den dazugehörenden Fragen
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 ProblemeDiagnostiker: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.
Schwerpunkte Kapitel 6 Methoden der Datensammlung
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
Schwerpunkte Kapitel 7 Datenaufbereitung – von der Analyse zum Bericht
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
Schwerpunkte Kapitel 8 Datenfeedback – Präsentation der Ergebnisse
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
Schwerpunkte Kapitel 9 Anforderungsprofil für Diagnostiker:innen
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
Kapitel 10 Tipps, damit Projektdiagnosen scheitern
Zu guter Letzt finden Sie nicht ganz ernstgemeinte Tipps im Sinne von paradoxen Verschreibungen, wie Sie es schaffen, Projektdiagnosen zum Scheitern zu bringen.
1.3 Zielgruppe
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
2 Was bedeutet Projektdiagnose?
2.1 Projektdiagnose
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:
1 DatensammlungDaten ü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.
2 DatenanalyseDatenanalyseDie 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“.)
3 Datenbewertung und EmpfehlungenAuf 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.
2.1.1 Daten sammeln
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:
1 Welche Daten werden benötigt, um ein möglichst klares Bild über den Zustand des Projektes zu erhalten?
2 Mit welchen Methoden werden die Daten am besten ermittelt?
2.1.1.1 Welche Informationen werden benötigt, um ein möglichst klares Bild über die Situation des Projektes zu erhalten?
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.
Datensammlung – einige Kernpunkte
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.
2.1.1.2 Mit welchen Methoden werden die Daten am besten ermittelt?
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:
1 Die richtigen Fragen stellenDiagnostiker: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.
2 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.
2.1.2 Datenanalyse
Nach der Datensammlung muss die Datenflut bewältigt werden. Eine Menge Arbeit, denn die Aussagen aus den einzelnen Interviews müssen gesichtet, sinnvoll eingeordnet und gründlich analysiert werden, nur so lassen sich die Ergebnisse bewerten und Empfehlungen ausarbeiten. Es stellt sich die Frage, nach welchen Kriterien die Daten geordnet werden können, um die Stärken und Schwächen des Projektes im Systemzusammenhang zu verstehen. Diagnostiker:innen müssen aus den vielen, unterschiedlichen Einzelteilen der Datensammlung ein Gesamtbild entwickeln. Strukturelle und personelle, fachliche und politische Ursachen müssen verstanden und Zusammenhänge hergestellt werden, um die Stärken und Schwächen des Projektes richtig einzuordnen. Damit sind hohe Anforderungen an Diagnostiker:innen verbunden.
1 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.
2 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.
2.1.3 Datenbewertung und Empfehlungen
Bewertungen und Empfehlungen sind ein unverzichtbarer Bestandteil jeder Diagnose, das gilt selbstverständlich auch für Projektdiagnosen. Stellen Sie sich vor, eine Hautärztin würde einen Patienten verabschieden mit der Aussage: „Sie haben auffällige Muttermale, schön, dass Sie da waren“, eine wahrlich schauderhafte Vorstellung.
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.
Nehmen wir zwei Beispiele aus der Praxis von Projektdiagnosen:
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.
2. Die Befragung von Mitarbeitern eines Projektteams ergab ein klares Bild: Projektmitarbeiter:innen arbeiten gleichzeitig über einen längeren Zeitraum in mehreren Projekten, häufig zehn bis zwölf Stunden pro Tag, um die Termine einzuhalten. Die Erschöpfung und die Unzufriedenheit sind hoch. Die Empfehlung der Diagnostikerin lautete: Eine klare Priorisierung ist dringend erforderlich, um die Arbeitszeiten der Projektmitarbeiter:innen auf ein vertretbares Maß von acht bis neun Stunden/Tag zu reduzieren. Sie nutzte die Bewertungskriterien „Zumutbarkeit für die Mitarbeiter:innen“ und „Risiken für das Unternehmen“, denn durch die hohe Belastung besteht die Gefahr, dass Mitarbeiter:innen kündigen und die Prioritätenprobleme sich negativ auf die Familien der Mitarbeiter:innen auswirken.
2.2 Wissenschaftlich fundierte psychologische Diagnosen und Projektdiagnosen – ein kurzer Vergleich
Mit der Gegenüberstellung von wissenschaftlich fundierten psychologischen Diagnosen und Projektdiagnosen möchte ich Kriterien für Projektdiagnosen darstellen.
Verglichen mit den Qualitätskriterien für wissenschaftlich fundierte psychologische Diagnosen sind die Kriterien für eine Projektdiagnose notwendigerweise deutlich weniger streng. Eine Gegenüberstellung der Gütekriterien von dieser wissenschaftlich fundierten Diagnostik und der Projektdiagnose erscheint mir dennoch interessant, um die Gütekriterien für die Bewertung von Projektdiagnosen besser einordnen zu können.1
Vergleich wissenschaftlich fundierte psychologische Diagnose und Projektdiagnose
| Wissenschaftlich fundierte psychologische Diagnose | Projektdiagnose |
| Objektivität Die Ergebnisse müssen unabhängig von Einflüssen der Diagnostiker:in oder der Untersuchungssituation zustande kommen. Das gilt für die Durchführung, Auswertung und Interpretation der Diagnose. | Neutralität In der Überschrift dieser Spalte steht Neutralität und das aus gutem Grund. Von Objektivität, obwohl dies von manchen Personen behauptet wird, darf nicht gesprochen werden, denn die Diagnostiker:innen beeinflussen durch die Auswahl ihrer Fragen, durch die Art und Weise des Fragens und durch die Aufbereitung der Daten zwangsläufig das Ergebnis. Die Projektdiagnostiker:innen bieten im Bericht ihre Sichtweise an, basierend auf fundierten Fragen, Erfahrungen und einer möglichst neutralen Haltung gegenüber allen Beteiligten. Neutralität sollte eine mentale und emotionale Voraussetzung der Projektdiagnostiker:innen sein. |
| Zuverlässigkeit (Reliabilität) Die Merkmale müssen zuverlässig gemessen werden, Messfehler sind zu vermeiden. | Zuverlässigkeit (Reliabilität) Dieses Merkmal trifft bei der Auswertung von Fragebögen bedingt zu, d.h. die Bögen müssen zuverlässig ausgewertet werden. Das setzt eine klare Formulierung der Fragen und eine geeignete Skalierung zur Beantwortung voraus. Bei Interviews lässt sich das Kriterium Zuverlässigkeit nicht anwenden, weil die Messbarkeit nicht gegeben ist. |
| Validität Eine diagnostische „Messung ist valide, wenn sie tatsächlich das misst, was sie messen soll, und somit glaubwürdige Resultate liefert. Soll die Zufriedenheit im Team gemessen werden, muss im Vorfeld klar definiert werden, was mit Zufriedenheit im Team gemeint ist. Andernfalls ist der Interpretationsspielraum zu groß und das Ergebnis nicht valide. | Validität Im Rahmen der Projektdiagnose spielt Validität bei der Formulierung des Fragebogens eine bedeutsame Rolle. Die Fragen müssen so klar formuliert sein, dass sie idealerweise von allen Befragten gleich verstanden werden. Werden Interviews durchgeführt, so müssen bestimmte Fragen in allen Interviews gestellt werden, um eine vergleichbare Einschätzung der Meinungen zu erhalten. |
| Akzeptanz Das Ausmaß, in dem persönliche Meinungen, Bewertungen oder gesellschaftspolitische Überzeugungen gegen einen Test angeführt werden. | Akzeptanz Akzeptanz ist für die Projektdiagnose ein wichtiger Faktor. Das trifft für die Auswahl der Fragen in Interviews bzw. im Fragebogen zu. Darüber hinaus kann auch der Nutzen der Diagnose an sich angezweifelt werden. |
| Fairness Werden Personengruppen z.B. nach Alter, Geschlecht, Religion, Kulturkreis u.a. gleichbehandelt oder gibt es offene oder verdeckte Diskriminierungen? Haben alle Personen die gleichen Chancen in einem psychologischen Test? | Fairness Fairness in der Vorgehensweise ist bei Projektdiagnosen ein wichtiges Thema. Wenn Projektmitarbeiter:innen und der Projektleitung kritische Fragen gestellt werden aber auf höheren Hierarchieeben sehr vorsichtig, behutsam Fragen gestellt werden, kann von Fairness keine Rede sein. Die Fragen und die Art und Weise des Fragens sollten unabhängig von der hierarchischen Position der Gesprächspartner:innen sein. |
| Testökonomie Steht der Aufwand im sinnvollen Verhältnis zum Nutzen des Verfahrens? Werden die Informationen, die durch das Verfahren gewonnen werden, für die diagnostische Entscheidung wirklich benötigt? | Ökonomie der Projektdiagnose Statt Testökonomie muss es Ökonomie der Projektdiagnose heißen. Der Aufwand der Projektdiagnose muss gerechtfertigt sein. Damit sind einige Fragen verbunden: - Lohnt sich die Diagnose zu diesem Zeitpunkt überhaupt? - Wird bei der Auswahl der Methode auch auf den zeitlichen und finanziellen Aufwand geachtet? - Kann die Anzahl der Interviewten eingeschränkt werden, ohne das Ergebnis signifikant zu gefährden? |
| Transparenz Ist das Verfahren für die Beteiligten verständlich? Können sich alle Beteiligten vorher genügend mit dem Verfahren vertraut machen? Gibt es anschließend ein angemessenes Feedback? | Transparenz Alle Beteiligten müssen über die Ziele und die Vorgehensweise informiert werden, ebenso darüber, was mit den Daten geschieht und in welcher Form die Befragten über die Ergebnisse der Diagnose informiert werden. Die Beteiligten haben einen moralischen Anspruch auf Feedback. |
| Unverfälschbarkeit Ist das Verfahren so konstruiert, dass der Kandidat, die Kandidatin die Ergebnisse möglichst nicht gezielt steuern oder verfälschen können? | Unverfälschbarkeit Dieses Kriterium lässt sich auf die Projektdiagnose nicht anwenden, weil Interviewte falsche, unvollständige Aussagen machen können. Außerdem können bei der Auswahl der Befragten bestimmte Personen, die möglicherweise eine kritische Meinung haben, ausgegrenzt werden. |
| Zumutbarkeit Belastet das Verfahren die Kandidat:innen in zeitlicher, psychischer Hinsicht nicht über Gebühr? | Zumutbarkeit Die zeitliche Belastung sollte bei der Planung der Befragungen nicht unterschätzt werden. Das gilt vor allem für Workshops, wenn diese über zwei Tage mit Übernachtung geplant werden. |
| Normierung Die Normierung eines Tests liefert das Bezugssystem, um die individuellen Testergebnisse im Vergleich zu denen einer Referenzpopulation einordnen zu können. Normen müssen hinreichend aktuell und repräsentativ für die Referenzpopulation sein. | Normierung Bei einer Projektdiagnose lassen sich nur bedingt Vergleiche zu anderen Projekten ziehen. Dennoch bestehen Vergleichsmöglichkeiten: Man könnte bei der Bewertung der Ergebnisse darauf hinweisen, dass die beinahe regelmäßige Arbeitszeit einiger Projektmitarbeiter von 12 Stunden/Tag im Vergleich zu ähnlichen Projekten in anderen Unternehmen viel zu hoch ist. Man kann die Entwicklungszeit eines Neuproduktes mit der Entwicklungszeit von Mitbewerbern vergleichen. Wo immer die Möglichkeit zum Vergleich besteht, sollte diese genutzt werden. Allerdings muss vorab genau geprüft werden, welche Aussagekraft der Vergleich wirklich hat. |
2.3 Projektreview, Audit, PM-Assessment – Begriffsklärung
Im Gegensatz zum Begriff Projektdiagnose, der bisher in der Projektmanagement-Literatur bisher nirgendwo aufgetaucht ist, sind Review, Audit und Assessment im Projektmanagement geläufige Begriffe, wobei die Trennschärfe zwischen Audit und Review nicht gegeben ist. Eine kurze Beschreibung der drei Begriffe dient hier einzig und allein dem Zweck, Projektdiagnose von Audit, Review und Assessment inhaltlich abzugrenzen, um Missverständnisse zu vermeiden. Auf die inhaltlichen und methodischen Unterschiede zwischen Audit, Review und Assessment gehe ich nicht ein, weil mir das für das Thema Projektdiagnose nicht erforderlich erscheint.
2.3.1 Projektreview und Projektaudit
Der Begriff ProjektreviewProjektreview ist in der Projektmanagement-Literatur nicht eindeutig definiert. Teilweise wird auf Projektaudit oder Assessment verwiesen1. Auch in der Praxis werden, abhängig vom Unternehmen, Reviews als Audits und Audits als Reviews bezeichnet.
Im Projektmanagement finden Reviews zu bestimmten Meilensteinen, am Ende einer Phase oder im agilen Projektmanagement eines Sprints statt, „um das zu diesem Zeitpunkt erreichte Projektergebnis möglichst objektiv zu betrachten. Der Fokus liegt normalerweise auf dem Grad der Zielerreichung, möglichen Risiken, dem Projektbudget und der Personalsituation des Projektes. „Je nach Größe und Wichtigkeit eines Projekts erfolgen Reviews entweder als moderierte und dokumentierte Sitzungen mit projektnahen Fachleuten oder in Form einer anonymisierten Stellungnahme durch projektferne Fachleute“.2
Der Begriff AuditAudit stellt einen stärkeren Bezug zum Managementsystem des Unternehmens her. Laut PM LEXIKON bedeutet Audit: „Systematische, unabhängige und dokumentierte Untersuchung von z.B. Organisationen, Produkten, Prozessen, Systemen, Programmen oder Projekten mit dem Ziel, Nachweise (Informationen, Daten, Fakten, Aufzeichnungen) zu erhalten, aufgrund derer objektiv begutachtet werden kann, inwieweit festgelegte Anforderungen erfüllt sind und/oder festgelegte Ziele erreicht werden“.3
Diese Definition zeigt, dass der Schwerpunkt des Projektmanagement-Audits eher auf den formalen Aspekten des Projektmanagements liegt. Auditor:innen beschäftigen sich überwiegend mit den Strukturen, den Prozessen und internen Regeln des Projektmanagements. Das muss nicht unbedingt so sein, stimmt aber in Regel mit der betrieblichen Praxis überein. Audits können einen wichtigen Beitrag zur Optimierung des Projektmanagements im Unternehmen leisten. Im Review wird mehr die fachliche Situation des Projekts analysiert, man kann von einer technischen, produktbezogenen Analyse sprechen. Dennoch werden auch in Reviews Soft Facts in die Untersuchung einbezogen, was nicht zuletzt von den Zielen der Durchführenden abhängig ist.
Der entscheidende Unterschied zur Projektdiagnose, so wie sie in diesem Buch beschrieben wird, besteht darin, dass Audits oder Reviews sich üblicherweise nicht mit den Kernursachen beschäftigen, die hinter den Symptomen liegen. In aller Regel werden vertiefende Fragen zur Zusammenarbeit, zu Entscheidungsprozessen, zu Macht und Politik nicht gestellt. Und das macht genau den Unterschied zwischen Reviews bzw. Audits und Projektdiagnosen aus, denn in der Diagnose werden Interessenkonflikte, Machtprozesse, paradoxe Entscheidungen, Wiederholungsmuster, By-Pass-Lösungen oder verlagerte Probleme ermittelt und analysiert. Diagnostiker:innen beschäftigen sich also mit der Logik und der Psycho-Logik der erkannten Probleme.
2.3.1.1 Review im agilen Projektmanagement
Im Gegensatz zum klassischen Projektmanagement ist der Terminus Review im agilen Projektmanagement (Scrum) klar definiert: Im sogenannten Sprint Review prüft das Scrum Team am Ende eines Sprints – ggf. mit weiteren, vom Product Owner eingeladenen Personen –die erreichten Ergebnisse und bespricht die Grundlagen für den nächsten Sprint. Reviews sind ein fester Baustein der agilen Projektarbeit. Neben Reviews kennt das agile Projektmanagement noch die Retrospektive, in der über die Zusammenarbeit im agilen Team (Scrum Team) gesprochen wird, um kontinuierliche Verbesserungen für die gemeinsame Projektarbeit zu erreichen. Typische Themen sind Kommunikation, Information, gegenseitige Unterstützung im positiven wie im negativen Sinne. Die Retrospektive ist eine Lessons Learned-Maßnahme.
2.3.2 Projektmanagement-AssessmentAssessment
Der Vollständigkeit halber sei noch das PM-Assessment erwähnt. Auf der Webseite der GPM (Deutsche Gesellschaft für Projektmanagement e.V.) findet man zum Thema PM-Assessment: „Ein Projektmanagement-Assessment kann für die Analyse, Beurteilung und Bewertung des Entwicklungsstandes, der Güte, der Reife bzw. der Kompetenz von Organisationen und Personen im Projektmanagement nach bestimmten Kriterien und Bewertungsmaßstäben herangezogen werden“1, um möglichen Handlungsbedarf für die Weiterentwicklung des Projektmanagement-Systems im Sinne eines kontinuierlichen Verbesserungsprozesses zu ermitteln. Im PM-Assessment wird also der Reifegrad des Projektmanagement-Systems analysiert, definitiv eine andere Aufgabe als eine Projektdiagnose.
2.4 Anlässe für Projektdiagnosen und Reviews
2.4.1 Anlässe für Reviews
Um die Anlässe für eine Projektdiagnose besser einordnen zu können, erscheint mir ein kurzer Ausflug zu den Anlässen von Projektreviews hilfreich. Projektreviews werden aus verschiedenen Anlässen durchgeführt, wobei es regelmäßig stattfindende und außerplanmäßige Reviews gibt.
Im klassischen Projektmanagement, oft wird der Begriff Wasserfall-Modell benutzt, werden Reviews in Unternehmen häufig zu fest vereinbarten Terminen geplant, die man auch als Meilenstein-Reviews bezeichnet. Teilweise werden diese Bestandsaufnahmen auch Audit genannt. Neben diesen regelmäßigen Reviews als fester Prozessschritt in einem Projektmanagement-System im Unternehmen, können Reviews auch zu besonderen Anlässen durchgeführt werden, wenn es die kritische Situation des Projektes erfordert. In solchen Reviews wird der Stand des Projektes, der Grad der Zielerreichung, technische Probleme, das Budget, die Verfügbarkeit von Projektmitarbeitern, unklare Zuständigkeiten im Projekt bzw. in der Organisation, Risiken oder die Auswirkungen von moving targets auf das Projekt untersucht. Daneben kann auch der Informationsfluss, der Umgang mit Prioritätenkonflikten oder die Zusammenarbeit im Team ermittelt werden, der Einfluss von Soft Facts ist also nicht ausgeschlossen. Normalerweise liegt der Schwerpunkt in Reviews auf den Hard Facts, der Fokus auf inhaltlichen Themen. Selbstverständlich werden auch in der Projektdiagnose all die oben genannten Diagnosefelder ermittelt, analysiert und bewertet, der entscheidende Unterschied liegt wie bereits beschrieben im Umfang und in der Tiefe der Analyse. Je stärker im Review Fragen und Methoden der Projektdiagnose integriert werden, desto mehr werden die Grenzen zwischen Review und Diagnose verschwimmen. Reviewer:innen sind gut beraten, sich das Repertoire der Projektdiagnose anzueignen.
2.4.2 Anlässe für Projektdiagnose
Es gibt verschiedene Anlässe für ProjektdiagnosenAnlässe für ProjektdiagnosenProjektdiagnoseAnlässe, die zu unterschiedlichen Zeitpunkten durchgeführt werden können.
1 Am häufigsten werden Diagnosen durchgeführt, wenn Fehlentwicklungen, nicht selten verbunden mit Orientierungslosigkeit, Schuldzuweisungen oder Konflikten auftreten und anzunehmen ist, dass die Gründe nicht rein technischer, fachlicher Natur sind, sondern durch schlechtes Projektmanagement, unklare Rollen oder mangelnde Zusammenarbeit im Projekt verursacht werden. Teilweise sind die Probleme seit längerer Zeit bekannt, doch die bisherigen Lösungsversuche blieben erfolglos oder es wurde nur halbherzig etwas unternommen.
2 Eine Projektdiagnose wird für besonders wichtige oder kritische Projekte geplant. Dabei kann es sich um Projekte von großer strategischer Bedeutung, wichtige Kundenprojekte oder um ein Nachfolgeprojekt eines gescheiterten Projektes handeln.
3 Probleme in der Projektarbeit bahnen sich am Horizont an und Fehlentwicklungen sollen verhindern werden. Häufiger basiert die Entscheidung auf Gesprächen zwischen der Projektleitung und dem Projektsponsor, wobei die Initiative für die Diagnose nach meiner Erfahrung häufiger von der Projektleitung oder vom Projektteam ausgeht, vor allem dann, wenn der Leidensdruck dort besonders groß ist.
4 Sehr selten wird eine Diagnose initiiert, um ganz gezielt die besonderen Merkmale eines erfolgreich laufenden Projektes zu ermitteln. Der Auftraggeber oder die Auftraggeberin wollen die Stärken dieser Projektarbeit im Unternehmen vermitteln, um Akzeptanz für das Projekt oder für das Projektmanagement-System im Allgemeinen zu steigern.
5 Durch eine systematische Analyse zum Projektabschluss (Lessons Learned) sollen Erkenntnisse aus dem Projektverlauf für zukünftige Projekte gewonnen werden. Dafür werden unterschiedliche Begriffe in der Praxis verwendet: Lessons Learned, Post Projekt Review, selten Post Mortem Analyse. Bezüglich Projektdiagnose erscheint mir der Begriff Lessons Learned am besten geeignet, denn Bruchstellen können Fundstellen sein. Viele Fragen der Projektdiagnose können auch für Lessons Learned Aktionen genutzt werden.
6 Eine besondere Form der Projektanalyse stellt das Projekt Preview als proaktive Maßnahme dar. Hier kann nicht von Projektdiagnose gesprochen werden, doch eine Reihe von Diagnosefragen können schon zu diesem Zeitpunkt gestellt werden. Bereits in einer frühen Phase des Projekts soll analysiert werden, ob das Projekt auf einer soliden inhaltlichen und organisatorischen Basis steht, wobei sich organisatorisch auf das Projektmanagement mit Strukturen und Verhalten bezieht. Für die inhaltliche Analyse oder eine präventive Risikoanalyse ist Fachwissen zwingend erforderlich. Hier dürften die Diagnostiker:innen in aller Regel überfordert sein. Erstaunlicherweise wird der Nutzen eines fundierten Projekt Previews zu wenig gesehen oder unterschätzt. Ich bin davon überzeugt, dass manche Projektdiagnose überflüssig wäre, wenn man mehr in die Prävention investieren würde.
Abb. 1:
Anlässe für Diagnosen und Reviews
2.4.3 Wann sollte eine Diagnose nicht durchgeführt bzw. vorzeitig beendet werden?
Eine Projektdiagnose sollte nicht durchgeführt bzw. vorzeitig beendet werden, wenn folgende Situationen auftreten:
ZeitmangelNotwendige Interviews können nicht durchgeführt werden, weil die Beteiligten zu wenig Zeit haben oder sich die Zeit einfach nicht nehmen. Das ist nicht immer einfach zu unterscheiden. Die Diagnostiker:innen müssen dieses Thema mit dem Auftraggeber bzw. der Auftraggeberin der Diagnose besprechen, denn sie haben die Verantwortung, die Situation zu ändern.
Es gibt keinen AuftraggeberAuch nach intensivem Bemühen lässt sich nicht klären, wer eigentlich Auftraggeber der Projektdiagnose ist. Wie bei Projekten, so gilt auch hier: Keine Diagnose ohne eine klare Auftraggeber:in. Wenn der Auftraggeber des Projektes eine neue Aufgabe übernommen hat, muss geprüft werden, ob die nachfolgende Person weiterhin an der Diagnose interessiert ist. Besteht kein Interesse, so ist ein Abbruch empfehlenswert.
Mangelndes Interesse, fehlender LeidensdruckDie Aussage, es gibt keine Diagnose, ohne die Absicht die erkannten Schwachstellen zu beseitigen, erscheint mir so generell formuliert, nicht haltbar, denn sie entspricht nicht immer der Realität. Diagnostiker:innen sollten nicht davon ausgehen, dass die Beauftragung einer Diagnose automatisch mit dem notwendigen Interesse an den Ergebnissen bzw. den sich daraus ergebenden Maßnahmen verbunden ist. Leidensdruck bei den Entscheider:innen ist insofern positiv, weil damit die Wahrscheinlichkeit, Veränderungsmaßnahmen durchzuführen, steigt. Auch darf man nicht davon ausgehen, dass der Leidensdruck konstant bleibt; mag sein, dass er in der Anfangsphase der Diagnose hoch war, doch im weiteren Verlauf deutlich gesunken ist. Sprechen Sie solche Veränderungen an. Klären Sie, ob genügend Bereitschaft vorhanden ist, sich mit den Ergebnissen der Diagnose ernsthaft auseinanderzusetzen.
Das Projekt ist sehr weit fortgeschrittenEine Projektdiagnose ist nicht ratsam, wenn sich ein Projekt trotz großer Probleme und Konflikte in der Endphase befindet und die Beteiligten sich entschieden haben, die Angelegenheit endlich zum Abschluss zu bringen. Durch eine Diagnose können mühsam gelöste Probleme oder unterdrückte Konflikte wieder auftauchen und erreichte Kompromisse zwischen Organisationseinheiten und Personen wieder zerbröckeln. In solchen Fällen sollte man sich bis zum Projektende gedulden um anschließend eine fundierte Lessons Learned-Maßnahme durchzuführen.
Frühzeitiger ErkenntnisfortschrittWenn sich nach einer Reihe von Interviews zeigt, dass immer wieder ähnliche oder gleiche Antworten auf die verschiedenen Fragen gegeben werden, sollte überlegt werden, ob der weitere zeitliche und finanzielle Aufwand gerechtfertigt ist. Es ist nicht vertretbar an einem einmal geplanten Vorgehen festzuhalten, wenn eine weitere Datensammlung für die Diagnose keinen Zusatznutzen bringt.
2.5 Der Diagnoseprozess von der Auftragsklärung bis zur Präsentation der Diagnoseergebnisse – Überblick
Eine Projektdiagnose kann in sechs aufeinander aufbauende Phasen unterteilt werden. Beginnend mit der Initiierungsphase und der Auftragsklärung geht es über die Datensammlung und -aufbereitung bis zur Präsentation der Ergebnisse. Hier endet die Projektdiagnose, weil die Entscheidung über die Folgemaßnahmen und deren Realisierung nicht Bestandteil der Projektdiagnose sind. Mit anderen Worten, die Verantwortung der Diagnostikerin endet mit der Präsentation der Ergebnisse und sie geht dann auf den Auftraggeber bzw. die Auftraggeberin über. Dieser Wechsel in der Verantwortung muss im Rahmen der Auftragsklärung unbedingt besprochen werden.
Phasen der ProjektdiagnoseProjektdiagnosePhasen – ein Überblick
| Phase | Ziel |
| Initiierungsphase | Die Entstehungsgeschichte mit dem Kontext verstehen. |
| Auftragsklärung | Alle relevanten Punkte für die Diagnose klären. |
| Datensammlung | Die richtigen Fragen stellen und die Fragen gekonnt stellen. |
| Datenanalyse und Bewertung | Die Ergebnisse der Befragung zu einem sinnvollen Gesamtbild zusammenfügen und bewerten. |
| Bericht ausarbeiten | Die Ergebnisse mit konkreten Empfehlungen klar, nachvollziehbar und verdaubar formulieren. |
| Datenfeedback | Die Ergebnisse klar vermitteln. Mit dem Datenfeedback endet die Diagnose. |
3 Auftragsklärung
3.1 Initiierung – Vorgeschichte der Diagnose verstehen
Die Arbeit der Diagnostiker:innen beginnt normalerweise vor dem offiziellen Start der Diagnose. Schon im Vorfeld können wichtige Informationen über die Hintergründe der Diagnose, die Erwartungen und Interessen der Beteiligten gesammelt werden. Versuchen Sie sich ein möglichst genaues Bild über den Entstehungsprozess zu machen. Warum soll eine Diagnose durchgeführt werden, wer verspricht sich was davon? Wer ist am Diskussionsprozess beteiligt? Kontextklärung spielt eine große Rolle, dazu gehört auch zu erfahren, warum das Management gerade Sie als mögliche Diagnostiker:in ausgewählt hat. Ist es Ihr guter Ruf? Schätzt man Sie, weil Sie die Probleme gründlich erfassen und deutlich kommunizieren? Traut man es Ihnen vor allem deshalb zu, weil Sie ein Projektmanagement Zertifikat erworben haben? Sind sie empfohlen worden, wenn ja, von wem? Nutzen Sie, falls möglich, Gespräche mit der Projektleitung, den Projektmitarbeiter:innen, dem Sponsor bzw. der Sponsorin des Projektes und mit Linienmanager:innen, um sich einen ersten Eindruck über die Situation des Projektes und die Erwartungen an die Diagnose zu verschaffen. Der Kontakt mit dem Linienmanagement darf nicht unterschätzt werden, denn sie können in unterschiedlicher Weise in das Projekt involviert sein, sei es als Ressourcenmanager:in, als interne Lieferant:innen für das Projekt oder weil ihre Organisationseinheiten vom Projektverlauf oder den Projektergebnissen betroffen sind. Das gilt vor allem bei Restrukturierungs- oder Prozessoptimierungsprojekten. Wie auch immer, Führungskräfte können die Diagnose fördern, aber auch blockieren.
Es gibt unterschiedliche Anlässe und Initiator:innen für Projektdiagnosen. Je besser Sie den Anlass und die Akteure kennen, desto besser kann die Auftragsklärung gelingen. Nach meiner Erfahrung gibt es drei typische Gründe, warum eine Diagnose durchgeführt werden soll:
Die Auftraggeber:innen des Projektes sind mit den Zwischenergebnissen nicht zufrieden, weil die geplanten Meilensteine nicht erreicht werden. Wiederholt hören sie Klagen über die schlechte Zusammenarbeit im Projektteam, über unklare Zuständigkeiten oder über die mangelnde Unterstützung von Linienmanager:innen. Sie versprechen sich von der Diagnose zuverlässige Informationen über die Ursachen der Probleme mit konkreten Empfehlungen.
Im Steering Committee bestehen seit geraumer Zeit unterschiedliche Meinungen über die Ergebnisse und den Verlauf des Projektes. Die Bereichsleiterin R&D (Research & Development) ist mit dem Projektverlauf im Großen und Ganzen zufrieden, während ihre Kollegen aus dem Marketing und der Produktion immer wieder auf die Schwachstellen im Projektmanagement hinweisen. Dabei wird mit dem Finger auf fehlende Abstimmungen, schlechte Planung und mangelnde Verbindlichkeit der Projektbeteiligten hingewiesen, wobei sich die Kritik vornehmlich auf das R&D Management bezieht. Dagegen sieht die Bereichsleiterin R&D die Ursachen vor allem beim Marketing, weil die Projektziele immer wieder geändert werden. Die Diskussion ist geprägt von Schuldzuweisungen und Unterstellungen. Die Geschäftsleitung hat entschieden, diese Problematik mit Hilfe einer Diagnose nachhaltig in den Griff zu bekommen, zumal ähnliche Diskussionen auch in anderen Projekten aufgetreten sind.
Interessenkonflikte zwischen Abteilungen und widersprüchliche Entscheidungen von Führungskräften erschweren die Arbeit des Projektteams erheblich. Projektmitarbeiter:innen stehen im Spannungsfeld zwischen Mitarbeit im Projektteam und den Vorgaben ihrer Linienmanager:innen. Der Projektleitung ist es nicht gelungen, diese Probleme im Team zu lösen und auch Gespräche mit Führungskräften haben nichts gebracht. Die Projektleitung hat die Situation mit dem Head of Project Portfolio Management und dem eigenem Linienmanagement besprochen mit dem Ergebnis, den Projektsponsor von der Notwendigkeit einer Projektdiagnose zu überzeugen.
3.1.1 Worauf sollten Diagnostiker:innen im Vorfeld achten?
Einfache Fragen können Ihnen helfen, die Ausgangssituation der Projektdiagnose besser zu verstehen.
Warum wird eine Projektdiagnose erwogen? Befindet sich das Projekt in einer besonderen Schieflage oder gibt es andere Gründe?
Sollen fachliche, technische Probleme untersucht werden oder geht es primär um die Analyse des Projektmanagements, wie die Zusammenarbeit im Team, Klarheit der Ziele, schlechte Planung oder um die Entscheidungsprozesse im Steering Committee? Projektdiagnostiker:innen sollten frühzeitig die Erwartungen der Beteiligten erfassen und einordnen. Dadurch wird die eigentliche Auftragsklärung erleichtert.
Gibt es Themen, die besonders hervorgehoben werden? Werden diese nur von einer Person genannt oder von mehreren? Stammen sie aus nur einer Organisationseinheit oder aus verschiedenen?
Gibt es Themen, die man nur hinter vorgehaltener Hand erwähnt? Wozu werden Ihnen diese Themen mitgeteilt? Möglicherweise möchte man Sie in eine bestimmte Richtung lenken oder zum Bündnispartner machen. Nehmen Sie solche Aussagen aufmerksam wahr, doch verlieren Sie nicht Ihre Neutralität.
Gab es bereits Maßnahmen, um die Situation des Projektes zu verbessern? Wenn ja, warum führten sie nicht zum Erfolg?
Wer ist Initiator:in der Diagnose? Welchen Einfluss haben diese Personen?
Welche Akteure aus welchen Organisationseinheiten sind an der Entscheidung beteiligt, ob eine Projektdiagnose durchgeführt werden soll?
Welche Organisationseinheiten und Personen sind nicht einbezogen? Besteht kein Interesse an der Diagnose oder werden sie gezielt ausgegrenzt?
Wird die Meinung der Projektleitung zur Diagnose gehört oder wird über ihren Kopf hinweg entschieden? Wenn ja, warum?
Sind die Projektbeteiligten, insbesondere die Projektleitung und das Projektteam darüber informiert, dass über eine Diagnose nachgedacht wird?
Achten Sie in ihren Gesprächen nicht nur auf den Inhalt, sondern auch darauf, was zwischen den Zeilen gesagt wird. Halten die Gesprächspartner:innen eine Diagnose überhaupt für notwendig oder stehen sie dieser Idee eher ablehnend gegenüber? Ironie, Schuldzuweisungen, zweifelndes Kopfschütteln oder negative Kommentare über das Projekt, die Projektleitung oder den Sponsor können Ihnen wertvolle Hinweise liefern. Nehmen Sie solche Informationen aufmerksam wahr, denn sie können Ihnen für die Auftragsklärung und auch im weiteren Verlauf der Arbeit wertvolle Dienste leisten. Machen Sie sich zeitnah Notizen. Im Kern geht es dabei um die Frage, wer die Diagnose unterstützen bzw. blockieren kann.
3.2 Auftragsklärung
Die Bedeutung eines klaren und verbindlichen Projektauftrags wird völlig zurecht sowohl in der Praxis als auch in der Projektmanagementlehre hervorgehoben. Das gilt ohne Abstriche auch für Projektdiagnosen. Die Auftragnehmer:innen müssen eine Reihe von Punkten mit dem Auftraggeber der Diagnose klären, damit diese erfolgreich durchgeführt werden kann. Die wesentlichen Inhalte der Auftragsklärung finden Sie auf den nächsten Seiten. Doch Papier ist bekanntlich geduldig, am Ende zählt, inwieweit Klarheit erreicht wurde und ob die Vereinbarung eingehalten wird.
Die AuftragsklärungAuftragsklärung selbst sollte als Bestandteil der Diagnose verstanden werden, denn bereits zu diesem frühen Zeitpunkt werden Fehlentwicklungen im Projekt geschildert, Ursachen und häufig auch Verursacher:innen genannt, wobei es sich um reale oder vermeintliche handeln kann. Das wird sich erst später in der Diagnose herausstellen. Nicht selten bestehen seitens der Entscheider:in bereits mehr oder minder klare Erwartungen an die Ergebnisse, sie wissen oder glauben zu wissen, was dabei herauskommen soll und welche Lösungen anzustreben sind. Erwartungen, Vorstellungen und Vermutungen des Managements sollten aufmerksam wahrgenommen und kritisch hinterfragt werden. Unprofessionell wäre es, wenn die Auftragsklärung nach dem Motto „wer bezahlt, bestimmt die Musik“ abläuft. Die Auftraggeberin verkündet die gewünschte Lösung und der Aufragnehmer nimmt die Anweisung pflichterfüllend entgegen. Damit wäre der diagnostischen Arbeit das seriöse Fundament entzogen und beim Ergebnis dürfte es sich eher um ein Gefälligkeitsgutachten handeln.
Der Auftragsklärungsprozess bietet wertvolle Informationen und sollte als Fundgrube für die Diagnose geschätzt werden. Diagnostiker:innen sind gut beraten, Ohren und Augen weit zu öffnen, um erste Eindrücke zu sammeln und Annahmen über die Situation des Projektes zu entwickeln.
Grundsätzlich müssen zwei Fragen beachtet werden, um eine tragfähige Vereinbarung zu erreichen:
1 Was muss ich klären? (Inhalte des Diagnoseauftrags)
2 Wie muss ich klären? (Vorgehensweise, um den Auftrag zu klären)
Beide Fragen werden im Folgendem erläutert.
3.2.1 Was muss ich klären?
Die wesentlichen Inhalte auf einen Blick
1 Ziele, inhaltliche Abgrenzung und Rahmenbedingungen
2 Systemgrenze der Projektdiagnose
3 Rollen im Rahmen der Diagnose
4 Vorgehensweise
5 Rechtliche Rahmenbedingungen
6 Organisatorisches
7 Abstimmungsprozesse und Informationsfluss
8 Zeitplan
9 Aufwandschätzung, Kosten
Diese Punkte müssen mit dem Auftraggeber der Projektdiagnose geklärt werden. Er muss nicht alle Punkte kennen, sondern die Diagnostiker:innen sind dafür verantwortlich, dass die relevanten Inhalte angesprochen werden. Bereits an dieser Stelle möchte ich darauf hinweisen, dass eine Checkliste für die Auftragsklärung wenig nutzt, wenn Unklarheiten oder unrealistische Erwartungen nicht offen angesprochen werden. Auf dieses zentrale Thema gehe ich unter Abschnitt 3.2.2 ein.
3.2.1.1 Ziele, inhaltliche Abgrenzung und Rahmenbedingungen der Diagnose
Eine Zielklärung steht und fällt mit den richtigen Fragen. Zunächst müssen die Ziele, der Umfang und die Tiefe der Projektdiagnose geklärt werden.
Was ist das Ziel der Diagnose?
Was ist aus Sicht des Auftraggebers bzw. der Entscheider:innen erreicht, wenn die Projektdiagnose erfolgreich durchgeführt worden ist?
Welche Erwartungen hat der Auftraggeber bzw. die Auftraggeberin?
Was ist dem Aufraggeber besonders wichtig?
Wie kommt die Diagnose zustande? Wer hatte die Idee?
Welche Themen sollen aus Sicht des Auftraggebers nicht analysiert werden?
Ziele und Themen der Diagnose unterscheiden
Grundsätzlich müssen im Rahmen der Auftragsklärung drei Themengebiete deutlich unterschieden werden. Darüber muss mit Auftraggebern:innen ausführlich gesprochen werden, um Missverständnisse zu vermeiden.
1. Untersuchung des Projektfortschritts
Die Ergebnisse bzw. Zwischenergebnisse des Projektes sollen ermittelt, analysiert und bewertet werden. Es geht um die inhaltlichen, fachlichen, technischen Themen, die nur mit dem notwendigen Fachwissen beantwortet werden können. Hier sollte nicht von Projektdiagnose gesprochen werden, sondern von Review, Audit oder Qualitätskontrolle. Wesentliche Themen sind beispielsweise:
Stand der Zwischenergebnisse (quantitativ und qualitativ) und der damit verbundenen Prognose über den weiteren Projektfortschritt
Analyse von Testergebnissen
Welche fachlichen, technischen Risiken gibt es?
Werden Qualitätsnormen eingehalten?
Kann der Endtermin angesichts der aktuellen Situation erreicht werden?
Welche Auswirkungen ergeben sich aus der aktuellen Situation für das Budget?
Könnten rechtliche Risiken bei Verzögerungen auftreten?
Noch mal, um diese Punkte seriös zu bearbeiten, sind Fachwissen, technisches Know-how und Produktkenntnisse zwingend erforderlich. In fachlich komplexeren Projekten können diese Fragen nicht von einer Person analysiert werden, sondern nur von einem Review Team. Ich habe viele Projektdiagnosen durchgeführt und stets darauf hingewiesen, dass ich nicht in Lage bin, mich zu inhaltlichen Fragen zu äußern. In einigen Fällen mit der Konsequenz, dass ich den Auftrag nicht bekommen habe. Dennoch, diese thematische Abgrenzung ist zwingend erforderlich.
2. Analyse des Projektmanagements
Bei der Projektdiagnose steht das Projektmanagement im Fokus. Dazu gehören u.a. die Analyse der Rollen im Projekt, die Entscheidungsprozesse im Steering Committee, der Einfluss des Sponsors und des Linienmanagements und die Zusammenarbeit im Projektteam. Selbstverständlich wird auch die zeitliche Verfügbarkeit der Projektmitarbeitenden, die Klarheit der Projektziele, der Informationsfluss und der Umgang mit Konflikten untersucht. Mit anderen Worten, der Einfluss von Hard- und Soft Facts ist Gegenstand der Analyse aber nicht die technischen, inhaltlichen Probleme des Projektes.
3. Untersuchung des Projektfortschritts und Analyse des Projektmanagements
In manchen Fällen soll das Projekt umfassend analysiert werden, also sowohl die Fachinhalte als auch das Projektmanagement sollen untersucht werden. Dazu bedarf es mehrerer Disziplinen. Bei der Zusammenstellung eines Teams von Diagnostiker:innen müssen die Zuständigkeiten der Beteiligten, die Abstimmungsprozesse und das Vorgehen gründlich geklärt werden. Insbesondere muss der Umgang mit zwangsläufig auftretenden Überlappungen besprochen werden. Konkurrenzverhalten zwischen den Beteiligten schadet der gemeinsamen Arbeit, deshalb sind regelmäßige jour fix empfehlenswert, um die Zusammenarbeit gemeinsam zu reflektieren.
Klären Sie mit dem Auftraggeber der Diagnose die Themengebiete gewissenhaft und machen Sie sehr deutlich, welche Gebiete Sie fachlich abdecken können und welche nicht. Darüber dürfen Sie weder die Auftraggebenden noch sich selbst täuschen.
3.2.1.2 Systemgrenze der Projektdiagnose
Die Definition der SystemgrenzeSystemgrenze ist mit der Zielklärung unmittelbar verbunden. Sie ist von größter Bedeutung für die Projektdiagnose, denn sowohl die Durchführung als auch das Ergebnis werden durch die Systemgrenze direkt beeinflusst.
Was bedeutet Systemgrenze? Mit der Festlegung der Systemgrenze wird die organisatorische Reichweite der Projektdiagnose bestimmt. Es geht konkret um die Frage, welche Subsysteme der Projektorganisation untersucht werden sollen, wer in den Diagnoseprozess einbezogen wird und welche Fragestellungen sich daraus ergeben.
Sollen beispielsweise die Mitglieder des Steering Committees und der CIO (Chief Information Officer) im Rahmen der Datenerhebung interviewt werden oder nicht? Sollen die Sichtweisen der Lieferant:innen oder der Kund:innen über die Situation des Projektes ermittelt werden? Antworten auf solche Fragen sind von größter Bedeutung für die Durchführung der Diagnose. Generell gilt:
Die Systemgrenze muss im Rahmen der Auftragsklärung besprochen und vereinbart werden, weil sie das Ergebnis der Diagnose entscheidend beeinflusst. Diagnostiker:innen müssen das „System Projekt“ und das „System Organisation“ verstehen, nur so kann die Systemgrenze sinnvoll, den Zielen der Diagnose entsprechend, bestimmt werden. Die Diagnostiker:innen sollten im Rahmen der Auftragsklärung allergrößten Wert darauflegen, dass die Systemgrenze den Zielen der Diagnose entspricht.
Projekt und Projektteam unterscheiden
Ich möchte an einem Praxisbeispiel mit einem groben Missverständnis aufräumen, das mir in meiner Arbeit immer wieder begegnet. Im Steering Committee waren alle damit einverstanden, eine Projektdiagnose durchzuführen, denn man versprach sich davon, dass die Probleme im Projektteam erkannt und beseitigt werden. Als ich erklärte, dass ich im Rahmen der Projektdiagnose nicht nur die Situation des Projektteams analysiere, sondern auch die Entscheidungsprozesse im Steering Committee und den Einfluss des Sponsors untersuchen werde, nahm die Zustimmung einiger Mitglieder des Steering Committees deutlich ab. Irrtümlicherweise setzen viele Projekt gleich Projektteam und das ist einfach verkehrt, denn das Projektteam ist ein Subsystem des Projektes. Zum Projekt und damit auch zur Diagnose gehören neben dem Projektteam auch Sponsor, Entscheidungsgremien, das Projekt Portfolio Management und andere Stakeholder des Projekts. Selbstverständlich müssen auch Linienmanager:innen in die Diagnose einbezogen werden, weil sie als Ressourcenmanager:innen für die fachliche und zeitliche Verfügbarkeit der Projektmitarbeiter:innen verantwortlich sind. In Change-Management-Projekten sind sie außerdem für die Implementierung der Projektergebnisse in ihren Organisationseinheiten verantwortlich.
Die Systemgrenze hängt vom Umfang des Projektes ab. Für eine sinnvolle Analyse der Diagnose lautet die Frage: Welche internen und ggfs. auch externen Organisationseinheiten müssen beteiligt werden, um ein aussagekräftiges Bild über den Projektverlauf zu erhalten? Soweit der Anspruch, doch in einigen Fällen habe ich die Erfahrung gemacht, dass Auftraggeber:innen mit meinem Verständnis der Systemgrenze nicht einverstanden waren. Ein Praxisbeispiel: Der Leiter der Produktentwicklung eines mittelständischen Unternehmens beauftragte mich, eine Diagnose für ein Projekt durchzuführen, das seit längerer Zeit nicht optimal läuft. Aus seiner Sicht ging es nicht primär um fachliche Themen, sondern um die Zusammenarbeit zwischen den beteiligten Abteilungen, um unklare Zuständigkeiten, Bereichsdenken, mangelnde Abstimmungen und intransparente Entscheidungen. Offensichtlich hatte er sich ein Bild über die Problematik gemacht und er hatte sehr genaue Vorstellungen, mit wem ich Interviews führen sollte: Projektleitung, Projektmitarbeiter:innen, Gruppen- und Abteilungsleitern:innen der beteiligten Abteilungen (Konstruktion, Produktmanagement, Einkauf, Qualitätssicherung). Nun wusste ich durch Vorgespräche, dass die beiden Geschäftsführer häufig ohne Abstimmung mit der Projektleitung ins Projektgeschehen eingreifen. Prioritäten werden dann über den Haufen geworfen, Projektziele verändert, weil einer der beiden Geschäftsführer, verantwortlich für den Verkauf, mit dem Kunden eine neue Vereinbarung getroffen hatte. Weder die Projektleitung noch die Abteilungsleitungen wurden in diese Entscheidungen einbezogen. Ich erklärte dem Auftraggeber der Diagnose, dass Interviews mit den beiden Geschäftsführern unbedingt erforderlich sind, um die Situation des Projektes zu analysieren. Seine Antwort war eindeutig: „Sie haben völlig recht, aber das ist mir zu heiß. Das könnte Ärger geben, zumal die beiden Geschäftsführer längst nicht immer an einem Strang ziehen und gerne den Druck auf die Abteilungsleiter und die Projektteams weitergeben“. (Originalzitat aus einem Interview). Ich erklärte dem Auftraggeber, dass ich es für angebracht halte, zunächst ein Gespräch mit ihm und den beiden Geschäftsführern zu führen, um deren Meinung zu der geplanten Maßnahme zu erfahren. Das Gespräch fand statt und am Ende hatten wir ein gutes Ergebnis erreicht. Die neuen Auftraggeber der Diagnose waren die Geschäftsführer und damit war die Diagnose hierarchisch richtig angesiedelt. Was folgt aus diesem Beispiel? Diagnostiker:innen dürfen sich auf keinen Fall mit einer vorgegeben Systemgrenze zufriedengeben, wenn ihnen diese ungeeignet erscheint, das Projekt sinnvoll zu analysieren.
Die richtige und klare Definition der Systemgrenze gehört zu den elementaren Aufgaben der Auftragsklärung, denn die Bestimmung der Systemgrenze beeinflusst, wer befragt wird und welche Fragen gestellt werden. Oberflächlichkeit und Nachlässigkeit haben hier keinen Platz.
Setzen Sie nie Projekt gleich Projektteam, das Team ist ein Subsystem des Projektes. Diese Trennung muss verstanden und beachtet werden.
Die Projektdiagnostiker:innen müssen die Entscheidungsträger bei der Definition der Systemgrenze beraten.
Eine vorgegebene Systemgrenze sollte nicht akzeptiert werden, wenn dadurch eine fundierte Diagnose erschwert oder gar verhindert wird.
Systemgrenzen unterscheiden
Bei der Definition der Systemgrenze im Rahmen der Projektdiagnose können drei verschiedene Systeme unterschieden werden:
1 Projektteam
2 System Projekt intern
3 System Projekt mit unternehmensexterner Beteiligung
1. Systemgrenze Diagnose des Projektteams
Selbstverständlich kann die Arbeit des Projektteams mit seinen Stärken und Schwächen analysiert werden. So werden beispielsweise der Grad der Zielerreichung, die zeitliche Verfügbarkeit der Teammitglieder, die Kommunikation im Team, der Informationsfluss, die Verbindlichkeit von Zusagen, die Qualität der Meetings, der Einsatz von Planungsmethoden oder die Führung der Projektleitung analysiert. Um die Situation des Projektteams zu verstehen, muss auch der Einfluss des Teamumfeldes (Entscheidungsgremien, Sponsor) auf das Team verstanden werden. Im Kapitel 5.3 Diagnose des Projektteams wird dieses Thema ausführlicher behandelt.
Bezieht sich die Diagnose nur auf das Subsystem ProjektteamSubsystem Projektteam, ist Bezeichnung Projektdiagnose nicht korrekt, denn die Untersuchung bezieht sich nicht auf das Projekt, sondern nur auf das Team. Zum Projekt gehören auch das Steering Committee, der Sponsor und die Linienmanager. Mit dieser definitorischen Klarstellung soll auf keinen Fall der Nutzen von Teamdiagnosen in Frage gestellt werden. Im Gegenteil, manche Projektdiagnose wäre vermeidbar, wenn man die Teamarbeit rechtzeitig und fundiert analysieren würde.
Abb. 2:
Systemgrenze Projektteam
Auftraggeber:in einer Teamdiagnose kann die Projektleitung, das gesamte Projektteam oder der Projektsponsor sein. Hier besteht ein wesentlicher Unterschied zur Projektdiagnose, denn weder die Projektleitung noch die Projektmitarbeiter:innen verfügen über die notwendigen Entscheidungskompetenzen, eine Projektdiagnose zu beauftragen. Sie können diese anregen, mit triftigen Argumenten auf eine Durchführung drängen, die Entscheidung jedoch liegt auf einer anderen Hierarchieebene.
2. Systemgrenze Diagnose Projekt intern
In Projektdiagnosen sind mehr Funktionen und Personen einbezogen als in Teamdiagnosen. Abhängig von der Größe des Projektes liegt die Zahl der Befragten zwischen zwölf (bei kleineren Projekten) bis fünfzig Personen. In seltenen Fällen können es noch mehr sein.
Abb. 3:
Systemgrenze Projekt intern
Wer muss bzw. kann befragt werden?
Die Antwort hängt wie bereits erklärt von der Definition der Systemgrenze ab.
Projektsponsor
Projektleitung
Teilprojektleiter:innen
Projektmitarbeiter:innen
Erfahrene Projektleiter:innen aus anderen Projekten, die einen Beitrag zur Analyse leisten können
Mitglieder von Entscheidungsgremien
Linienmanager:innen
Projekt Portfolio Management
Externe Kooperationspartner:innen, Lieferant:innen, Kund:innen, Berater:innen
3. Systemgrenze Diagnose Projekt mit unternehmensexterner Beteiligung
Im Unterschied zur zweiten Variante werden hier auch externe Kooperationspartner:innen in die Projektdiagnose einbezogen. Dabei kann es sich um Kund:innen, Lieferant:innen oder um Kooperationspartner:innen handeln, mit denen gemeinsam ein Produkt entwickelt wird. Soweit ich es beurteilen kann, erscheint mir diese Variante eher ein Ausnahmefall zu sein.
Die Systemgrenze ist keine starre Angelegenheit
Die Systemgrenze kann sich im Verlauf der Diagnose ändern. Im Rahmen einer Diagnose für ein Produktentwicklungsprojekt in einem mittelständischen Familienunternehmen waren Gespräche mit den beiden Geschäftsführern, Abteilungsleitern, der Projektleitung und Projektmitarbeiter:innen geplant. Im Verlauf der Interviews wiesen einige Interviewte auf zu häufige Änderungen im Entwicklungsprozess hin, die viel Zeit und Geld kosten und sowohl im Projektteam als auch bei Führungskräften zu Frustrationen führen. Dabei ging nicht um notwendige technische Änderungen, sondern um Modifikationen bezüglich der Farbe, teilweise am Produkt selbst, vor allem aber an der Verpackung. Das Blau war nicht blau genug und statt runden Schaltern sollten Eckige eingebaut werden, um die Innovation des Produktes hervorzuheben. Diese ad hoc Änderungen wurden an der Produktentwicklung vorbei von der Gattin des Seniorchefs entschieden, die seit Jahren im Hintergrund mit viel Herzblut aktiv mitwirkt. Es war nicht ganz einfach, die beiden Geschäftsführer als Auftraggeber der Diagnose davon zu überzeugen, dass auch der Einfluss des Seniors und seiner Gattin im Rahmen der Diagnose analysiert werden sollte.
Diagnostiker:innen müssen im Verlaufe der Datensammlungsphase prüfen, ob die Systemgrenze im Verlauf der Diagnose neu definiert werden muss. Dabei kann es sich um eine Erweiterung oder eine Reduzierung handeln. Mit Hilfe der Stakeholderanalyse können sich Diagnostiker:innen oft bereits zu Beginn ihrer Arbeit einen guten Überblick über die zu beteiligten Akteure verschaffen. Deshalb sollte eine Stakeholderanalyse für das Projekt fester Bestandteil im Rahmen der Auftragsklärung sein.
3.2.1.3 Rollen
Aufgaben, Verantwortungen und Entscheidungskompetenzen der Beteiligten im Rahmen der Projektdiagnose müssen geklärt werden. Selbstverständlich! Doch ganz so einfach ist es in der Praxis nicht immer. Manchmal werden Punkte nicht beachtet oder die Beteiligten gehen einfach davon aus, dass die Verantwortung klar ist. Die Rollenklärung für die DiagnoseRollenklärungDiagnose darf auf keinen Fall zu vernachlässigt werden.
Welche Rollen müssen geklärt werden?
Auftraggeber:in der Projektdiagnose
Weitere Entscheidungsträger:innenPrüfen Sie, ob weitere Stellen bzw. Personen, die Einfluss auf den Diagnoseverlauf ausüben können, in den Klärungsprozess einbezogen werden müssen. Das können beispielsweise Top-Manager:innen, die Leitung des Projekt-Portfolio-Managements oder in Change Projekten auch die Personalvertretung sein.
Aufgaben und Verantwortungen des Diagnostikers, der Diagnostikerin
Wer soll befragt werden? Eventuell muss auch die Reihenfolge bestimmt werden.
Wer soll bei der inhaltlichen und methodischen Vorbereitung der Diagnose mitarbeiten?Vor allem beim Einsatz von externen Diagnostiker:innen ist es empfehlenswert, wenn Mitarbeitende aus der Organisation bei der Zusammenstellung der Fragen mitwirken. Ich schätze es sehr, wenn erfahrene Mitarbeiter:innen (aber nicht zu viele) an der Ausarbeitung des Fragenkatalogs mitarbeiten. Sie kennen die Abläufe der Projektarbeit, haben oft schwierige Situationen in Projekten selbst erlebt und wissen um die Einflüsse mancher Führungskräfte und Gremien auf die Projekte. Außerdem können sie wertvolle Hinweise geben, wie der Informationsfluss für die Projektdiagnose und die Zeitplanung für die Interviews am besten gestaltet werden können.
Wer soll wann und in welcher Form über die Ergebnisse und Zwischenergebnisse informiert werden?Vor allem bei umfangreichen Diagnosen ist es nicht unwahrscheinlich, dass Auftraggeber:innen oder andere Entscheidungsträger über die Zwischenergebnisse informiert werden möchten. Klären Sie, wer und in welcher Form informiert werden soll. Diagnostiker:innen müssen mit dem Auftraggeber vereinbaren, dass Führungskräfte keine Vorabinformationen unter vier Augen erhalten.
Rolle des Auftraggebers der DiagnoseIn der Regel veranlasst der Projektsponsor die Projektdiagnose. Daraus kann sich ein Rollenkonflikt ergeben, denn der Sponsor ist zum einen Auftraggeber der Diagnose und zum anderen wird sein Einfluss als Sponsor des Projektes auf den Projektverlauf ermittelt und bewertet. Nicht selten ist der Sponsor Teil des Problems. Ich weise im Rahmen der Auftragsklärung deutlich darauf hin, dass die Entscheidungsträger des Projektes möglicherweise auch Probleme verursachen und ich diese Informationen im Datenfeedback aufzeigen werde. Erfreulicherweise habe ich in über 25 Jahren nur zweimal erlebt, dass Entscheider dieses Vorgehen abgelehnt haben. Dann ist es angebracht, den Auftrag nicht anzunehmen.Auftraggeber:in der Diagnose haben die Verantwortung, alle Beteiligten über den Anlass und die Ziele der Diagnose zu informieren.Es passiert immer wieder, dass Mitarbeiter:innen zu geplanten Interviewterminen nicht erscheinen. Deshalb sollte der Aufrageber die Linienmanager: innen auffordern, dafür zu sorgen, dass ihre Mitarbeiter:innen die Termine wahrnehmen. Die Auftraggeberseite steht für die Priorität der Diagnose.Erklären Sie dem Auftraggeber, dass er als Projektsponsor selbstverständlich in die Diagnose einbezogen werden muss und möglicherweise Teil des Problems ist. Verdeutlichen Sie den möglichen Rollenkonflikt.Die Projektdiagnose endet mit dem Diagnose-Bericht, bzw. der Präsentation der Ergebnisse. Mit dem Ende der Präsentation der Diagnoseergebnisse übernimmt der Auftraggeber die Verantwortung. Die Diagnostiker:innen sind nicht für die Entscheidung über mögliche Maßnahmen verantwortlich. Dieses Thema ist mit dem Auftraggeber gründlich zu klären.
Rolle der Diagnostiker:innenDiagnostiker:innen sind verantwortlich für die Planung und Durchführung der Projektdiagnose. Das beinhaltet eine Reihe von Aufgaben:Ziele klärenGründliche Beratung über die Systemgrenze. Die Entscheidungsträger können von den Diagnostikern:innen einen gründlich ausgearbeiteten Vorschlag über die Systemgrenze erwarten. Diagnostiker:innen sollte auf keinen Fall eine Systemgrenze akzeptieren, wenn diese ungeeignet ist, das Projekt umfassend und tief genug zu analysieren.Fragen für die Datensammlung ausarbeitenAuswahl der Methoden zur Datensammlung ausarbeitenGründliche Datenanalyse, Bewertung der Ergebnisse und EmpfehlungenDiagnosebericht erstellenPräsentation der ErgebnisseFalls erforderlich, zwischenzeitliche Abstimmungsgespräche mit dem Auftraggeber bzw. der Auftraggeberin führen
Rollenklärung bei mehreren DiagnostikernAbhängig vom Umfang des Projektes und von der zeitlichen Kapazität der Diagnostiker:innen können mehrere Personen mitarbeiten. In diesen Fällen sollten einige Punkte beachtet werden, um eine gute und vertrauensvolle Zusammenarbeit zu erreichen.Wer hat die Gesamtverantwortung seitens der Auftragnehmer:innen für die Diagnose?Wer ist erster Ansprechpartner:in für den Auftraggeber der Diagnose und für andere Entscheider? Informelle Absprachen hinter dem Rücken des Gesamtverantwortlichen sind Tabu.Wer interviewt wen?Mit der formalen Rollenklärung allein ist es jedoch nicht getan. Deshalb gehe ich an dieser Stelle direkt auf weitere Punkte ein.Haben alle Diagnostiker:innen das gleiche Verständnis über die Ziele und die daraus resultierenden Fragen?Wie werden die Abstimmungsprozesse im Verlauf der Diagnose organisiert?In welchen Intervallen und in welcher Form findet der Austausch statt?Wie können die Abstimmungsmeetings gut vorbereitet werden?Besteht ein gemeinsames Verständnis über die Vorgehensweise?Welche Fragen müssen in allen Interviews gestellt werden?Bestimmte Fragen müssen unabhängig von den einzelnen Interviewern:innen in allen Interviews gestellt werden, um vergleichbare Ergebnisse zu erhalten. Notwendig sind beispielsweise Fragen zum Grad der Zielerreichung, zur Priorität des Projektes, zur zeitlichen Verfügbarkeit der Projektmitarbeiter:innen, zum Informationsfluss oder zur Zusammenarbeit im Team. Ich rate jedoch von einem starren Fragekatalog im Sinne eines Fragebogens ab, der den Interviewern:innen keinen Spielraum für diagnostische Entdeckungen lässt.Wie schnell müssen die Ergebnisse der einzelnen Interviews an den Gesamtverantwortlichen der Diagnose weitergeleitet werden? Das sollte möglichst zeitnah erfolgen, z.B. wöchentlich oder zweimal pro Woche, in besonderen Fällen sogar täglich.Es gibt Kernregeln, die zu Beginn der Zusammenarbeit im Team der Diagnostiker:innen besprochen werden müssen:Vertraulichkeit der GesprächeWer was in einem Interview gesagt hat darf nicht an Mitarbeiter aus der Organisation weitergetragen, auch nicht an die Auftraggeberin der Diagnose.Keine Alleingänge bei Absprachen mit FührungskräftenKeine Aussagen über ZwischenergebnisseDie Regeln zum Einstieg in die Interviews sollen von allen beachtet werden. Die Maxime lautet: Bevor ich Fragen stelle, biete ich an, dass die Person mir Fragen stellen kann, um durch Transparenz ein offenes Klima zu fördern.
Interne oder/und externe Diagnostiker – Pro und Kontra
Projektdiagnosen können sowohl von Mitarbeitern:innen der Organisation als auch von Externen durchgeführt werden. Auch Tandemlösungen können sinnvoll sein. Was spricht für eine interne und was für eine externe Beauftragung?
Interne Diagnostiker:innen kennen normalerweise die Abläufe und die Personen wesentlich besser. Das kann vorteilhaft sein, aber es besteht die Gefahr, die eigenen Sichtweisen, Vorurteile oder Wünsche bewusst oder unbewusst einfließen zu lassen. Mitarbeiter:innen des Unternehmens sind stärker ökonomisch und sozial abhängig, die Unabhängigkeit der Internen darf zurecht in Frage gestellt werden und Unabhängigkeit ist eine fundamentale Voraussetzung für eine gute Diagnose.
Externe sind weniger betriebsblind, was aber zwangsläufig bedeutet, dass sie wichtige Einflüsse übersehen können. Ich höre häufiger das Argument, Externe sind objektiver als Interne. Um es klar auszudrücken, von Objektivität zu sprechen, ist nicht zutreffend, denn sowohl die Datensammlung, die Analyse als auch die Bewertungen der externen Diagnostiker:innen werden durch ihre Sichtweisen, Erfahrungen, ihren fachlichen Background, ihre Werte oder Lieblingsideen beeinflusst. In der Praxis kann die Arbeit der externen Diagnostiker:innen auch durch das Ziel des Beratungsunternehmens, den Folgeauftrag zu akquirieren, erheblich beeinflusst werden. Man produziert das gewünschte Ergebnis, um weiter im Geschäft zu bleiben. Idealerweise sind externe Diagnostiker:innen weitgehend ungebunden und müssen nicht auf die Reaktionen des eigenen Managements Rücksicht nehmen.
Darmowy fragment się skończył.
