projektManagementaktuell | AUSGABE 5.2015 82 WISSEN seine Bedeutung. In der Quantenphysik sagen wir auch, mit der Messung kollabiert das System der überlagernden Zustände. Was hat das nun mit Projektmanagement zu tun? Erfolgreiche Projekte basieren auf sinnvollem Projektcontrolling und erfolgreicher Projektsteuerung. Beides lebt davon, den aktuellen Zustand eines Projektes korrekt messen zu können. Und hier fängt nun oft das Problem an. Wenn wir ein großes Projekt durchführen wollen, dann wissen wir, dass es zu Abweichungen vom Projektplan kommen kann. Und niemand von uns mag es, erst am Ende des Projektes diese Abweichungen zu entdecken oder festzustellen, dass das Projekt ein Fehlschlag war. Deutlich angenehmer ist es, von diesen Abweichungen früher zu erfahren. Denn dann können wir darauf reagieren und das Projekt immer noch zum Erfolg führen. Diese Erkenntnis ist nun nicht neu im Projektmanagement und Generationen von Projektmanagern haben sich schon mit der Fortschrittskontrolle von Projekten beschäftigt und entsprechende Instrumente entwickelt. Und doch scheitern immer wieder Projekte scheinbar überraschend in der Schlussphase. Wie kann das sein? 1935 schlug der Physiker Erwin Schrödinger ein faszinierendes Gedankenexperiment vor. In eine undurchsichtige Stahlkammer wird eine Katze zusammen mit einer winzigen Menge einer radioaktiven Substanz, einem Geiger‚schen Zählrohr und einem Kolben Blausäure eingesperrt. Bei der radioaktiven Substanz besteht eine 50-prozentige Chance, dass innerhalb einer Stunde eines der Atome zerfällt, was von dem Geiger‚schen Zählrohr gemessen würde und in diesem Falle das Zertrümmern des Kolbens mit der Blausäure durch einen Hammer auslösen würde. Mit dem Ergebnis, dass die Katze stirbt. Dann wird eine Stunde gewartet. Da nur eine 50-prozentige Chance besteht, dass eines der Atome zerfällt, existiert die Katze in dieser Stunde gleichzeitig in zwei sich wiedersprechenden Zuständen: Sie ist tot und sie ist lebendig (und vermutlich ziemlich verärgert). Erst wenn wir nach Ablauf der Stunde die Stahlkammer öffnen und nachsehen, wird einer der beiden Zustände real und der andere verliert Die Wurzel unseres Problems liegt in der Art, wie wir Projekte planen. Bevor wir mit der Umsetzung anfangen, • sammeln wir alle Anforderungen an das zu erstellende Ergebnis, • erstellen wir daraus ein detailliertes fachliches Konzept, • erzeugen wir basierend auf dem fachlichen Konzept ein detailliertes und vollständiges technisches Konzept, • leiten wir aus dem technischen Konzept alle notwendigen Tätigkeiten ab, • erstellen wir den Projektplan, der genau festlegt, wer bis wann was tun wird. Das Ergebnis ist quasi die vollständige Beschreibung des Lösungsweges. Die regelmäßige Fortschrittskontrolle findet nun in der Regel als Abgleich zwischen „Tätigkeiten, die bis jetzt hätten fertig sein sollen“ und „Tätigkeiten, die bis jetzt tatsächlich geleistet wurden“ statt. Wir messen den Projektfortschritt also auf der Basis „geleisteter Arbeit“ gegen „geplante Arbeit“. Klingt erst mal logisch. Der Irrtum dieses Verfahrens liegt in der Annahme, dass der Projektplan vollständig und die Umsetzung fehlerfrei ist; und der Schlussfolgerung, dass damit das Befolgen des Projektplanes automatisch zum gewünschten Projektergebnis führt. Herauszufinden, dass dem allerdings oft nicht so ist, das ist nur durch realistisches Testen der Ergebnisse möglich. In der klassischen Projektplanung findet dies zumeist erst zum Ende des Projektes statt und da kann dann das Erwachen schmerzhaft sein. Wir finden eventuell erst in der Schlussphase des Projektes heraus, dass das Produkt nicht fertig ist oder nicht funktioniert, obwohl doch alle geplanten Tätigkeiten durchgeführt wurden. Jetzt noch das Projekt innerhalb von Time & Budget zu retten, ist schier unmöglich. Schrödingers Katze im PM … oder: wie geht es eigentlich meinem Projekt? Autor: Carsten Czeczine >> Für eilige Leser Gutes Projektmanagement bedeutet nicht nur das Planen und Verteilen von Arbeit, sondern auch das regulierende Eingreifen bei Abweichungen und Störungen. Die Grundlage dafür ist eine saubere Fortschrittskontrolle, mit der erst das Risiko eines Projektfehlschlages früh erkannt werden kann. Trotz langjähriger unangenehmer Erfahrungen mit Projekten, deren Scheitern erst in den Schlussphasen ersichtlich wurde, basiert die Fortschrittskontrolle in vielen Projekten immer noch auf veralteten Ansichten. In diesem Beitrag wollen wir ein alternatives Modell der Fortschrittskontrolle aus der Welt der agilen Vorgehensweisen vorstellen, das den Fortschritt auf Basis der lauffähigen Bestandteile des Projektergebnisses bewertet, und damit eine neue Sichtweise anbieten. PM-aktuell_5-2015_Inhalt_01-100.indd 82 10.11.2015 13: 28: 07 Uhr WISSEN 83 projektManagementaktuell | AUSGABE 5.2015 ßen Funktionalitäten sein, die die Entwicklung Ihrer Produkte so komplex und herausfordernd macht? Ein anderer gerne genommener Einwand ist: „Wir können nicht innerhalb von vier Wochen etwas entwickeln und vollständig testen. Unsere Tests sind dafür viel zu aufwendig.“ Sind diese Tests zu aufwendig, weil sie so gut und umfassend sind? Oder weil sie nicht effizient genug durchgeführt werden? Auch hier gilt die gleiche Antwort wie zuvor. Ja, in einigen Kontexten sind die Tests und anderen Abnahmeverfahren tatsächlich, selbst bei bester Organisation, nicht in einem derart kurzen Zeitraum machbar. Und auch hier ist das deutlich seltener der Fall, als es zuerst scheint. Was wir also sehen, ist, dass es für die Umstellung von Projekten auf ein realistisches Bewertungs- und Messverfahren in kurzen Intervallen nicht einfach mit dem Beschluss getan ist, sich alle vier Wochen die Ergebnisse ansehen zu wollen. Tatsächlich ist es dazu notwendig, den gesamten Prozess, wie Produkte und Projekte geplant, entwickelt und getestet werden, unter die Lupe zu nehmen und auf das Ziel der stückweisen Abnahme in kleinen Inkrementen umzustellen. Eine Anstrengung, die sich jedoch immer lohnt, denn sie führt zu einem Unternehmen, das in der Zukunft in kürzerer Zeit die besseren Produkte in besserer Qualität entwickeln wird. Überlassen wir also Schrödingers Katze den Physikern und arbeiten lieber mit eindeutigen Zuständen. In der Quantenphysik dient Schrödingers Katze als Parabel, um den quantenmechanischen Effekt der Zustandsüberlagerung zu veranschaulichen, und führt dort zu neuen Erklärungsversuchen unserer Welt oder so faszinierenden Ideen wie der Theorie unendlich vieler paralleler Universen. Im Projektmanagement dahingegen führt Schrödingers Katze zu Kopfschmerzen und zu manchmal scheinbar unendlicher Frustration. Hier lässt sich Schrödingers Katze übrigens auch gut mit einer alten Weisheit der Dakota-Indianer kombinieren: Wenn dein Pferd tot ist, steig ab! Diese Weisheit wird gerne im Kontext des Projektmanagements zitiert, um klarzumachen, dass gescheiterte Projekte losgelassen werden sollen. Aber wie wir oben schon gesehen haben, scheitern viele an der Frage, ob das Pferd denn wirklich schon tot ist. So gesehen, leiden viele Projekte sogar an Schrödingers Pferd!  durchführen müssen, damit die Funktion wirklich funktioniert. Zum Beispiel, dass Sie in der Test- oder Abnahmephase Ihres Projektes feststellen, dass eine Funktionalität nicht ordnungsgemäß funktioniert und Sie diese nun nachbessern müssen. Das ist Aufwand, den Sie höchstens indirekt durch Puffer eingeplant haben. Wobei Sie aber nicht wissen können, wie viel Puffer Sie tatsächlich brauchen werden. Oft ist es das, was Ihnen am Ende Ihres Projektes die Kopfschmerzen bereitet. In Scrum bewerten wir am Ende jeder Iteration, welche Funktionalitäten wirklich fertig sind und welche nicht. Wir bekommen damit einen realistischen Überblick über den Zustand unseres Projektes und eine realistische Information darüber, wie schnell wir tatsächlich sind. Auf diese neue Art der Bewertung umsteigen führt in vielen Projekten erst mal zur Ernüchterung. Plötzlich liegt schwarz auf weiß der Nachweis vor, dass die ursprünglichen Erwartungen mehr oder weniger zu optimistisch waren. Gerne wird nun die überraschend geringe Entwicklungsgeschwindigkeit erst mal dem Mehraufwand durch das direkte Testen zugeschrieben. Und Sie ahnen schon, welche Maßnahme dann gerne als Erstes zur Steigerung der Projektperformance gewählt wird. Doch das ist purer Selbstbetrug, diesen Aufwand zum Testen und Nachbessern müssen Sie so oder so betreiben. Je weiter Sie ihn nach hinten verschieben, desto mehr erhöhen Sie das Risiko eines Projektfehlschlages. In erfolgreichen Projekten stellen wir uns den Problemen, sobald sie auftreten, und reduzieren damit Projektrisiken so gut wie möglich. Meine Lieblingsfrage, die ich Projekt- und Produktmanagern immer wieder gerne stelle, ist: „Wann möchten Sie wissen, dass Sie ein Problem in Ihrem Projekt haben? “ Und die einzige sinnvolle Antwort darauf lautet: „So früh wie möglich! “ Je früher im Projekt Sie wissen, dass Sie ein Problem haben, umso mehr Optionen haben Sie noch, dieses Problem zu lösen und das Projekt so erfolgreich zu Ende zu führen. „Ja, aber bei uns ist es nicht möglich, innerhalb von vier Wochen eine ganze Funktionalität zu realisieren.“ Wirklich? In der Tat gibt es vereinzelte Themenkomplexe, in denen Kernfunktionalitäten nicht so weit reduzierbar oder sinnvoll zerlegbar sind. Aber das ist bei Weitem nicht so oft der Fall, wie es uns viele Projektmanager oder Produktverantwortliche glauben machen wollen. Denken Sie selber mal darüber nach, könnte es genau diese Sichtweise von zu gro- Der Grund für diese späte Erkenntnis ist: Wir messen das Falsche. Wir messen die Menge an geleisteter Arbeit und vergleichen das mit der Menge an Arbeit, von der wir glauben, dass sie notwendig ist. Was wir nicht messen, ist das erzielte Ergebnis. Damit verbleibt unser Projekt trotz einer scheinbaren Messung in einem überlagerten Zustand, es ist gleichzeitig ein voller Erfolg und ein totaler Misserfolg. Im Bild von Schrödingers Katze wäre das so, als würden wir den Zustand der Katze rein durch das Verstreichen der Zeit bestimmen wollen, ohne dabei die Tür der Stahlkammer zu öffnen. Wenn wir ein Projekt bewerten wollen, dann stellt sich zuerst die Frage nach dem erzielten Ergebnis, also was das erzeugte Produkt kann. Dicht gefolgt von der Frage nach den Kosten. Niemand wird uns aufrichtig für unseren unermüdlichen Arbeitseinsatz und die vielen geleisteten Stunden danken, wenn das Ergebnis nicht stimmt. Oder haben Sie schon Lobeshymnen für die vielen Stunden Arbeit gehört, die in den neuen Berliner Flughafen gesteckt wurden? Nein, was unsere Kunden an erster Stelle interessiert, ist: Ist das Produkt fertig und funktioniert es? Wie können wir dieses Problem der falschen Fortschrittsmessung lösen? Nur indem wir in kurzen Abständen die Tür zur Stahlkammer öffnen und uns vom tatsächlichen Zustand der Katze überzeugen. Wir lassen das System der überlagernden Zustände durch die konkrete Messung kollabieren. Im Projektmanagement bedeutet das, dass wir uns in kurzen Abständen die tatsächlichen Ergebnisse ansehen, die bisher erzielt wurden. Das Projektmanagement-Framework Scrum zeigt, wie das funktionieren kann. In Scrum werden innerhalb kurzer Iterationen von maximal vier Wochen Länge sogenannte potenziell auslieferfähige Produktinkremente erzeugt. Das bedeutet, es werden immer vollständige Funktionalitäten erstellt, und zwar in finaler Marktqualität. Finale Marktqualität bedeutet in diesem Kontext, dass innerhalb der Iteration alle notwendigen Tätigkeiten durchgeführt werden, um diese Funktionalität ausliefern zu können. Bei den meisten Produkten würde das z. B. das vollständige Testen und Dokumentieren bedeuten. Das Ziel ist, dass eine Funktionalität am Ende einer Iteration wirklich fertig ist, es existieren keine versteckten Restaufwände für diese Funktionalität mehr. Was sind jetzt versteckte Restaufwände? Versteckte Restaufwände sind alle die Tätigkeiten, die Sie ungeplant zu einem späteren Zeitpunkt PM-aktuell_5-2015_Inhalt_01-100.indd 83 10.11.2015 13: 28: 07 Uhr projektManagementaktuell | AUSGABE 5.2015 84 WISSEN agilen Projektmanagement- und Entwicklungsmethoden. Zusätzlich referiert er regelmäßig zu diesen Themen auf nationalen und internationalen Konferenzen. Anschrift: binaris informatik GmbH, Elisabethstraße 5, 40764 Langenfeld, Tel.: 0151/ 24 03 91 15, E-Mail: Carsten.Czeczine@ binaris-informatik.de Autor Carsten Czeczine ist Trainer und Coach bei binaris education und unterstützt branchenübergreifend Unternehmen bei der Einführung und Optimierung von Schlagwörter finale Marktqualität, Fortschrittskontrolle, Projektmanagement, Schrödingers Katze, Scrum, versteckte Restaufwände Kompetenzelemente der NCB 3.0 4.1.12 Ressourcen, 4.1.13 Kosten und Finanzmittel, 4.1.16 Überwachung und Berichtswesen Die neue ICB4 ist da ! Die IPMA hat auf ihrem Weltkongress in Panama den globalen Standard für individuelle Projekt-, Programm- und Portfoliomanagementkompetenzen (ICB4) veröffentlicht. Neben der vollständigen Überarbeitung der Projektmanagementkompetenzen umfasst der Standard nun auch Wissen, Fertigkeiten und Fähigkeiten, die für ein erfolgreiches Arbeiten im Programm- und Portfoliomanagementumfeld notwendig sind. Der Standard richtet sich sowohl an Personen, die ihre Kompetenz im Projekt-, Programm- und Portfolioumfeld entwickeln und zertifizieren lassen wollen, als auch an alle, die sich professionell mit der Kompetenzentwicklung beschäftigen (beispielsweise Coaches, HR, Trainer, Hochschullehrer). Auf Basis dieses Standards werden weltweit Trainingsmaterialien, Zertifizierungsrichtlinien und Fachpublikationen erstellt werden. Die ICB4 ist ein Kompetenz- und kein Prozessstandard. Anders als beispielsweise das PMBOK, Prince2 oder Scrum ist daher nicht beschrieben, wie Projekte, Programme und Portfolios gesteuert werden sollten. Die ICB4 definiert vielmehr, welche Kompetenzen jede Einzelne und jeder Einzelne benötigt, um erfolgreich in diesen Domänen handeln zu können. Die Grundlage für die neue ICB4 bildet eine klare dreistufige Architektur, die für alle drei Domänen identisch ist: Sie besteht aus 1.) Kompetenzbereichen, 2.) Kompetenzelementen und 3.) Key Competence-Indikatoren. 1. Jede Domäne ist in die drei Kompetenzbereiche „People“, „Practice“ und „Perspective“ gegliedert. Damit wurde das bereits mit der ICB3 erfolgreich eingeführte Konzept des Eye-of-Competence beibehalten, aber wesentlich prägnantere Begriffe eingeführt. 2. Auf der nächsten Ebene sind 29 Kompetenzelemente definiert. Jedes Element besteht aus einer prägnanten Definition, dem Zweck und einer ausführlichen Beschreibung. Ergänzt wird jedes Element durch eine exemplarische Auswahl an notwendigem Wissen und notwendigen Fertigkeiten. 3. Die Kompetenzelemente werden wiederum durch das ganz neue Konzept der „Key Competence-Elemente“ (KCI) konkretisiert. Diese legen fest, welche Fertigkeiten und Fähigkeiten entwickelt werden müssen und wie diese beobachtet und gemessen werden können. Während die Kompetenzelemente für die drei Domänen (fast) identisch sind, unterscheiden sie sich in der Ausgestaltung der KCIs. Während zur Umsetzung eines Projekts zum Beispiel die Strategie verstanden werden muss, realisiert ein Programm einen wesentlichen Teil der Strategie, und ein Portfoliomanager stellt mittels seiner Arbeit sicher, dass die gesamte Unternehmensstrategie adressiert wird. Die neue ICB4 beschreibt Kompetenz als „application of knowledge, skills and abilities in order to achieve the desired results“. Diese Definition schließt Wissen („Knowledge“), Fertigkeiten („Skills“), Fähigkeiten („Capabilities“) ein. Kompetenz ist außerdem nicht Selbstzweck, sondern dient dem Erreichen eines gewünschten Ergebnisses. Im Kompetenzbereich „People“ sind personale und soziale Kompetenzen definiert. Zu den personalen Kompetenzen zählen beispielsweise Selbstmanagement, Integrität, Kommunikation. Die Kompetenz zur Interaktion mit anderen wird definiert durch Kompetenzen wie z. B. Leadership, Teamwork, Umgang mit Konflikten. Der Kompetenzbereich „Practice“ beschreibt das funktionale Handwerkzeug eines Projekt-, Programm- und Portfoliomanagers. Entsprechend unterscheidet sich dieser Bereich zwischen den Domänen am deutlichsten. Neu ist das Kompetenzelement „Design“, welches vor dem Start jedes Vorhabens die wesentlichen Elemente zur erfolgreichen Umsetzung festlegt (Architektur). Programme, nicht nur als ein Bündel zusammenhängender Maßnahmen verstanden, dienen unter anderem dem Erreichen eines strategischen Ziels mittels signifikanter Anpassung von Strukturen, Prozessen und Verhalten, um einen vordefinierten Nutzen zu realisieren. Daher wurden hier die Kompetenzelemente „Change/ Transformation“ und „Benefits Realisation“ beschrieben. Im komplett neu strukturierten Bereich „Perspective“ werden alle Kompetenzen im Umfeld des Vorhabens zusammengefasst. Dieser Bereich enthält nun die Kompetenzen „Strategie“, „Governance, Structures and Processes“, „Compliance, Standard and Regulations“, „Power and Interests“ und „Cultures and Values“. Durch ihre modulare Architektur ist die neue ICB auf weitere Domänen wie Consulting, Training, Coaching, Sponsorship oder PMOs erweiterbar. Erste Erweiterungen sind bereits in Vorbereitung. Nach der einstimmigen Freigabe der ICB4 durch alle 62 IPMA-Landesverbände ist die englische Version bereits zum Download verfügbar. Sie ist unter Einbindung der gesamten IPMA umgesetzt worden und wurde in den letzten vier Jahren von einem internationalen Projektteam unter Führung des spm Vorstandsmitglieds Martin Sedlmayer und unter Mitarbeit von Dr. David Thyssen, GPM, und Marco Fuster, spm, entwickelt. Als Sponsor unterstützte Reinhard Wagner, IPMA-Präsident, das Vorhaben von Beginn an. Das Projekt zur Fachübersetzung ist bereits gestartet. Im Januar 2016 wird die ICB4 in deutscher Sprache in Deutschland, der Schweiz und in Österreich veröffentlicht werden. An dieser werden sich neue Trainingsmaterialien und Zertifizierungsdokumente orientieren. Die englische Version ist bereits jetzt kostenfrei zum Download verfügbar unter products.ipma.ch. Kontakt-E-Mails: martin.sedlmayer@spm.ch, david.thyssen@prometicon.de, marco.fuster@outlook.com PM-aktuell_5-2015_Inhalt_01-100.indd 84 10.11.2015 13: 28: 07 Uhr