Kitabı oku: «Projektdiagnose», sayfa 3
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.
