in Agilität, Lean Management, Produktmanagement, Projektmanagement - Standards, Theory of Constraints (ToC)

Produktmanagement statt Projektmanagement?

Einer von mehreren interessanten Vorträgen im Rahmen der PM-Welt 2018 war der von Conny Dethloff, dem Bereichsleiter für „Agile Product and Data Management“ bei OTTO. Er weckte besonderes Interesse, weil er bekannte, nicht mehr Projektmanagement zu betreiben. Genauer: „Wir haben Projekte als Strukturelement abgeschafft und Produktmanagement eingeführt“. Denn, so zusammenfassend am Ende seines Vortrages: „Projekte sind kein Naturgesetz. Taugen sie als Strukturierungselement nicht mehr, um Wert zu generieren, kann man sie durch Anderes ersetzen“.

Nun ist es immer gut, Dogmen in Frage zu stellen. Andererseits sollte man nicht nur um der Pointe willen bewährte Methoden über Bord werfen. Es lohnt sich also, etwas tiefer zu blicken und zu klären, was konkret gemeint ist. Daraus ergeben sich dann auch die Schlussfolgerungen für die eigene Praxis.

Zunächst meine ich, sollte man den Aufgabenbereich nennen, für den Conny Dethloff verantwortlich ist. Es geht um Business Intelligence (BI), die Identifikation relevanter Daten des Marktes und des Unternehmens. Diese Daten sind in Informationen umzuwandeln, die Entscheidungen ermöglichen und zu Handlungen führen. Er hat diesen Bereich nach Value Streams (Wertschöpfungsketten) gegliedert. Er bezieht sich dabei auf das Viable Systems Model, das auf Stafford Beer (1959) zurückgeführt wird. Dass diese Gliederung als Gegensatz zu Projekten gewertet wird überrascht: Projekte sind temporäre Organisationen, Wertschöpfungsketten sind wie Prozesse dauerhafte Organisationselemente. Es wird klar, dass es für den Alltagsbetrieb des BI-Bereiches einfach keine Projekte braucht, es sind End-to-End-Prozesse die auf einen Wertbeitrag für den Kunden ausgerichtet sind. Das könnte man in der Tat in Projektform abwickeln, allerdings wären das relativ kleine Projekte, die alle gleich strukturiert sind.  Dafür ist Projektmanagement tatsächlich nicht adäquat. Sollte er allerdings die derzeitige Gliederung seines Bereiches, die sich schlicht an der Struktur der (internen) Kunden ausrichtet, umstellen, wäre das wohl am besten in Form eines Projektes abzuwickeln.

Conny Dethloff nennt ein weiteres Paradigma, das er anwendet, die  Theory of Constraints (ToC) von E. Goldratt. Dieses Paradigma bestimmt die KPIs der Wertströme, nämlich: „Durchsatz an fertigen Lösungen, die Outcome generieren“, „Bestand an unfertigen Lösungen innerhalb des Wertstroms“ und „Betriebskosten für die Erstellung der Lösungen“. Nun ist auch die ToC ursprünglich ein Prozessmodell, allerdings gibt es eine authentische Anwendung für das Projektmanagement, das Critical Chain Project Management (CCPM). Der Durchsatz und die Minimierung des Bestandes an unfertigen Lösungen sind dort tatsächlich zentrale Steuerungsgrößen. Die Kosten spielen in der ToC ausdrücklich eine untergeordnete Rolle, die Nennung der Betriebskosten in diesem Kontext ist daher überraschend.

Nun geht es mir überhaupt nicht darum, die Reinheit der Lehre von Projekt-, Produkt- und Prozessmanagement zu verteidigen. Hier gibt es eine derartige Vielzahl an Ansätzen und dementsprechend auch mehr oder minder optimale Empfehlungen zur Umsetzung, dass eine solche Diskussion akademischen Kontroversen überlassen werden soll. Theoretische Verwirrung schadet zwar auch der Praxis, aber ich möchte herausarbeiten, was uns Conny Dethloff an beachtenswerten Impulsen gibt und dabei seinen etwas willkürlichen Umgang mit Management-Paradigmen nicht weiter diskutieren.

Impuls 1: „Projektmanagement“ ist eine Hülle, die viel offen lässt

Was als Projekt deklariert wird und wie dieses abgewickelt wird, hängt von vielen Faktoren ab. Wie groß die Aufgabe ist, welche Skills verfügbar sind, wie hoch das Erfolgs-, Termin- und Kostenrisiko ist, welche Vorgehensweisen in der Organisation gut etabliert sind etc. etc. Ob also etwas erfolgreich umgesetzt wird, hängt weniger davon ab, ob man es als Projekt abwickelt, sondern ob man die den Zielen und Rahmenbedingungen am besten angepassten Mittel wählt.

Das ist die Gefahr von Projektmanagement-Standards, dass ohne viel nachzudenken jedes als projektwürdig eingestufte Vorhaben nach einem fixen Schema abgehandelt wird. Gute Standards sollten daher immer Raum für unterschiedliche Varianten der Projektabwicklung bieten. Festlegungen wie z.B. „Es muss einen Lenkungsausschuss geben“, „Der Projektleiter kommt immer aus dem Fachbereich/der IT“, „Es darf keine duale Leitung geben“, „Projekte sind immer in folgenden Phasen abzuwickeln“, sind kontraproduktiv. Projekte sind per definitionem einmalige oder zumindest ungewöhnliche Aufgabenstellungen, daher kann es kein einheitliches Schema für das Management von Projekten geben.

Impuls 2: Ergebnisorientierung ist wichtiger als Prozessoptimierung

ISO 21100, PMI und PRINCE2 definieren Prozesse, die das Management von Projekten ausmachen. An sich ein guter Ansatz, aber wie immer, kommt es auf die Dosis an. Wenn die Fokussierung auf Prozesse und deren Optimierung zu stark wird, leidet der Erfolg. Am stärksten betont noch PRINCE2 die Bedeutung des Projektinhaltes. IPMA geht auf den Inhalt überhaupt nicht ein, in den Kontext-Kompetenzen würde man dies erwarten, sucht jedoch vergeblich.

Ich sehe diesen Aspekt bei allen PM-Standards als krass unterbewertet, denn der Inhalt ist von dominierender Bedeutung ist: „Content is king!„. Ich würde mich niemals darauf einlassen, z.B. ein Bauprojekt zu managen. Aber auch schon in meinen Kompetenzbereich, dem Management von IT-Projekten, würde ich ohne hinreichendes Verständnis für die Inhalte (sowohl der Branche als auch der eingesetzten Technologie) keinen Auftrag annehmen; im Interesse des Auftraggebers und auch im eigenen Interesse, denn ich möchte nicht scheitern, schon gar nicht mutwillig.

Wenn es also der Erfolgswahrscheinlichkeit dient, sind die unterschiedlichsten und ungewöhnlichsten Organisationsformen von Projekten zulässig, wenn das Wertströme, Fraktale, Viable Systems etc. sind, kein Problem, solange das Ergebnis stimmt.

Impuls 3: Das Einzige, was zählt, ist der Kunde

Ganz im Sinne von Geffroys provokantem Buch „Das Einzige, was stört, ist der Kunde„, eine der von mir so geschätzten paradoxen Interventionen, ist eben der Kunde das Maß aller Dinge, auch im Projektmanagement. Das gilt auch für die Organisation der Projektarbeit. Projekte sind temporäre Organisationen, daher ist es auch möglich und sinnvoll, diese so zu gestalten, dass sie optimal zur Kundenorganisation passen. Ein Statement wie „Das widerspricht unserem Projektmanagement-Standard“ sind ein Krisensymptom, außer, der Satz wird sinngemäß so fortgesetzt: „Aber wir werden uns an ihre Anforderungen so anpassen, dass das bestmögliche Ergebnis gesichert ist“. Das heißt nicht, dass man völlig prinzipienlos jeder willkürlichen Anforderung folgt, aber es erfordert eine sehr intensive und von einer positiven Einstellung geprägte Auseinandersetzung mit den spezifischen Gegebenheiten des konkreten Vorhabens. In  einem Dialog auf Augenhöhe werden Lösungen entstehen, die das Beste aus beiden Welten in einer einmaligen Weise kombinieren.

Wenn Sie regelmäßig über neue Blogposts informiert werden wollen, tragen Sie sich bitte hier ein. Bitte öffnen Sie dann Ihr Postfach und klicken Sie auf den Bestätigungslink, andernfalls wird die Anmeldung nicht wirksam („Double-Opt-In“).

Ihre Adresse wird nicht weitergegeben. Sie können sich jederzeit mit einem Klick wieder abmelden.

Hier noch einige Buchtipps zur Theory of Constraints und deren Implikationen für das Projektmanagement:



Schreibe einen Kommentar

Kommentar