Kitabı oku: «Projektdiagnose», sayfa 2

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.