Auf grundsätzlicher Ebene beispielsweise Agil vs. Wasserfall; oder konkreter auf Tool-Ebene MS Projekt vs. Basecamp oder Trello - und die mal eben erstellte Excel-ToDo-Liste dürften auch die meisten kennen.
Dabei werden allerdings häufig einige Basics viel zu selten diskutiert, die augenscheinlich sogar nicht jedem bewusst sind. Um jene grundlegenden Zusammenhänge soll es im Folgenden gehen.
Einsteigen möchte ich jedoch mit der Definition von Projektmanagement lt. DIN 69901:
Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Initiierung, Definition, Planung, Steuerung und den Abschluss von Projekten.Diese Definition formuliert einen riesigen Handlungsraum, den man immer präsent haben sollte, wenn man an Projektmanagement denkt.
10er Regel der Fehlerkosten
Projekt- und Qualitätsmanagement sind bei Agenturen an vielen Stellen eng miteinander verknüpft. Sicher sollte es einen losgelösten, expliziten Qualitätssicherungs-Prozess in einem Projekt geben, bevor ein Projekt Live geht, produktiv gestellt wird oder wie auch immer der Terminus heißt.Dennoch ist Qualitätsmanagement (oder Qualitätssicherung) keine singuläre Aufgabe gegen Ende eines Projekts, sondern eine andauernde Aufgabe während der kompletten Projektlaufzeit. Der Grund hierfür ist unter anderem die 10er Regel der Fehlerkosten oder im Englischen rule of 10.
Diese, durch Studien und Analysen (aus den 70er Jahren) belegte Regel der Qualitätssicherung besagt, dass die Kosten, einen Fehler zu beheben, in jeder Projektphase um den Faktor 10 steigen.
Ein Fehler, der mit einem zusätzlichen Aufwand von 10,- € in der Planungs-/Konzeptionsphase hätte vermieden oder behoben werden können, kostet in der Entwicklungsphase 100,- €, der Umsetzungsphase 1.000,- € und wenn er erst beim Kunden, also nach Auslieferung des Produkts auffällt, 10.000,- €.
Über den Faktor 10 würde ich mit mir diskutieren lassen, der mag branchen- oder produktspezifisch sein. Der grundlegende Zusammenhang, dass die Fehlerkosten mit einem Faktor, sagen wir mal zwischen 5 und 10, pro Projektstufe multipliziert werden, ist aber Fakt.
Diese Regel ist Bestandteil zahlreicher Publikationen aus unterschiedlichsten Branchen:
- Qualitätsmanagement im eCommerce, Prof. Dr. Georg Herzwurm
- Six Sigma Black Belt
- 10er-Regel der Fehlerkosten, Online-Verwaltungslexikon
- Die Wirtschaftlichkeit von Softwaretests, Cecconi + Partner
- Warum frühzeitige Tests in der Softwareentwicklung so wichtig sind, Paul Herwarth von Bittenfeld, //SEIBERT/MEDIA
Was macht man damit?
- Bevor man den nächsten Projektabschnitt, welcher auch immer das ist, beginnt, sollte man nochmal ganz genau darüber nachdenken, ob man nichts übersehen hat; auch gerne Feedback von Kollegen einholen.
- Jeder, der eine neue Aufgabe bekommt, sollte bevor er oder sie mit der Arbeit beginnt, ebenfalls nochmal genau überlegen, ob alle nötigen Informationen vorliegen, ob alles durchdacht ist.
- Man sollten immer damit rechnen, dass eine Aufgabe wieder zurückdelegiert wird - und es sollte jedem klar sein, dass man das macht, um obige Fehlerkette und die damit verbundenen Mehraufwände zu vermeiden.
- Es muss anerkannt, oder sogar cool sein, einen Fehler frühzeitig zu finden und an zu sprechen - egal auf welcher Ebene oder in welchem Prozessschritt.
Das Magische Dreieck
Dieser Begriff beschreibt die Abhängigkeit der drei Komponenten Qualität, Zeit und Kosten. Wegen der drei Elemente spricht man im englischen Sprachraum auch vom, wie ich finde besser passenden, triple constraint.In dem Modell geht man davon aus, dass man keine einzelne dieser drei zueinander in Zielkonkurrenz stehenden Komponenten ändern kann, ohne nicht auch mindestens eine andere zu ändern. Pessimisten sagen sogar, dass man nie alle drei zur Zufriedenheit eines Kunden auslegen kann.
Im Detail gilt also:
- Will ich die Qualität erhöhen, muss ich entweder die Zeit verlängern oder die Kosten erhöhen.
- Reduziert sich die zur Verfügung stehende Zeit, reduziert das entweder die Qualität oder erhöht die Kosten.
- Sollen die Kosten reduziert werden, reduziert sich ebenfalls die Qualität, oder aber man muss mehr Zeit einplanen.
Kritik
Kritiker dieses Modells führen an, dass Qualität nicht variabel ist. Daher findet man überwiegend leichte Modifikationen dieses Modells, in welchen der Begriff Qualität durch Scope (Leistungsumfang) ersetzt wird.Ich finde, dass man durchaus auch die Qualität reduzieren kann, wenn man diesen Begriff entsprechend interpretiert: Bezieht man Qualität nur auf Fehlerfreiheit, dann kann man in der Tat diese nicht reduzieren. Laut Duden steht Qualität für Güte oder charakteristische Eigenschaften (einer Sache, Person). Betrachtet man die Güte einer Software, einer Website o.Ä. mit Bezug auf die Erfüllung einer Aufgabe, die diese lösen oder unterstützen soll, ist der Leistungsumfang aber sehr wohl ein Bestandteil davon.
Daher drücken eigentlich beide Varianten das gleiche aus.
Was macht man damit?
Kunden, oder allgemeiner Stakeholder, tendieren dazu, diesen Zusammenhang, der in der Fachwelt nicht wirklich bestritten wird, zu ignorieren oder aus zu blenden. Oftmals kennen sie diesen auch gar nicht; klar, der Kunde ist kein Projektmanager.Umso wichtiger ist es, dass ein Projektmanager diesen im Kopf hat und sich nicht scheut, den Kunden damit zu konfrontieren.
Weitere Quellen:
- Projektmanagement, Wikipedia
- Das "Triple Constraint" im Projektmanagement, Dr. Stefan Hagen, pm-blog.de
- Understanding the Project Management Triple Constraint, Duncan Haughey
- Triple Constraints of Projects: Quality, Cost & Schedule, enterprise-pm.com
- Magisches Dreieck/Viereck in der Volkswirtschaft, Gabler Wirtschafslexikon
Grenzen der Parallelisierbarkeit von Arbeit
Folgenden Satz hat sicher schon jeder mal von Kunden gehört:Dann müsst ihr halt mit mehr Leuten dran arbeiten.Abgesehen davon, dass das natürlich - wir erinnern uns an das triple constraint - die Kosten erhöhen würde, kommt noch ein weiterer Umstand hinzu, der am besten mit einem Beispiel zu verdeutlichen ist:
Braucht ein Mann zum Ausheben einer Grube mit einer Länge, Breite und Tiefe vom je einem Meter 10 Stunden, dann müssten 20 Arbeiter ja in einer halben Stunde fertig sein. Fragt sich nur, wie 20 Arbeiter auf einer Grundfläche von 1 m² "kooperieren".
(Projektmanagement Für Ingenieure: Gestaltung Technischer Innovationen Als Systemische Problemlösung in Strukturierten Projekten, Walter Jakobi, Springer Verlag, 2010)Aus dem gleichen Buch stammt folgende Grafik:
Hier kommt ausschließlich der Kommunikationsaufwand im Team hinzu, es gibt jedoch noch weitere Zusammenhänge, die zu einem ähnlichen Effekt führen. Einer davon ist, dass gewisse Arbeiten zwingend sequenziell ausgeführt werden müssen und daher Prinzip bedingt nicht von weiteren Ressourcen profitieren.
Was macht man damit?
Einerseits hilft das Wissen um diesen Zusammenhang natürlich für die Argumentation in Richtung Kunde. Andererseits sollte sich jeder Projektmanager genau überlegen, ob der Break-Even, also die Stelle, ab der es nichts mehr bringt, weitere Ressourcen hinzu zu ziehen, schon erreicht ist, bevor er oder sie ein weiteres Teammitglied in das Projekt einbezieht. Nicht selten stehen Teammitglieder einem Projekt nicht zu 100% zur Verfügung, da sie noch andere Aufgaben haben. Dann ist es erheblich sinnvoller, an dieser Stelle an zu setzen.Ganzheitliches Projektmanagement
Gerne wird auch übersehen, dass ein Projekt nicht nur aus der Sachebene, sondern zu 80% aus der Sozialebene besteht - ein Zusammenhang, der in unterschiedlichen Kontexten unter dem Begriff Eisbergmodell zu finden ist. Eine kurze Suche nach "Eisbergmodell Projektmanagement" bei Google Images liefert reichlich Grafiken zu dem Thema.Ohne auf alle Details eingehen zu wollen, da das Rahmen sprengen würde, möchte ich festhalten, dass Begriffe wie Kommunikation, Kooperation, Motivation, Konfliktmanagement, Arbeitshaltung, (Herstellung des) Auftragskonsens, die Ergebnisakzeptanz, uvm. auch zum Projektmanagement und damit zu den Aufgaben des Projektmanagers gehören.
Was hervorragend zum nächsten Thema überleitet:
Das (Projekt-)Team
Reiner Lingmann, Director Project Management bei Pixelpark in Köln, der auch Seminare und Vorlesungen zu Projektmanagement hält, hat nicht nur dieses Thema hervorragend aufbereitet und behauptet:
Er nennt folgende Punkte, die ein Team "töten" können (verkürzt dargestellt):
- Banale Parolen, wie bspw. Qualität ist unser oberstes Ziel.
- Überstunden, die zwar kurzfristig zusammenschweißen, darüber hinaus aber für De-Motivation sorgen. Des Weiteren - und diesen Punkt halte ich für sehr wichtig - wird die Kompetenz des Projektmanagers in Frage gestellt, denn dessen Aufgabe ist es schließlich, das Team vor Überlastungen zu schützen!
- Interner Wettbewerb: Natürlich, denn das verhindert erfolgreich Wissensaustausch, Kooperation und das Vertrauen im Team.
- Management by Objectives, also das Führen durch rein quantitative Ziele, denn nur selten sind derartige Ziele sinnvoll für den Erfolg eines Projekts.
- Leistungsmessungen und -beurteilungen, insbesondere das öffentliche Loben oder Tadeln einzelner Teammitglieder, was schlussendlich wieder zu Wettbewerb führt.
- Großraumbüros, weil diese keine Möglichkeit zu Distanz und Individualität zulassen, durch häufige Störungen zu Produktivitätsverlusten führen und auch ein Gefühl der ständigen Kontrolle hervorrufen.
- Räumliche Trennung der Teammitglieder, denn ein Team braucht Nähe und Gemeinsamkeiten.
- Konformität: Unterschiede machen ein Team lebendig.
- Zu viel Kommunikation und auch zu wenig Kommunikation.
- Angst (z.B: vor Veränderung): People hate change. And that’s because people hate change. I want to be sure that you get my point. People really hate change. They really, really do. (DeMarco, Lister)
Daraus leitet Hr. Lingmann folgende Spielregeln im Team ab:
- auch unangenehme Themen ansprechen
- die eigene Unwissenheit nicht vertuschen
- keine eigennützigen Verfahren vorschlagen
- relevante Informationen und Hintergründe mitteilen
- Lob und Anerkennung aufteilen
- Ehrlichkeit und Offenheit anerkennen
- Raum für Dialoge und Diskussionen schaffen
- Gleichgewicht zwischen Plädieren und Erkunden behalten
Entfernen Sie alle Barrieren, die Menschen den Stolz auf ihre Arbeit nehmen. Dazu gehören insbesondere viele Arten von persönlichen Beurteilungen!
Was macht man damit?
Ein Projektmanager sollte seine Aufgabe auch darin sehen - und die Möglichkeit bekommen - das Team auf zu bauen und auf die gemeinsame Aufgabe ein zu schwören.Die Aufwandsschätzung
Nicht nur Projektmanager, sondern auch die Fachleute im Team müssen oft genug irgendwelche Aufwände schätzen - sei es um Zeitpläne zu erstellen oder ein Angebot oder Kostenvoranschlag erstellen zu können. Leider werden diese Schätzungen oft als exakt angesehen, obwohl inzwischen hinreichend belegt ist, dass diese sehr ungenau sind.Diesen Bereich möchte ich mit ein paar Zitaten einleiten:
- Work expands so as to fill the time available for its completion.
Frei übersetzt heißt dies: „Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht.“ – und nicht in dem Maß, wie komplex sie tatsächlich ist. Dies ist das sog. Parkinsonsche Gesetz, erstmals veröffentlicht in The Economist, Nr. 5856, 19.11.1955. - Hofstadters Gesetz, veröffentlicht in Gödel, Escher, Bach: An Eternal Golden Braid, 1979: Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.Die rekursive Art dieses Gesetztes ist eine Spiegelung der häufig beobachteten Tatsache, dass es trotz bester Absichten schwierig ist, den Aufwand einer komplexen Aufgabe zu schätzen, obwohl man weiß, dass die Aufgabe komplex ist.
- Und eine ganz alte Weisheit von Nils Bohr, 1922:
Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen. - Oder auch - etwas aktueller - Rolf Dobelli in Die Kunst des klaren Denkens: 52 Denkfehler, die Sie besser anderen überlassen, Seite 167 (Seit mind. Sept. 2013 in den Top 20 der Spiegel Sachbuch-Charts):
Je komplexer ein System und je länger der Zeithorizont, desto verschwommener wird der Blick in die Zukunft.
Im Lean- bzw. Agile Umfeld gab es sogar schon Diskussionen, ob Aufwandsschätzungen überhaupt sinnvoll sind bzw. als waste (Muda) betrachtet werden müssen. Der spannende Artikel Is Estimating A Wasteful Practice? aus dem Jahre 2008 fasst diese Diskussion zusammen.
Zwei weitere Komponenten gibt es zu betrachten:
Natürlich will der Kunde wissen, was ein Projekt kostet. Und meistens er will es wissen, bevor alle Anforderungen in einem Detailgrad vorliegen, der eine Schätzung erlaubt. Hinzu kommt im Agenturumfeld die Besonderheit, dass wir es mit Kreativprozessen zu tun haben. Wie lange dauert es, eine Kommunikations- oder Kreativ-Idee zu haben? Hm, 5 Minuten, 2 Tage, 1 Monat? Keine Ahnung!
Auch das Argument der Erfahrung zieht hier kaum, denn ich habe bisher kein Projekt erlebt, bei dem ich behaupten könnte, dass es einem anderen derart ähnlich war, dass man irgendwas hätte daraus ableiten können. Eine Untersuchung von 120 Projekten bei Boeing Systems scheint dies zu bestätigen:
- Ohne Rückgriff auf historische Daten ergaben sich Schätzungsabweichungen von +22% bis -148%
- Mit Rückgriff auf Historische Daten - also sozusagen objektive, formalisierte Erfahrungen - lagen diese immerhin noch bei +20% bis -24%.
Prof. Dr. Frank Dopatka hostet auf seiner Website eine Arbeit von Stanislas Mauser mit dem Titel Kostenschätzung in agilen Projekten: Planlos?, die sich explizit mit dem Thema auseinander setzt und diverse Methoden beleuchtet, mit denen man Aufwandsschätzungen verbessern kann.
Was macht man damit?
Schwer zu beantworten, denn eigentlich ist dies eine unlösbare Aufgabe. Die Agentur muss in der Regel einen - schlimmstenfalls mit Mitbewerbern vergleichbaren - Kostenvoranschlag abgeben; auf den die Agentur leider viel zu oft festgenagelt wird, weil einfach nicht mehr Budget da ist.Ich kann nur empfehlen, mit dem Kunden zu vereinbaren, dass die Umsetzung erst dann final angeboten wird, wenn die Anforderungsanalyse abgeschlossen ist. Alles andere ist völliges Glaskugel-Business.
Einen letzten, kurzen, aber dennoch sehr wichtigen Punkt habe ich noch:
The Magical Number 7 (plus/minus 2)
Gerorge A. Miller, ein 2002 verstorbener US-amerikanischer Psychologe mit langjähriger Professur an der Princeton University hat in dem Artikel The Magical Number Seven, Plus or Minus Two, veröffentlicht 1956 in The Psychological Review, dargelegt, dass ein Mensch etwa 7 (plus/minus 2) Informationseinheiten (engl. chunks) im Gedächtnis behalten kann. Dieses Limit ist genetisch bedingt und auch durch Training nicht änderbar.Er bestätigte damit eine Annahme des englischen Philosophen John Locke, der das Aufnahmevermögen von Erwachsenen untersuchte und daraus das sog. seven phenomenon ableitete - vor ca. 300 Jahren!
Was macht man damit?
Natürlich ist dieser Zusammenhang für das Projektmanagement relevant:- Es ist absolut sinnlos, dem Team oder einzelnen Mitgliedern eine Task-Liste an die Hand zu geben, die größer ist als ebendiese 7 Elemente.
- Projekt-Switching ist ein Killer für die Performance eines Mitarbeiters, denn dann bleiben pro Projekt noch weniger Elemente übrig, die im Gedächtnis sind.
- E-Mails mit Massenverteilern sind ebenso sinnlos. Eine der wichtigsten Aufgabe eines Projektmanagers ist die sinnvolle Distribution von Informationen; die relevante Info, zur richtigen Zeit an die richtige Person!
Fazit
Projektmanagement geht weit über das Erstellen und Verwalten von Aufgabenlisten hinaus. Ein fundiertes Wissen, nicht nur über diverse Projektsteuerungs-Methoden, sondern vor allem auch über Kommunikation, Motivation und sogar Psychologie, sowie die hier beschriebenen grundlegenden Zusammenhänge gehören zu zentralen Kompetenzen eines guten Projektmanagers.P.S.:
Bedanken möchte ich mich bei Hr. Lingmann, insbesondere, weil sich aus meiner Anfrage ob ich Teile aus seinem Vorlesungsscript übernehmen darf, ein wertvoller E-Mail Austausch ergeben hat.
Keine Kommentare:
Kommentar veröffentlichen