261 94 13MB
German Pages 176 Year 2014
Holger Zimmermann Projektmanagement im Verlag
Akademie des Deutschen Buchhandels Praxiswissen Verlag
Herausgegeben von Tina Findeiß und Bernd Zanetti
Holger Zimmermann
Projektmanagement im Verlag
ISBN 978-3-11-032377-1 e-ISBN (PDF) 978-3-11-032404-4 e-ISBN (EPUB) 978-3-11-038984-5 ISSN 2196-1484 Libary of Congress Cataloging-in-Publication Data A CIP catalog record for this book has been applied for at the Libary of Congress. Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliothek; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar © 2014 Walter de Gruyter GmbH, Berlin/Boston Zeichnungen: Angela Holzmann, aha Design, München; Oliver Köjer, Duisburg Satz: le-tex, Leipzig Druck und Bindung: Strauss GmbH, Mörlenbach ♾ Gedruckt auf säurefreiem Papier Printed in Germany www.degruyter.com
Inhalt Vorwort 1 32 Fragen für Projektleiter – Eine Anleitung 3 Fragen als Leitlinie dieses Buchs 3 Fragen zum Projektstart 3 Fragen zur Projektplanung 5 Fragen zur Projektsteuerung 8 Fragen zum Projektabschluss 12 Ist das überhaupt ein Projekt? 14 Warum dieses Kapitel sein muss 14 Der Begriff „Projekt“ an sich 14 Der Routineprozess als Gegenteil von Projekt 15 Projektmanagement 16 Projekte und Routineprozesse im Verlag 17 Der Projektablauf im Überblick 18 Ziele von Projektmanagement 18 Vier Ziele, vier Projektmanagement-Abschnitte 18 Einen klaren Rahmen schaffen: Projektstart bis Projektskizze 20 Das Vorgehen vereinbaren: die Projektplanung 25 Das vereinbarte Projektergebnis herstellen: Projektsteuerung 28 Die weitere Verwendung der Projektergebnisse sicherstellen: Übergabe und Projektabschluss 30 Einstieg ins Projekt: die Ausgangslage verstehen 32 Der Auftrag in Rohform 32 Vorlage „Projektauftrag“ 33 Das Projekt beginnt jetzt 34 Das vorläufige Projektteam 35 Gemeinsames Verständnis als Grundlage guter Zusammenarbeit 36 Ein Fragenkatalog zum Einstieg 37 Zeit fürs Kennenlernen 39 Risiken systematisch minimieren 43 Risikoanalyse auch als Instrument der Teamentwicklung 43 Erster Schritt: Risiken listen 43 Zweiter Schritt: Eintrittswahrscheinlichkeit schätzen 44 Dritter Schritt: Schadenshöhe ermitteln 45 Vierter Schritt: Gegenmaßnahmen für die wesentlichen Risiken entwickeln 45 Fünfter Schritt: Risikoanalyse zyklisch durchführen 46 Risikoanalyse im Verlag und in Großprojekten 47 Projektziele richten Energie 48 Warum sich viele Projektteams mit Entscheidungen schwer tun 48 Auftrag, Zielvorgaben und Projektziel 48 Projektziele formulieren 49 Zieldiskussion im Projektstart-Workshop 51 Visuelle Vorstellung und Hilfsfragen 51
VI – Inhalt Vorlage: Projektziel 52 Vollständigkeit von Zielen: nicht nur das Buch zählt 54 Abgrenzung dessen, was nicht zu liefern ist 55 Projektziele gemeinsam entwickeln und festlegen 55 Erscheinungstermin und Lieferbarkeit als Zwischenziele 56 Mit Dienstleistern arbeiten: Lastenheft, Pflichtenheft, Projektziele 56 Ausflug: Der Projektstart-Workshop 57 Verlagsprojekte planen 63 Das Grundverständnis von Projektplanung 63 Die Struktur des Projekts 63 Phasen als zeitliches Grundgerüst 67 Die Aufgabenliste 71 Der Zeitplan 76 Pünktlich liefern dank des kritischen Pfads 82 Ausflug: Projektmanagement-Software 84 Ressourcen sicherstellen 89 Einnahmen und Ausgaben 95 Abschluss der Projektplanung 98 Projektsteuerung: Das Geplante realisieren 102 Die Zeit im Griff 102 Budgets im Griff 107 Die Qualität im Griff 109 Zusammenarbeit über Verlagsbereiche hinweg gestalten 118 Projektkommunikation 126 Ergebnisse dokumentieren 135 Risiken für Verlag und Projekt im Griff behalten 140 Änderungen im Projektverlauf 141 Der Projektabschluss 145 Übergabe an die Linienorganisation 145 Aus Projekten lernen 145 Der formale Projektabschluss 147 Projektmanagement-Standards im Verlag einführen 149 Die Einführung von Projektmanagement-Standards ist ein Projekt 149 Die Zielsetzung eines Standardisierungsprojekts 149 Themenfelder der Einführung von Projektmanagement-Standards 151 Phasen der Einführung von Projektmanagement-Standards 161 Schlussworte, oder: Warum die Mühe? 163 Meine persönliche Sicht 163 Nutzen für den Verlag 164 Quellenverzeichnis 166 Weitere hilfreiche Quellen und Buchtipps 166 Abbildungsverzeichnis 167 Tabellenverzeichnis 169 Über den Autor 170
Vorwort Sie erschließen gerade neue Einnahmequellen für Ihren Verlag und versuchen digitale Geschäftsmodelle im Markt zu etablieren? Sie suchen nach neuen Möglichkeiten, Bücher oder besser: Inhalte zu vermarkten? Sie integrieren neue Softwaresysteme, um Prozesse schlanker zu machen? All das sind typische Aufgabenstellungen, bei denen die Arbeitsform Projekt entweder große Vorteile bietet oder gar die einzig mögliche Arbeitsform darstellt. Doch in Verlagen ist die Grenze zwischen Projekt und Routineprozess nicht immer leicht zu greifen. Was die Projektarbeit an einigen Stellen nicht gerade einfacher macht. Wie Projektarbeit gestaltet sein sollte, um sich im Projekt leichter zu tun und die Erfolgswahrscheinlichkeit zu steigern, davon handelt dieses Buch. Dieses Buch soll ein Praxisbuch sein. Deshalb ist es so geschrieben, dass Sie es zu Beginn eines Projekts aus dem Regal ziehen und vorne zu lesen beginnen können. Es wird Sie Schritt für Schritt durch Ihr Projekt leiten. Das Grundmuster bildet ein Fragenkatalog, der einen Leitfaden für Projektleiter darstellt. Die Fragen sind nummeriert und Sie können diese in ihrer Reihenfolge abarbeiten. Ich verspreche Ihnen, dass Sie damit einen guten Einstieg in Ihr Projekt finden, zu einer vernünftigen Projektplanung gelangen und eine belastbare Projektsteuerung aufbauen können. Die Fragen sind nicht der Stein der Weisen, sie bilden lediglich eine mögliche, in der Praxis bewährte Vorgehensweise ab. Im letzten Abschnitt des Buchs ist außerdem beschrieben, wie Projektmanagement-Standards im Verlag eingeführt oder weiterentwickelt werden können. Erfahrungsgemäß haben nur wenige Menschen eine formale Projektmanagement-Ausbildung. Allerdings kann ich versprechen, dass diese Methode „Projektmanagement“ hilft Dinge möglich zu machen, die man auf den ersten Blick vielleicht gar nicht für möglich hält. Außerdem macht sie Ihnen ganz persönlich das Leben leichter. Auch das verspreche ich. Deshalb lohnt es sich sowohl aus Sicht des Verlags wie aus Ihrer Sicht, sofern Sie in Projekten arbeiten, in gutes Projektmanagement zu investieren. Wobei Projektmanagement für mich eine Sammlung von Hilfsmitteln ist. Nicht mehr, nicht weniger. Falls Sie gerne eine elektronische Version der in diesem Buch verwendeten Vorlagen nutzen möchten, dann senden wir Ihnen gerne einen Gutschein für unser Projektkaufhaus. Dort finden Sie die hier im Buch vorgestellten Muster wie auch weitere. Senden Sie dazu eine Kopie Ihres Kaufbelegs an Holger Zimmermann. Projektmensch. Stichwort „PM im Verlag“ Hanfweg 10 72160 Horb am Neckar Oder schicken Sie einen Scan des Belegs an [email protected] mit demselben Betreff. Wir laden Sie in Verbindung mit dem Kauf dieses Buchs außerdem ein, unseren Projektbrief zu beziehen, in dem wir regelmäßig zum Thema Projektmanagement schreiben. Sie lernen dann unter anderem Herrn Idepap kennen, der Dinge erleben darf, die sonst kein Projektleiter erlebt. Für dieses Buch ausgewählt habe ich ausschließlich Instrumente, die sich im praktischen Einsatz als zuverlässig und hilfreich bewiesen haben. Dass der Fokus der Auswahl dabei auf Projekten in Verlagen liegt, sagt schon der Buchtitel aus. Wobei ich anmerken will, dass ich nicht nur in der Verlagsbranche tätig bin. Ich habe viele Anleihen aus anderen Branchen in dieses Buch integriert, die im Verlag hilfreich sind.
2 Vorwort
Projektmanagement ist eine Art Werkzeugkiste mit Hilfsmitteln, die das Leben leichter machen und die Erfolgswahrscheinlichkeit des Vorhabens steigern.
Einfach nur wiederzugeben, was eh schon getan wird, wäre mir zu wenig. Weshalb ich an mancher Stelle mit Ihrem Widerstand rechne. Und ich bitte Sie, seien Sie kritisch. Jedes vorgestellte Werkzeug ist ein Hilfsmittel. Es soll Ihnen das Leben leichter machen und die Wahrscheinlichkeit Ihres Erfolgs steigern. Wenden Sie nur Instrumente an, die Ihnen einen Nutzen bringen. Aber bitte, prüfen Sie vorher, ob das, was andere etwa über Aufwände sagen, auch tatsächlich zutrifft. Nicht alles, was landläufig als Mehraufwand betrachtet wird, ist tatsächlich einer. Nicht alles, was wie Bürokratie aussieht, will verwalten. Deshalb finde ich es wichtig immer wieder zu fragen, wie ein Instrument angewendet werden muss, dass es Ihnen und Ihrem Team Nutzen stiftet. Der Sinn und Zweck eines Plans ist es nicht, den Plan einzuhalten. Ein Plan ist ein Hilfsmittel, um Ziele zu erreichen. Da bei der erstmaligen Anwendung der Instrumente mit Widerstand zu rechnen ist, habe ich die Passagen gekennzeichnet, in denen der Nutzen beschrieben ist. Falls Sie also die Methode gegenüber Kollegen oder Vorgesetzten argumentieren müssen, suchen Sie sich die Stellen heraus, die am Rand mit „Nutzenargumentation gekennzeichnet sind. Wo sich weiterführende Artikel und Quellen lohnen, finden Sie einen QR-Code samt Link, der sie direkt zum Ziel führt. Dasselbe gilt für die verwendeten Vorlagen. Seit über 15 Jahren unterstütze ich mit meinem Team Projektleiter, Projektteams sowie deren Auftraggeber bei der Umsetzung ihrer Vorhaben. Dabei versuchen wir aus den verschiedenen Projektmanagement-Standards die Werkzeuge herauszuarbeiten, die nicht nur in Büchern gut aussehen, sondern auch in der Anwendung eine gute Figur machen. Was Sie in diesem Buch finden, wenden wir selbst an, ebenso wie viele unserer Kunden. Weshalb ich auch behaupten kann, die Fallstricke in der Anwendung zu kennen – und Wege, diese zu vermeiden. Ich wünsche Ihnen viel Freude bei der Lektüre und viel Erfolg in Ihren Projekten. Bei Fragen: fragen! Schreiben Sie mir an [email protected]. Holger Zimmermann
32 Fragen für Projektleiter – Eine Anleitung Fragen als Leitlinie dieses Buchs Dieses Buch ist so aufgebaut, dass ein Fragenkatalog den roten Faden liefert. Wenn Sie Ihr Projekt starten, können Sie bei der ersten Frage beginnen, sich dann der zweiten widmen, anschließend der dritten und so fort. Die Fragen werden Sie durch Ihr Projekt führen. Sie stellen nicht den Stein der Weisen dar, bilden aber eine Vorgehensweise ab, die sich in vielen Projekten im Verlagsumfeld und darüber hinaus bereits bewährt hat. Die Fragen wiederum orientieren sich am Projektablauf, beginnend beim Projektstart bis hin zum Projektende. Um Ihnen einen schnellen Überblick zu bieten, ist eine Zusammenfassung aller Fragen mit einer kurzen Beschreibung dem Buch vorangestellt. Haken Sie die Fragen ab, die bereits beantwortet sind und starten Sie mit der ersten offenen Frage. Bitte achten Sie, bevor Sie das Häkchen setzen, auf die Qualität Ihrer Antwort auf die Frage. Denn viele Projektteams gehen zu oberflächlich über die Fragen hinweg. Jede Antwort sollte mindestens so konkret und greifbar sein, dass auch ein Außenstehender verstehen kann, was sich dahinter verbirgt. Ist die Antwort nur für Auserwählte verständlich, genügt das dem Anspruch nicht. Projektmanagement ist eine „Wir-Methode“, denn es gilt gemeinsam etwas auf die Beine zu stellen.
Fragen zum Projektstart Frage Nr. 1: Ist das ein Projekt? Viele Projekte werden nicht als solche erkannt und deshalb nicht entsprechend organisiert. Umgekehrt werden viele Dinge als Projekt bezeichnet, die diesen Titel nicht tragen sollten. Zum einen, weil sie eigentlich standardisiert werden sollten, um produktiver zu sein, zum anderen, weil sie schlicht nicht komplex genug sind, um aus Projektmanagement-Techniken Nutzen zu ziehen. Deshalb steht diese Klärung ganz am Anfang: ist das Vorhaben ein Projekt, dann wird Projektmanagement nötig. Ist es kein Projekt, dann sinnvollerweise nicht. So einige Buchprojekte in Verlagen sollten besser als Routineprozess standardisiert werden, denn dann würden die Verlage mehr Geld damit verdienen. Und Sie hätten mehr Energie für die außergewöhnlichen Vorhaben, die dann echte Projekte sind. Projekte sind per Definition Vorhaben, die einmalig sind. Jedes Buch ist sicher einmalig, die Vorgehensweise der Bucherstellung ist es jedoch nicht. Jedes Mal, wenn Sie erkennen, dass sich eine Vorgehensweise wiederholt, sollten Sie zumindest kurz zweifeln, ob es sich tatsächlich um ein Projekt handelt. Dasselbe gilt, wenn Sie erkennen, dass die Zusammenarbeit der Beteiligten auch ohne eine besondere Organisation zum Ziel führen wird, was meist der Fall ist, wenn ein Vorhaben nicht komplex ist.
Frage Nr. 2: Wie lautet der Auftrag? Je konkreter und spezifischer der Auftrag, desto leichter tun sich Auftraggeber, Projektleiter und Projektteam. Da Auftraggeber in der Praxis selten viel Zeit für die Auftragsübergabe verwenden, ist es Aufgabe der Projektleitung – selbst wenn sie noch nicht formal feststeht – den Auftrag möglichst gut zu klären. Der Auftrag enthält Ziel-
Die 32 Fragen in diesem Buch leiten Sie durch Ihr Projekt. Sie bilden eine bewährte Vorgehensweise ab.
4 32 Fragen für Projektleiter – Eine Anleitung vorgaben, die für alle weiteren Schritte relevant sind, sowie Annahmen über einzuhaltende Rahmenbedingungen. Als Projektleiter sollten Sie versuchen in einer persönlichen Rücksprache mit dem Auftraggeber die Ausgangslage möglichst gut zu klären. Stellen Sie so viele Fragen, wie Sie nur können. Insbesondere sollte am Ende des Gesprächs klar sein, welcher Nutzen nach Projektabschluss vorliegen muss und was darüber hinaus vom Projektteam erwartet wird.
Frage Nr. 3: Wer sollte und wer kann mich bei der Projektplanung unterstützen? Selten sind zu Projektbeginn sämtliche Ressourcen benannt. Nicht nur deshalb bietet es sich an, mit einem vorläufigen Projektteam in Projektstart und -planung zu gehen. Darüber hinaus fällt es so sowohl den dafür benannten Kollegen wie auch dem Projektleiter leichter, Änderungen an der Besetzung des Projektteams vorzunehmen. Erst nach erfolgter Projektplanung ist eine realistische Aussage über den Personalbedarf möglich. Für das vorläufige Team werden die Personen nominiert, die im Verlag aus ihrer Erfahrung oder Position heraus sinnvollerweise an der Projektplanung mitwirken sollten und können.
Frage Nr. 4: Was ist hier los? (Oder: was wissen wir bereits?) Ein langsamer Projektstart ist sowohl aus Verständnisgesichtspunkten wie auch aus Perspektive der Teamentwicklung nützlich. Ein gemeinsames Verständnis der Ausgangslage ist eine wichtige Grundlage für alle weiteren Schritte. Viele Dinge erkennen wir erst dann als sinnvoll, wenn wir die Grundlage verstanden haben, auf der sie entschieden wurden. So reduziert die gemeinsame Diskussion und Analyse der Ausgangslage im Rahmen einer ersten Projektbesprechung Konfliktpotenzial und verkürzt Diskussionen während Zielfindung und Projektplanung. Zusammengetragen werden alle Fakten, Annahmen und offene Fragen zu Vergangenheit, heutigem Stand und der Zukunft des Projekts.
Frage Nr. 5: Was könnte uns aufhalten? (Und was tun wir, damit das nicht geschieht?) Die Risikoanalyse ist zum einen ein wertvolles Werkzeug, um die Erfolgswahrscheinlichkeit des Projekts zu erhöhen. Gleichzeitig unterstützt die damit verbundene Diskussion die Teamentwicklung. Vorausgesetzt die Analyse wird im Team durchgeführt. Zuerst werden alle Risiken gelistet, unabhängig wie schwergewichtig sie sind. Anschließend werden alle Risiken der Liste hinsichtlich ihrer Eintrittswahrscheinlichkeit und Schadenshöhe bewertet. Aus der Multiplikation dieser Schätzungen ergeben sich die Risikopunkte. Je mehr Risikopunkte ein Risiko mit sich bringt, desto eher sollten Gegenmaßnahmen unternommen werden, um Wahrscheinlichkeit oder Schadenshöhe zu reduzieren. Oder beides.
Frage Nr. 6: Wie sieht die Welt nach Projektende aus? Je klarer die Projektziele definiert sind, desto leichter können Entscheidungen getroffen werden. Ganz abgesehen davon, dass Projektziele Grundlage für selbstständiges
Frage Nr. 9: Was ist zu tun? 5
Arbeiten des Teams und wichtig für die Motivation desselben sind. Mit den Projektzielen wird der Zustand beschrieben, der nach Abschluss des Projekts erreicht sein soll. Messbare, greifbare Punkte sind wichtig, um Erfolg eindeutig erkennen zu können. Stellen Sie sich vor, das Projekt ist zu Ende und Sie berichten ihrem besten Freund, was Sie erreicht haben. Die Geschichte, die Sie jetzt erzählen können, stellt die Projektziele dar. Ihr Freund sollte dabei zweifelsfrei erkennen können, ob Sie erfolgreich waren oder nicht.
Fragen zur Projektplanung Frage Nr. 7: Um welche Themenbereiche müssen wir uns kümmern? Die Projektplanung beginnt schlicht damit, alle Themenbereiche zu identifizieren, zu denen Tätigkeiten durchgeführt werden müssen, um die Projektziele zu erreichen. Mit der Identifikation dieser Bereiche wird gleichzeitig der Umfang des Projekts klar abgegrenzt und damit der Verantwortungsbereich des Projektteams. Diese Themenbereiche ergeben die oberste Ebene des Projektstrukturplans (PSP), der die Grundlage sehr vieler Projektplanungs- und Projektsteuerungsinstrumente ist. Im Projektstrukturplan wird später die anfallende Arbeit in so kleine Einheiten unterteilt, dass sie von einzelnen Personen im Sinne der Projektziele erledigt werden kann.
Frage Nr. 8: In welchen zeitlichen Abschnitten wollen wir vorgehen? Phasen sind grobe zeitliche Abschnitte eines Projekts, die jeweils mit einem definierten Zwischenergebnis - einem sogenannten Meilenstein - enden. Die Unterteilung eines Projekts in solche Phasen bringt mehrere Vorteile mit sich. Zum einen geben diese chronologischen Blöcke Orientierung, denn man kann daraus ableiten, welche Dinge im Moment im Fokus stehen und welche (noch) ausgeblendet werden können. Zum anderen sind Phasen geeignet, sehr abstrakte Projekte greifbar zu machen. In diesem Fall werden spätere Phasen im Projektverlauf nur sehr vage betrachtet, während die aktuell anstehende Phase im Detail geplant wird. Ist ein Meilenstein erreicht, wird die jeweils nächste Phase im Detail betrachtet und geplant, da diese aufgrund der neu gewonnen Erkenntnisse nun greifbar genug ist. Außerdem eignen sich Phasen, um etwa Vorgesetzten und Auftraggebern einen schnellen Überblick über den zeitlichen Projektstatus zu geben. Dazu werden den ursprünglich geplanten Meilensteinterminen die tatsächlichen Termine gegenübergestellt und erläutert, wie etwaige Abweichungen kompensiert werden können.
Frage Nr. 9: Was ist zu tun? Der Projektstrukturplan wird auch als die Mutter aller Pläne bezeichnet, da viele weitere Planungsschritte, etwa Zeitplanung, Budgetkalkulation und Kommunikation, darauf aufbauen. Er gibt dem Projekt seine Struktur, oder genauer: er gibt der im Projekt anstehenden Arbeit Struktur, indem sämtliche Arbeitspakete erfasst werden, die zur Zielerreichung erledigt werden müssen. So wird die anstehende Arbeit greifbar und kann leichter auf viele Schultern verteilt werden. Gleichzeitig wird die Menge der zu erledigenden Arbeit sichtbar und die Verantwortung des Teams sowie einzelner Personen definierbar.
6 32 Fragen für Projektleiter – Eine Anleitung Jetzt wird der Projektstrukturplan so weit heruntergebrochen, dass am Ende jede zur Zielerreichung durchzuführende Tätigkeit sichtbar wird. Diese strukturierte Aufgabenliste macht das Verteilen der Arbeit von mehrere Personen erst möglich, weshalb die Arbeit entsprechend detailliert aufgeschlüsselt sein muss. Erst wenn die vermutlich Verantwortlichen eindeutig verstehen werden, was zu tun ist, ist die Aufgabenliste fertig. Da im Verlauf eines Projektes alle zur Zielerreichung durchzuführenden Tätigkeiten sowieso identifiziert werden müssen, bedeutet dieser Planungsschritt entgegen landläufiger Vorurteile keinen Zusatzaufwand. Im Gegenteil. Wiederholtes Überlegen und Identifizieren von Tätigkeiten wird so vermieden. Gleichzeitig werden durch eine gemeinsame Aufgabenliste Missverständnisse auf Basis unterschiedlicher Sichtweisen ausgeräumt. In der Praxis stiften viele Projektpläne keinen Nutzen, weil sie nicht detailliert genug aufgeschlüsselt sind.
Frage Nr. 10: In welcher Reihenfolge sollen die Tätigkeiten erledigt werden? Basiert ein Zeitplan auf logischen Überlegungen zur Abhängigkeit zwischen Tätigkeiten, erleichtert das die Projektsteuerung ungemein. Denn nur dann wird – in Verbindung mit der Schätzung der Dauer jeder Tätigkeit – der echte kritische Pfad sichtbar, der ein wichtiges Hilfsmittel für eine pünktliche Lieferung der Projektergebnisse ist. Außerdem sind Pläne, die aufgrund logischer Überlegungen aufgestellt werden, meist eher akzeptiert, da eben diese logischen Überlegungen nachvollziehbar sind. Sind mehrere Möglichkeiten denkbar, die Tätigkeiten in eine sinnvolle Reihenfolge zu bringen, einigt sich das Projektteam jetzt auf eine gemeinsame Vorgehensweise. Dazu werden die verschiedenen Szenarien diskutiert und das für das Projekt am besten geeignete Szenario ausgewählt. Dieser Verhandlungsprozess dient der Teamentwicklung, hilft Konflikte zu vermeiden und reduziert langwierige Diskussionen im späteren Projektverlauf.
Frage Nr. 11: Welche Dauer schätzen wir bis zur Erledigung der Tätigkeit? Wird die Reihenfolge der Tätigkeiten definiert und deren Dauer geschätzt, entsteht ein erster Entwurf eines Zeitplans. Dieser ist eine wichtige Grundlage für die Beschaffung von Ressourcen, denn über diesen ersten Entwurf wird der Personalbedarf sichtbar. Wobei bei der Schätzung der Dauer erste Annahmen über die Personalausstattung getroffen werden, etwa von wie viel Personen eine Tätigkeit durchgeführt wird. Dieser erste Entwurf zeigt eine Art Ideallinie für den Projektverlauf. Er zeigt außerdem, wo der kritische Pfad liegt und was nicht-kritische Tätigkeiten sind. Dieses Wissen wird beim Verhandeln um Ressourcen wichtig, denn daraus ergeben sich die Prioritäten für deren Zuordnung. Tätigkeiten, die auf dem kritischen Pfad liegen, werden zuerst mit Ressourcen bedient.
Frage Nr. 12: Wer hat Verantwortung für welchen Aufgabenbereich? Auf dem Weg zu einer Ressourcenplanung auf Ebene einzelner Arbeitspakete oder Tätigkeiten hilft es, zuvor Verantwortungsbereiche für Teammitglieder zu definieren. Diese Zuordnung von Verantwortung beinhaltet meist eine organisatorische wie auch inhaltliche Verantwortung für einen Teilbereich des Gesamtprojekts. Grundlage für die Festlegung dieser Teilbereiche ist der Projektstrukturplan.
Frage Nr. 16: Wie geht es einfacher? 7
Frage Nr. 13: Mit welchem Arbeitsaufwand rechnen wir? Der für eine Tätigkeit anfallende Arbeitsaufwand ist Grundlage für die Kapazitätsplanung. Während die Dauer einer Tätigkeit die Zeitspanne zwischen Beginn der Arbeitsaufnahme und dem Vorliegen des Ergebnisses beschreibt, wird mit „Arbeit“ oder „Arbeitsaufwand“ beschrieben, wie viele Stunden tatsächlich an einer Aufgabe gearbeitet werden muss, bis diese erledigt ist. Dauer und Arbeit können sich etwa durch Wartezeiten unterscheiden oder weil mehrere Personen gleichzeitig an einer Aufgabe arbeiten. Im ersten Fall ist die Dauer größer als der Arbeitsaufwand, im zweiten Fall die Dauer geringer als der Arbeitsaufwand. Soll eine Person oder eine Gruppe von Personen eine Aufgabe übernehmen, muss sichergestellt sein, dass diese den anfallenden Arbeitsaufwand in der vorgesehenen Dauer bewältigen kann.
Frage Nr. 14: Welche Aufgabe soll von welchen Mitarbeitern erledigt werden? Die Ressourcen- oder Kapazitätsplanung ist genau genommen ein Verhandlungsprozess, an dem Projektleitung, Führungskräfte der Teammitglieder und Teammitglieder teilnehmen. Zusätzlich sind in manchen Fällen auch Projektleiter anderer Projekte beteiligt, die auf dieselben Personen zugreifen. Systematisch wird geprüft, wer welche Aufgaben übernehmen kann. Dazu werden Spielräume genutzt, die sich durch den Puffer nicht-kritischer Tätigkeiten ergeben. Am Ende der Verhandlung steht die Dokumentation der Verhandlungsergebnisse im persönlichen Kalender der beteiligten Personen sowie im Projektplan. Wobei sich der Projektplan üblicherweise gegenüber den vorherigen Entwurfsstufen ändert, da selten alle Aufgaben wie gewünscht mit Personal ausgestattet werden können, was Auswirkung auf Qualität, Zeit und Kosten haben kann. Bei Ressourcenkonflikten wird auf Basis des kritischen Pfads und der Rangfolge verschiedener Projekte untereinander entschieden, wer wann auf welche Person zugreifen darf. Diese Informationen sind deshalb eine wichtige Grundlage der Verhandlungen.
Frage Nr. 15: Mit welchen Einnahmen und Ausgaben rechnen wir? Auf Basis des PSP und der darauf aufbauenden Tätigkeitslisten werden jeder Tätigkeit Einnahmen und Ausgaben zugeordnet. So lässt sich mit wenig Aufwand eine Schätzung der finanziellen Anforderungen erstellen, die ein Vorhaben mit sich bringt. Damit wird gleichzeitig die Grundlage für selbstständiges Arbeiten der Teammitglieder verbessert, da diese nun wissen, in welchem finanziellen Rahmen sie sich bei der Umsetzung bewegen sollen.
Frage Nr. 16: Wie geht es einfacher? Alleine diese Frage zu stellen und zu diskutieren, hilft Projekte zu optimieren, denn der Fokus der Wahrnehmung wird auf den Optimierungsaspekt gelenkt. Dank der vorliegenden Visualisierung in Form des Projektplans werden Optimierungsmöglichkeiten sichtbar. Diese werden systematisch ausgelotet, was in fast allen Projekten bei steigender Qualität Geld und Zeit spart.
8 32 Fragen für Projektleiter – Eine Anleitung Frage Nr. 17: Zu welchem Zeitpunkt werden welche Ergebnisse vorliegen? Stichtage sind ein hilfreiches Werkzeug, um im Projektverlauf erkennen und deutlich machen zu können, wie sich ein Projekt zeitlich entwickelt. Für wichtige Zwischenergebnisse oder Meilensteine werden Stichtage definiert, wann das jeweilige Ergebnis vorliegen soll. Diesen Stichtagen werden während der Umsetzung die tatsächlichen Termine beziehungsweise Prognosen gegenübergestellt. Stichtage können sich aus externen Terminvorgaben ergeben, etwa wenn vertraglich Zwischenlieferungen vereinbart sind. Diese werden als Stichtage in den Projektplan übernommen. Stichtage können sich aber auch aus der Projektplanung ergeben. In diesem Fall nutzt die Projektleitung diese Termine, um schneller und mit weniger Aufwand den Überblick über den Verlauf verschiedener Projektteile herstellen zu können.
Frage Nr. 18: Wie schließen wir die Planung ab? Da der Projektplan eine Vereinbarung des Projektteams darüber dokumentiert, wie das Projektteam vorgehen will, um die Ziele zu erreichen, steht am Ende der Projektplanung die Freigabe des Plans durch das Projektteam. Dasselbe gilt in Bezug auf Auftraggeber und Lenkungsgremien, die ebenfalls zustimmen sollten. Zuvor wird der Projektplan letztmals auf die Einhaltung der Vorgaben geprüft, wobei gelegentlich noch kleinere Anpassungen im Sinne letzter Optimierungen vorgenommen werden. Mit der Freigabe des Projektplans als Basisplan für die Umsetzung, wechselt die Perspektive der Projektleitung weg von der Projektplanung hin zur Projektsteuerung. Die Freigabe und damit der Beginn der Umsetzung werden häufig im Rahmen eines Kick-off-Meetings durchgeführt.
Fragen zur Projektsteuerung Frage Nr. 19: Wie steuern wir die Umsetzung zeitlich? Die Projektsteuerung ist genau genommen eine Art Lernprozess, der dafür sorgen soll, dass möglichst früh im Projekt Unterschiede zwischen Planung und Realität erkannt werden können und daraus Schlüsse für die weitere Projektbearbeitung abgeleitet werden. Dazu werden in regelmäßigen Sitzungen Planung und Echtdaten gegenübergestellt. Führen die Abweichungen voraussichtlich zu einer verspäteten Lieferung der Projektergebnisse und damit zu einer Abweichung von den Projektzielen, entwickelt die Projektleitung Maßnahmen, die zu einer Kompensation der Verzögerung führen und sorgt dafür, dass diese umgesetzt werden. Die Projektsteuerung hat dabei nicht zum Ziel, den Projektplan einzuhalten, auch wenn dies häufig die geltende Annahme ist. Der Plan ist lediglich ein Hilfsmittel, um frühzeitig Erkenntnisse zu gewinnen und so die Zielerreichung wahrscheinlicher zu machen.
Frage Nr. 20: Wie steuern wir Einnahmen und Ausgaben? Was für die zeitliche Entwicklung des Projekts gilt, gilt gleichermaßen für die Entwicklung von Einnahmen und Ausgaben. Regelmäßig werden die Planwerte den Echt-
Frage Nr. 23: Wer ist in welcher Rolle wie beteiligt? 9
und Prognosewerten gegenübergestellt, um daraus Erkenntnisse zu gewinnen und im Bedarfsfall frühzeitig Kompensationsmaßnahmen einzuleiten.
Frage Nr. 21: Wie stellen wir Qualität sicher? Wird die Qualität erst zum Projektende überprüft und sichergestellt, ist das zu spät. Die Definition dessen, was Qualität am Ende bedeutet, beginnt mit der Festlegung der Projektziele. Im weiteren Projektverlauf werden dann Anforderungen konkretisiert. Die jeweils gültigen Anforderungen müssen eindeutig erkennbar sein, um Qualität sicherstellen zu können.
Aus diesen Anforderungen lassen sich Testkriterien und Testverfahren ableiten, über die Qualität dann letztlich überprüft werden kann. Je früher diese Tests, nach Möglichkeit bereits für Teilergebnisse, im Projektverlauf durchgeführt werden, desto weniger Qualitätsrisiken können sich anhäufen. Sämtliche Aufgaben der Qualitätssicherung werden bereits während der Projektplanung im Rahmen der Aufgabenliste erfasst. Damit wird im Rahmen der standardmäßigen Fortschrittsüberwachung gewährleistet, dass eine Qualitätssicherung im Rahmen der Projektarbeit stattfindet. Zusätzlich wird vor wichtigen Zwischenzielen, sogenannten Meilensteinen, das bis dorthin vorliegende Ergebnis den Anforderungen gegenübergestellt. Während die Tätigkeiten der Qualitätssicherung im Rahmen der Projektsteuerung in der Verantwortung der Projektleitung liegen, werden zu diesen Abnahmen Auftraggeber und Lenkungsgremien sowie gegebenenfalls Kunden hinzugezogen.
Frage Nr. 22: Wie stellen wir eindeutige Anforderungen sicher? Nicht selten explodiert der Projektaufwand förmlich, da steigende Anforderungen für stetig zunehmenden Arbeitsaufwand sorgen. Um dieses Explodieren zu vermeiden, müssen zusätzliche Anforderungen frühzeitig erkannt und vor Aufnahme in das Projekt bewertet werden. Änderungsformulare oder Änderungsanträge sind an dieser Stelle ein hilfreiches Stück Bürokratie, um geänderte Anforderungen systematisch bearbeiten zu können. Grundbedingung ist dazu, dass die jeweils gültige Version des Anforderungskatalogs eindeutig definiert und bekannt ist. Sämtliche Änderungswünsche werden gegenüber diesem Status der Anforderungen bewertet. Wird ein Änderungsantrag bewilligt, werden sämtliche dafür durchzuführenden Tätigkeiten im Projektplan erfasst, wodurch der Bedarf für eine separate Überwachung und Steuerung von Änderungen entfällt, was die Projektsteuerung vereinfacht.
Frage Nr. 23: Wer ist in welcher Rolle wie beteiligt? Jeder an einem Projekt Beteiligte hat bestimmte Erwartungen, wie er seine Rolle ausfüllen will und wie andere ihre Rolle ausfüllen sollen. Meist decken sich diese Erwartungen nicht vollständig mit denen anderer Beteiligter. Eine gute Rollenklärung macht bewusst, wer was von wem erwartet, wer welche Kompetenzen erhält und wie die Spielregeln der Zusammenarbeit aussehen. Das reduziert Reibungsverluste. Gleichzeitig ist diese, sinnvollerweise in einem Workshop erarbeitete Vereinbarung für den Projektleiter ein wichtiges Instrument im weiteren Projektverlauft. Die Projektleitung kann Missstände jederzeit in Bezug auf diese Vereinbarung an-
10 32 Fragen für Projektleiter – Eine Anleitung sprechen und so Konflikte frühzeitig angehen, so lange diese noch verhältnismäßig einfach aufzulösen sind.
Frage Nr. 24: Wie binden wir die Stakeholder ein? Stakeholder sind Menschen, die ein irgendwie geartetes Interesse am Projekt haben. Abhängig von deren Einstellung zum Thema und Machtposition können diese Personen wesentlichen Einfluss auf Projektverlauf und -ergebnis nehmen. Um diese Einflussnahme möglichst konstruktiv und im Sinne des Projekts verlaufen zu lassen, werden alle potenziellen Stakeholder identifiziert. Für jeden Stakeholder werden anschließend die vermutete Einstellung zum Projekt sowie deren Machtposition bewertet. Aus dieser Stakeholderanalyse lassen sich Schlüsse ziehen, wie welche Stakeholder ins Projekt einbezogen werden sollten, um die Erfolgswahrscheinlichkeit hoch zu halten.
Frage Nr. 25: Wann informieren wir wen wie über was? Eine systematische, zielgerichtete Information ist sicherlich einer der bedeutendsten Erfolgsfaktoren in Projekten. Regelmäßigkeit und Routine sind wichtig. Ausgangsbasis für jegliche Kommunikation sind die Zielgruppen und deren Bedürfnisse. Wer benötigt wann welche Informationen, um gute Ergebnisse liefern zu können? Wer muss wann mit welcher Information erreicht werden, damit er die Ergebnisse akzeptieren kann? Neben den Mitstreitern gehören Auftraggeber und Lenkungsgremien zu den wichtigsten Zielgruppen. Außerdem gilt es zusätzlich über die Grenzen des Projektteams hinweg zu kommunizieren. Hier liefern die Analysen des Projektumfelds sowie der Stakeholder, der Menschen, die ein Interesse an einem Projekt haben, wichtige Hinweise, wer wann warum über was informiert werden sollte. Die Ergebnisse dieser Überlegungen münden in einer Tätigkeitsliste für den Projektleiter. So werden etwa die Tätigkeitsbereiche „Meetings“, „Berichte“ etc. in der Rubrik „Projektmanagement“ in den Projektstrukturplan aufgenommen. So wird auch die Arbeit der Projektleitung sicht- und damit delegierbar.
Frage Nr. 26: Wie stellen wir Informationen auf Abruf zur Verfügung? Nicht alle Information muss aktiv verteilt werden. Angesichts überquellender E-MailPostfächer werden Überlegungen immer wichtiger, wie Informationen auf Abruf verfügbar gemacht werden können. Das wiederum bedingt, dass die Zielgruppe über diese Informationsquellen Bescheid weiß und bei Bedarf auch tatsächlich darauf zugreift. Die Funktion einer dafür nötigen Informationszentrale kann beispielsweise ein Netzlaufwerk oder eine Seite beziehungsweise Datenbank im Intranet übernehmen. Der Projektstrukturplan liefert die dafür geeignete Struktur. Die Grenzen zur Projektdokumentation verschwimmen in diesem Fall. Eine einfache Lösung kann es auch sein, ein Teampostfach einzurichten, an das alle Mails in Kopie versendet werden. Was sich lohnt, wenn im Gegenzug die Kopien an andere Teammitglieder entfallen, die Mails nur der Information wegen oder zur Sicherheit erhalten. Nach einer Anlaufphase sind solche zentralen Postfächer
Frage Nr. 29: Wie gehen wir mit Änderungen um? 11
meist schnell akzeptierte und gern genutzte Informationsquellen. Dank moderner Suchtechnologie kann ein großer Teil des Sortierens entfallen, vor allem wenn vom Projektteam Spielregeln hinsichtlich der Betreffzeilen und Stichworte vereinbart werden.
Frage Nr. 27: Was dokumentieren wir wie zu welchem Zweck? Die Kunst der Projektdokumentation ist es, heute bereits zu wissen, was übermorgen gebraucht werden wird. Wieder spielen die Zielgruppen eine wichtige Rolle. Wer wird die Ergebnisse später verwenden? Welche Informationen werden dazu benötigt? Wer könnte auf den Projektergebnissen aufbauen? Diese und verwandte Fragen helfen herauszufinden, für wen die Dokumentation gemacht wird und wo die Bedarfe liegen. Die Zielgruppen, die jetzt im Fokus stehen, decken sich nicht zwangsläufig mit denen, die zuvor für die Information im Projekt identifiziert wurden. Will man sichergehen, dass diese Informationsbedarfe nach Projektende gedeckt werden, sollten sie bereits in den Projektzielen verankert werden. Das schafft das nötige Bewusstsein. Werden die Projektziele während der Umsetzung immer wieder herangezogen, wenn Entscheidungen getroffen werden müssen, sorgt das für den notwendigen Erinnerungseffekt. Außerdem sollten sämtliche Tätigkeiten der Dokumentation dort in den Projektplan aufgenommen werden, wo auch das zu dokumentierende Ergebnis entsteht. Tätigkeiten wie etwa „Ergebnisse im Handbuch dokumentieren“ helfen allen Beteiligten, dass diese Aufgaben tatsächlich erledigt und nicht vergessen werden. Die Erledigung wird im Rahmen der Projektsteuerung überwacht, wie für jede andere Tätigkeit auch.
Frage Nr. 28: Wie stellen wir die Risikoüberwachung sicher? Eine erste Risikoanalyse zu Beginn eines Projekts markiert den Startpunkt für das Risikomanagement. Ab diesem Zeitpunkt werden Risiken zyklisch immer wieder unter die Lupe genommen, bewertet und bei Bedarf Präventions- oder Kompensationsmaßnahmen durchgeführt. Grundlage hierfür ist die erste Analyse, die fortgeschrieben und aktualisiert wird. So gelingt es, den Erkenntniszugewinn des Projektteams, das Klügerwerden, in die Projektarbeit einfließen zu lassen.
Frage Nr. 29: Wie gehen wir mit Änderungen um? Zusätzliche Wünsche und Anforderungen an das Projektergebnis führen im Normalfall dazu, dass mehr Aufwand nötig wird, um das Projektergebnis liefern zu können. Um ein Explodieren des Projektaufwands in den Bereich des Nicht-Leistbaren zu vermeiden, ist ein systematischer Umgang mit neuen Anforderungen nötig. Jeder zusätzliche Wunsch, jede zusätzliche oder geänderte Anforderung wird in einem Änderungsantrag erfasst. Diese Änderungsanträge werden regelmäßig gesichtet und bewertet. Auf Grundlage der Bewertung, die wiedergibt, welche Auswirkungen die Aufnahme einer Änderung in das Projekt auf Dauer, Aufwand und Qualität des Ergebnisses hat, wird über den Änderungsantrag entschieden. Wird einer Änderung zugestimmt, wird der Projektplan entsprechend angepasst, so dass diese Änderung im Rahmen der standardmäßigen Projektsteuerung abgearbeitet wird.
12 32 Fragen für Projektleiter – Eine Anleitung
Fragen zum Projektabschluss Frage Nr. 30: Wie werden wann wem welche Projektergebnisse mit welchen Konsequenzen übergeben? Üblicherweise soll das Ergebnis eines Projekts nach Projektende weiterverwendet und eingesetzt werden. Wer etwa eine neue Software einführt, der will, dass diese weiterhin im Einsatz ist, dass sie gewartet wird, die Updates eingespielt werden etc. Um dies zu erreichen, werden die während des Projekts erarbeiteten Ergebnisse und Produkte vor Projektende an die übernehmenden Organisationseinheiten übergeben. Im Beispiel der neuen Software beschafft und installiert das Projektteam die Software und übergibt sie dann der IT-Abteilung zur weiteren Betreuung. Eine solche Übergabe lässt sich selten an einem Tag erledigen. Sie ist eine wichtige Phase im Projektverlauf, in der meist Projektteam und übernehmende Personen gemeinsam daran arbeiten, Know-how zu übernehmen und den weiteren Betrieb sicherzustellen. Spätestens im Rahmen der Übergabe muss klar sein, wer in Zukunft und ab wann welche Verantwortung übernimmt und wer entsprechend Verantwortung abgibt. Beides hat eine sachliche Dimension und eine menschliche. Nicht immer ist es leicht, etwas zu übernehmen, was man nicht selbst entwickelt hat und etwas abzugeben, das vielleicht über Jahre aufgebaut wurde. Dieser Prozess benötigt nicht selten mehr Zeit, als der rein fachliche Teil des Transfers benötigen würde. Entsprechend sollte dieses Mehr an Zeit vorhanden sein, da sonst der Nutzen nicht oder nicht voll zur Verfügung steht.
Frage Nr. 31: Wie sichern und nutzen wir die Erfahrung aus dem Projekt für unser Unternehmen? Die in Projekten gewonnene Erfahrung kann zu einem strategischen Wettbewerbsvorteil für einen Verlag werden, vorausgesetzt sie wird für zukünftige Vorhaben gesichert. Wobei das Lernen aus Projekten nicht erst zum Projektende erfolgen sollte. Wird bereits während des Projekts Erfahrung reflektiert, kann diese bereits für das laufende Vorhaben von Nutzen sein. Neben der Dokumentation der Echtdaten eines Projekt sind ein subjektiver Erfahrungsbericht der Projektleitung mit Empfehlungen sowie eine Auswertung der Erfahrung des Projektteams nützliche Informationen. Letztere werden in einem einfachen Fall im Rahmen eines entsprechenden Workshops gesammelt. Wobei neben der Sammlung auch wichtig ist, dass diese Informationen zukünftigen Projektleitern bekannt sind und diese mit wenig Aufwand darauf zugreifen können. Die Standardisierung der Ablage solchen Wissens auf Unternehmensebene ist meist notwendig, um dies sicherzustellen.
Frage Nr. 32: Wie schließen wir das Projekt ab? Der formale Projektabschluss markiert das Ende der Projektarbeit. Nach dem formalen Abschluss wird durch das Projektteam keine Arbeit mehr am Projekt durchgeführt. Das Team wird aufgelöst, verbunden mit einer Entlastung durch Auftraggeber oder Lenkungsgremien. Dieser Punkt kann auch rechtliche Relevanz haben, weshalb er offiziell dokumentiert wird.
Frage Nr. 32: Wie schließen wir das Projekt ab? 13
Zusätzlich gehört zu einem erfolgreichen Projektabschluss eine entsprechende Feier, denn aufgrund der Risiken, die Projekte mit sich bringen, ist ein Erfolg keinesfalls selbstverständlich. Diese Gelegenheit kann dann genutzt werden, um Wissen weiterzugeben und sicherzustellen, dass alle Beteiligten das Projektergebnis zu Gesicht bekommen.
Ist das überhaupt ein Projekt? Warum dieses Kapitel sein muss Ein echtes Projekt erfordert es, dass sich die Beteiligten für eine bestimmte Zeit auf eine temporäre Organisation einigen, die hilft, das anstehende Vorhaben zum Ziel zu führen. Das bedeutet Arbeit, die zu Beginn eines Projektes erledigt werden muss, etwa die Definition des Vorhabens und die Projektplanung. Wer ein Projekt vor sich hat und diese Arbeit unterlässt, weil er das Vorhaben nicht als Projekt erkennt, wird sich schwer tun, wenn nicht gar scheitern. Wer kein Projekt vor sich hat und sich diese Mühe macht, wirft Geld zum Fenster hinaus. Deshalb ist es wichtig, Projekte zu erkennen und ebenso Vorhaben, die nicht in diese Klasse passen. Gerade im Verlag gelingt dies nicht immer leicht, da routinemäßig sehr individuelle Inhalte erarbeitet werden, was zu einer Unschärfe und damit sehr häufig zu Reibungsverlusten führt. Frage Nr. 1: Ist das ein Projekt? Projekte sind Vorhaben, die einmalig durchgeführt werden und zeitlich begrenzt sind. Außerdem ist eine gewisse Komplexität nötig, damit Projektmanagement einen Nutzen schafft. Ist ein Vorhaben ein Projekt, bedeutet dies, dass die Zusammenarbeit organisiert werden muss. Im Gegensatz zu Routineprozessen, bei denen die Zusammenarbeit bereits organisiert ist. Um keine Effizienz zu verschenken, ist es wichtig, Projekte und Routineprozesse klar abzugrenzen. Routineprozesse sollten dann nach Möglichkeit standardisiert werden, während Projekte eine individuelle Organisationslösung erfordern. Gerade in Verlagen hat dies eine besondere Bedeutung, da die Abgrenzung nicht immer leicht fällt. Umso intensiver sollte sich ein Projektteam darüber Gedanken machen, bevor es blind in ein Vorhaben startet.
Der Begriff „Projekt“ an sich
Projekt
Kennzeichen eines Projekts
Wir sind schnell bei der Hand mit dem Wort „Projekt“. Das führt zu einem Effekt, den wir als „Projektitis“ bezeichnen: alle möglichen Vorhaben werden als Projekte betitelt, auch wenn diese diesen Titel nicht verdient haben. Entsprechend unreflektiert wird an derlei Vorhaben herangegangen. Was fatale Folgen haben kann. Im besten Fall steigt der Aufwand, nicht selten scheitern diese Vorhaben auf ganzer Linie. Gutes Projektmanagement beginnt damit, ein Projekt als solches zu erkennen und ein Vorhaben, das eher als Routine zu betrachten ist, eben als solches zu identifizieren. Wer sich mit der Definition des Wortes „Projekt“ auseinander setzt, bekommt unzählige Begriffsbestimmungen zu Gesicht. Die meisten eint, dass es sich bei einem Projekt um ein einmaliges Vorhaben von begrenzter Dauer handelt. Sehr häufig wird nun noch die damit verbundene Komplexität angeführt, womit sich die Gemeinsamkeiten bereits erschöpfen. Was die Unterscheidung von Projekt und Nicht-Projekt etwas schwierig macht. Weitere Kriterien helfen, wobei man sich diese ein wenig wie Gewichte für eine Waage vorstellen kann. Je mehr davon zutreffen, desto eher kippt die Waage in die eine, je weniger, desto mehr in die andere Richtung. Für ein Projekt sprechen neben Einmaligkeit, zeitlicher Begrenzung und Komplexität unter anderem • ein Budget, das genau für dieses Vorhaben bereitgestellt wird, • die Zusammenarbeit mehrerer Menschen (die nicht zwingend als Projektteam betitelt werden müssen) • die Zusammenarbeit von Menschen, die üblicherweise nicht zusammen arbeiten
Der Routineprozess als Gegenteil von Projekt 15
•
• •
der Bedarf an unterschiedlichem Know-how (es genügt nicht, sich mit Literatur auszukennen, ich brauche auch einen Juristen, einen Marketing-Experten und einen Historiker – um ein Beispiel zu nennen) das Arbeiten über Abteilungs- oder gar Unternehmensgrenzen hinweg das mit dem Vorhaben verbundene Risiko beziehungsweise die Unsicherheit, unter der das Vorhaben durchgeführt wird.
Bei all diesen Punkten wird mehr oder weniger stillschweigend vorausgesetzt, dass das Vorhaben einen definierten Auftrag beziehungsweise definierte Ziele hat. Je mehr diese Kriterien für ein Vorhaben zutreffen, desto eher trifft die Bezeichnung „Projekt“ zu. Wobei unterschiedliche Beteiligte eine andere Sicht auf ein Vorhaben haben können. Was für den einen etwa einmalig ist, ist für einen anderen Routine. Eine solche Situation kann zu unterschiedlichen Grundannahmen und damit zu hohen Reibungsverlusten führen: wenn der eine erwartet, dass die Routineorganisation Regeln und Prozesse hat, über die sich das Vorhaben umsetzen lässt, und der andere nicht davon ausgeht, werden diese beiden sich immer wieder darüber auslassen, was nun richtig oder falsch ist. Der eine will etwas organisieren, wovon der andere annimmt, dass es längst organisiert ist. Dafür, dass ein Vorhaben besser nicht als Projekt durchgeführt werden sollte, sprechen unter anderem • die Wiederholung einer bestimmten Vorgehensweise (was bei vielen sogenannten „Buchprojekten“ der Fall ist, die im Ergebnis unterschiedliche Inhalte jedoch die immer gleiche oder zumindest sehr ähnliche Vorgehensweise haben) • das Vorhandensein einer Checkliste, die lediglich noch abgearbeitet werden muss • das Vorhandensein einer ausführlichen Prozessbeschreibung, die alle notwendigen Arbeitsschritt erläutert • die Tatsache, dass alle Beteiligten mit Sicherheit automatisch wissen werden, was wer wann tun muss und dies ohne zusätzliche Koordinationsmaßnahmen auch tun werden Einen undefinierten Schwebezustand zwischen Projekt und Nicht-Projekt gilt es zu vermeiden, weshalb die Klärung, ob ein Vorhaben als Projekt organisiert werden soll und muss, oder nicht, ganz zu Beginn der Arbeit steht. Auch wenn das etwas theoretisch anmuten mag, ist diese Frage von äußerst praktischem Nutzen, denn viele Organisationen reden von Projekten und versuchen diese über Standardregelungen in den Abteilungen umzusetzen. Was einer ganzen Reihen von Beratern und Dienstleistern ein beträchtliches Auskommen sichert, denn diese Projekte laufen meist nicht besonders gut.
Der Routineprozess als Gegenteil von Projekt Bei der Auseinandersetzung mit dem Projektbegriff bleibt eine Frage offen: Was ist das Gegenteil von Projekt? An der fehlenden eindeutigen Antwort auf diese Frage kann es auch liegen, dass viele Vorhaben mit Projekt bezeichnet werden, die es gar nicht sind. In der Praxis hat sich für uns der Begriff „Routineprozess“ bewährt. Auch wenn er sprachlich vielleicht einen weißen Schimmel darstellt, macht er doch deutlich, dass es sich um organisierte und beschriebe Routinetätigkeiten handelt. Womit ebenso klar wird, welcher Anspruch mit Nicht-Projekten verbunden ist: Vorhaben für Routineprozesse sind bereits organisiert und zwar so, dass alle Beteiligten sich automatisch und ohne Abstimmungsbedarf über die gesamte Projektlaufzeit an diesen beschriebenen Ablauf halten werden.
Abgrenzung Nicht-Projekte
16 Ist das überhaupt ein Projekt?
Abbildung 1: Ein Routineprozess sorgt dafür, dass jeder weiß, was er wann wie mit wem zu tun hat. Bei sich wiederholenden Tätigkeiten sorgt das für Effizienz.
Diese Abgrenzung ist wichtig, denn nur wenn es die Kategorie der Nicht-Projekte gibt, gibt es eine Möglichkeit Projekte von Nicht-Projekten zu unterscheiden. Im Gegensatz zu Vorhaben für Routineprozesse benötigen Projekte eine Organisationsleistung. Die Beteiligten müssen sich darüber unterhalten und sich vereinbaren, wie sie in diesem einen spezielle Fall vorgehen wollen, um die Ziele zu erreichen. Es gibt keinen Auto-
matismus dafür.1
Projektmanagement Genau für diesen Einsatzzweck sind die Instrumente des Projektmanagement gedacht. Sie machen zum einen die Arbeit leichter, wenn ein echtes Projekt durchgeführt werden soll, und erhöhen außerdem die Erfolgswahrscheinlichkeit. Wer also erkennt, dass es sich bei einem anstehenden Vorhaben um ein Projekt handelt, der kann sich sicher sein, dass er in der Werkzeugkiste Projektmanagement entsprechende Hilfsmittel findet. Und als solch eine Werkzeugkiste verstehen wir, was meist unter diesem Begriff „Projektmanagement“ verkauft wird. Die unter „Der Routineprozess als Gegenteil von Projekt“ (Seite 15) beschriebene Abgrenzung der Routineprozesse gegenüber Projekten liefert für diesen Begriff zusätzlich eine weitere Perspektive, stellt sie doch die Beteiligten in den Vordergrund. Während das klassische Projektmanagement sich an der Sache, am Vorhaben selbst orientiert, kann man unter dieses Gesichtspunkten Projektmanagement auch anders verstehen: Projektmanagement ist das Einwirken auf Menschen, um gemeinsam ein definiertes Ziel zu erreichen. Wobei manche Menschen, auf die von Seiten der Projektleitung eingewirkt wird, gar nicht wissen, dass sie an einem Projekt mitwirken. Etwa der Lieferant, der zu einem definierten Zeitpunkt Hardware liefern soll oder ein Stück Software. Er selbst weiß nichts vom Projekt und entscheidet durch eine pünktliche oder unpünktliche Lieferung möglicherweise trotzdem über Erfolg oder Misserfolg des Vorhabens. Woraus ersichtlich wird, dass ein guter Projektleiter auch auf Beteiligte einwirken wird, die nicht als Projektteam bezeichnet werden.
1 Vgl. Wer von Abteilungen redet, denkt nicht in Projekt, Projektmensch-Blog, Holger Zimmermann, http://blog.projektmensch.com/2012/09/03/wer-von-abteilungen-redet-denkt-nicht-in-projekt/, 3. September 2012
Projekte und Routineprozesse im Verlag 17
Projekte und Routineprozesse im Verlag Ist die Entwicklung, Herstellung und Vermarktung eines Buches ein Projekt? Für einen Verlag, der einige Dutzend Bücher pro Jahr publiziert? Das für den Projektbegriff wesentliche Kriterium der Einmaligkeit entfällt, argumentieren die einen. Die anderen erwidern, dass es sich schließlich um ein einmaliges Werk handle. Wer nun hat Recht? Und was macht Sinn? Ein Verlag, der viel Rendite machen will, sollte zuschauen, dass er seine Buchpublikationen so gut in einem Routineprozess organisiert, dass diese für nahezu alle Fälle eine ausreichend hohe Qualität im Ergebnis erreichen werden. Routineprozesse sind auf Effizienz getrimmt. Frederick W. Taylor und Henry Ford stehen modellhaft für diese Herangehensweise, die in kleinteiligen, klar geregelten Arbeitsschritten, Schnittstellen und Zuständigkeiten von Personen und Abteilungen zu erkennen ist. Die Bezeichnung neuer Publikationsvorhaben dieser Art sollte damit verbunden nicht mehr auf das Wort „Projekt“ zurückgreifen. Diese Vorhaben sind keine Projekte und bedürfen auch nicht der dafür notwendigen Organisationsleistung. Allerdings ist es notwendig, die entsprechenden Standards zu schaffen. So werden oft aus einem ersten Pilotprojekt und ein, zwei Folgeprojekten Routineprozesse geschaffen, die die Erfahrung aus den Projekten zusammenfassen und einen auf effiziente Bearbeitung ausgerichteten Routineprozess schaffen. Wer diese Standardisierung nicht leistet, darf weiter von Projekten sprechen und auf die mögliche Effizienz verzichten. Das Denken in Routineprozessen und Effizienz führt allerdings auch zu einem Effekt, den Henry Ford einmal mit der Aussage beschrieben haben soll: „Sie können mein Auto in jeder Farbe haben. Hauptsache sie ist Schwarz.“ Wirklich Abwechslungsreiches und Neues entsteht so selten. Routineprozesse können nur das liefern, wofür sie entwickelt wurden und ein begrenztes Maß an Ausnahmen behandeln. Für die außergewöhnlichen Dinge ist die Arbeitsweise „Projekt“ weit besser geeignet, ist sie doch per Definition bereits für das Neue, das Außergewöhnliche gedacht. Allerdings wird dieses Neue auf Kosten der Effizienz geschaffen, was jedem bewusst sein muss, der das Neue schaffen will. Projekte sind nicht effizient. Folglich braucht auch ein Verlag, der auf Rendite ausgerichtet ist, zusätzlich in seinem Sortiment Publikationen, die als Projekte entstehen und so Neues liefern. Etwa um neue Zielgruppen zu erschließen oder bestehende Leser auf neuartige Weise besser als der Wettbewerb versorgen zu können. Vorausgesetzt, der Verlag will noch ein paar Jahre existieren. Ein Buchprojekt kann also sehr wohl ein Projekt sein, wenn es eine einzigartige Vorgehensweise erfordert. Ganz abgesehen davon, dass gerade die Möglichkeiten der digitalen Welt derzeit häufig dazu zwingen, neue Publikationen in Projektform zu entwickeln, etwa weil neben Printausgabe und eBook zusätzlich ein individuelles Webportal aufgebaut werden soll. Spätestens jetzt sind in den meisten Verlagen keine Routineprozesse mehr vorhanden, um ein solches Vorhaben systematisch zu bearbeiten. Dies wiederum bedeutet, dass für die Umsetzung dieser Vorhaben eine besondere Organisationsleistung nötig wird. Es handelt sich um echte Projekte. Wer in einem solchen Vorhaben arbeitet, sollte – nein, besser: muss Abteilungen und Zuständigkeiten vergessen. Sie gelten nicht für das Projekt. Jetzt wird die Arbeit anders organisiert. Noch eindeutiger wird die Entscheidung für die Arbeitsweise „Projekt“, wenn es um die Entwicklung neuer Geschäftsmodelle geht. Deren Tragweite reicht so weit, dass davon die Existenz der Häuser abhängt. Es wäre fahrlässig, solche Vorhaben ohne die für ein Projekt notwendige Organisationsleistung zu Beginn umsetzen zu wollen. Die Standards in Abteilungen liefern auf die mit derartigen Projekten verbundenen Fragen mit Sicherheit keinerlei Antworten mehr.
Der Projektablauf im Überblick Ziele von Projektmanagement Projektmanagement ist im Wesentlichen eine organisatorische Disziplin: es gilt die Zusammenarbeit von Menschen so einzurichten, dass mit möglichst wenig Mühe vereinbarte Ziele erreicht werden. Über den Projektverlauf hinweg schlägt sich dies in vier Teilzielen nieder, die nacheinander erreicht werden sollen: 1. Einen klaren und eindeutigen Auftrag samt passenden Rahmenbedingungen zu haben. Die Projektskizze ist hierfür ein gut geeignetes Instrument. 2. Eine klare und eindeutige Vereinbarung über das Vorgehen mit allen Beteiligten zu haben. Der Projektplan hält diese Vereinbarung fest. 3. Ein den vereinbarten Anforderungen und Projektzielen entsprechendes Produkt beziehungsweise Projektergebnis hergestellt zu haben. 4. Die Weiterverwendung der Ergebnisse nach Projektabschluss sichergestellt zu haben. Das Ergebnis wird an den Projektzielen gemessen.
Gutes Projektmanagement sorgt für einen reibungsfreieren Projektablauf und damit auch dafür, dass sich jeder Beteiligte leichter tut. Bei gleichzeitig steigender Erfolgswahrscheinlichkeit.
Projektmanagement bedeutet in erster Linie Arbeitsaufwand, wobei dieser Aufwand wohl eher als Investition in einen reibungsfreieren Projektablauf verstanden werden sollte. Wer systematisches Projektmanagement betreibt, kann davon erwarten, dass er und die Beteiligten sich leichter tun im Projekt und dass gleichzeitig die Erfolgswahrscheinlichkeit steigt. Projektmanagement hat zum Zweck, das Projektteam jederzeit in eine handlungsfähige Position zu bringen, um es so in die Lage zu versetzen, den Projektverlauf aktiv zu beeinflussen.
Vier Ziele, vier Projektmanagement-Abschnitte Die Projektmanagement-Ziele werden nacheinander verfolgt. Entsprechend kann ein Projekt aus organisatorischer Sicht grundsätzlich in vier zeitliche Abschnitte unterteilt werden, die jeweils eines dieser Ziele zum Soll-Ergebnis haben: a) Abschnitt 1, der als Projektstart, Projekteinrichtung, Projektdefinition oder Projektinitiierung bezeichnet werden kann b) Abschnitt 2, die Projektplanung c) Abschnitt 3, der als Realisierung, Projektsteuerung oder Umsetzung bezeichnet werden kann d) Abschnitt 4, Übergabe und Projektabschluss Sehr häufig wird damit verbunden die Frage gestellt, wann ein Projekt beginnt. In der Praxis hat sich für uns eine Antwort bewährt: „Jetzt.“ Womit ich zum Ausdruck bringen will, dass ab dem Moment, zu dem eine Person einen ersten Auftrag erhält, dessen Verantwortung beginnt und dass ab diesem Zeitpunkt Ressourcen für das Vorhaben eingesetzt werden. Entsprechend macht es Sinn, die anstehende Aufgabe ab diesem Moment strukturiert zu bearbeiten. Genau dazu sind die Instrumente des Projektmanagement gedacht, weshalb aus organisatorischer Sicht „jetzt“ das Projekt beginnt. Wobei „Jetzt“ in jedem Projekt eine andere Situation sein wird. Beim einen Vorhaben wurde in der Vorprojektphase lediglich eine Idee entwickelt, die nun ausgearbeitet werden soll. Bei einem anderen Vorhaben kann es durchaus sein, dass bereits eine Machbarkeitsstudie vorliegt, die außerhalb des Projekts durchgeführt wurde. Jedes Projekt muss deshalb „jetzt“ die jeweils individuelle Ausgangslage aufgreifen und auf deren Grundlage alles Weitere organisieren.
Vier Ziele, vier Projektmanagement-Abschnitte 19
Abbildung 2: Aus Projektmanagement-Sicht sind die organisatorischen Phasen Projekteinrichtung, Projektplanung, Umsetzung sowie Übergabe und Abschluss eine hilfreiche Gliederung des Vorhabens.
In diesem ersten Moment im Projekt sind viele Dinge noch nicht geregelt, viele Fragen offen. Deshalb wird oft argumentiert, dass dies noch kein Projekt sein könne. Mit dieser Argumentation wird dann gleichzeitig auf ein strukturiertes Herangehen verzichtet, was sich jedoch meist als Fehler erweist, da unnötig Aufwand produziert wird und unnötige Reibung entsteht. Offene Fragen sind zu Projektbeginn ganz normal und Projektmanagement ist dazu da, diese offenen Fragen im Projektverlauf systematisch einer Beantwortung zuzuführen. Offene Fragen sind kein Argument gegen Projektmanagement, offene Fragen sind ein Argument dafür, die Instrumente des Projektmanagement anzuwenden. Wären alle Fragen bereits beantwortet, wäre das Projekt wohl bereits erledigt. Nicht verwechselt werden sollte der Projektstart mit dem Beginn der Umsetzung. Bis zum Beginn der Realisierung wird geplant, sprich auf Papier erarbeitet, wie es gelingen könnte, die Ziele zu erreichen. Ab dem Beginn der Umsetzung werden verstärkt Ressourcen eingesetzt, weshalb dieser Termin nicht selten als Projektstart bezeichnet und im Rahmen eines Kick-off-Meetings freigegeben wird. Diese beiden Zeitpunkte sorgen in der Praxis häufig für Verwirrung, da sie nicht sauber getrennt werden. Das eine hat die Bezeichnung „Beginn der Umsetzung“ verdient, die sich vom „Projektstart“ unterscheidet und zeitlich nach diesem liegt.
Produkt steht zur Verfügung Projektplan freigegeben Projektskizze freigeben Projektstart Abbildung 3: Wichtige Meilensteine aus Sicht des Projektmanagement
Projektende, Übergabe gesichert
20 Der Projektablauf im Überblick
Einen klaren Rahmen schaffen: Projektstart bis Projektskizze Die Projektksizze als kommunikative Quittung und Projektvertrag
Projektskizze
Eine Projektskizze schafft Vertrauen beim Auftraggeber und führt damit letztlich dazu, dass dieser weniger in das Projektgeschehen eingreifen wird.
Die Projektskizze ist ein hilfreiches Mittel, um einen klaren Rahmen für das weitere Projekt zu schaffen und zu vereinbaren. Ein gewisses Maß an Klärung und Planung sind nötig, um eine solche Projektskizze sinnvoll ausfüllen zu können. Die Projektskizze fasst diese Ergebnisse strukturiert zusammen. Sie ist Grundlage der Vereinbarung zwischen Auftraggeber, Projektleitung und Projektteam über Ziele, Verantwortung und verfügbare Mittel zur Erreichung der Ziele. Andernorts wird das, was hier als Projektskizze bezeichnet wird, Projektauftrag, Projekt-Carta oder Projekt-Mandat betitelt. Diese Begriffe werden jedoch widersprüchlich interpretiert, wohingegen Projektskizze eher neutral besetzt ist. Ein neutraler Begriff hilft, Missverständnisse und Fehlinterpretationen zu vermeiden. Aus kommunikativer Sicht kommt die Projektskizze einer Quittung gleich: der Auftraggeber beauftragt ein Projektteam mit einem Projekt. Das Projektteam meldet mit der Projektskizze zurück, was es als Auftrag verstanden hat, welche Annahmen zur Ausgangslage bestehen und wie das Team das Projekt angehen möchte. Diese Quittung stellt sicher, dass Auftraggeber, Projektleitung und Projektteam von denselben Dingen sprechen. Damit hat das Projektteam die Sicherheit, in die ‚richtige’ Richtung zu marschieren. Beim Auftraggeber schafft die Projektskizze Vertrauen, denn er kann sich nun sicherer sein, dass das Projektteam in seinem Sinne handeln wird. Dieser Vertrauensgewinn führt in vielen Fällen zu einem deutlich spürbaren Effekt: die Anzahl der spontanen Eingriffe des Auftraggebers in das Projektgeschehen geht deutlich zurück. Das entlastet sowohl den Auftraggeber wie auch Projektleitung und Projektteam.
Idee / Impuls/ mündl. Auftrag
Rücksprache/ Auftragsklärung
Voranalyse Vorläufiges Team definieren
ProjektstartWorkshop
Projektplan 1.00 erstellen
Achtung Wortwahl: Antrag, Auftrag, Ziele und Projektskizze werden oft in unterschiedlicher Bedeutung verwendet, was zu Missverständnissen führen kann.
Projektteam definieren
Projektskizze erstellen
Projektskizze freigeben lassen
Projektplan 2.00 /Umsetzung keine Umsetzung ohne Unterschrift
Abbildung 4: Von der Idee bis zur Projektskizze ist ein gewisses Maß an Planung nötig.
Aus kommunikativen Gesichtspunkten ist es deshalb auch ratsam, die Projektskizze gemeinsam zu besprechen und gemeinsam freizugeben. In diesem Freigabegespräch werden die vom Projektteam erarbeiteten Punkte nochmals durchgesprochen und Fragen geklärt. Erst dann kommt es zum formalen Akt der Freigabe, mit dem die Projektskizze zu einer Art Vertrag zwischen Auftraggeber und Projektleitung beziehungsweise Projektteam wird, auf den sich beide beziehen können.
Inhalte der Projektskizze 21
Inhalte der Projektskizze Zwei Dinge sollte die Projektskizze mindestens beschreiben, um als Ausgangsbasis für die weitere Projektarbeit von Nutzen zu sein: e) eine Beschreibung der Ausgangslage des Projekts und f) die Definition der Projektziele Sind diese beiden Positionen beschrieben, ist das Vorhaben grundsätzlich definiert. Sobald Start- und Endpunkt bekannt sind, kann es lediglich noch eine Diskussion über verschiedene, alternative Wege der Zielerreichung geben. Das wiederum schließt unzählige Möglichkeiten bereits aus, die entweder nicht der Ausgangssituation gerecht werden oder am Ziel vorbei gehen. Darüber hinaus hat es sich bewährt, grundsätzliche Angaben zur Vorgehensweise zu machen. Wobei klar sein muss, dass der Freigabe der Projektskizze im Grunde genommen eine Verhandlung mit dem Auftraggeber über Ressourcen und verfügbare Mittel vorausgeht. Entsprechend fundiert sollten die Angaben zur Vorgehensweise sein. Diese Qualität erreicht man, indem man eine Art erste, rohe Projektplanung macht, die auf den Fragenkatalog aus dem Kapitel „32 Fragen für Projektleiter – Eine Anleitung“ (S. 3 f.) aufbaut. Als besonders nützlich für diese Verhandlungen haben sich neben Ausgangslage und Projektzielen erwiesen: • eine erste Risikoanalyse, die unter anderem hilft, knifflige Fragen und Problemstellungen konstruktiv anzusprechen • die obersten Ebenen des Projektstrukturplans, die unter anderem helfen Umfang und Dimension eines Vorhabens begreiflich zu machen und Verantwortung abzugrenzen • ein erstes, grobes Termingerüst auf Basis von Phasen und Meilensteinen, die in Verbindung mit dem Projektstrukturplan ebenfalls Umfang und Dimension bewusst machen • eine Abschätzung von Ressourcen- und Finanzmittelbedarf auf dieser Grundlage • eine Bewertung von Aufwand und Nutzen • ein Vorschlag für die Besetzung des Projektteams samt Rollen der Projektteammitglieder • ein Vorschlag zur Zusammenarbeit mit dem Auftraggeber • ein Vorschlag zur Besetzung und Zusammenarbeit mit Lenkungsgremien, die bereichsübergreifende Entscheidungen treffen • ein Vorschlag, welche Projektmanagement-Instrumente verwendet werden sollen und wie sich die Projektleitung das Vorgehen zur Projektsteuerung vorstellt Diese Informationen geben dem Auftraggeber einen grundlegenden Einblick in die Arbeitsweise des Projektteams und bieten ihm damit gezielt Möglichkeiten, eigene Anforderungen zu benennen. Gleichzeitig kann sich so die Projektleitung Freiräume sichern. Deshalb ist es unter anderem wichtig, im Rahmen der Rollenbeschreibung auch Entscheidungskompetenzen zu definieren. Die Projektleitung hat dabei Vorschlags-, der Auftraggeber Entscheidungsrecht. Darüber hinaus ist der Auftraggeber auf einer besseren Datenbasis leichter in der Lage, über die Freigabe von Ressourcen zu entscheiden. Eine mit einem wenigstens groben Projektstrukturplan hinterlegte Personalbedarfsplanung hat wesentlich mehr Aussagekraft als der schlichte Wunsch nach Ressourcen.
Vorbereitung Verhandlung über Projektskizze
22 Der Projektablauf im Überblick Vorlage Projektskizze Diese Projektskizze hat sich in unseren Projekten über viele Jahre hinweg bewährt:
Projekt:
Datum:
Projektleitung:
Auftraggeber:
Dokumentordner:
Auftrag, Ausgangslage, Idee/ Entstehung, Rahmenbedingungen:
Wesentliche Risiken
Bewertung Wahrschein-
Folgen/
lichkeit
Schadenshöhe
Rang Gegenmaßnahme
Ersteinschätzung Aufwand & Nutzen:
Projektziel(e):
Seite 1 von 3
Holger Zimmermann. Projektmensch. • Diplom-Wirtschaftsingenieur (FH) • Hanfweg 10 • D-72160 Horb am Neckar • Telefon +49 7451 55709-0 • [email protected] • www.projektmensch.com
Vorlage Projektskizze 23
Nicht-Ziele:
Grundsätzliche Vorgehensweise/ Projektstrategie/ Projektdesign:
Projektstruktur (mind. 2 Ebenen):
Meilensteine: Nr. 0
Datum
Erwartetes Ergebnis Projektstart
... x
Projektabschluss
Projektteam, Rollen, Verantwortung, (Entscheidungs-)Kompetenz:
Spielregeln der Zusammenarbeit des Projektteams (Frequenz Kommunikation, Kommunikationsplattform, Abgleich Kapazitäten etc.):
Seite 2 von 3
Holger Zimmermann. Projektmensch. • Diplom-Wirtschaftsingenieur (FH) • Hanfweg 10 • D-72160 Horb am Neckar • Telefon +49 7451 55709-0 • [email protected] • www.projektmensch.com
24 Der Projektablauf im Überblick
Berichte und Zusammenarbeit mit dem Lenkungsgremium:
Was zeichnet dieses Projekt aus? Was machen wir hier anders als üblich?
Freigabe unter folgenden Bedingungen:
Folgende Instrumente des Projektmanagement sollen benutzt werden:
Erster Bericht am:
Freigabe – oder „So machen wir das“:
Datum
Unterschrift Auftraggeber
Unterschrift Projektleiter
Seite 3 von 3
Holger Zimmermann. Projektmensch. • Diplom-Wirtschaftsingenieur (FH) • Hanfweg 10 • D-72160 Horb am Neckar • Telefon +49 7451 55709-0 • [email protected] • www.projektmensch.com
Abbildung 5: Die Projektskizze ist Grundlage für die Zusammenarbeit von Projektleiter, Auftraggeber und Projektteam. Sie wird erst diskutiert und dann freigegeben.
Das Verständnis dieses Dokuments ist dabei eben das einer Skizze. Das Projektteam beziehungsweise die Projektleitung bringt einen Entwurf der Projektskizze mit in das
Projektplanung ist gemeinsames, systematisches Denken 25
Freigabegespräch mit dem Auftraggeber. Im Gespräch mit diesem wird die Projektskizze ergänzt und angepasst, bis beide Seiten damit einverstanden sind. Es geht dabei auch um den Austausch, das Gespräch, um gegenseitiges Verständnis. Dann erst erfolgt die Freigabe, deren Bedingungen ebenfalls in der Projektskizze festgehalten werden. Im Freigabegespräch entsteht oft ein starkes hierarchisches Gefälle zwischen Auftraggeber und Projektleitung. Alle Beteiligten sollten dies jedoch eher als Gespräch auf Augenhöhe betrachten. Der Projektleiter wird beauftragt, möglichst selbstständig etwas zu liefern, was der Auftraggeber benötigt. Jetzt benennt der Projektleiter die Bedingungen, unter denen er erfolgreich sein kann. Die könnte der Auftraggeber gar nicht liefern, da er meist nicht die Zeit hat, sich entsprechend tief in das Projekt einzuarbeiten.
Freigaben sind Gespräche auf Augenhöhe. Der Projektleiter liefert dem Auftraggeber etwas, was dieser selbst nicht erstellen könnte.
Das Henne-Ei-Problem: wie man zu Mitstreitern kommt Zu Beginn eines Projekts steht der Projektleiter meist vor einem Dilemma. Häufig ist lediglich er benannt, indem er den Auftrag zur Durchführung des Projekts erhalten hat. Nun benötigt er weitere Personen mit entsprechendem Fachwissen in unterschiedlichen Bereichen, um einen Projektplan erstellen zu können. Gleichzeitig benötigt er den Projektplan, um erkennen zu können, welche Personen mit welchem Know-how er in welchem zeitlichen Umfang benötigen wird. Dieses Henne-Ei-Problem kann relativ leicht gelöst werden, indem für die Startphase bis zum Abschluss der Projektplanung ein vorläufiges Projektteam installiert wird. Der Projektleiter schätzt ab, welche Wissensgebiete im Projekt benötigt werden und versucht in Zusammenarbeit mit den jeweiligen Vorgesetzten passende Mitstreiter zu gewinnen. Diese Mitstreiter werden jedoch nicht für die gesamte Projektlaufzeit gebucht, sondern lediglich für die Startphase bis zum Abschluss der Projektplanung. Dieses Vorgehen erleichtert einige Dinge im weiteren Projektverlauf. Zuallererst ist es leichter, Zusagen zur Beteiligung an der Projektplanung zu erhalten, als für die Mitarbeit an einem Projekt mit noch unbestimmter Dauer und in noch unbestimmtem Umfang. Gleichzeitig ist es wesentlich leichter, an dieser Zusammensetzung wieder etwas zu ändern. Es ist von Anfang an Teil der Vereinbarung, dass sich die Zusammensetzung des Projektteams nochmals ändern kann und vermutlich auch ändern wird. Alles andere würde hellseherische Fähigkeiten des Projektleiters voraussetzen. Nicht selten wird im Rahmen der Projektplanung erkannt, dass der ein oder andere Kollege nicht im ursprünglich gedachten Umfang benötigt wird und statt dessen ein anderer Kollege weit mehr beansprucht werden wird, als zu Beginn angenommen. Aufgrund der vorläufigen Verpflichtung fürs Projekt kann dieser Erkenntnis Rechnung getragen werden und das ohne Gesichtsverlust. Es war schließlich so beabsichtigt.
Ein vorläufiges Projektteam löst das Henne-Ei-Problem der Ressourcenausstattung zu Projektbeginn.
Das Vorgehen vereinbaren: die Projektplanung Projektplanung ist gemeinsames, systematisches Denken „Trauen Sie sich zu, alle Tätigkeiten Ihres Projekts auswendig in der richtigen Reihenfolge aufzulisten?“ Diese Frage stellen wir im Rahmen von ProjektmanagementTrainings regelmäßig, wenn es um den Nutzen von Projektplanung geht. Wir fordern zur Unterschrift auf. Bisher hat niemand unterschrieben und wir stellen diese Frage seit mehr als zehn Jahren. Trotzdem versuchen Projektleitung immer wieder selbst größere Projekte auswendig zu steuern. Sie leben dabei nicht selten in dem Irrglauben, Projektplanung sei
Es ist kognitiv unmöglich, sämtliche Tätigkeiten eines Projekts auswendig zu erfassen. Deshalb werden Projektpläne benötigt.
26 Der Projektablauf im Überblick unnötig. Begründet wird dies durch die vielen Änderungen, die kommen. Dass diese Vielzahl an spontanen Einsätzen jedoch nur entsteht, weil kein gemeinsamer Plan vorliegt, ist diesen Personen selten bewusst. Um es festzuhalten: Projektplanung machen wir alle. Wir überlegen uns, welche Aufgaben zu erledigen sind und wer diese machen könnte. Der Unterschied zum Verständnis von Projektplanung im Sinne einer Projektmanagement-Methodik ist schlicht der, dass die Projektplanung systematisch und gemeinsam erfolgt – und dass die Ergebnisse in einer bewährten Form der Visualisierung zusammengefasst werden. Projektplanung ist nicht mehr und nicht weniger als gemeinsames, systematisches Nachdenken darüber, wie die Projektziele erreicht werden könnten. Der Konjunktiv, die Möglichkeitsform ist an dieser Stelle besonders wichtig. Kein Plan lässt sich eins zu eins umsetzen. Er zeigt lediglich einen Weg, auf dem es gelingen könnte, die Projektziele zu erreichen. Einen Weg, über den das Projektteam die Zielerreichung für wahrscheinlich genug hält, um ihn zu gehen. Damit wird der Projektplan zu einer Vereinbarung der Beteiligten über die Vorgehensweise. Die Projektplanung ist gleichzeitig ein Verhandlungs- und Einigungsprozess der Mitstreiter, die sich damit auf eine gemeinsame Vorgehensweise verpflichten.
Der Basisplan markiert das Ende der Projektplanung und den Beginn der Umsetzung
Basisplan, Basislinie, Urplan, Urlinie
Am Ende der Projektplanung steht der Basisplan oder die Basislinie, der Urplan, die Urlinie, wie diese Planversion auch genannt wird. Als Basisplan wird die Version des Projektplans bezeichnet, die vom Projektteam, Auftraggebern und gegebenenfalls Lenkungsgremien zur Umsetzung freigegeben wird. Er enthält alle Vereinbarungen zur Vorgehensweise hinsichtlich Abfolge von Tätigkeiten, Zeitbedarf, Ressourceneinsatz, Budgets, Qualitätsanforderungen und Maßnahmen der Qualitätssicherung sowie Tätigkeiten des Projektmanagement. Der Projektplan beschreibt dabei die Schritte zur Zielerreichung. Er beschreibt nicht die inhaltliche Lösung, sondern die Aktivitäten, die durchgeführt werden müssen, um das Projektergebnis zu erstellen. Er ist als Konjunktiv zu verstehen, zeigt er doch lediglich eine mögliche Vorgehensweise, mit der es gelingen könnte, die Projektziele zu erreichen. Eine Möglichkeit, deren Erfolgswahrscheinlichkeit das Projektteam hoch genug einschätzt, um mit diesem Plan in die Umsetzung zu gehen. An der Erstellung des Basisplans wird so lange gearbeitet, bis das Projektteam mit der Vorgehensweise einverstanden ist und diese als machbar betrachtet. Die Akzeptanz eines Projektplans durch das Projektteam ist eine unabdingbare Voraussetzung dafür, dass der Projektplan einen großen Nutzen stiften kann. Je nach Schwierigkeitsgrad können zur Erstellung mehrere Iterationsschleifen nötig sein, in denen die Projektplanung immer wieder verworfen und neu aufgebaut wird. Auf dieser Art und Weise werden systematisch Erkenntnisse über das Projekt gewonnen, die nach und nach dazu führen, dass eine angemessene Vorgehensweise entwickelt werden kann. Der Basisplan ist wiederum als eine Art Vertrag aller Mitstreiter zu verstehen. Er visualisiert die Vereinbarungen bezüglich der Übernahme und Erledigung von Aufgaben. Entsprechend verbindlich sollten Zusagen getroffen werden. Wobei die Zusagen sich darauf beziehen, dass eine für eine Aufgabe verantwortliche Person diese Aufgabe wie geplant übernehmen oder sich bei Abweichungen melden wird, um gegebenenfalls Kompensationsmaßnahmen einzuleiten. Gelingt eine solche Vereinbarung,
Nutzen der Projektplanung 27
reduziert diese die notwendige Aufmerksamkeit der Projektleitung beträchtlich. Die Projektleitung muss dann nur noch im Abweichungsfall einschreiten, was die Arbeit deutlich leichter macht. Mit der Freigabe des Basisplans beginnt dessen Umsetzung. War die Projektleitung bisher verantwortlich für die Projektplanung, wechselt die Perspektive nun hin zur Projektsteuerung. Grundlage dafür ist der Basisplan, der grundsätzlich nun nicht mehr verändert wird. So bleibt die Ideallinie ständig sichtbar, wohl wissend, dass die Realität sich nicht an den Plan halten wird. Diese Realität wird dann dem Plan gegenüber gestellt. Aus dem Unterschied zwischen Plan und Realität können Schlüsse gezogen und Maßnahmen abgeleitet werden, die sicherstellen sollen, dass die Zielerreichung wahrscheinlich bleibt.
Nutzen der Projektplanung Sinn eines Projektplans ist nicht die Einhaltung des Plans. Ein Plan ist ein Hilfsmittel, um Ziele angenehmer und mit höherer Wahrscheinlichkeit zu erreichen. Eine Abweichung der Realität gegenüber dem Plan ist kein Argument gegen Planung. Vielmehr ist dies ein Argument dafür, mit dem Projektplan eine solide Grundlage für die Analyse der Abweichungen und damit die Projektsteuerung zu schaffen. Wir haben einige tausend Seminarteilnehmer nach dem Nutzen der Projektplanung befragt, nachdem diese sich die Methodik erarbeitet hatten. Wertet man die entsprechenden Protokolle aus, finden sich sinngemäß immer wieder Aussagen wie diese: • Der Projektplan bringt das Projektteam in eine handlungsfähige Position, so dass Engpässe früh erkannt und beseitigt werden können. • Aus dem Zeitplan lässt sich der kritische Pfad erkennen, der hilft, das Projekt pünktlich abzuschließen. • Der Personalbedarf wird sichtbar und kann damit auch gegenüber Auftraggebern leichter kommuniziert werden. • Die Arbeit kann leichter auf ein Team verteilt werden. Jeder weiß, wo er anpacken muss, wer die Vorarbeit erledigt und wem die Ergebnisse weitergegeben müssen. • Zeitpläne lassen erkennen, warum welcher Abgabetermin für das Gesamtergebnis wichtig ist. Das erhöht die Akzeptanz von Abgabeterminen und damit die Wahrscheinlichkeit einer pünktlichen Lieferung von Arbeitsergebnissen. • Mit dem Projektplan wird es für die Projektleitung möglich, sich auf die Bewältigung von Abweichungen gegenüber der Planung zu fokussieren, während alles andere so organisiert ist, dass es auch ohne Eingriff der Projektleitung funktioniert. • Es ist leicht auf einem Blatt Papier etwas zu ändern. Leichter, als wären schon Tatsachen geschaffen worden. Das reduziert das Konfliktpotenzial. • Möglichkeiten Zeit und Aufwand zu sparen werden deutlich. Dadurch lassen sich Projekte optimieren. • Die Dimension eines Vorhabens wird sichtbar. Dadurch kann bereits bevor viel Geld ausgegeben wird erkannt werden, ob sich das Vorhaben überhaupt lohnen kann. • Durch die Visualisierung fällt es leichter, den Überblick zu behalten. Die Komplexität wird „begreifbarer“. • Mit dem Projektplan können Abläufe und Zusammenhänge viel besser erläutert und kommuniziert werden.
Ein Projektplan ist ein Hilfsmittel, das unter anderem Engpässe frühzeitig sichtbar macht und das Projektteam damit in eine handlungsfähige Position bringt.
28 Der Projektablauf im Überblick •
Es wird weniger vergessen werden, da das Projekt aus verschiedenen Perspektiven beleuchtet wird, wodurch viele Dinge bewusst werden, die man sonst übersehen hätte.
Diese Liste könnte leicht fortsetzt werden. Sie deckt sich mit meiner Erfahrung in Projekten, wobei ich persönlich gerne anfügen möchte, dass Projektplanung Ruhe und Sicherheit in Projekte bringt. Ein Effekt, den ich persönlich sehr schätze.
Machen und nicht so viel darüber sprechen
Je mehr über das Wie und Warum der Projektplanung diskutiert wird, desto geringer deren Akzeptanz. „Einfach machen“ macht vieles leichter, da sich der Nutzen von Plänen schnell erschließt, wenn diese erst einmal das Projekt in seiner Ganzheit zeigen.
Eine Erfahrung machen wir immer wieder, wenn „Projektplanung“ auf der Agenda steht: Es entstehen Widerstände. Sätze wie „Pläne stimmen eh nie!“ oder „Da hält sich doch eh niemand dran!“ sind nicht selten. Das hat unter anderem damit zu tun, dass zu wenig Wissen über die Projektmanagement-Methodik vorhanden ist. Das wiederum führt zum einen zu wenig nützlichen Plänen, die dann verständlicherweise dazu führen, dass niemand solche Pläne haben möchte. Der Aufwand lohnt schlicht nicht. Zum anderen stehen unbewusste Ängste im Raum. Diesen Effekt kann leicht gemildert werden, indem nicht so viel über Projektplanung gesprochen und statt dessen einfach ein Projektplan erstellt wird. In unseren Projekten schaffen wir sehr häufig Akzeptanz für Pläne, indem wir diese schlicht im Rahmen etwa eines Workshops erstellen, ohne sie mit den Fachbegriffen zu benennen. Letztlich ist es für das Ergebnis aus Projektmanagement-Sicht nicht relevant, ob Sie „Aufgabenliste“ oder „Projektstrukturplan“ sagen. Sie können ankündigen „Jetzt erstellen wir ein Gantt-Diagramm!“ oder schlicht fragen, „Wie wollen wir vorgehen, um das Projektziel zu erreichen?“ Beides schafft denselben Nutzen, sofern Sie die Instrumente verwenden. Das eine jedoch mit weniger Befürchtungen und Akzeptanzschwierigkeiten als das andere. Wer noch nie etwas von einem „Gantt-Diagramm“ gehört hat, hat berechtigte Befürchtungen, damit nicht klar zu kommen.
Das vereinbarte Projektergebnis herstellen: Projektsteuerung Regelmäßigkeit sorgt für Vortrieb Die Projektsteuerung funktioniert nach einem einfachen Prinzip. Regelmäßig werden Echtdaten den Planwerten gegenübergestellt. Aus der Abweichung zwischen Plan und Realität lässt sich eine Prognose über den weiteren Projektverlauf ableiten. Zeigt die Prognose, dass die Zielerreichung gefährdet sein könnte, werden Maßnahmen eingeleitet, die eine Erreichung der Projektziele wieder wahrscheinlich machen. Die Regelmäßigkeit dieser Plan-Ist-Vergleiche ist sehr wichtig. Sie stellte eine Art Motorfunktion für das Projekt dar. Solange der Fortschritt regelmäßig ausgewertet wird, wird weiter am Projekt gearbeitet. Das Jour Fixe als regelmäßige, kurze Besprechung zur Projektsteuerung ist in vielen Fällen ein gut geeignetes Mittel, um diese Regelmäßigkeit herzustellen und das Projektteam oder wenigstens das Kernteam daran zu beteiligen. Dieses Jour Fixe sollte nicht mit einer regelmäßigen Abteilungsbesprechung oder der Verlagskonferenz gleichgesetzt werden. Diese haben andere Zielsetzungen. Im Rahmen des Jour Fixe aus Projektmanagement-Sicht werden lediglich der Soll-Ist-Abgleich durchgeführt, die Prognose erstellt und gegebenenfalls Kompensationsmaßnahmen eingeleitet.
Belastbare Form der Zusammenarbeit herstellen 29
Wann inhaltliche Diskussionen geführt werden, etwa über die Ausstattung eines Buchs oder die Gestaltung einer Website, sollte sich aus dem Zeitplan ergeben. Werden diese Dinge im Jour Fixe besprochen, ist die Wahrscheinlichkeit hoch, dass die Themen der Projektsteuerung zu kurz kommen. Damit entfällt die Motorfunktion und der Vortrieb bleibt aus.
Zeit, Budget und Qualität im Griff behalten Im Rahmen der Projektsteuerung steht das gesamte magische Dreieck der Projektarbeit im Fokus. Dieses so bezeichnete Dreieck steht symbolisch für die Abhängigkeit der Dimensionen Projektdauer, Projektaufwand und zu liefernder Qualität. Die Beziehung dieser Größen untereinander wird im Rahmen der Zieldefinition automatisch festgelegt. Neben der Dauer des Vorhabens gilt es dementsprechend Arbeitsaufwände und Projektbudget zu steuern sowie sicherzustellen, dass die vereinbarte Qualität geliefert wird. Hierfür sind immer die Projektziele Anspruch und Grundlage. Je klarer diese Ziele definiert sind, desto leichter wird sich ein Projektteam mit Entscheidungen nicht nur bezüglich der Projektsteuerung tun. Eben diese Entscheidungen sind zuhauf nötig, wenn die Realität auf einen Plan trifft. An der einen Stelle wurde beispielsweise die Dauer einer Tätigkeit zu kurz geschätzt, eine verzögerte Lieferung droht. Mit zusätzlichem Personal könnte dieser Verzug kompensiert werden, was allerdings die Kosten nach oben treibt. Hat ein Projektteam klare Ziele und einen klaren Rahmen für das Projekt, fällt die Entscheidung leicht. Sind die Ziele nicht klar, führt das meist zu langwierigen Diskussionen, Vertagungen, erneuten Diskussionen und wenig Ergebnis. Das gesamte Projektmanagement-System eines Projekts muss darauf ausgelegt sein, mit Abweichungen gegenüber der ursprünglichen Planung möglichst einfach umgehen zu können. Die Abweichung der Realität gegenüber der Planung ist der Normalzustand. Der Plan versetzt ein Projektteam in die Lage, geeignete Kompensationsmaßnahmen zu identifizieren und einzuleiten.
Belastbare Form der Zusammenarbeit herstellen In der Phase der Umsetzung zeigt sich, wie belastbar die Form der Zusammenarbeit ist. Kern der Umsetzung bildet die zyklische Projektsteuerung. Darüber hinaus ist nun eine systematische Kommunikation wichtig, die dafür sorgt, dass die Zusammenarbeit möglichst reibungsfrei Hand in Hand laufen kann. Dazu gehört auch, Ergebnisse sinnvoll zu dokumentieren und Informationen auf Abruf bereitzustellen, so dass im Bedarfsfall darauf zugegriffen werden kann, ohne dass der Posteingang des Projektteams überquillt. Grundlage guter Zusammenarbeit ist es, dass jeder Beteiligte seine Rolle und damit seine Verantwortung und seine Kompetenzen kennt. Ein Teil dieser Rolle wird über die Zuordnung der Aufgabenpakete im Rahmen der Projektplanung definiert. Allerdings reicht das nicht aus. Jeder Beteiligte sollte wissen, was von ihm erwartet wird und welche Freiräume gegeben sind. Diese sollten geklärt und vereinbart werden, ebenso wie die Spielregeln, nach denen zusammengearbeitet wird.
Magisches Dreieck der Projektarbeit
30 Der Projektablauf im Überblick
Die weitere Verwendung der Projektergebnisse sicherstellen: Übergabe und Projektabschluss Aus dem Projekt Routine werden lassen Irgendwann im zeitlichen Ablauf steht das vereinbarte Projektergebnis zur Verfügung. Nun gilt es dieses Ergebnis in den Routinebetrieb des Unternehmens zu überführen und so die weitere Verwendung sowie Pflege, Wartung und Weiterentwicklung sicherzustellen. Damit wechselt auch die Organisationsform. Aus der Arbeitsform Projekt, das die Herstellung des Ergebnisses erst möglich gemacht hat, soll nun ein effizienter Regelbetrieb werden. Aus organisatorischer Sicht ist dieser Punkt insofern wichtig, da mit Abschluss der Übergabe und des Projekts sämtliche Projektmanagement-Tätigkeiten beendet werden. Bis zu diesem Zeitpunkt wurde der Fortschritt und die Entwicklung etwa über ein Jour Fixe sichergestellt. Jetzt übernehmen die Besprechungen des Regelbetriebs diese Themen, etwa die Verlagskonferenz. Entsprechend muss in der letzten Projektmanagement-Phase sichergestellt werden, dass die Übernehmenden über alle dazu notwendigen Informationen verfügen und die Prozesse und Abläufe klar definiert sind. Gerade in Verlagen ist dieser Zeitpunkt nicht eindeutig zu erkennen, da ein und dieselben Personen während des Projekts und danach für das Thema verantwortlich zeichnen. Umso wichtiger ist es, den Wechsel vom Projekt zum Routineprozess eindeutig zu markieren und zu kommunizieren.
Aus Projekten lernen und Wettbewerbsvorteil aufbauen
Die Erfahrung in der Projektarbeit kann ein schwer zu kopierender, strategischer Wettbewerbsvorteil für einen Verlag werden. Vorausgesetzt die Erfahrung wird gesichert und geteilt.
Ein besonderer Fokus in dieser letzten Projektmanagement-Phase des Projekts liegt darauf, die gewonnene Erfahrung zu sichern. Daraus kann für einen Verlag ein strategischer Wettbewerbsvorteil werden, der nur schwer zu kopieren ist. Gelingt es durch ein gutes, erfahrenes Projektmanagement beispielsweise neue Geschäftsmodelle schneller und systematischer zu erschließen als die Konkurrenz, kann dies ein wichtiger Nutzen sein. Ein Teil dieser Wissenssicherung erfolgt über die Projektdokumentation, die jetzt vervollständigt, abgeschlossen und übergeben wird. Die Kunst ist es hierbei heute schon zu wissen, welche Informationen in Zukunft benötigt werden. Eine Analyse der Anwendungsfälle und Zielgruppen ist hilfreich, um eine schlüssige Dokumentation zu liefern und nicht unnötig Aufwand zu betreiben. Darüber hinaus sind die Erfahrungswerte der Projektleitung und des Projektteams wichtig, da sie für zukünftige Projekte nützliche Informationen liefern können. Der subjektive Bericht der Projektleitung, der den Projektverlauf beschreibt und Hinweise liefert, was zu empfehlen ist und was nicht, ist ein bewährtes Instrument. Außerdem wird eine Sammlung der „Lessons Learned“, der gesammelten Erfahrung des Projektteams, meist als sehr wertvoll betrachtet. Wer daraus einen strategischen Vorteil aufbauen will, nutzt diese Ergebnisse und Erkenntnisse, um einen individuellen Projektmanagement-Prozess für das eigene Haus daraus zu entwickeln. Ein solcher Projektmanagement-Prozess ist quasi ein Routineablauf für Vorhaben, die der Organisation bisher unbekannt sind. Wird ein solcher Ablauf als Hilfsmittel für Projektleiter, Auftraggeber und Projektteam betrachtet und gedacht, führt er meist schnell dazu, dass Projekte mit weniger Reibungsverlust zum Ergebnis kommen als vor Einführung. Als Hilfsmittel eingeführt und nicht
Das Projekt formal beenden 31
als Vorgabe im Sinne von Bürokratie, erhält ein solcher praxisnaher Prozess meist schnell die notwendige Akzeptanz. Methodik-Schulungen und die Bereitstellung geeigneter Hilfsmittel etwa in Form einer Projektmanagement-Software sind hierfür notwendige Begleitmaßnahmen. Auch diese können auf Basis der gemachten Erfahrungen leichter entwickelt beziehungsweise ausgewählt werden, da die Anforderungen präziser zu erfassen sind.
Das Projekt formal beenden Als letzter Schritt auf der Agenda eines Projekts steht dessen formaler Abschluss, der am einfachsten im Rahmen einer Projektabschlusssitzung durchgeführt werden kann. Im Rahmen dieser Sitzung wird das Projektergebnis formal von der übernehmenden Organisation sowie vom Auftraggeber abgenommen. Gleichzeitig wird das Projektteam aufgelöst und damit auch die Projektleitung von ihren Aufgaben entbunden. Mit dem formalen Abschluss geht die Verantwortung auf die Übernehmenden über. Dies kann auch rechtliche Bedeutung haben, etwa wenn inhaltliche Verantwortung für redaktionelle Inhalte übergeben wird. In diesen Fällen kommt dem Protokoll der Übergabebesprechung eine zusätzliche Bedeutung zu.
Einstieg ins Projekt: die Ausgangslage verstehen Der Auftrag in Rohform Frage Nr. 2: Wie lautet der Auftrag? Schlecht formulierte Aufträge führen zu vielen Missverständnissen in Projekten. Eine eindeutige Klärung des Projektauftrags ist elementar, um den Nutzen eines Projekts sicherzustellen. Der Auftrag liefert die Zielvorgaben und unter welchen Rahmenbedingungen diese erreicht werden sollen. Er markiert den Startpunkt des Projekts im Sinne einer Übergabe von Verantwortung vom Auftraggeber an den Projektleiter. Hilfreich ist es für den Auftragnehmer, neben dem eigentlichen Auftrag auch Hinweise darauf zu bekommen, welcher Nutzen erwartet wird und welche Überlegungen dazu geführt haben, dass der Auftrag erteilt wurde.
Auftragsklärung
Die ideale Vorstellung vieler Projektleiter ist es, zu Projektbeginn einen klaren, schriftlichen Auftrag zu erhalten, in dem Ziele benannt und Ressourcen bestätigt sind. Entsprechend sind die meisten, die diese Erwartungshaltung pflegen, regelmäßig enttäuscht. Nicht selten werden Projektaufträge im Aufzug erteilt, frei nach dem Motto: „Gut dass ich Sie treffe. Wir haben da gerade über etwas diskutiert. Kümmern Sie sich doch bitte mal!“ Herzlichen Glückwunsch, Sie sind jetzt Projektleiter! Allerdings ohne formales Mandat, ohne Ressourcen, ohne inhaltliche Angaben. Mit diesem Fakt einher geht die Tatsache, dass wir meist darauf trainiert sind, Ergebnisse zu liefern. Wer Fragen stellt, wird manchmal gar als schwach angesehen. Das Gegenteil ist der Fall: clevere Projektleiter wissen um die Wichtigkeit, Fragen zu stellen. Denn der, der den Auftrag erteilt hat, weiß mehr, als der Projektleiter nach Auftragsübergabe. Leider verzichten manche Projektleiter darauf Fragen zu stellen, nehmen an, sie hätten das schon richtig verstanden und legen los mit der Arbeit. Mit fatalen Konsequenzen: gelegentlich wird erst nach viel Arbeit erkannt, dass der Auftrag eigentlich ganz anders gemeint war. Dann wurde bereits viel Zeit investiert und Geld ausgegeben. Unter anderem deshalb ist es sinnvoll, den Auftrag sauber zu klären bevor sich irgendjemand an die Arbeit macht. Wichtig ist bei der Auftragsklärung unter anderem zu verstehen, was die Absicht hinter dem Mandat ist, was von Ihnen und Ihrem Team erwartet wird. Damit verbunden gleich eine Freigabe für Budgets und Ressourcen zu erwirken halte ich dagegen nicht für sinnvoll. Werden diese Punkte bereits im ersten Gespräch vereinbart, decken sie sich meist nicht mit der Realität und werden so zur Last für das Vorhaben. Wenn diese bereits feststehen, sollte das Projektteam die Eckdaten kennen. Sind diese noch nicht festgelegt, sollte das erst einmal so bleiben. Eine kurze Rücksprache mit dem Auftraggeber – oder zumindest mit der Person, die den Auftrag überbracht hat – kann sich an folgenden Fragen orientieren: • Wie und aus welchen Beweggründen ist das Projekt entstanden? • Welcher Nutzen wird erwartet? • Um welche Themen soll sich das Projektteam kümmern und welche sind nicht mehr im Verantwortungsbereich? • Welche Rahmenbedingungen müssen berücksichtigt werden? • Welche Vorgaben gilt es einzuhalten beziehungsweise zu erreichen? • Welche Ressourcen (Personen, Material, Budget etc.) sind bereits vorgesehen? • Welche Personen sind außerdem in welcher Rolle beteiligt oder sollen beteiligt werden?
Vorlage „Projektauftrag“ 33
Diese Punkte genügen erfahrungsgemäß, um ein erstes Gespräch in Gang zu bringen. Da die Zeit der Führungskräfte oft eng bemessen ist, kann eine Einladung zum Mittagessen ein eleganter Weg sein, um trotzdem zu einer Rücksprachegelegenheit zu kommen. Die Abfrage dieser Daten per E-Mail bringt selten die gleiche Qualität des Ergebnisses, wie ein persönliches Gespräch. Hilfreich ist es außerdem meist, einen Zugang zur Assistenz der entsprechenden Führungskraft zu schaffen und diese in die Kommunikation einzubeziehen. Diese Personen wachen über den Zugang zur Führungskraft und sollten deshalb die Bedeutung des Projekts beurteilen können und Ihren Namen kennen.
Vorlage „Projektauftrag“ Diese Vorlage richtet sich vor allem an Auftraggeber. Wenn Sie als Auftraggeber sicherstellen wollen, dass das Projektteam den Auftrag im Sinne des Auftraggebers versteht, füllen Sie diese Vorlage aus. Falls Sie als Projektleiter einen solchen Auftrag nicht erhalten, füllen Sie ihn selbst aus und fragen Ihren Auftraggeber, ob Sie es in seinem Sinne verstanden haben. Die daraus üblicherweise entstehende Diskussion deckt unterschiedliche Interpretationen auf und sorgt für Auftragsklarheit. Die ist Grundvoraussetzung, dass ein Projekt gelingen kann. Dabei ist nicht wichtig, ob das Formular „richtig“ ausgefüllt wird. Im Gegenteil. Wird etwas „falsch“ ausgefüllt, löst das üblicherweise sofort eine Reaktion aus, da der Auftraggeber die Diskrepanz erkennt und beseitigen will. Er wird erklären wollen, wie seine Aussagen zu verstehen sind. Die Ergebnisse des Gesprächs werden in die Vorlage übernommen. Diese wird diskutiert, bis der Auftraggeber sie gerne und ohne Vorbehalte unterschreibt. Zur Klärung können durchaus mehrere Schleifen nötig werden. Diese sollten dann nicht als störend, sondern als sehr wertvoll empfunden werden. Auftragsklarheit zu einem frühen Zeitpunkt spart sehr viel unnötigen Planungsaufwand und vor allem viele Eingriffe und Änderungen durch den Auftraggeber im laufenden Projekt. Außerdem ist die Diskussion und Klärung des Auftrags eine wichtige vertrauensbildende Maßnahme. Am Ende der Diskussion sollte dem Auftraggeber klar sein, dass sein Projektleiter verstanden hat, um was es geht. Er wird ab sofort mit hoher Wahrscheinlichkeit weniger kontrollieren und eingreifen wollen.
34 Einstieg ins Projekt: die Ausgangslage verstehen
Projektmandat Projekt:
Datum:
Projektleitung:
Auftraggeber:
Auftragsbeschreibung:
Nutzenerwartung:
Hintergrund und Entstehung:
Erwartung an Projektleitung und Projektteam:
Vorgaben (Termine, Zwischenergebnisse, Budget, Qualität):
Relevante Dokumente:
0050 Vorlage Projektmandat (1-00 HZ)_neutral.docx/ Seite 1 von 2
Holger Zimmermann. Projektmensch. • Diplom-Wirtschaftsingenieur (FH) • Hanfweg 10 • D-72160 Horb am Neckar • Telefon +49 7451 55709-0 • [email protected] • www.projektmensch.com
Abbildung 6: Die Vorlage „Projektmandat“ dient dazu, Auftragsklarheit zwischen Projektleiter und Auftraggeber herzustellen.
Das Projekt beginnt jetzt Wann beginnt ein Projekt? Und wann sollte der Projektleiter damit beginnen, die Projektarbeit systematisch zu strukturieren? Aus Sicht der Praxis lassen sich diese Fragen leicht beantworten:
Das vorläufige Projektteam 35
Das Projekt beginnt jetzt, in dem Moment, in dem ein (noch nicht formal benannter) Projektleiter einen (oft mündlich überbrachten) Auftrag eines Auftraggebers erhalten hat und erkennt, dass für das gesamte Vorhaben die Kriterien für ein Projekt erfüllt sind. Die künstliche Unterteilung in eine weitere Vorprojekt-Phase führt meist dazu, dass die Arbeit weiterhin unstrukturiert bearbeitet wird. Was nicht Absicht derjenigen sein kann, die eine Vorprojektphase fordern. Mit einer Vorprojekt-Phase wird lediglich unterstellt, dass das Projekt nicht zwangsläufig auch umgesetzt werden wird. Am Ende der Vorprojekt-Phase steht typischerweise eine Entscheidung, ob und in welcher Form ein Projekt realisiert werden soll. Für weit besser geeignet halte ich den Ansatz, die Arbeit am Projekt gleich zu Beginn zu strukturieren, im Bewusstsein, dass ein Abbruch jederzeit möglich ist und durchaus sinnvoll sein kann. Etwa wenn nach Abschluss der Projektplanung oder einer Machbarkeitsstudie die Erkenntnis zutage tritt, dass sich das Vorhaben nicht lohnen wird. Unter der Annahme, dass das Projekt im Moment der Auftragsübergabe startet, wird die Machbarkeitsstudie schlicht zu einer ersten Phase oder einem der ersten Arbeitspakete im Projekt. Für diesen Abschnitt sollte die Arbeit so gut organisiert werden, wie für jede folgende Phase auch. Ganz abgesehen davon, dass wir immer wieder die Erfahrung machen, dass auf diese Art und Weise die Gesamtziele des Vorhabens und damit der Nutzen bewusster sind, was die Qualität der Ergebnisse einer solchen Phase verbessert.
Das vorläufige Projektteam Frage Nr. 3: Wer sollte und kann mich bei der Projektplanung unterstützen? Zu Projektbeginn steht der Projektleiter vor einem Dilemma: er sollte ein Team für sein Projekt gewinnen, wozu er sagen können muss, in welchem Umfang die Teammitglieder mitarbeiten sollen. Um eben diese Aussage treffen zu können, würde er jedoch bereits das eben noch nicht benannte Team benötigen. Der Ausweg aus diesem Dilemma führt über ein vorläufiges Team: die Mannschaft wird im ersten Schritt lediglich bis zur Projektplanung gebucht. Erst während der Projektplanung wird um die Ressourcen für die Umsetzung verhandelt. Damit steht das endgültige Projektteam erst am Ende der Projektplanung fest.
Im nächsten Schritt gilt es das Projekt systematisch zu erschließen. Das geschieht im Idealfall mit den Personen, die später auch in der Umsetzung eine Rolle spielen. Allerdings sind diese in den seltensten Fällen bereits alle bekannt und für das Vorhaben freigegeben. Trotzdem benötigt der Projektleiter deren Wissen, um eine schlüssige und sinnvolle Vorgehensweise etwa in Form eines Projektplans zu erarbeiten. Ohne diesen Projektplan kann er jedoch nicht benennen, wen er tatsächlich braucht. Ein Henne-Ei-Problem. Oft gibt es natürliche Ansprechpartner für das übergeordnete Thema des Vorhabens. Wobei ich als „natürliche Ansprechpartner“ die Personen bezeichne, die aufgrund ihrer Stellung und ihres Know-hows als zukünftiges Projektteam naheliegen. Wer eine neue Buchreihe für eine spezielle Zielgruppe in den Markt einführen und dabei gleichzeitig ein Webportal aufbauen will, wird Kollegen aus Lektorat, Marketing, Herstellung und IT brauchen, um das Projekt stemmen zu können.
Das Dilemma, in dem ein Projektleiter zu Beginn steckt, betrifft die Ressourcen. Zum einen werden nun Ressourcen benötigt, etwa das Projektteam, zum anderen kann der Projektleiter noch keine Aussage darüber treffen, in welchem Umfang diese Personen benötigt werden. Das wiederum macht es der für das potenzielle Projektteammitglied verantwortlichen Führungskraft schwer, die Person für das Projekt freizustellen. Die
36 Einstieg ins Projekt: die Ausgangslage verstehen Führungskraft kennt den Umfang nicht und muss befürchten, dass eine wichtige Person ihre eigentliche Arbeit nicht mehr machen kann. Ein kleiner Umweg hilft, um dieses Dilemma aufzulösen. Die potenziellen Teammitglieder werden lediglich für den Einstieg ins Projekt und die Projektplanung „ausgeliehen“. Nach Abschluss der Planung ist der Ressourcenbedarf besser bekannt. Dann wird über das endgültige Team verhandelt. Damit wird ein zweites Problem gelöst, das Projektleiter oft haben. Nicht selten wird im Rahmen der Projektplanung erkannt, dass ein Projektteammitglied etwa aufgrund seiner Urlaubsplanung gar nicht so recht zum Projekt beziehungsweise dem Projektverlauf passt. Ist diese Person als vorläufiges Projektteammitglied nur für die Planung verpflichtet, ist es der normalste Vorgang der Welt, dass ein neues Teammitglied hinzukommen und der bisher vorgesehene Kollege aus dem Projektteam entlassen wird. Da jeder weiß, dass die Verpflichtung nur vorläufig war, geschieht dies im offenen Gespräch und ohne Gesichtsverlust. Wobei klar sein dürfte, dass die Wahrscheinlichkeit, dass ein vorläufiges Teammitglied fester Bestandteil des Projektteams wird, sehr hoch ist. Diese vorläufige Projektgruppe sollte dabei nicht zu groß werden, denn große Gruppen erfordern formellere Strukturen, die zum jetzigen Zeitpunkt noch nicht vorhanden sind und gegebenenfalls erst geschaffen werden müssen. Bereits ab acht Personen steigt außerdem die Gefahr, dass sich Subgruppen herausbilden, was die Entwicklung einer gemeinsamen Vorgehensweise deutlich erschwert.2 Außerdem steigt das Risiko, dass Entwurfsaktivitäten abgekürzt werden, da scheinbar zu viele Menschen mit Aufgaben versorgt werden müssen. Sprich, es wird zu Beginn des Projekts zu wenig nachgedacht, was sich später bitter rächt.
Gemeinsames Verständnis als Grundlage guter Zusammenarbeit Frage Nr. 4: Was ist hier los? (Oder: Was wissen wir bereits?) Wer ein Budget hat, der muss es nicht mehr klären. Umgekehrt gilt, dass der, der noch über keines verfügt, noch eines beschaffen muss. Sobald die Ausgangslage bekannt ist, fällt es leicht, die notwendigen Schritte zu definieren. Deshalb muss, um beim Beispiel Budget zu bleiben, bekannt sein, ob es bereits eines gibt oder nicht. Die weiteren Schritte hängen davon ab.
Ein gemeinsames Verständnis der Ausgangslage reduziert Reibungsverluste im weiteren Projektverlauf.
In diesem Punkt ist eine gemeinsame Sicht des Projektteams wichtig, um unnötige Diskussionen im weiteren Projektverlauf zu vermeiden. Ist jedem klar, dass es ein Budget gibt, wird keiner mehr auf die Idee kommen, eines beschaffen zu müssen. Die gemeinsame Klärung der Ausgangslage, der aktuellen Situation, erscheint manchmal banal. Dabei ist sie weit nutzbringender als manch kompliziert erscheinendes Projektmanagement-Werkzeug. Die Reibung sowohl durch Missverständnisse wie auch durch unnötige Diskussionen wird deutlich reduziert. Ganz abgesehen davon hilft ein solch eher verantwortungsfreier erster Schritt, der nicht gleich Lösungen liefern muss, der Arbeitsgruppe auf dem Weg zu einem produktiven Team einen guten Start zu haben. Im Idealfall sind jetzt nicht nur verlagsinterne Mitarbeiter an Bord, sondern auch externe Dienstleister, Autoren und andere am Projekt Beteiligte.
Das Ziel des ersten Treffens des vorläufigen Projektteams ist es, die Grundlagen für die weitere Arbeit zu schaffen. Zu diesem Zeitpunkt treffen unterschiedliche Charaktere mit unterschiedlichen Perspektiven, Meinungen, Erfahrungen und Know-how aufeinander. Das schafft Spielraum für Interpretation. Deshalb ist es wichtig, dass alle Beteiligten ein gemeinsames Verständnis für die Ausgangslage des Projektes haben. Dazu gehören der sachliche Inhalt ebenso, wie die subjektive Interpretation der Beteiligten samt deren Ansichten. Als Einstieg in einen solchen Projektstart-Workshop hat es sich
2 Vgl. The Psychology Of Behaviour At Work: The Individual In The Organisation, Adrian Furnham, Psychology Press, 2005, S. 485f
Ein Fragenkatalog zum Einstieg 37
bewährt, eine gemeinsame Bestandsaufnahme zu machen3. Die muss nicht zwingend Neues zutage fördern, vielmehr geht es um eine gemeinsame Sicht auf die Dinge.
Ein Fragenkatalog zum Einstieg Folgende Fragen haben sich bewährt, um eine Bestandsaufnahme zu machen. Wobei diese sicherlich kein vollständiges Bild ergeben und immer um eigene Fragen ergänzt werden sollten. Offene Fragen. Schließlich ist jedes Projekt einzigartig. • Welche Personen sitzen heute am Tisch? • Wer ist außerdem bereits am Projekt beteiligt? • Wie kam es zur Zusammensetzung dieser Runde? • Wie lautet der Auftrag? • Welche Dokumente wurden mit dem Auftrag übergeben? • Wie sind die Anforderungen an das Ergebnis beschrieben? • Wer sind die Autoren dieser Unterlagen? • Welche Informationen haben wir darüber hinaus über diesen Auftrag? • Welche Zielvorgaben müssen wir einhalten? • Wer ist der Auftraggeber des Vorhabens? • Wer ist der Initiator des Projekts? • Welche Idee steckt hinter dem Auftrag? • Wie ist der Auftrag entstanden, welche Vorgeschichte hat er? • Wer war an der Entstehung beteiligt? • Welcher Nutzen wird erwartet? • Welche Erwartung besteht bezüglich der Vorgehensweise und Projektorganisation von Seiten der Auftraggeber? • Wer sind die Abnehmer oder Nutzer unseres Projektergebnisses? • Wer sind die Menschen, die darüber hinaus ein Interesse an diesem Projekt haben (Stakeholder)? • Welche Erwartungshaltung unterstellen wir wem? • Wer ist in welcher Rolle wo im Unternehmen aktiv? • Welches Know-how haben wir zu diesem Thema und welches nicht? • Welche Partner sind bei derartigen Vorhaben üblicherweise involviert? • Welche Projektmanagement-Unterstützung steht uns zur Verfügung? • Welche Kontakte haben wir, die uns helfen könnten? • Welche Erfahrung haben wir mit dem Thema? • Welche Erfahrung haben wir mit dieser Art von Projekt? • Welche ähnlichen Projekte laufen oder liefen bereits? • Welche parallelen Projekte laufen derzeit und wie relevant sind diese für uns? • Welche Dokumente existieren bereits? • Welche Quellen und Daten stehen uns zur Verfügung? • Was ist unsere Meinung zu diesem Thema? • Wer hat Lust an welchem Teilbereich des Vorhabens mitzuwirken? • Was ist uns wichtig? • Was ist das ursächliche Problem, das wir lösen sollen? • Welche Ideen und Konzeptansätze bezüglich des Projekts gibt es bereits? • Welche Entscheidungen das Projekt betreffend wurden bereits getroffen?
3 Aus „Projektstart: Gemeinsames Verständnis für die Ausgangslage schaffen“, Projektmensch-Blog, Holger Zimmermann, http://blog.projektmensch.com/2013/06/05/projektstart-gemeinsames-verstandnis-fur-die-ausgangslage-schaffen/, abgerufen 5. Juni 2013
Fragen zum Einstieg ins Projekt und zum gemeinsamen Verständnis der Ausgangslage
38 Einstieg ins Projekt: die Ausgangslage verstehen • • • • • • • • • • • • •
Wer die Ausgangslage versteht, hat damit ein solides Fundament für alle weiteren Schritte im Projekt.
• • • • • • • • • • • • • • • •
Welche Vorarbeiten wurden bereits geleistet, etwa von den Auftraggebern? Was gehört zu unserem Verantwortungsbereich? Was gehört nicht mehr zu unserem Verantwortungsbereich? Welche Ressourcen stehen uns zur Verfügung? Wie steht es um die Kapazität der Menschen am Tisch? Welches Budget steht uns zur Verfügung? Was wird über dieses Budget abgerechnet, was nicht? Welche Termine sind für uns relevant? Welche Vorgaben müssen wir einhalten? Welche Vorgehensweisen in Projekten haben sich bewährt? Welche Rollen sind bei uns üblich oder haben sich in der Projektarbeit bewährt? Welche Projektmanagement-Standards sind relevant für uns? Was wurde bereits zur weiteren Vorgehensweise und Organisation des Projektteams überlegt oder in die Wege geleitet? Was ist uns bei der weiteren Zusammenarbeit als Team wichtig? Was sollten wir bei diesem Projekt beachten? Welche Gesetze und Genehmigungen sind für uns relevant? Welche Normen haben für uns Gültigkeit? Mit welchen Annahmen arbeiten wir im Moment? Welche Software steht uns in welcher Version zur Verfügung? Welche Infrastruktur können wir in welcher Form nutzen? Welche Rahmenbedingungen gelten darüber hinaus für uns? Welches Umfeld adressieren wir? Welche Markttrends sind für uns relevant? Welche technologischen Entwicklungen betreffen uns? Welche Erwartungen haben wir selbst an dieses Projekt? Wie passen Projekt und Unternehmensstrategie zusammen? Welche unerwarteten Dinge hat es bereits gegeben? Wie ist die öffentliche Wahrnehmung des Themas derzeit? Welche Fragen sind darüber hinaus noch offen?
Der Fragenkatalog mag lang erscheinen. Das entspricht seinem Wert. Die Antworten sind wie das Fundament, auf dem später Ziele und Projektpläne stehen. Je besser das Fundament, desto stabiler der Aufbau. Projektleiter, die versuchen diesen Schritt abzukürzen, bezahlen das meist mit langwierigen Diskussionen oder gar Reibereien im Projektteam. Bei der oben erwähnten Markteinführung einer neuen Buchreihe mit Webportal oder gar der Entwicklung neuer Geschäftsmodelle sind zwei bis drei Stunden in einem Start-Workshop gut investierte Zeit. Weniger sollte kaum investiert werden, da sonst lediglich an der Oberfläche gekratzt wird.
Die Frage nach den Selbstverständlichkeiten, die man im Kopf hatte, die jedoch nicht genannt wurden, hilft Missverständnisse zu vermeiden und falsche Annahmen zu korrigieren.
Wichtig ist bei der Beantwortung, dass die Antworten ehrlich sind und auch scheinbare Selbstverständlichkeiten auf den Tisch kommen. Was selbstverständlich klingen mag, ist es leider nicht immer. Oder besser: selbstverständlich ist etwas immer nur für den, der es für selbstverständlich hält. Sehr häufig haben wir in Startworkshops erlebt, dass Teilnehmer ob der Antworten überrascht waren. „Was, wir haben auch ein Verkaufsteam in Österreich?“ „Ja, seit Anfang des Jahres.“ „Gut, dass wir darüber gesprochen haben.“ Deshalb eine klare Empfehlung: Bitten Sie die Runde am Ende dieses Tagesordnungspunkts gezielt auch Selbstverständlichkeiten zu benennen. Darüber hinaus verdient ein weiterer Aspekt besondere Beachtung: Nicht selten fühlt sich jemand in Bedrängnis, weil er sich selbst unterstellt, das Projektteam erwarte, er hätte eine Frage bereits klären können. Aufgrund dieser Unterstellung bringt er
Zeit fürs Kennenlernen 39
Hörensagen als Antwort ein. Anstatt ehrlich zu sagen, dass die Frage ungeklärt ist, benennt er eine Annahme oder etwas Gehörtes als Fakt. Ein fataler Fehler, denn nun gehen alle von diesem Fakt aus, der keiner ist. Gerade die Frage nach dem Budget wird häufig so beantwortet. Dabei ist es nur logisch, dass zu Projektbeginn mehr Fragen unbeantwortet als beantwortet sind. Die offenen Fragen zu identifizieren ist eine wertvolle Leistung dieser ersten Übung. Denn daraus lassen sich die Folgeschritte logisch ableiten. Wenn jeder weiß, dass das Budget noch nicht geklärt ist, ist für alle Beteiligten völlig klar, dass es zum einen geklärt werden muss und zum anderen noch kein Geld ausgegeben werden kann. Das reduziert Reibung und unnötige Diskussionen. Offene Fragen sollten unbedingt als offene Fragen erfasst werden. Annahmen und Hörensagen gilt es als solches zu Kennzeichnen. Dann ist für jeden völlig logisch und nachvollziehbar, dass diese Punkte wohl noch geklärt werden müssen. Während einer solchen Besprechung sollten die Ergebnisse für alle Beteiligten sichtbar dokumentiert werden. Da die Punkte jedoch erfahrungsgemäß unstrukturiert genannt werden, jedoch eine strukturierte Dokumentation wünschenswert ist, hat sich das Erstellen einer Mind-Map bewährt. Dabei werden Gedanken in baumähnlichen Ästen samt Verzweigungen gebündelt.
Zeit fürs Kennenlernen Gruppen haben eine bestimmte Dynamik, die sich nicht umgehen lässt. Diese Dynamik beginnt mit der ersten Zusammenkunft, weshalb diese nicht nur aus sachlichen Gesichtspunkten gestaltet werden sollte. Bereits in der ersten Sitzung kann späteren Reibungsverlusten vorgebeugt werden, wenn Zeit fürs Kennenlernen vorhanden ist und dieses Kennenlernen geschickt gestaltet wird. Fünf Phasen sind für die Teamentwicklung typisch4: 1. Forming – der Einstieg in die Gruppenarbeit, die ersten Zusammenkünfte, der auch als „Auftauen“ bezeichnet werden kann 2. Storming – das (öffentliche) Auftreten unterschiedlicher Meinungen und Vorstellungen, der Beginn der „Gärung“ 3. Norming – das Entwickeln von bewussten und unbewussten Spielregeln der Zusammenarbeit, das Abklingen der „Gärung“ 4. Performing – die anvisierte Phase bewusster Teamentwicklung, die auch als „Produktivität“ bezeichnet wird, denn jetzt erst ist produktives Arbeiten möglich 5. Adjourning – die Phase des Abschieds und der Auflösung, die auch als „Ausstieg“ bezeichnet wird Die erste Phase ist dabei eine Phase, die auch als Auftauen beschrieben werden kann5. Die Mitglieder der Gruppe müssen sich orientieren. Das Verhalten ist eher zurückhaltend und auf die Sache bezogen. Gibt es Unstimmigkeiten, werden diese erst einmal nicht ausgesprochen. Jetzt ist es wichtig, den Menschen Raum zu geben. Die verantwortungsfreie Diskussion über die Ausgangslage ist hierfür ein geeignetes Instrument. Sie gibt den Menschen Zeit im Projekt anzukommen. Ziel aller Schritte auf zwischenmenschlicher Ebene ist es, einen möglichst hohen Grad an Kooperation zu erzeugen.
4 Stages of Small-Group Development Revisited, Bruce W. Tuckman/ Mary Ann C. Jensen, Group & Organization Studies, Dezember 1977, Seite 419f. 5 Projektmanagement-Fachmann, Band 1, ohne Autorennennung, RKW-Verlag, 7. Auflage, 2003, S. 345f
Fragen, auf die es noch keine Antwort gibt, sind zu Beginn üblich. Diese sollten als offene Fragen stehen bleiben, also nicht gleich an der Antwort gearbeitet werden.
Das Mind-Map-Buch: Die beste Methode zur Steigerung Ihres geistigen Potenzials, Tony Buzan, Barry Buzan
40 Einstieg ins Projekt: die Ausgangslage verstehen Projektmanagement ist eine kooperative Arbeitsweise. Je besser es gelingt Kooperation zu erzeugen, desto leichter tut sich ein Projektteam in der Zusammenarbeit. Gerade da der Projektleiter auf viele Teammitglieder nur mittels Verhandlung und Vereinbarung einwirken kann und keine hierarchisch bedingte Weisungsbefugnis hat. 80
Wohlbefinden
60 40 20 0
Zeit
-20 -40
Auftauen
Gärung
Produktivität
Ausstieg
Abbildung 7: Teamphasen – aus Basismodule (4–16 HZ). Eignet sich gut als Erklärungsmodell für die Gruppe. Die Gärung ist das „Tal der Tränen“, durch das die Gruppe durch muss.
Die Beschreibung der Teamphasen mit den Begriffen Auftauen, Gärung und Produktivität scheint für Projektteams griffiger zu sein. Es lohnt sich, diese Teamphasen mit dem Team zu besprechen.
In der Praxis hilft es, diese Gruppenprozesse mit der Gruppe anzusprechen. Eine Gruppe, die verstanden hat, dass ein „Tal der Tränen“ kommen wird, findet leichter den Ausgang. Außerdem erhöht sich dadurch die Bereitschaft in der frühen Phase des Projekts Wert auf die Beziehungen, Rollen und Verhaltensweisen aller Beteiligter zu legen. Während das Modell nach Tuckman in derlei Diskussion eher als Abstrakt wahrgenommen wird, löst die Beschreibung der Teamphasen mit der Gärung als Motivationstal eher ein Schmunzeln aus, weshalb ich dieses in der praktischen Anwendung bevorzuge, auch wenn das theoretische Grundgerüst dahinter eher auf Workshops bezogen ist. Der Prozess an sich ist nur bedingt linear. Jede Änderung der Aufgabenstellung kann dazu führen, dass er von vorne beginnt. Ebenso eine Änderung der Teamzusammensetzung, etwa durch neue Teammitglieder oder das Aussteigen eines Kollegen. Entsprechend gilt es für die Projektleitung diesen eher weichen Faktoren der Zusammenarbeit jeweils gerecht zu werden.
Vertrauen aufbauen und Feedback geben
Wer zu Beginn in die Entwicklung des Teams investiert, erhöht damit früh die Produktivität der Zusammenarbeit.
Ein hochproduktives Team tut sich mit der Zusammenarbeit leicht, da die Eigenheiten sämtlicher Beteiligter sowie die Spielregeln des Teams akzeptiert sind. Das muss kein Ergebnis bewusster Entscheidungen sein. Während der Gärungsphase finden die Teilnehmer ihren Platz innerhalb der Gruppe. Damit ist ihre Rolle klar. Sie wissen, oft unbewusst, wann ihre Talente gefragt sind und wann nicht. Sie haben das akzeptiert und verhalten sich entsprechend. Die Zusammenarbeit wird von den Beteiligten oft als mühelos beschrieben. Was während der Gärungsphase innerhalb der Gruppe geschieht, kann mit dem Johari-Fenster erklärt werden. Damit wird modellhaft versucht, die gegenseitigen Wahrnehmungsmöglichkeiten innerhalb einer Gruppe bewusst zu machen. Die direkte Interaktion der Gruppenmitglieder beziehungsweise deren Möglichkeiten zur Interaktion sind maßgeblich dafür, wie gut eine Gruppe funktioniert. Je besser sich die Gruppenmitglieder kennen und akzeptieren, desto besser funktioniert diese Interaktion. Damit ist das Ziel jeder Teamentwicklungsmaßnahme beschrieben. Das Johari-Fenster beschreibt, wie sich Menschen gegenseitig wahrnehmen, und damit deren Persönlichkeitsmerkmale und Verhaltensweisen aus verschiedenen Perspektiven. • Der Bereich A, das öffentliche Ich, beschreibt was allen Beteiligten in Bezug auf ein Teammitglied bekannt ist und dem Teammitglied selbst ebenfalls. Etwa die
Vertrauen aufbauen und Feedback geben 41
•
•
kennen andere von mir
ist mir bewusst
ist mir nicht bewusst
A: Öffentliches Ich
B: Blinder Fleck
C: Private Person
D: Das Unbekannte
kennen andere nicht
•
Tatsache, dass jemand gerne Ideen spinnt und gute Ideen hat. Automatisch wird ein solches Teammitglied in passenden Situationen ins Rampenlicht gestellt und fühlt sich dort vermutlich auch wohl. Der Bereich B, der blinde Fleck, beschreibt etwa Verhaltensweisen, die einem Teammitglied selbst nicht bewusst sind, die andere jedoch sehr wohl wahrnehmen. So könnte ein Teammitglied die Eigenschaft haben, andere gerne zu unterbrechen. Diese Verhaltensweise liegt damit im Bereich des blinden Flecks dieser Person. Die Person selbst nimmt diese Verhaltensweise nicht wahr, andere dagegen schon. Die Verhaltensweise beeinflusst die Produktivität der Zusammenarbeit der Gruppe in beträchtlichem Maße. Der Bereich C, die private Person, beschreibt Dinge, die nur ein Teammitglied selbst von sich weiß und die andere nicht wahrnehmen. Wünsche und Träume sowie Ängste und Schwächen sind in diesem Segment zu finden. Zumindest in der Anfangsphase der Arbeit im Team. Der Bereich D, das Unbekannte, adressiert Verhaltensweisen und Persönlichkeitsmerkmale, die weder den Gruppenmitgliedern noch der einzelnen Person bewusst sind. Etwa die Angst vor dem Fallschirmsprung, die jedoch bei der Einführung einer Software keine Rolle spielt, könnte in diesem Bereich liegen.
Abbildung 8: Mit der Johari-Fenster lassen sich modellhaft die Hintergründe der Teamentwicklung erklären.
Das Unbekannte hat für die Teamentwicklung keine Relevanz. Die anderen Bereiche sind wichtig. Ziel der Teamentwicklung ist es, den Bereich A, das öffentliche Ich, möglichst zu vergrößern, indem die Bereiche B „Blinder Fleck“ und C „Private Person“ verkleinert werden. Je größer dieser Bereich, desto besser können die Beteiligten ihr Verhalten aufeinander abstimmen, was wiederum die Produktivität der Zusammenarbeit steigert. Der blinde Fleck wird kleiner, indem Feedback zum Verhalten einzelner Personen gegeben wird. Die private Person wird kleiner, sobald genügend Vertrauen in die anderen Gruppenmitglieder besteht. Der Grundstein für diese Entwicklung wird in der Startphase, während des Auftauens gelegt. Während dieser Zeit ist es besonders hilfreich, wenn in Formaten gearbeitet wird, in denen sich die Gruppenmitglieder persönlich treffen. Etwa ein Projektstart-Workshop ist ein solches Format, das auch aus Sicht der Teamentwicklung sehr gute Dienste leistet. Im Rahmen solcher Treffen kann der Projektleiter gezielt nach Feedback fragen. Er kann auch außerdem erwünschtes und unerwünschtes Verhalten in der Gruppe thematisieren und reflektieren. Dabei ist in der Startphase nicht zwingend die Einigung wichtig, vielmehr sind die unterschiedlichen Sichtweisen und Standpunkte interessant. Diese können dann später aufgegriffen werden, wenn Uneinigkeit darüber entsteht, wer sich wie verhalten sollte.
In der Startphase eignen sich Formate besonders, die ein persönliches Treffen der Teammitglieder ermöglichen.
42 Einstieg ins Projekt: die Ausgangslage verstehen
Ist-Zustand A C
Soll-Zustand B
Teamaufbau
D
• Vertrauen • Feedback
B
A C
D
Abbildung 9: Ziel der Teamentwicklung ist die Vergrößerung des öffentlichen Ich, um die Zusammenarbeit durch leichtere Interaktion der Beteiligten produktiver zu machen.
Der Projektleiter drückt durch sein Verhalten aus, wie viel er der Gruppe bereits vertraut. Gibt er zu diesem Zeitpunkt Vorschussvertrauen in die Gruppe, ist dies der Teamentwicklung dienlich. Außerdem kann er darauf achten, dass der Erfahrung, den persönlichen Geschichten und Berichten der Beteiligten Raum gegeben wird. Mit diesen Erzählungen öffnen sich die Beteiligten der Gruppe, der Bereich „private Person“ wird kleiner, die Teamentwicklung kommt voran. Kommt es im Rahmen der Gärung zu ersten kontroversen Diskussion, ist das Modell des Johari-Fensters ebenfalls hilfreich. Hinter kritischen Anmerkungen stecken oft unausgesprochene Erwartungen an das Verhalten anderer, die sich im Moment der Kritik entgegen der Erwartung verhalten. Schafft es eine Gruppe, diese Erwartungshaltungen zu besprechen und gar Vereinbarungen bezüglich der Zusammenarbeit zu treffen, fördert das die Teamentwicklung. Aus Sicht der Teamentwicklung ist deshalb ein Team, dessen Mitglieder bereits an anderer Stelle (gut) zusammengearbeitet haben, einem Team mit untereinander unbekannten Mitgliedern vorzuziehen. Ein solches Team wird im Normalfall schneller produktiv zusammenarbeiten. Jeder kennt die anderen, weiß wie diese „ticken“ und welche Erwartungen bestehen, und wird sich diesen Spielregeln der Gruppe anpassen. Ausnahmen gibt es dann, wenn das bestehende Team bisher nicht in die Phase der Produktivität gekommen war oder sich Konflikte verfestigt haben.
Autoren als besondere Teammitglieder
Wer Autoren in die Teamentwicklung einbezieht, sorgt für bessere Kooperation und weniger Reibung.
Im Verlagsumfeld gibt es eine Besonderheit, was die Projektteams betrifft: die Autoren. Während ein Großteil der Teammitglieder häufig fester Bestandteil des Verlags ist oder Dienstleister über viele Jahre für einen Verlag arbeiten, gilt dies für Autoren nicht. Diese haben häufig einen Hauptarbeitsplatz und manche werden nur ein einziges Mal eingesetzt. Sie werden häufig eher als eine Art Lieferant von Texten eingebunden, denn als Teammitglieder betrachtet. Wobei letztere Sicht die passendere ist, liefern die Autoren doch einen wesentlichen Teil des Werks, wenn es sich um ein entsprechendes Projekt handelt. Aus diesem Gesichtspunkt heraus macht es Sinn, die Autoren ebenfalls in den Prozess der Teamentwicklung einzubeziehen. Während bei internen Projekten, etwa der Einführung eines neuen Redaktionssystems, ein Projektstart-Workshop genügen kann, ist es gelegentlich sinnvoll bei der Zusammenarbeit mit Externen zwei StartWorkshops zu machen. Erst einen internen, um sich Klarheit auch über geheim zu haltende Details zu verschaffen, dann ein zweiter, der externe Teammitglieder ebenfalls einbezieht. Wichtig ist an dieser Stelle, dass offen und ehrlich mit dieser Tatsache umgegangen wird, denn sonst ist das Vertrauen gleich zu Beginn zerstört. Und Vertrauen ist eine wesentliche Grundlage guter Teamarbeit.
Risiken systematisch minimieren Risikoanalyse auch als Instrument der Teamentwicklung Die Risikoanalyse hat einen sachlichen Nutzen, der unbestritten ist: Risiken werden erkannt, bewertet und nach Möglichkeit vermieden oder in ihren Folgen gelindert. Dieses Instrument kommt eigentlich dann erstmals zum Einsatz, wenn ein erster Entwurf des Projektplans vorhanden ist. Dann werden alle Bestandteile dieses Entwurfs auf ihre Risiken überprüft und wo sinnvoll, Maßnahmen der Risikominimierung berücksichtigt. Die Risikoanalyse in einer frühen Phase eines Projekts kann einen zweiten, zusätzlichen Nutzen bringen: sie hilft dem Team in einer intensiven Diskussion zu „gären“, die anderen besser einschätzen zu können und damit den Einzelnen ihren Platz in der Gruppe leichter und schneller zu finden. Auf Basis einer scheinbar sachlichen Diskussion tauscht sich das Projektteam über Einstellungen aus und sorgt für Feedback. Insofern lohnt sich Risikobetrachtung in einem frühen Stadium. Sie hat sich bei uns als zweiter Tagesordnungspunkt im Projektstart-Workshop etabliert und bewährt. Wobei zu diesem Zeitpunkt ganz klar gilt: gearbeitet wird am Flipchart und an der Pinnwand, nicht mit PC und Projektor. Die Arbeit mit der Gruppe am Flipchart hat eine ganz andere Dynamik als aus dem Stuhl heraus mit Blick gen Projektionsfläche. Kenner der Projektmanagement-Materie entgegnen an dieser Stelle häufig, man wisse noch zu wenig über das Projekt, um eine systematische Risikoanalyse durchführen zu können. Sie haben vollkommen recht mit dieser Aussage. Dafür ist es zu früh. Diese blauäugige Form der Risikoanalyse hilft allerdings das Projekt besser zu verstehen und einschätzen zu können. Das macht wiederum im nächsten Schritt die Abgrenzung und Formulierung der Ziele leichter. Aus der Beobachtung mehrerer hundert Projektteams wissen wir: die nach einer Risikoanalyse formulierten Projektziele sind von deutlich besserer Qualität, als bei den Teams, die auf diesen Schritt verzichtet haben. Die Projektteams sind sich der Fallstricke und Zusammenhänge des Projekts besser bewusst und deshalb besser in der Lage, das Augenmerk auf die wesentlichen Punkte zu lenken.
Erster Schritt: Risiken listen Frage Nr. 5: Was könnte uns aufhalten? (Und was tun wir, damit das nicht geschieht?) Die Risikoanalyse ist ein Projektmanagement-Werkzeug mit einem sehr guten Aufwand-Nutzen-Verhältnis. Gerade in der Anfangsphase hilft sie, das Projekt abschätzen und eine geeignete Projektstrategie definieren zu können, die Eckpfeiler der Organisation des Vorhabens. Außerdem helfen Risiken, die Projektziele klarer abgrenzen zu können. Zu Beginn der Analyse werden wertungsfrei sämtliche Risiken erfasst, die einem Projektteam in den Sinn kommen. Anschließend werden deren Eintrittswahrscheinlichkeit sowie deren potenzieller Schaden beziffert. Aus der Multiplikation dieser Werte ergibt sich die Risikopunktzahl. Je mehr Risikopunkte ein einzelnes Risiko hat, desto eher sollten Gegenmaßnahmen eingeplant werden, die zu einer Minimierung der Eintrittswahrscheinlichkeit, zu einer Minimierung der Schäden oder zu beidem führen. Die bei der Bewertung stattfindende Diskussion ist darüber hinaus sehr wertvoll für die Entwicklung des Teams, da sich die Beteiligten schnell besser kennenlernen. Entsprechend sollte diese Diskussion in der Gruppe geführt und dafür ausreichend Zeit eingeplant werden.
Eine Risikoanalyse beginnt mit dem Versuch, alle Risiken zu identifizieren. Ziel des ersten Schrittes ist es, eine möglichst lange Liste von Risiken zusammenzutragen. Ob diese sinnvoll sind oder nicht, wird in diesem Schritt nicht bewertet. Alle Einfälle kommen ausnahmslos auf die Liste.
Eine frühe Risikoanalyse sorgt für ein besseres Verständnis für die Zusammenhänge im Projekt und dient gleichzeitig der Teamentwicklung.
44 Risiken systematisch minimieren
Risikoklassen
Nach einer ersten freien Runde, bietet es sich an, verschiedene Risikoklassen zu durchforsten, um die Aufmerksamkeit auf bestimmte Themenfelder zu lenken. So kommen erfahrungsgemäß weitere Risiken auf die Liste. Diese sollten so präzise wie möglich formuliert sein. Je exakter die Formulierung gelingt, desto leichter wird das Risiko bei weiteren Schritten greifbar. Tut sich das Projektteam schwer mit einer exakten Beschreibung, kann es sich lohnen, die Beschreibung des Risikos und der Ursachen separat zu erfassen. So wird deutlicher, was mit dem jeweiligen Risiko gemeint ist, was die spätere Bewertung erleichtert. Typische Risikoklassen sind: • Technische Risiken • Personelle Risiken • Organisatorische Risiken • Wirtschaftliche Risiken • Politische Risiken • Rechtliche Risiken • Strukturelle Risiken • Finanzielle Risiken • Umweltrisiken • Akzeptanzrisiken • Transportrisiken/ Logistische Risiken • Gesundheitsrisiken • Kommunikationsrisiken • Qualitätsrisiken • Höhere Gewalt als Risiko • Strategische Risiken • Prozessrisiken So könnte etwa ein technisches Risiko sein, dass die oben erwähnte neue Buchreihe mit Webportal so viele Anfragen an den parallel installierten Webserver generiert, dass dieser ausfällt und das Webportal zum Buch nicht mehr aufgerufen werden kann. Ein typisches personelles Risiko ist etwa der Ausfall des Projektleiters durch eine schwere Krankheit.
Zweiter Schritt: Eintrittswahrscheinlichkeit schätzen
Nicht für alle Risiken können Gegenmaßnahmen entwickelt werden. Über eine einfache Skala von eins bis zehn werden Risiken deshalb bewertet.
Zumeist gibt es in einem Projekt mehr Risiken, als bearbeitet werden können. Deshalb ist es wichtig, die herauszufinden, die die größte Bedrohung für den Projekterfolg darstellen. Im nächsten Schritt wird deshalb die Risikowahrscheinlichkeit geschätzt. Dabei geht es um die Eintrittswahrscheinlichkeit unter der Annahme, dass das Projektteam „normal“ arbeitet, wie es in der Projektumgebung üblich ist. In einem pragmatischen Ansatz genügt bei den meisten Projekten im Verlag hierfür eine einfache Skala von eins bis zehn, um die Eintrittswahrscheinlichkeit zu bewerten. Es handelt sich dabei eher um eine relative Bewertung der Risiken. Die Bewertung erfolgt hierbei durch die Gruppe. Wie treffsicher Verfahren dieser Art sein können, beschreibt James Surowiecki in „Die Weisheit der Vielen“: 800 Menschen hatten das Gewicht eines Ochsen jeweils auf einer Gewinnspielkarte geschätzt und diese abgegeben, um bei einer Ochsen-Wette den Hauptpreis zu gewinnen. Der mittlere Wert aller Schätzungen ergab 1197 englische Pfund. Das tatsächlich Gewicht lag bei 1198 Pfund.6
6 James Surowiecki, Die Weisheit der Vielen, Goldmann, 2007, S.7f.
Vierter Schritt: Gegenmaßnahmen für die wesentlichen Risiken entwickeln 45
Ein Ergebnis, das in Wiederholungen durch ähnliche Experimente immer wieder bestätigt wurde: die Durchschnittsbestimmung liefert recht treffsichere Ergebnisse. Was allerdings gleichzeitig gegen die Qualität von sogenannten Expertenschätzungen spricht.7 Ist dem Projektleiter zu diesem Zeitpunkt die Wirkung der Risikoanalyse auf die Teamentwicklung wichtiger, sollte die Bewertung der Eintrittswahrscheinlichkeit in einer offenen Diskussion erfolgen, auch wenn darunter die Qualität der Bewertung leiden könnte. Dem Projektleiter obliegt es, die ruhigeren Teilnehmer ebenfalls zu Wort kommen zu lassen. Ist die Qualität der Bewertung der Eintrittswahrscheinlichkeit wichtiger, wird erst von verdeckt bewertet und anschließend diskutiert. Jeder Teilnehmer notiert in diesem Fall seine Einschätzung für jedes Risiko auf einem Blatt Papier. Sind alle Teilnehmer fertig mit der Bewertung, werden die so geschätzten Werte gemittelt und diskutiert.
Dritter Schritt: Schadenshöhe ermitteln Genau genommen kann ein Schaden in vier Dimensionen eintreten: • finanzieller Schaden • zeitlicher Schaden (Verzug) • Schaden an der Qualität des Ergebnisses • Schaden an Leib und Leben In der oben erwähnten, pragmatischen Variante der Risikoanalyse werden diese Auswirkungen in einem Schadenswert gebündelt. Eine Skala von eins bis zehn bietet sich auch hier an, um jedem Risiko die jeweilige Schadenshöhe zuzuordnen. Je höher der vermutete Schaden bei Eintritt des Risikos, desto höher die Punktzahl. Zehn Punkte stehen für ein erfolglos abgebrochenes Projekt, das gar das projekttreibende Unternehmen in Turbulenzen bringt. Ein Punkt steht für ein Risiko, dessen Schaden mit minimalem Aufwand verkraftet werden kann. Es gilt dasselbe Bewertungsprinzip wie auch für die Bewertung der Eintrittswahrscheinlichkeit.
Vierter Schritt: Gegenmaßnahmen für die wesentlichen Risiken entwickeln Auf der Sachebene ist Sinn und Zweck der Risikoanalyse, die Gefahr durch Risiken möglichst klein zu halten. Da jedoch nicht für alle Risiken Maßnahmen zur Minimierung durchgeführt werden können und dies für geringe Risiken auch wenig sinnvoll ist, müssen im nächsten Schritt die wesentlichen Risiken identifiziert werden. Dies geschieht durch die Multiplikation von Eintrittswahrscheinlichkeit (E) und Schadenshöhe (S). Das Produkt daraus ergibt die Risikopunktzahl (R). Je höher die Risikopunktzahl, desto mehr Bedeutung hat ein Risiko für das vorliegende Projekt und desto wichtiger ist es, dafür eine Gegenmaßnahme oder Risikominimierungsmaßnahme zu entwickeln und umzusetzen. Gegenmaßnahmen sind konkrete Aktivitäten, die entweder präventiv durchgeführt werden, um die Eintrittswahrscheinlichkeit zu senken, oder die die Schadenshöhe im Eintrittsfall lindern sollen. Entsprechend ist es meist hilfreich, Verantwortlichkeiten für diese Gegenmaßnahmen zu definieren, so dass die Umsetzung der Gegenmaßnahmen wahrscheinlicher wird.
7 Spyros Makridakis u.a., Tanz mit dem Glück, Tolkemitt Verlag bei Zweitausendeins, 2010, S.197
Schadensdimensionen
46 Risiken systematisch minimieren In Tabelle 1 hat das Risiko mit der Ordnungsnummer 2 die höchste Risikopunktzahl. Entsprechend werden hierfür als erstes Gegenmaßnahmen vorgesehen. In den Bewertungsspalten werden Eintrittswahrscheinlichkeit (E), Schadenshöhe (S) und Risikopunktzahl (R) aufgeführt. Tabelle 1: Pragmatische Risikoanalyse. Erst werden Risiken gelistet, dann bewertet, anschließend für die wesentlichen Risiken Gegenmaßnahmen entwickelt. Nr.
Risiko & Ursache
E
S
R
1
Serverausfall nach Start der Werbung, technisch bedingt
2
7
14
2
Autor fällt aus aufgrund Krankheit
6
9
54
3
Wettbewerber lanciert Konkurrenzprodukt vor uns
3
8
24
3
...
4
...
5
...
Gegenmaßnahme
Verantwortlich
Zwei Autoren verpflichten
...
Die Bewertung in Risikopunkten spiegelt kein objektives Ergebnis wider. Es drückt vielmehr eine aus der Diskussion entstandene Einschätzung des Projektteams aus. Die Bewertung ist eher relativ zu verstehen. Ein Risiko mit einer höheren Risikopunktzahl hat eine größere Bedeutung für das Projekt als ein Risiko mit einer kleineren Punktzahl. Die vergebenen Punkte sind zwischen verschiedenen Projekten nicht vergleichbar, helfen jedoch im Projekt Risiken systematisch zu diskutieren. Daraus folgernd macht es keinen Sinn eine Nichtaufgriffsgrenze auf Basis der Risikopunkte zu definieren. Deshalb werden beginnend mit dem Risiko mit der höchsten Risikopunktzahl in absteigender Reihenfolge so lange Gegenmaßnahmen definiert, bis es dem Projektteam nicht mehr sinnvoll erscheint, Geld und Zeit für weitere Gegenmaßnahmen zu investieren. Im obigen Beispiel würde man also im nächsten Schritt für das Risiko mit der Ordnungsnummer 3, dann für das mit der Ordnungsnummer 1 Gegenmaßnahmen überlegen. Diese Gegenmaßnahmen finden später Eingang in den Projektplan, so dass deren Erledigung nicht außerhalb der regelmäßigen Statusprüfung überwacht werden muss.
Fünfter Schritt: Risikoanalyse zyklisch durchführen Das Verhältnis Aufwand für eine Risikoanalyse zu deren Nutzen wird von nahezu allen Anwendern als sehr positiv beurteilt. Gerade in der Startphase, in der eher noch blauäugig diskutiert wird, hilft das Instrument, das Projekt besser einschätzen zu können. Außerdem geben viele Anwender wieder, dass dadurch die präzise Formulierung der Projektziele leichter gelingt.
Risikoanalyse im Verlag und in Großprojekten 47
Diese erste Analyse markiert den Einstieg in das Risikomanagement im Projekt. Je weiter die Projektplanung vorangetrieben ist, desto konkreter kann eine Risikoanalyse ausfallen. Die erste, ursprüngliche Liste wird deshalb mindestens vor wichtigen Zwischenergebnissen und idealerweise dazwischen in regelmäßigen Abständen wieder hervorgekramt und auf den aktuellen Stand gebracht. So wird sichergestellt, dass die Ergebnisse den aktuellen Erkenntnisstand wiedergeben. Das Klüger-Werden im Projektverlauf findet damit Eingang ins Risikomanagement.
Risikoanalyse im Verlag und in Großprojekten Die hier vorgestellte Variante des Risikomanagements ist eine pragmatische Version, die für typische Verlagsprojekte gut geeignet ist. Der Vollständigkeit halber muss allerdings erwähnt werden, dass es weit präzisere Instrumente des Risikomanagements gibt. So ist etwa die Ausdifferenzierung des vermuteten Schadens in verschiedene Schadensdimensionen (Zeit, Qualität, Aufwand & Menschenleben) bei größeren Projekten sinnvoll. Auch die zusätzliche gezielte Analyse von Ursachen für Risiken hilft, Risiken besser einschätzen und minimieren zu können. Bei Großprojekten ist es außerdem sinnvoll, das nach Gegenmaßnahmen verbleibende Restrisiko zu beziffern und sowohl im Projektbudget wie auch im Zeitplan zu berücksichtigen. Wie mächtig gutes Risikomanagement wirken kann, hat unter anderem Klaus Grewe, Gesamtkoordinator aller Projekte der Olympischen Spiele 2012 in London gezeigt. Am Ende hat er vier Monate vor der Zeit und unter Budget geliefert.8
8 Das Projektmanagement der olympischen Spiele in London 2012 - Leseprobe, https://www.projektmagazin.de/Klaus-Grewe-Projektmanagement-Olympische-Spiele-2012, 13. Juli 2013
Projektziele richten Energie Warum sich viele Projektteams mit Entscheidungen schwer tun
Wer herausfinden will, ob die Ziele wirklich klar sind, kann das mit einem kleinen Experiment tun.
Vielleicht kennen Sie das auch: die Besprechung dauert eine gefühlte Ewigkeit und die Diskussion dreht sich doch immer wieder ums gleiche. Eigentlich müsste eine Entscheidung gefällt werden, aber am Ende werden dann doch nochmal Hausaufgaben verteilt zur weiteren Klärung des Sachverhalts. Selten sind in einer solchen Situation die vorgeschlagenen Lösungen schlecht. Sehr häufig sind die Ziele nicht klar genug, um eine Entscheidung leicht zu machen. Außerdem werden Lösungen für Probleme nicht mit den Zielen in Beziehung gebracht, was die Entscheidung zusätzlich erschwert. Dabei geht es bei einem Projekt einzig und allein darum, vereinbarte Ziele zu erreichen. Obwohl Ziele die Grundlage sind, Entscheidungen treffen zu können, ist deren Verwendung in der Praxis eher selten. Ich rede an dieser Stelle von schriftlich festgehaltenen, präzise ausgearbeiteten Zielen. Auf die Frage nach den Projektzielen höre ich sehr häufig, die seien „eh klar“. Was meist ein großer Irrtum ist, wie man mit einem einfachen Experiment herausfinden kann: Picken Sie sich ein paar beliebige Teammitglieder eines beliebigen Projektteams heraus und bitten Sie diese, die Ziele des Vorhabens einzeln, ohne miteinander zu sprechen, auf ein Blatt Papier zu schreiben. Vergleichen Sie die Ergebnisse und suchen Sie sich gezielt Übereinstimmungen und Abweichungen. Ich habe schon Projektteams erlebt, da war nicht einmal der Grundtenor dessen, was da niedergeschrieben wurde, derselbe. Nun stellen Sie sich vor, dieses Projektteam will eine Entscheidung treffen, um zwischen zwei Lösungen zu wählen. Da jeder seine Entscheidung an der eigenen Zielvorstellung misst, kann die Diskussion über Lösungen lange dauern. Gute Ziele sorgen dafür, dass Entscheidungen leicht fallen, was voraussetzt, dass das Projektteam sich auf gemeinsame Ziele geeinigt hat. Erst wenn dieses Experiment dazu führt, dass alle Nennungen dieselben Ziele anführen, sind die Ziele präzise genug formuliert und von allen gleichermaßen verstanden. Eine wichtige Grundbedingung für die weitere Arbeit.
Auftrag, Zielvorgaben und Projektziel
Projektziele, Projektauftrag, Mandat, Projektskizze
Projektziele werden häufig mit dem Auftrag oder Mandat verwechselt. Wobei die Worte „Auftrag“ oder „Projektauftrag“ keinesfalls einheitlich behandelt werden, weshalb eine Klärung und gezielte Verwendung dieser Worte – hier wie auch im Projekt – nötig und sinnvoll ist. • Projektauftrag: damit bezeichne ich den Moment, in dem ein Auftraggeber eine Person beauftragt, sich eines bestimmten Themas anzunehmen. Viele Projektaufträge werden mündlich überbracht und dabei der Projektleiter nicht formal zum Projektleiter benannt, wenn er auch ab diesem Moment die Verantwortung dafür erhält, das gewünschte Ergebnis zu liefern. Der Projektauftrag enthält mehr oder weniger präzise benannte Zielvorgaben. „Auftrag“ und „Mandat“ sind für mich gleichwertige Begriffe. Der Projektauftraggeber oder Sponsor eines Vorhabens ist verantwortlich für die Übergabe des Projektauftrags, der idealerweise schriftlich verfasst sein sollte. • Projektziel oder Projektziele: Werden vom Projektteam auf Grundlage des Projektauftrags formuliert und sind wesentlich präziser als der Auftrag verfasst. Projektziele beschreiben den Soll-Zustand nach Projektende. Sie beschreiben das
Projektziele formulieren 49
•
zu liefernde Ergebnis in seiner Gesamtheit und formulieren damit auch, welcher Nutzen nach Abschluss vorhanden sein soll. Projektskizze: Die Projektskizze oder der Projektsteckbrief ist die Grundlage für die formale Freigabe des Projekts (siehe „Einen klaren Rahmen schaffen: Projektstart bis Projektskizze“, S. 20 f.). In der Projektskizze werden die Annahmen und Bedingungen formuliert, unter denen das Projektteam die Projektziele für erreichbar hält. Mit der Projektskizze vereinbaren Auftraggeber sowie Projektleitung und Projektteam außerdem, wie vorgegangen werden soll, um die Projektziele zu erreichen, und welche Ressourcen dafür bereitgestellt werden. Zur Erstellung einer Projektskizze ist mindestens ein geringes Maß an Projektplanung nötig, da die Angaben in der Projektskizze sonst nicht belastbar sind. Aus kommunikativer Sicht ist die Projektskizze die Quittung des Projektteams an den Auftraggeber auf dessen Auftrag hin. Sie beschreibt, wie der Auftrag verstanden wurde, welche Projektziele daraus abgeleitet wurden und wie vorgegangen werden soll, um den Auftrag zu erfüllen.
Projektziele formulieren Projektziele beschreiben die Gesamtheit des zu liefernden Ergebnisses als Soll-Zustand nach Projektende. Das klingt banal, ist jedoch gar nicht so leicht zu greifen. Der Projektauftrag fokussiert meist einen zu frühen Zustand im zeitlichen Ablauf. „Führen Sie eine neue Buchreihe inklusive Webportal für die Zielgruppe Delta ein“, könnte etwa ein Projektauftrag lauten. Gemeint ist damit allerdings nicht, dass die neue Reihe im Markt verfügbar ist, vielmehr soll mit der neuen Reihe vermutlich Geld verdient werden. Unter anderem darin liegt der Unterschied zwischen Zielen und Auftrag. Ziele fokussieren auf den Zeitpunkt, zu dem der erwartete Nutzen zur Verfügung steht. Ein Ansatz für ein Projektziel könnte in diesem Fall etwa lauten: „Mit unserer neuen Buchreihe für die Zielgruppe Delta haben wir im ersten Jahr nach Markteinführung einen Umsatz mit gedruckten und elektronischen Büchern von 500.000 Euro netto erwirtschaftet und im dazugehörigen Webportal Zusatzverkäufe mit einem Umsatz von 100.000 Euro netto realisiert.“
Abbildung 10: Das Ziel ist es am Ende wieder unten am Berg zu sein mit schönen Erinnerungen im Kopf und schönen Fotos in der Tasche. Niemand will oben auf dem Berg verhungern.
Die Festlegung des Projektziels lässt sich gut mit einer Bergwanderung erläutern. Dieses Vorhaben beginnt mit der Idee „Auf in die Berge!“, die dem mündlichen Projektauftrag gleich kommt. Würde dieser Auftrag ohne nachzudenken in ein Ziel über-
50 Projektziele richten Energie führt, müsste das Zielfähnchen auf den entsprechenden Gipfel gesteckt werden. Dass dies nicht das Ziel der Klettertour sein kann, ist offensichtlich. Die wenigsten wollen dort oben ankommen und bleiben. Vielmehr ist das erwartete Ergebnis der Bergtour nach Abschluss wieder unten am Berg zu sein, schöne Erinnerungen im Kopf zu haben und schöne Fotos in der Tasche. Dasselbe Prinzip gilt für die Festlegung von Projektzielen. Wann ist das Team wieder unten am Berg? Diesen Zustand gilt es als Projektziel zu definieren. Es ist der Zeitpunkt, zu dem der erwartete Nutzen vollständig oder zumindest ausreichend belegt vorliegt. Frage Nr. 6: Wie sieht die Welt nach Projektende aus? „Beschreiben Sie so präzise und eindeutig wie möglich, welchen neuen Zustand Sie nach Abschluss Ihres Projektes hergestellt haben.“ Dieser Satz steht für die Aufgabenstellung bei der Entwicklung der Projektziele. Projektziele beschreiben den Zustand, der nach Abschluss des Vorhabens erreicht sein soll. Sie sind eine Art Vereinbarung zwischen Auftraggeber(n), Projektleitung und Projektteam über die zu liefernden Produkte sowie den zu liefernden Nutzen. Grundlage dieser Vereinbarung ist der Projektauftrag, der Zielvorgaben enthält. Je klarer und eindeutiger Projektziele verfasst sind, desto leichter werden Entscheidungen. Gute Projektziele sind verständlich geschrieben, die wichtigen Punkte sind nach Möglichkeit messbar definiert und das Ziel enthält Angaben, zu welchem Termin der Soll-Zustand erreicht sein soll. Erfahrene Projektleiter versuchen oft zu beschreiben, was sich nach Abschluss des Projekts gegenüber dem Zeitpunkt des Projektbeginns verändert hat, da dies dem Verständnis dient. Der Zeitpunkt der Zielerreichung liegt meist nach dem Zeitpunkt, auf den sich der Projektauftrag fokussiert, da der erwartete Nutzen erst später zur Verfügung steht. Wenn der Auftrag lautet, eine neue Buchreihe samt Webportal einzuführen, steht das Produkt zwar am Markt bereit, hat aber noch keine Umsätze erzielt, die jedoch eigentliches Ziel hinter dem Auftrag sind. Ziele müssen schriftlich festgehalten werden, um deren Eindeutigkeit sicherzustellen und unterschiedlichen Interpretationen möglichst sowie einem Verwässern über die Projektlaufzeit wenig Raum zu geben.
In der Startphase des Projekts fällt es sehr häufig schwer, die Ziele greifbar zu formulieren. Umso wichtiger ist dieser Prozess, da die Ziele Grundlage für die Auswahl der Maßnahmen sind. Je schwammiger Projektziele sind, desto wertvoller ist es, diese auf den Punkt zu bringen. Wobei es nicht darum geht, Lösungen oder Lösungswege zu beschreiben. Im Gegenteil: Ziele sind lösungsneutral9. Ziele geben dem Projektteam Orientierung und sind letztlich auch Grundlage für Motivation und selbstständiges Arbeiten. Wer die Ziele kennt, kann selbst viel besser abschätzen, wie eine Aufgabe erledigt werden muss, um den Projektzielen bestmöglich zu dienen. Was wiederum den Projektleiter entlastet, da weit weniger Kontrollformalitäten notwendig werden. Viele Projektleiter wünschen sich mehr selbstständiges Abarbeiten von Aufgaben durch die Teammitglieder. Ziele sind dafür eine wichtige Grundlage. Wobei der erste Entwurf der Projektziele in der Startphase auch als solcher verstanden werden darf und sollte. Es ist ein Entwurf, der weiter konkretisiert werden darf. Nicht zuletzt ist die auf den Projektzielen aufbauende Projektplanung gleichzeitig auch eine Prüfung der Projektziele auf deren Schlüssig- und Sinnhaftigkeit. Selbst nach der Freigabe von Projektzielen bedürfen diese häufig einer weiteren Konkretisierung. Eine Konkretisierung ist Verantwortung des Projektteams, sollte allerdings nicht mit einer Änderung der Ziele verwechselt werden. Zieländerungen sind Sache des Auftraggebers und bedürfen mindestens dessen Zustimmung. Zielkonkretisierungen dagegen sind häufig nötig, um den Erkenntniszugewinn des Projektteams
9 Hans-D. Lidtke, Projektmanagement: Methoden, Techniken, Verhaltensweisen, 5. Auflage, Hanser, 2007, S.34
Visuelle Vorstellung und Hilfsfragen 51
über die Projektlaufzeit in den Zielen zu verarbeiten. Sich im Kreis drehende Diskussionen sind ein deutliches Indiz dafür, dass eine Konkretisierung der Ziele zumindest überlegt werden sollte. Hierfür übernimmt die Projektleitung Verantwortung. Der Auftraggeber wird im Rahmen des Berichtswesens hierüber informiert.
Zieldiskussion im Projektstart-Workshop Wie können Sie konkret vorgehen, um Projektziele zu formulieren? Es hat sich bewährt, Projektziele im Rahmen eines Projektstart-Workshops zu entwickeln, da diese Diskussion auch der Teamentwicklung dient. Außerdem ist die Akzeptanz der Ziele im Projektteam wichtig, was eine Diskussion der Teammitglieder voraussetzt. Der Projektleiter nimmt in diesem Fall häufig die Rolle des Moderators ein, der in der Sache neutral sein sollte. Als Moderator ist er verantwortlich dafür, dass die Diskussion gut verläuft, alle Aussagen entsprechend Eingang in das Ergebnis finden und alle Teilnehmer einer Besprechung angemessen zu Wort kommen. Diese Rolle steht in Konflikt zu der Tatsache, dass der Projektleiter verantwortlich dafür ist, das vereinbarte Projektergebnis zu liefern. Er hat damit auch eine inhaltliche Verantwortung für das Ergebnis des Workshops. Allerdings genügt es oft schon, sich dieser Tatsache bewusst zu sein und den Konflikt zu Beginn des Workshops anzusprechen. Dann kann der Projektleiter während des Workshops immer wieder Bezug darauf nehmen und so beide Rollen wahrnehmen, ohne dass sich das Team manipuliert fühlt. Meist ist es der Projektleiter, auf den zu Beginn der Zieldiskussion alle Teilnehmer schauen. Entsprechend gelingt die Diskussion oft leicht, wenn er mit einem Vorschlag für ein Projektziel beginnt und dieser Vorschlag so lange erweitert, ergänzt und korrigiert wird, bis das Projektteam mit dem Ziel vollständig einverstanden ist. Diese auch als Ein-Text-Verfahren bekannte Vorgehensweise10 hat sich in Verhandlungen bestens bewährt und wird von den Anwendern bei der Entwicklung von Zielen als sehr hilfreich beschrieben. Aus Sicht des Projektleiters ist es allerdings wichtig, dass es nicht um gewinnen und verlieren geht. Das Ergebnis der Übung sollte schlicht ein gutes und von den Beteiligten akzeptiertes Projektziel sein.11 Will sich der Projektleiter mit seinem Vorschlag unbedingt durchsetzen, ist das meist kontraproduktiv für den Verlauf des Workshops wie auch für den Verlauf des weiteren Projekts.
Visuelle Vorstellung und Hilfsfragen Um die Gesamtheit des Projektziels erfassen zu können, sind bildhafte Vorstellungen hilfreich. Was sich etwa bei Bauprojekten leicht beschreiben lässt. „Wir bauen ein Haus!“ lautet bei einem solchen Vorhaben oft die Formulierung des (Projekt-)Auftrags. Als Ziel des Vorhabens verbirgt sich dahinter eine ganz andere Vorstellung: „Wir leben mit der ganzen Familie in einem Einfamilienhaus. Jeder von uns hat ein eigenes Zimmer. Die Gemeinschaftsräume (Küche, Essen, Wohnen) sind so großzügig bemessen, dass wir samt allen Omas, Opas und Patentanten Platz finden. Feste mit unseren Freunden sind leicht möglich. Der Garten ist groß genug, dass unsere Kinder dort toben und tollen können.
10 Roger Fisher, William Ury, Bruce Patton, Das Harvard Konzept, Campus, 2006, S.164 11 Eine Anleitung zur Moderation der Ein-Text-Methode liefern Jan Bodo Sperling und Jacqueline Wasseveld in Führungsaufgabe Moderation, 4. Auflage, wrs Verlag, 2000, S. 44f.
52 Projektziele richten Energie Für Gäste steht ein Gästezimmer zur Verfügung und unsere Fahrzeuge haben mindestens einen eigenen Stellplatz. Das Haus ist umweltfreundlich gebaut: sowohl während des Baus wie auch während des Betriebs benötigen wir wenig Rohstoffe. ...“ Eine solche bildhafte Vorstellung kann ein guter Ausgangspunkt sein, um in eine Zieldiskussion einzusteigen. In unserem Beispiel „Neue Buchreihe mit Webportal“ könnte diese lauten: „Unsere neue Buchreihe wird uns förmlich aus den Händen gerissen. Bereits ein Jahr nach Verkaufsstart haben wir über 500.000 Euro netto Umsätze mit Büchern in Papierform und als eBooks erwirtschaftet. Die Registrierungen im zugehörigen Webportal zeigen, dass mehr als 30 Prozent unserer Käufer sich online registriert haben und regelmäßig lesen (durchschnittlich mehr als ein Anmeldevorgang pro Monat). Der Fachhandel mit Ladenlokal stellt unsere Buchreihe aufgrund der einfach zu verwendenden Werbemittel und Aufsteller gerne in den Vordergrund. Mehr als 50 Online-Rezensionen außerhalb der Online-Buchhändler unterstreichen die Resonanz, die die Buchreihe erreicht hat. Dabei sind mindestens neun von zehn Rezensionen positiv. ...“
Bei der Formulierung des Projektziels ist die Vorstellung hilfreich, dass das Projektteam nach erfolgreichem Abschluss des Projekts gemeinsam am Lagerfeuer sitzt und unbeteiligten Dritten berichtet, was das Team auf die Beine gestellt hat: • Was ist nun zu sehen, zu riechen, zu hören, zu fühlen, zu schmecken? • Was hat sich gegenüber dem Ausgangszustand verändert? • Was hat sich nicht verändert? • Wer hat jetzt welchen Nutzen? Welcher Nutzen steht nach Projektabschluss (neu) zur Verfügung? • W oran erkennen die unbeteiligten Dritten zweifelsfrei, dass das Team erfolgreich war?
Stellen Sie sich das Ergebnis mög lichst bildhaft vor und beschreiben Sie es so, dass andere zweifelsfrei erkennen werden, ob Sie erfolgreich waren. Beschreiben Sie auch, was Sie nicht erreichen wollen und was deshalb nicht Ihre Verantwortung ist.
Gerade die visuelle Vorstellung des Ergebnisses beschreiben viele Projektteams als sehr nützlich. Eine bildhafte Darstellungsform verankert das Ergebnis besser in den Köpfen und macht wichtige Zusammenhänge bewusst. Die Journalistenmethode zur Zielformulierung kann diese Gesamtheit gut darstellen. Sie geht von der Idee aus, dass ein versierter Fachjournalist, der kompletten Einblick in das Projekt hat, nach Abschluss des Projekts eine Reportage über das Projektergebnis veröffentlicht. Dieser Bericht wird zu Projektbeginn als Zielbeschreibung verfasst. Außerdem hilft es, sich bei der Zielformulierung bewusst zu machen, was nicht im Rahmen des Projekts bearbeitet werden sollte. Diese Themen können bewusst über Nicht-Ziele formuliert werden, so dass der Verantwortungsbereich des Projektteams klarer abgegrenzt werden kann. Dieser Verantwortungsbereich wird maßgeblich über die Ziele definiert.
Vorlage: Projektziel
Die 1-Text-Methode ist geeignet, um im Rahmen eines Workshops Projektziele zu erarbeiten.
Zur Vorbereitung einer Zielformulierung im Rahmen eines Projektstart-Workshops kann folgende Vorlage dienen. Sie wird den Teilnehmern im Vorfeld des Workshops zu Verfügung gestellt, verbunden mit der Bitte, das Blatt entsprechend auszufüllen. Während des Workshops wird dann dieselbe Struktur auf der Pinnwand genutzt, um die verschiedenen Perspektiven zu einer gemeinsamen Zielformulierung zu integrieren. Eine gute geeignete Methode zur Zielformulierung ist die unter „Zieldiskussion im Projektstart-Workshop“ (Seite 51) erwähnte 1-Text-Methode. Diese kann wie dort mit einem Vorschlag des Projektleiters starten. Alternativ kann der Projektleiter oder
Vorlage: Projektziel 53
Moderator versuchen aus den verschiedenen Vorschlägen der einzelnen Teilnehmer einen ersten Textvorschlag für das Projektziel zu entwerfen. Dieser Vorschlag wird mit genügend Zwischenraum großformatig auf Flipchart oder Pinnwand festgehalten. Daraufhin wird der Text in der Diskussion so lange angepasst, bis die gesamte Gruppe mit der Zielformulierung einverstanden ist. Was nicht passt wird durchgestrichen, wo etwas fehlt wird Text ergänzt.
Abbildung 11: Vorlage Projektziel
54 Projektziele richten Energie
Vollständigkeit von Zielen: nicht nur das Buch zählt Projektaufträge fokussieren oft auf den Hauptgegenstand der Lieferung am Projektende: „Führen Sie eine neue Buchreihe mit Webportal ein.“ Damit sind die Ziele eines Projekts jedoch noch nicht in vollem Umfang beschrieben, denn am Ende des Projekts muss weit mehr stehen, als nur die Buchreihe und das Webportal. So müssen etwa die Wartung und der Service des Webportals sichergestellt sein, Prozesse zur Pflege der Inhalte müssen funktionieren etc. Da Ziele die Grundlage für alle Handlungen und Unterlassungen im Projekt sind, ist es wichtig, diese möglichst vollständig zu erfassen. Nur dann lassen sich daraus schlüssig Projektpläne ableiten. Gerade diese Schlüssigkeit zwischen Zielen und Projektplänen ist ein wichtiger Faktor, der maßgeblich mit darüber entscheidet, wie viel Konfliktpotenzial in einem Projekt entsteht. Je lückenhafter der Schluss zwischen Zielen und Plänen ist, desto mehr Konfliktpotenzial durch Interpretationen entsteht. Wobei beachtet werden muss, dass die Vereinbarung von Projektzielen gleichzeitig auch den Verantwortungsbereich des Projektteams definiert. Um die obige Zielformulierung „Neue Buchreihe mit Webportal“ hinsichtlich Vollständigkeit zu verbessern, sollten (beispielhaft) folgende Punkte ergänzt werden: „... Die Wartung der technischen Plattform sowie des Webservers ist geregelt. Ebenso ist die inhaltliche Pflege und Erweiterung des Webportals definiert. In beiden Fällen sind die Aufgaben im Stellenplan verankert und ein entsprechendes Budget im Rahmen der Jahresplanung bereitgestellt. ...“
Wo sinnvoll und nötig, kann bereits in Zielen eine Struktur entwickelt werden. Ein übergeordnetes Ziel wird in Teilziele zerlegt, die wiederum in Teilziele aufgeteilt werden können. Eine solche Zielhierarchie führt von einem übergeordneten Grobziel auf der untersten Ebene zu präzisen, operational formulierten Detailzielen. Diese wiederum sind Ausgangspunkt für die Formulierung von Anforderungen etwa an das im Projektbeispiel benannte Webportal in Form eines Lastenhefts.
Abbildung 12: Beispielhafter Ausschnitt einer Zielhierarchie für das Beispielprojekt.
Projektziele gemeinsam entwickeln und festlegen 55
Abgrenzung dessen, was nicht zu liefern ist Mit der Festlegung der Projektziele wird erstmals der Verantwortungsumfang des Projektteams definiert. Damit verbunden sind Erwartungen verschiedener Beteiligten. Um sicherzustellen, dass keine Erwartungen mit den Projektzielen verbunden sind, die nicht erfüllt werden sollen, können „Nicht-Ziele“ festgelegt werden. „Nicht-Ziele“ beschreiben die Dinge, die eventuell vom Projektteam als Ergebnis erwartet werden könnten, die das Projektteam jedoch nicht im Rahmen des Projekts liefern wird. Durch die Formulierung dieser Dinge können Missverständnisse vermieden werden. Außerdem fallen dadurch Entscheidungen leichter und Diskussionen im Projektteam kürzer aus, da bestimmte Themen erst gar nicht weiterverfolgt werden müssen, sofern sie Nicht-Zielen dienen. Unterstellt man im Beispielprojekt, dass es eventuell von Seiten verschiedener Stakeholder oder Beteiligter die Erwartung geben könnte, dass mit der Sicherstellung der Wartung des Webportals auch die dafür bisher vorhandenen Prozesse optimiert werden sollten, könnte ein Nicht-Ziel für das Beispielprojekt wie folgt lauten: „... Nicht-Ziel des Projektes ist es, die bestehenden Wartungs- und Pflegeprozesse für Infrastruktur und Betreuung von Webportalen im Verlag zu optimieren. ...“
Projektziele gemeinsam entwickeln und festlegen Eine gute Möglichkeit, die Vollständigkeit sowie die Akzeptanz von Zielen sicherzustellen, ist es, Stakeholder im Laufe der Entwicklung von Zielen zu beteiligen. Diese sollen gezielt aus ihrer Sicht Anforderungen an das Ergebnis benennen. Ein erster Entwurf einer Zielformulierung ist hierfür meist eine gute Gesprächsgrundlage. Wobei je nach Möglichkeit Stakeholder auch im Rahmen eines Projektstart-Workshops beteiligt werden können. Neben Akzeptanz und Vollständigkeit sind auch die Entscheidungskompetenz sowie Mehrheitsverhältnisse Kriterien zur Zusammenstellung der Zielformulierungsgruppe.12 Außerdem sollte berücksichtigt werden, wie hoch die Erwartungen an die Neuartigkeit des Ergebnisses sind. Je höher die Erwartungen an die kreative Leistung des Projektteams, desto eher sollten fach- und/oder unternehmensfremde Personen am Entstehungsprozess beteiligt werden. Sonst ist die Gefahr zu groß genau das zu erfinden, was bisher immer schon erfunden wurde. Die Zielformulierungsgruppe muss sich nicht zwingend mit den Personen decken, die das Projekt planen und umsetzen werden. Allerdings sollten diese so repräsentiert sein, dass auch hier Akzeptanz für die Ziele entstehen kann. Weder das Vorgeben von Zielen durch Auftraggeber noch durch die Projektleitung sind geeignete Wege, um Ziele festzulegen. Nicht immer gelingt es, alle genannten Personen gleichzeitig an einen Tisch zu bekommen. Dann ist es Aufgabe der Projektleitung, eine geeignete Vorgehensweise zu finden, um trotzdem für eine angemessene Beteiligung und Diskussion zu sorgen. Der Projektleitung kommt dabei die Aufgabe zu, die Argumente der jeweils nicht vertretenen Personen weiterzutragen.
12 vgl. Projektmanagement: Methoden, Techniken, Verhaltensweisen, Hans-Dieter Litke, Hanser, 5. Auflage, 2007, S. 37
Eine Zielformulierungsgruppe ist ein geeignetes Gremium, um schlüssige Projektziele zu erarbeiten.
56 Projektziele richten Energie
Erscheinungstermin und Lieferbarkeit als Zwischenziele
Mit Meilensteinen werden wichtige Zwischenziele festgelegt. Sie werden bei Bedarf im Projektverlauf neu definiert. Meilensteine bieten Orientierung und helfen, die Komplexität greifbarer zu machen.
„Jetzt im Handel erhältlich.“ ist ein wichtiger Moment auf dem Weg zu unseren Projektzielen. Allerdings stellt dieser Moment lediglich ein Etappen- oder Zwischenziel dar, einen wichtigen Meilenstein. Meilensteine werden in zwei Schritten definiert. Das erste Mal lassen sich Etappenziele definieren, nachdem das Gesamtziel festgelegt wurde. Nach Erstellung einer ersten Aufgabenübersicht werden diese ersten Meilensteine oft nochmals durch weitere Meilensteine ergänzt, um die Komplexität des Vorhabens besser handhaben zu können. Für die Formulierung von Zwischenzielen gelten dieselben Spielregeln, wie für die Entwicklung des Projektziels. Sie sollten den nach Erreichen des Meilensteins gegebenen Soll-Zustand so eindeutig und vollständig wie möglich beschreiben. Auch hier gilt es, die wesentlichen Eckpunkte messbar zu machen, um zweifelsfrei beurteilen zu können, ob das Zwischenziel erreicht wurde. Im Beispielprojekt „Neue Buchreihe mit Webportal“ wird etwa die Verfügbarkeit des ersten Titels im Handel ein wichtiger Meilenstein sein. Die Formulierung könnte folglich lauten: „Zwischenziel: Der erste Titel der Reihe ist am laut Verzeichnis lieferbarer Bücher im Handel erhältlich und bei jedem Buchhändler im deutschsprachigen Raum käuflich mit einer maximalen Lieferzeit von einer Woche erwerbbar. Das Webportal ist ebenfalls mit allen Funktionen der Stufe 1 laut Entwurf des Lastenhefts in der Version 1.03 vom via Internet zu erreichen. ...“
Mit Dienstleistern arbeiten: Lastenheft, Pflichtenheft, Projektziele
Lastenheft, Pflichtenheft
Spätestens wenn bei einem solchen Projekt Dienstleister ins Boot kommen, etwa um das Webportal für den Verlag zu erstellen, gilt es die Anforderungen an das technische Ergebnis formal und präzise zu benennen. Hierfür haben sich Lastenhefte bewährt. Ein Lastenheft beschreibt, welche Anforderungen etwa ein neues Webportal erfüllen muss, um die Projektziele zu erreichen. Es ordnet sich eindeutig den Projektzielen unter. Während die Projektziele die Gesamtheit des zu liefernden Ergebnisses beschreiben, fokussiert ein Lastenheft auf einen abgegrenzten (meist technischen) Teil der Lieferung. Hierbei werden die Anforderungen idealerweise generisch, sprich: lösungsneutral, formuliert. Während das Lastenheft vom Auftraggeber, in diesem Fall dem Verlag, erstellt und als Grundlage der Ausschreibung beziehungsweise Angebotseinholung verwendet wird, erstellt die liefernde Partei daraus ein Pflichtenheft. Das Pflichtenheft beschreibt, wie der Auftragnehmer gedenkt, die Anforderungen des Lastenheftes zu erfüllen. Je besser die im Pflichtenheft beschriebenen Lösungsansätze die Projektziele erreichen, desto geeigneter ist der Lösungsansatz. Dieser kann dabei durchaus von den Anforderungen des Lastenheftes abweichen, da Dienstleister oft besseres Know-how auf ihrem Gebiet haben und dadurch bessere Lösungen vorschlagen können. Aus diesem Grund ist es aus Projektsicht immer sinnvoll, die Projektziele sämtlichen beteiligten Parteien zur Verfügung zu stellen. Sprechen Anforderungen an die Geheimhaltung dagegen, können in vielen Fällen wenigstens relevante Teilziele weitergegeben werden.
Die Agenda eines Projektstart-Workshops 57
Ausflug: Der Projektstart-Workshop Wie man ganz konkret den Einstieg findet Wo es keinen beschriebenen Weg gibt, wie ein Projekt startet, stellt sich immer wieder dieselbe Frage: Wie mache ich den Anfang? Ein mehr als bewährtes Instrument ist der Projektstart-Workshop. Er stellt den ersten Schritt nach der Auftragsklärung dar. Im Projektstart-Workshop wird versucht, einen roten Faden für den weiteren Projektverlauf zu entwickeln. Dieser Workshop sollte nicht mit einer Kick-off-Besprechung verwechselt werden. Die Kick-off-Besprechung markiert das Ende der Projektplanung und den Beginn der Umsetzung. Damit ist diese Besprechung eine Meilenstein-Besprechung mit besonderem Inhalt, die am Ende der Planungsphase durchgeführt wird. Der ProjektstartWorkshop liegt zeitlich wesentlich früher, noch vor der Projektplanung. Ziel des Projektstart-Workshops ist es, einen ersten Entwurf der Projektziele, eine erste Struktur der Aufgaben und des zeitlichen Ablaufs, sowie eine erste Übereinkunft über die weitere Zusammenarbeit zu haben. Damit wird der Rahmen für das Projekt grob abgesteckt und der Einstieg in die weitere Projektplanung erleichtert. Die Dauer dieses Workshops wird maßgeblich davon bestimmt, wie viel Zeit die Teilnehmer kurzfristig aufbringen können. In vielen Verlagsprojekten ist es sinnvoll, von einem ganzen Tag auszugehen. Innerhalb eines Tages lassen sich ausreichend gute Ergebnisse erzielen. Gleichzeitig ist ein Tag für die meisten Mitarbeiter ein noch zu realisierendes Maß.
Die Agenda eines Projektstart-Workshops Die Agenda des Projektstart-Workshops orientiert sich im Wesentlichen an dem Teil der in diesem Buch vorgestellten 32 Fragen, die sich auf Projektstart und Projektplanung beziehen. Hier ein Vorschlag für eine eintägige Variante des Projektstart-Workshops mit Angaben zur Dauer der einzelnen Tagesordnungspunkte sowie deren Visualisierung. Die zugrunde liegende Annahme ist dabei, dass der Projektleiter oder ein externer Moderator die Moderation des Workshops übernehmen und geeignete Räumlichkeiten sowie Moderationsausstattung in Form von Pinnwänden, Packpapier und entsprechenden Verbrauchsmaterialien zur Verfügung stehen.
Ein Projektstart-Workshop ist ein bewährtes Instrument, um ein Projekt schnell und klar auf die Gleise zu setzen.
Projektstart-Workshop, Kick-off
58 Projektziele richten Energie
Projektstart-Workshop 1-Tages-Variante
Vorschlag zur Tagesordnung Ziele des Workshops
Alle Projektbeteiligten gehen von denselben Grundlagen aus und arbeiten auf dasselbe Ziel hin
Die Projektstruktur ist als gemeinsame Arbeitsgrundlage erarbeitet und Verantwortlichkeiten sind abgestimmt
Die weitere Organisation des Projekts ist vereinbart
Ablauf Ausgangslage erfassen: Was ist hier los?
Es gilt den aktuellen Status Quo aus möglichst vielen Perspektiven zu erfassen, um ein gemeinsames Verständnis für die Ausgangslage bei allen Beteiligten zu schaffen, so dass alle von denselben Voraussetzungen ausgehen; typische Fragen sind (unter anderen):
Wie kam es zu dem Projekt?
Welche Erwartungen verbindet der Auftraggeber über das Lastenheft hinaus mit dem Projekt?
Welche Überlegungen haben zur jetzigen Konzeption geführt?
Worauf legt der Auftraggeber, worauf legen die anderen Beteiligten bei solchen Projekten besonders wert?
Welche Rahmenbedingungen gelten (verfügbarer Platz, Anforderungen anderer Projekte, möglicher Zugang zum Gebäude, gesetzliche Auflagen…)?
Welche andere Vorhaben/ Projekte spielen für dieses Projekt eine Rolle (z.B. Anschluss Förderbänder, Logistikumstellung, …)?
Welche Infrastruktur steht vor Ort zur Verfügung und welche könnte kurzfristig geschaffen werden (z.B. Strom, Wasser, PC, Werkzeug, Transportmittel, …)?
Welche Anforderungen an das Projektmanagement gibt es seitens der Beteiligten (Zeitpläne, Dokumentation, …)?
Welche Softwaresysteme kommen bei wem während des Projekts zum Einsatz?
Welche Schwierigkeiten sehen die Projektbeteiligten bereits, die gelöst werden müssen?
Welche Risiken könnten zu Schwierigkeiten führen?
Wie will der Auftraggeber das Projekt organisieren bzw. welche Erwartungen hat er diesbezüglich an die Lieferanten?
Welche Personen sind in welcher Rolle beteiligt?
Was entscheidet wesentlich darüber, dass das Projekt ein Erfolg wird?
Welche Auflagen müssen eingehalten werden (Normen, Gesetze, Zertifizierungen etc.)?
Welche zeitlichen Vorgaben und Anforderungen gilt es zu erfüllen?
© Holger Zimmermann. Projektmensch / www.projektmensch.com
Die Agenda eines Projektstart-Workshops 59
Welche Ideen und Überlegungen zur Umsetzung der Aufgaben gibt es bei den
Von welchen Annahmen gehen die Beteiligten aus?
Welche Dokumente und Zeichnungen stehen bereits zur Verfügung?
Welche Vorarbeiten sind bereits erledigt bzw. auf welche Ergebnisse können
Beteiligten bereits?
wir aufbauen?
Welche wesentlichen Fragen sind bisher noch offen?
Wichtig ist, dass dieser Punkt eine Informationssammlung ist, keine Diskussion oder gar Entwicklung von Problemlösungen; das Gesamtbild ist wichtig, nicht einzelne Details
Dauer: 2 Stunden (Gesamtdauer: 2 Stunden)
Visualisierung: Mind-Map auf Pinnwand mit Packpapier
Ziele fixieren: Wie sieht die Welt nach Projektende aus?
Den Soll-Zustand, der nach erfolgreichem Projektabschluss erreicht sein soll, möglichst präzise beschreiben. Oft hilft die Vorstellung, dass man sich nach Projektende gemeinsam am Ort des Geschehens trifft und einem Dritten das Ergebnis vollständig vorstellen muss:
Was ist am Tag nach Projektabschluss zu sehen?
Woran erkennt ein Außenstehender, dass das Projekt erfolgreich war?
Welche Kriterien müssen erfüllt sein, damit das Projekt als Erfolg gilt?
Was ist nicht zu sehen (zu hören, zu riechen, zu fühlen, zu schmecken)?
Was darf auf keinen Fall passiert sein?
(Was zu hören, zu riechen, zu fühlen, zu schmecken?)
Dauer: 1 Stunde (Gesamtdauer: 3 Stunden)
Visualisierung: 1-Text-Methode; der Moderator macht auf Basis der Ausgangslage oder einer ersten Info der Teilnehmer einen Vorschlag für einen Text; dieser Text wird solange korrigiert und ergänzt, bis alle Beteiligten damit einverstanden sind und Klarheit über jeden verwendeten Begriff besteht
Projektstrukturplan: Was ist zu tun?
Aufbau eines vollständigen Projektstrukturplans auf mindestens den oberen zwei bis drei Ebenen; beispielhaft die Fragen für bis zu fünf Ebenen:
Aus welchen Teilprojekten besteht das Projekt (z.B. nach Projektbeteiligten gegliedert)?
Aus welchen Teilbereichen bestehen diese Teilprojekte (z.B. nach einzelnen Anlagen, Anlagenteilen oder Baugruppen gegliedert)?
Aus welchen Teilaufgaben die Teilbereiche (z.B. nach Komponenten gegliedert)?
Welche Arbeitspakete sind in welcher Teilaufgabe zu erledigen?
© Holger Zimmermann. Projektmensch / www.projektmensch.com
60 Projektziele richten Energie
Was ist in welchem Arbeitspaket zu tun (Laut DIN nicht mehr Bestandteil des Projektstrukturplans, allerdings wichtig, um Aufgaben verteilen zu können; voraussichtlich im Rahmen eines eintägigen Startworkshops in dieser Detaillierung nicht zu leisten)?
Wichtig:
egal auf welcher Ebene man endet, es muss klar sein, was im jeweiligen Bereich zu tun ist, damit entsprechend Verantwortung vergeben werden kann und über deren Umfang Klarheit besteht
hiermit werden die Grenzen des Projekts und damit der Projektumfang definiert; alle Dinge, die zum Erfolg notwendig sind (z.B. Fundamente, Anschlüsse der Energieversorgung etc.) sollten enthalten sein
Dauer: 2 Stunden (Gesamtdauer: 5 Stunden)
Visualisierung: Ebenen 1 und 2 mit Moderationskarten auf Pinnwänden mit Packpapier, danach eindeutige Nummerierung und Fortsetzung zu „jeder Nummer“ auf FlipchartPapier
Phasenplan: In welchen zeitlichen Abschnitten arbeiten wir auf welches Zwischenergebnis hin?
Grobe zeitliche Abfolge des Projekts in Phasen als einfache Abstimmung der Zeitachse, wobei nach jeder Phase exakt definiert wird, welche Ergebnisse als Meilenstein vorliegen müssen; wichtiges Instrument, um Aufmerksamkeit zu fokussieren, was sich zum Beispiel sehr deutlich auf die Dauer von folgenden Besprechungen auswirkt; die sollten sich jeweils am nächsten zu erreichenden Meilenstein orientieren
Dauer: 45 min (Gesamtdauer: 5‘45 Stunden)
Visualisierung: Phasenplan mit Meilensteinen auf Packpapier, wobei jeder Meilenstein mit Buchstaben eindeutig gekennzeichnet wird und die zu erreichenden Zwischenergebnisse dazu auf Flipchart notiert werden
Verantwortung: Wer übernimmt welchen Bereich (welches Arbeitspaket)?
Festgelegt wird, wer welche Aufgabe übernimmt; ggf. wird je Teilbereich auf der 2. Ebene einfach festgelegt, wer jeweils für welche Klärung verantwortlich zeichnet; Ebenen und Detaillierungsgrad an dieser Stelle stark abhängig vom Projektumfang
Wichtig: keine für den ersten Meilenstein relevante Aufgabe und verantwortliche Person
Dauer: 45 min (Gesamtdauer: 6’30 Stunden)
Visualisierung: mit Kullern (runde Moderationskarten) als Ergänzung direkt im Projektstrukturplan auf der Pinnwand, ggf. ergänzt um Notizen auf Flipchart unter Verwendung der Zuordnung durch das Nummernsystem
© Holger Zimmermann. Projektmensch / www.projektmensch.com
Teilnehmer des Projektstart-Workshops 61
Projektorganisation: Wie organisieren wir die zukünftige Zusammenarbeit?
Typische Fragen:
In welchen Abständen treffen wir uns zum Abgleich der Aufgabenerledigung sowie Klärung technischer Fragen (Konkrete Termine!)?
Wer übernimmt die Organisation dieser Besprechungen?
Wer nimmt daran teil?
Wie wird informiert und dokumentiert?
Wo und wie werden Dokumente gesammelt und bereitgestellt?
Welche Softwaresysteme werden wofür eingesetzt (z.B. ProjektmanagementSoftware, Konstruktionssoftware etc.)?
Wie wird die Versionsverwaltung bzw. das Änderungsmanagement organisiert?
Wie wird bei außergewöhnlichen Ereignissen eskaliert?
Dauer: 1 Stunde (Gesamtdauer: 7’30 Stunden)
Visualisierung: Dokumentation auf Flipchart
Nächste Schritte: Wer macht nun konkret was?
Zusammenfassung der Besprechung wobei jeder Teilnehmer nochmal kurz aufführt, was er nun erledigen wird und geklärt wird, wer das Fotoprotokoll der Besprechung erstellt und wer die Ergebnisse weiter vervollständigt, zum Beispiel zu einem Projektplan des gesamten Vorhabens
anschließend Feedback der Teilnehmer zu Arbeitsergebnissen des Tages und Zusammenarbeit
Dauer: 30 min (Gesamtdauer: 8 Stunden)
Visualisierung: Dokumentation auf Flipchart
Teilnehmer Mindestens der Projektleiter des Auftraggebers und jeweils der Projektverantwortliche aller beteiligten Lieferanten/ Partner, ideal sechs, maximal zwölf Personen (abhängig auch von der Moderationserfahrung des Besprechungsleiters)
© Holger Zimmermann. Projektmensch / www.projektmensch.com
Abbildung 13: Vorlage Projektstart-Workshop
Teilnehmer des Projektstart-Workshops In Abbildung 4 „Von der Idee bis zur Projektskizze“ ist ein gewisses Maß an Planung nötig“ auf Seite 20 ist beschrieben, wie ein vorläufiges Projektteam helfen kann, das mit dem Projektstart verbundene Henne-Ei-Problem der Teambesetzung aufzu-
62 Projektziele richten Energie
Eine Beteiligung des (internen) Auftraggebers eines Projekts am Projektstart-Workshop ist sinnvoll und hilfreich.
Gibt es wesentliche Änderungen in der Zusammensetzung des Projektteams, lohnt es sich, einen weiteren Workshop mit den neuen Team durchzuführen.
lösen. Dieses vorläufige Projektteam bildet grundsätzlich den Teilnehmerkreis für den Projektstart-Workshop. Müssten zu viele Personen beteiligt werden, werden ein Kernteam gebildet und gegebenenfalls mehrere Projektstart-Workshops mit derselben Agenda durchgeführt. Der jeweils nachfolgende Workshop baut dabei auf den Ergebnissen des vorhergehenden auf, die als Vorschläge zur Weiterentwicklung betrachtet werden. Das Kernteam nimmt an allen Workshops teil, um die Kontinuität sicherzustellen. Eine Beteiligung des Auftraggebers am Projektstart-Workshop ist durchaus sinnvoll. Dieser sollte im Idealfall zu Beginn und Ende des Workshops teilnehmen. In der Anfangsphase kann er helfen, Auftrag und Rahmenbedingungen zu präzisieren. Außerdem sind Auftraggeber meist in der Lage, wesentliche Fragen des Projektteams zur Ausgangslage zu beantworten. Gegen Ende des Workshops kann der Auftraggeber gegebenenfalls korrigierend eingreifen und Wissenslücken füllen. In manchen Fällen ist sogar eine erste, vorläufige Freigabe der erarbeiteten Ziele und Pläne möglich, was manchen Folgeschritt erleichtert. Die Wahrscheinlichkeit, dass das Kernteam auch nach Freigabe weiterhin am Projekt beteiligt wird, ist üblicherweise hoch. Trotzdem kann es sinnvoll und nötig sein, einen weiteren Workshop nach Freigabe der Projektskizze durchzuführen. Dies gilt unter anderem dann, wenn große Teile des Projektteams anders besetzt werden als im vorläufigen Projektteam. Eine schlichte und nicht diskutierte Übernahme der Planung für dieses neue Team würde dazu führen, dass die Belange der geänderten Mannschaft darin nicht berücksichtigt sind. Dies wiederum führt zu mangelnder Akzeptanz der Vorgehensweise, womit deren Nutzen gegen Null geht.
Verlagsprojekte planen Das Grundverständnis von Projektplanung Auch auf die Gefahr hin, dass sich an dieser Stelle etwas wiederholt: Projektplanung ist nicht mehr und nicht weniger, als das gemeinsame, systematische Nachdenken über die Vorgehensweise zur Zielerreichung. Dabei werden die Erkenntnisse in bewährter Form visualisiert, etwa Zeitpläne als Balken- oder Ganttdiagramme. Ein Projektplan beschreibt eine mögliche Vorgehensweise zur Zielerreichung, deren Umsetzbarkeit dem Projektteam wahrscheinlich genug erscheint, um sich auf diese Vorgehensweise zu einigen. Um das Thema Projektplanung wird für mein Verständnis zu viel Aufhebens gemacht. Es wird mit Worten wie „Projektstrukturplan“ und „Gantt-Diagramm“ um sich geworfen und über „Software-Tools“ diskutiert. Genau das führt jedoch üblicherweise dazu, dass wenig geplant wird. Was nicht der Anspruch der Projektleitung sein kann. Meist ist es besser, nicht viel über Planung zu sprechen, sondern ohne viele Worte die Planung pragmatisch zu betreiben. Ein paar Argumente für Planung wurden bereits im Kapitel „Das Vorgehen vereinbaren: die Projektplanung“ (S. 25 f.) aufgeführt. Wir alle betreiben bei kleinen wie bei großen Vorhaben das, was Projektplanung letztlich ist: wir erfassen die zu erledigen Tätigkeiten, wir ordnen diese in eine sinnvolle Reihenfolge, prüfen, ob das Budget ausreicht etc. Wir tun das vielleicht in anderer Form, als gewöhnlich mit Projektplanung assoziiert wird. Es gibt dann keine Balkendiagramme oder Netzpläne, statt dessen eine Aufgabenliste und vielleicht viele Haftnotizen. Aus Projektmanagement-Sicht besteht der Unterschied zu dem, was wir eh tun, in zwei Punkten: 1. Nicht jeder einzelne Beteiligte listet seine Aufgaben für sich auf, sondern es wird ein gemeinsamer Plan für alle Beteiligten erstellt. 2. Die Pläne werden auf eine besondere Art visualisiert, die sich bewährt hat und die international verständlich ist. Dieses Grundverständnis ist wichtig, um Ängste und Befürchtungen auszuräumen. Die Erfahrung lehrt außerdem, dass es keinen „richtigen“ Projektstrukturplan und nicht den einen „richtigen“ Zeitplan für ein Projekt gibt. Das Denken in „richtig“ und „falsch“ blockiert mehr als es nützt. Vielmehr ist es wichtig, diese Projektmanagement-Werkzeuge als das zu verstehen, was sie sind: Projektmanagement-Werkzeuge sind Hilfsmittel, die die Arbeit leichter machen und die Erfolgswahrscheinlichkeit steigern sollen. Diese Sichtweise reduziert die Barriere zur Anwendung und nimmt viele Ängste.
Die Struktur des Projekts Einen Überblick über alle Aufgaben verschaffen Grundlage für viele Planungsschritte ist eine Übersicht der anstehenden Tätigkeiten. Diese wird im ersten Schritt mit dem Projektstrukturplan (PSP) erschlossen, der sämtliche zu bearbeitenden Elemente des Projekts beschreibt. Frage Nr. 7: Um welche Themenbereiche müssen wir uns kümmern? Das erste angestrebte Ergebnis der Projektplanung ist eine lange, strukturierte Liste aller Tätigkeiten, die durchgeführt werden müssen, um die Projektziele vollständig zu erreichen. Diese Liste kann nicht
Wer bei der Planung ohne viele Worte über Methodik und Werkzeuge pragmatisch Planung betreibt, kommt oft besser voran, als der, der mit Fachbegriffen um sich wirft.
64 Verlagsprojekte planen in einem Schritt erstellt werden, da wir damit kognitiv überfordert sind. Das Projekt wird deshalb Schritt für Schritt in Aufgabenbereiche zerlegt, um sich in immer kleineren Blöcken der Aktivitätenoder Tätigkeitsliste zu nähern. Hierfür wird der Projektstrukturplan erarbeitet, der auf der Ebene die Themenbereiche beschreibt, um die sich das Projektteam grundsätzlich kümmern muss und in denen deshalb Aufgaben anfallen. Danach wird Themenbereich für Themenbereich weiter unterteilt, bis eine strukturierte Übersicht aller zur Zielerreichung durchzuführender Arbeitspakete vorliegt.
Um sich bei der Entwicklung des PSP nicht zu verstricken, bietet es sich an, mit Hilfsfragen zu arbeiten. Deren erste lautet „Um welche Themenbereiche müssen wir uns kümmern, um die Projektziele zu erreichen?“ Die Antwort darauf wird grafisch einem Organigramm ähnlich erfasst, wobei der PSP keinesfalls ein Organigramm darstellt, sondern lediglich die gleiche Form der Darstellung nutzt.13
Abbildung 14: Die oberste Ebene des Projektstrukturplans beschreibt zu bearbeitende Themengebiete.
Nachdem die Themenbereiche identifiziert sind, wird Themenbereich für Themenbereich mit derselben Fragestellung unter die Lupe genommen. Dabei bringt die Rubrik „Projektmanagement“ Besonderheiten mit sich, die später unter „ProjektmanagementAufgaben im Projektstrukturplan erfassen“ auf Seite 65 erläutert werden. Mit dem Fokus auf das Webportal lautet die Fragestellung: „Um welche Themenbereiche müssen wir uns im Element „Webportal“ kümmern?“ Der PSP wird entsprechend erweitert.
Abbildung 15: Projektstrukturplan Teilthemen beziehungsweise Teilaufgaben auf tiefer liegenden Ebenen.
Danach wird wiederum eines der Elemente auf unterster Ebene herausgedeutet und weiter unterteilt. Allerdings werden die Elemente jetzt bereits so greifbar, dass die Fragestellung varriert werden kann: „Welche Arbeitspakete müssen wir erledigen, damit wir das Thema „Gesamtkonzept“ abhaken können?“ Wobei im Beispiel aufeinanderfolgende Prozessschritte als Arbeitspakete verwendet wurden.
13 Der Projektstrukturplan ist kein Ressourcenplan, Projektmensch-Blog, Holger Zimmermann, http:// blog.projektmensch.com/2012/02/29/ein-projektstrukturplan-ist-kein-ressourcenplan/, abgerufen 7. Januar 2014
Projektmanagement-Aufgaben im Projektstrukturplan erfassen 65
Abbildung 16: Auf der untersten Ebene des PSP werden die Arbeitspakete definiert.
So wird nach und nach eine komplette Übersicht aller Arbeitspakete eines Projekts entwickelt. Themenbereich für Themenbereich wird so lange weiter detailliert, bis die Arbeitspakete so kleinteilig sind, dass sie leicht einer Person oder Gruppe zugeordnet werden können, die sich um die Erledigung kümmern soll.
Projektmanagement-Aufgaben im Projektstrukturplan erfassen Im Projektstrukturplan werden sämtliche Arbeitspakete erfasst, die auf dem Weg zum Projektziel erledigt werden müssen. Das gilt auch für alle Tätigkeiten, die im Rahmen der Projektplanung und -steuerung durchgeführt werden. Denn auch diese Tätigkeiten erfordern Ressourcen, die zum Zeitpunkt der Bearbeitung zur Verfügung stehen müssen. Das ist nur ein Grund dafür, die Projektmanagement-Arbeitspakete ebenfalls aufzuführen. Ganz abgesehen davon, dass diese damit greifbarer werden und somit leichter zu erledigen sind. Zu den wichtigsten Themen in der Rubrik Projektmanagement zählen: • Projekt-Einrichtung mit Erstellung von Grobplanung und Projektskizze • Projektplanung inklusive Ressourcenplanung • Fortschrittssteuerung • Projektkommunikation • Dokumentation Zusätzlich kann ein Arbeitspaket „Projekt-Handbuch“ sinnvoll sein, das im Ergebnis die Projektmanagement-Systematik des Projekts zusammenfasst und als Orientierung für das Projektmanagement-Team sowie das Projektteam dient. Wobei ein Projekt-Handbuch nicht mit einem Projektmanagement-Handbuch verwechselt werden darf. Das Projekt-Handbuch bezieht sich auf ein einzelnes Projekt und hält die dafür spezifischen Projektmanagement-Spielregeln fest. Das Projektmanagement-Handbuch hat unternehmensweite oder wenigstens bereichsweite Gültigkeit und fasst die grundsätzlichen Regeln der Projektarbeit zusammen, die für alle Projekte und Projektteams Gültigkeit haben. Um das Berichtswesen zu erleichtern, können in dieser Rubrik auch die Meilensteine erfasst werden. Als Meilensteine werden definierte Zwischenergebnisse im Projektverlauf bezeichnet. Diese werden obenauf geführt, so dass mit wenig Aufwand eine Zusammenfassung des Projektstatus geliefert werden kann. Dies gilt insbesondere, wenn der Projektplan mittels Projektmanagement-Software aufbereitet wird.
Inhalte der Rubrik „Projektmanagement“ im PSP
Projekt-Handbuch, Projektmanagement-Handbuch
Werden Meilensteine im Projektplan obenauf geführt, können Statusberichte mit sehr wenig Aufwand erstellt werden.
66 Verlagsprojekte planen
Abbildung 17: Der vollständige PSP zeigt den Gesamtumfang der zu erledigenden Tätigkeiten.
Meilensteine bieten Orientierung 67
Standardprozesse des Verlags nutzen Die große Kunst bei der Erstellung von Projektstrukturplänen ist es, den richtigen Grad der Granularität und Detailtiefe zu treffen. Den sachlichen Anforderungen, etwa Zusammenhänge erkennen zu können und eine gute Checkliste zu haben, stehen oft Akzeptanzschwierigkeiten gegenüber. Gerade durch die verschwimmende Grenze zwischen Projekt und Routineprozessen in Verlagen wird Projektplanung oft als unnötig empfunden. Der hohe Grad an Detaillierung obendrein. Umso mehr Beachtung verdient die Grenze zwischen Routineprozessen und echten Projekttätigkeiten. Dort wo auf Routineprozesse des Verlags zurückgegriffen wird, etwa in der Rubrik „Vermarktung: Standardwerbemittel Verlag“ im Beispiel-Projektstrukturplan in Abbildung 17 auf Seite 66, werden die Arbeitspakete so beschrieben, dass eine Übergabe an die Routineprozesse sichergestellt wird. Auf eine weitergehende Detaillierung wird in diesen Fällen verzichtet. Umgekehrt werden die Dinge, die nicht durch Routineprozesse im Verlag abgebildet sind oder die, die bewusst außerhalb dieser Abläufe bearbeitet werden sollen, detailliert ausgearbeitet. Das bewusste Bearbeiten von Aufgaben, die eigentlich als Standard vorhanden sind, außerhalb der Routineabläufe ist ein sehr wirksames Mittel, um die kreative Leistung und damit den Neuigkeitsgrad der Ergebnisse zu steigern.
Software oder Kärtchen und Pinnwand? Ein Projekt ohne Software zu steuern ist möglich. Zunächst hat die Methode Projektmanagement nichts mit einer entsprechenden Software zu tun. Projektmanagement ist eher eine Denkweise und ein Werkzeugkasten. Eine Projektmanagement-Software erleichtert die Arbeit jedoch ungemein, da sie Datenverwaltung und Zeichenarbeit übernimmt. Sie ist ein Mittel, um die Produktivität des Projektmanagements zu steigern. Allerdings ist der Einsatz von Software zu Beginn der Planung nicht empfehlenswert. Die Pinnwand ist das effektivere Instrument während Projekteinrichtung und -planung. Sie liefert einen besseren Überblick und schafft in Besprechungen und Workshops eine bessere Gruppendynamik. Wer sehen will, was das genau bedeutet, muss lediglich die Körperhaltung von Besprechungsteilnehmern beobachten. Wo im Workshop mit Pinnwand im Stehen diskutiert und gezeigt wird, lümmeln die Teilnehmer in Besprechungen mit PC und Projektor eher passiv auf ihren Stühlen. Außerdem fällt es an der Pinnwand jedem einzelnen Teilnehmer leichter, selbst Hand anzulegen und ein Kärtchen zu ergänzen. Die Pinnwand kommt meist an Grenzen, sobald mehr als zwei Ebenen der Projektstruktur erfasst werden. Deshalb ist es ein praktikabler Weg, die grobe Projektstruktur gemeinsam mit Kärtchen und Pinnwand zu entwickeln und das Ergebnis anschließend in eine geeignete Software zu übernehmen. Damit verbunden ist oft auch der Wechsel von Workshop hin zu kleineren Besprechungen, in denen gezielt einzelne Teile der Projektstruktur verfeinert werden. Die Gruppe erstellt die grobe Struktur gemeinsam, in Gesprächen zwischen Projektleiter und einzelnen Fachexperten entstehen die Details einzelner Teile dieser Struktur. Der Projektleiter sorgt für eine durchgehende Systematik.
Phasen als zeitliches Grundgerüst Meilensteine bieten Orientierung Erst nachdem der Projektstrukturplan erstellt ist, wird das ganze Ausmaß des Vorhabens sichtbar. Nicht selten ist die Überraschung ob der Dimension des Projekts groß.
Gerade in der Startphase ist es sinnvoll Pinnwände und Flipcharts zu verwenden. Der PC bleibt erst einmal außen vor.
68 Verlagsprojekte planen Je größer ein Vorhaben ist, desto hilfreicher ist es, dieses Vorhaben in zeitliche Abschnitte zu untergliedern. Erste Zwischenziele werden oft bereits während der Zieldefinition festgelegt (siehe „Erscheinungstermin und Lieferbarkeit als Zwischenziele“, Seite 56). Diese sind meistens inhaltlich bedingt. Jetzt werden diese Meilensteine konkretisiert und bei Bedarf um weitere Zwischenziele ergänzt, um die Vorgehensweise weiter zu strukturieren. Frage Nr. 8: In welchen zeitlichen Abschnitten wollen wir vorgehen? Zeitliche Abschnitte und damit verbundene Zwischenergebnisse helfen, das Projekt weiter zu strukturieren. Diese als Meilensteine bezeichneten Zwischenziele bieten zum einen Orientierung, zum anderen helfen sie, die Komplexität greifbarer zu machen. Kleinere Abschnitte sind gedanklich leichter zu durchdringen, als große.
Meilensteine, Projektphasen, Projektmanagement-Phasen
Die zeitlichen Abschnitte zwischen den Meilensteinen werden als Phasen bezeichnet. Deren Titel beschreibt, welchen Arbeitsschwerpunkt der jeweilige zeitliche Abschnitt hat. Inhaltliche Zwischenziele und Projektmanagement-Phasen werden zu einem Phasenplan integriert. Für das Projekt „Neue Buchreihe mit Webportal“ könnten die zeitlichen Abschnitte wie folgt aussehen: Tabelle 2: Phasen und Meilensteine des Beispielprojekts „Neue Buchreihe mit Webportal“
Grafisch aufbereitete Phasenpläne machen das Erklären eines Projekts leichter.
Nr.
Bezeichnung der Phase
Meilenstein
1
Projekteinrichtung und -planung
Projektskizze und Projektplan sind freigegeben, ein erster Entwurf des Geschäftsplans liegt vor.
2
Anforderungsanalyse
Sämtliche Anforderungen an die Buchreihe und das Webportal sind schriftlich benannt und freigegeben.
3
Titelplanung und Konzeption
Mindestens die ersten fünf Titel der Buchreihe sind definiert und Autoren für mindestens den ersten Titel verpflichtet, das Pflichtenheft für das Webportal ist freigegeben.
4
Programmierung und Herstellung
Das Webportal ist mit allen Funktionen bertriebsbereit, der Druck der Erstauflage gestartet. Der Testbetrieb ist vorbereitet und kann nun beginnen.
5
Testbetrieb
Sämtliche Funktionen des Webportals sind fehlerfrei und einsatzbereit, die Erstauflage liegt fertig gedruckt am Lager. Sämtliche Werbemittel sind einsatzbereit, deren konkrete Verwendung ist geplant.
6
Markteintritt
Der erste Titel der Reihe ist am laut Verzeichnis lieferbarer Bücher im Handel erhältlich und bei jedem Buchhändler im deutschsprachigen Raum käuflich mit einer maximalen Lieferzeit von einer Woche erwerbbar. Das Webportal ist ebenfalls mit allen Funktionen der Stufe 1 laut Entwurf des Lastenhefts in der Version 1.03 vom via Internet zu erreichen. Die Vermarktung ist gestartet.
7
Projektende
Siehe Projektziele.
Grafisch aufbereitete Phasenmodelle sind ein gutes Werkzeug, um den Ablauf eines Projekts zu erläutern. Schnell wird deutlich, wann welche Schwerpunkte gesetzt wurden. Gezielt kann dann auf eine einzelne Phase im Detail eingegangen werden, ohne den Gesamtzusammenhang zu verlieren. Unterschieden werden können dabei
Durchgängigkeit von Projekten: Von Start bis Ende 69
Projektmanagement-Phasen, die auf organisatorische Ergebnisse fokussieren, und inhaltliche Phasen, die entsprechend inhaltliche Ergebnisse zum Ziel haben. Wobei beide Phasen Hand in Hand laufen.
Projekteinrichtung
Projektplanung
Grundverständnis & gemeinsame Sprache
Aufbau Erfahrungswissen
Übergabe & Abschluss
Realisierung
Prozesse, Handbuch & PMO
Experimentieren, Optimieren, Verinnerlichen
Abbildung 18: Grafische Aufbereitung der Projektphasen und Einordnung in die Projektmanagement-Phasen
Eine erste Terminschiene An diesem Punkt der Projektplanung besteht oft die Erwartung, die Meilensteine mit Terminen zu versehen. In der Tat ist dies bei diesem Planungsstand erstmals möglich, wenn auch nur grob. Auf Basis von Erfahrungswerten können die Zeiträume von Meilenstein zu Meilenstein geschätzt werden, was in der Praxis durchaus üblich ist. Dabei ist allerdings die Versuchung groß, die nun geschätzten Meilensteintermine als unverrückbare Fixpunkte im zeitlichen Ablauf eines Projekts zu betrachten. Das macht allerdings nur Sinn, wenn die Termine mit einem detaillierten Zeitplan erarbeitet wurden, da die ersten Annahmen nicht selten weit daneben liegen. Deshalb ist es hilfreich, diese zu diesem Zeitpunkt geschätzten Termine auch als „geschätzte Termine“ zu benennen. Die Angabe von belastbaren Terminen ist erst nach der Erstellung eines Zeitplans und der Zuordnung von Ressourcen möglich.
Durchgängigkeit von Projekten: Von Start bis Ende Die Versuchung ist groß, ein Projekt in einer Abteilung des Verlags zu beginnen und stillschweigend davon auszugehen, dass die anderen Abteilungen schon wissen werden, was wann zu tun ist. Gerade bei Projekten, die sehr nahe an den eigentlichen Leistungen eines Verlags und damit nahe an Routineprozessen sind, geschieht dies häufig. Damit nimmt allerdings eines der größten Missverständnisse in der Projektarbeit seinen Anfang. Nur in echten Routineprozessen kann davon ausgegangen werden, dass andere schon wissen werden, was zu tun ist. In Projekten ist dies nicht der Fall. Wer ein Projekt beginnt, tut gut daran, bereits von Beginn an bis zum vollständigen Ende zu denken, bis an den Zeitpunkt, zu dem der gewünschte Nutzen vorliegt. Mindestens in den Projektzielen sollte sich dies ausdrücken. Selbst wer nur eine Phase eines größeren Vorhabens umsetzen soll, muss bereits jetzt an den Soll-
Software & Karrieremodell
70 Verlagsprojekte planen
Sämtliche am Projektergebnis Beteiligte werden von Beginn an einbezogen. Abteilungsgrenzen spielen dabei keine Rolle.
Zustand nach Abschluss des gesamten Vorhabens denken, um nicht wesentliche Teile auszulassen oder wesentliche Beteiligte nicht zu berücksichtigen. Sämtliche Beteiligte, auch die späterer Phasen, werden in der Startphase des Projekts und an der Planung in angemessener Form beteiligt. Damit wird sichergestellt, dass die Vorarbeit, die letztlich in den frühen Phasen für nachfolgende Phasen geleistet wird, komplett ist und das Projekt durchgängig bis zum Ende durchdacht ist. Geschieht dies nicht, muss in Folgephasen oft nachgearbeitet werden, was zu steigenden Aufwänden und einer längeren Projektdauer führt. Außerdem ist das Risiko der Nicht-Akzeptanz von Ergebnissen und Vorgehensweisen bei Nicht-Beteiligung schlicht zu groß. Eine Beteiligung in den Anfangsphasen eines Projekts bedeutet keinen Zwang, diese Personen dauerhaft in das Projekt einzubeziehen. Gerade Phasenpläne bieten sich an, um mit einzelnen Personen oder Gruppen von Personen Vereinbarungen zu treffen, in welcher Phase sie wie beteiligt werden. So kann es durchaus sein, dass mancher Beteiligte nur in der Startphase und in der Übergabephase am Vorhaben mitwirkt. Selbst ein Wechsel der Projektleitung ist denkbar, wenn auch keinesfalls wünschenswert. Jeder Wechsel und jede Nicht-Beteiligung während definierter Projektabschnitte bedingen jedoch meist eine klare Vereinbarung über diese Beteiligung und ein gute Information während der Phasen, in der die Person nicht beteiligt ist. Sollten die Ergebnisse vorheriger Phasen von den Bearbeitern nachfolgender Phasen nicht akzeptiert werden, führt dies zu teuren und, sachlich betrachtet, unnötigen Korrekturen.
Neue Geschäftsmodelle mit Experimenten erschließen
Wo hohe Risiken sind, etwa bei der Entwicklung neuer Geschäftsmodelle, sind Phasen ebenfalls nützlich, um Risiken begrenzen zu können.
Projektphasen sind darüber hinaus gut geeignet, um das Risiko eines Projekts in beherrschbaren Grenzen zu halten. Dies ist insbesondere hilfreich, wenn es gilt, neue Geschäftsfelder, neue Geschäftsmodelle und neue Einnahmequellen zu erschließen. Angesichts der aktuellen technischen Entwicklung verbunden mit den Möglichkeiten der Digitalisierung ist diese Kategorie von Projekt derzeit eines der strategischen TopThemen in Verlagen. Das Risiko bei der Einführung neuer Geschäftsmodelle, etwa einer Paywall für Inhalte, ist immens groß. Manche Projektrisiken können existenzielle Auswirkungen auf das gesamte Unternehmen haben. Insofern ist es wichtig, die Risiken in beherrschbarem Ausmaß zu halten. Dies kann durch eine Phase des Experimentierens geschehen. Lernen kann man dabei von der Werbebranche und den großen Internet-Konzernen. Diese führen vor der endgültigen Markteinführung einer Idee nicht selten A/BTests durch.14 Durch diese Tests wird etwa festgestellt, welche Version einer Website oder einer Anzeige besser funktioniert. Dazu werden beispielsweise den Besuchern einer Internetadresse zufallsgesteuert unterschiedliche Versionen einer Website geliefert und deren Verhalten anonym ausgewertet. So kann festgestellt werden, welche Variante besser im Sinne der Ziele funktioniert. Mit dieser Erfahrung im Gepäck wird dann das endgültige Produkt fertiggestellt und eingeführt. Die Phase des Experimentierens in Geschäftsmodell-Projekten dient dazu, ein mögliches Geschäftsmodell in experimenteller Form unter möglichst echten Bedingungen zu testen. Damit wird der potenzielle Schaden verringert, sollte das neue Geschäftsmodell nicht die gewünschte Wirkung haben. Außerdem kann so wertvolle Erfahrung über das Verhalten von Kunden gewonnen werden, die eine Optimierung des Modells möglich macht.
14 Vgl. „Schluss mit dem Scheitern“, Christoph Kucklick, Zeit Magazin, Nr. 1/2014, S. 21
Wer will, dass andere mitarbeiten, muss delegierbare Aufgaben formulieren 71
Das Experiment wird dabei beispielsweise so aufgebaut, dass nur ein Teil der Kunden mit einem neuen Geschäftsmodell bedient wird während die übrigen nach wie vor über das bestehende bedient werden. Gerade wo digitales Geschäft im Vordergrund steht, können solche Experimente mit relativ wenig Aufwand durchgeführt werden. Aus organisatorischer Sicht bietet es sich an, die Phase explizit im Phasenplan des Projekts zu verankern, da eine besondere Perspektive mit dieser Phase verbunden ist. Es gilt in dieser Zeit zu experimentieren und zu lernen. Im Ergebnis soll der Meilenstein „Geschäftsmodell bestätigt und optimiert“ erreicht werden. Im Beispielprojekt „Neue Buchreihe mit Webportal“ ist vor allem das Webportal mit Risiken behaftet, während bei einem Verlag wohl davon angegangen werden kann, dass die Einführung einer neuen Buchreihe eher kalkulierbarere Risiken mit sich bringt. Ist noch keine Erfahrung vorhanden, wie Besucher der Website am besten zu einem Kauf verleitet werden, könnten verschiedene Aufbereitungen, Besucherführungen und Layouts getestet und verglichen werden. Die erfolgversprechendste Variante wird auf Basis der gewonnenen Erfahrung optimiert, nochmals getestet und dann zu endgültigen Umsetzung freigeben. Damit ist die Phase „Experimentieren und Lernen“ abgeschlossen.
Projekteinrichtung
Anforderungsanalyse
Projektplanung
Titelplanung & Konzeption
Übergabe & Abschluss
Realisierung
Experimentieren & Lernen
Programmierung & Herstellung
Testbetrieb
Abbildung 19: Phasenplan des Beispielprojekts mit Phase „Experimentieren & Lernen“
Eine solche Phase kostet Geld. Dieses Geld stellt eine Investition in ein geringeres Risiko des Scheiterns dar. Die Entscheidung darüber, ob dieses Geld investiert werden soll, ist Sache des Auftraggebers. Die Projektleitung trägt die Verantwortung dafür, einen geeigneten Weg vorzuschlagen.
Die Aufgabenliste Wer will, dass andere mitarbeiten, muss delegierbare Aufgaben formulieren Der Projektstrukturplan markiert den Einstieg in die Projektplanung. Er ist Ausgangsbasis für die Erstellung einer detaillierten Aufgabenliste. Arbeitspaket für Arbeitspaket werden nun alle Tätigkeiten identifiziert, die irgendwann irgendjemand erledigen muss, um die Projektziele zu erreichen. Dabei ist es unerheblich, wer diese Aufgaben durchführen wird. Jede einzelne Aktivität wird erfasst. Frage Nr. 9: Was ist zu tun? Auf Basis des Projektstrukturplans werden sämtliche durchzuführenden Tätigkeiten für jedes einzelne Arbeitspaket aufgelistet. Diese Aktivitäten sollten so kleinteilig sein, dass sie delegierbar sind. Sprich:
Markteintritt
72 Verlagsprojekte planen eine Person, die die Aufgabe umsetzen soll, muss eindeutig wissen, was getan werden muss. Dabei sollte die Zuordnung einer Tätigkeit zu einer Personen oder Gruppe von Personen ebenso eindeutig sein, so dass die Verantwortung für eine Aufgabe präzise geregelt werden kann. Die Zuordnung Tätigkeit und Ressourcen muss eindeutig sein. Außerdem sollten die Aktivitäten so kleinteilig aufgelistet sein, dass sowohl deren Dauer wie auch der damit verbundene Aufwand geschätzt werden können.
Tätigkeit, Aufgabe, Aktivität
Während die bisherigen Elemente des PSP mit Substantiven beschrieben sind, werden Aktivitäten aktiv, sprich mit Verben formuliert. Das erhöht die Eindeutigkeit dessen, was getan werden muss. Es ist eben ein Unterschied, ob in einer Aufgabenliste „Vertrag“ steht oder „Vertrag schreddern“. Die Begriffe Tätigkeit, Aufgabe und Aktivität werden üblicherweise synonym verwendet.
Darstellung als strukturierte Liste In der Praxis wird nun die Darstellungsform gewechselt. Während der Projektstrukturplan mindestens auf den oberen Ebenen in einer einem Organigramm ähnlichen Darstellung aufbereitet wird, wird nun mit einer strukturierten Liste gearbeitet. Die im Projektstrukturplan verwendeten Ebenen werden über Einrückungen dargestellt. Außerdem werden jetzt die Tätigkeiten üblicherweise nummeriert. Im Beispielprojekt könnte der in Abbildung 20 beispielhaft dargestellte Teil der Aktivitätenliste wie folgt aussehen: 3. Buchreihe 3.1. Gesamtkonzept Reihe 3.1.1. ... 3.2. Autorenleitfaden 3.2.1. ... 3.3. Dokumentvorlagen 3.3.1. ... 3.4. Ersttitel 3.4.1. Autor(en) 3.4.1.1. Potenzielle Autoren recherchieren 3.4.1.2. Vorauswahl treffen 3.4.1.3. Erstgespräche führen 3.4.1.4. Zweite Auswahl: Autorenkreis weiter einschränken 3.4.1.5. Verhandlungen führen 3.4.1.6. Vertrag entwerfen 3.4.1.7. Verträge abstimmen 3.4.1.8. Verträge unterschreiben 3.4.1.9. Standardinformationen für Autoren und Vorlagen bereitstellen 3.4.1.10. Terminplan abstimmen 3.5. Layout 3.5.1. ... 3.6. ...
Detaillierungsgrad der Aufgabenliste Wenn ein Plan genug Details sichtbar macht, werden Zusammenhänge deutlich und damit Engpässe, Ressourcenbedarf und Schlüsselstellen greifbar.
Sehr häufig zögern Projektplaner, wenn es um einen hohen Grad der Detaillierung im Projektplan geht. Der Aufwand ist vermeintlich zu hoch, alle Aufgaben kleinteilig zu erfassen. Auch das Argument, man könne den Mitstreitern doch nicht klein-klein vorschreiben, wie sie arbeiten sollen, wird häufig angeführt. Das ersticke doch jegliche Kreativität.
Detaillierungsgrad der Aufgabenliste 73
Abbildung 20: Beispiel für einen Teil der Aktivitätenliste im Projektstrukturplan
74 Verlagsprojekte planen
Projektplanung ist ein kooperativer Prozess, kein Anweisen von Arbeit durch den Projektleiter.
Im Projektplan sichtbar gemachte Aufgaben lassen sich besser verteilen und steuern, als nicht sichtbare Tätigkeiten.
Detaillierungsgrad der Projekt planung
Aus meiner Sicht entspringen diese Argumente einem falschen Verständnis des Wortes „Projektplanung“. Wer zu wenig Details in den Projektplan aufnimmt, sollte sich diese Zeit besser sparen. Ein zu wenig detaillierter Projektplan bringt keinen Nutzen und wird deshalb mit Recht in der Papiertonne landen. Nur ein gutes Maß an Details liefert Erkenntnisse über Engpässe, Schlüsselstellen im Projekt und den Ressourcenbedarf. Wobei gerade die mangelnde Transparenz in Sachen Personalausstattung von denselben Personen bemängelt wird. Dabei könnten diese selbst Abhilfe schaffen, indem sie einen echten Einblick in das Projekt in Form eines ausreichend detaillierten Projektplans schaffen. Auch auf die Gefahr hin, dass ich mich erneut wiederhole: Projektplanung ist nichts anderes, als das gemeinsame, systematische Nachdenken über ein Projekt. Wobei die Ergebnisse auf eine Art und Weise erfasst werden, die sich bewährt hat. Nicht mehr. Nicht weniger. Wobei der Projektplan auf der untersten Ebene Tätigkeiten erfasst, Aufgaben beschreibt, nicht inhaltliche Lösungen. Die sollen erst durch die Erledigung der Aufgaben geschaffen werden. Spätestens damit ist das Argument, man dürfe die Kreativität nicht einschränken, ebenfalls vom Tisch. Die kreative Leistung der Entwicklung einer Lösung darf immer noch erbracht werden. Der Projektplan sagt am Ende wann wer welche kreative Leistung bringen darf – oder muss. Aus diesem Verständnis heraus muss klar sein, dass Projektplanung nichts mit Vorschreiben zu tun hat. Im Gegenteil. Als fähiger Projektplaner frage ich die Menschen, wie sie in ihrem Arbeitspaket vorgehen wollen, um das von ihnen erwartete Ergebnis zu liefern. Diese Aufgabenliste übernehme ich in den Projektplan und versuche sie mit den Antworten der Kollegen in Einklang zu bringen. Wo nötig, werden Schnittstellen und Übergaben im Detail abgestimmt, was einer Verhandlung gleich kommt. Die Rolle des Planers ist dabei die eines Moderators, der die Vereinbarung der Beteiligten in Form eines Projektplans dokumentiert. Außerdem muss klar sein, dass die zur Zielerreichung durchzuführende Menge an Aufgaben erledigt werden muss, unabhängig davon, ob sie im Projektplan erfasst wurde oder nicht. Wobei offensichtlich ist, dass eine auf einem Blatt Papier sichtbare Aufgabenliste leichter zu steuern ist, als eine auf verschiedene Köpfe des Projektteams verteilte, unsichtbare Liste. Gerade wenn es um die Zusammenarbeit von mehreren Personen geht, die immer unterschiedliche Aufgabenlisten im Kopf haben werden. Im Projektplan steht keine Aufgabe, die nicht erledigt werden muss. Umgekehrt sollte auch keine fehlen. Einen praktikablen und nützlichen Detaillierungsgrad eines Projektplans hat man dann erreicht, wenn folgende vier Kriterien erfüllt sind: 1. Die Aufgabe ist delegierbar, sprich die Person, die eine Aufgabe erledigen soll, muss sie verstehen. Besteht ein Projektteam aus vielen Praktikanten, wird eventuell ein höherer Detaillierungsgrad sinnvoll sein, als bei einem Team mit erfahreneren Mitstreitern. 2. Die Dauer der Aufgabe ist greifbar. Je kleinteiliger Tätigkeiten beschrieben sind, desto leichter fällt es Projektteams erfahrungsgemäß deren Dauer zu schätzen. Immer wenn eine intensive Diskussion über die Erledigungsdauer, oder den damit verbundenen Arbeitsaufwand, einer Tätigkeit entsteht, ist dies ein deutlicher Hinweis darauf, dass diese Aufgabe in kleinere Arbeitsschritte aufgeteilt werden sollte. 3. Die Zuordnung von Ressourcen ist eindeutig. Sobald unterschiedliche Personen unterschiedliche Teile einer Tätigkeit erledigen sollen, ist es ein Muss, diese unterschiedlichen Teile der Aufgabe zu beschreiben. Es ist ein wesentlicher Nutzen der Projektplanung, dass jeder ohne separate Anweisung weiß, was er wann tun muss. Der Projektplan nimmt damit Koordinationsaufwand ab, was sich etwa in kürzeren Besprechungen niederschlägt, da wenig in Diskussion abgestimmt werden muss.
Qualitätssicherung und Dokumentation einplanen 75
4. Der Fortschritt einer Tätigkeit ist sicht- und kontrollierbar. Die Fortschrittsmessung im Projekt erfolgt in regelmäßigen Abständen. An jedem Kontrollpunkt sollten Ergebnisse sichtbar sein. Sind etwa Ergebnisse einer Tätigkeit zählbar, kann diese gröber im Projektplan erfasst werden, als bei einer Tätigkeit, deren Ergebnisse nicht in zählbaren Einheiten münden. Wer Ergebnisse sichtbar macht, erlebt weniger negative Überraschungen in Form von kurzfristig vor dem geplanten Bearbeitungsende bekannt gegebenen Terminüberschreitungen. Wird so detailliert geplant, fürchten Projektplaner außerdem häufig, den Überblick zu verlieren. Auch hier gilt das oben aufgeführte Argument: die Menge an Aufgaben ist bereits da, unabhängig von deren Erfassung im Projektplan. Schreibe ich die Aufgaben nicht auf, habe ich als Projektleiter weit weniger Überblick, als wenn diese in einer Aufgabenliste erfasst sind.
Nicht jedes Detail im Plan muss selbst geplant werden Zu wenig detaillierte Projektpläne entstehen oft auch deshalb, weil das Projektteam die genauen Arbeitsschritte innerhalb einer Teilaufgabe in einem Projektplan nicht kennt. Etwa wenn ein Dienstleister einen Bereich übernehmen soll, ist das der Fall. Folglich werden in diesem Bereich des Plans die Aufgabenpakete nur grob erfasst. Sehr häufig ist das ein Fehler, der zu kurzfristigen Planänderungen und zeitlichem Verzug führt. Für den Einstieg in die Projektplanung ist dieser grobe Grad der Detaillierung vollkommen in Ordnung. Allerdings sollte es dabei nicht bleiben. Der groben Planung muss die Bitte an den Dienstleister folgen, die Aufgaben in seinem Bereich detaillierter zu beschreiben. Diese vom Dienstleister zurückgemeldete Aufgabenliste wird in den bisherigen Plan aufgenommen. Meist ergeben sich daraus Punkte, die geklärt werden müssen. Das Ergebnis dieser Klärung führt zu einer Anpassung des Projektplans zu einem Zeitpunkt, zu dem noch nicht alle Ressourceneinsätze fixiert sind. Der Projektplan dokumentiert gleichzeitig die getroffenen Vereinbarungen. Ab diesem Zeitpunkt sollten Projektteam und Dienstleister diese Version des Projektplans als Grundlage für ihre Arbeit verwenden. Dasselbe gilt in der Zusammenarbeit mit Autoren. Durch die Nachfrage nach einem Zeitplan werden diese ein Stück weit gezwungen, über ihr Vorgehen nachzudenken. Allein das führt bereits dazu, dass Engpässe früher erkannt werden. Ein früh erkannter Engpass kann leichter ausgeräumt werden, als einer, der schon akut besteht.
Qualitätssicherung und Dokumentation einplanen Ein wichtiges Kriterium für eine belastbare Aufgabenliste ist, wie oben beschrieben, deren Vollständigkeit. Es müssen alle Aufgaben enthalten sein, die irgendwer irgendwann im Projekt durchführen muss, um das jeweilig notwendige Arbeitsergebnis eines Strukturplanelements herzustellen. Im Rahmen dieser Erfassung sämtlicher Arbeitsschritte lohnt es sich, sämtliche Tätigkeiten, die zur Qualitätssicherung und Dokumentation der Ergebnisse notwendig sind, ebenfalls beim jeweiligen Element des Projektstrukturplans zu erfassen. So sollten etwa Tätigkeiten wie „Testszenarien definieren“, „Tests durchführen“ und „Testergebnisse in Zwischenbericht dokumentieren“, wo nötig und sinnvoll, ebenfalls aufgeführt werden.
Um die Qualität der Ergebnisse von Beginn an sicherzustellen, sollten alle zur Qualitätssicherung notwendigen Tätigkeiten ebenfalls im Projektplan erfasst werden.
76 Verlagsprojekte planen Werden die Arbeitsschritte auf diesem Wege mit dargestellt, können sie später im Rahmen der Zeitplanung leichter zugeordnet werden. Dasselbe gilt für die Ressourcenplanung. Qualitätssicherung und Dokumentation erfordern somit keinen separaten Prozess, der koordiniert und abgestimmt werden muss.
Der Zeitplan Ein Zeitplan ist kein Terminplan Zeitplan, Terminplan
Zwischen Zeitplan und Terminplan gibt es einen Unterschied, der in der Praxis sehr häufig nicht beachtet wird: erst wenn der Start der Umsetzung definiert ist und Ressourcen abgeglichen sind, wird aus einem Zeitplan ein Terminplan. Der Zeitplan beschreibt bis zu diesem Punkt lediglich die Abfolge von Tätigkeiten und deren Dauer. Er ist auf logischen Überlegungen aufgebaut, nicht auf Terminen. Wobei klar ist, dass mit einem Projekt Vorgaben bezüglich der Termine eingehalten werden müssen. Diese Terminvorgaben gehen jedoch nicht als Termine in die Planung ein. Vielmehr werden der Planung diese Stichtage gegenübergestellt, so dass man erkennen kann, ob bei einer bestimmten Vorgehensweise Terminvorgaben eingehalten werden können.
Erst ist die Reihenfolge der Tätigkeiten relevant Grundlage für die Erstellung des Zeitplans ist die Aufgabenliste und somit der Projektstrukturplan. Im ersten Schritt werden alle Aktivitäten in eine logisch sinnvolle Reihenfolge gebracht. Dieser Schritt ist, über das gesamte Projekt betrachtet, nicht trivial. Immerhin gilt es nicht selten mehrere hundert Tätigkeiten schlüssig aneinander zu reihen. Frage Nr. 10: In welcher Reihenfolge sollen die Tätigkeiten erledigt werden?
Erst die Reihenfolge der Tätigkeiten innerhalb eines Arbeitspakets definieren, dann Schnittstellen in andere Bereiche eintragen.
Manche Tätigkeiten können erst erledigt werden, sobald andere Tätigkeiten abgeschlossen sind. Bei anderen wiederum gibt es mehrere Möglichkeiten einer Aneinanderreihung. Entsprechend ist die Festlegung der Reihenfolge auf der einen Seite ein auf Logik basiertes Entwickeln der Abfolge, auf der anderen Seite ein Verhandeln um die „richtige“ Sequenz. Am Ende jedoch muss die Reihenfolge aller Aktivitäten eindeutig festgelegt sein, um in Verbindung mit der geschätzten Dauer eines Vorgangs einen Zeitplan erstellen und die zeitlich kritischen Tätigkeiten identifizieren zu können. Erst werden die Tätigkeiten innerhalb eines Aufgabenpakets in Reihenfolge gebracht. Anschließend werden Schnittstellen zu anderen Elementen des PSP geprüft und eingetragen. „Gedacht“ wird dabei idealerweise nicht besonders viel: es handelt sich um Fleißarbeit, weniger um kreative Leistung. Wer sich zu viele Gedanken über Abhängigkeiten von und zu anderen Elementen des PSP macht, stolpert meist darüber. Die Fokussierung auf ein Aufgabenpaket und das Vertrauen auf die Methodik helfen, die Fülle der Tätigkeiten und Abhängigkeiten in den Griff zu bekommen. Wobei Anwender häufig das Denken in Vorgängern als hilfreich beschreiben: bei jeder Aktivität wird ausschließlich überlegt, welche Vorgänger-Aktivitäten erledigt sein müssen, um Arbeit an der fokussierten Tätigkeiten starten zu können. Die Nummer der Vorgänger-Aktivität wird erfasst.
Um diesen Schritt zu bewältigen, ist der zur Frage Nr. 10 beschriebene methodischer Kniff hilfreich: zuerst werden lediglich die Tätigkeiten innerhalb eines Arbeitspakets in Reihenfolge gebracht. Dies gelingt meist leicht, da es sich nur um wenige Tätigkeiten handelt.
Zeitschätzung: Dauer eines Vorgangs 77
Abbildung 21: Tätigkeiten innerhalb eines Arbeitspakets in Reihenfolge bringen
Erst nachdem diese in Reihenfolge gebracht wurden, werden systematisch Abhängigkeiten von anderen Elementen des PSP geprüft und erfasst. Dazu wird erst auf oberster Ebene erwogen, zu welchem anderen Bereich des PSP Abhängigkeit bestehen könnten. Wo dies theoretisch möglich ist, wird eine Ebene tiefer betrachtet und wieder geprüft, wo zu den einzelnen Elementen auf zweiter Ebene Abhängigkeiten bestehen könnten. Für die Elemente, für die dies gilt, wird die nächste Ebene geprüft usw. So werden nach und nach alle Abhängigkeiten identifiziert. Die Arbeit ist erledigt, sobald jede Tätigkeit in diese Sequenz eingereiht wurde.
Zeitschätzung: Dauer eines Vorgangs Die Erstellung eines Zeitplans ist ein iterativer Prozess. Schritt für Schritt nähert man sich einer realistischen Planung, die dann auch Ressourcenverfügbarkeit und Kapazitätsgrenzen betrachtet. In der jetzigen Stufe werden diese Betrachtungen außen vor gelassen. Der Zeitplan wird erstellt, als stünden alle Ressourcen der Welt zum jeweils gewünschten Zeitpunkt in beliebiger Menge zur Verfügung. Dadurch wird eine Art Ideallinie identifiziert, die später so gut wie möglich eingehalten werden soll, falls der Zeitpunkt der Lieferung des Projektergebnisses von Bedeutung ist. Im Moment sind alle Aktivitäten des Projekts bekannt und für diese ist eine schlüssige Bearbeitungsfolge definiert. Um daraus einen ersten Entwurf eines Zeitplans zu machen, muss lediglich für jede Tätigkeit die Dauer geschätzt werden. Frage Nr. 11: Welche Dauer schätzen wir bis zur Erledigung der Tätigkeit? Aus Reihenfolge und Dauer ergibt sich der erste Entwurf eines Zeitplans. Wobei die Dauer so geschätzt wird, als stünde die Ressource für die Bearbeitung der Tätigkeit auf jeden Fall im benötigten Umfang zur Verfügung. Die Zeit zwischen Aufnahme der Arbeit an der Tätigkeit und dem Vorliegen des Ergebnisses wird als Dauer bezeichnet. Die Dauer hängt mit dem zur Erledigung nötigen Arbeitsaufwand zusammen, muss jedoch nicht identisch sein. So kann die Dauer einer Arbeit einen Tag betragen, der Arbeitsaufwand jedoch 32 Stunden, was voraussetzt, dass mindestens vier Personen zu je acht Stunden an der Tätigkeit arbeiten. Etwa wenn Personen gleichzeitig Tests am Webportal durchführen. In anderen Fällen kann die Dauer fünf Tage betragen, der Arbeitsaufwand jedoch nur zwei Stunden. Dies könnte beispielsweise bei einer Tätigkeit „Angebote einholen“ der Fall sein.
Fällt es schwer, die Dauer zu schätzen, ist dies meist ein Hinweis darauf, dass der Grad der Detaillierung noch zu grob ist. In vielen Fällen hilft es dann, wenn die formulierte Tätigkeit in kleinere Teiltätigkeiten heruntergebrochen wird und diese in Reihenfolge gebracht werden. Dann wird die jeweilige Dauer der einzelnen Teiltätigkeiten geschätzt.
Dauer, Arbeitsaufwand
78 Verlagsprojekte planen
Abbildung 22: Um einen ersten Zeitplan zu erstellen, wird die Dauer jeder einzelnen Tätigkeit geschätzt.
Zeitplandarstellung als Netzplan oder Gantt-Diagramm Zwei unterschiedliche Arten der Zeitplandarstellung sind üblich. Die Abbildungen 21 und 22 zeigen Netzpläne, die vor allem die Abfolge von Tätigkeiten deutlich machen. Diese Darstellung lohnt sich vor allem bei sehr großen Projekten oder zur Erschließung der Reihenfolge von einzelnen Teilelementen des Projektstrukturplans. Wobei in letzterem Fall der Netzplan meist in Form von Handskizzen verwendet wird. Für die meisten Projekte in Verlagen passender dürfte das Gantt-Diagramm sein, das auch als Balkendiagramm bezeichnet wird. Vor allem das schnelle Erkennen zeitlicher Abläufe wird von Anwendern als Nutzen hervorgehoben. Es enthält grundsätzlich dieselben Informationen wie der Netzplan, bereitet diese lediglich grafisch anders auf. Das Gantt-Diagramm wird auf Basis des Projektstrukturplans erstellt, der als strukturierte Liste aufbereitet ist. Daneben sind Spalten für Dauer und Vorgänger üblich. In der Spalte für Vorgänger werden die Referenznummern der Tätigkeiten aufgeführt, die vorher erledigt sein müssen, bevor die Tätigkeit begonnen werden kann. In Abbildung 23 muss die Tätigkeit in der Zeile Nr. 83 „Potenzielle Autoren recherchieren“ erledigt sein, bevor „Vorauswahl treffen“ begonnen werden kann. Die Zeilennummer ist in diesem Fall die eindeutige Referenznummer für die Tätigkeit und somit bei „Vorauswahl treffen“ in der Spalte „Vorgänger“ als eben solcher aufgeführt.
Abbildung 23: Darstellung des Zeitplans als Gantt-Diagramm. Enthält dieselben Informationen wie Abbildung 22
Aufgaben außerhalb des Verlags Für den Projektplan ist es im ersten Schritt unerheblich, wer die jeweiligen Aufgaben durchführen wird. Alle Tätigkeiten, die zur Zielerreichung erledigt werden müssen, haben Auswirkung auf den Ablauf und damit auf die Dauer des Projekts. Deshalb sollten sich auch alle zu erledigenden Tätigkeiten im Zeitplan wiederfinden.
Zeitschätzung unter Unsicherheit 79
Aufgaben, die extern erledigt werden, werden gerne mit dem Liefertermin in den Zeitplan übernommen. Eine Methode, die auf keinen Fall zu empfehlen ist. Sehr häufig kommt kurz vor Liefertermin der Anruf, dass es noch etwas länger dauern wird.
Abbildung 24: Leistungen, die extern erledigt werden, können als Sammelvorgang in den Zeitplan aufgenommen werden. Für diesen Sammelvorgang erstellt der externe Partner einen detaillierten Zeitplan.
Diese Unsicherheit kann reduziert werden, indem der jeweilige Dienstleister oder Lieferant für die Zeit bis zur Lieferung einen detaillierten Ablauf- und Zeitplan erstellt. Damit wird nachvollziehbar, was bis wann erledigt sein müsste, dass der Liefertermin gehalten werden kann. Außerdem ist ersichtlich, wann welche Bereitstellung von intern oder anderen Beteiligten an den externen Partner erfolgen muss. Der vom externen Mitstreiter gelieferte Projektplan wird in den eigenen Plan integriert. Idealerweise wurde der Projektplan nach Vorgaben der Projektleitung erstellt, da sonst der Aufwand für die Integration zu hoch wird und auf die Integration verzichtet wird. Dies wiederum bedeutet Mehraufwand bei der Projektsteuerung, da mehrere Pläne überwacht und in Einklang gebracht werden müssen.
Zeitschätzung unter Unsicherheit Sämtliche Dauern, die in einen Zeitplan aufgenommen werden, sind Schätzungen. Es ist unsicher, ob diese Schätzungen eintreffen werden. Je geringer die Unsicherheit, desto höher die Verlässlichkeit eines Plans. Oder umgekehrt betrachtet: je höher die Sicherheit einer Schätzung, desto verlässlicher ist ein Plan. Höhere Sicherheit bedeutet in diesem Fall eine höhere Wahrscheinlichkeit, eine Tätigkeit innerhalb der veranschlagten Dauer erledigen zu können. Liegen für bestimmte Aufgaben Erfahrungswerte vor, werden diese als Grundlage der Zeitschätzung verwendet. Dabei wird beim ersten Entwurf davon ausgegangen, dass Personalressourcen mit beliebiger Kapazität zur Verfügung stehen. Erst später werden dieser Ideallinie die tatsächlich verfügbaren Ressourcen gegenübergestellt. Diejenigen, die später vermutlich die Tätigkeit erledigen werden, werden bei der Zeitschätzung einbezogen. Dabei sollte versucht werden, die tatsächliche Dauer ohne
Die Kritische Kette: Das neue Konzept im Projektmanagement, Eliyahu M. Goldratt
80 Verlagsprojekte planen eventuelle Reserven in den Zeitplan zu übernehmen. Würden die Reserven eingeplant, würde das Projekt künstlich verzögert. Sind für bestimmte Tätigkeiten keine Erfahrungswerte verfügbar, kann es helfen, diese Tätigkeiten weiter in kleinere Arbeitsschritte zu unterteilen, die dann leichter zu schätzen sind. Je kleinteiliger ein Arbeitspaket zerlegt wird, desto leichter fällt es üblicherweise, die dafür benötigte Dauer zu bestimmen. Diesen Effekt kann man in Gruppendiskussionen beobachten. Gilt es eine Dauer zu schätzen, die sich schwer bestimmen lässt, dreht sich die Diskussion meist so lange im Kreis, bis ein Teilnehmer die weiter detaillierten Tätigkeiten auflistet. Ab diesem Moment ist die Diskussion meist beendet. Zuletzt bleiben dann noch einzelne Tätigkeiten übrig, deren Dauer immer noch schwer zu bestimmen ist. Für diese Tätigkeiten lohnt sich dann eine Betrachtung der Wahrscheinlichkeiten. Nehmen wir an, im Beispielprojekt gilt es eine bestimmte Funktion in einer neuen Programmiersprache zu programmieren. Kein Teilnehmer der Schätzklausur hat Erfahrung damit, wie lange diese Tätigkeit dauert. Also werden verschiedene Szenarien betrachtet: • Der beste Fall: Im besten Fall kann diese Funktion aus dem Quellcode-Pool eines Programmierers entnommen und mit wenigen Anpassungen übernommen werden. Dann ist die Tätigkeit in x Tagen erledigt. „x“ steht dabei für die optimistische Dauer. • Der schlechteste Fall: Im schlechtesten Fall muss alle neu programmiert werden und es scheitern mehrere Versuche, bis das Stück Software vorliegt. In diesem Fall ist die Tätigkeit in y Tagen erledigt. „y“ steht für die pessimistische Dauer.
Beide Fälle haben eine relative Wahrscheinlichkeit des Eintretens, die nahe Null liegt. Dass etwas wie von Zauberhand gelingt, ist ebenso unwahrscheinlich, wie die Annahme, dass wirklich alles erdenkliche schief laufen wird. Zwischen diesen Werten liegt mit „z“ ein Wert, der gewisse Reibung unterstellt, jedoch von einem „normalen“ Verlauf ausgeht. Dieser Wert wird oft als realistische Schätzung bezeichnet. Er hat eine relative Wahrscheinlichkeit größer Null. Aus der Verbindung dieser Punkte ergibt sich eine Kurve, die der Gaußschen-Normalverteilung sehr nahe kommt.
Abbildung 25: Betrachtet man die relative Wahrscheinlichkeit verschiedener Erledigungsdauern einer Tätigkeit, entsteht eine Kurve, die der Gaußschen-Normalverteilung nahe kommt.
Zeitschätzung unter Unsicherheit 81
Für die Verlässlichkeit des Zeitplans relevant ist die absolute Wahrscheinlichkeit, innerhalb deren eine Tätigkeit erledigt werden kann. Diese wird durch die Fläche unter der Kurve widergespiegelt. Demnach hat die Dauer x eine absolute Wahrscheinlichkeit von null Prozent. Dieser Wert wird in der Praxis häufig als Liefertermin verwendet und ist eine Erklärung, warum Projekte oft länger dauern als angenommen. Er ist für die Verwendung im Zeitplan völlig ungeeignet. Die Dauer y hat eine absolute Wahrscheinlichkeit von Nahe 100 Prozent. Dieser Wert deckt alle (theoretischen) Unwägbarkeiten ab und ist deshalb für die Verwendung im Projektplan ebenfalls ungeeignet. Er würde das Projekt künstlich in die Länge ziehen. In den Projektplan übernommen wird deshalb die Dauer bis zur Fertigstellung, die eine angemessen hohe absolute Wahrscheinlichkeit hat. Wir arbeiten an dieser Stelle seit vielen Jahren mit dem 75-Prozent-Wert (p) und haben gute Erfahrungen damit gemacht.15
Ist die Unsicherheit über die benötigte Erledigungsdauer groß, ist der Wert mit 75 Prozent absoluter Wahrscheinlichkeit ein guter Startwert.
Abbildung 26: In den Projektplan wird der Wert übernommen, der eine angemessen hohe Wahrscheinlichkeit hat, dass er ausreicht. Im Beispiel der 75-Prozent-Wert.
Dieser modellhafte Ansatz ist immer dann hilfreich, wenn die Unsicherheit in den Schätzwerten zu groß ist. Genau genommen stellt er eine Abkürzung dar, da er die hinter der Unsicherheit verborgenen Risiken nicht einzeln betrachtet und bewertet. Für viele Projekte ist dieses Vorgehen jedoch vollkommen ausreichend. Eine Besonderheit sei allerdings angemerkt: liegt eine so geschätzt Tätigkeit auf dem kritischen Pfad (der nachfolgend in Kapitel „Pünktlich liefern dank des kritischen Pfads“ auf Seite 82 beschrieben ist), sollte diese Tätigkeit genauer betrachtet werden. Dann kann eine detaillierte Risikoanalyse der jeweiligen Tätigkeit bessere und belastbarere Ergebnisse liefern.
15 Diese Vorgehensweise geht u.a. auf den Ansatz von Tom DeMarco und Timothy Lister zurück, beschrieben in: Bärentango – Mit Risikomanagement Projekte zum Erfolg führen, Tom DeMarco/ Timothy Lister, Hanser, 2003
82 Verlagsprojekte planen Nehmen wir an, dass im Beispielprojekt die Erstellung der Software-Funktion im besten Fall (x) einen Tag dauern wird. Im schlechtesten Fall (y) könnten dafür zwölf Tage benötigt werden. Daraus ergibt sich p = x + (y–x) x 0,75 = 9,25 Tage. Entsprechend wird im Zeitplan mit einem Wert von 9,25 Tagen gearbeitet. Sollte die Tätigkeit auf dem kritischen Pfad liegen, wird sie genauer analysiert und gegebenenfalls durch geeignete Maßnahmen eine kürzere Laufzeit erwirkt.
Aufgabenliste und Zeitschätzung der Autoren In Verlagsprojekten wird sehr häufig davon ausgegangen, dass - sofern am Projekt beteiligt - Autoren eher später liefern, als ursprünglich angenommen. Das wiederum bringt so manches Vorhaben ins Straucheln, da damit die Vorstellung etwa auf der Buchmesse gefährdet ist. Interessanterweise bleiben Autoren trotzdem bei der Zeitplanung außen vor. Es wird ein Liefertermin für das Skript vereinbart. Dieser Termin wird jedoch nicht mehr hinterfragt. Sobald eine erste Skriptprobe eingeht, wird diese inhaltlich bewertet. Über das weitere Vorgehen wir eher selten gesprochen. Will ein Projektleiter frühzeitig sichergehen, dass der Autor pünktlich liefern wird, muss er die Tätigkeiten des Autors sichtbar machen. Was für Dienstleister und Lieferanten gilt, kann in diesem Fall ebenfalls gelten. Für die Arbeit des Autors wird ein Zeitplan erstellt, der in weiteren Schritten die dazu notwendige Verfügbarkeit des Autors gegenüberstellt. In den Gesprächen, in denen dies geschieht, dürften so einige Autoren überrascht sein, wie viele Nachtschichten bereits von Beginn an eingeplant sind, um den Termin zu halten. Allein das führt zu einer verlässlicheren Terminaussage. Alternativ gibt es in diesem Fall auch die Möglichkeit den Fortschritt in Seiten zu zählen. Da im Voraus meist vereinbart wird, welchen Seitenumfang ein Manuskript haben soll oder wie viele Seiten einer Website mit Inhalt zu füllen sind, kann dies eine Grundlage für die Fortschrittsmessung sein. Basis ist eine Schätzung, wie viele Seiten ein Autor pro Tag erstellen kann. Daraus ergibt sich der Kapazitätsbedarf, der sich im Kalender des Autors darstellen lassen sollte.
Pünktlich liefern dank des kritischen Pfads
Der kritische Pfad ist ein nützliches Instrument, um das vereinbarte Ergebnis pünktlich zu liefern.
In jedem Zeitplan gibt es eine Sequenz von Tätigkeiten, die die Projektlaufzeit bestimmt. Sie wird als „kritischer Pfad“ bezeichnet und ist ein wichtiges Instrument der Projektsteuerung. Wer den kritischen Pfad im Griff hat, wird mit hoher Wahrscheinlichkeit pünktlich liefern. Wer den kritischen Pfad nicht einmal kennt, der muss auf sein Glück und die Energie des Teams vertrauen, um das Projekt in der vorgegebenen Zeit abschließen zu können.
Abbildung 27: Schraffiert dargestellt der kritische Pfad für ein Arbeitspaket. Er bestimmt die Gesamtlaufzeit der Aufgabenbearbeitung.
Aufgrund der logischen Aneinanderreihung der Tätigkeiten und der Schätzung der Dauer entstehen an manchen Stellen Puffer zwischen Tätigkeiten. Das ist immer dann
Pünktlich liefern dank des kritischen Pfads 83
der Fall, sobald von parallelen Vorgängen mit derselben nachfolgenden Tätigkeit einer länger als die anderen dauert. Die längste der parallelen Tätigkeiten bestimmt demnach, wann die nachfolgende Tätigkeit beginnen kann. Bei dieser Aktivität darf eine Verzögerung nicht in Kauf genommen werden. Eine solche Reihenfolge gibt es für das gesamte Projekt. Diese wird als kritischer Pfad oder auch kritischer Weg bezeichnet. Innerhalb dieser Reihenfolge von Aufgaben gibt es keinen Puffer. Die Tätigkeiten folgen lückenlos aufeinander und bestimmen so den Abschlusszeitpunkt des Projekts. Umgekehrt kann ein Projektteam entspannt reagieren, wenn eine der Tätigkeiten mit kürzerer Dauer etwas länger dauert. Sofern der Puffer davon nicht aufgezehrt wird. Der Puffer bezeichnet die arbeitsfreie Zeit, die zwischen Abschluss einer Tätigkeit und Beginn der nachfolgenden Tätigkeit liegt.
Kritischer Pfad, kritischer Weg
Abbildung 28: Puffer ist arbeitsfreie Zeit zwischen einer Tätigkeit und ihrem Nachfolger.
Spätestens mit dem kritischen Pfad wird der Nutzen der Methodik deutlich. Er liefert bei knappen Ressourcen, was in den meisten Verlagen der Normalzustand sein dürfte, einen wichtigen Hinweis darauf, welche Aufgaben als erste mit Ressourcen versehen werden. Außerdem ist er für die Projektleitung wichtig, die nicht immer allen Aufgaben hinterhertelefonieren kann. Der kritische Pfad wird eng abgesichert, die nicht kritischen Aufgaben sind kein Grund, den Feierabend hinauszuzögern. Nun ist doch einige Vorarbeit nötig, um den kritischen Pfad zu identifizieren. Da ist die Frage berechtigt, ob man sich diese Arbeit sparen kann. Dazu können Sie selbst ein kleines Experiment durchführen: Bitten Sie Ihr Projektteam vor Beginn der Planung, die im anstehenden Projekt kritischen Aufgaben aufzuschreiben und die Aufschriebe gesammelt und verschlossen zu deponieren. Erstellen Sie dann einen Projektplan und vergleichen Sie die Ergebnisse der Planung mit den Aufschrieben. Erstens werden Sie feststellen, dass jedes Teammitglied andere Tätigkeiten auf der Liste kritischer Tätigkeiten hatte. Zweitens werden Sie feststellen, dass der Deckungsgrad zwischen Aufschrieb und Projektplan nicht besonders hoch ist. Allerdings gilt es zum aktuellen Planstand noch zu beachten, dass bisher noch keine Gegenprüfung mit den Ressourcen stattgefunden hat. Der Planungsstand hat im Moment Entwurfscharakter. In den folgenden Schritten gilt es diesen Entwurf, der auch als Ideallinie bezeichnet werden kann, möglichst zu halten. Dazu wird versucht, mindestens den kritischen Pfad wie im Plan eingetragen, mit Ressourcen zu besetzen. Bei den nicht kritischen Tätigkeiten hat die Projektleitung Handlungsspielraum, indem der Puffer geschickt ausgenutzt wird. Eine nicht-kritische Tätigkeit kann irgendwann zwischen ihrem frühesten Anfangszeitpunkt und dem spätesten Endzeitpunkt erledigt werden. Der früheste Anfangszeitpunkt ist der Zeitpunkt, zu dem alle notwendigen Vorgängertätigkeiten erledigt sind. Der späteste Endzeitpunkt ist der Zeitpunkt, zu dem die Tätigkeit spätestens erledigt sein muss, um nicht zu einer Verzögerung einer nachfolgenden Tätigkeit zu führen. Bei mehreren aufeinanderfolgenden nicht-kritischen Tätigkeiten hat die gesamte Sequenz einen frühesten Anfangs- und einen spätesten Endzeitpunkt,
Mit dem kritischen Pfad wird eine sinnvolle Zuordnung der (knappen) Ressourcen erst möglich.
Wer für Akzeptanz der Projektplanung sorgen will, kann dafür ein kleines Experiment rund um den kritischen Pfad nutzen.
Frühester Anfangszeitpunkt, spätester Endzeitpunkt
84 Verlagsprojekte planen innerhalb derer die anstehenden Tätigkeiten erledigt werden können. Diese Tatsache wird bei der Ressourcenplanung genutzt, sollte die benötigten Ressourcen nicht zum Wunschtermin zur Verfügung stehen.
Ausflug: Projektmanagement-Software Projektmanagement-Software macht Projektsteuerung effizienter
Wer die Bedienung einer Projektmanagement-Software erlernen will, tut das am besten im Rahmen eines laufenden Projekts und mit einem Coach.
Gutes Projektmanagement hat zunächst nichts mit einer Software zu tun. Projektmanagement ist eine Methode, eine Art zu Denken und eine bestimmte Haltung, die Dinge voranzutreiben. Eine Projektmanagement-Software hilft denjenigen, die methodisch fit sind, die Projektsteuerung mit weniger Aufwand zu betreiben. Die Software erleichtert die Datenverwaltung, das Zeichnen von Plänen, die Berechnung von kritischen Pfaden etc. Ohne Methodenkenntnis hilft die beste Projektmanagement-Software nur wenig. Allerdings ist nicht jede Software, die als Projektmanagement-Software angepriesen wird, in der Lage, diese methodischen Anforderungen umzusetzen. Manches als Projektmanagement-Tool verkaufte Produkt sollte besser als Aufgabenverwaltung bezeichnet werden, oder als Kommunikationswerkzeug. Diese Werkzeuge haben durchaus ihre Berechtigung, da sie die Bearbeitung von Aufgaben im Team erleichtern. Sie liefern jedoch nicht alle Funktionen, die in Verlagsprojekten sinnvollerweise eingesetzt werden sollten. Wer sich für eine Projektmanagement-Software entschieden hat, darf mit vielen unbekannten Funktionen rechnen. Trotzdem ist aus meiner Sicht eine Software-Schulung nur der zweitbeste Weg, deren Einsatz zu erlernen. Darin werden meist nur die Funktionen der Software gelehrt, nicht die Erstellung eines Projektplans mit all den damit einhergehenden Fragen. Weit praxisnäher ist der Einstieg, wenn ein Projektleiter ein tatsächlich anstehendes Projekt mit einer neuen Software plant und sich hierbei durch einen Coach, der sowohl Methode wie auch Software versteht, unterstützen lässt. Damit sind die erlernten Inhalte näher an der Anwendung, in der Praxis auftretende Fragen können beantwortet werden und gleichzeitig profitiert das laufende Projekt davon. Außerdem ist der zeitliche Aufwand für den Projektleiter meist geringer, wenn er sich die Software auf diesem Wege erschließt.
Anforderungen an eine gute Projektmanagement-Software
Anforderungen an eine Projekt management-Software
Eine Projektmanagement-Software ist ein Hilfsmittel, das zum einen die Arbeit der Projektleitung erleichtern soll. Das gilt für die Planungsphase ebenso wie für die Projektsteuerung. Zum anderen soll die Software die Zusammenarbeit des Teams unterstützen und im Idealfall Auftraggeber und Lenkungsgremien auf dem Laufenden halten. Daraus lassen sich wesentliche Anforderungen ableiten: • Das Anlegen und Verwalten des Projektstrukturplans sollte mit wenig Aufwand möglich sein. Außerdem sollte sich der Projektstrukturplan für die verschiedenen Zielgruppen in einem unterschiedlichen Detaillierungsgrad darstellen lassen. Ideal ist es, wenn eine Darstellung der Projektstruktur sowohl grafisch, etwa als Mind-Map oder ähnlich einem Organigramm, wie auch in Listenform möglich ist. • Eine Projektplanung muss auf Basis logischer Überlegungen möglich sein. Mindestens die Angabe von Abhängigkeiten zwischen Aufgaben und die Angabe der Dauer für jede einzelne Tätigkeit sollten möglich sein, woraus die Software in Verbindung mit dem Termin des Umsetzungsbeginns den Projektzeitplan errechnet. Dieser Plan sollte mindestens als Balkendiagramm grafisch aufbereitet werden.
Anforderungen an eine gute Projektmanagement-Software 85
•
•
•
•
• •
•
•
•
Dem Zeitplan sollte grundsätzlich ein Kalender hinterlegt sein, der definierte Tage, etwa die Wochenenden, automatisch als arbeitsfrei behandelt. Ist dies nicht der Fall, leidet die Akzeptanz der Software erfahrungsgemäß sehr. Die Berechnung des kritischen Pfads sollte automatisch geschehen. Dazu sollte es möglich sein, eine Übersicht aller kritischen Tätigkeiten zu generieren und den kritischen Pfad in der grafischen Ansicht optisch hervorzuheben. Den Aktivitäten müssen Ressourcen zugeordnet werden können, wobei eine automatische Auswertung der Ressourcenbelastung eine zusätzliche Arbeitserleichterung bringt. Hierfür ist es nötig, dass die Software einen Unterschied zwischen der Dauer einer Tätigkeit und dem zu erbringenden Arbeitsaufwand macht. Es muss möglich sein, den Plandaten von Zeit und Kosten die Echtwerte gegenüberzustellen und daraus eine Prognose über den voraussichtlichen Projektverlauf in Zukunft berechnen zu lassen. Da in Verlagen häufig mit externen Partnern gearbeitet wird, sind standardisierte Export- und Importfunktionen wichtig. Management-Berichte sollten mit wenig Aufwand erstellt werden können. Neben der direkten Erstellung von Berichten in der Software sind Exportfunktionen grafischer Teile etwa in einer Präsentationssoftware nützlich. Die Software sollte die Möglichkeit bieten, Dokumente mit Aufgaben zu Verknüpfen und Notizen zu Aktivitäten zu speichern, da somit der Aufwand für die Projektdokumentation erheblich sinkt. Für das Projektteam ist ein Zugriff auf die Projektpläne und eine persönliche Sicht darauf wichtig, wobei aus Perspektive der Projektleitung die Möglichkeit bestehen sollte, die Rechte dafür individuell festlegen zu können. Die Möglichkeit, dass die Teammitglieder selbst Aufgaben als erledigt markieren können, ist nützlich, jedoch nicht zwingend nötig. Dasselbe gilt für die Möglichkeit, dass die Projektleitung Erinnerungen an Abgabeterminen versenden kann. Eine vernünftige Druckfunktion, auch für große Pläne und auf handelsüblichen Druckern, ist wichtig.
Dass eine Software, die intuitiv zu bedienen ist, Vorteile in der Akzeptanz hat, dürfte selbstverständlich sein. Und Akzeptanz ist eine wesentliche Voraussetzung dafür, dass eine Software tatsächlich eingesetzt wird. Die Software ist wiederum in vielen Fällen ein wichtiger Schritt, um die Anwendung der Methode voranzubringen. Ohne eine entsprechende Software haben Projektleiter oft nicht die Kapazität, Projektplanung und -steuerung in einem sinnvollen Detaillierungsgrad betreiben zu können. Ebenso offensichtlich sollte sein, dass eine Software mit einem guten Support einem Anbieter ohne Unterstützung vorgezogen werden sollte, da es sich durchaus um komplexere Softwarewerkzeuge handelt. In vielen Fällen werden die oben beschriebenen Anforderungen nicht durch eine einzelne Software erfüllt. Dann sollte den Schnittstellen zwischen den unterschiedlichen Programmen besondere Beachtung geschenkt werden. Diese sollten einen Austausch in beide Richtungen möglich machen. Spätestens wenn eine größere Änderung am Projekt durchgeführt wird, wird das Zurückspielen etwa von der Zeitplansoftware in das Programm, mit dem der Projektstrukturplan erstellt wurde, notwendig. Sonst besteht die Gefahr, dass notwendige Anpassungen allein deshalb unterbleiben, weil die Mühe zu groß wäre, und damit die Reibungsverluste im Projekt aufgrund einer Diskrepanz zwischen vorliegenden Plänen und tatsächlichem Vorgehen steigen. Während die oben aufgeführten Anforderungen sich auf die Durchführung eines einzelnen Projekts fokussieren, sollte aus Unternehmenssicht eine auf Dauer eingeführte Projektmanagement-Software auch in der Lage sein, die Steuerung des gesam-
86 Verlagsprojekte planen
Die automatischen Berechnungen einer Projektmanagement-Software sind mit Vorsicht zu genießen. Es muss nachvollziehbar bleiben, welche Änderungen die Software vorgenommen hat.
ten Projekt-Portfolios zu erleichtern. Wesentlich ist hierfür die Möglichkeit, verschiedene Projektpläne zu einem Gesamtplan integrieren zu können. Außerdem erleichtert ein gemeinsamer Ressourcenpool für ein Projektportfolio die Kapazitätsplanung über Projekte hinweg ungemein. Allerdings sollte an dieser Stelle gewarnt werden, dass die Automatismen, die manches Software-Paket diesbezüglich bietet, mit Vorsicht zu genießen sind. Schon mancher Projektleiter hat etwa nach einem automatischen Kapazitätsabgleich ratlos auf seinen Projektplan geblickt, da die durch die Software vorgenommenen Änderungen nicht mehr nachvollziehbar waren. Damit waren sämtliche Vereinbarungen des Projetteams über die Vorgehensweise nicht mehr gültig. Ohne Absprachen und Gespräche zur Abstimmung funktionieren Projekte nur selten. Im Zweifelsfall sollte immer der persönliche Kontakt der Funktion einer Software vorgezogen werden. Nur wo die softwaregesteuerten Abläufe bereits eingeführt und akzeptiert sind, haben diese eine Chance, ein Projekt wirklich zum Laufen zu bringen.
Redaktionssysteme und Projektmanagement-Werkzeuge gemeinsam verwenden Redaktionssysteme sind keine Projektmanagement-Werkzeuge. Ein Redaktionssystem hat grundsätzlich einen anderen Fokus als eine Projektmanagement-Software. Beim Redaktionssystem stehen die Inhalte und deren Publizierung im Vordergrund. Sie sind eher dafür gemacht, standardisierte Routineprozesse zu etablieren. Der Aufwand Prozesse für ein einzelnes Projekt anzulegen, ist meist zu hoch. Die Projektmanagement-Software fokussiert dagegen auf die Organisation und Koordination des Projektteams im Rahmen eines einmaligen Vorhabens. Sie ist darauf auslegt, mit wenig Aufwand eine einmalige Vorgehensweise zu dokumentieren. Prozesse in Redaktionssystemen dagegen sind tendenziell eher für die dauerhafte Verwendung gedacht. Trotzdem kann ein Redaktionssystem sehr nützliche Dienste innerhalb eines Projektes leisten, nämlich immer dort, wo Inhalte nach einem standardisierten Ablauf bearbeitet werden. Dies wird meistens dann der Fall sein, wenn das zu liefernde Ergebnis der Projekte nahe am üblichen Leistungsportfolio des Verlags liegt, etwa wenn wie im Beispielprojekt neben einem klassischen Buchtitel zusätzlich ein Webportal mit Inhalten gefüllt werden soll.
Abbildung 29: Beispielhafter Zeitplan für die Erstellung eines Texts im Projektplan, wenn kein Standardablauf des Redaktionssystems genutzt wird.
Kann innerhalb eines Projekts auf einen im Redaktionssystem hinterlegten Ablauf zugegriffen werden, wird dies getan. Damit bietet sich zum einen die Chance, Planungsaufwand zu reduzieren, da die notwendigen Arbeitsschritte im Redaktionssystem hinterlegt sind und deshalb nicht in den Projektplan übernommen werden müssen. Im Projektplan findet sich an dieser Stelle ein weniger detailliertes Aufgabenpaket mit
Kostenlose Projektmanagement-Software 87
dem Verweis auf den entsprechenden Prozess im Redaktionssystem. Zum anderen macht dieses Vorgehen die Bearbeitung oft leichter, da die Beteiligten in der gewohnten Systemumgebung arbeiten können.
Abbildung 30: Beispielhafter Ablauf für die Erstellung eines Texts, wenn auf den Standardablauf eines Redaktionssystems zurückgegriffen wird.
Dieser Weg sollte allerdings nur beschritten werden, wenn auch tatsächlich Standards genutzt werden. Die Gefahr besteht darin, dass eine Abweichung der Vorgehensweise im Projekt gegenüber dem im Redaktionssystem hinterlegten Ablauf marginalisiert wird. Dieses Unterschätzen der Abweichung führt dann meist zu langwierigen Diskussionen, wenn nicht gar zu Konflikten. Ist eine Abweichung gegenüber dem Standard vorhanden, ist der Projektplan die geeignetere Stelle, um diese besondere Vorgehensweise zu beschreiben. Wer die Standards des Redaktionssystems nutzt, sollte sich außerdem bewusst sein, dass er damit die Projektsteuerung und Fortschrittsüberwachung in zwei Systemen vornehmen muss. Das ist sicherlich kein Beinbruch, sollte jedoch bei der Entscheidung bedacht werden. Für einzelne Abläufe im Rahmen eines Projekts wird sich das nicht lohnen. Erst wenn immer wieder die Standards genutzt werden können, entsteht eine echte Arbeitserleichterung.
Kostenlose Projektmanagement-Software Der Markt für Projektmanagement-Software ist mehr als unübersichtlich. Subjektiv betrachtet drängen immer mehr Anbieter auf den Markt, die zumindest behaupten, Projektmanagement-Software anzubieten. Selbst kostenlose Software steht inzwischen in einer Qualität zur Verfügung, die zumindest den Einstieg in die Projektplanung stark erleichtert. Ein Beispiel hierfür ist die Software „projectlibre“, deren Vorgänger „openproj“ bereits gute Dienste geleistet hat. Die Software steht sowohl für Mac wie auch Windows-Rechner im Rahmen einer Open-Source-Lizenz frei zur Verfügung.16 Sie unterstützt sämtliche in diesem Buch beschriebenen Planungsschritte ab der Aufgabenliste. Mit ihr lassen sich Gantt-Diagramme und Netzpläne auf Basis des Projektstrukturplans erstellen und der Fortschritt der Bearbeitung im Vergleich zwischen Basisplan und Echtdaten steuern. Als Alternative hierzu wird immer wieder, ebenfalls als Open-Source-Software verfügbar, „]project open[“ genannt. Allerdings kann ich hierfür keine Erfahrungswerte liefern. Das gleiche gilt für „Open Workbench“, ein Projektmanagement-Programm für Windows-Rechner. Ergänzend sind bei der Planung Softwareprogramme hilfreich, die keine Projektmanagement-Software im eigentlichen Sinne darstellen. Bei der Projektstrukturierung kann beispielsweise Mind-Mapping-Software sehr nützliche Dienste leisten. Ei-
16 Common Public Attribution Licence (CPAL) Version 1.0 lt. http://www.projectlibre.org, 10. Dezember 2013
Abläufe im Redaktionssystem sollten dann genutzt werden, wenn auf Standard-Vorgehen zurückgegriffen wird. Und nur dann.
88 Verlagsprojekte planen ner der bekanntesten kostenlos erhältlichen Vertreter dieser Art Software dürfte „Free Mind“ sein, das allerdings nur für Windows-Rechner erhältlich ist.17 Als Alternative auf Windows- und Mac-Rechnern kommt beispielsweise Freeplane in Frage. Diese Software bietet gar einen Export in eine XML-Datei, die sich in verschiedene Projektmanagement-Programme importieren lässt. Sie ist als „freie Software“ unter einer GNU General Public Licence verfügbar18. Auch in diesem Segment nahezu unmöglich, einen Überblick über die Angebote zu haben. Eine Hilfestellung bietet der Verein OpenPM e.V. auf seiner Wissensplattform unter http://openpm.info/display/openPM/Software19. Dort ist ein Überblick über Projektmanagement-Software zu finden, der nicht vollständig ist, jedoch von Praktikern erstellt und gepflegt wird.
Apps für Projektmanagement Inzwischen sind auch für Apples iPad und andere Tablet-Geräte unzählige Apps unter der Überschrift „Projektmanagement“ verfügbar. Grundsätzlich eint alle Angebote ein gemeinsames Problem: der Bildschirm ist zu klein, um vernünftig Projektplanung und -steuerung zu betreiben. Unter iOs habe ich die App „SG Project Pro“ im Einsatz. Mit ihr lassen sich einfache Pläne erstellen und Anpassungen an bestehenden Plänen vornehmen. Einen weiteren Einsatz kann ich guten Gewissens derzeit nicht empfehlen. Als Alternativen tauchen immer wieder „Project Planner HD“, „xPlan“ und „Gantt Pro“ auf, die laut Hersteller ähnliche Funktionalität bieten. Für Android-Geräte steht eine ähnliche Funktionalität mit „Projektplan“, „GanttDroid Pro“ und „GanttMan“ zur Verfügung. Allen ist gemeinsam, dass damit Balkendiagramme erstellt und bearbeitet werden können. Bis auf die erstgenannte, habe ich diese Apps noch nicht getestet. Eher geeignet sind die Tablet-Geräte, um damit den Projektstrukturplan mittels Mind-Maps zu erstellen. Auf iOS-Geräten habe ich gute Erfahrungen mit „iThoughtsHD“ gemacht, unter anderem auch aufgrund der vielfältigen Ex- und Importmöglichkeiten, die eine Übernahme in Projektmanagement-Software erleichtern. Plattformübergreifend erhält „iMindMap HD“ des Mind-Map-Erfinders Tony Buzan immer wieder gute Kritiken.
Projektplanung in der Cloud Wer keine Software auf seinem Rechner installieren möchte, kann inzwischen unzählige Angebote als „Software as a Service (SaaS)“ nutzen. Die Software läuft auf einem Webserver, auf den via Internetbrowser oder in manchen Fällen über Apps zugegriffen wird. Sehr häufig ist eine Testphase kostenlos, danach wird monatlich für eine bestimmte Anzahl Nutzer bezahlt. Die Wartung der Software auf dem eigenen PC kann entfallen. Allerdings bleibt die Frage der Sicherheit der Daten. Viele Anbieter sitzen in den USA oder nutzen zumindest Serverstandorte dort. Im August 2013 haben wir mehrere Dutzend Angebote unter die Lupe genommen und hinsichtlich Funktionalität, Bedienerfreundlichkeit und der Möglichkeit, Daten mit Standardprogrammen auszutauschen, untersucht. Das Thema Sicherheit der Da-
17 lt. http://freemind.softonic.de, 10. Dezember 2013 18 lt. http://sourceforge.net/projects/freeplane/, 10. Dezember 2013 19 Übersicht über Projektmanagement-Software, Stand 10. Dezember 2013
Die Verlagsbereiche sind nicht automatisch verantwortlich 89
ten haben wir außen vor gelassen, da alle untersuchten Anbieter einen vergleichbaren Standard anführen. Als Favorit hat sich „CobaltPM“20 des US-Anbieters Integrated Business Solutions herauskristallisiert. Damit lässt sich eine lokale Installation der Software ersetzen. Ausgehend von einem Projektstrukturplan ist es leicht, einen auf Abhängigkeiten und Zeitschätzungen basierten Projektplan zu erstellen. Auch die Projektsteuerung auf Basis eines Soll-Ist-Vergleichs ist damit gut möglich. Notwendige Exportfunktionen zur lokalen Datensicherung oder Zusammenarbeit mit anderen Systemen sind integriert. Auf Platz zwei landete „Smartsheet“21, das mit zusätzlichen Apps für Tablet-Geräte punktet, jedoch in der Projektsteuerung Schwächen hat. Preislich liegt Smartsheet außerdem niedriger als CobaltPM.22
Lokale Projektmanagement-Software zum Kauf Wer auf herkömmlichem Wege Projektmanagement-Software nutzen will, kommt bei der Recherche kaum an Microsoft Project vorbei. Die aktuellen Versionen des Anbieters aus Redmont bieten weit mehr Funktionalität, als in den meisten Verlagsprojekten benötigt wird. Sämtliche in diesem Buch beschriebenen Planungs- und Steuerungsaufgaben sind damit problemlos zu erledigen. Es ist vielmehr die Funktionsvielfalt, die viele Nutzer abschreckt. Microsoft Project läuft nur auf Windows-Rechnern. Es gibt inzwischen auch eine Cloud-Version. Diese war bei unserem Test im August 2013 jedoch noch unbrauchbar. Für den Mac ist „Merlin“ eine Empfehlung wert. Die Software bietet ebenfalls alle Funktionen, um ein Projekt zu strukturieren, zu planen und die Umsetzung zu steuern. Die Zusammenarbeit mit Microsoft Project funktioniert aus meiner Erfahrung problemlos. Das gleiche gilt für die Zusammenarbeit mit der frei verfügbaren Software „Project libre“.
Ressourcen sicherstellen Die Verlagsbereiche sind nicht automatisch verantwortlich Der Unterschied zwischen Projekt und Routineprozess liegt darin, dass beim Routineprozess die Verantwortung quasi „automatisch“ geregelt ist. Das ist im Projekt nicht der Fall, also muss die Projektleitung die Verantwortung für jede einzelne Tätigkeit sicherstellen. Dabei kann bewusst von den üblichen Gepflogenheiten abgewichen werden. Nur weil der Verlag eine eigene IT-Abteilung hat, muss diese nicht zwangsläufig alle IT-Arbeiten übernehmen, wenn etwa Kapazitätsengpässe dagegen sprechen oder eine neue Technologie entwickelt und ausprobiert werden soll. Frage Nr. 12: Wer hat Verantwortung für welchen Aufgabenbereich? Mit der Zuordnung von Verantwortung zu den verschiedenen Teilbereichen des Projektstrukturplans beginnt die Ressourcenplanung. Dabei geht es meist um eine grundsätzliche Rollenklärung. Wer stellt welchen Bereich des Projekts auch organisatorisch sicher? Wer sorgt dafür, dass die Kommunikation in einem bestimmten Aufgabenbereich funktioniert?
20 siehe http://www.cobaltpm.com 21 siehe http://www.smartsheet.com 22 lt. Websites der Anbieter, 10. Dezember 2013
90 Verlagsprojekte planen Je größer ein Projekt, desto wichtiger ist dieser Schritt. Meist kristallisiert sich hierbei eine Art Kernteam heraus, das die Fäden in der Hand hält. Die Zuordnung von Verantwortung muss sich nicht an den Unternehmensstrukturen orientieren, denn diese sind für Routineprozesse geschaffen. Wo sinnvoll, werden diese übernommen, wo nicht, wird davon abgewichen. Wobei eines gilt: je neuartiger das Ergebnis sein soll, desto besser ist es, nicht auf bestehende Strukturen zu setzen. Die Zuordnung von Verantwortung zu Teilen des Projekts ist die Vorstufe zur Ressourcenplanung, die dann zusätzlich verfügbare Kapazitäten berücksichtigt.
Abbildung 31: Mindestens jedem Element des PSP auf oberster Ebene werden die Personen zugeordnet, die für die einzelnen Bereiche verantwortlich zeichnen.
Mit der Zuordnung der Personen zu Bereichen des Projektstrukturplans geht einher, dass die damit verbundene Verantwortung sowie die gegenseitigen Erwartungen diskutiert werden. Darüber hinaus ist es sinnvoll, erste (organisatorische) Spielregeln der Zusammenarbeit festzulegen, etwa wer den Projektplan pflegt und wie mit Dokumenten verfahren werden soll.
Arbeitsaufwand als Grundlage der Kapazitätsplanung Der Mangel an Ressourcen ist ein Dauerthema in Verlagen. Gerade deshalb kommt der Ressourcenplanung besondere Bedeutung zu. Nur wenn die im Projektplan aufgeführten Zeiten auch mit Ressourcen hinterlegt sind, hat der Plan einen Sinn und Aussagekraft. Grundlage für eine schlüssige Ressourcenplanung ist die Schätzung der Arbeitsaufwände. Sie erfolgt, wie bei der Schätzung der Dauer, Aufgabe für Aufgabe. Frage Nr. 13: Mit welchem Arbeitsaufwand rechnen wir? Der Arbeitsaufwand beschreibt die Zeit, die tatsächlich an einer Tätigkeit gearbeitet wird. Sie kann kürzer oder länger sein als die Dauer und wird für jede Aktivität einzeln geschätzt. Die Schätzung des Arbeitsaufwands hat im ersten Moment keine Auswirkung auf die Dauer. Erst im Moment der Zuordnung von Ressourcen kann eine Anpassung nötig werden, etwa wenn die Ressource nicht ausreichend Kapazität hat.
Mitarbeiter zuordnen und Verfügbarkeit prüfen 91
Abbildung 32: Arbeitsaufwände werden einzeln für jede Tätigkeit geschätzt und hier im Beispiel in der Spalte „Aufwand“ erfasst.
Mitarbeiter zuordnen und Verfügbarkeit prüfen Im nächsten Schritt der Projektplanung werden jeder Tätigkeit Personen zugeordnet. Wobei es im Projektmanagement üblich ist, von Ressourcen zu sprechen. Meist sind damit Personen gemeint, allerdings kann es sich dabei auch um Material oder Maschinen handeln. Im Verlag wird die Zuordnung von Kollegen und freien Mitarbeitern der häufigste Fall sein. Die Zuordnung wird grundsätzlich nach Gesichtspunkten der Qualifikation vorgenommen. Für jede Tätigkeit sind bestimmte Fähigkeiten und Fertigkeiten nötig. Diese sind, neben der grundsätzlichen Verfügbarkeit der Person für das Projekt, maßgeblich für die Zuordnung zu einer Aufgabe. Die Zugehörigkeit zu einer Abteilung oder einem Unternehmensbereich ist es nicht. Abteilungen stellen aus Projektsicht lediglich eine Art Ansammlung potenzieller Mitarbeiter mit ähnlichem Know-how dar. Frage Nr. 14: Welche Aufgabe soll von welchen Mitarbeitern erledigt werden? Auf Basis der Qualifikation werden jeder Aufgabe die Personen zugeordnet, die die Tätigkeit zum Ergebnis bringen sollen. Dann wird geprüft, ob die Kapazität dieser Personen ausreicht, um den Anforderungen des Projektplans gerecht zu werden. Ist dies nicht der Fall, wird erst versucht innerhalb des Projektes Verschiebungen vorzunehmen, um Kapazitätsspitzen auszugleichen. Dabei wird der Puffer genutzt, der bei Tätigkeiten vorhanden ist, die nicht auf dem kritischen Pfad liegen. Bei Tätigkeiten auf dem kritischen Pfad wird alles daran gesetzt, Ressourcen zu beschaffen, um diese Ideallinie halten zu können. Gibt es dabei Kollisionen mit anderen Projekten oder Routinetätigkeiten, wird um Ressourcen verhandelt. Wobei Ziel dieser Verhandlungen ist, die Zusage der Ressourcen zu bekommen, die Aufgabe im geplanten Zeitraum zu erledigen. An den Verhandlungen sind die Projektleiter aller betroffenen Projekte, die benötigten Personen sowie deren Vorgesetzte beteiligt.
Grundvoraussetzung für die Ressourcenplanung ist der Arbeitskalender. Bevor einzelne Personen angesprochen werden, wird der ersten Version des Zeitplans der Arbeitskalender hinterlegt, der arbeitsfreie Tage enthält. Das sind sowohl Wochenende und Feiertage, wie auch Betriebsferien und sonstige Tage, an denen nicht gearbeitet wird. Bei Projekten in internationalem Umfeld werden die entsprechenden länderspezifischen Gegebenheiten berücksichtigt.
92 Verlagsprojekte planen Autoren und Dienstleister ins Boot bekommen: Ressourcenplanung ist ein Verhandlungsprozess Es hat sich als sehr hilfreich erwiesen, die Ressourcenplanung als Verhandlungsund Kommunikationsprozess zu verstehen. Der ursprüngliche Projektplan bis zur Aufwandsschätzung ist neben der Zeitplanung gleichzeitig eine Art Personalbedarfsplanung. Danach ist der Personalbedarf des Projekts sichtbar. Im Verständnis, dass nun ein Verhandlungsprozess beginnt, definiert der Projektleiter je Tätigkeit seine Wunsch-Ressource und damit eine Art Bedarfsmeldung.
Abbildung 33: Nach Zuordnung der Wunsch-Ressourcen ist klar, wann welche Ressource in welchem Umfang benötigt wird.
Im nächsten Schritt wird geprüft, ob diese Bedarfsmeldungen innerhalb des Projekts zu einer Überlastung der Ressource führen. Wo dies der Fall ist, wird versucht durch zeitliche Verschiebungen Kapazitätsspitzen zu entzerren. Gelingt dies nicht, müssen für die Aufgaben, die zur Überlastung führen, andere Ressourcen eingesetzt oder eine Verzögerung des Projekts in Kauf genommen werden, indem bisher zur parallelen Bearbeitung geplante Aufgaben nacheinander abgearbeitet werden.
Abbildung 34: Das Arbeits- oder Ressourcenlastdiagramm zeigt die Auslastung in Prozent eines Arbeitstages über der Zeit. In diesem Fall ist keine Überlastung zu erkennen.
Nach der Prüfung auf Kapazitätsüberschreitungen innerhalb des Projekts wird mit der als Ressource vorgesehenen Person geprüft, ob der Bedarf des Projekts zu Kollisionen mit anderen Projekten führt. Wo dies der Fall ist, wird wieder versucht, den Puffer bei nicht kritischen Tätigkeiten zu nutzen, um Spitzen zu vermeiden. Aus Sicht der Ressource, in diesem Fall des Mitarbeiters, ist es unerheblich, woher eine Tätigkeit stammt. Das Prinzip, das innerhalb eines Projekts gilt, gilt auch über Projektgrenzen hinweg. Beim Mitarbeiter laufen die Projekte in Form von Tätigkeiten zusammen, die innerhalb eines definierten Zeitraums erledigt werden müssen. Wenn wir im Zeitplan in den Abbildung 35 und 36 davon ausgehen, dass der Arbeitsaufwand aller Tätigkeiten die Dauer komplett ausfüllt (Dauer = Arbeitsaufwand), dann führt die dort dargestellte Planung zu einer Überlastung bei Mitarbeiter 1 am
Autoren und Dienstleister ins Boot bekommen: Ressourcenplanung ist ein Verhandlungsprozess 93
ersten Tag im Projekt. Er ist an diesem Tag sowohl für Aufgabe 1 wie auch für Aufgabe 2 vorgesehen. Diese Überlastung wird in einem als Arbeitslast- oder Ressourcenlastdiagramm bezeichneten Schaubild dargestellt.
Abbildung 35: Beispiel für einen Zeitplan als Netzplan dargestellt mit einer Kollision, die zur Überlastung bei Mitarbeiter 1 führt.
Abbildung 36: Beispiel desselben Zeitplans wie in Abbildung 35, hier als Gantt-Diagramm dargestellt
Abbildung 37: Die ursprüngliche Planung führt zu einer Überlastung an Tag 1 (oben), die durch den verzögerten Beginn der nicht kritischen Aufgabe 1 um einen Tag vermieden wird (unten).
In Abbildung 37 ist die Auslastung durch zwei Tätigkeiten vor der Optimierung und nach der Optimierung dargestellt. Ob eine Tätigkeit kritisch ist oder nicht zeigt der bisherige Entwurf des Zeitplans. In diesem Fall ist Aufgabe 2 kritisch und hat keinen Puffer zur nachfolgenden Tätigkeit. Aufgabe 1 liegt nicht auf dem kritischen Pfad und hat einen Puffer zur nachfolgenden Tätigkeit von drei Tagen. Sie kann innerhalb dieser Pufferzeit verschoben werden. Vor der Optimierung beginnen beide Tätigkeiten am ersten Tag und benötigen beide denselben Mitarbeiter. Das führt zu einer Überlastung. Diese wird ausgeglichen, indem der Beginn von Aufgabe 2 um einen Tag hinausgezögert wird. Dadurch reduziert sich der Puffer zur nachfolgenden Tätigkeit um einen Tag von drei Tagen auf zwei Tage.
94 Verlagsprojekte planen
Abbildung 38: Überarbeiteter Zeitplan nach Abbau der Kapazitätsspitze an Tag 1, die zur Überlastung des Mitarbeiters 1 führte.
Wer diejenigen, die die Erledigung einer Tätigkeit zu einem bestimmten Zeitpunkt zugesagt haben, bittet, die mit der Zusage verbundene Aufgabe im Kalender zu vermerken, erhöht die Wahrscheinlichkeit einer pünktlichen Lieferung.
So bleiben zum Schluss nur noch wenige Kollisionen übrig. Für jede dieser übrigen Kollision innerhalb des Projekts wird nun überlegt, ob alternative Lösungen möglich sind. So könnten zusätzliche Ressourcen zum Einsatz kommen, etwa ein freiberuflicher Mitarbeiter. Diese Entscheidung wird wesentlich davon abhängen, welche zeitlichen und finanziellen Puffer das Projekt noch hat. Bleiben auf diesen Achsen keine Spielräume mehr, bleibt nur noch der Ausweg, die Qualität zu reduzieren, indem beispielsweise weniger Funktionen ins Ergebnis implementiert werden und so Aufwand beziehungsweise die benötigte Zeitdauer reduziert werden können. Erst wenn es Kollisionen über Projekte hinweg gibt, die sich über dieses Abgleichsverfahren nicht auflösen lassen, ist es nötig zu wissen, welchen Rang welches Projekt hat, um diese Kollisionen sinnvoll bereinigen zu können. Das Projekt mit dem höheren Rang bekommt in diesem Fall die Ressourcen zum gewünschten Zeitpunkt. Das Projekt mit dem niedrigeren Rang muss die Bearbeitung der Aufgabe und damit die Lieferung des Ergebnisses verzögern.23 Der Rang entscheidet über die Energieversorgung verschiedener Projekte, unter der Annahme, dass nie genug Ressourcen zur Verfügung stehen, um alle Projekte parallel bearbeiten zu können. Die Ergebnisse dieses Verhandlungsprozesses werden sowohl in den Projektplänen festgehalten wie auch im Kalender der Personen, welche die Aufgaben bearbeiten werden. Als Projektleiter sollten Sie diese immer bitten, die gemachten Zusagen im Kalender zu vermerken. Sonst besteht die Gefahr, dass ein anderer Projektleiter die Person für denselben Tag im Projekt einplant und die eingeplante Person die Kollision nicht erkennt, was zu einer Doppelbuchung führt. Diese wird meist erst erkannt, wenn es bereits zu spät ist, eine Korrektur vorzunehmen. Dieser Ablauf funktioniert sowohl mit den Kollegen innerhalb des Verlags wie auch mit externen Dienstleistern und Autoren. Wobei der beschriebene Punkt besonders wichtig ist, dass die Personen, die Zusagen über Bearbeitungszeitpunkte machen, sich diese im eigenen Kalender vermerken. Oft werden dabei Aufwandsschätzungen aufgrund der Erfahrung der Ressourcen nochmals angepasst. Der Projektplan stellt am Ende der Verhandlungen alle Zusagen der beteiligten Personen in einer Übersicht dar. Diese Zusagen sind eine Art Versprechen der übernehmenden Personen, auf das sich die abgebende Partei im Konfliktfall beziehen kann. Zu viele Projekte, zu wenig Kapazität Eine Grundklage der Projektleiter nicht nur im Verlag bezieht sich auf die chronisch zu geringe Ausstattung der Projekte mit Personal. Projektmitarbeiter sowie Projektleiter klagen darüber hinaus noch über zu viele Projekte gleichzeitig. Die Fragen nach
23 siehe hierzu „Für die, die (zu) viele Projekte haben: die Projekt-Pipeline – (1) Grundlagen“, Projektmensch-Blog, Holger Zimmermann, http://blog.projektmensch.com/2010/08/17/fur-die-die-zu-vieleprojekte-haben-die-projekt-pipeline-1-grundlagen/, abgerufen 15. August 2013
Projektstruktur gleich Budgetplan fürs Projekt 95
dem Ressourcenbedarf sowie den tatsächlich anstehenden Projekten können nur die wenigsten präzise beantworten. Erst durch die Erstellung eines Zeitplans, der zeigt, wann welche Aufgabe erledigt werden sollte, wird der Ressourcenbedarf erstmals grob sichtbar. Wird dann noch der Arbeitsaufwand geschätzt, wird der tatsächliche Ressourcenbedarf deutlich. Ohne diese Planung bleibt jede Ressourcenabschätzung vage. Vor allem müssen die Bedarfe verschiedener Projekte von den Beteiligten immer wieder spontan ausgeglichen werden, da es unmöglich ist, gleichzeitige Bedarfe aus verschiedenen Projekten im Voraus erkennen und damit frühzeitig beseitigen zu können. Damit ist gleichzeitig die Grundlage dafür gelegt, den Personalbedarf verschiedener Projekte im Sinne eines Multi-Projekt-Management ausbalancieren zu können. Aus Sicht des Auftraggebers eines Projektteams ist es nur logisch, die Forderung nach Personalausstattung mit einer schlüssigen Bedarfsplanung untermauern zu lassen. Projektleiter, die mangelnde Personalausstattung beklagen, ohne die daraus resultierende Forderung mit einer Bedarfsabschätzung zu unterlegen, sind in einer schwachen Position. Im umgekehrten Fall sind diejenigen Projektleiter, die eine entsprechende Forderung auf der Grundlage einer soliden Planung stellen, meist die, die bekommen, was sie benötigen. Schließlich ist die damit verbundene Entscheidung nur noch logisch, sobald der Projektplan die Notwendigkeit schlüssig aufzeigt. Dasselbe Prinzip gilt für die Bearbeitung vieler Projekte, die scheinbar gleichzeitig laufen. Erst wenn Kollisionen sichtbar werden, lassen sich sinnvolle Entscheidungen über Prioritäten treffen. Sind die Kollisionen nicht sichtbar, ist es nachvollziehbar, dass Auftraggeber schlicht maximale Geschwindigkeit in allen Projekten fordern. So haben sie die höchste Wahrscheinlichkeit, dass wenigstens keine Kapazität verschenkt wird. Immerhin ist so zumindest die Auslastung hoch.
Einnahmen und Ausgaben Projektstruktur gleich Budgetplan fürs Projekt Die Kalkulation des Projektbudgets geht ähnlich vonstatten, wie die Schätzung der Zeitaufwände: für jede einzelne Tätigkeit werden sowohl Einnahmen wie auch Ausgaben geschätzt. Wobei als „Projektbudget“ der Teil der Einnahmen und Ausgaben betrachtet wird, der während der Projektlaufzeit entsteht. Meist steht eine liquiditätsorientierte Betrachtung der Zahlungsströme im Fokus. Separat davon ist der Geschäftsplan zu betrachten. In eine solche Berechnung gehen die Projektkosten als Investitionen oder Aufwände ein. Zusätzlich werden die Aufwände einbezogen, die nach Projektabschluss entstehen, etwa laufende Wartungs- und Betriebsaufwände. Ein solcher Geschäftsplan ist, sofern er benötigt wird, ein Ergebnis der Projektarbeit. Er zeigt auf, wie sich das Projektergebnis im Laufe der Zeit amortisieren soll. Frage Nr. 15: Mit welchen Einnahmen und Ausgaben rechnen wir? Sachkosten, Personalkosten und Einnahmen werden separat betrachtet. Für jede Tätigkeit im Projektstrukturplan werden Einnahmen und Ausgaben geschätzt. Auf der jeweils übergeordneten Ebene des Projektstrukturplans können so Zwischensummen gebildet werden, die auf oberster Ebene das Projektbudget ergeben. Personalkosten errechnen sich aus dem geschätzten Arbeitsaufwand multipliziert mit dem individuellen Stundensatz der zugeordneten Ressourcen.
Ein schlüssiger Projektplan macht den Ressourcenbedarf sichtbar und damit die Verhandlung mit dem Auftraggeber über die Ressourcenausstattung leichter.
96 Verlagsprojekte planen
Geht ein Projekt über den Wechsel des Geschäftsjahres hinaus, sollten Abgrenzungsthemen im Rahmen der Kostenkalkulation mit der Buchhaltung oder dem Controlling abgestimmt werden, um viele Mühe für nachträgliches Aufarbeiten zu vermeiden.
In den meisten Projekten in Verlagen genügt auf der Kostenseite eine Einteilung in Personalkosten und Sachkosten, wobei die Personalkosten meist die Aufwände sind, die von im Verlag fest angestellten Mitarbeitern geleistet werden. Im Fokus stehen eher Geldflüsse, weniger kaufmännisch korrekte Abrechnungen. Die kaufmännische Erfassung und Abgrenzung erfolgt in den meisten Fällen im Rahmen von Routineprozessen, ebenso wie etwa das Bezahlen der über die Projektlaufzeit anfallenden Rechnungen. Eine Ausnahme bildet der Jahresabschluss, wenn Projekte über den Jahreswechsel hinweg bearbeitet werden. Die korrekte Abgrenzung sollte im Rahmen der Projektkalkulation mit der Buchhaltung oder der Controlling-Abteilung des Verlags abgestimmt werden.
Abbildung 39: Eine einfache Projektkalkulation auf Basis des PSP. Für jede Tätigkeiten werden Sachkosten und Einnahmen geschätzt sowie die Personalkosten berechnet.
Bei den Sachkosten werden alle Aufwände erfasst, für die eine Rechnung eingeht. Wobei diese Betrachtung manchmal zu kurz greift und sich eine separate Betrachtung der Honorare anbietet. Im Projektbudget werden ausschließlich die Honorare betrachtet, die direkt für das Projekt bezahlt werden, etwa wenn der Satz durch einen externen Dienstleister erbracht wird. Autorenhonorare hingegen werden im übergeordneten Geschäftsplan auf Basis erwarteter Verkaufszahlen kalkuliert, wenn diese von den Absatzzahlen oder Umsätzen abhängig sind. Eventuelle Einmalzahlungen an Autoren sind Grenzfälle.
Verlagsinterner Personalaufwand
Erst wenn auch der interne Aufwand eines Projekts betrachtet wird, wird ein Vergleich mit anderen Projekten und damit eine Auswahl der sinnvollsten Vorhaben möglich.
Bei vielen Verlagsprojekten liegen die personellen Aufwände weit höher als die Sachkosten, wobei lediglich letztere im offiziellen Projektbudget festgehalten werden. Diese Nicht-Betrachtung der Personalkosten führt dazu, dass die Wirtschaftlichkeit der Projekte leidet. Allein deshalb macht eine Betrachtung der Projektkosten in der Planungsphase Sinn. Sie macht eine frühe Wirtschaftlichkeitsbeurteilung von Projekten möglich, ebenso wie den Vergleich konkurrierender Projekte. Um eine qualifizierte Aussage treffen zu können, welche Projekte sinnvoller sind als andere, müssen auch die internen Aufwände in die Projektkalkulation einfließen. Nur dann können zwei Projekte gegeneinander abgewogen werden. Angesichts knapper Personalressourcen ist diese Abwägung immer nötig, wenn sie auch selten bewusst durchgeführt wird. Für Projektleiter ist diese Berechnung immer dann ein hilfreiches Kommunikationsmittel, wenn zu viele Projekte anstehen, die unter realistischer Betrachtung nicht zum Abschluss geführt werden können. Verschiedene Projekte konkurrieren miteinander um diese knappen Ressourcen. Die Betrachtung auch der internen Aufwände macht eine Entscheidung aufgrund des Aufwand-Nutzen-Verhältnisses leichter. Wobei sicherlich nicht ausschließlich Kos-
Budget für Restrisiken 97
tenbetrachtungen den Ausschlag geben dürfen, welche Projekte durchgeführt und welche nicht gestartet werden. Schließlich sind Projekte ein sehr wichtiges Mittel, um strategische Wettbewerbspositionen zu erschließen.
Optimierung aus Kostensicht Die Kostenbetrachtung macht erst eine Optimierung des Projektablaufs aus Kostengesichtspunkten möglich. Erst jetzt wird sichtbar, wo Kostentreiber sind. Diese können nun systematisch reduziert werden. Wieder spielt der kritische Pfad eine wichtige Rolle. Denn bei kritischen Tätigkeiten darf eine Einsparung auf keinen Fall zu längeren Bearbeitungszeiten führen, da diese sonst wiederum zu einer längeren Gesamtlaufzeit des Vorhabens führen. Einsparpotenzial mit geringerem Risiko bieten oft die Tätigkeiten, die nicht kritisch sind und mit einem Puffer einhergehen. Dieser Puffer kann genutzt werden, etwa um Aufgaben von weniger erfahrenen, jedoch günstigeren Mitarbeitern erledigen zu lassen. Manchmal gelingt es auch, mit Zulieferern zu verhandeln, die aufgrund der Spielräume im Projektplan Kapazitätslücken füllen und deshalb zu einem niedrigeren Preis arbeiten können. Wieder gilt es, Aufgabe für Aufgabe nach Einsparpotenzial zu durchforsten. Diese Einsparungen haben dann konsequenterweise Einfluss auf den Zeitplan, jedoch – sofern eben der kritische Pfad nicht berührt wird – nicht auf den Endtermin. Wichtig ist, dass bei Verschiebungen ein Abgleich der Ressourcenplanung durchgeführt wird.
Budget für Restrisiken Wer ohne Risikobudget startet, steht meist von Beginn an auf verlorenem Posten. Es ist grundsätzlich sinnvoll und nötig, ein Budget für Projektrisiken zur Verfügung zu haben, um im Eintrittsfall handlungsfähig zu bleiben. Tritt ein Risiko ein und das Projektteam verfügt nicht über die nötigen Mittel, um dieses Risiko zu kompensieren, verstreicht wertvolle Zeit bis zur Freigabe weiterer Mittel durch den Auftraggeber oder Lenkungsgremien. Dies führt dazu, dass weitere Störungen im Projektverlauf auftreten und viele Änderungen am Projektablauf koordiniert werden müssen. Diese sind am Ende nicht selten teurer als die Kosten, die zur Vermeidung nötig gewesen wären. Im Wesentlichen können zwei Arten von Risikobudgets unterschiedenen werden: Zum einen benötigen die in der Risikoanalyse identifizierten Minimierungsmaßnahmen Ressourcen und Geldmittel. Diese Maßnahmen sollten im Projektstrukturplan enthalten sein und werden somit im Rahmen der Projektkalkulation wie jede andere Tätigkeit kalkuliert. Zum anderen bleibt nach allen Minimierungsmaßnahmen ein Restrisiko übrig. Dieser potenzielle Schaden, der bei Eintritt eines Risikos entstehen könnte, muss ebenfalls mit Geldmitteln und Ressourcen ausgeglichen werden können. Hierfür wird ein separates Risikobudget eingeplant, das der Einfachheit halber dem Aufgabenpaket „Risikomanagement“ in der Rubrik „Projektmanagement“ des Projektstrukturplans zugeordnet wird. Im Beispielprojekt „Neue Buchreihe mit Webportal“ könnte ein weiteres Risiko sein, dass die bestehenden Webserver für die dauerhafte Last nicht geeignet sind. Das Risiko wird entsprechend hoch bewertet, weshalb „Lasttests durchführen“ als Gegenmaßnahme eingeplant wird. Diese Maßnahme kostet Geld und wird entsprechend im Projektbudget berücksichtigt.
Risikobudget
98 Verlagsprojekte planen Die Annahme ist weiterhin, dass die Leistungsfähigkeit durch Anpassungen der Konfiguration mit hoher Wahrscheinlichkeit sichergestellt werden kann. Es bleibt jedoch das Restrisiko, dass dies nicht gelingt und die Server die erforderliche Leistung nicht bringen. Demnach müssten zwei neue Server angeschafft und eingerichtet werden, was beträchtliche Kosten mit sich bringt. Hierfür wird eine Risikoreserve eingeplant, die die Handlungsfähigkeit des Projektteams sicherstellt.
Abschluss der Projektplanung Den Projektplan entschlacken Die Tendenz in Projekten ist eindeutig: sie werden meist größer, selten kleiner. Hier noch ein Wunsch, hier noch eine Funktion, die eingebaut werden könnte, hier noch eine Aufgabe, die das Ganze abrundet. Dieser Trend macht Projekte teurer und anstrengender. Mit einer kleinen, einfachen Schleife kurz vor Abschluss der Projektplanung kann dieser Trend zumindest gebremst werden: direkt vor der Freigabe des Basisplans wird der Projektplan systematisch durchgearbeitet und für jedes Aufgabenpaket hinterfragt, ob die jeweiligen Aufgaben unbedingt durchgeführt werden müssen. Falls die Antwort „Ja“ lautet, wird geprüft, wie die Bearbeitung dieser Aufgaben vereinfacht werden kann. Ziel dieser Schleife ist es, Optimierungsmöglichkeiten bewusst zu machen und die damit verbundene Chance auf eine smartere Projektabwicklung zu nutzen. Frage Nr. 16: Wie geht es einfacher? Bevor der Projektplan freigeben wird, wird eine Optimierungsrunde eingeschoben. Es wird geprüft, welche Aufgaben weggelassen werden können, ohne die vereinbarten Projektziele zu gefährden. Für die verbleibenden Tätigkeiten wird geprüft, wie diese einfacher erledigt werden können, ebenfalls ohne die Projektziele zu gefährden. Diese Optimierungsrunde spart Zeit, Geld und Nerven. Und sie wirkt dem scheinbar natürlichen Trend von Projekten entgegen, immer größer und teurer zu werden.
Die für diese Optimierung aufgewendete Zeit lohnt sich schnell mehrfach. Zum einen wird der Projektaufwand reduziert. Das führt sehr häufig zu einer Reduzierung der Projektlaufzeit, womit der Nutzen, den das Projekt liefern soll, früher zur Verfügung steht. Gleichzeitig hat diese Schleife Signalwirkung für die weitere Projektbearbeitung: „Es ist erwünscht, Dinge wegzulassen oder einfacher zu machen!“ Da dies für jeden Mitstreiter persönlich entspannende Wirkung hat, ist die Wahrscheinlichkeit hoch, dass sich das Projektteam während der Projektlaufzeit immer wieder daran erinnert, das Signal aufgreift und den Projektplan einfacher macht.
Terminvorgaben sind Stichtage
Finger weg von Start- und Endtermin einer einzelnen Tätigkeit. Terminvorgaben werden als Stichtage eingetragen und mit der Realität abgeglichen.
Ein Projektplan wird rein auf Basis logischer Überlegungen aufgebaut, nicht zuletzt um den kritischen Pfad identifizieren zu können. Aus Reihenfolge und Dauer von Tätigkeiten ergibt sich, in Kombination mit Ressourcenverfügbarkeit und Überlegungen zur Kostensituation, ein Zeitplan. Aus diesem Zeitplan ergibt sich wiederum, wann welche Zwischenergebnisse vorliegen können. Diesen Terminen werden die Terminvorgaben in Form von Stichtagen gegenübergestellt. Das ist insofern eine wichtige Aussage, dass so mancher frischgebackene Projektleiter sich eine Projektmanagement-Software kauft und versucht mittels Starttermi-
Terminvorgaben sind Stichtage 99
nen und Endterminen einen Zeitplan zu erstellen. Ein solcher Zeitplan sieht nur zu Projektbeginn gut aus. Sobald sich erste Abweichungen der Realität gegenüber dem Plan ergeben, steigt der Pflegeaufwand des Plans ins Uferlose. Entsprechend wird dem Plan die Realität nicht gegenüber gestellt. Irgendwann wird der Unterschied zwischen Plan und Realität so groß, dass der Plan vergessen wird und man sich versucht durchzuwursteln. Ein Plan dagegen, der auf Basis von Abhängigkeiten zwischen Aufgaben und deren Bearbeitungsdauer erstellt wird, macht eine Aktualisierung leicht. Lediglich die Tätigkeit, die eine andere als die geplante Bearbeitungsdauer hat, muss angepasst werden. Alle davon abhängigen Tätigkeiten verschieben sich automatisch, da der Computer deren Verschiebung anhand der Abhängigkeiten berechnen kann. Das reduziert den Aufwand für die Projektsteuerung beträchtlich. Der Plan wird zum Hilfsmittel. Deshalb eine klare Aussage: Finger weg von Starttermin und Endtermin einer einzelnen Tätigkeit. Derartige Termine werden als Stichtage erfasst. Frage Nr. 17: Zu welchem Zeitpunkt werden welche Ergebnisse vorliegen? Stichtage für Zwischenergebnisse helfen, den Überblick in Sachen Terminvorgaben zu behalten. Die Terminvorgaben werden den Tätigkeiten und Meilensteinen im Zeitplan als Stichtage gegenübergestellt. Liegt ein sich aus dem Zeitplan ergebender Liefertermin nach dem vorgegebenen Stichtag, ist eine weitere Optimierung der Projektabläufe nötig.
Liegt der Stichtag nach dem Termin, zu dem laut Zeitplan das erforderliche Ergebnis zur Verfügung steht, ist der zugehörige Teil des Projekts im grünen Bereich. Liegt der Stichtag vor dem Termin, zu dem die Lieferung laut Zeitplan möglich ist, ist eine weitere Optimierung des Projektablaufs nötig. Es müssen Maßnahmen eingeleitet werden, die zu einer Erreichung des Stichtags führen.
Abbildung 40: Der Stichtag, als Pfeil dargestellt, wird erreicht. Eine weitere Optimierung ist nicht nötig.
In Abbildung 40 ist ein solcher Stichtag mit einem Pfeil eingezeichnet. Der Abschluss der Bearbeitung der letzten Tätigkeit fällt exakt mit dem Stichtag zusammen, so dass jeder Verzug einer vorhergehenden Tätigkeit auf dem kritischen Pfad dazu führen wird, dass der Stichtag nicht erreicht wird. In Abbildung 41 ist ein solcher Verzug eingetreten. Die Sequenz aller Tätigkeiten auf dem kritischen Pfad dauert so lange, dass der Abschluss der Bearbeitung nach dem Stichtag liegt. Der Stichtag kann somit nicht gehalten werden. Nun müssen
100 Verlagsprojekte planen Maßnahmen ergriffen werden, die dazu führen, dass der Abschluss der Bearbeitung spätestens zum Stichtag erfolgen kann. So könnte beispielsweise die erste Tätigkeit mit mehr Personal bearbeitet werden, damit die Bearbeitungsdauer verkürzt wird. Genügt das nicht, könnten für die darauffolgende Tätigkeit beispielsweise Überstunden bewilligt werden etc.
Abbildung 41: Der Stichtag liegt vor dem im Zeitplan erreichten Abschlusstermin der Tätigkeit. Eine weitere Optimierung ist nötig.
Diese zeitliche Optimierung des Ablaufs kann einzig und allein entlang des kritischen Pfads erfolgen. Dieser wird systematisch, Tätigkeit für Tätigkeit, durchgearbeitet und auf Kürzungsmöglichkeiten untersucht. Wobei für eine kürzere Durchlaufzeit meist ein höherer Aufwand oder eine niedrigere Qualität des Ergebnisses in Kauf genommen werden müssen. Je präziser die Projektziele definiert sind und das magische Dreieck der Projektarbeit im Rahmen der Zieldefinition beschrieben ist, desto leichter fallen diese Entscheidungen.
Der Basisplan markiert das Ende der Projektplanung Basisplan, Basislinie
Kluge Projektleiter nutzen Projektpläne, um die notwendigen Bedingungen für den Projekterfolg auszuhandeln.
Sind alle notwendigen Optimierungen durchgeführt, wird der Projektplan erst vom Projektteam und danach von Auftraggeber und Lenkungsgremien zur Umsetzung freigegeben. Die so verabschiedete Version des Projektplans wird als Basisplan oder Basislinie bezeichnet. Damit verbunden ist eine aktualisierte Freigabe von Budgets und Ressourcen, da erst jetzt für eine Umsetzung ausreichend präzise Werte vorliegen. Alle vorher verwendeten Werte waren gröbere Schätzungen. Dasselbe gilt für bisher verwendete Meilensteintermine. Nun ist eine weit bessere Abschätzung vorhanden, wann welches Zwischenergebnis voraussichtlich erreicht werden wird. Es kann durchaus sinnvoll sein, ein Projekt an diesem Punkt abzubrechen. Wird etwa erkannt, dass die ursprünglichen Schätzwerte so nicht gegeben sind und damit die Sinnhaftigkeit des Projekts gefährdet ist, sollte ein Abbruch mindestens diskutiert werden. Deshalb ist eine ehrliche Planung sehr wichtig. Leider wird in der Praxis nicht selten versucht, die Projektpläne so zu frisieren, dass damit die bisher geschätzten Zahlen erreicht werden. Es ist nicht Sinn und An-
Der Basisplan markiert das Ende der Projektplanung 101
spruch der Projektplanung, bisherige Annahmen zu bestätigen. Vielmehr stellt die Projektplanung eine kritische Prüfung und Verifizierung bisheriger Annahmen dar. Ein Projektplan ist ein Hilfsmittel. Er zeigt lediglich, wie es gelingen könnte, die vereinbarten Projektziele zu erreichen. Er zeigt nicht, wie es gelingen wird und er erzählt keine Märchen. Projektpläne erleichtern sowohl die Projektsteuerung sowie auch die Kommunikation über den Projektverlauf. Kluge Projektleiter nutzen dieses Instrumentarium, um damit die für den Projekterfolg tatsächlich notwendigen Mittel einzufordern. Sie zeigen auf Basis der Pläne auf, wo Engpässe sind, wo Gefahren lauern und worauf somit besonders geachtet werden muss. Das hilft auch Auftraggebern und Lenkungsgremien, besser zu verstehen, wie sie das Projekt unterstützen können und wo sie nicht sparen dürfen, wenn sie den Projekterfolg nicht gefährden wollen. Deshalb sollte diese Freigabe nicht auf dem Schriftweg erfolgen. Eine gute moderierte Diskussion auf Basis des Projektstrukturplans ist das geeignete Mittel, um nochmals Annahmen und Überlegungen zu prüfen. Dies dient gleichzeitig eben auch der bereits mehrfach erwähnten Förderungen des Verständnisses für die Zusammenhänge im Projekt bei allen Beteiligten. Entsprechend sind Teilnehmer dieser Diskussion mindestens Vertreter aus Projektleitung, Projektteam und Lenkungsgremien. Frage Nr. 18: Wie schließen wir die Planung ab? Am Ende der Projektplanung steht eine offizielle Freigabe des Projektplans sowohl durch Projektleitung und Projektteam, wie auch durch Auftraggeber und Lenkungsgremien. Alle Beteiligten sollten die wesentlichen Zusammenhänge und Restriktionen verstanden und akzeptiert haben. Ein offizielles Freigabeprotokoll mit Unterschrift sorgt dafür, dass letzte Ungereimtheiten auf den Tisch kommen. Deshalb sollte die Freigabe eines Projektplans immer im persönlichen Gespräch erfolgen. An der Freigabe werden alle Personen beteiligt, die wesentlich zum Projekt beitragen, auch Autoren, freie Grafiker, externe Dienstleister, Druckereien und andere Parteien außerhalb des Verlags. Deren Verständnis und Akzeptanz der im Plan dokumentierten Vorgehensweise ist ebenso nötig für die Zielerreichung, wie die Leistungen aller internen Kollegen. Gegebenenfalls wird von Personen, die nicht an der Freigabebesprechung teilnehmen können oder sollen, vorab eine Freigabe eingeholt.
Die Freigabe der Projektskizze wie auch des Projektplans erfordern einen Dialog mit dem Auftraggeber und/oder den Lenkungsgremien.
Projektsteuerung: Das Geplante realisieren Die Zeit im Griff Ziele erreichen, nicht Pläne einhalten Sinn eines Projektplans ist nicht die Einhaltung des Plans. Ein Projektplan ist ein Werkzeug, das helfen soll, Ziele zu erreichen. Abweichungen der Realität gegenüber der Planung sind der Normalzustand. Die Projektmanagement-Systematik muss deshalb darauf ausgelegt sein, mit diesen Unterschieden möglichst einfach umgehen zu können. Aus der Abweichung zwischen Realität und Basisplan werden Schlüsse gezogen und Reaktionen abgeleitet, die sicherstellen, dass die Ziele trotz aller Widrigkeiten erreicht werden. Die Wahrscheinlichkeit, dass Plan und Realität identisch sind, geht gegen Null. Nicht alle Details können während der Planung bereits identifiziert werden, nicht jede Annahme wird sich im Laufe der Umsetzung des Projektplans bestätigen. Frage Nr. 19: Wie steuern wir die Umsetzung zeitlich? Jeder Basisplan bildet eine Annahme ab, wie es gelingen könnte, die Projektziele zu erreichen. Die Realität folgt diesen Annahmen nicht. Allerdings liefert der Unterschied zwischen Annahme und Realität Hinweise darauf, wie und wo steuernd eingegriffen werden muss, um die Projektziele trotz dieser Abweichungen zu erreichen. Jetzt macht es Sinn, ein Jour Fixe, eine regelmäßige Besprechung mit dem Projektteam zur Projektsteuerung einzuplanen: „Wir treffen uns alle zwei Wochen, montags, zehn Uhr für eine halbe Stunde.“ Diese Regeltermine haben zur Agenda, Plan und Soll zu vergleichen, um aus den Differenzen Schlüsse für die weitere Vorgehensweise zu ziehen und Kompensationsmaßnahmen einzuleiten, sofern notwendig und sinnvoll. Es lohnt sich übrigens, die Regelbesprechung durchzuführen, auch wenn Teilnehmer fehlen. Diese Regelbesprechung ist der Motor des Projekts. Im Fokus stehen neben der Zeit auch Kosten und Qualität der Ergebnisse. Regelbesprechungen sind der Motor eines Projekts. Sie sollten nicht ausfallen, weil einzelne Teilnehmer fehlen.
Der Basisplan bleibt unverändert. Durch die Gegenüberstellung der tatsächlichen Entwicklung werden Abweichungen sichtbar. Aus diesem Delta lassen sich leicht Kompensationsmaßnahmen einleiten.
Um die Zielerreichung systematisch sicherzustellen, werden im Rahmen der Projektsteuerung Basisplan und Realität regelmäßig gegenübergestellt. Aufgaben, die im Projektplan links des Tages liegen, an dem diese Kontrolle erfolgt, sollten abgeschlossen sein. Für die Tätigkeiten unmittelbar rechts des Statusdatums, wie der Tag der Gegenüberstellung genannt wird, muss sichergestellt sein, dass sämtliche Voraussetzungen und Ressourcen nach wie vor gegeben sind, um die Tätigkeit bearbeiten zu können. In Abbildung 42 konnte Tätigkeit 1 nicht wie ursprünglich geplant abgeschlossen werden. Da diese auf dem kritischen Pfad liegt, verzögern sich sämtliche nachfolgenden Tätigkeiten, so dass sich ohne einen Eingriff in den Ablauf der gesamte Projektabschluss verzögern würde. Die aktuelle Prognose zeigt, dass die letzte geplante Tätigkeit nach dem vorgegebenen Stichtag liegt. Wobei sich die Prognose aus der tatsächlichen Entwicklung in der Vergangenheit plus der ursprünglichen Planung ableitet. In der Grafik sind manche Tätigkeiten bereits abgeschlossen, manche noch in Arbeit.
Wichtig sind die Reaktionen auf Abweichungen 103
Abbildung 42: Zeitlicher Verzug. Die Abweichung der Realität gegenüber dem Basisplan ist der Normalzustand im Projekt.
Wichtig sind die Reaktionen auf Abweichungen Die Prognose ist der eine Teil der Projektsteuerung. Weit wichtiger, dass die Projektleitung sicherstellt, dass auf Abweichungen zielgerichtet reagiert wird. Vorausgesetzt, die Abweichungen gefährden den Projekterfolg. Ob dies der Fall ist, zeigt die Fortschreibung der Projektplanung auf Basis der echten Werte in der Vergangenheit und des Basisplans. Statusdatum Status Tätigkeit 1
√
Tätigkeit 2 in Arbeit Tätigkeit 3
√
Tätigkeit 4
offen
Tätigkeit, die anders durchgeführt wird, als ursprünglich geplant, um den Termin zu halten. Tätigkeit, aktuelle Prognose Tätigkeit, tatsächliche Bearbeitung Tätigkeit geplant, kritischer Pfad Tätigkeit geplant, nicht kritisch Stichtag
Abbildung 43: In diesem Beispiel wurde der zeitliche Verzug kompensiert, indem bspw. Tätigkeit 4 mit mehr Personal bearbeitet wird.
104 Projektsteuerung: Das Geplante realisieren Die Grafik in Abbildung 43 zeigt, wie der zeitliche Verzug aus Abbildung 42 kompensiert werden kann. Da erkannt wurde, dass das Projektende durch den Verzug bei Tätigkeit 1 ebenfalls verzögert werden wird, wurde mit Kompensationsmaßnahmen darauf reagiert. Diese Maßnahmen können immer nur auf Tätigkeiten einwirken, die in der Zukunft liegen. Im Beispiel wurde auf Tätigkeit 4 so eingewirkt, dass diese in kürzerer Zeit erledigt werden kann. Dies könnte etwa durch Überstunden oder zusätzliches Personal geschehen, oder durch die Reduzierung von Anforderungen an das Ergebnis dieser Tätigkeiten. Überstunden und zusätzliches Personal haben Auswirkung auf die Projektkosten, eine Reduzierung der Anforderungen Auswirkungen auf die Qualität des Ergebnisses.
Nicht reagieren zu müssen spart wertvolle Energie Auf Abweichungen vom Plan, die den Projekterfolg nicht gefährden, wird konsequenterweise nicht reagiert. Wird etwa eine Tätigkeit, die nicht auf dem kritischen Pfad liegt und einen Puffer von fünf Tagen hat, um zwei Tage verzögert, erfordert dies keinerlei Kompensation.
Abbildung 44: Die Verzögerung bei Tätigkeit 3 hat keine Auswirkung auf den Projektabschluss. Darauf wird nicht reagiert.
Nur wer Plan und Realität vergleichen kann, kann abschätzen, wo tatsächlich Reaktionen auf Abweichungen nötig sind und wo nicht. Das spart Ressourcen, da nur auf Abweichungen reagiert wird, sofern diese den Endtermin gefährden.
In Abbildung 44 wird die Tätigkeit 3 vermutlich mit einer Verzögerung abgeschlossen werden. Diese Aufgabe liegt nicht auf dem kritischen Pfad und der Puffer zur nachfolgenden Tätigkeit wird durch die Verzögerung nicht aufgebraucht. Auf eine solche Abweichung ist keine Reaktion nötig. Die Verzögerung fällt in die Kategorie „egal“. In dieser Erkenntnis liegt ein großer Nutzen der Projektmanagement-Methodik. Projektteams, die keinen Projektplan vorliegen haben, können nicht erkennen, welche Auswirkung eine verzögerte Lieferung hat. Konsequenterweise reagieren sie entweder auf jede Abweichung und investieren dadurch Energie auch an Stellen, an denen keine Reaktion nötig wäre. Sie verschwenden Ressourcen. Oder Sie reagieren
Jour Fixe als Motor von Verlagsprojekten 105
nicht. Auch dort nicht, wo eine Reaktion dringend angeraten wäre, wodurch sie den Projekterfolg gefährden.
Jour Fixe als Motor von Verlagsprojekten Die Gegenüberstellung von Realität und Basisplan erfolgt in regelmäßigen Intervallen. Als Format haben sich dafür kurze, systematische Besprechungen der Projektleitung oder des Projektteams, abhängig von der Projektgröße, bewährt. Diese Besprechungen werden häufig als „Jour Fixe“ (frz. fester Tag) bezeichnet. Sie sind Teil der Regelkommunikation in einem Projekt. Ein Jour Fixe findet immer am selben Tag, im selben Abstand, mit dem selben Teilnehmerkreis und mit derselben Agenda statt. Im Sinne des Projektmanagement ist das Jour Fixe eine regelmäßige Besprechung zur Projektsteuerung. Die Agenda ist kurz: 1. Status: a. Was wurde erledigt? b. Wie lange hat die Erledigung gedauert? c. Welche Kosten sind entstanden? d. Wie gut wurden die Anforderungen an die Qualität erfüllt? 2. Abweichungen und Kompensationsmaßnahmen a. Welche Abweichung gegenüber der Planung gibt es? b. Welche Auswirkungen haben diese auf den Projekterfolg? c. Wo müssen welche Kompensationsmaßnahmen durchgeführt werden? d. Wer ist für deren Umsetzung verantwortlich? 3. Nächste Schritte a. Welche Arbeiten stehen in den nächsten Intervallen an? b. Inwieweit sind die Voraussetzungen und Ressourcen dafür gegeben? c. Welche neuen Informationen liegen dazu vor? d. Wie müssen wir darauf reagieren? e. Wer ist für die Umsetzung der Reaktionen verantwortlich? Ebenso kurz wie die Agenda sind die Besprechungen auch. Die Empfehlung eine solche Besprechung am Stehtisch zu machen, habe ich bereits mehrfach gehört und kann sie nur weitergeben. Besprechungen werden dadurch deutlich kürzer. Wer erst mit einer Kaffeetasse vor sich an einem Tisch sitzt, bleibt gerne ein bisschen länger. Ein Jour Fixe im Sinne dieses Buchs ist eine Besprechung zur Projektsteuerung. Ausschließlich Themen der Projektsteuerung stehen auf der Agenda. Wo stehen wir? Welche Abweichungen gibt es gegenüber dem Plan? Wie wollen wir damit umgehen? Bei einer solchen Besprechung geht es nicht um inhaltliche Diskussionen, etwa über die Buchausstattung oder das Layout des Webportals. Sollen diese Themen in der Gruppe erledigt werden, muss im Projektstrukturplan die Aufgabe „Buchausstattung definieren“ zu finden sein. Aus dem Zeitraum im Projektplan ergibt sich dann, wann sich der entsprechende Personenkreis treffen muss, um eben dies zu diskutieren. Es handelt sich nicht um ein Thema, das im Rahmen der Steuerungsbesprechung diskutiert wird. Wobei jedem klar sein dürfte, dass sich dieser Anspruch nicht immer mit der Praxis in Einklang bringen lässt. Gerade wenn Teilnehmer anreisen müssen, lohnt es sich, Steuerungsbesprechungen mit inhaltlichen Diskussionen zu verbinden. Allerdings empfehle ich dann, erst die Themen der Projektsteuerung auf die Agenda zu setzen. Erfahrungsgemäß werden die inhaltlichen Diskussionen über Ausstattungen, Layouts, Farben von Gesprächsrunden als spannender und nicht so anstrengend empfunden. Stehen diese zuerst auf der Tagesordnung, bleibt für die übrigen Punkte
Agenda Jour Fixe
Besprechungen am Stehtisch sind oft kürzer.
Wenn möglich, sollten Steuerungsbesprechungen und inhaltliche Diskussionen getrennt werden.
106 Projektsteuerung: Das Geplante realisieren meist keine Zeit mehr. Die jedoch entscheiden darüber, ob die Arbeit gemacht wird oder eben nicht.
Meilenstein-Trendanalyse Die Analyse der zeitlichen Entwicklung der Meilensteine eines Projekts ist ein beliebtes Instrument, um zu erkennen, wie sich der Fortschritt eines Projekts grundsätzlich entwickelt. Zu regelmäßigen Berichtszeitpunkten werden die Plantermine der Meilensteine den Ist-Terminen beziehungsweise Prognoseterminen gegenüber gestellt. Aus den Abweichungen der aktuellen Werte gegenüber den Plandaten lässt sich der Trend der Terminentwicklung erkennen. 11. Jan. Meilenstein 1 Meilenstein 2 Meilenstein 3
22. Nov.
3. Okt.
14. Aug.
25. Jun.
6. Mai.
17. Mrz. 1
2
3
4
5
6
7
8
9
Berichtszeitpunkte
Abbildung 45: Die Meilenstein-Trendanalyse in grafischer Form ist beliebt, da sie die grundsätzliche zeitliche Entwicklung eines Projekts auf einen Blick erkennbar macht. Hier ein Projekt, dessen Liefertermine sich verzögern.
Abweichungen einzelner Tätigkeiten von der Planung sind egal, sofern der Projektleiter schlüssig aufzeigen kann, wie er eine Abweichung kompensieren wird, um die Projektziele zu erreichen.
In der Praxis konzentriert sich diese Trendanalyse leider oft ausschließlich auf die berichtende Funktion. Stattdessen ist es viel wichtiger aus einem negativen Trend Handlungen abzuleiten, die dafür sorgen, dass ein negativer Trend umgekehrt oder wenigstens gemildert werden kann. Zu einem Meilenstein-Trendbericht gehört deshalb immer auch ein Handlungsvorschlag der Projektleitung, wie eventuelle Abweichungen kompensiert werden können. Als Auftraggeber oder Mitglied eines Lenkungsgremiums ist mir eine Abweichung nahezu egal, sofern der Projektleiter schlüssig aufzeigt, wie er gedenkt diese Abweichung zu kompensieren und so die Projektziele zu erreichen. Fehlt diese Gegenmaßnahme ist das ein Hinweis darauf, dass der Projektleiter seine Rolle nicht in vollem Umfang wahrnimmt. Im Beispiel in Abbildung 45 ist zu erkennen, dass sich sämtliche MeilensteinTermine mit jedem Berichtszeitpunkt weiter nach hinten verschieben. Die logische Frage an die Projektleitung lautet in diesem Fall: „Wie wollen Sie den Terminverzug
Budgets im Griff 107
wieder kompensieren?“ Es ist Aufgabe der Projektleitung, entsprechende Kompensationsmaßnahmen zu entwickeln und durchzusetzen. Liegen diese nicht mehr im Handlungsspielraum der Projektleitung, werden diese dem Lenkungsgremium zur Freigabe vorgelegt. Dann ist es Aufgabe der Projektleitung entsprechende Maßnahmen und Entscheidungen als Vorschlag für das Lenkungsgremium einzubringen. Lenkungsgremien haben Entscheidungsbefugnisse, die über den Handlungsrahmen des Projekts hinaus gehen. Sie können beispielsweise zusätzliches Budget oder zusätzliche Ressourcen beschaffen, die über das ursprüngliche Maß hinausgehen, indem sie andere Vorhaben nicht durchführen. Somit stehen über das Lenkungsgremium weit mehr Handlungsoptionen zur Verfügung, als die Projektleitung alleine durchsetzen kann. Deshalb sollte die Projektleitung die Berichte an das Lenkungsgremium immer als Chance verstehen, Entscheidungen im Sinne des Projekts zu erwirken.
Lernen aus dem Projektverlauf für den Projektverlauf Ein Projektteam gewinnt im Verlauf eines Projekts ständig an Wissen und Erfahrung dazu. Diese Erfahrung gilt es für den weiteren Projektverlauf zu nutzen und zwar bereits während das Projekt noch läuft. Deshalb sollten folgende Fragen regelmäßig im Rahmen des Jour Fixe diskutiert werden: • Was kennzeichnet den bisherigen Projektverlauf? • Wo waren unsere Annahmen zutreffend, wo nicht? • Was läuft gut, was nicht? • Worin sehen wir Chancen für den weiteren Projektverlauf? • Welche Erkenntnisse leiten wir aus dem bisherigen Projektverlauf ab? • Was wollen wir für die weitere Projektlaufzeit anders machen? Völlig zurecht wird häufig gefordert, dass eine Organisation aus der Projekterfahrung Lehren ziehen soll. Allerdings kommen die „Lessons Learned“ am Ende eines Projekts nur noch anderen Projekten zugute. Wird der Lernprozess bereits während der Projektlaufzeit fester Bestandteil der Projektmanagement-Sitzungen, kann bereits das laufende Projekt davon profitieren. Ein Projektleiter muss lediglich den entsprechenden Tagesordnungspunkt auf die Agenda setzen, um diesen Effekt für das Projekt zu nutzen. Dabei muss dieser Tagesordnungspunkt nicht lange dauern. Nicht selten genügt eine halbe Stunde.
Budgets im Griff Was für die zeitliche Steuerung eines Projekts gilt, gilt ebenso für die Steuerung von Einnahmen und Ausgaben. Aus dem Projektplan ergibt sich, wie viel Ausgaben bis zur Erledigung bestimmter Aufgaben veranschlagt sind. Frage Nr. 20: Wie steuern wir Einnahmen und Ausgaben? Für alle erledigten Tätigkeiten wird die Summe der aufgelaufenen Kosten betrachtet. Ist die tatsächliche Zahl höher als geplant, müssen bei zukünftigen Aufgaben Einsparungen durchgesetzt werden. Dazu wird Aufgabe für Aufgabe hinsichtlich Einsparpotenzial geprüft. Dasselbe Prinzip gilt für die Einnahmen, die während eines Projekts erzielt werden. Liegt die Summe der geplanten Einnahmen unter dem veranschlagten Betrag, müssen zukünftige Einnahmen erhöht oder im Gegenzug Kosten zukünftiger Aufgaben gesenkt werden, um die Budgetziele zu erreichen.
Lernfragen für die Jour-Fixe-Statusbesprechung
108 Projektsteuerung: Das Geplante realisieren Um zukünftig mögliche Einsparungen realisieren zu können, wird jede einzelne Tätigkeit hinsichtlich Einsparpotenzial überprüft. Da Einsparungen oft mit Nachverhandlungen oder Änderungsaufwand samt den dafür notwendigen Umplanungen einher gehen, ist es in vielen Fällen lohnenswert, mit der Untersuchung bei Tätigkeiten zu beginnen, die nicht auf dem kritischen Pfad liegen. Das Risiko für einen zeitlichen Verzug aufgrund der zusätzlichen Arbeitsschritte sinkt dadurch.
Abbildung 46: Sachkostenkontrolle auf Basis einzelner Tätigkeiten.
Die Auflistung in Abbildung 46 zeigt einen Ausschnitt des Budgetsplans des Beispielprojekts „Neue Buchreihe mit Webportal“. In diesem Ausschnitt wurden die aufgelaufenen Sachkosten kontrolliert. Bei der Tätigkeit mit der Ordnungsnummer 85 „Erstgespräche führen“ wurden 700 Euro statt der geplanten 500 Euro ausgegeben. Dadurch wird, in der vorläufigen Annahme, dass keine Kompensationsmaßnahme durchgeführt wird, das Budget in Summe um 200 Euro überschritten, da alle anderen Tätigkeiten mit Status „erledigt“ im Rahmen des Budgetplans liegen. Wobei es sich bei dieser Aussage um eine Prognose handelt, da noch nicht alle Tätigkeiten abgeschlossen wurden und somit deren Kosten unsicher sind. Um nun sicherzustellen, dass das Budget am Projektende nicht wirklich überschritten wird, müssen Einsparpotenziale bei zukünftigen Tätigkeiten identifiziert werden. So könnten etwa bei den Tätigkeiten 87 „Verhandlungen führen“ und 89 „Verträge abstimmen“ auf persönliche Gespräche verzichtet und statt dessen Videokonferenzen durchgeführt werden. Die Kosteneinsparung wird erreicht, indem die Qualität der Gesprächsführung von persönlich auf via Videokonferenz gesenkt wird. Damit steigt das Risiko von Missverständnissen geringfügig, was in Abwägung gegenüber der Einhaltung des Budgets in Kauf genommen werden kann.
Abbildung 47: Kostenaufstellung nach Einplanen der Kompensationsmaßnahmen bei Tätigkeiten 87 und 89.
Anforderungen eindeutig halten 109
Die Qualität im Griff Qualität bedeutet vereinbarte Anforderungen zu erfüllen Die Qualität eines Ergebnisses leitet sich daraus ab, wie gut es die gestellten Anforderungen erfüllt. Um dies beurteilen zu können, müssen zum einen die Anforderungen eindeutig bekannt sein, das Ergebnis vorliegen und Testverfahren vorhanden sein, die ein Prüfen des Ergebnisses hinsichtlich der Anforderungen möglich machen. Sowohl ein Unterschreiten der Anforderungen wie auch ein Überschreiten können schlechte Qualität darstellen. Beide Fälle müssen frühzeitig identifiziert werden, so dass möglichst wenig Schaden entstehen kann. Je früher Abweichungen erkannt werden, desto größer ist der Handlungsspielraum der Projektleitung. Frage Nr. 21: Wie stellen wir Qualität sicher? Qualität bedeutet, den Anforderungen möglichst exakt zu entsprechen. Die Anforderungen ergeben sich im Rahmen eines Projekts aus den Projektzielen, gegebenenfalls ergänzt durch Konzeptionspapiere, Lastenhefte und Pflichtenhefte. Diese Anforderungen müssen eindeutig benannt sein. Wird auf ein Papier Bezug genommen, muss dieses Papier eindeutig zuzuordnen sein, weshalb es sich anbietet, jegliche Dokumente im Projekt mit Versionsnummern und Statusdatum zu kennzeichnen. Außerdem muss jederzeit klar sein, welche Version gültig ist, sprich: auf welche Version Bezug genommen wird.
Anforderungen eindeutig halten Wer Qualität sicherstellen will, muss eindeutig wissen, an welchen Anforderungen diese Qualität gemessen werden soll. Deshalb ist es wichtig, sämtliche Dokumente, in denen Anforderungen beschrieben werden, immer eindeutig zu kennzeichnen. Dies kann etwa über eine Versionsnummer geschehen. Diese muss sowohl in der digitalen Version eines Dokuments sowie im Ausdruck sichtbar sein. Jede Veränderung des Dokuments führt zu einer Veränderung der Versionsnummer. Sämtliche Versionsnummern und damit verbundene Änderungen werden zu Beginn des Dokuments in einer Versions- oder Dokumenthistorie zusammengestellt, so dass jeder Leser des Dokuments den Änderungsverlauf nachvollziehen kann. Darüber hinaus muss klar sein, welche Version die aktuell gültige Vereinbarung über die zu liefernde Qualität darstellt. Schließlich kann eine neue Version eines Dokuments nur ein Entwurf für eine zukünftig gültige Anforderungsliste sein. Aus diesem Grund wird in einer Änderungshistorie vermerkt, ob ein Entwurf gültig oder eben nur ein Entwurf ist. Tabelle 3: Beispiel einer Änderungshistorie im Dokument. Lfd.Nr.
Version
Änderung
Autor
Status
1
1-00
Dokument angelegt
Elvira Hansen
Entwurf
2
1-01
Kapitel „Anforderungen Zahlungsprozess“ neu eingefügt
Elvira Hansen
freigegeben
3
1-02
Anforderungen Zahlungsprozess ergänzt
Sven Berber
Entwurf
110 Projektsteuerung: Das Geplante realisieren In Tabelle 3 ist die Version 1-01 des Dokuments die aktuell zu verwendende Version. Das ist aus der Zeile „Status“ ersichtlich. Dort hat die Version 1-01 den Status freigegeben. Alle darauffolgenden Versionen, in der Tabelle ist dies einzig die Version 1-01, haben lediglich den Status „Entwurf“. Neben den Angaben zum Änderungsverlauf hilft es, für jedes Dokument den Eigentümer zu benennen. Diese Person ist verantwortlich für die Konsistenz des Dokuments und die einzige Person, die den Status des Dokuments verändern darf. Selbst Entwürfe inhaltlicher Änderungen werden üblicherweise nur in Absprache mit dieser Person durchgeführt.
Änderungen erfordern Freigaben – auch von Seiten der Verlagsleitung Für das Scheitern von Projekten sind nicht selten unreflektiert übernommene Änderungen von Projektzielen und Anforderungen verantwortlich. Das Projektteam muss sich bewusst sein, dass jede Änderung von Anforderungen neue Tätigkeiten mit sich bringen kann und damit Aufwand produziert. Aus zusätzlichen Anforderungen, die nachträglich gefordert werden, entsteht logischerweise zusätzlicher Arbeitsaufwand für die Integration und Realisierung dieser Anforderungen. Allerdings können auch wegfallende Anforderungen zusätzlichen Aufwand auslösen, etwa wenn durch den Wegfall einer Anforderung Korrekturen und Änderungen an bereits bestehenden Ergebnissen nötig werden. Welche konkreten Auswirkungen eine einzelne geänderte Anforderung hat, muss im Einzelfall analysiert werden. Eine pauschale Aussage ist nicht möglich. Erst nach der Analyse des Einzelfalls wird die Freigabe erteilt. Ohne eine Freigabe darf eine Änderung keinen Eingang in das Projekt finden. Sobald eine Änderung zur Aufnahme in das Projekt freigegeben wird, ist es wichtig, dass die nun durchzuführenden Tätigkeiten bekannt und mit Ressourcen versorgt sind. Nur dann ist sichergestellt, dass die zur Aufnahme der Änderung notwendigen Tätigkeiten durchgeführt werden. Ob es sich um neue Tätigkeiten handelt oder Korrekturmaßnahmen durchgeführt werden müssen, ist für die Systematik der Änderungsbearbeitung unerheblich. Grundvoraussetzung und Zielsetzung zugleich ist die Eindeutigkeit der Anforderungen zu jedem Zeitpunkt im Projekt. Frage Nr. 22: Wie stellen wir eindeutige Anforderungen sicher? Der Auslöser für eine Änderung ist immer ein Änderungswunsch. Dieser Änderungswunsch wird formalisiert in einem Änderungsantrag erfasst, um sicherzustellen, dass der Änderungswunsch korrekt ins Projekt übernommen wird. Auf Basis dieser formalisierten Erfassung werden die Auswirkungen auf das Projekt in Zeit, Geld und Aufwand sowie Qualität abgeschätzt. Diese Abschätzung ist wiederum Grundlage für eine formale Freigabe der Änderung. Wird diese Änderung freigegeben, wird erst der Projektplan samt der Ressourcenzuordnung entsprechend angepasst. Der Basisplan liegt damit in einer neuen, nun gültigen Version vor. Die Umsetzung der Änderung ist damit im Rahmen der Projektsteuerung sichergestellt und erfordert keine zusätzlichen Koordinationsmaßnahmen. Änderungen, die das Erreichen der Projektziele nicht gefährden oder eine Anpassung der Projektziele darstellen, werden typischerweise von der Projektleitung freigegeben. Änderungen der Ziele oder der von Auftraggeber oder Lenkungsgremien gestellten Anforderungen müssen auch von diesen freigegeben werden. Es ist ein fataler Fehler von Projektteams, geänderte Anforderungen etwa der Verlagsleitung ohne Freigabe derselben umzusetzen. Neue Anforderungen benötigen meist Zeit, Geld und Ressourcen, die bereitgestellt werden müssen.
Wer die entsprechenden Kompetenzen zur Freigabe welcher Änderungen hat, sollte spätestens zu Beginn der Umsetzung des Projektplans vereinbart werden (siehe Ka-
Vorlage: Änderungsantrag und -bewertung 111
pitel „Erwartungen, Kompetenzen, Spielregeln“, Seite 119). Anzunehmen, die sonst innerhalb des Verlags gültigen Spielregeln finden im Projekt ebenfalls Anwendung, kann ein fataler Irrtum sein. Außerdem ist der Handlungsspielraum des Projektleiters selten vorab definiert. Üblicherweise wird bei internen Projekten, etwa unserem Beispielprojekt „Neue Buchreihe mit Webportal“, die Projektleitung für Änderungsfreigaben verantwortlich zeichnen, sofern die Projektziele unberührt bleiben. Dies wird der Fall sein, wenn beispielsweise einzelne Funktionen im Pflichtenheft ergänzt oder gestrichen werden.
Spätestens wenn die Projektziele berührt werden, sind Auftraggeber und Lenkungsgremien mit im Boot. Die Projektziele sind elementare Grundlage der Zusammenarbeit zwischen Auftraggeber und Projektteam, ebenso wie alle zuvor vereinbarten Anforderungskataloge, wie auch immer diese bezeichnet werden. Deshalb müssen beide Parteien beteiligt werden, sobald Projektziele geändert werden. Eine Konkretisierung der Formulierung von Projektzielen hingegen kann in den meisten Fällen durch die Projektleitung vorgenommen werden.
Vorlage: Änderungsantrag und -bewertung Änderungsantrage stellen unter anderem sicher, dass eine gewünschte Änderung korrekt verstanden wird. Darüber hinaus machen sie eine systematische Bearbeitung der Änderungen mit wenig Aufwand möglich. Damit verbunden ist der Effekt, dass nicht alle Änderungen unreflektiert übernommen werden, was das Projekt zum Scheitern führen kann. Die nachfolgende Vorlage hat sich in vielen Projekten bewährt. Der erste Teil wird vom Antragsteller ausgefüllt, der Bewertungsteil von der Projektleitung. Die Freigabe erfolgt nach den in der Kompetenzmatrix (siehe Tabelle 5, Seite 120) definierten Spielregeln.
112 Projektsteuerung: Das Geplante realisieren
Für Verlagsprojekte angemessen: Qualitätssicherung im Rahmen der üblichen Projektsteuerung 113
Abbildung 48: Vorlage Änderungsantrag
Für Verlagsprojekte angemessen: Qualitätssicherung im Rahmen der üblichen Projektsteuerung Werden die Aufgaben der Qualitätssicherung, wie im Kapitel „Die Aufgabenliste“ (S. 71 f.) beschrieben, im Rahmen der Aufgabenplanung mit erfasst, benötigt die Qualitätssicherung grundsätzlich keinen zusätzlichen Steuerungsmechanismus. Im Rahmen der Projektsteuerung wird die Erledigung aller Aufgaben kontrolliert und sichergestellt, also auch die der Qualitätssicherung. Wobei es sich bei diesen Tätigkeiten anbietet, zusätzlich zu hinterfragen, welcher Stand der Anforderungen Grundlage für die Durchführung der Qualitätssicherungstätigkeiten war. Eine Qualitätssicherungsaufgabe kann nur als erledigt markiert werden, wenn der korrekte Stand der Anforderungen verwendet wurde. Im Gegensatz zur Verwendung von projektübergreifenden Qualitätssicherungsplänen, ist diese Vorgehensweise sehr schlank und kann im Rahmen der üblichen Steuerungsmechanismen abgebildet werden. Für die meisten Verlagsprojekte ist dieser Ansatz mehr als ausreichend. Er hat außerdem den Vorteil, dass sich so das gesamte Projektteam und gar Lieferanten für die Erreichung der geforderten Qualität einbinden lassen.24 Erst wenn Projekte eine Größe erreichen, die so viel Aufwand für Qualitätssicherung produzieren, dass ein oder mehrere Personen damit ausgelastet werden können, ist dies ein starkes Indiz dafür, dass Maßnahmen der Qualitätssicherung zentral ge-
24 vgl. Projektmanagement, Hans-Dieter Litke u.a., Haufe, 2. Auflage, 2012, S. 115
Das Erfassen und Kontrollieren der Erledigung von Aufgaben der Qualitätssicherung im Rahmen des Projektplans macht die Qualitäts sicherung sehr schlank.
114 Projektsteuerung: Das Geplante realisieren bündelt werden sollten. Dann werden diese Maßnahmen in einem übergreifenden Qualitätssicherungsplan zusammengeführt und optimiert. Damit liegt ein zusätzliches Gewicht darauf, dass die unterschiedlichen Anforderungen zueinander passen.
Abbildung 49: Beispiel für das Planen der Aktivitäten der Qualitätssicherung, die in den Meilenstein „Livesystem ist verfügbar“ münden.
In Abbildung 49 ist beispielhaft eine Liste der Tätigkeiten aufgeführt, die etwa für die Qualitätssicherung des Livesystems des Webportals im Beispielprojekt erledigt werden müssen. Die Liste basiert auf einer Annahme, wie viele Iterationsschleifen vermutlich nötig werden, um die notwendige Qualität erreicht zu haben. Verlagsinterne Mitarbeiter haben meist ein gutes Gefühl dafür, wie viele solche Schleifen üblicherweise nötig werden, bis alle Kinderkrankheiten beseitigt sind. Diese Schleifen werden als einzelne Tätigkeiten aufgeführt. Wird statt dessen eine zusammenfassende Tätigkeit im Plan erfasst, führt dies meist dazu, dass bereits der erste Test die dafür vorgesehene Zeit in Anspruch nimmt. Eine kleinteiligere Auflistung macht allen bewusst, dass nach einem ersten Test und einer ersten Korrektur weitere Tests und Korrekturen folgen werden. Damit ist die Wahrscheinlichkeit höher, dass die Qualitätssicherungstätigkeiten pünktlich erledigt werden.
Unabhängig von der Art und Weise, wie die Qualität sichergestellt werden soll, ist es zwingend notwendig, die Anforderungen so zu beschreiben, dass diese getestet werden können. Je klarer und eindeutiger die Kriterien definiert sind, die das Erreichen der Anforderungen erkennen lassen, desto leichter lässt sich die Qualität überprüfen. Die Vorbereitung von Testszenarien und die Vorbereitung von Tests gehören dann zum Katalog der durchzuführen Qualitätssicherungsaufgaben dazu.
Qualitätssicherung erfordert Expertenwissen Projektleitung hat zu einem großen Teil mit Koordination und Steuerung zu tun. Damit sind zwei von drei Perspektiven des magischen Dreiecks des Projektmanagement abgedeckt: die pünktliche Lieferung und die Einhaltung des vereinbarten Aufwands. Auch die Durchführung der Qualitätssicherung ist damit sichergestellt, da diese im Rahmen der üblichen Projektsteuerung erfolgt. Für diesen koordinierenden Teil des Projektmanagements sind nur bedingt Fachkenntnisse über das zu liefernde Produkt notwendig. Vielmehr sind Kenntnisse der Projektmanagement-Methodik, der Kommunikation und von Führung gefragt. Anders sieht es aus, wenn es um Qualitätsaspekte des zu liefernden Ergebnisses geht. Die Beurteilung von Qualität benötigt entsprechendes Expertenwissen. In Verlagen ist es üblich, dieses Fachwissen ebenfalls beim Projektleiter zu sehen. Für den größten Teil der Projektmanagement-Arbeit sind jedoch andere Fähigkeiten gefragt.
Vorlage: Meilenstein-Freigabe 115
Auf diesem Grund ist es sinnvoller, das entsprechende Fachwissen zielgerichtet im Rahmen der Ressourcenplanung zuzuordnen. Demnach werden die Arbeiten der Qualitätssicherung in den Projektplan aufgenommen und in einem weiteren Schritt Verantwortlichkeiten definiert. Im Idealfall werden für die Definition von Testkriterien und die Abnahme andere Experten eingesetzt, als für die Herstellung des zu testenden Ergebnisses. Damit werden blinde Flecken reduziert, die dazu führen können, dass wichtige Qualitätsaspekte übersehen werden und die Qualität des Ergebnisses darunter leidet.
Abnahmen durch den Auftraggeber: Qualitätssicherung mit Meilensteinen Zusätzlich zur regelmäßigen Fortschrittskontrolle auch der Maßnahmen zur Qualitätssicherung, macht es Sinn, Zwischenabnahmen auf Basis von Meilensteinen durchzuführen. Im Rahmen einer Meilensteinbesprechung wird systematisch geprüft, ob alle für den Meilenstein definierten Zwischenziele erreicht wurden. Damit verbunden ist die Freigabe der nächsten Phase. Diese Form der Zwischenabnahme geschieht sinnvollerweise gemeinsam mit den Auftraggebern und Lenkungsgremien. Je nach Verständnis von Meilensteinen, kann es durchaus sinnvoll sein, Gelder und Ressourcen für die nachfolgende Phase erst freizugeben, wenn der Meilenstein vollständig erreicht ist. Damit lassen sich aus Sicht der Auftraggeber Projektrisiken in einem kalkulierbaren, begrenzten Rahmen halten. Nicht zu verwechseln sind der Meilenstein als Zwischenergebnis im Projektverlauf mit der zugehörigen Meilensteinbesprechung. Die Meilensteinbesprechung ist ein Arbeitsschritt, der erledigt werden muss. Eine solche Besprechung geht üblicherweise dem Erreichen des Meilensteins voraus, der wiederum lediglich ein definiertes Zwischenergebnis darstellt. Dieses Zwischenergebnis wird erreicht und hat deshalb auch eine Dauer von Null im Projektplan. Die Meilensteinbesprechung dagegen nimmt Zeit in Anspruch, die entsprechend im Projektplan berücksichtigt wird.
Vorlage: Meilenstein-Freigabe Im Rahmen der Meilensteinbesprechung werden die erreichten Ergebnisse den vereinbarten Soll-Ergebnissen gegenübergestellt. Außerdem berichtet der Projektleiter über den voraussichtlichen weiteren Projektverlauf. Ist mit einer Abweichung gegenüber den vereinbarten Projektzielen zu rechnen, stehen darüber hinaus die Kompensationsmaßnahmen im Vordergrund der Diskussion. Diese stellen sicher, dass die Ziele trotz etwa eines verspäteten Meilensteins noch erreicht werden. Gleichzeitig werden im Rahmen der Meilenstein-Besprechung Entscheidungen diskutiert, die vom Lenkungsgremium getroffen werden müssen, um die Erreichung der Projektziele abzusichern. Diese sind ebenso Bestandteil der Freigabe eines Meilensteins und damit der nächsten Projektphase, wie Bedingungen des Lenkungsgremiums, unter denen die Freigabe erfolgt. All diese Aspekte fasst die nachfolgende Vorlage zusammen.
Meilenstein, Meilensteinbesprechung
116 Projektsteuerung: Das Geplante realisieren
Agile Ansätze fokussieren auf funktionsfähige Resultate 117
Abbildung 50: Vorlage Meilenstein-Freigabe
Agile Ansätze fokussieren auf funktionsfähige Resultate Vor allem im Bereich der Softwareprojekte dringen derzeit agile ProjektmanagementAnsätze wie „Scrum“ immer stärker ins Bewusstsein. Eine Besonderheit dieser Methode Projekte zu steuern, liegt in der starken Fokussierung auf funktionsfähige Ergebnisse. Im Rahmen sogenannter Sprints, die häufig einen Monat dauern und ein fester Rhythmus in der Projektbearbeitung sind, wird immer versucht, ein funktionsfähiges und damit auch getestetes Resultat zu schaffen. In der oft als „klassisches Projektmanagement“ bezeichneten Art des Projektmanagement, die in weiten Teilen Grundlage dieses Buchs ist, war das früher nicht üblich. Getestet wurde erst am Ende. Entsprechend groß war gelegentlich die Überraschung, ob das Produkt funktioniert hat oder nicht. Der als agil bezeichnete Projektmanagement-Ansatz hat insofern Charme, da er eine Art automatische und regelmäßige Qualitätssicherung mit sich bringt, die dazu noch früh Abweichungen von der geforderten Qualität sichtbar macht. Dieser Ansatz kann für Verlagsprojekte übernommen werden, indem bereits während der Projektplanung in der Projektstruktur funktionsfähige Teilergebnisse geplant werden. Diese werden dann in einem Zyklus aus Erstellung und Test in den zeitlichen Ablauf eingeplant, so dass bereits während der Projektlaufzeit funktionsfähige Zwischenergebnisse getestet werden. So werden Qualitätsrisiken und -probleme frühzeitig erkannt, was die Fehlerbeseitigung meist erleichtert. Folgefehler werden seltener und der Korrekturaufwand sinkt. Spätestens wenn der Projektstrukturplan entwickelt wird, sollte diese Denkweise berücksichtigt werden, um davon zu profitieren.
Agiles Projektmanagement mit Scrum, Ken Schwaber
Das Fokussieren auf frühe, testfähige Teilergebnisse, reduziert die Auswirkung von Fehlern auf spätere Projektergebnisse.
118 Projektsteuerung: Das Geplante realisieren
Zusammenarbeit über Verlagsbereiche hinweg gestalten Typische Rollen im Projekt und im Verlag
Rollendefinition
Die Rolle, die eine Person in einem Projekt spielt, muss nicht zwingend etwas mit deren üblicher Rolle und Aufgabenbereich im Verlag zu tun haben. Wobei der Begriff „Rolle“ im Kontext von Projektmanagement eher als eine Beschreibung der Funktion im Projekt, weniger als eine soziale Rolle innerhalb eines sozialen Systems verstanden wird.25 Nur weil jemand im Lektorat arbeitet, bedeutet dies nicht zwangsläufig, dass diese Person im Projekt alle üblicherweise dem Lektorat zugeordneten Tätigkeiten durchführt. Eine Klärung der Rollen im Projekt ist zwingend notwendig, um unnötige Reibung – vor allem durch Missverständnisse über Verantwortung und Spielregeln der Zusammenarbeit – zu vermeiden. Eine Rolle im Projekt kann beschrieben werden, indem • Erwartung an die Rolle, • Verantwortung der Person, • Kompetenzen und • Spielregeln der Zusammenarbeit geklärt werden. Damit wird grundsätzlich vereinbart, wie die einzelnen Personen innerhalb des Projekts zusammenwirken. Frage Nr. 23: Wer ist in welcher Rolle wie beteiligt? Aus dem Projektplan ergibt sich, wer für welche Aufgaben oder Aufgabenbereiche eingespannt wird. Daraus lassen sich grundsätzliche Rollen im Projekt ableiten. Diese beschreiben, wie eine Person am Projekt mitwirkt. Mindestens die Rollen Auftraggeber, Projektleitung und Mitglieder des Projektteams müssen in jedem Projekt geklärt werden.
Typische Rollen im Projekt
Drei Rollen gilt es in jedem Projekt mindestens zu klären: 1. Auftraggeber: Der Auftraggeber eines Projekts ist die Person, die einen Projektleiter mit der Umsetzung eines Vorhabens beauftragt. Auftraggeber können sowohl Verlagsmitarbeiter wie auch externe Personen sein. Letztere etwa, wenn diese einen Fachbuchverlag als Kooperationspartner nutzen, um für einen Internetauftritt Inhalte zu liefern. Der Auftraggeber ist in jedem Fall verantwortlich dafür, die Projektziele freizugeben und das Projekt mit den notwendigen Ressourcen auszustatten. 2. Projektleiter: Der Projektleiter ist verantwortlich dafür, das vereinbarte Projektergebnis selbstständig zu liefern. Er wird vom Auftraggeber mit einem Vorhaben beauftragt und mit Ressourcen ausgestattet. Wobei er die Verantwortung dafür trägt, dass der Bedarf an Ressourcen geplant und sinnvoll verwendet wird. Er ist außerdem verantwortlich dafür, dass das Projektteam gut koordiniert arbeitet. Bei einer Gefährdung der Zielerreichung, die durch den Projektleiter und das Projektteam nicht mehr kompensiert werden können, hat der Projektleiter die Pflicht diese Gefährdung dem Auftraggeber zu eskalieren. 3. Mitglieder des Projektteams: Das Projektteam ist verantwortlich für die Erledigung einzelner, definierter Tätigkeiten. Der Projektleiter regelt, wer wann welche Aufgabe übernimmt und stellt sicher, dass die Anforderungen daran benannt sind. Mitglieder des Projektteams übernehmen als Experten inhaltliche Arbeiten. Ein und dieselbe Person kann sowohl die Rolle der Projektleitung wie auch die
25 vgl. Rolle, https://www.projektmagazin.de/glossarterm/rolle, 26. August 2013
Erwartungen, Kompetenzen, Spielregeln 119
eines Teammitglieds haben. In Verlagen kein seltener Zustand. Dann ist wichtig, dass die Rolle „Projektleitung“ Vorrang vor der Rolle des „Projektteammitglieds“ hat, da sonst die Gefahr besteht, dass die Arbeit des gesamten Teams sowie sämtlicher darüber hinaus beteiligter Personen unkoordiniert erledigt wird, was den Projekterfolg gefährdet oder mindestens abschwächt. Weitere typische Rollen in Projekten sind: 1. Mitglieder des Lenkungsausschuss oder des Lenkungsgremiums: Der Lenkungsausschuss ist immer dann eine sinnvolle Einrichtung, wenn mehrere Unternehmensbereiche am Ergebnis mitwirken oder mehrere Bereiche des Verlags vom Ergebnis des Projekts betroffen sind. Die Mitglieder des Lenkungsausschusses treffen übergeordnete Entscheidungen für ihre Unternehmensbereiche. Entsprechend sollten alle betroffenen Unternehmensbereiche darin vertreten sein, entweder direkt oder indirekt. Der Auftraggeber ist zwingend Mitglied des Lenkungsgremiums und es bietet sich in vielen Fällen an, dass er dessen Leitung übernimmt. Je nach Projektumfang benötigt der Auftraggeber das Lenkungsgremium, um die für das Projekt benötigten Ressourcen aus verschiedenen Unternehmensbereichen bereitzustellen. 2. Lieferanten: Lieferanten sind Personen oder Gruppen von Personen, die einzelne für das Projekt benötigte Lieferungen bereitstellen und darüber hinaus nicht am Projekt beteiligt sind. Sowohl interne wie auch externe Personen können in dieser Rolle am Projekt mitwirken. So ist etwa die hauseigene IT-Abteilung oft in der Rolle eines internen Lieferanten, wenn beispielsweise eine bestimmte Software für ein Teammitglied installiert werden muss, weitere Leistungen der IT jedoch nicht benötigt werden.
Erwartungen, Kompetenzen, Spielregeln Sobald es um Rollen im Projekt geht, wird häufig die AKV-Matrix angesprochen. Damit sind Aufgaben, Kompetenzen und Verantwortung gemeint. Diese tabellarische Auflistung soll helfen, Rollen bewusst zu machen und zu klären. Tabelle 4: Beispiel für eine Aufgaben-Kompetenzen-Verantwortungsmatrix (AKV-Matrix), die auch kurz als „Kompetenzmatrix“ bezeichnet wird. Rolle
Aufgaben
Kompetenzen
Verantwortung
Projektleitung
Erstellen und Führen des Projektplans, Einberufen und Leiten von Besprechungen ...
Sämtliche Entscheidungen über Vorgehensweisen, Aufgabenverteilung im Rahmen der Vereinbarung mit Linienabteilungen, Budgetvollmacht bis 100000 Euro im Einzelfall bis zur Budgetgrenze des Projekts ...
Erreichen der Projektziele, Eskalation bei Zielgefährdung ...
Auftraggeber
Beschaffung von Ressourcen, grundsätzliche Freigabe von Budgets ...
Änderungen von Projektzielen, Entscheidung über Fortführung und Abbruch, Freigabe von Meilensteinen ...
Projektauftrag, Sicherstellen der Vereinbarkeit von Projektzielen mit Unternehmenszielen und -strategie ...
...
...
...
...
120 Projektsteuerung: Das Geplante realisieren In Tabelle 4 sind in einer AKV-Matrix beispielhaft die zwei wichtigsten Rollen beschrieben, die im Beispielprojekt „Neue Buchreihe mit Webportal“ mit Sicherheit notwendig sind.26 Darüber hinaus wird im Beispielprojekt sicherlich auch ein Lenkungsausschuss sinnvoll sein, da viele Bereiche des Verlags zusammenwirken müssen.
Das Klären von gegenseitigen Erwartungen und Kompetenzen sowie der Spielregeln der Zusammenarbeit ist wichtig, um Konflikte zu vermeiden und Reibungsverluste durch unterschiedliche Erwartungshaltungen zu reduzieren.
Die AKV-Matrix leistet nützliche Dienste, lässt jedoch die Spielregeln der Zusammenarbeit außer Acht. Jeder Projektbeteiligte hat an solche Spielregeln eine mehr oder weniger bewusste Erwartungshaltung. Sätze wie etwa „Die Informationen müsste er sich doch holen!“ sind typisch dafür, dass eine Klärung dieser Spielregeln nicht stattgefunden hat. Sobald gegenseitige Erwartungen bewusst und daraus Spielregeln vereinbart werden, sinken die Reibungsverluste durch unnötige Diskussionen und das Konfliktpotenzial beträchtlich. Deshalb leistet eine Abwandlung der AKV-Matrix nützliche Dienste, die eben diese Klärung von Erwartungen sowie der Spielregeln der Zusammenarbeit mit abdeckt. Erfolgt die Zuordnung von Aufgaben im Rahmen der Ressourcensteuerung über den Projektplan, ist außerdem die Aufgabenspalte in der AKV-Matrix nicht nötig. Sie macht eher bei kleineren Vorhaben mit Projektcharakter Sinn. Diese Klärung von Erwartungen und Spielregeln sollte im Rahmen einer Besprechung mindestens des Projektteams stattfinden. Als Instrument zur Moderation und späteren Dokumentation hat sich folgende Tabelle bewährt: Tabelle 5: Beispiel einer alternativen Rollenklärung, die die Diskussion im Team stärker fördert. Rolle
Erwartung an diese Rolle
Kompetenzen
Spielregeln zur Zusammenarbeit
Projektleitung
Stellt sicher, dass jeder weiß, was zu tun ist; klärt bei Konflikten ...
Verteilt die Arbeit, die nicht freiwillig übernommen wurde; entscheidet über Lösungen, wenn das Team sich nicht einigen kann ...
Bekommt für jede Tätigkeit eine Fertigmeldung; hilft bei der Beschaffung von Ressourcen für Aufgabenpakete ...
Auftraggeber
Gibt uns einen klaren Projektauftrag; stellt sicher, dass wir am Projekt arbeiten können ...
Hat die Hoheit über Auftrag, Zieländerung, alle Freigaben; entscheidet nicht darüber, wer was erledigen soll ...
Wird regelmäßig von uns informiert, hat keine Verpflichtung nachzufragen ...
...
...
...
...
Während bei der AKV-Matrix die Sache im Vordergrund steht, erlaubt diese Variante auch Zwischentöne im Sinne des Projektteams als soziales System. Unausgesprochene und ungeklärte Erwartungen sind häufig der Auslöser für Konflikte, die Zeit, Geld und Nerven kosten. Wird die obenstehende Tabelle gemeinsam erarbeitet, macht das die Zusammenarbeit leichter. Die Inhalte ähneln denen der AKV-Matrix. Die Perspektive ist meist eine andere, aus der diese Inhalte beschrieben werden. Wichtig ist dass alle Personen beteiligt sind, deren Rolle geklärt wird.
26 Auf eine vollständige Beschreibung von Erwartungen, Kompetenzen und Spielregeln wurde im Rahmen dieses Buchs verzichtet.
Projektleiter und Fachexperten 121
Projektleiter und Fachexperten Ein Projektleiter ist die Person, die dafür sorgt, dass alle Fachexperten gut zusammenarbeiten können und dass deren Zusammenarbeit koordiniert abläuft. Er sorgt dafür, dass die Vorgehensweise sowohl sachlich definiert und jedem Beteiligten klar ist. Und er sorgt dafür, dass das soziale System „Projektteam“ samt dessen Beziehungen zur Außenwelt funktioniert, indem er eine Systematik der Zusammenarbeit schafft, die es den Menschen leicht macht, am Ergebnis mitzuwirken. Gute Projektleiter sind dabei in ihrer Rolle Täter, nicht Opfer. Sie gestalten das System und lassen sich auch von schlechten Auftraggebern nicht abhalten, ein gutes Ergebnis abzuliefern. Sehr häufig werden Projektleiter aus fachlichen Gesichtspunkten für die Rolle des Projektleiters ausgewählt. Leider. Denn damit fehlt dem Projekt ein wichtiger Experte, der dazu noch mit Aufgaben betraut wird, für die er nicht ausgebildet ist und auf die er womöglich keine Lust hat. Die Verantwortung des Projektleiters ist es dafür zu sorgen, dass sämtliche Experten für unterschiedliche Wissensgebiete möglichst reibungsfrei zusammenarbeiten. Dazu muss er vor allem Methodenkenntnisse haben und kommunizieren können. Wir haben in den vergangenen Jahren tausende Seminarteilnehmer, erfahrene Hasen wie Anfänger gefragt, was Aufgaben der Projektleitung sind. Die Ergebnisse sind eindeutig. Zu den Aufgaben der Projektleitung gehören vor allem: • Koordination der Beteiligten • Zieldefinition • Erstellen des Projektplans • Steuerung der Umsetzung samt Sicherstellen von Reaktionen auf Abweichungen der Realität gegenüber dem Projektplan • Ressourcensteuerung • Risikomanagement • Entscheidungen (herbeiführen) • Abstimmung mit Lenkungsgremien und Auftraggebern • Kommunikation im Team und nach außen • Führen des Projektteams ohne hierarchische Weisungsbefugnis • Motivieren • Einladen, Moderieren und Nachbereiten von Besprechungen • Konfliktlösung • Dokumentation • Änderungsmanagement • Überblick herstellen Diese Liste basiert auf den Nennungen der Seminarteilnehmer und stellt eine Auswahl der häufigen Nennungen dar. Wie viel Fachwissen ist für die Durchführung dieser Aufgaben nötig? Unbestritten wird etwa für die Erstellung des Projektplans Expertenwissen vonnöten sein. Deshalb fragt der Projektleiter den jeweiligen Experten. Der Projektleiter führt den Plan, liefert die Struktur, sorgt dafür, dass die einzelnen Fachbeiträge zu einem Ganzen werden. Er ist nicht der Experte. Ist der Projektleiter der Experte für das Hauptthema des Projekts, birgt dies gar eine riesige Gefahr. Das Projektteam wird von ihm erwarten, seiner Rolle als Experte gerecht zu werden. Der Projektleiter registriert diese Erwartungshaltung und will ihr gerecht werden. Er schreibt fortan Konzepte, entwickelt fachliche Lösungen. Seine Aufgaben als Projektleiter kommen zu kurz, das Projekt kommt in schwieriges Fahrwasser. Ein Effekt, der nicht unterschätzt werden sollte. Neben der Tatsache, dass Fachexperten sehr häufig keinen Spaß an der Rolle des Projektleiters haben und al-
Projektleiter
Aufgaben der Projektleitung
Ein Projektleiter muss kein Fachexperte sein.
122 Projektsteuerung: Das Geplante realisieren
Anforderungen an einen Projektleiter
lein deshalb auch gerne die Expertenrolle einnehmen. Wer ein bedeutsames Projekt durchführen und erfolgreich sein will, sollte einen Projektleiter zum Projektleiter machen, nicht einen Fachexperten. Formuliert man auf Basis obenstehender Liste Anforderungen an die Fähigkeiten und Fertigkeiten eines idealen Projektleiters, sind folgende Nennungen häufig: • ist analytisch und strukturiert • ist gut organisiert • kann gut mit Menschen (umgehen) • kann gut zuhören und kommunizieren • beherrscht die Projektmanagement-Methodik • kann überzeugen • ist auch in brisanten Situationen ruhig • kann mit Konflikten gut umgehen • tut sich leicht, den Überblick zu behalten Nun stehen entsprechende Personen in Verlagen nicht immer zur Verfügung und manche Projekte sind auch zu klein, um eine solche Trennung sinnvoll zu machen. In diesen Fällen ist es wichtig, die Erwartung an den Projektleiter als Projektleiter klar zu benennen und mit dem Team zu thematisieren. Der Projektleiter braucht den Freiraum, seine Aufgaben als Projektleiter wahrnehmen zu können. Für das Erstellen von Konzepten und inhaltlichen Lösungen ist das Team verantwortlich. Erst wenn der Projektleiter alle Projektleitungsaufgaben erledigt hat, darf er auch inhaltliche Arbeit übernehmen.
Stakeholder als Rolle im Projekt Eine besondere Rolle im Projekt stellen die Stakeholder dar. Als „Stakeholder“ werden alle Personen und Personengruppen bezeichnet, die aus irgendeinem Grund ein Interesse am Projekt oder dessen Ergebnis haben. Die Gruppe der Stakeholder umfasst sämtliche bisher beschriebenen Rollen und geht gar darüber hinaus. So sind etwa die Nutzer eines Webportals Stakeholder, ebenso wie Anteilseigner des Verlags. Im Gegensatz zu den Rollen, die im Projekt eine zugewiesene Funktion übernehmen, sind die darüber hinaus gehenden Stakeholder schwieriger zu greifen. Sie tauchen nicht im Projektplan auf und sind nicht für die Erledigung von Aufgaben verantwortlich. Nicht immer besteht von vorneherein die Gelegenheit, mit diesem Personenkreis dessen Rolle zu klären. Trotzdem können sie gewaltigen Einfluss auf Projekte nehmen, wie gerade politische Großprojekte deutlich zeigen. Stuttgart 21 ist hierfür nur eines der Beispiele. Obwohl nicht direkt am Projekt beteiligt, haben Demonstranten gewaltigen Einfluss auf Projektfortschritt und -verlauf genommen.27 Diese Personen waren und sind der Projektleitung und dem Projektteam namentlich nicht einmal bekannt, was ein Einbinden grundsätzlich erschwert. Da die Stakeholder nicht im Projektplan in Erscheinung treten, ist es schwierig, mit dieser Zielgruppe Vereinbarungen über Verantwortung, Kompetenzen und Spielregeln der Zusammenarbeit zu treffen. Trotzdem ist die geschickte Einbindung dieser Personengruppe wichtig, wenn nicht gar elementar, für den Projekterfolg. Deshalb
27 siehe u.a. Stuttgarter Nachrichten Online, Dossier zu Stuttgart 21, http://www.stuttgarter-zeitung. de/stuttgart21, 26. August 2013
Stakeholder als Rolle im Projekt 123
wird die Stakeholderanalyse eingesetzt, um Stakeholder zu identifizieren, deren Positionierung zum Projekt einzuschätzen und geeignete Strategien der Beteiligung und Einbindung zu entwickeln. Frage Nr. 24: Wie binden wir die Stakeholder ein? Bei einer einfachen Stakeholderanalyse werden auf Basis einer Analyse des Projektumfelds alle Personen und Gruppen von Personen identifiziert, die möglicherweise ein wie auch immer geartetes Interesse am Projektverlauf oder Projektergebnis haben könnten. Für jeden Stakeholder werden anschließend Annahmen über deren Einstellung zum Projekt erfasst. Außerdem wird die Macht dieser Personen und Gruppen eingeschätzt, die sowohl hierarchisch wie auch informell begründet sein kann. Aus den Ergebnissen der Analyse werden Rückschlüsse auf die Gestaltung des Projekts, vor allem aber auf die Einbindung der verschiedenen Personenkreise und die Kommunikation gezogen. Diese können durchaus zu einer umfangreicheren Anpassung der Projektplanung führen. Im mindesten sind üblicherweise im Rahmen des Projektmanagements zusätzliche Tätigkeiten nötig, etwa die Herausgabe eines Projektnewsletters.
In Abbildung 51 auf der folgenden Seite ist eine grafisch aufbereitete Stakeholderanalyse dargestellt, wie sie für das Beispielprojekt „Neue Buchreihe mit Webportal“ Verwendung finden könnte. Der Macht auf der horizontalen Achse ist die Einstellung einer Person oder Personengruppe auf der vertikalen Achse gegenübergestellt. Auf Basis von Annahmen über Einstellung und Macht einer Person oder Personengruppe wurden diese in dieses Koordinatensystem eingetragen. Die Größe der Kreisfläche spiegelt dabei die Größe der Gruppe wider. So wird schnell deutlich, in welchem Stakeholder-Umfeld sich ein Projekt bewegt. Aus der Position der Personen und Gruppen zueinander lassen sich konkrete Maßnahmen ableiten. So macht es im vorliegenden Beispiel Sinn, den Inhaber als starke Person mit einer sehr positiven Einstellung einzubinden, um damit die eher negative Einstellung des Geschäftsführers zu kompensieren. Alternativ könnte man auch versuchen, den Geschäftsführer mit Argumenten zu einer positiveren Einstellung zu bewegen, was eventuell schon ausreichend könnte. Allein auf den Geschäftsführer als wesentlichen Entscheider und Treiber des Projekts zu setzen, würde das Vorankommen im Projekt auf jeden Fall nicht erleichtern. Kritiker werden an dieser Stelle äußern, dass die Stakeholderanalyse an dieser Stelle zu spät kommt. Sie haben vollkommen Recht. Die Stakeholderanalyse ist ein Instrument, das sehr früh, noch vor der Projektplanung, eingesetzt werden sollte. Allerdings habe ich immer wieder die Erfahrung gemacht, dass zu einem frühen Zeitpunkt das Projekt noch zu wenig greifbar ist. Erst nach Abschluss der Projektplanung ist das Projekt gedanklich durchdrungen. Jetzt fällt es wesentlich leichter auszumachen, wer wann wovon betroffen sein könnte. Die Ergebnisse der Stakeholderanalyse sind meist besser. Unabhängig davon macht eine Erfassung und erste Diskussion der Stakeholder gleich zu Projektbeginn sehr viel Sinn, wie diese auch im Kapitel „Ein Fragenkatalog zum Einstieg“ auf Seite 37 vorgeschlagen ist.
Die Stakeholderanalyse ist spätestens nach Abschluss der Projektplanung fällig, wobei eine Erfassung der wesentlichen Interessensgruppen gleich zu Projektbeginn mit Frage Nr. 1 sinnvoll und nützlich ist.
124 Projektsteuerung: Das Geplante realisieren
Abbildung 51: Die grafische Darstellung von Einstellung und Macht erleichtert die Stakeholderanalyse und das Ziehen von Schlüssen daraus28.
Die Struktur des Projektteams verfeinern
Kernteam, Projektteam
Über eine Visualisierung wie etwa der Teamzwiebel können die Zielgruppen von Kommunikation strukturiert werden.
Im Laufe der Erfassung von Projektbeteiligten und weiteren Stakeholdern ergeben sich Erkenntnisse, die es leicht machen, die Struktur des Projektteams zu verfeinern. Aus dem Projektplan wird ersichtlich, wer wie häufig und an welchen Stellen zum Einsatz kommt. Daraus lässt sich genauer abgrenzen, welche Rolle eine bestimmte Person innerhalb des Projektteams spielt. Oft gibt es Mitstreiter, die sehr viel und sehr eng mitarbeiten, sowohl fachlich wie auch organisatorisch beteiligt sind und an sämtlichen Entscheidungen mitwirken. Dieser Personenkreis kann als „Kernteam“ bezeichnet werden. Ebenso gibt es Mitstreiter, die nur gelegentlich oder sehr punktuell mitwirken. Diese können eher als „Erweitertes Projektteam“ betitelt werden. Dazwischen sind diejenigen, die als Experten dauerhaft am Projekt arbeiten. Dieser Personenkreis stellt am ehesten dar, was als Projektteam verstanden wird. Während das Kernteam sehr eng mit der Projektleitung zusammenarbeitet und an vielen, wenn nicht allen Steuerungsbesprechungen teilnimmt, ist dies für das erweiterte Projektteam nicht erforderlich. Vorausgesetzt, dieser Personenkreis wird auf anderem Wege informiert und kann auf anderem Wege Informationen einspeisen. Sich der feineren Struktur aus organisatorischer Perspektive bewusst zu werden, ist eine vorbereitende Stufe zur Planung von Kommunikation und Information. Eine visuelle Darstellung der Struktur unter Zuordnung von Erwartungen, Verantwortung, Kompetenzen und Spielregeln der Zusammenarbeit hilft, die Abstim-
28 In Anlehnung an Projektmanagement-Fachmann, Band 1, ohne Autorennennung, RKW-Verlag, 7. Auflage, 2003, S. 74
Die Rolle der Verlagskonferenz als Lenkungsgremium 125
mung innerhalb des Projektteams vorzunehmen. Hierfür hat sich die „Teamzwiebel“ bewährt, wie in Abbildung 52 zu sehen. Sie macht schnell deutlich, wie eng jemand in das Projekt eingebunden ist. Jeder Kreis der Teamzwiebel steht für eine Gruppe von Personen im Projekt und damit auch für deren Rolle. Jeder dieser Ringe steht damit gleichzeitig für eine Zielgruppe von Kommunikation. Die Kommunikationsplanung baut direkt auf dieser Definition der Zielgruppen auf.
Weitere Stakeholder Betroffene/ Abnehmer Lieferanten Erweitertes Projektteam Projektteam Kernteam
Projektleitung
Abbildung 52: Die Zwiebeldarstellung hilft, sich der Struktur des Projektteams bewusst zu werden und diese mit dem Team zu diskutieren.
Die Darstellung in Abbildung 52 zeigt dabei einen Umfang, wie er für das Beispielprojekt „Neue Buchreihe mit Webportal“ passt. Ein Kernteam von vielleicht drei bis vier Personen inklusive Projektleiter treibt dieses Projekt voran, unterstützt von einem Kreis von Experten, der als Projektteam definiert wird. Im erweiterten Projektteam sitzen externe Berater, die zu definierten Zeitpunkten Know-how von außen liefern. Lieferanten sind vor allem externe Zulieferer, die etwa das Webhosting bereitstellen. In die Rubrik „Betroffene / Abnehmer“ fallen sowohl die Personen, die später die Hotline zum Webportal betreuen werden wie auch Endkunden sowie Buchhändler. Die Stakeholder wurden bereits in der Stakeholderanalyse erfasst (siehe Seite 122).
Bei kleineren Projekten kann die Teamzwiebel eventuell nur aus Projektleitung und Projektteam bestehen. Bei größeren Projekten kann eine solche Aufteilung Anwendung für jedes Teilprojekt finden, womit das Gesamtteam auf mehrere Teamzwiebeln aufgeteilt wird.
Die Rolle der Verlagskonferenz als Lenkungsgremium Aus Sicht der Projektsteuerung kann die Verlagskonferenz zu einem Lenkungsgremium für Projekte werden. Für Buchprojekte ist diese Runde in vielen Fällen das Gremium, das Freigaben für wichtige Meilensteine erteilt. Dort Berichten etwa Lektoren über anstehende Veröffentlichungen und Ideen. Allerdings steht in vielen Verlags-
126 Projektsteuerung: Das Geplante realisieren konferenzen eher der Inhalt der Werke im Vordergrund. Der organisatorische Anteil der Projekte ist eher am Rande ein Thema, etwa in Form von Veröffentlichungsterminen. Wird dieses Gremium als Lenkungsgremium für Projekte eingesetzt, besteht die Gefahr, dass inhaltliche Themen im Vordergrund bleiben und organisatorische Belange eher in den Hintergrund rücken. Für die Projektsteuerung ist es wichtig, dass auch organisatorische Themen besprochen und dafür Entscheidungen herbeigeführt werden, etwa bei abweichenden Ressourcenbedarfen. Das erfordert, dass auch diesen Themen Zeit gewidmet wird. Dies sollte allen Beteiligten bewusst sein, wenn die Verlagskonferenz als Lenkungsgremium eingesetzt werden soll. Die Diskussion organisatorischer Belange muss in der Agenda verankert sein. Nicht alle Projekte eines Verlags sind allerdings bei diesem Lenkungsgremium sinnvoll angesiedelt. Gerade organisatorische Veränderungen im Verlag oder die Einführung neuer Geschäftsmodelle erfordert eine andere Besetzung. Vertreten sein müssen alle betroffenen Bereiche, nicht nur etwa Verlagsleitung, Lektorat und Herstellung. Ein geschickt agierender Projektleiter sollte einen Vorschlag machen, welche Personen aus Projektsicht in dieser Runde vertreten sein sollten. Grundlage hierfür ist die bereits erwähnte Stakeholderanalyse (siehe Seite 129).
Projektkommunikation Aktiv informieren Wer arbeiten und gute Ergebnisse liefern will, benötigt korrekte Informationen, um das vereinbarte Ergebnis liefern zu können. Der beste Wille taugt nur wenig, wenn die Grundlage für die Arbeit falsch ist. So einleuchtend das ist, so wenig Aufmerksamkeit wird der Kommunikation in Projekten zuteil. In vielen Projekten wird ad hoc informiert, bei Bedarf und in einer bereits bestehenden Konferenz kurz über das Projekt berichtet. Im Fokus stehen meist inhaltliche Informationen. Dabei fallen organisatorische Themen häufig unter den Tisch. Sie sind schließlich auch deutlich langweiliger als etwa ein spannender Buchinhalt, eine neuartige Ausstattung oder die Inhalte eines Webportals. Projektleiter, die genau anders vorgehen und sehr viel Wert auf eine strukturierte, verlässliche Kommunikation legen, machen dagegen häufig die Erfahrung, dass sich viele Dinge von alleine regeln. Was bei anderen Projekten zum Problem wird und im Streit eskaliert, wird erst gar nicht zum Thema. Es gibt erst gar keinen Anlass zum Konflikt. Frage Nr. 25: Wann informieren wir wen wie über was? Ausgangspunkt für die Projektkommunikation sind die verschiedenen Zielgruppen, die in der Teamzwiebel dargestellt werden (siehe Abbildung 52). Auf dieser Grundlage wird geklärt, welche Informationen diese Zielgruppen wann benötigen, um den an sie gestellten Anforderungen gerecht werden zu können. Daraus wird die Regelkommunikation abgeleitet. Es wird beschrieben, wann wer über welchen Kanal und welches Medium über welche Sachverhalte informiert wird. Diese Informationen werden im Projektplan festgehalten. Außerdem wird festgelegt, welche Informationen auf welcher Plattform zum Abruf bereitgestellt werden und wer wie darauf Zugriff hat. Kommunikation ist eine der wichtigsten Aufgaben der Projektleitung, die nicht an den Grenzen des Projektteams endet.
Die aktive Kommunikation ist sicherlich eine der wichtigsten Aufgaben der Projektleitung. Sie endet nicht an den Grenzen des Projektteams. Gerade die Information späterer Benutzer und weiterer Stakeholder ist in vielen Projekten erfolgskritisch. Al-
Regelkommunikation 127
lerdings kann gute Kommunikation sehr aufwändig sein, weshalb es sich besonders lohnt, Zeit in eine einfache und belastbare Kommunikationsstruktur zu investieren, um den Aufwand in Grenzen zu halten.
Regelkommunikation Den Grundtakt der Regelkommunikation stellt das Jour Fixe dar, die regelmäßige Projektstatusbesprechung. Jeweils zu diesem Termin sind aktuelle Daten über den Projektfortschritt und Status verfügbar und damit mit wenig Aufwand für andere Zielgruppen aufzubereiten. Ausgehend von diesem Takt werden über die gesamte Laufzeit sämtliche Aufgaben der Projektkommunikation eingeplant. Dabei greifen Projektkommunikation und Vermarktung des Projekts sinnvollerweise eng ineinander. „Unter Projektkommunikation und Projektmarketing werden alle Maßnahmen und Vorgehensweisen des projektinternen und -externen Informationsaustausches sowie alle projektfördernden Maßnahmen bei allen Beteiligten und Betroffenen des Projektes verstanden. Projektkommunikation und Projektmarketing sind projektbegleitende Prozesse, die den gesamten Projektlebensweg begleiten.“29
Abbildung 53: Beispiel für die Unterteilung der Regelkommunikation (schematische Darstellung).
Eine Trennung der beiden Maßnahmen ist, mit Ausnahme vielleicht von Fusionen und großer Organisationsumstellungen, bei den meisten Verlagsprojekten weder nötig noch sinnvoll. Beide Aspekte der Botschaften, die hinter dieser Unterscheidung zwischen Projektkommunikation und Projektmarketing stecken, sind allerdings wichtig und beachtenswert. Projektkommunikation zielt eher darauf, dass jede Zielgruppe korrekte Informationen in brauchbarer Form bereitgestellt bekommt, um anstehende Arbeit erledigen zu können. Unter der Überschrift „Projektmarketing“ geht es tendenziell
29 Projekte erfolgreich managen, Dr. Thor Möller u.a., 45. Aktualisierung, August 2011, Kapitel 7.2.5, Seite 6
Die Maßnahmen der Projektkommunikation werden auf Basis der Zielgruppen in der Rubrik „Projektmanagement“ des PSP erfasst und eingeplant, wie jede andere Tätigkeit auch.
128 Projektsteuerung: Das Geplante realisieren eher darum, dass die Informationen in einer dem Projekt dienlicher Form aufbereitet werden.30 Projektmarketing richtet sich zusätzlich an Personen, die keine Arbeit am Projekt leisten. Beide Arten der Kommunikation haben gleichermaßen zum Ziel, Vertrauen entstehen zu lassen. Der Aufbau einer regelmäßigen Kommunikation ist wichtig, um Informationsstände nicht zu weit auseinander laufen zu lassen und verlässliche Informationspunkte zu schaffen, an denen jeder einzelne seine individuelle Planung ausrichten kann. Je enger die Abstände zwischen Punkten der Regelkommunikation liegen, desto höher ist die Intensität aber auch der damit verbundene Aufwand. Aus der Projektlaufzeit lassen sich Schlüsse für die Abstände zwischen Kommunikationspunkten ableiten. Ebenso dienen der Bedarf an Projektmarketing sowie die weiteren Ergebnisse der Stakeholderanalyse als Anhaltspunkte für die Bestimmung der Intervalldauer. Tabelle 6: Beispiel für einen einfachen Kommunikationsplan zur Regelkommunikation
Regelkommunikation ist ein wichtiges Mittel, um den Fortschritt sicherzustellen.
Zielgruppe
Intervall
Medium/ Kanal
Inhalte/ Botschaft
Projektleitung, Kernteam
alle 2 Wochen
Jour-Fixe/ Status besprechung
• Statusabgleich Ist/ Soll für Zeit, Aufwand, Budget, Qualität • Kompensationsmaßnahmen • Nächste Schritte und Ressourcensicherung • Entscheidungen
Geschäftsleitung & Verlagsleitung
alle 6 Wochen
im Anschluss an Verlagskonferenz mit Präsentation und schriftlichem Bericht
• • • • •
Geschäftsleitung & Verlagsleitung
jeweils drei Wochen nach Verlagskonferenz
schriftlicher Zwischenbericht
• Inhalte wie oben (alle 6 Wochen)
Kernteam, Projektteam, Erweitertes Projektteam
alle 6 Wochen vor Bericht an Geschäfts- und Verlagsleitung
Besprechung
• Informationsaustausch durch Bericht reihum über Ergebnisse, Erkenntnisse, notwendigen Abgleich und nächste Schritte
Kernteam, Projektteam, Erweitertes Projektteam, Stakeholder
wöchentlich
Projekt-Weblog
• die wichtigsten Informationen von der Projektleitung für das Team und die Stakeholder
...
...
...
• ...
Statusbericht über Projektziele erreichte Ergebnisse inhaltliche Konzeption Plan vs. Realität und Kompensation • Nächste Schritte • Notwendige Entscheidungen
Der Kern der Regelkommunikation ist, dass sie regelmäßig stattfindet. Wer für ein Projekt regelmäßige Statusbesprechungen durchführt und darin Vorgehensweisen abstimmt, hat damit bereits ein großes Maß an Sicherheit, dass das Projekt voran-
30 ebenda, Kapitel 7.2.5, Seite 8ff.
Projektberichte sind ein Hilfsmittel für die Projektleitung 129
kommen wird. Ausfallende Besprechungen und ausbleibende schriftliche Berichte sind häufig ein erstes Indiz, dass ein Projekt in Schwierigkeiten gerät und nicht wie vorgesehen vorankommt. Es lohnt sich wenigstens kurze Besprechungen mit kleinem Teilnehmerkreis zu machen oder kurze schriftliche Informationen zu verteilen, allein der Signalwirkung wegen. Von der Nicht-Teilnahme einzelner Personen sollte sich die Projektleitung nicht aufhalten lassen. Abgesagte Besprechungen senden ein deutliches Signal: „Dieses Projekt ist nicht wichtig!“
Projektberichte sind ein Hilfsmittel für die Projektleitung Gelegentlich werden in der Projekt-Praxis das Berichtswesen und die Regelkommunikation getrennt betrachtet. Aus meiner Sicht ist dies sehr häufig dann der Fall, wenn das „Projekt-Reporting“, wenn die Projektberichte eine Einbahnstraße darstellen: „Der Projektleiter hat dem Lenkungsgremium zu berichten“, lautet dann in etwa die zugehörige Beschreibung in der Arbeitsanweisung. In der Berichtsbesprechung selbst, so es eine solche überhaupt gibt, geht es dann darum, die Absolution erteilt zu bekommen, es „richtig gemacht“ zu haben. Logischerweise führt dies dazu, dass Projektberichte immer gut aussehen und von den Berichtenden selbst schlechteste Ergebnisse noch als „in Ordnung“ verkauft werden. Das ist nicht der Sinn des und Anspruch an das Reporting. Projektberichte sind ein Hilfsmittel für die Projektleitung. Der Projektleiter kann über die Berichte Lenkungsgremien in das Projekt einbinden, für Entscheidungen sorgen und Ressourcen beschaffen. Deshalb nutzen erfahrene Projektleiter diese Gelegenheiten geschickt, um das Projekt voranzubringen. Das Berichtswesen ist ein wichtiges Instrument, um Auftraggeber und Lenkungsgremien entsprechend ihrer Rolle in das Projekt einzubinden. Berichte sind ein Instrument der Regelkommunikation an Entscheider. Diese Personenkreise sind ihrem Titel entsprechend dazu da, übergeordnete Entscheidungen zu treffen. Dazu benötigen sie Informationen über den Projektstatus, ohne selbst im Projekt mitwirken zu können. Ehrliche Informationen, auf die sie vertrauen und auf die sie sich verlassen können. Ziel der Berichte ist es, eine gute Zusammenarbeit zwischen Projektleitung und Entscheidern aufzubauen. Das erfordert Nachfragen der Auftraggeber und das Aufzeigen der kniffligen Stellen durch die Projektleitung. Nur so entsteht das nötige Vertrauen, das Grundlage einer guten Zusammenarbeit ist. Kein Projekt der Welt funktioniert wie geplant. Wie bereits erwähnt ist nicht die Einhaltung des Plans das oberste Gebot. Vielmehr sind Pläne Hilfsmittel der Projektleitung, um die Projektziele zu erreichen. Aus dem Delta zwischen Plan und Realität lassen sich Schlüsse ziehen und Kompensationsmaßnahmen ableiten. Die sind es, die letztlich über den Projekterfolg entscheiden. Die ständige Anpassung der Vorgehensweise an die Realität erst macht die Zielerreichung möglich. Viele dieser Kompensationsmaßnahmen können selbstständig durch die Projektleitung in Gang gebracht und umgesetzt werden. Allerdings kommt ein Projektteam dann an seine Grenzen, sobald zur Kompensation von Abweichungen notwendige Ressourcen fehlen. Die kann das Lenkungsgremium bewilligen, nicht der Projektleiter. Entsprechend muss der Projektleiter aufzeigen, wo ein Engpass besteht, welche Auswirkungen dieser hat und wie er kompensiert werden kann beziehungsweise sollte. Damit verbunden ist ein Vorschlag der Projektleitung an das Lenkungsgremium, wie dieses aus Sicht des Projekts entscheiden sollte. Die Entscheidung obliegt dann dem Gremium. Erfolgreiche Projektleiter nutzen das Berichtswesen geschickt, um
130 Projektsteuerung: Das Geplante realisieren ihr Projekt selbst dann erfolgreich zu machen, wenn die eigenen Mittel ausgeschöpft sind. Grundlage ist dafür, dass mit jedem Bericht ehrlich über Abweichungen gegenüber der Planung informiert wird, egal ob diese negativ oder positiv sind. Werden dazu gleichzeitig Maßnahmen benannt, die trotz Abweichungen die Zielerreichung sicherstellen, helfen die Berichte ungemein, das nötige Vertrauen aufzubauen.
Das Verhalten der Auftraggeber in Lenkungsgremien Die Rolle der Auftraggeber und deren Anteil am Ergebnis eines Projekts wird häufig weit unterschätzt. Irgendwie geht man gemeinhin davon aus, dass der Projektleiter das Vorhaben schon zum Ergebnis führen wird. Dabei ist der Anteil, den Auftraggeber und Lenkungsgremien am Projekterfolg haben, beträchtlich. Jeder Auftraggeber sollte sich fragen, wie er dazu beitragen kann, die Arbeit des Projektleiters leichter zu machen und die Erfolgswahrscheinlichkeit zu steigern. Die Antworten darauf sind meist banal. Etwa ein gut formulierter Projektauftrag ist für einen Auftraggeber mit wenig Aufwand verbunden und spart Projektleitung und Projektteam eine Menge Arbeit. Auftraggeber, die regelmäßig für Rücksprachen zur Verfügung stehen, tun sich und dem Projekt ebenfalls einen Gefallen.
Abbildung 54: Berichtspyramide im Falle von Auftraggebern, die nur negativ kritisieren.31
Im Rahmen des Berichtswesens und der Lenkungsausschusssitzungen nimmt diese Personengruppe ebenfalls beträchtlich Einfluss. Dabei ist deren Verhalten gegenüber dem Projektleiter im Falle von Verzögerungen oder Budgetüberschreitungen wichtig. Muss ein Projektleiter immer nur negative Kritik einstecken, wenn er Negatives berichtet, ist die Gefahr groß, dass er irgendwann nur noch Positives berichten wird. Ab diesem Zeitpunkt verliert der Auftraggeber seinen Einfluss auf das Projekt. Ein Projektleiter schafft es im Zweifelsfall sehr lange, einen Auftraggeber im Glauben zu lassen, dass ein Projekt gut vorankommt. Abbildung 54 beschreibt den Effekt, der entsteht, wenn Berichte durch die Angst vor der Reaktion von Lenkungsgremium und Auftraggeber geprägt sind.
31 Aus „10 Tipps, wie Sie Ihr Projekt sicher ruinieren“, Vortrag, Holger Zimmermann, Wissensforum der Süddeutschen Zeitung, 12. November 2013
Vorlage Projektbericht 131
Umgekehrt bauen die Auftraggeber ihren Einfluss aus, die mit der Projektleitung konstruktiv am Projekterfolg arbeiten. Abweichungen gegenüber der Planung sind der Normalzustand im Projekt. Ein Plan basiert auf Annahmen und Schätzungen. Die Wahrscheinlichkeit, dass er sich eins zu eins umsetzen lässt, geht gegen Null. Wichtig sind die Reaktionen auf die Abweichungen, die müssen sichergestellt werden. Darauf sollten Auftraggeber und die Mitglieder des Lenkungsgremiums fokussieren. In diesem Verständnis sollte die Zusammenarbeit zwischen Auftraggeber und Lenkungsgremium und Projektleitung gestaltet werden. Abweichungen wird es ständig geben und es ist Aufgabe der Projektleitung dafür zu sorgen, dass die Projektziele trotzdem erreicht werden. Entweder die Projektleitung setzt selbst Kompensationsmaßnahmen in Gang oder schlägt, wenn der eigene Einflussbereich ausgeschöpft ist, dem Lenkungsgremium entsprechende Schritte vor. Aufgabe des Auftraggebers ist es, mitzuhelfen, dass die Kompensationsmaßnahmen greifen, etwa durch entsprechende Entscheidungen oder Unterstützung bei der Kommunikation. So tragen alle Parteien dazu bei, dass das Projekt ein Erfolg wird.
Vorlage Projektbericht Die nachfolgende Vorlage hat sich bewährt, da sie den Auftraggebern und Mitgliedern von Lenkungsgremien einen schnellen Überblick über den Projektstatus in strukturierter Form liefert, ohne zu viel Detailkenntnis zu verlangen. Gleichzeitig hilft sie dem Projektleiter, regelmäßig das Projekt und dessen Fortschritt zu reflektieren. Dabei zielt die Vorlage vor allem darauf ab, dass das Projektteam selbstständig Kompensationsmaßnahmen einleitet, wo diese sinnvoll und nötig sind, um die Zielerreichung im Bereich des Möglichen zu halten. Eine immer wieder eingesetzte Vorlage sorgt dafür, dass Berichtspräsentationen produktiver ablaufen. Wird immer wieder in einem anderen Muster berichtet, entsteht zusätzlicher Aufwand, da sich die Beteiligten immer wieder neu orientieren müssen.
Wer Abweichungen der Realität gegenüber der Planung als Normalzustand betrachtet, tut sich leichter, Kompensationsmaßnahmen umzusetzen. Diese sind letztlich der Schlüssel, um das vereinbarte Ziel zu erreichen.
132 Projektsteuerung: Das Geplante realisieren Projektbericht
Datum:
Autor:
Projekttitel
Projektziel
Meilensteine Nr. Meilenstein
Datum lt.
Tatsächlich
Basisplan
abgeschlossen am
Prognose aktuell
1 2 3 4 5 6
Erledigte Schritte/ Konkrete Ergebnisse seit vergangenem Bericht (auf Basis PSP)
Abweichungen gegenüber Zeitplan & Kompensationsmaßnahmen (auf Basis PSP)
©1997-2013 Holger Zimmermann. Projektmensch.
www.projektmensch.com
Vorlage Projektbericht 133
Projektbudget Geplante Ausgaben bis heute:
Tatsächliche Ausgaben bis heute:
Geplante Ausgaben Gesamtprojekt:
Aktuelle Prognose Ausgaben Gesamtprojekt:
Kompensationsmaßnahmen bei Abweichung:
Wesentliche Risiken für das Projekt & Gegenmaßnahmen Nr. Risiko
Bewertung
Bewertung
Kompensations-
Wahrscheinlichkeit
Schadenshöhe
maßnahme
1 2 3 4 5 6 Qualität der Ergebnisse (geplant vs. tatsächlich, durchgeführte Tests, Prognose bis Projektabschluss, Reaktionen)
Nächste Schritte, Termine und Ressourcen
Notwendige Entscheidungen des Lenkungsgremiums
©1997-2013 Holger Zimmermann. Projektmensch.
Abbildung 55: Vorlage Projektbericht
www.projektmensch.com
134 Projektsteuerung: Das Geplante realisieren Wissensmanagement oder „Informationen über die Verlagsgrenze hinaus auf Abruf verfügbar machen“
Tagesberichte sind eine einfache Möglichkeit, Informationen auf Abruf verfügbar zu machen.
Im Projekt besteht schnell die Gefahr, dass das eigene E-Mail-Postfach überquillt, da es gilt, unzählige Informationen zu verteilen. E-Mails sind leicht zu schreiben und zu verteilen. Sie erfordern, da sie ein sogenanntes asynchrones Kommunikationswerkzeug sind, keine Anwesenheit der Empfänger. Empfänger können die E-Mail zu einem späteren Zeitpunkt lesen. Allerdings führen überquellende E-Mail-Postfächer tendenziell eher dazu, dass weniger gelesen jedoch einiger Aufwand für die Ablage betrieben wird. Dieser Aufwand kann reduziert werden, indem Informationen geschickt auf Abruf verfügbar gemacht werden. Dank heutiger Suchtechnologie ist eine strukturierte Ablage in Ordner häufig nicht mehr nötig, wenn alle Beteiligten die passenden Stichworte im Dokument erwähnen. Eine einfache, jedoch wirksame Methode, die gleichzeitig die Selbstorganisation der Teammitglieder unterstützt, ist der Tagesbericht. Eine kurze, in maximal fünf bis zehn Minuten getippte, stichwortartige Zusammenfassung wird von jedem, der am Projekt gearbeitet hat, an zentraler Stelle abgelegt. Hierfür sind keine aufwändigen Software-Systeme nötig. Eine zentrale, eigens für das Projekt eingerichtete EMail-Adresse „[email protected]“, auf die alle Beteiligten mittels des üblichen Mailprogramms zugreifen können, genügt für viele Projekte vollauf. Der Tagesbericht dient gleichzeitig der Reflexion der Teammitglieder und kann als Grundlage für die Fortschrittsüberwachung verwendet werden, wenn darin Tätigkeiten als „abgeschlossen“ gemeldet werden. Frage Nr. 26: Wie stellen wir Informationen auf Abruf bereit? Ein zentraler Informationspool, in dem sämtliche Informationen zum Projekt verfügbar sind, erleichtert die Arbeit ungemein. Wichtig ist, dass alle Nutzer dieser Ablage wissen, wie Informationen dort abgelegt werden sollen und wie die Recherche funktioniert. Außerdem sollte auf Basis der Rollendefinition geklärt werden, wer welche Zugriffsrechte auf welche Daten erhält. Aus Sicht der Systematik ist es unerheblich, ob die Informationen in Papierform, über einen internen Server oder eine cloudbasierte Lösung verfügbar gemacht werden. Wobei softwarebasierte Systeme mindestens den Vorteil der Suchfunktion mit sich bringen und außerdem mit weniger Aufwand über die Distanz, etwa externen Autoren oder Dienstleistern, bereitgestellt werden können.
Die Grenzen zur Dokumentation sind an dieser Stelle fließend. Wobei sich ein genauer Blick lohnt, wo welche Informationen in welcher Form entstehen und wofür diese später wieder benötigt werden oder eingesetzt werden sollten. Allein die Diskussion über diese Fragen führt meist zu einer besser strukturierten Informationsplattform. Neben den Dokumenten, die Ergebnis der Projektarbeit sind, etwa einer Bedienungsanleitung für das Webportal im Beispielprojekt, gibt es eine Vielzahl von Notizen, Erkenntnissen, Gedanken und Ideen, deren Erfassung sich lohnt. Je einfacher es ist, diese Dinge zentral bereitzustellen und im richtigen Moment wieder zu finden, desto höher die Bereitschaft, eine zentrale Informationsplattform zu nutzen.
Aufgabengetriebene Kommunikation Die Regelkommunikation ist wichtig als Motor eines Projekts, auf Abruf bereitgestellte Informationen machen die Arbeit leichter, da weniger Missverständnisse entstehen und weniger gesucht werden muss. Eine dritte Art der Kommunikation stellt die Bearbeitung von Aufgaben sicher, ohne dass die Projektleitung eingreifen wird: die aufgabengetriebene Kommunikation.
Sinn und Zweck von Dokumentation 135
Wird die aufgabengetriebene Information als Spielregel mit dem Projektteam vereinbart, sichert sie zusätzlich den Fortschritt und sorgt automatisch dafür, dass kleinere Abweichungen von der Planung automatisch kompensiert werden. Jedes Mal, wenn eine Tätigkeit vor Ihrem Abschluss steht, informiert die für die Erledigung verantwortliche Person sämtliche Bearbeiter nachfolgender Tätigkeiten über den Stand der Dinge. Wird dabei ein Problem aufgedeckt, das die beteiligten Personen nicht alleine lösen können, ohne den Projektplan ändern zu müssen, wird die Projektleitung an den Gesprächen beteiligt. So werden schwierige Themen automatisch und frühzeitig der Projektleitung zugetragen, was die Problemlösung wesentlich erleichtert. Zusätzlich kann es lohnenswert sein, dass die Projektleitung diese Kommunikation bei allen Tätigkeiten, die auf dem kritischen Pfad liegen, steuert und während der Aufgabenbearbeitung durch Rückfragen sicherstellt, dass die verantwortliche Person alle notwendigen Arbeitsmaterialien, Werkzeuge und Informationen verfügbar hat, um die Tätigkeit im Rahmen der Planung abschließen zu können. Anrufe und Nachfragen dieser Art werden von vielen Projektbeteiligten, entgegen der Befürchtungen vieler Projektleiter, als Wertschätzung empfunden. Voraussetzung dafür ist allerdings, dass diese Rückfragen als Hilfestellung und echtes Interesse verstanden werden und nicht als Ausdruck des Misstrauens gegenüber den Aufgabenverantwortlichen.
Ergebnisse dokumentieren Sinn und Zweck von Dokumentation Die Kunst der Projektdokumentation ist es, heute bereits zu wissen, was übermorgen gebraucht werden wird. Erst Monate oder gar Jahre später fällt auf, ob gut oder schlecht dokumentiert wurde. Damit entsteht auch der Nutzen erst lange Zeit nach dem Projekt, was den Anreiz zur Dokumentation nochmals reduziert. Wenn es um das Thema Dokumentation geht, werden viele Projektteams lahm. Da der Nutzen von Dokumentation zu großen Teilen erst nach dem Projekt entsteht, fällt es in vielen Fällen erst einmal leicht – eine gute Informationslage vorausgesetzt – auf die Dokumentation zu verzichten. Im Beispielprojekt „Neue Buchreihe mit Webportal“ könnte das etwa der Fall sein, wenn eine Erweiterung des Webportals durchgeführt werden soll. Wo finden sich nun gleich die Zugangsdaten für den Webserver? Welche Sonderanpassungen wurden am Shopsystem vorgenommen? Aus welchem Grund wurde welcher Parameter des Webservers wie eingestellt? Eine Investition in Dokumentation von wenigen Minuten kann darüber entscheiden, wie hoch der Suchaufwand für die geplante Erweiterung des Portals sein wird. Allerdings ist es die Kunst der Dokumentation, vorher zu wissen, was später einmal gebraucht werden wird. Der Bedarf nach Dokumentation entsteht erst nach Projektabschluss.
Es darf wohl als offensichtlich betrachtet werden, dass eine Anforderung unbedingt erfüllt sein muss, um die Chance auf eine gute Dokumentation zu wahren: es muss den Beteiligten leicht fallen, Ergebnisse festzuhalten. Es ist Aufgabe der Projektleitung entsprechende Strukturen vorzubereiten und Systeme bereitzustellen, die genau diesen Effekt erzielen. Wobei damit nur die Chance gewahrt bleibt, dass dokumentiert wird. Eine Garantie auf Dokumentation ist das noch lange nicht.
Wer aufgabengetriebene Kommunikation als Spielregel vereinbart, sorgt für Fortschritt ohne Eingriffe der Projektleitung nötig zu machen.
Anrufe und Nachfragen zum Aufgabenstatus sind Wertschätzung.
136 Projektsteuerung: Das Geplante realisieren Frage Nr. 27: Was dokumentieren wir wie zu welchem Zweck? Die Antwort darauf will gut überlegt sein. Wird zu viel dokumentiert, steigt der Aufwand im Projekt und das Auffinden bestimmter Fakten wird hernach schwieriger. Wird zu wenig dokumentiert, steigt der Aufwand nach dem Projekt für die Rekonstruktion der Projektergebnisse und damit verbundener Informationen. Der Idealfall wäre gegeben, wenn exakt die Dinge dokumentiert werden, die bis zum Ende der Verwendung des Projektergebnisses tatsächlich benötigt werden. Eine Analyse der Verwendung der Projektergebnisse während des Projekts und nach Projektende hilft, die notwendigen und hinreichenden Anforderungen an eine gute Dokumentation zu klären. Über die Aufnahme der gewünschten Dokumentation in die Projektziele sowie der dafür durchzuführenden Tätigkeiten in den Projektplan wird die Dokumentation im Projekt verankert. Die Projektleitung hat darüber hinaus die Aufgabe, die Dokumentation so einfach wie möglich zu machen, um ein gutes Ergebnis zu erreichen.
Wobei bewusst unterschieden werden sollte zwischen den Informationen, die für das laufende Projekt benötigt werden und den Informationen, die für die Zeit nach Projektabschluss aufbewahrt werden sollen. Diese beiden Kategorien haben meist unterschiedliche Zielgruppen und einen anderen Nutzungszeitraum. Entsprechend eignen sich unterschiedliche Arten der Erfassung und Aufbereitung. Informationen für das laufende Projekt sind meist für die Projektsteuerung nötig und werden nach Projektabschluss nur noch selten oder wenn, dann in komprimierter Form benötigt. Sie können als Notizen zu den einzelnen Arbeitspaketen erfasst und mit dem Projektplan gespeichert werden. Damit ist gleichzeitig klar, wer wo was dokumentiert. Denn eine Aufgabe hat einen Verantwortlichen, der damit gleichzeitig die Verantwortung für die Dokumentation der für die Projektsteuerung wesentlichen Daten übernimmt. Die Erfassung als Notiz ist einfach, mit wenig Aufwand verbunden und dort zu finden, wo sie gebraucht wird. Viele Software-Programme bieten eine entsprechende Funktion.
Dokumentation im Projekt verankern Wir haben in Projekten mit zwei Dingen immer wieder gute Erfahrung gemacht, wenn es um Dokumentation von Ergebnissen für die Nachprojektphase ging. Erstens lohnt es sich, die Dokumentation als Ergebnis des Projekts im Projektziel zu verankern. Zweitens macht es Sinn, die Tätigkeiten, die durchgeführt werden müssen, um am Ende des Projekts eine gute Dokumentation in Händen halten zu können, mit in den Projektplan aufzunehmen, wo die Ergebnisse entstehen. Im Beispielprojekt könnte das Projektziel folglich um folgenden Satz ergänzt werden: „... Sämtliche Projektergebnisse sind an einer zentralen Stelle auf Basis einer Verwendungsanalyse dokumentiert, so dass via Intranet darauf zugegriffen werden kann. ...“ Womit zumindest grundsätzlich die Anforderungen an die Dokumentation in den Zielen formuliert sind.
Aus der Anforderung des Ziels lassen sich Element für Element die notwendigen Tätigkeiten ableiten, die durchgeführt werden müssen, um das so ergänzte Projektziel zu erreichen. Ausgangspunkt für eine gute Dokumentation ist zum einen der Projektstrukturplan, der sich gleichfalls als Struktur der Dokumentation anbietet. Jedes Element darin kann hinsichtlich der für Dokumentation notwendigen Tätigkeiten überprüft und ergänzt werden. Zusätzlich lohnt es sich, eine Verwendungsanalyse zu machen, in der systematisch erforscht wird, welche Anwendungsfälle entstehen könnten und welche Anforderungen an Dokumentation diese mit sich bringen.
Den Aufwand für Protokolle gering halten 137
Abbildung 56: Die umrandete Tätigkeit wird aufgenommen, um die Dokumentation sicherzustellen.
Eine Verwendungsanalyse stellt keinen großen Aufwand dar. Oft ist ein einfaches Brainstorming ein guter Einstieg, der durch die oben beschriebene Analyse aller Elemente des Strukturplans ergänzt wird. Dabei ist wichtig, dass sowohl Vorgehensweise wie auch inhaltliche Produkte des Projekts dokumentationswürdige Ergebnisse hervorbringen. In einem weiteren Schritt kann es hilfreich sein, die Stakeholderanalyse (siehe Seite 129) zu nutzen, um die Bedarfe der verschiedenen Gruppen zu identifizieren.
Den Aufwand für Protokolle gering halten Haben Sie das Gefühl, dass Protokolle gelesen und berücksichtigt werden? Viele Projektleiter klagen darüber, dass Protokolle nichts bringen. Was auch nicht verwundert, wenn man in so einigen Projekten die Zeitspanne zwischen Besprechungsende und Eintreffen des Protokolls betrachtet, die durchaus Wochen betragen kann. In diesen Fällen sind die im Protokoll dokumentierten Punkte bereits veraltet, die Mühe war umsonst. Genau genommen sind Protokolle Grenzgänger zwischen Dokumentations- und Informationswerkzeug. Zum einen werden damit beispielsweise Zwischenergebnisse und Entscheidungen festgehalten, zum anderen werden über Protokolle für die Arbeit notwendige Informationen bereitgestellt. Beiden Anforderungen müssen Protokolle damit gerecht werden. Allerdings macht es durchaus Sinn zu überlegen, wie der Aufwand dafür gering gehalten werden kann, ohne den Nutzen zu reduzieren. Ein nützliches Protokoll steht den Besprechungsteilnehmern im Idealfall direkt nach der Besprechung zur Verfügung, damit diese mit den neuen Informationen direkt an ihren Aufgaben weiterarbeiten können. Gleichzeitig ist es sinnvoll, das Protokoll öffentlich zu führen, um dessen Korrektheit noch während des Erfassens sicherzustellen. Das vermeidet Freigabezyklen und damit Verzug. Sehr gute Ergebnisse in der Protokollierung einer Besprechung erzielen wir immer wieder, wenn wir die wichtigen Punkte auf Flipchart oder Pinnwand mitschreiben und diese Ergebnisse direkt im Anschluss als Fotoprotokoll verteilen. Das hält den Aufwand gering, macht eine schnelle Lieferung möglich und erspart manchem Empfänger das Lesen, da die visuelle Darstellung genügt, um den Sachverhalt zu erinnern. Gleichzeitig macht diese Art der Dokumentation die Besprechung besser, da alle aufgrund der zentralen Visualisierung über dasselbe diskutieren und gegebenenfalls sofort korrigierend eingreifen, wenn der Moderator etwas falsch notiert hat. Die Verwendung der öffentlichen Notizen als Protokoll sollte zu Beginn einer Besprechung mit den Teilnehmern vereinbart werden, um Missverständnisse und Konflikte durch abweichende Erwartungen zu vermeiden.
Visualisierung der Besprechungsergebnisse auf Flipchart und schnell bereitgestellte Fotoprotokolle sorgen für bessere Besprechungen sowie frühe Verfügbarkeit von Besprechungsergebnissen und reduzieren den Aufwand für die Projektleitung.
138 Projektsteuerung: Das Geplante realisieren Wichtig ist allerdings, dass nicht nur Stichworte mitgeschrieben werden, da diese zu unterschiedlichen Interpretationen führen. Ganze, klar verständliche Sätze ergänzt um eindeutige, gegebenenfalls vereinbarte Symbole sind hilfreich für das Verständnis. Durchgehend verwendete Symbole können es beim Lesen leichter machen, etwa Entscheidungen und Aufgaben schnell zu erkennen. Symbole innerhalb eines Texts stechen hervor und lenken so die Aufmerksamkeit. So könnten im Beispielprojekt Verantwortlichkeiten immer in rechteckigen Klammern erfasst werden, Aufgaben mit Rauten gekennzeichnet, Entscheidungen mit einem „E“ in einem Kreis und offene Fragen mit einem Fragezeichen in einem Dreieck.
Protokollinhalte
Technisch betrachtet ist ein Mitschreiben mittels PC und Projektor sicherlich auf den ersten Blick produktiver. Allerdings führt die Projektion auf eine Leinwand zum einen häufig dazu, dass alle eher auf die Wand starren als miteinander zu reden. Zum anderen, vor allem wenn noch gedämpftes Licht dazu kommt, ist die Dynamik der Besprechung eine ganz andere. Das können Sie in jeder Besprechung selbst beobachten. Eine Standardisierung der Protokollinhalte macht sich schnell bezahlt, da der Aufwand für das Erstellen und das Lesen sinkt. Neben dem Besprechungstitel gehören Angaben zu den Teilnehmern sowie das Datum der Besprechung zu den Mindestangaben des Protokolls. Je Themenblock hat sich folgende Struktur vielfach bewährt: • Thema • Leitfrage(n) • Diskussion • Entscheidung samt Begründung • Weiteres Vorgehen Die Leitfragen stellen an dieser Stelle einen kleinen Ausflug in die Moderationstechnik dar. Dadurch, dass der Besprechungsleiter diese Leitfragen vorab definiert und öffentlich bekannt gibt, lenkt er die Diskussion zielorientiert. Wird etwa über das Thema „Anforderungen an das Webportal“ diskutiert, könnten die Leitfragen lauten: „Welche Anforderungen muss das Webportal unbedingt erfüllen? Welche soll es erfüllen? Welche müssen nicht erfüllt werden?“
Offene Fragen als Leitfragen machen mehr Sinn als geschlossene, wenn eine Diskussion in Gang gebracht werden soll. Außerdem dienen Leitfragen gleichzeitig dem besseren Verständnis des Protokolls, wenn diese dort mit aufgeführt sind. Darüber hinaus ist das Erfassen der Begründung von Entscheidungen im Protokoll wichtig, da diese zwar am Ende einer Besprechung noch vollkommen klar und logisch ist, jedoch nach einem halben Jahr vergessen.
Protokolle sind keine Steuerungsinstrumente Unter der Annahme, dass es sich bei einem Vorhaben um ein echtes Projekt handelt, ist für Protokolle eine Aussage wichtig: Aufgaben haben in Protokollen nichts zu suchen, außer zur Dokumentation einer Besprechung. Protokolle sind keine Werkzeuge zur Steuerung eines Projekts, da über Protokolle kein Gesamtüberblick über ein Vorhaben hergestellt werden kann.
Das Entscheidungsbuch 139
Die Verwendung von Protokollen als Instrument der Aufgabensteuerung führt meist dazu, dass kein Projektplan eingesetzt wird, da diese als Doppelung der Arbeit gesehen wird. Terminvorgaben für die Erledigung von Aufgaben werden dann schnell willkürlich gesetzt, da deren Angabe im Protokoll notwendig erscheint. Diese willkürliche Terminzuordnung führt dazu, dass diese Termine nicht akzeptiert und Aufgaben verspätet abgeliefert werden. Wer Termine für Aufgaben festsetzen will, muss den kritischen Pfad (siehe Seite 82 f.) kennen, der sich nur aus einer auf Logik basierten Projektplanung ableiten lässt. Logikbasierte Terminplanung führt zu Akzeptanz und diese Akzeptanz dazu, dass Teammitglieder sich mit höherer Wahrscheinlichkeit an Terminzusagen halten. Sie erkennen die Sinnhaftigkeit und Notwendigkeit. Wer erreichen will, dass Teammitglieder ihre Aufgaben pünktlich erledigen, sollte auf keinen Fall Protokolle zur Aufgabenverfolgung und Terminsteuerung einsetzen. In einigen Verlagen ist es Routine, bei der nächsten Projektbesprechung das Protokoll der vergangenen Besprechung hervorzukramen und die darin festgelegten Tätigkeiten zu diskutieren. Sobald dies geschieht, gerät ein eventuell vorhandener Projektplan schnell in Vergessenheit, da Protokolle weit weniger komplex erscheinen. Allerdings ist zu bedenken, dass das Projekt durch die Reduktion auf Protokolle nicht an Komplexität verliert. Es ist lediglich nur ein kleinerer Teil der Komplexität sichtbar und damit der unsichtbare Teil nur schwer zu steuern. Wer sich entschieden hat, mit Projektplänen zu arbeiten, dem empfehle ich nachdrücklich, Protokolle nicht als Steuerungsinstrumente zu verwenden. Die Aufgaben werden im Protokoll lediglich zur Dokumentation von Besprechungsergebnissen erfasst. Anschließend werden sie im Projektplan dokumentiert, wobei sich in der Praxis regelmäßig zeigt, dass die in Besprechungen diskutierten Tätigkeiten meist lediglich eine Präzisierung bereits im Plan erfasster Arbeitspakete oder Aufgaben handelt. Diese Ergänzungen können in den Notizen zur Aufgabe erfasst werden, wobei – geeignete Systeme vorausgesetzt – ein Verweis oder Link auf das zugehörige Protokoll oft sinnvoll und ausreichend sind.
Das Entscheidungsbuch Im Verlauf selbst kleinerer Projekte werden von unterschiedlichen Personen und Personengruppen unzählige Entscheidungen getroffen, die sowohl den Projektverlauf wie auch die Nutzungsphase nach Projektabschluss beeinflussen. Nicht selten fällt es schwer, den Überblick über diese Vielzahl der Entscheidungen zu behalten oder gar nach dem Projekt zu rekapitulieren, warum welche Entscheidung wie getroffen wurde. Das Entscheidungsbuch sorgt an diesen Stellen für Abhilfe. Es handelt sich schlicht um ein Dokument, das sämtliche Entscheidungen samt Begründung, Datum der Entscheidung und beteiligten Personen auflistet. Um den mit der Erstellung und Pflege sowie den mit der Recherche nach bereits getroffenen Entscheidungen verbundenen Aufwand klein zu halten, werden die jeweiligen Passagen aus den Protokollen hier zusammengeführt. Je nach Projektgröße handelt es sich um eine einfache, fortlaufende Erfassung der Entscheidungen oder ein auf Grundlage des Projektstrukturplans strukturiertes Dokument. Den Bezug zu den Arbeitspaketen des Projektstrukturplans herzustellen, lohnt sich auf jeden Fall. Wobei das Entscheidungsbuch ein Grenzgänger zwischen den Disziplinen Projektdokumentation und Projektkommunikation darstellt, da es Zwecken beider Kategorien dient.
Ein Entscheidungsbuch hilft den Überblick über Entscheidungen zu behalten.
140 Projektsteuerung: Das Geplante realisieren Das Projekttagebuch
Symbole und Stichworte helfen, die gesuchten Informationen schneller zu finden.
Dieses Dokument fällt, wie das Entscheidungsbuch, ebenfalls in die Rubrik Grenzgänger zwischen Projektdokumentation und -kommunikation. Während das Entscheidungsbuch gezielt einen Überblick über sämtliche Entscheidungen herstellen soll, wird im Projekttagebuch der chronologische Verlauf des Projekts beschrieben. Je nach Verteilerkreis der Informationen können sich Entscheidungsbuch und Projekttagebuch ergänzen oder sämtliche Entscheidungen im Projekttagebuch mit aufgeführt werden. In letzterem Fall bietet es sich an, die Entscheidungen etwa durch Symbole oder Stichworte so zu kennzeichnen, dass diese leicht zu identifizieren sind. Sonst besteht die Gefahr, dass Entscheidungen übersehen werden und dadurch unnötig zusätzlicher Aufwand entsteht. Ursprünglich war das Projekttagebuch ein Dokument, das der Projektleiter führt. Aufgrund der Entwicklungen in der Informationstechnologie gehen allerdings immer mehr Projektteams dazu über, ein gemeinsames Projekttagebuch zu führen, zu dem jeder Projektbeteiligte nach vereinbarten Spielregeln und Konventionen beiträgt. In diesem Fall ist es Aufgabe der Projektleitung, für geeignete Spielregeln und Konventionen zu sorgen und diese durchzusetzen.
Risiken für Verlag und Projekt im Griff behalten Risikoanalyse ist ein zyklisches Instrument
Risikoanalyse: Als zyklisch eingesetztes Instrument stellt es sicher, dass möglichst viele Unwägbarkeiten möglichst früh identifiziert werden, so dass noch Handlungsspielraum besteht.
Die Risikoanalyse spielt gerade beim Projektstart eine zentrale Bedeutung (siehe Seite 43 f.). Zum einen hilft sie in der Anfangsphase, das Projekt besser zu verstehen und so zu besseren Zielen und Projektplänen zu kommen. Zum anderen fördert die mit einer Risikoanalyse einhergehende Diskussion der Beteiligten deren Zusammenwachsen zu einem Team. Diese anfängliche Risikoanalyse stellt jedoch nur einen ersten Schritt in punkto Risikomanagement dar. Über die gesamte Projektlaufzeit hinweg wird die Risikoanalyse zyklisch wieder und wieder durchgeführt, um aktuellen Entwicklungen und Erkenntnissen im Projekt Rechnung zu tragen. Frage Nr. 28: Wie stellen wir die Risikoüberwachung sicher? Risikomanagement besteht im Grunde genommen aus drei Schritten: Risiken erkennen, Risiken bewerten und Risiken vermeiden beziehungsweise deren Folgen lindern. Eine Bewertung von Risiken wird durchgeführt, um dadurch die bedeutenden Risiken identifizieren zu können. Durch Gegenmaßnahmen wird sichergestellt, dass die Risiken entweder gar nicht erst eintreten oder, falls doch, deren Wirkung handhabbar bleibt. Nach der Erstanalyse beim Projektstart werden diese Schritte während der gesamten Projektlaufzeit zyklisch wiederholt, wobei es sich lohnen kann, eine Person aus dem Projektmanagement-Team gezielt dafür verantwortlich zu machen. Durch diesen offiziellen Auftrag hat dieser Risikomanager das Recht, ja geradezu die Pflicht, Risiken anzusprechen. Dieser explizite Auftrag an die Person dient der Akzeptanz ihrer Einwände. Und Akzeptanz ist eine wesentliche Voraussetzung für ein funktionierendes Risikomanagement.
Der Risikomanager als Moderator Die für das Risikomanagement verantwortliche Person wird üblicherweise damit zu kämpfen haben, dass sie für alles Negative geradestehen muss. Um diesen Effekt zu
Gültige Konfiguration und Änderungsanträge 141
vermeiden, ist eine öffentliche Rollenklärung sehr wichtig. Es muss allen Beteiligten klar sein, dass Risikominimierung eine Aufgabe aller Beteiligten ist. Der Risikomanager führt die Daten zusammen und sorgt dafür, dass die zur Risikoanalyse und -minimierung notwendigen Instrumente zur Verfügung stehen. Darüber hinaus stellt er sicher, dass der Punkt „Risikominimierung“ regelmäßig auf der Agenda der Projektbesprechungen steht. Die wiederholte Diskussion von Risiken unter den der Beteiligten ist insofern wichtig, da sie das Risikobewusstsein und -verhalten des Teams verbessert. Dabei bietet es sich an, dass er die Moderation dieser Besprechungsteile sowie die geeignete Dokumentation übernimmt. Für die Erledigung der Gegenmaßnahmen zeichnen einzelne Personen aus dem Projektteam verantwortlich, keinesfalls ausschließlich der Risikomanager. Eine systematische und wiederholte Risikoanalyse hat darüber hinaus Signalwirkung an das Projektteam. Dadurch wird immer wieder klar gestellt, dass auch Bedenken erwünscht sind, sofern wo sinnvoll und nötig mit Gegenmaßnahmen darauf reagiert wird. Erfahrungsgemäß kommen dadurch kritische Punkte schneller zur Sprache, was dem Projektteam mehr Handlungsmöglichkeiten gibt. Je früher Risiken bekannt sind, desto größer ist deren Beeinflussbarkeit sowie die Beeinflussbarkeit eventueller Maßnahmen zur Schadenslinderung.
Risiken für Projekt und Verlag sind relevant In Risikodiskussionen hören wir häufig die Frage, um welche Risiken es bei der Betrachtung geht. Wir antworten dann: „Um alle.“ Risiken von vorneherein auszuklammern, kann getrost als „gefährlich“ bezeichnet werden. Jedes Risiko – und klingt es noch so bescheiden – sollte in die Liste der Risiken aufgenommen werden. Je ursächlicher die Risiken sind, desto greifbarer werden sie häufig. Allerdings gibt es grundsätzlich Risiken für das Projekt und Risiken für die Unternehmung. Manche Projektteams führen für beide Wirkungsfelder Bewertungen durch, um sicherzustellen, dass alle Aspekte der Risikobetrachtung diskutiert wurden. In diesem Fall werden zur beschriebenen Risikoanalyse (siehe Seite 46) lediglich zwei weitere Bewertungsspalten hinzugefügt, in denen die Risiken hinsichtlich Wahrscheinlichkeit und Auswirkungen auf den Verlag als Unternehmung stattfindet, während die bereits verwendeten Spalten sich auf Wahrscheinlichkeit und Wirkung hinsichtlich des Projekts konzentrieren.
Änderungen im Projektverlauf Gültige Konfiguration und Änderungsanträge Grundsätzlich gibt es drei Kategorien von Abweichungen gegenüber dem Projektplan, die umgangssprachlich als „Änderungen“ bezeichnet werden: a. Abweichungen gegenüber dem Projektplan, die sich etwa aufgrund Schätzungenauigkeiten ergeben (bspw. eine Aufgabe dauert länger als geplant). Diese werden im Rahmen der Projektsteuerung bearbeitet. b. Abweichungen, die sich aufgrund des Eintretens von Risiken ergeben (bspw. der Ausfall eines Autors). Diese werden entsprechend den Ergebnissen der zyklischen Risikoanalyse aufgegriffen.
142 Projektsteuerung: Das Geplante realisieren c. Änderungen, die aufgrund zusätzlich benötigter Zielbestandteile oder zusätzlicher Anforderungen an das Ergebnis notwendig werden. Diese werden im Rahmen des Änderungsmanagements bearbeitet, um das es in diesem Kapitel geht. Gerade letztere Rubrik führt nicht selten dazu, dass Projekte länger dauern und mehr kosten als ursprünglich angenommen. Das Projektteam erkennt nicht, dass die Anforderungen an das Ergebnis immer weiter steigen. Steigende Anforderungen führen fast zwangsläufig dazu, dass mehr Aufwand betrieben werden muss, als zu Beginn kalkuliert. Deshalb ist es wichtig, steigenden Anforderungen Einhalt zu gebieten oder entsprechend mehr Zeit, Ressourcen und Budget zugestanden zu bekommen. Dieser Teil des Projektmanagements hat einen engen Bezug zur Qualitätssicherung, deren Ausgangsbasis eindeutige Anforderungen sind. Frage Nr. 29: Wie gehen wir mit Änderungen um? Grundlage jedes Änderungsmanagement ist die gültige Konfiguration der Anforderungen an ein Ergebnis. Diese müssen eindeutig definiert und für alle Beteiligten erkennbar sein. Dieser gültigen Version der Anforderungen werden Änderungswünsche gegenübergestellt, die im ersten Moment auch als Wünsche behandelt werden sollten und in Änderungsanträgen erfasst werden. Für jeden Wunsch in Form eines Änderungsantrags wird systematisch überlegt, welche zusätzlichen Mittel dafür aufgewendet werden müssen und welche Auswirkungen dies auf den weiteren Projektverlauf haben wird. Der gültige Projektplan ist für eine solche Simulation die Grundlage. Auf Basis dieser Erkenntnisse wird von den im Rahmen der Rollenklärung dafür kompetenten Personen entschieden, ob und unter welchen Bedingungen die neuen Anforderungen angenommen oder abgelehnt werden. Wird eine Änderung angenommen, wird der Projektplan entsprechend angepasst, so dass die Bearbeitung der Änderungen im Rahmen der üblichen Projektsteuerung erfolgt. Eine zusätzliche Liste zur Verfolgung der Änderungen ist damit nicht mehr notwendig.
Der gültige Katalog der Anforderungen Spätestens mit der Definition der Projektziele wird das erste Mal im Projektverlauf über Anforderungen an das Ergebnis des Projekts entschieden. Spätestens ab diesem Zeitpunkt muss sichergestellt sein, dass sich jeder an diese Anforderungen hält, damit Teilergebnisse am Ende zueinander passen. Dies setzt mindestens voraus, dass jedem Mitstreiter der aktuelle Katalog der Anforderungen bekannt ist oder er diesen bei Arbeitsaufnahme in Erfahrung bringen kann. Über die Zuordnung von Versionsnummern zu Dokumenten wird die Grundvoraussetzung geschaffen, Dokumente eindeutig identifizieren zu können. Darüber hinaus hilft die Statusangabe innerhalb des Dokuments, die Relevanz eines Dokuments beurteilen zu können. So gibt es grundsätzlich den Status „Entwurf“ sowie den Status „Freigegeben“. Je nach Art und Weise der Dokumentsteuerung kann dazu der Status „Revidiert“ oder „Freigabe aufgehoben“ kommen, sobald es eine neuere freigegebene Version ein und desselben Dokuments gibt. (Siehe hierzu auch die Kapitel „Qualität bedeutet vereinbarte Anforderungen zu erfüllen“ und „Anforderungen eindeutig halten“, Seite 109). Das Verlassen auf den Status eines Dokuments ist allerdings nicht genug und kann nur einen ersten Hinweis geben, da erfahrungsgemäß immer lokale Kopien von Dokumenten vorhanden sind. Spätestens dort ist es kaum mehr möglich, die Statusangabe zu verändern. Deshalb wird darüber hinaus eine zentrale Übersicht benötigt, die den aktuellen Stand der Anforderungen eindeutig widerspiegelt. In vielen Fällen genügt ein zentral verfügbares Dokument, das eine Liste der gültigen Dokumente mit Anforderungen liefert. Dieses Dokument sollte allerdings, so hat es die Praxis gezeigt, lediglich schreibgeschützt bereitgestellt werden. Dokumentenmanagementsysteme können diese Arbeit vereinfachen. Allerdings zeigt sich in der
Auswirkung von Änderungen auf bereits vorliegende Ergebnisse 143
Praxis immer wieder, dass diese zwar die Versionsverwaltung erleichtern, allerdings die zentrale Stelle zur Information über aktuelle Anforderungen vom System nicht geliefert wird. Wird mehr als eine Person für die Pflege der Übersicht aktueller Anforderungen verantwortlich gemacht, führt das üblicherweise zu Verwirrung. Ein Stellvertreter ist für den Krankheitsfall sicherlich nötig. Er sollte allerdings ausschließlich dann oder nach Absprache einspringen.
Der Änderungsantrag als Grundlage aller Anpassungen der Anforderungen Die Grundregel, um Änderungen an den Anforderungen im Griff zu behalten, ist simpel: Jeder Änderungswunsch erfordert einen Änderungsantrag, jeder Änderungsantrag eine Genehmigung, jede Genehmigung eine Information an alle Beteiligten sowie die Anpassung des Projektplans. Auf keinen Fall sollten Änderungswünsche ohne Änderungsantrag aufgenommen werden. Sonst droht das Scheitern des gesamten Vorhabens, da der Aufwand nicht mehr geleistet werden kann. Der Änderungsantrag stellt grundsätzlich die Schriftform eines Änderungswunsches dar. Er enthält mindestens Angaben zum Autor, eine Beschreibung des Änderungswunsches sowie des Nutzens, der von der Änderung erwartet wird. Außerdem sind Angaben zum Bearbeitungsstatus hilfreich. Ich halte darüber hinaus Rubriken zu den erwarteten Auswirkungen auf den weiteren Projektverlauf für nützlich. Diese sind jedoch sicherlich nicht zwingend notwendig. Man kann sich trefflich streiten, wer einen Änderungsantrag stellen darf, ob etwa auch Außenstehende dazu berechtigt sind. In Anbetracht der Tatsache, dass diese in Ermangelung der Möglichkeit selbst einen Antrag stellen zu können eben ihre Kontakte ins Projektteam nutzen, um Änderungsanträge über Dritte einzureichen, ist diese Diskussion müßig. Viel wichtiger ist es, sich im Klaren zu sein, wer Änderungsanträge verwaltet und wer darüber entscheiden darf, ob diese zu Änderungen im Projekt führen oder nicht. Eine entsprechende Klärung der Kompetenzen erfolgt im Rahmen der Rollenklärung (siehe „Erwartungen, Kompetenzen, Spielregeln“, Seite 119).
Auswirkung von Änderungen auf bereits vorliegende Ergebnisse Sicherzustellen, dass jeder Beteiligte bei Aufnahme einer Arbeit am Projekt den korrekten Stand der Anforderungen verwendet, ist notwendig jedoch nicht hinreichend, um am Ende zueinander passende Teilergebnisse zu haben. Von jeder Änderung können auch vergangene Ergebnisse betroffen sein und deren Überarbeitung nötig werden. Im Beispielprojekt „Neue Buchreihe mit Webportal“ wird innerhalb der Teilaufgabe „Webportal“ ein Server ausgewählt und installiert (siehe hierzu Projektstrukturplan auf Seite 73). Nehmen wir an, dass für diesen anfangs als Anforderung benannt wurde, dass er mindestens über Version 4 der Datenbanksoftware verfügen muss. Nehmen wir weiter an, dass der Server bereits gemietet und installiert wurde. Nun wird im Projektverlauf festgestellt, dass zusätzliche Funktionen nötig werden und diese lediglich über die inzwischen freigegebene Version 5 der Datenbanksoftware realisiert werden können. Wird der entsprechende Änderungsantrag freigegeben, muss das bereits vorliegende Ergebnis „Installierter Server mit Datenbanksoftware 4“ nochmals bearbeitet werden, so dass das Ergebnis „Installierter Server mit Datenbanksoftware Version 5“ vorliegt, sobald die entsprechenden Programmieraufgaben aufgenommen werden. Ohne diese Anpassung bereits vorliegender Ergebnisse würden zukünftige Arbeiten nicht verwendbare Ergebnisse liefern.
144 Projektsteuerung: Das Geplante realisieren Anpassung des Projektplans an geänderte Anforderungen
Wer in frühen Phasen Wert auf möglichst klare Anforderungen legt, reduziert den Aufwand durch Änderungen in späteren Projektphasen.
Jeder Änderungsantrag führt zu zusätzlichen oder geänderten Tätigkeiten im Projekt. Diese müssen, wie alle anderen Tätigkeiten, auf Ressourcen verteilt und deren Durchführung sichergestellt werden. Um eine separate Steuerung dieser Änderungen und damit Aufwand auf Seiten des Projektmanagements zu vermeiden, werden sämtliche Anpassungen an Tätigkeiten, Ressourcen etc. in den Projektplan aufgenommen. Dieser erhält entsprechend eine höhere Versionsnummer, wobei die entsprechende Version des Projektplans nach Freigabe in der Übersicht gültiger Dokumente als gültig geführt wird. Bei den Anpassungen kann es sich sowohl um simple Notizen handeln, die eine Tätigkeit näher beschreiben, und schlichte Anpassungen der Dauer einer Tätigkeit bei vorhandenen Ressourcen, wie auch um die Neuplanung ganzer Bereiche des Projekts. Da der Aufwand für derartige Umplanungen beträchtlich sein kann, ist es nur logisch, dass wohlüberlegt werden sollte, ob Änderungen überhaupt aufgenommen werden. Hinzu kommen zusätzliche Konflikte mit anderen Projekten, etwa wenn diese auf dieselben Ressourcen zugreifen. Diese Engpässe können verlagsweite Umplanungsaufwände hervorrufen, die so manche Änderung nicht mehr lohnenswert machen. Gleichzeitig wird so auch die Bedeutung guter Anforderungskataloge sichtbar. Gelingt es, die Anforderungen von Anfang an so zu definieren, dass wenig ergänzungsbedürfte Lücken existieren und kommende Entwicklungen bereits antizipiert werden, reduziert sich der Projektaufwand beträchtlich – bei vermutlich besserem Projektergebnis. Dass dies vollkommen gelingt, kann als Utopie betrachtet werden. Allerdings sollte Mühe darauf verwendet werden, um nicht bereits bekannte und ersichtliche Anforderungen zu übersehen.
Kommunikation von Änderungen Im Rahmen des Änderungsmanagements verdient die Kommunikation von Änderungen besondere Beachtung. Erfährt ein Mitarbeiter von einer Änderung nicht oder erst sehr spät, liefert er eventuell nicht oder nur teilweise brauchbare Ergebnisse, da er mit alten Anforderungsständen weiterarbeitet. Die Korrektur kann dann neben zusätzlichem Aufwand auch einen Qualitätsverlust mit sich bringen. Im einfachsten Fall ist die Regelkommunikation so strukturiert, dass in deren Rahmen Änderungen auf natürliche Art und Weise kommuniziert werden können. Trotzdem empfiehlt es sich, Änderungen sowie deren Auswirkungen immer auch hinsichtlich der davon betroffenen Personen zu untersuchen. So können diese gezielt über Anpassungen informiert werden. Festzuhalten bleibt, dass das Auftreten von Änderungen gegenüber der ersten Annahme der Normalzustand in Projekten ist. Änderungen werde oft als negativ betrachtet. Genau genommen sind Änderungen eher positiv zu werten, denn über Änderungen wird der Erkenntniszugewinn der Beteiligten in das Projekt aufgenommen. Das Projektmanagement-System muss der Tatsache Rechnung tragen, dass Änderungen normal sind, indem es darauf ausgelegt ist, sämtliche Änderungen systematisch und mit möglichst wenig Mühe bearbeiten zu können.
Der Projektabschluss Übergabe an die Linienorganisation Bevor ein Projekt abgeschlossen werden kann, muss die weitere Verwendung der im Rahmen der Projektarbeit erstellten Ergebnisse sichergestellt werden. Dazu werden die Projektergebnisse üblicherweise an die Linienorganisation übergeben. So wird etwa ein im Rahmen eines Projekt erstelltes und eingeführtes IT-System an die IT-Abteilung zur Wartung und Pflege übergeben. Ebenso das im Beispielprojekt erstellte und eingeführte Webportal. Die weitere Pflege der Inhalte muss dazu standardisiert und in einen Routineprozess überführt werden. Sämtliche Verantwortung muss definiert und vereinbart sein. Die Grenze des Verantwortungsbereichs des Projektteams wurde dazu im Rahmen der Projektziele definiert.
Frage Nr. 30: Wie werden wann wem welche Projektergebnisse mit welchen Konsequenzen übergeben? Dieser Schritt stellt sicher, dass die Projektergebnisse weiter Verwendung finden. Entsprechend wichtig ist er. Wobei das Grundsätzliche dieser Übergabe sowie die Grenze der Verantwortung des Projektteams bereits im Rahmen der Projektziele definiert werden, da eine Übergabe im Rahmen der Projektbearbeitung vorbereitet werden muss. Letztlich geht mit der Übergabe die Verantwortung an die Linienorganisation über. Die nach Projektende verantwortlichen Mitarbeiter werden üblicherweise mindestens in der Anlaufphase der Übernahme von den Mitgliedern des Projektteams unterstützt. Schließlich haben diese im Laufe des Projekts viel Know-how und Erfahrung sammeln können. Dieses Wissen gilt es nun zu übertragen. Um sicherzustellen, dass alle betroffenen Personen denselben Kenntnisstand haben, ist es empfehlenswert, den Übergang der Verantwortung formal zu vollziehen, zu dokumentieren – etwa in Form eines Übergabeprotokolls – und offiziell zu kommunizieren.
Nicht selten wird die Übergabe von Projektergebnisse nicht systematisch genug vorbereitet und durchgeführt. Das führt dann meist dazu, dass der Projektleiter weiter in der Verantwortung steht, obwohl er bereits andere Aufgaben übernehmen sollte. Weder für den Projektleiter noch für die übernehmende Abteilung und das Unternehmen ist dieser Zustand zufriedenstellend. Wie alle anderen Tätigkeiten im Projekt, werden sämtliche Aktivitäten der Übergabe bereits während der Projektplanung berücksichtigt. Insofern stellt die Übergabe in manchen Unternehmen die letzte Phase im Projekt dar und wird als solche ausgewiesen. Die übernehmenden Abteilungen sind wichtige Stakeholder im Projekt und sollten bereits während der Planung eingebunden und während des Projektfortschritts regelmäßig über den Stand der Dinge informiert werden, um ein Mindestmaß an Akzeptanz der Ergebnisse sicherzustellen.
Aus Projekten lernen Erfahrung wird zum strategischen Wettbewerbsvorteil Die in Projekten gewonnene Erfahrung ist für ein Unternehmen von unschätzbarem Wert. Gelingt es, dieses Wissen für zukünftige Projekte zu nutzen, kann daraus ein strategischer Wettbewerbsvorteil für einen Verlag entstehen, etwa wenn es dadurch gelingt, neue Geschäftsmodelle oder Technologien schneller und sicherer als die Wettbewerber für das eigene Haus zu nutzen. Deshalb ist die systematische Siche-
Aus der Projektarbeit gesammelte Erfahrung kann zu einem strategischen Wettbewerbsvorteil für einen Verlag werden.
146 Der Projektabschluss rung der Erfahrung ein wichtiger Schritt zur Vorbereitung des formalen Projektabschlusses. Frage Nr. 31: Wie sichern und nutzen wir die Erfahrung aus dem Projekt für unser Unternehmen? Zur Erfahrungssicherung gehört unter anderem die Dokumentation von Echtdaten und Erfahrungswerten. Diese gilt es so zu dokumentieren, dass diese von zukünftigen Projektteams leicht genutzt werden können. Neben dieser Sammlung von Zahlen, Daten und Fakten hat sich ein subjektiver Bericht der Projektleitung bewährt, der Erfahrungen aus der Perspektive der Projektleitung wiedergibt und in dem daraus Empfehlungen für zukünftige Projekte abgeleitet werden. Außerdem wird eine Sammlung der „Lessons Learned“ durch das Projektteam häufig als sehr nützlich bewertet. Wobei das Erfassen dieser „gewonnenen Erkenntnisse“ alleine nicht genügt, denn schließlich hilft dieses Wissen nur, wenn andere darauf Zugriff haben und von dieser Zugriffsmöglichkeit auch wissen.
Fakten und Subjektives sind wichtig
Subjektiver Bericht der Projektleitung
Während der Projektplanung ist es zum Beispiel hilfreich zu wissen, wie viele Korrekturschleifen typischerweise eingeplant werden müssen, bis Freigaben erteilt werden. Solche Informationen sind es, die aus der Erfahrung eines oder mehrerer Projekte extrahiert werden können, um die Qualität der Planung nachfolgender Projekte zu erhöhen. Auch Vorlagen, etwa eines Projektstrukturplans, für ähnlich gelagerte Vorhaben sparen sehr viel Aufwand und Mühe. Sie sind außerdem ein erster, wichtiger Schritt in Richtung Standardisierung von Projektmanagement. Gelingt es für bestimmte Vorhaben oder Teilen davon Routineprozesse zu definieren und einzuführen, erhöht dies die Produktivität. Neben den sachlichen Informationen hilft das subjektive Wissen der Projektleitung, zukünftige Projekte gut zu organisieren. • Welche Projektmanagement-Werkzeuge waren besonders hilfreich? • Worauf sollte besonders geachtet werden? • Was hat nicht gut funktioniert? • Welche Empfehlungen gibt es? Die Antworten auf diese Fragen, zusammengefasst in einem bewusst subjektiv gehaltenen Erfahrungsbericht der Projektleitung, sind für zukünftige Projektleiter meist von sehr großem Wert. Das Augenmerk liegt besonders auf Projektmanagement-Werkzeugen und der organisatorischen Sicht auf das Vorhaben. Potenzielle Nutzer müssen über die Verfügbarkeit eines entsprechenden Berichts informiert werden und außerdem auch zu einem späteren Zeitpunkt Zugriff darauf haben.
Gesammelte Erfahrung des Teams nutzen
Lessons Learned
Ebenfalls als sehr wertvoll wird die gesammelte Erfahrung des Teams eingeschätzt. Diese „Lessons Learned“ können auf einfachem Wege in einem entsprechenden Workshop gesammelt werden: • Was ist gut gelaufen? • Was ist nicht gut gelaufen? • Worin liegen Chancen für zukünftige Projekte? • Wo sind Risiken zu finden? • Welche Erkenntnisse nehmen wir aus diesem Projekt mit? • Welche Empfehlungen lassen sich daraus für zukünftige Projekte ableiten?
Ein offizieller Abschluss spart Aufwand 147
Entlang dieser Fragen wird der Projektverlauf reflektiert. Bei größeren Projekten lohnt sich ein differenzierter Blick Phase für Phase, um nicht zu oberflächlich zu bleiben. Wobei es nicht zwanghaft darum geht, ein einheitliches Votum der Gruppe zu erzielen. Gerade verschiedene Sichtweisen helfen, ein Projekt besser zu verstehen. Diese sollten entsprechend im Protokoll gekennzeichnet sein.
Der formale Projektabschluss Ein offizieller Abschluss spart Aufwand Der formale Projektabschluss ist der allerletzte Schritt im Projekt. Nach Entlastung und Auflösung des Teams arbeitet kein Mitglied des Projektteams mehr an irgendwelchen Aufgaben. Was nicht bedeutet, dass nicht dieselben Personen mit dem Ergebnis weiterarbeiten, was manches Mal zur Verwirrung führt. In unserem Beispielprojekt „Neue Buchreihe mit Webportal“ wird als Ergebnis unter anderem ein funktionsfähiges Webportal samt Pflege- und Wartungsprozess an die Routineorganisation übergeben. Nun kann es durchaus sein, dass ein Redakteur während der Projektlaufzeit für das Projektteam abgestellt war, der redaktionelle Arbeiten am Webportal übernommen hat. Dieser Redakteur kann durchaus nach Abschluss des Projekts weiterhin für die Inhalte und die Pflege des Portals verantwortlich sein. Er ist dann allerdings nicht mehr Teil des Projektteams, sondern hat diese sich aus dem Projekt ergebenden, neuen Tätigkeiten im Rahmen seiner Arbeitsstelle in der Routineorganisation des Verlags übernommen. Er bearbeitet nun Themen auf Basis des im Rahmen des Projekts entwickelten und freigegebenen Routineprozesses. Es gibt keine Notwendigkeit mehr, seine Arbeit separat zu organisieren, da das Projekt beendet ist.
Diesen Punkt des Abschlusses versäumen viele Projektteams, da die Personen im Projekt und für die Arbeit danach dieselben sind, wenn diese auch während und nach dem Projekt in verschiedenen Rollen arbeiten. Die Arbeit geht dann beispielsweise für den Redakteur nahtlos in den Routinebetrieb über. Nicht selten werden in solchen Fällen Elemente der Projektorganisation weiter beibehalten, etwa ein Jour Fixe, obwohl diese aus organisatorischer Sicht in einem Routineprozess so nicht mehr nötig sind. Solche Effekte produzieren unnötig Arbeitslast und damit Aufwand. Um derartige Effekte zu vermeiden, ist ein formaler Projektabschluss nötig. Außerdem wird mit dem formalen Abschluss auch die Führungsverantwortung klar. Bis zum Projektende hat die Projektleitung im vereinbarten Rahmen Zugriff auf die Mitglieder des Projektteams. Dieser Zugriff besteht nach dem formalen Abschluss nicht mehr. Lediglich die Führungskraft in der Linie hat dann noch die Möglichkeit, Aufgaben an das ehemalige Projektteammitglied zu delegieren. Frage Nr. 32: Wie schließen wir das Projekt ab? Damit Projekte nicht im Sande verlaufen oder schlicht das Projektpersonal eine Sache weiterhin betreuen muss, ist ein formaler Projektabschluss nötig. Dieser wird am einfachsten im Rahmen einer Projektabschlusssitzung vollzogen, die den Endpunkt der Arbeit am Projekt markiert. Im Rahmen dieser Abschlusssitzung wird das Projektteam durch den Auftraggeber oder das Lenkungsgremium entlastet und aufgelöst. Außerdem bietet es sich an, diese Gelegenheit mit einem Dankeschön und einer Feier des Erfolgs zu verbinden. Eine Angelegenheit, die sich viele Projektteams vornehmen, die erfahrungsgemäß jedoch nur wenige nutzen.
148 Der Projektabschluss Übergang der Verantwortung kann auch rechtlich relevant sein Spätestens mit der Entlastung des Projektteams endet auch dessen Verantwortung für die Projektergebnisse, was auch rechtliche Bedeutung haben kann. So sind zum Beispiel Konstellationen denkbar, in denen während der Projektlaufzeit des Projektteam die rechtliche Verantwortung für den Inhalt des Webportals hat und entsprechend als „Inhaltlich Verantwortlicher“ im Impressum aufgeführt ist. Nach Projektende übernimmt diese Verantwortung die Routineorganisation, was etwa zu einer Änderung der Impressumsangaben führen kann.
Spätestens im Rahmen des formalen Projektabschlusses werden diese Übergaben offiziell dokumentiert, so dass keine Zweifel über Verantwortungsbereiche bestehen bleiben. Das sorgt gleichzeitig dafür, dass Missverständnisse und Reibungsverluste etwa durch vermeintliche doppelte Zuständigkeiten oder Lücken in der Verantwortung vermieden werden.
Eine Abschlussfeier gehört dazu
Es ist keine Selbstverständlichkeit, dass ein Projekt ein Erfolg wird. Deshalb gehört eine Feier des Erfolgs auch zum Projektabschluss. Diese kann genutzt werden, um Erfahrungen weiterzugeben und das Projektergebnis vorzustellen.
Projekte sind mit Risiken behaftet und es ist allein deshalb keine Selbstverständlichkeit, dass ein Projektteam ein Projekt erfolgreich abschließt. Auch wenn wir oft unausgesprochen davon ausgehen, dass Projekte erfolgreich enden, gibt es dafür keine Garantie. Was alleine schon ein Grund ist, einen entsprechenden Erfolg mit einem Dankeschön und einer kleinen Feier zu würdigen. Es bietet sich an, eine solche Feier zur Kommunikation von Erfahrungswissen zu nutzen und um das fertige Ergebnis des Projekts zu präsentieren. Davon auszugehen, dass alle am Projekt Beteiligten auch das Endergebnis des Vorhabens sehen werden, ist ein Irrtum. Gerade deshalb lohnt sich eine Präsentation. Und diese Präsentation ist auch eine letzte Prüfung des Projekterfolgs: kann nichts präsentiert werden, ist das Projekt wohl noch nicht abgeschlossen.
Projektmanagement-Standards im Verlag einführen Die Einführung von Projektmanagement-Standards ist ein Projekt Genau genommen ist ein Projektmanagement-Prozess ein Routineprozess für unbekannte Vorhaben. Ist ein solcher Prozess in einem Unternehmen etabliert, macht er die Arbeit in und an Projekten grundsätzlich leichter und produktiver. Die Führungskräfte können von solch einer Standard-Vorgehensweise in Projekten erwarten, dass sie einen besseren Überblick über den Projektverlauf bekommen und selbst weniger in den Projektverlauf eingreifen müssen. Projektleiter nennen oft die damit verbundene Orientierung sowie die Sicherheit als wesentlichen Nutzen aus einer standardisierten Vorgehensweise. Außerdem wird häufiger angeführt, dass Entscheidungswege damit klarer und schneller werden, was sowohl Auftraggebern von Projekten wie auch Projektleiter und -teams zugute kommt. Die Besonderheit eines solchen Projektmanagement-Ablaufs liegt darin, dass dieser Prozess ausschließlich organisatorische Dinge beschreibt. Der Ablauf beschreibt wie der Verlauf eines Projekts erarbeitet und beschrieben wird, wie etwa ein Projektplan entsteht, der wiederum beschreibt, was zu tun ist, um das Projektergebnis zu liefern. Das führt nicht selten zu einem gedanklichen Knoten im Kopf. Andere Abläufe im Verlag sind dagegen wesentlich weniger abstrakt, da sie bereits die Tätigkeiten beschreiben, die durchzuführen sind, um das erwartete Endergebnis des Vorgangs zu liefern. Der Auslöser für die Einführung von Projektmanagement-Standards kann in allen Verlagsbereichen liegen. Nicht selten ist der Auslöser problembehaftet, wenn etwa die Geschäftsleitung feststellt, dass die Erfolge von Projekten zu wünschen übrig lassen. Unter diesen Vorzeichen wird dann sehr häufig versucht mit Maßnahmen der Personalentwicklung eine Besserung zu erzielen. Diese alleine genügen allerdings nicht, vor allem nicht, wenn nur Projektleiter und Teammitglieder in Projektmanagement geschult werden. Die Auftraggeber von Projekten, also meist die Geschäftsleitung und die Führungskräfte des Verlags, haben mindestens einen genau so großen Anteil am Erfolg von Projekten, wie Projektleitung und -teams. Deshalb müssen diese ebenfalls an einer solchen Standardisierung beteiligt werden und im Ergebnis ihr Verhalten ändern. Gelingt dies nicht, wird ein Routineprozess für Projekte nur bedingt Wirkung erzielen.
Ein einfacher ProjektmanagementStandard erleichtert es Führungs kräften, den Überblick über Projekte zu behalten. Er reduziert außerdem die Anzahl der notwendigen Eingriffe in das Projektgeschehen durch die Führungskräfte.
Die Zielsetzung eines Standardisierungsprojekts Am Ende eines Standardisierungsprojekts gilt es die Erfolgsquote aller Projekte gesteigert zu haben. Soweit sind sich die Beteiligten meist schnell einig. Sobald jedoch hinterfragt wird, was sich hinter „erfolgreiche Projekte“ verbirgt, beginnt eine spannende Diskussion. Aus meiner Sicht sind zwei Zielkorridore wesentlich, die dauerhaft gesichert und ausgebaut werden sollten: • Nach erfolgreicher Einführung von Projektmanagement-Standards ist das Verhältnis Aufwand für die Projektbearbeitung zum daraus entstandenen Nutzen besser als zuvor. Dies gilt für das Projekt-Portfolio in seiner Gesamtheit. • Außerdem tun sich die in Projekten arbeitenden und an Projekten beteiligten Personen leichter.
Ziele der Einführung von Projekt management-Standards sind die Verbesserung des Verhältnisses von Aufwand und Nutzen über das gesamte Projektportfolio hinweg, wie auch die Arbeitserleichterung für alle Beteiligten.
150 Projektmanagement-Standards im Verlag einführen Dadurch entsteht ein strategischer Wettbewerbsvorteil, der von konkurrierenden Unternehmen nur schwer und mit zeitlicher Verzögerung erschlossen werden kann. Die Hauptziele können erreicht werden, indem folgende Teilziele realisiert werden: • Der Projektbegriff ist eindeutig definiert. • Es stehen genug gut ausgebildete Projektleiter zur Verfügung, die die unterschiedlichen Projekte innerhalb des Verlags zum Erfolg führen können. • Die internen Auftraggeber kennen ihre Rolle in Projekten und agieren in geeigneter Weise, um die Erfolgswahrscheinlichkeit der Projekte zu steigern. • Ein definierter Projektablauf ist akzeptiert, dokumentiert und wird in allen Projekten angewendet. Er macht es möglich, dass auch weniger gut qualifizierte Projektleiter Projekte mit einer höheren Wahrscheinlichkeit zum Erfolg führen können. • Aus den Erfahrungen in den verschiedenen werden systematisch Lehren für zukünftige Projekte und die gesamte Organisation gezogen, die in zukünftigen Projekten angewendet werden. • Das Projekt-Portfolio wird von Auswahl über Durchführung bis zum Projektabschluss der Projekte aktiv auf Basis der Unternehmensziele und Aufwände gesteuert. Dies schließt die Steuerung des Ressourcenbedarfs gegenüber den verfügbaren Kapazitäten mit ein. • Allen Beteiligten stehen geeignete Systeme, Vorlagen und Hilfsmittel zur Verfügung, die die Produktivität der Projektarbeit erhöhen. • Wenigstens für besonders schwierige Projekte und die gezielte Weiterentwicklung von Projektleitern sind Strukturen geschaffen, die bedarfsgerechte Hilfestellungen etwa durch Projekt-Coaching sicherstellen, um den Erfolg der Projekte abzusichern. • Die Weiterentwicklung des Projektmanagement-Prozesses ist sichergestellt, etwa indem es im Unternehmen eine Person oder Personengruppe gibt, die dafür die Verantwortung wahrnimmt. • Sämtliche Beteiligte beschreiben die Arbeit in Projekten als angenehmer und leichter. • Sämtliche Beteiligte sprechen dieselbe Sprache, was Missverständnisse vermeiden hilft und Abstimmungsaufwand sowie Reibungsverluste reduziert. • Im Verlag ist eine Karriere für Projektleiter etabliert, die eine systematische Weiterbildung von Auftraggebern, Projektleitern und Teammitgliedern umfasst. • Die praxisnahe und erfolgreiche Anwendung der Methodik wurde in Pilotprojekten nachgewiesen und kommuniziert.
Messgrößen für die erfolgreiche Einführung von Projektmanagement-Standards
Diese Ziele sind umfangreich und können meist erst nach einigen Jahren erreicht werden. Dies gilt insbesondere, da die Erreichung dieser Ziele die Akzeptanz der Systematik durch sämtliche Beteiligte voraussetzt. Akzeptanz zu erreichen erfordert üblicherweise eine intensive Beteiligung aller Personen, die den Prozess später mit Leben füllen und anwenden sollen. Wer Akzeptanz erreichen will, sollte außerdem Zeit für die Verarbeitung neuer Erfahrungen und Schleifen dafür einplanen. Ob die oben aufgeführten Ziele erreicht wurden, kann an einer oder mehreren Messgrößen festgemacht werden. Unter anderem an folgenden Punkten lässt sich erkennen, ob und wie gut die Einführung von Projektmanagement-Standards wirkt: • Bei vergleichbaren Projekten sollten sowohl die Aufwände wie auch die Projektlaufzeit sinken. • Die Anzahl ungeplanter Überstunden sollte sinken. • Die Anzahl kurzfristiger Änderungen sollte niedriger sein als zuvor.
Der Projektmanagement-Prozess 151
• •
Die Anzahl der Management-Eingriffe in vergleichbaren Projekten sollte niedriger sein. Die Anzahl der Projektabbrüche und nicht fortgesetzter Projekte sollte sinken.
Themenfelder der Einführung von Projektmanagement-Standards Die oberste Ebene des Projektstrukturplans Aus den Projektzielen lassen sich die Themenfelder ableiten, die im Rahmen der Standardisierung von Projektmanagement-Abläufen adressiert werden müssen. Diese wirken sowohl auf einzelne Projekte wie auch auf das gesamt Projektportfolio sowie die Weiterentwicklung der Systematik.
Teilaufgaben der Einführung von Projektmanagement-Standards
Abbildung 57: Oberste Ebene des Projektstrukturplans für die Einführung von ProjektmanagementStandards
Der Projektmanagement-Prozess Der Projektmanagement-Prozess ist letztlich ein Standardprozess zur Bearbeitung bisher für den Verlag unbekannter Aufgabenstellungen. Er beschreibt, wann wer was tun sollte oder muss, um Projektmanagement im Sinne des Verlags zu betreiben. Wobei ein Projektmanagement-Prozess letztlich eine Standardisierung der Projektarbeit bedeutet, um so die Produktivität der Projektarbeit zu steigern. Gleichzeitig bietet ein guter Projektmanagement-Prozess Hilfestellung und Orientierung, so dass auch weniger erfahrene oder weniger gut ausgebildete Projektleiter eingesetzt werden können. Gerade in der Anfangsphase der Einführung ist der Prozess deshalb eine wichtige Stütze. Mit ihm einher geht die Abgrenzung des Projektbegriffs. Je greifbarer die Trennlinie zwischen Projekt, kleinerem Vorhaben und Routineprozessen ist, desto leichter tun sich die Beteiligten üblicherweise. Die allgemeinen Definitionskriterien für Projekte werden meist um verlagsindividuelle Kriterien ergänzt, etwa die Größenordnung von Vorhaben. Werden diese Kriterien erreicht, wird die Anwendung des Projektma-
Ein guter ProjektmanagementProzess bietet allen Beteiligten Hilfestellung und Orientierung. Auch weniger erfahrene Projektleiter können dadurch besser eingesetzt werden.
Projektmanagement-Prozess
152 Projektmanagement-Standards im Verlag einführen
Fragen zur Erstellung eines Pro jektmanagement-Prozesses
nagement-Prozesses zur Pflicht. Bei allen anderen Vorhaben mit projektähnlichem Charakter ist seine Anwendung optional. Gute Erfahrung machen wir mit Projektmanagement-Prozessen immer dann, wenn diese einfach gehalten sind und als Hilfestellung wahrgenommen werden. Im Wesentlichen genügt es zu Beginn folgende Fragen zu beantworten: • W ie wird ein Vorhaben zum Projekt? • Wie kommt ein Projektleiter zu Ressourcen und einer inhaltlichen Freigabe? • Wie wird die Zusammenarbeit koordiniert und welche Methoden und Instrumente (beispielsweise Projektpläne) sollen hierfür eingesetzt werden? • Welche Rollen müssen besetzt sein und wer hat welche Verantwortung? • Wie arbeiten diese Personen in diesen Rollen zusammen, in guten wie in schlechten Zeiten? • Was muss bei der Übergabe beachtet werden? • Wie wird der Projektabschluss vollzogen? Ein einfacher Projektmanagement-Prozess wird letztlich im Kapitel „Der Projektablauf im Überblick“ (Seite 20f.) beschrieben. Auf der Zeitachse werden nacheinander definierte Ergebnisse vom Projektleiter gefordert, die sicherstellen, dass den unterschiedlichen Anforderungen der Beteiligten Rechnung getragen wird. In Abbildung 3 „Wichtige Meilensteine aus Sicht des Projektmanagement“ (Seite 22) ist dieser Prozess letztlich grafisch aufbereitet. Diese Grafik bietet einen guten Einstieg in die Diskussion eines solchen Prozesses im Verlag.
Qualifizierung des Projektpersonals
Da interne Auftraggeber einen großen Anteil am Erfolg eines Projekts haben, sollte deren Rolle frühzeitig geklärt werden.
Nicht nur in Verlagen sind die wenigsten Mitarbeiter in Projektmanagement-Methodik ausgebildet. Deshalb markiert sehr häufig eine Grundlagenschulung der Projektleiter den Startpunkt für die Veränderungen in der Projektarbeit im Unternehmen. Diese Schulungen haben zum einen das Ziel, ein gemeinsames Verständnis von Projektmanagement und eine gemeinsame Sprache zu schaffen. Zum anderen sollen sie den Projektleitern aufzeigen, wie der Projektmanagement-Prozess in einem Projekt mit Leben gefüllt wird. Im Idealfall weiß der Projektleiter nach der Schulung, was er wann im Projekt tun muss und kann, um den Projektmanagement-Prozess geschickt zu nutzen. Aus unserer Erfahrung ist ein hoher Praxisbezug dieser Schulungen sehr wichtig. Wird mit tatsächlich zur Bearbeitung anstehenden Projekten als Grundlagen der Schulung gearbeitet, werden die echten Fragen an die Oberfläche gespült und können im Rahmen des Seminars diskutiert werden. Außerdem erhöht ein solches Vorgehen die Akzeptanz bei den Beteiligten, da automatisch diskutiert wird, wie die Anwendung der Methodik im jeweiligen Verlag gelingt. Wobei die Diskussion des Nutzens fester Bestandteil einer solchen Grundlagenschulung sein sollte ebenso wie die Diskussion der Rolle des Projektleiters und dessen Haltung.32 Neben den Projektleitern sind die internen Auftraggeber von Projekten eine wichtige Zielgruppe. Gerade die Auftraggeber haben einen großen Anteil am Erfolg eines Projekts, sind sich dessen jedoch selten bewusst. Eben dieses Bewusstsein für die
32 Ein Beispiel für bewährte Schulungsinhalte finden Sie unter http://www.projektmensch.com/go2/ pmk
Qualifizierung des Projektpersonals 153
Rolle und Verantwortung des Auftraggebers sowie deren Eingriffsmöglichkeiten in Projekten sollten früh thematisiert werden. Eine Teilnahme an einer Grundlagenschulung ist dabei aus meiner Erfahrung sehr hilfreich, da dadurch das Verständnis für die Nöte von Projektleitern und -teams wächst. Werden gemischte Gruppen aus Projektleitern, Projektmitarbeitern und Auftraggebern in den Grundlagenseminaren geschult, entsteht ein besonders wertvoller Wissenstransfer. Transfertage, Erfahrungsaustausch und Aufbauschulungen werden in späteren Phasen der Einführung von Standards wichtig, um in der Praxis auftretende Fragen zu beantworten und die Anwendung der Methodik zu festigen. Themen wie Führen ohne Weisungsbefugnis, Kommunikation, Moderation sind über die methodischen Inhalte hinaus zentral. Neben Schulungen ist die Begleitung der Projektleiter in deren Projekten durch einen Projektmanagement-Profi sehr hilfreich, da viele auftretende Fragen persönlicher Natur sind und in einem Coaching-Prozess besser bearbeitet werden können. Dieser kann mit der Projektunterstützung kombiniert werden, so dass sowohl der Projektleiter im Sinne der Personalentwicklung davon profitiert, wie auch die im Rahmen des Coaching bearbeiteten Projekte.
154 Projektmanagement-Standards im Verlag einführen
So kann ein Ablauf eines Lehrgangs für zukünftige ProjektmanagementProfis aussehen.
Abbildung 58: Beispiel eines Qualifikationsmodells für Projektleiter
Das Projektmanagement-Handbuch als Leitfaden 155
Karrieremodell für Projektleiter In Verlagen laufen Projekte meist „nebenher“, sprich der Projektleiter hat eine Linien tätigkeit und muss zusätzlich ein Projekt bearbeiten. Spätestens wenn ein Projekt Dimensionen annimmt, die einen Großteil der Arbeitszeit eines Projektleiters fordern, leidet eine dieser Parallelwelten. Deshalb haben viele Projektleiter keine Lust auf die Projektleitung, obwohl ihnen die Projektleitung an sich Spaß macht. Außerdem ist es ein Risiko, die Linienarbeit abzugeben, denn dann ist eine Rückkehr auf die ursprüngliche Arbeitsstelle eventuell nicht mehr möglich. Karrieremodelle für Projektleiter beantworten mindestens die Frage, was mit einem Projektleiter nach Abschluss eines Projekts geschieht. Das gilt in großen wie in kleinen Verlagen gleichermaßen. In kleineren Häusern sind Ängste und Sorgen gegebenenfalls größer, da die Kosten für den Lohn einer einzelnen Person weit stärker ins Gewicht fallen, was den Mitarbeitern durchaus bewusst ist. Kann der Projektleiter zurück auf seine ursprüngliche Arbeitsstelle? Welche alternativen Optionen gibt es? Möchte sich eine Organisation in Sachen Projektmanagement auf lange Sicht weiterentwickeln, müssen diese Fragen beantwortet werden. Wobei die Antwort eng mit dem Qualifikationsmodell von Projektpersonal verzahnt ist. Will ein Verlag der aktuellen Entwicklung von Projekten Rechnung tragen, sind in Zukunft in größeren Verlagen durchaus Projektabteilungen denkbar, aus denen Projektleiter für die größten Projekte des Verlags rekrutiert werden. In Verbindung mit flexiblen Arbeitszeitkonten kann sich das Unternehmen auf diesem Wege gut ausgebildetes und erfahrenes Projektpersonal sichern. Neben den großen Projekten können diese Personen Teile der Qualifikation zukünftiger Projektleiter übernehmen und die Patenschaft für kleinere Vorhaben sowie innerbetriebliches Coaching übernehmen. Eine einzelne Person oder ein Projektmanagement-Dienstleister als langjähriger Partner können diese Funktion in einem kleineren Verlag übernehmen. Diese Abteilungen sind es dann sinnvollerweise auch, die zukünftig systematisch neue Geschäftsfelder erschließen und für die Umsetzung der Unternehmensstrategie sorgen. Damit wird das Unternehmen in die Lage versetzt, sich einen strategischen Wettbewerbsvorteil zu schaffen, der nur schwer von Wettbewerbern kopiert werden kann, da er Teil der Unternehmenskultur wird. Vorausgesetzt, ein Verlag ist bereit, mehrere Jahre in den Aufbau zu investieren.
Projektabteilungen können dafür sorgen, dass systematisch Neugeschäft erschlossen wird.
Das Projektmanagement-Handbuch als Leitfaden Das Projektmanagement-Handbuch fasst alle Spielregeln und Vorgehensweisen des Projektmanagement-Standards zusammen. Es dient allen Projektbeteiligten als Leitfaden und Hilfsmittel. Deshalb sind darin idealerweise sämtliche Vorlagen und Checklisten integriert, die ein Projektleiter im Projektverlauf benötigt. Als Grundstruktur bieten sich die vier Projektmanagement-Phasen an, wie in Abbildung 2 im Kapitel „Vier Ziele, vier Projektmanagement-Abschnitte“ (Seite 18) beschrieben. So können gerade unerfahrene Projektleiter einfach mit dem Handbuch arbeiten und sich Schritt für Schritt daran orientieren. Neben dem zeitlichen Ablauf sollten vor allem auch die grundsätzlichen Rollen sowie deren grundsätzliche Aufgaben darin beschrieben sein. Neben dem Projektleiter sind in jedem Projekt mindestens Projektteammitglieder und Auftraggeber nötig. Die im Projektmanagement-Handbuch definierten Erwartungen an eine Rolle sowie deren Kompetenzen können dann Grundlage für die individuelle Rollendefinition im Projekt sein.
Projektmanagement-Handbuch
156 Projektmanagement-Standards im Verlag einführen
Inhalte eines ProjektmanagementHandbuchs
Wichtig ist es, dass ein Projektmanagement-Handbuch früh im Projekt zur Verfügung steht, da es gerade zu Beginn großen Nutzen stiftet.
Mit dieser Inhaltsstruktur eines Projektmanagement-Handbuchs haben wir mehrfach gute Erfahrungen gemacht: • Projekt vs. Routine: Worauf soll das Handbuch angewendet werden und worauf nicht? • Überblick über den Projektmanagement-Prozess –– Projektmanagement-Phasen –– Anforderungen an die Phasen • Rollen im Projekt und grundsätzliches Zusammenwirken –– Projektleiter –– Auftraggeber –– Lenkungsgremien –– Teammitglieder –– (Interne Lieferanten) –– (Stakeholder) • Wesentliche erwartete Lieferungen - Was muss der Projektleiter wann in welcher Form liefern? –– Projekt-Mandat –– Projektziele –– Projektskizze oder Projektauftrag –– Ressourcenvereinbarung –– Projektplan –– Projektberichte –– Eskalation –– Änderungsanträge/-meldungen –– Übergabevereinbarung –– Abschlussbericht • Weitergehende Erwartungen? –– Anforderungskatalog, Lastenheft, Pflichtenheft –– Business Case/ Geschäftsplan/ Wirtschaftlichkeitsberechnungen –– Projektcontrolling –– Personalentwicklung im Projekt • Formulare, Hilfsmittel, Quellen –– Vorlage Projekt-Mandat –– Vorlage Projektskizze –– Vorlage/ Beispiel Projektplan –– Phasenplan –– Zeitplan –– Ressourcenplan –– Budgetplan –– Qualitätsplan –– Vorlage Projektbericht –– Vorlage Änderungsantrag/-meldung –– Vorlage Eskalationsmeldung –– Vorlage Abschlussbericht Dieses Buch orientiert sich im Wesentlichen an diesem Ablauf und ist ähnlich aufgebaut, wie ein Projektmanagement-Handbuch. Allerdings sollte sich das Projektmanagement-Handbuch auf die tatsächlich anzuwendenden Dinge konzentrieren und kann die in diesem Buch darüber hinaus enthaltenen Erklärungen aussparen. Wie das Projektmanagement-Handbuch bereitgestellt wird, ist aus unserer Erfahrung für dessen Erfolg unerheblich. Wichtig ist, dass es früh im Projekt zur Verfügung
Über die Organisationsstruktur Führungskräfte einbinden und Projekt-Portfolios steuern 157
steht und leicht genutzt werden kann. Will der Auftraggeber sich, dem Projektteam und dem Projekt einen Gefallen tun, liefert er das Handbuch mit dem Auftrag und verbunden mit dem Hinweis, die Spielregeln des Handbuchs zu nutzen. Einige unserer Kunden stellen die Inhalte über ein Intranet zur Verfügung und dies in einem Format, das die direkte Verwendung der Vorlagen erlaubt und Kommentare möglich macht. Diese Kommentare werden dann genutzt, um eine verbesserte Version des Handbuchs zu erarbeiten.
Projektunterstützung Wer neu in das Thema Projektmanagement einsteigt oder Projektmanagement unter geänderten Rahmenbedingungen betreibt, hat üblicherweise viele Fragen und stößt auf Schwierigkeiten. Bleiben diese Fragen unbeantwortet und die Schwierigkeiten ungelöst, tritt die Einführung von Projektmanagement-Standards schnell auf der Stelle. Wer dieses Pausieren vermeiden will, sollte dafür sorgen, dass die Projektleiter unkompliziert Unterstützung bekommen und diese auch nutzen. Da ein solches Angebot meist ungewohnt ist, muss der für die Einführung der Standards Verantwortliche häufig aktiv dafür sorgen, dass ein entsprechendes Angebot tatsächlich auch in Anspruch genommen wird. Meist macht es Sinn, verschiedene Unterstützungsangebote zu kombinieren. Etwa einen internen Erfahrungsaustausch zu etablieren, der mit Impulsreferaten von Experten angereichert wird, um nicht im eigenen Käfig gefangen zu bleiben, und parallel Einzelcoachings für ausgewählte Projektleiter und Projekte anzubieten. Gerade letztere sind eine sehr erfolgreiche Methode, schnell eigene Projektmanagement-Experten aufzubauen, die dann als interne Multiplikatoren wirken können und Ansprechpartner für Fragen weniger erfahrener Kollegen sind.
Über die Organisationsstruktur Führungskräfte einbinden und Projekt-Portfolios steuern Wird alleine auf die Projektleiter und Projektteams eingewirkt, um Projektmanagement-Standards zu etablieren, dauert der Prozess meist länger, als wenn gleich von Anfang an Führungskräfte mit in die Entwicklung und Anwendung der neuen Standards einbezogen werden. Unter anderem darum, wie die Führungsebene involviert wird, geht es im Bereich „Organisationsstruktur“ des Projektstrukturplans. Außerdem gilt es, Schritt für Schritt Steuerungsinstrumente aufzubauen, die die Führungsebene in die Lage versetzen, ein ganzes Portfolio an Projekten systematisch zu steuern. Da Führungskräfte üblicherweise ein Interesse an den Ergebnissen wichtiger Projekte haben und auf diese Projekt einwirken wollen, bieten sich derartige Vorhaben als einer Art Hilfsmittel an, um neue Organisationsstrukturen zu etablieren. So kann es beispielsweise Sinn machen, für ein Projekt besonderer Bedeutung erstmalig einen Lenkungsausschuss einzurichten und in diesem Rahmen Rolle und Aufgabe eines solchen Gremiums zu diskutieren und definieren. Wichtig ist bei der Einrichtung solcher Gremien, dass es zu einer Beteiligung der Gremiumsmitglieder am Projekt kommt und die Arbeit des Gremiums einen Wert für das Projekt hat. So könnte etwa das Augenmerk zu Beginn auf bereichsübergreifen-
Um Führungskräfte trotz Desinteresse an ProjektmanagementMethodik an deren Entwicklung zu beteiligen, können bedeutsame Projekte genutzt werden.
158 Projektmanagement-Standards im Verlag einführen den Entscheidungen liegen, die nach einer vereinbarten Systematik auf Basis eines Vorschlags der Projektleitung getroffen werden. Soll nicht nur ein Projekt sondern vielmehr ein ganzes Projekt-Portfolio im Fokus stehen, bietet sich die Einrichtung von Projekttagen an. An diesen Tagen wird in einer fest definierten Reihenfolge von Projektleitern berichtet und über den weiteren Projektverlauf entschieden. In Verbindung mit einer Projektliste können so leicht Prioritäten angepasst werden, um etwa Ressourcenengpässen und Änderungen in einzelnen Projekten Rechnung zu tragen. Tabelle 7: Beispiel für eine einfache Portfolio- und Berichtssteuerung über eine Tabelle Projekttage sind ein effizientes Mittel, um ein Projekt-Portfolio zu steuern.
Projekt
Rang
Projektleiter
Projekttage Datum 1 Datum 2
Datum 3
Datum 4
Beispielprojekt A
100
...
Bericht
-
Bericht
-
Beispielprojekt X
200
...
Bericht
Bericht
-
-
Beispielprojekt M
300
...
-
Bericht
-
Bericht
...
...
Wann wer berichtet, wird in einer einfachen Tabelle erfasst. Über den Rang eines Projekts wird die Energieversorgung des Vorhabens definiert. Je höher der Rang, desto eher erhält das jeweilige Projekt Ressourcen. Erst wenn ein Projekt höheren Rangs genügend Ressourcen hat, werden Projekte niedrigeren Rangs mit Ressourcen bedient. (Siehe hierzu auch Kapitel „Autoren und Dienstleister ins Boot bekommen: Ressourcenplanung ist ein Verhandlungsprozess“, Seite 92 f.)
Pilotprojekte als Quelle für Erfahrung und als Beweis für den Nutzen der Standards
Pilotprojekte für die Anwendung einer verbesserten Projektmanagement-Methodik können ein guter Weg sein, um den Nutzen erlebbar zu machen.
Selten ist es möglich, von Beginn der Einführung an alle Projekte nach einem zukünftigen verlagsweiten Projektmanagement-Standard durchzuführen. Unter anderem deshalb macht es Sinn, mit ein paar wenigen ausgewählten Pilotprojekten zu starten. Diese werden sorgfältig nach strategischen Gesichtspunkten und Multiplikationseffekten ausgesucht und intensiv begleitet. Die Pilotprojekte werden genutzt, um Erfahrung mit der neuen Methodik zu sammeln und damit Prozesse samt Dokumentation zu verbessern. Außerdem werden die Pilotprojekte genutzt, um zu zeigen und zu beweisen, wie und wie gut die Projektmanagement-Methode wirkt. Wichtig ist dabei die Messlatte geschickt zu setzen. Sind die Erwartungen an die neue Methode zu gering, scheint die Mühe nicht lohnenswert. Sind die Erwartungen zu hoch, riskiert man das Scheitern der neuen Standards. Als Projektleiter tut man gut daran, die Anwendung der Methodik in diesen Projekten als Erprobung zu bezeichnen und parallel zur Projektbearbeitung einen Lernprozess zu etablieren, in dem regelmäßig Wirkung und Fortschritt reflektiert werden. Besonderes Augenmerk wird dabei auf tatsächliche gegenüber vermuteten Aufwänden gelegt, sowie auf den Nutzen – gefühlt wie auch messbar – des Standards. In diesem Rahmen bieten Pilotprojekte gleichfalls viele Möglichkeiten, die Einführung und Anwendung der Methodik mit wenig Aufwand zu kommunizieren. Selbst bei kleineren Verlagen ist das wichtig. Oft wird unnötiger Aufwand bei mangelndem Nutzen unterstellt, wenn Projektmanagement-Standards eingeführt werden sollen. Erst im Kontakt mit echten Projekten und in der Anwendung erleben die Menschen, was
Damit die Verhaltensänderung bei allen gelingt: Kommunikation und Vermarktung 159
gutes Projektmanagement wirklich bedeuten kann. Der frühere Feierabend und die geschonte Unternehmenskasse sind nur zwei Nutzenargumente, die sichtbar werden.
Projektmanagement-Werkzeuge sorgen für Produktivität im Projektmanagement Wer eine gute Projektmanagement-Software nutzt, erstellt einen Projektplan mit weniger Aufwand als der Kollege, dem ein solches Werkzeug nicht zur Verfügung steht. Unter diesem Gesichtspunkt gilt es im Rahmen der Einführung von Standards Werkzeuge zur Verfügung zu stellen, welche die Produktivität des Projektmanagements und der Projektleitung erhöhen. Wobei eine Projektmanagement-Software nur ein mögliches Werkzeug darstellt. Vorlagen, Checklisten und Vorschläge können ebenfalls für weniger Aufwand sorgen. Sowohl Vorlagen und Checklisten können mit wenig Aufwand selbst erstellt oder noch einfacher zugekauft werden.33 Nicht ganz so einfach gestaltet sich die Anschaffung und Einführung einer Projektmanagement-Software. Selten sind die Anforderungen zu Beginn der Einführung so präzise zu benennen, dass eine Auswahl auch nach Jahren mit Erfolg gekrönt ist. Deshalb nutzen wir gerne in der Startphase einer Einführung frei verfügbare Software-Programme oder Projektmanagement-Software als Mietlösung. Damit können Projektteams schnell auf ein Hilfsmittel zugreifen und die Kosten sowie das Risiko eines Fehlkaufs bleiben klein. Informationen hierzu finden Sie im Kapitel „Kostenlose Projektmanagement-Software“ auf Seite 87. Wichtig ist das Bewusstsein, dass eine Projektmanagement-Software lediglich ein Hilfsmittel darstellt. Viele Projektteams, die mit der Anschaffung beauftragt werden, schießen über das Ziel hinaus. Sie wollen gleich noch das Berichtswesen automatisieren, mehr Transparenz über das Portfolio hinaus schaffen und Kommunikationswege abkürzen. So verlockend das alles klingt, die Einführung scheitert meist daran, dass die Projektleiter schlicht überfordert sind. Ein starkes Indiz dafür, dass die Software wenig Akzeptanz finden wird, ist die Tatsache, dass Berichte und Kennzahlen im Fokus der Auswahl stehen. Dort wo nach einer Hilfestellung für Projektteams in Form einer Software gesucht wird, ist die Erfolgsaussicht größer. Erst wenn die einzelnen Projekte gut organisiert sind und das Portfolio gesteuert wird, macht es Sinn, Dinge wie die Automatisierung des Berichtswesens anzupacken.
Damit die Verhaltensänderung bei allen gelingt: Kommunikation und Vermarktung Genau genommen will die Einführung von Projektmanagement-Standards das Verhalten von Mitarbeitern, Lieferanten, Dienstleistern und anderen beteiligten Personen ändern. Der Wunsch nach einer Verhaltensänderung wird meist mit Widerstand quittiert. Die Beteiligung an der Veränderung sowie die Kommunikation dazu sind wichtige Faktoren, die darüber entscheiden, ob die gewünschte Veränderung eintritt. Sie sind notwendig, wenn auch nicht hinreichend. Alle Aspekte des Projektstrukturplans zur Einführung von Projektmanagement-Standards tragen dazu bei, dass systematisch eine Verhaltensänderung herbeigeführt wird, die dann auch beibehalten wird.
33 Als Käufer dieses Buchs erhalten Sie einen Gutschein für das Projektkaufhaus. Dort können Sie die hier verwendeten Vorlagen abrufen. Details finden Sie im Vorwort auf Seite 1
Eine Projektmanagement-Software ist ein Hilfsmittel vor allem für das Projektteam. Deshalb sollten bei der Auswahl nicht Berichte und Kennzahlen im Fokus stehen. Die lassen sich im Zweifel schnell erstellen, wenn die Grundlagen stimmen.
160 Projektmanagement-Standards im Verlag einführen Doppler und Kollegen führen eine Formel für Veränderung ins Feld, die auf „das Beraterduo Dannemiller & Tyson“ zurückgeht und die – der leichteren Verständlichkeit leicht abgewandelten Form - hilft, Veränderungsprojekte zu gestalten: Druck / Unzufriedenheit x Vision x Können / First Steps > Widerstand34 Daraus lässt sich ableiten, worauf in Beteiligung und Kommunikation Wert gelegt werden sollte. Zum einen muss deutlich werden, welcher Druck vorhanden ist, die Unzufriedenheit muss bewusst werden. Zum anderen gilt es die Vision, den Sinn und Zweck, den Nutzen erlebbar zu machen und zum dritten, das Können zu steigern und konkret greifbare erste Schritte zu liefern. Die Formel macht deutlich, dass alle Faktoren wichtig sind. Ist nur ein Faktor nicht bedient, entspricht also Null, bringen alle anderen Bemühungen nichts. Projektleiter machen in diesem Punkt oft den Fehler, dass sie zu schnell in ihren Bemühungen nachlassen, wichtige Botschaften zu kommunizieren. Sie selbst haben die Argumente bereits satt, da sie diese unzählige Male gedacht, gehört und diskutiert haben. Das bedeutet jedoch nicht, dass diese Argumente bereits bei der Zielgruppe angekommen, geschweige denn akzeptiert und verinnerlicht sind. Ein dem Verhaltensforscher Konrad Lorenz zugeschriebener Satzbringt es auf den Punkt: „Gedacht ist noch nicht gesagt, gesagt noch nicht gehört, gehört noch nicht verstanden, verstanden noch nicht akzeptiert, akzeptiert noch nicht getan und getan noch nicht verinnerlicht.“ Erst wenn die Zielgruppe das neue, gewünschte Verhalten zeigt, also sprich die Methode und die Werkzeuge anwendet, und diese Arbeitsweise auch bei Gegenwind beibehält, sollte man in den Bemühungen nachlassen. Wie unter „Pilotprojekte als Quelle für Erfahrung und als Beweis für den Nutzen der Standards“ (Seite 158) aufgeführt, bieten sich diese besonderen Vorhaben an, um Methodik und Werkzeuge erleb- und begreifbar zu machen. Außerdem sind die parallel dazu organisierten Lern-Workshops wichtige Mittel der Verarbeitung und Bewusstmachung. Die Auswahl der Teilnehmer hierfür sollte sorgfältig getroffen werden, wobei die Stakeholderanalyse hierfür ein sehr nützliches Instrument ist. Diese ist unter „Stakeholder als Rolle im Projekt“ (Seite 122) beschrieben.
Organisatorische Verankerung der Projektmanagement-Standards Im Rahmen der Einführung von Projektmanagement-Standards werden meist externe Trainer und Berater benötigt, die der Organisation neues Wissen liefern und aufbereiten. Zielsetzung muss es allerdings sein, dieses Wissen intern aufzubauen und zu halten, sprich den Anteil der externen Wissenslieferanten Schritt für Schritt zu reduzieren. Damit dies dauerhaft erreicht wird, ist eine organisatorische Verankerung der Projektmanagement-Standards nötig, etwa indem eine Person oder Abteilung für das Projektmanagement im Unternehmen und die Weiterentwicklung der Standards verantwortlich zeichnet. Der Aufgabenbereich Einführung und Weiterentwicklung von Projektmanagement-Standards sowie die Koordination der zentralen Projektmanagement-Aktivitäten, wie etwa die Durchführung von Projekttagen sowie die inhaltliche Betreuung von Schulungsprogrammen und der Projektleiter-Karriere, wird häufig einem „Project Management Office (PMO)“ übertragen. Dieser Begriff ist allerdings nicht eindeutig definiert, allein schon da die verschiedenen Projektmanagement-Standards sowie die
34 Vgl. Unternehmenswandel gegen Widerstände: Change Management mit den Menschen, Klaus Doppler u.a., Campus Verlag, 2002, S. 105ff.
Phasen der Einführung von Projektmanagement-Standards 161
DIN-Norm unterschiedliche Aussagen dazu treffen. Deshalb ist es ratsam, die Aufgaben einer solchen Organisationseinheit klar zu benennen. Das PMO kann ein Ergebnis der Einführung von Projektmanagement sein, wenn die Einführung von einem Projektleiter koordiniert wird. Alternativ kann die Einrichtung eines PMO auch der Auftakt zur Einführung von Projektmanagement-Standards sein. Dann übernimmt ein Vertreter dieser Organisationseinheit die Projektleitung für die Einführung. Beide Vorgehensweisen waren in der Vergangenheit von Erfolg gekrönt und können deshalb als alternative Vorgehensweisen betrachtet werden. Die Einrichtung eines PMO kann auf verschiedenen Ebenen erfolgen. In einem kleinen Verlag kann eine Stabsstelle diese Funktion wahrnehmen, in großen Verlagen sind PMO auf verschiedenen Ebenen denkbar, deren Arbeit wiederum durch ein PMO auf Geschäfts- und Verlagsleitungsebene koordiniert wird. Neben der Koordination der zentralen Projektmanagement-Aktivitäten ist in PMOs häufig auch die Projektunterstützung angesiedelt, sofern Kapazität und Know-how dafür vorhanden sind.
Projektmanagement des Einführungsprojekts Dieses Kapitel muss der Vollständigkeit halber sein. Da die Einführung von Projektmanagement-Standards eindeutig ein Projekt ist, lohnt es sich, in die Projektmanagement-Werkzeugkiste zu greifen. Sie können mit Frage Nr. 1 starten, dann Frage Nr. 2 beantworten, anschließend Frage Nr. 3 aufgreifen und so weiter. Mehr gibt es an dieser Stelle kaum zu sagen.
Phasen der Einführung von Projektmanagement-Standards Die meisten Menschen ahnen nicht, was mit gutem Projektmanagement möglich ist. Diese Tatsache kennzeichnet die Ausgangslage bei der Einführung von Projektmanagement-Standards wesentlich. Es existieren allerlei Annahmen und Vorurteile bezüglich der Methode, positive wie negative. Und irgendwie kann jeder mitsprechen, denn schließlich arbeiten die meisten Menschen irgendwann irgendwie in und an Projekten. Nicht immer haben diese Bilder, die in den Köpfen existieren, tatsächlich etwas damit zu tun, was Projektmanagement letztlich bedeutet. Deshalb ist es wichtig und hilfreich in der ersten Phase der Einführung dafür zu sorgen, dass fundierte Kenntnisse über den Themenkomplex Projektmanagement aufgebaut werden und ein gemeinsames Grundverständnis für Methode und Möglichkeit entwickelt wird. Meist sind Grundlagenschulungen ein guter erster Schritt.
162 Projektmanagement-Standards im Verlag einführen
Grundlagenschulungen sind ein guter erster Schritt zur Einführung von Projektmanagement-Standards, um ein gemeinsames Verständnis für die Möglichkeiten und den Nutzen zu schaffen.
Abbildung 59: Beispiel für die Phasen der Einführung von Projektmanagement-Standards
Wurde mit den Schulungen eine gewisse Breite erreicht, gilt es das Wissen in die Anwendung zu bringen und so echtes Erfahrungswissen aufzubauen. Dies gelingt, indem begleitete Pilotprojekte gestartet und ehemalige Schulungsteilnehmer in deren Projekten beispielsweise durch einen Coach begleitet werden. Außerdem können nun Angebote wie ein Erfahrungsaustausch von Projektleitern, Projektunterstützung und weiterführende Schulungen starten. Dieses so gewonnene Know-how kann anschließend reflektiert und in einem ersten Projektmanagement-Handbuch sowie Anforderungen an zukünftige Werkzeuge und Prozesse zusammengefasst werden. Damit einher geht der Aufbau eines PMO, um die organisatorische Verankerung sicherzustellen. Mit dem ProjektmanagementHandbuch werden erste Hilfsmittel bereitgestellt und eine Softwarelösung für eine Testphase ausgewählt. Damit sind wesentliche Voraussetzungen für einen zukünftigen Standard geschaffen. Nun kommt die Phase des Experimentierens, Optimierens und Verinnerlichens. Damit einher geht die Verbreiterung der Basis der Projekte. Während anfangs wenige, meist bedeutende Projekte im Fokus stehen, gilt es nun die Methode in allen Bereichen einzuführen. Eine Vorgehensweise von Standort zu Standort macht dabei meist wenig Sinn. Im Gegenteil, die standortübergreifende Vernetzung ist doch oft wichtig für die Projektarbeit. Die Softwarelösungen werden außerdem in diesem Abschnitt getestet. In der letzten Phase werden spätestens die Projektmanagement-Software und das Karrieremodell eingeführt. Danach erfolgt die Übergabe an das PMO, das die Arbeit nun als Routineprozess fortsetzt. Dies sollte allerdings frühestens dann geschehen, wenn deutliche Erfolge zu sehen sind. Erfolgt die Übergabe zu früh, verliert das Vorhaben an Aufmerksamkeit. Damit steigt das Risiko, dass der Standard in der Versenkung verschwindet und sich die Verlagsmitarbeiter anderen Themen widmen.
Schlussworte, oder: Warum die Mühe? Meine persönliche Sicht Viele Projektteams bleiben weit hinter ihren Möglichkeiten zurück. Das ist sehr schade, denn wenige Dinge sind faszinierender als eine Aufgabenstellung, die sich am Rande dessen bewegt, was man selbst zu leisten vermag. Dieses Phänomen hat Mihaly Csikszentmihalyi mit seinem Forschungen zu „Flow“ untermauert und in verschiedenen Büchern beschrieben. Flow ist ein Zustand, in dem wir eintauchen können und trotz oder gerade wegen großer Anstrengungen große Freude erleben. Was liegt also näher, als Projekte so zu gestalten, dass im Projektteam viel Flow entsteht? Ich habe den Eindruck, dass viele Teams sich in diesem Punkt selbst im Weg stehen. Das Außergewöhnliche scheitert an der eigenen Vorstellungskraft. „Das hat doch noch nie geklappt?“ Mag sein. Dass etwas noch nie geklappt hat, ist jedoch kein Beweis dafür, dass es in Zukunft nicht klappen wird. Wir alle hätten kein Smartphone in der Tasche, kein Auto in der Garage, keinen Strom im Haus, hätten alle Menschen so gedacht und gehandelt. Die Entwicklungphase all dieser Dinge entspricht dem, was sich hinter dem Wort „Projekt“ verbirgt, egal ob so benannt oder nicht. Im Verlauf eines Projekts gibt es einen wichtigen Zeitpunkt dafür, dass Flow entstehen kann: der Zeitpunkt der Zielformulierung. Als Projektleiter können Sie diesen Zeitpunkt geschickt nutzen, indem sie sich mit den Projektzielen so weit aus dem Fenster wagen, wie es mit diesem Projektteam möglich ist. Achten Sie dabei darauf, dass sich die persönlichen Motive der Teammitglieder, etwas bewegen zu wollen, darin wiederfinden. Schon haben sie einen guten Grundstein gelegt, dass Flow entstehen kann. Flow entsteht, wenn wir gerade etwas mehr leisten müssen, als wir eigentlich leisten können. Wir sind etwas über unserer persönlichen Grenze, merken jedoch, dass es machbar sein könnte. Das reizt uns. Damit dieser Effekt eintritt, ist ständiges und direktes Feedback über das Vorankommen nötig. Je direkter ein Projektteam merkt, was funktioniert und was nicht, desto eher entsteht die mit diesem Phänomen einhergehende Freude. Demnach kommt der Fortschrittsmessung im Projekt eine größere Bedeutung zu, als nur die Darstellung des Vorankommens durch Häkchen und Kennzahlen. Warum ich das schreibe? Weil mit Projekten mehr möglich ist, als die meisten Menschen ahnen. Projekte sind prädestiniert, Neues zu erschließen und Dinge auf die Beine zu stellen, die es so noch nicht gab. Das kann sehr viel Spaß machen und Sinn geben. Die Verantwortung ob das gelingt hat jedes Projektteam für sich, wobei der Projektleiter unbestritten eine wesentliche Rolle spielt. Ich wünsche mir oder besser: ich wünsche Ihnen, dass Sie diesen Effekt auch erleben (dürfen). Ein besonderes Projekt kommt mir bei diesen Gedanken unweigerlich in den Sinn. Es hat auf den ersten Blick nichts mit der Verlagsbranche gemein. Ein Projekt, das eine ganz andere Branche als unmöglich abgetan hat und das dort, wo es entstanden ist, lange belächelt wurde. Im Rahmen des ersten Horber Jugendforums hatten sich Jugendliche gemeldet, sie hätten gerne ein Festival in Horb, einem Mittelzentrum mit rund 25000 Einwohnern. Ich hatte die Patenschaft für dieses Projekt übernommen. 30 Jugendliche zwischen 14 und 23 Jahren wollten mitmischen. Keiner davon hatte Erfahrung mit einem größeren Event, maximal noch mit den technischen Gegebenheiten. Wie im Fragenkatalog dieses Buchs beschrieben, hatten sich die jungen Macher auf den Weg gemacht, um eine erste Ausgabe des „Mini-Rock-Festivals“ mit 3500 Be-
Kreativität: Wie Sie das Unmögliche schaffen und Ihre Grenzen überwinden, Mihaly Csikszentmihalyi
Projektziele dürfen anspruchsvoll sein, damit Flow und damit viel Freude entsteht.
164 Schlussworte, oder: Warum die Mühe? suchern an zwei Tagen auf die Beine zu stellen. Ausnahmslos alles lag über den bisherigen Fähigkeiten der Teammitglieder. In vielen Situationen hat allein der Glaube Einzelner dafür gesorgt, dass die Mannschaft bei der Stange geblieben ist. Und vielleicht auch ein bisschen die Angst vor dem Gesichtsverlust im Freundeskreis. So wurde also trotz aller Unkenrufe und Befürchtungen weiter eine Aufgabe nach der anderen zum Ergebnis geführt. Ständiges Feedback war wichtig. Man kam voran, aber mühsam, musste sich anstrengen. Mehr und mehr wurde alles andere ausgeblendet. Die Vorstellung, abends dort zu stehen mit einer mächtigen Bühne und über 3000 anderen Menschen war so reizvoll, so verlockend. Alles schien zum Greifen nah. Damit war es die Mühe wert. Bereits die Entstehung, das Erarbeiten hat sich gelohnt. Was Csikszentmihalyi beschrieben hat, war für diese Truppe Realität: Flow. Sie haben es geschafft, die Mini-Rocker. Ich vermute, dass kein Mitglied dieser Truppe jemals diesen Moment vergessen wird, als die Arbeit getan war und man fünf Minuten den Anblick genießen konnte. Da standen sie, mehrere tausend Gäste vor der beleuchteten Bühne mit historischer Stadtkulisse im Hintergrund, fast ganz so wie es die Ziele vorgegeben hatten. Ein sehr emotionaler Moment. Die Mannschaft hat damit etwas auf die Beine gestellt, was kaum jemand für möglich gehalten hatte. In Deutschland gibt es vermeintlich kaum mehr Platz für neue Festivals und Jugendliche können schon gar keines auf die Beine stellen. Das waren die Vorurteile. So kann man sich irren. Das Ergebnis ist unter anderem in der Wikipedia nachzulesen.35 Im Jahr 2014 feiern die Mini-Rocker die zehnte Auflage des Festivals. Sie waren bereits mehrfach unter den zehn beliebtesten Festivals ihrer Größe bei den European Festival Awards. In der Verlagsbranche machen derzeit ähnliche Vorverurteilungen die Runde, wie sie die Mini-Rocker ignorieren mussten. Vielleicht nehmen Sie es wie diese jugendlichen Festivalmacher und glauben einfach daran, dass es doch noch einen Weg geben wird etwa ein zukunftsträchtiges Geschäftsmodell zu finden. Projektmanagement ist die ideale Methode, um sich das gewünschte Ergebnis zu erschließen.
Nutzen für den Verlag
Wer gutes Projektmanagement betreibt, kann pro Zeit mehr Projekte zum Ergebnis führen und damit mehr Nutzen schaffen.
Mal angenommen, Sie schaffen es heute in einem definierten Zeitraum von sagen wir einem Jahr 20 Projekte zum Abschluss zu bringen. Jedes dieser Projekte stiftet einen Nutzen, der Einfachheit halber in Geld ausgedrückt, von je einer Million Euro bei variablen Kosten von je einer halben Million Euro. Dann haben Sie zehn Millionen Euro, um damit Ihre Betriebskosten zu decken. Nehmen wir an, diese liegen bei acht Millionen Euro, bleiben unterm Strich zwei Millionen Euro als Gewinn. Nehmen wir weiter an, Sie schaffen es mit Hilfe wundersamer Techniken im darauffolgenden Jahr 24 Projekte zum Abschluss zu bringen, also 20 Prozent mehr als zuvor. Einnahmen und Ausgaben bleiben stabil, liegen also bei 24 Millionen auf der Habenseite und zwölf Millionen bei den Ausgaben. Bleiben zwölf Millionen, um die Betriebskosten zu decken. Ziehen wir acht Millionen von den zwölf Millionen ab, bleiben unterm Strich vier Millionen Euro als Gewinn. 100 Prozent mehr als im Jahr zuvor. Bitte verzeihen Sie diese vereinfachte Berechnung. Es geht um die Hebelwirkung abgeschlossener Projekte, die hier deutlich wird. Wer es schafft einen verhältnismäßigen kleinen Teil der Projekte früher abzuschließen, steigert den unternehmerischen
35 Mini-Rock-Festival, http://de.wikipedia.org/wiki/Mini-Rock-Festival, abgerufen 5. Januar 2014
Nutzen für den Verlag 165
Nutzen um ein Mehrfaches. Denn nur abgeschlossene Projekte bringen Nutzen. Genau diesen Nutzen soll die Projektmanagement-Methodik liefern. Tabelle 8: Hebelwirkung guten Projektmanagements.36 Jahr 1
Jahr 2
Anzahl abgeschlossene Projekte
20
24
Nutzen der Projekte: 1 Million je abgeschlossenem Projekt (in Millionen Euro)
20
24
abzüglich Variable Kosten der Projekte, 0,5 Millionen Euro je abgeschlossenem Projekt (in Millionen Euro)
10
12
ergibt Deckungsbeitrag (in Millionen Euro)
10
12
abzüglich fixe Betriebskosten (in Millionen Euro)
8
8
ergibt Gewinn (in Millionen Euro)
2
4
Darüber hinaus kann, wie an mehreren Stellen in diesem Buch erwähnt, solides Projektmanagement einen strategischen Wettbewerbsvorteil darstellen. Gerade wenn es darum geht, neue Geschäftsmodelle einzuführen, neue Technologien für den Verlag zu erschließen oder neue Einnahmequellen zu eröffnen, sind handhabbares Risiko und eine hohe Erfolgswahrscheinlichkeit wichtig für die Zukunft des Unternehmens. Auch diese beiden Faktoren dürfen Sie von gutem Projektmanagement erwarten. Neben der Tatsache, dass sich die Menschen dank cleverem Projektmanagement in und mit der Arbeit an Projekten leichter tun.
36 Vgl. Theory of Constraints - Optimales Multiprojektmanagement - Teil 1: Multitasking abbauen Leistungsfähigkeit steigern, Uwe Techt, Projektmagazin 11/2008, S. 2
Quellenverzeichnis Bärentango – Mit Risikomanagement Projekte zum Erfolg führen, Tom DeMarco/ Timothy Lister, Hanser, 2003 Das Harvard Konzept, Roger Fisher, William Ury, Bruce Patton, Campus, 2006 Das Projektmanagement der olympischen Spiele in London 2012 - Leseprobe, https://www.projektmagazin.de/Klaus-Grewe-Projektmanagement-Olympische-Spiele-2012, 13. Juli 2013 Der Projektstrukturplan ist kein Ressourcenplan, Projektmensch-Blog, Holger Zimmermann, http:// blog.projektmensch.com/2012/02/29/ein-projektstrukturplan-ist-kein-ressourcenplan/, abgerufen 7. Januar 2014 Die Weisheit der Vielen, James Surowiecki, Goldmann, 2007 Führungsaufgabe Moderation, Jan Bodo Sperling und Jacqueline Wasseveld, 4. Auflage, wrs Verlag, 2000 Für die, die (zu) viele Projekte haben: die Projekt-Pipeline – (1) Grundlagen, Projektmensch-Blog, Holger Zimmermann, http://blog.projektmensch.com/2010/08/17/fur-die-die-zu-viele-projekte-haben-die-projekt-pipeline-1-grundlagen/, 15. August 2013 Mini-Rock-Festival, http://de.wikipedia.org/wiki/Mini-Rock-Festival, abgerufen 5. Januar 2014 Projekte erfolgreich managen, Dr. Thor Möller u.a., 45. Aktualisierung, August 2011, Kapitel 7.2.5 Projektmagazin-Glossar „Rolle“, https://www.projektmagazin.de/glossarterm/rolle, abgerufen 26. August 2013 Projektmanagement: Methoden, Techniken, Verhaltensweisen, Hans-Dieter Litke, Hanser, 5. Auflage, 2007 Projektmanagement, Hans-Dieter Litke u.a., Haufe, 2. Auflage, 2012 Projektmanagement-Fachmann, Band 1, ohne Autorennennung, RKW-Verlag, 7. Auflage, 2003 Projektstart: Gemeinsames Verständnis für die Ausgangslage schaffen, Projektmensch-Blog, Holger Zimmermann, http://blog.projektmensch.com/2013/06/05/projektstart-gemeinsames-verstandnis-fur-die-ausgangslage-schaffen/, abgerufen 5. Juni 2013 Schluss mit dem Scheitern, Christoph Kucklick, Zeit Magazin, Nr. 1/2014 Stages of Small-Group Development Revisited, Bruce W. Tuckman/ Mary Ann C. Jensen, Group & Organization Studies, Dezember 1977 Stuttgarter Nachrichten Online, Dossier zu Stuttgart 21, http://www.stuttgarter-zeitung.de/stuttgart21, abgerufen 26. August 2013 Tanz mit dem Glück, Spyros Makridakis u.a., Tolkemitt Verlag bei Zweitausendeins, 2010 The Psychology Of Behaviour At Work: The Individual In The Organisation, Adrian Furnham, Psychology Press, 2005 Theory of Constraints - Optimales Multiprojektmanagement - Teil 1: Multitasking abbauen - Leistungsfähigkeit steigern, Uwe Techt, Projektmagazin 11/2008 Unternehmenswandel gegen Widerstände: Change Management mit den Menschen, Klaus Doppler u.a., Campus Verlag, 2002 Wer von Abteilungen redet, denkt nicht in Projekt, Projektmensch-Blog, Holger Zimmermann, http:// blog.projektmensch.com/2012/09/03/wer-von-abteilungen-redet-denkt-nicht-in-projekt/, abgerufen 3. September 2013
Weitere hilfreiche Quellen und Buchtipps Agiles Projektmanagement mit Scrum, Ken Schwaber, Microsoft Press Deutschland, 2007 Das Mind-Map-Buch: Die beste Methode zur Steigerung Ihres geistigen Potenzials, Tony Buzan, Barry Buzan, mvg Verlag, 2013 Der Termin: Ein Roman über Projektmanagement, Tom DeMarco, Carls Hanser Verlag, 2007 Die Kritische Kette: Das neue Konzept im Projektmanagement, Eliyahu M. Goldratt, Campus Verlag, 2002 Kreativität: Wie Sie das Unmögliche schaffen und Ihre Grenzen überwinden, Mihaly Csikszentmihalyi, Klett-Cotta, 2010 openPM, http://www.openpm.info, openPM e.V. PM-Blog, http://www.pm-blog.com, Hagen Management GmbH Projektmensch-Blog, http://www.projektmensch-blog.com, Holger Zimmermann Spielräume. Projektmanagement jenseits von Burn-out, Stress und Effizienzwahn, Tom DeMarco, Hanser Fachbuch, 2001
Abbildungsverzeichnis Abbildung 1: Ein Routineprozess sorgt dafür, dass jeder weiß, was er wann wie mit wem zu tun hat. Bei sich wiederholenden Tätigkeiten sorgt das für Effizienz. 16 Abbildung 2: Aus Projektmanagement-Sicht sind die organisatorischen Phasen Projekteinrichtung, Projektplanung, Umsetzung sowie Übergabe und Abschluss eine hilfreiche Gliederung des Vorhabens. 19 Abbildung 3: Wichtige Meilensteine aus Sicht des Projektmanagement 19 Abbildung 4: Von der Idee bis zur Projektskizze ist ein gewisses Maß an Planung nötig. 20 Abbildung 5: Die Projektskizze ist Grundlage für die Zusammenarbeit von Projektleiter, Auftraggeber und Projektteam. Sie wird erst diskutiert und dann freigegeben. 24 Abbildung 6: Die Vorlage „Projektmandat“ dient dazu, Auftragsklarheit zwischen Projektleiter und Auftraggeber herzustellen. 34 Abbildung 7: Teamphasen – aus Basismodule (4–16 HZ). Eignet sich gut als Erklärungsmodell für die Gruppe. Die Gärung ist das „Tal der Tränen“, durch das die Gruppe durch muss. 40 Abbildung 8: Mit der Johari-Fenster lassen sich modellhaft die Hintergründe der Teamentwicklung erklären. 41 Abbildung 9: Ziel der Teamentwicklung ist die Vergrößerung des öffentlichen Ich, um die Zusammenarbeit durch leichtere Interaktion der Beteiligten produktiver zu machen. 42 Abbildung 10: Das Ziel ist es am Ende wieder unten am Berg zu sein mit schönen Erinnerungen im Kopf und schönen Fotos in der Tasche. Niemand will oben auf dem Berg verhungern. 49 Abbildung 11: Vorlage Projektziel 53 Abbildung 12: Beispielhafter Ausschnitt einer Zielhierarchie für das Beispielprojekt. 54 Abbildung 13: Vorlage Projektstart-Workshop 61 Abbildung 14: Die oberste Ebene des Projektstrukturplans beschreibt zu bearbeitende Themengebiete. 64 Abbildung 15: Projektstrukturplan Teilthemen beziehungsweise Teilaufgaben auf tiefer liegenden Ebenen. 64 Abbildung 16: Auf der untersten Ebene des PSP werden die Arbeitspakete definiert. 65 Abbildung 17: Der vollständige PSP zeigt den Gesamtumfang der zu erledigenden Tätigkeiten. 66 Abbildung 18: Grafische Aufbereitung der Projektphasen und Einordnung in die Projektmanagement-Phasen 69 Abbildung 19: Phasenplan des Beispielprojekts mit Phase „Experimentieren & Lernen“ 71 Abbildung 20: Beispiel für einen Teil der Aktivitätenliste im Projektstrukturplan 73 Abbildung 21: Tätigkeiten innerhalb eines Arbeitspakets in Reihenfolge bringen 77 Abbildung 22: Um einen ersten Zeitplan zu erstellen, wird die Dauer jeder einzelnen Tätigkeit geschätzt. 78 Abbildung 23: Darstellung des Zeitplans als Gantt-Diagramm. Enthält dieselben Informationen wie Abbildung 22 78 Abbildung 24: Leistungen, die extern erledigt werden, können als Sammelvorgang in den Zeitplan aufgenommen werden. Für diesen Sammelvorgang erstellt der externe Partner einen detaillierten Zeitplan. 79 Abbildung 25: Betrachtet man die relative Wahrscheinlichkeit verschiedener Erledigungsdauern einer Tätigkeit, entsteht eine Kurve, die der Gaußschen-Normalverteilung nahe kommt. 80 Abbildung 26: In den Projektplan wird der Wert übernommen, der eine angemessen hohe Wahrscheinlichkeit hat, dass er ausreicht. Im Beispiel der 75-Prozent-Wert. 81 Abbildung 27: Schraffiert dargestellt der kritische Pfad für ein Arbeitspaket. Er bestimmt die Gesamtlaufzeit der Aufgabenbearbeitung. 82 Abbildung 28: Puffer ist arbeitsfreie Zeit zwischen einer Tätigkeit und ihrem Nachfolger. 83 Abbildung 29: Beispielhafter Zeitplan für die Erstellung eines Texts im Projektplan, wenn kein Standardablauf des Redaktionssystems genutzt wird. 86 Abbildung 30: Beispielhafter Ablauf für die Erstellung eines Texts, wenn auf den Standardablauf eines Redaktionssystems zurückgegriffen wird. 87 Abbildung 31: Mindestens jedem Element des PSP auf oberster Ebene werden die Personen zugeordnet, die für die einzelnen Bereiche verantwortlich zeichnen. 90
168 Abbildungsverzeichnis Abbildung 32: Arbeitsaufwände werden einzeln für jede Tätigkeit geschätzt und hier im Beispiel in der Spalte „Aufwand“ erfasst. 91 Abbildung 33: Nach Zuordnung der Wunsch-Ressourcen ist klar, wann welche Ressource in welchem Umfang benötigt wird. 92 Abbildung 34: Das Arbeits- oder Ressourcenlastdiagramm zeigt die Auslastung in Prozent eines Arbeitstages über der Zeit. In diesem Fall ist keine Überlastung zu erkennen. 92 Abbildung 35: Beispiel für einen Zeitplan als Netzplan dargestellt mit einer Kollision, die zur Überlastung bei Mitarbeiter 1 führt. 93 Abbildung 36: Beispiel desselben Zeitplans wie in Abbildung 35, hier als Gantt-Diagramm dargestellt 93 Abbildung 37: Die ursprüngliche Planung führt zu einer Überlastung an Tag 1 (oben), die durch den verzögerten Beginn der nicht kritischen Aufgabe 1 um einen Tag vermieden wird (unten). 93 Abbildung 38: Überarbeiteter Zeitplan nach Abbau der Kapazitätsspitze an Tag 1, die zur Überlastung des Mitarbeiters 1 führte. 94 Abbildung 39: Eine einfache Projektkalkulation auf Basis des PSP. Für jede Tätigkeiten werden Sachkosten und Einnahmen geschätzt sowie die Personalkosten berechnet. 96 Abbildung 40: Der Stichtag, als Pfeil dargestellt, wird erreicht. Eine weitere Optimierung ist nicht nötig. 99 Abbildung 41: Der Stichtag liegt vor dem im Zeitplan erreichten Abschlusstermin der Tätigkeit. Eine weitere Optimierung ist nötig. 100 Abbildung 42: Zeitlicher Verzug. Die Abweichung der Realität gegenüber dem Basisplan ist der Normalzustand im Projekt. 103 Abbildung 43: In diesem Beispiel wurde der zeitliche Verzug kompensiert, indem bspw. Tätigkeit 4 mit mehr Personal bearbeitet wird. 103 Abbildung 44: Die Verzögerung bei Tätigkeit 3 hat keine Auswirkung auf den Projektabschluss. Darauf wird nicht reagiert. 104 Abbildung 45: Die Meilenstein-Trendanalyse in grafischer Form ist beliebt, da sie die grundsätzliche zeitliche Entwicklung eines Projekts auf einen Blick erkennbar macht. Hier ein Projekt, dessen Liefertermine sich verzögern. 106 Abbildung 46: Sachkostenkontrolle auf Basis einzelner Tätigkeiten. 108 Abbildung 47: Kostenaufstellung nach Einplanen der Kompensationsmaßnahmen bei Tätigkeiten 87 und 89. 108 Abbildung 48: Vorlage Änderungsantrag 113 Abbildung 49: Beispiel für das Planen der Aktivitäten der Qualitätssicherung, die in den Meilenstein „Livesystem ist verfügbar“ münden. 114 Abbildung 50: Vorlage Meilenstein-Freigabe 117 Abbildung 51: Die grafische Darstellung von Einstellung und Macht erleichtert die Stakeholderanalyse und das Ziehen von Schlüssen daraus. 124 Abbildung 52: Die Zwiebeldarstellung hilft, sich der Struktur des Projektteams bewusst zu werden und diese mit dem Team zu diskutieren. 125 Abbildung 53: Beispiel für die Unterteilung der Regelkommunikation (schematische Darstellung). 127 Abbildung 54: Berichtspyramide im Falle von Auftraggebern, die nur negativ kritisieren. 130 Abbildung 55: Vorlage Projektbericht 133 Abbildung 56: Die umrandete Tätigkeit wird aufgenommen, um die Dokumentation sicherzustellen. 137 Abbildung 57: Oberste Ebene des Projektstrukturplans für die Einführung von ProjektmanagementStandards 151 Abbildung 58: Beispiel eines Qualifikationsmodells für Projektleiter 154 Abbildung 59: Beispiel für die Phasen der Einführung von Projektmanagement-Standards 162
Tabellenverzeichnis Tabelle 1: Pragmatische Risikoanalyse. Erst werden Risiken gelistet, dann bewertet, anschließend für die wesentlichen Risiken Gegenmaßnahmen entwickelt. 46 Tabelle 2: Phasen und Meilensteine des Beispielprojekts „Neue Buchreihe mit Webportal“ 68 Tabelle 3: Beispiel einer Änderungshistorie im Dokument. 109 Tabelle 4: Beispiel für eine Aufgaben-Kompetenzen-Verantwortungsmatrix (AKV-Matrix), die auch kurz als „Kompetenzmatrix“ bezeichnet wird. 119 Tabelle 5: Beispiel einer alternativen Rollenklärung, die die Diskussion im Team stärker fördert. 120 Tabelle 6: Beispiel für einen einfachen Kommunikationsplan zur Regelkommunikation 128 Tabelle 7: Beispiel für eine einfache Portfolio- und Berichtssteuerung über eine Tabelle 158 Tabelle 8: Hebelwirkung guten Projektmanagements. 165
Über den Autor Holger Zimmermann ist überzeugt davon, dass Projekte ein herausragendes Instrumentarium bieten, um Unternehmen ein dauerhaftes Alleinstellungsmerkmal und neue, zukunftsfähige Geschäftsmodelle zu verschaffen. „Mit Projekten ist mehr möglich, als man ahnt.“ ist ihm dabei Leitsatz. Mit seiner Firma „Projektmensch.“ unterstützt er Projektteams, Projektleiter und Führungskräfte in deren Projekten. Der Unternehmer ist in unterschiedlichen Branchen tätig und liefert einen außergewöhnlichen Querschnitt der Anwendung von Projektmanagement-Methoden. Seit 1997 ist er selbstständig, seit 2008 lehrt der Diplom-Wirtschaftsingenieur (FH) für die Akademie des Deutschen Buchhandels. Zimmermann war und ist außerdem Dozent an verschiedenen Hochschulen und Herausgeber des Projektmensch-Blog. Als Gründungsmitglied des openPM e.V. ist es ihm ein Anliegen, Praxiswissen für Projektmanagement in Unternehmen zu tragen.