Projektmanagement 3.0 – Der nächste Schritt hin zum geschäftswert-fokussierten Produkt in der Software-Entwicklung

Dieser Artikel ist ein Beitrag zur Blogparade Beyond Project Management. Auch wenn der Titel auf ein neues Projektmanagement abzielt, so möchte ich, inspiriert durch Roland’s Beitrag, ebenfalls die Diskussion erweitern um die Kontexte Organisation und Gesellschaft. Die disruptiven Veränderungen im Markt, wie auch in der Gesellschaft, sorgen ja gerade dafür, dass wir uns überhaupt der Diskussion um Veränderung im Projektmanagement stellen müssen.

Projektmanagement (PM) in der Software-Entwicklung kommt immer dann zum Tragen, wenn keine Produktentwicklung stattfindet. Also bei Entwicklungen außerhalb der Reihe, die entweder intern gebraucht werden oder die individuelle Anforderungen eines externen Kunden abdecken. Derartige Entwicklungen werden im Sinne einer Ausnahme der Organisation als Projekt behandelt, das zeitlich begrenzt und einem Risikomanagement unterworfen wird, da die zu erwartenden Tätigkeiten nicht zum Standard-Repertoire der Organisation zählen. Man könnte auch von Projektentwicklung sprechen.

Die Produktentwicklung ist dagegen fest eingebunden in die Linienorganisation. Die Zusammensetzung von Entwicklungsteams ändern sich dabei höchst selten. Da die Teams über lange Zeiträume stabil sind, sind diese gut eingeschwungen, die Produktivität erwartungsgemäß höher. Der Support durch die Linienorganisation ist quasi immer gegeben.

Projektentwicklung kennt keine eigene Organisationsstruktur. Sie ist auf das Wohlwollen der Linienorganisation angewiesen. Meist in Form einer Matrixstruktur, werden Mitarbeiter abgestellt, die Projektentwicklung zu unterstützen, ohne das damit auch eine Weisungsbefugnis erteilt wird. Die Linienorganisation zeigt meist wenig Interesse an der Projektentwicklung und handelt dementsprechend in ihrem Sinne. Die für die Projektentwicklung wichtigen Skills bzw. Leute verbleiben entweder ganz in der Produktentwicklung oder stehen nicht selten kürzer zur Verfügung als die geplante Projektlaufzeit. Damit kann nicht grundsätzlich von stabilen Teams ausgegangen werden, was Einfluss auf die Leistungsfähigkeit der Projektentwicklung hat.

Man sieht hier bereits, dass der Ausnahmetatbestand „Software-Entwicklung im Projekt“ Konsequenzen nach sich zieht, die selbst ein Risiko darstellen können. Ohne dies weiter zu vertiefen werfen wir stattdessen mal einen Blick auf die Statistik zum Erfolg von Projekten (interpretieren wir „Wasserfall“ hier mal als nicht agil durchgeführte Projekte):

Die Standish Group zeigt uns klar auf, dass Projektentwicklung nicht gerade von Erfolg gekrönt ist. Als erfolgreich galten hierbei Projekte, die die Zeit- und Budget-Vorgaben eingehalten haben, bei gleichzeitiger vollumfänglicher Lieferung des geplanten Funktionsumfangs. Natürlich in der gewünschten Qualität mag man noch hinzufügen.

Das ist nicht wirklich schön anzuschauen. Gerade wenn man sich klar macht, dass wir uns jetzt schon einige Jahrzehnte mit Projektentwicklung befassen, viele Werkzeuge zur Auswahl haben, ja sogar Standards definiert haben, nach denen man sich zertifizieren lassen kann. Und trotz dieser Fülle an Hilfen ergibt sich eine so magere Ausbeute.

„Das kann ja dann wohl nur an der Unfähigkeit der handelnden Personen liegen.“ „Dieser Beurteilungsreflex wurde lange eingeübt und ist verständlich, Herr Taylor. Sie würden wie gewöhnlich immer die Optimierung am Einzelnen ansetzen. Herr Luhmann aber rät uns zur Vorsicht. Die Menschen machen alles richtig in dem System, in dem sie sich bewegen. Vielleicht liegt’s ja auch einfach am System, dass man trotz all der eigenen Bemühungen nur selten in der grünen Zone landet.“

Und natürlich „menschelt“ es auch noch gewaltig. Ein Indiz dafür, dass wir es mit Komplexität zu tun haben. Die aber leider nicht Bestandteil der DNA bisheriger PM-Ansätze ist. Die meisten Ansätze gehen von uneingeschränkter Planbarkeit aus, wenn die Anforderungen klar formuliert sind. Leider lässt sich in komplexen Umgebungen das Ursache-Wirkung-Prinzip nicht länger aufrecht erhalten. Es fehlt schlicht die Voraussagbarkeit über längere Zeiträume.

Werfen wir nun einen Blick auf die sich abzeichnende Alternative „Agilität“, die seit einigen Jahren immer mehr Akzeptanz findet:

Da ist ja zumindest mal mehr grün zu sehen. Es sieht so aus, dass Agilität in Projekten gut dreimal mehr erfolgreiche Resultate hervorbringt. Aber wir haben immer noch über 50% an Projekten, die die gesteckten Ziele nicht oder nur mit Mühe erreichen. Agilität mag den Faktor Mensch besser berücksichtigen, aber mindestens mal das Grundproblem der Ausnahme zur Linienorganisation löst sie auch nicht auf. Vielleicht sollten wir daraus schließen, dass Projektentwicklung per Definition bzw. wegen der sich daraus ableitenden gelebten Praxis keinen praktikablen Ansatz darstellt (siehe auch Robert’s Hinweise auf #BeyondProjects).

Produktentwicklung

Wenn wir uns also auf die Produktentwicklung fokussieren wollen, was machen wir dann mit den organisatorischen Ausnahmen? Die grundsätzliche Frage ist eigentlich eine andere: ist es noch zeitgemäß zwischen „bekanntem Standardvorgehen“ und „Ausnahmen“ zu unterscheiden? In den Zeiten, als die Dinge kompliziert waren, war das Komplexe noch die Ausnahme. Die heutigen Märkte sind allerdings durchweg komplex. Sie fordern immer mehr Innovation in immer kürzerer Zeit. Neben der sowieso schon vorhandenen Komplexität treten zusätzlich disruptive Innovationen auf: Marktführer verschwinden jetzt plötzlich in kürzester Zeit in die Bedeutungslosigkeit (z.B. Nokia).

Wenn alles komplex ist, dann können wir uns auch gleich so aufstellen, dass wir mit diesem Sachverhalt immer umgehen können. Eine Produktentwicklung, die in der Lage ist auf komplexe Entwicklungen des Markts zu antworten, kann somit auch die bisherigen „Ausnahmen“ gleich mit abdecken. Und das ohne die Nachteile, die uns die Projektentwicklung so oft beschert.

Agilität ist für die Entwicklung von komplexen Produkten in komplexen Umgebungen ausgelegt. Sie wird in der weiterentwickelten Produktentwicklung sicher ein Schlüssel zum Erfolg sein können. Eigentlich haben wir derzeit auch keinen besseren. Aber Agilität in die Organisation einzuführen, um die Produktentwicklung für die Märkte fit zu machen, ist ein schwieriges Unterfangen.

Die meisten Organisationen können mit dem agilen Mindset noch nichts anfangen. Tayloristisch-geprägte Strukturen mit langer Tradition lassen sich nicht so einfach auflösen. Das Menschenbild ist noch X, nicht Y. Allerdings drängen neue Mitarbeiter in die Unternehmen, die sich nicht mehr grundsätzlich an die alten Strukturen anpassen, nur weil man das so macht. Die Frage nach dem Warum wird wichtiger und verlangt nach einer plausiblen Antwort. Und dabei treffen jetzt zwei Kulturen aufeinander: vorgegebener Status (von oben verordnet) vs. explizite Anerkennung (durch Mitarbeiter).

„We live in a knowledge worker age but operate our organizations in a controlling industrial age model that absolutely suppresses the release of human potential.“, Stephen R. Covey

Alleine um die guten Leute halten zu können, die zum eigenen Unternehmen gefunden haben, wird es langsam wichtig, vom Taylorismus los zu lassen. Sonst sind diese schnell beim Mitbewerb. Ich denke Sprenger hat hier recht, wenn er darauf hinweißt, dass der eigentliche Wettbewerb in Zukunft auf dem Arbeitsmarkt stattfindet. Zudem wird es wichtiger werden mehr in das eigene Recruiting zu investieren. Gute Leute zu finden ist bereits eine Herausforderung. Die zusätzlich benötigten Fähigkeiten für agiles Arbeiten machen die Sache noch schwieriger. Denn selbstverantwortliches Handeln ist auch in unserer Gesellschaft noch kein Leitmotiv. Unser Ausbildungssystem produziert so etwas höchstens zufällig.

Projektmanagement 3.0

Es wird Zeit brauchen, bis eine Produktentwicklung in der Lage ist die komplexen Märkte vollständig zu bedienen. Die Organisation muss sich erst einmal darüber bewusst werden, dass Komplexität und disruptive Innovationen nicht die Ausnahme sondern die Regel sind. Deshalb werden wir auf die Projektentwicklung erst einmal nicht verzichten können. Sie muss die Brücke bilden zur neuen Arbeitsweise der Organisation. Ziel ist, dass, wenn die Organisation ausreichend gelernt hat, auf die Projektentwicklung vollständig verzichten werden kann.

Wie sieht nun diese Projektentwicklung aus, die in der Übergangsphase stattfinden wird? Um hier sauber abgrenzen zu können, führe ich den Begriff Projektmanagement 3.0 (PM 3.0) ein. Angelehnt an die Ideen von Jurgen Appelo zu Management 3.0 definiert PM 3.0 die dritte Phase des Projektmanagements, die stark ausgeprägte Züge von Agilität in sich trägt, aber nur marginal auf tayloristische Ideen zurückgreift. Im Gegensatz dazu beschreibt Projektmanagement 2.0 den Mix zwischen tayloristischen Grundzügen und empirischen Erkenntnissen nach 1940, z.B. Micromanagement gepaart mit Leadership, also den Status Quo sozusagen. Projektmanagement 1.0 wäre damit die reine tayloristische Lehre, die in der folgenden Diskussion nicht weiter betrachtet wird.

PM 3.0 beschreibt den nächsten logischen Schritt in einer notwendigen Übergangsphase hin zu einer Produktentwicklung für eine komplexe Welt. Zu Beginn wird PM 3.0 fast disruptiv auf die noch tayloristisch geprägte Organisation bzw. Produktentwicklung wirken (siehe auch Eberhard’s Gestaltungsprinzipien). Es wird aber gleichzeitig dafür sorgen, daß die Organisation mindestens in einem Bereich entsprechend schnell lernt. Dies könnte gerade wegen der disruptiven Innovationen, die zwar nicht unvorhersehbar sind, aber mit einer gewaltigen Wucht und Geschwindigkeit den Markt umkrempeln, überlebenswichtig sein.

Wenn wir auf das derzeitig stattfindende PM 2.0 schauen, fällt auf, dass wir zwar Verbesserungen in Effektivität (Ergebnis) und auch Effizienz (Vorgehen) verzeichnen, aber nur im zweistelligen Bereich (bis 30% ist sicher realistisch). Aber wir wissen bereits, dass wir in der Lage wären Verbesserungen im dreistelligen Bereich hinzubekommen (realistisch wären sicher bis zu 300%; Jeff Sutherland’s Hyper-Productive-Teams ordnen wir bis auf Weiteres mal als Ausnahmeerscheinungen ein).

Wesentlicher Aspekt beim Übergang von PM 2.0 zu PM 3.0 ist die Etablierung eines agilen Mindsets in den Umsetzungsteams. Wir reden hier von den Prinzipien des Agilen Manifests (z.B. nicht getane Arbeit maximieren), die die Projektentwicklung für ihr Umfeld interpretieren muss, bevor über die Praktiken nachgedacht werden kann. Sicher wird der Einstieg mit einem an Kanban angelehnten Vorgehen einfacher sein. Der Übergang ist fließender. Allerdings besteht auch die Gefahr, dass die alte Denke mit neuen Werkzeugen gelebt wird. Ein an Scrum angelehntes Vorgehen ist disruptiver, bringt längerfristig aber sicher bessere Ergebnisse. Je nach dem wie man sich entscheidet, verkürzt oder verlängert sich die Übergangsphase, bzw. wird der Konflikt heftiger oder weniger heftig ausfallen.

Egal welchen Rahmen man definiert, es muss dafür gesorgt werden, dass die Produktentwicklung an den Erfahrungen der Umsetzungsteams partizipiert, die Organisation also letztendlich lernt. Einen ersten Lernschritt wird sowieso das direkte Umfeld der Projektentwicklung machen müssen, alleine um Projekte besser zu unterstützen und die sowieso schon dünne Erfolgsquote nicht noch zu verringern. Hier wird sicher noch viel mit Adaptern gearbeitet werden müssen, z.B. beim Controlling oder Reporting, damit die Organisation trotz der mehr oder weniger disruptiven Veränderung weiter produktiv sein kann.

Projektmanager 3.0

Die Projektmanager, die den Wandel treiben werden, müssen sich ebenfalls verändern. Sie werden einen Teil ihrer Verantwortung abgeben (z.B. das Micromanagement), dafür aber mehr Zeit für die wichtigen Dinge haben. Sie werden z.B. Leadership als eine zentrale Fähigkeit entwickeln bzw. ausbauen müssen. Die Menschen stehen nun im Mittelpunkt (siehe auch Melanie’s Beitrag zum Umgang). Nicht jedem wird der Wechsel zu dieser Y-Denke liegen, aber auf jene, die sich dieser öffnen können, warten spannende Aufgaben. Alleine das Coaching der Teams kann eine Vollzeitaufgabe sein. Nichtsdestotrotz bleibt es eine Herausforderung die notwendigen Softskills zu entwickeln, um die Teams wirklich nach vorne bringen zu können und dieses Niveau dann auch wirklich zu halten.

„Your first and foremost job as a leader is to take charge of your own energy and then help to orchestrate the energy of those around you.“, Peter Drucker

Servant Leadership wird ebenfalls ein zentrales Leitbild für die Organisation werden müssen. Auch hier wird die Organisation im direkten Umfeld der Projektentwicklung zuerst eine neue Bewußtseinshaltung entwickeln, die zum Unternehmen passt. Dieser Ansatz wird dann langsam in andere Teile der Organisation getragen werden.

Project Management Office 3.0

In vielen Organisationen wird der Projektmanager 3.0 auch weiterhin controlling-unterstütztende Tätigkeiten durchführen müssen. Wenn man z.B. über die Etablierung von Scrum nachdenkt, könnte man sich ein Lead-Team aus Product Owner (PO), Scrum Master und Projektmanager vorstellen, um diese Notwendigkeit abzubilden. Wenn der Projektmanager aber Verantwortungen abgibt und nicht in Rollenkonflikte mit dem PO bzw. Scrum Master geraten soll, ist es am besten auf ihn im Lead-Team zu verzichten. Allerdings brauchen wir trotzdem jemanden, der z.B. das Controlling für die Organisation unterstützt. Hier kann über die Zuarbeit eines Project Management Office (PMO) nachgedacht werden. In der Version 3.0 arbeitet das PMO ebenfalls weitersgehend agil. Sowohl in der Organisation seiner eigenen Tätigkeiten als auch in der Unterstützung bzw. Kommunikation zu den Projekten.

Organisation für Komplexität

Es ist damit zu rechnen, dass selbst bei der Anpassung in kleinen Schritten irgendwann die Organisation selbst über den Inspect-und-Adapt-Ansatz auch ins Visier der Optimierung und Effizienzsteigerung geraten wird. Nach Kruse erzeugt Komplexität zusätzliche Komplexität. Es ist zu erwarten, dass die Anforderungen der Märkte noch steigen werden (Stichwort Time-to-Market), so dass der Organisation nichts übrig bleiben wird sich zu entscheiden: Anpassen oder bedeutungslos werden (siehe auch Peter’s emergente Organisation).

Hierbei wird die Frage nach dem Mehrwert für den Kunden (Geschäftswert, Business Value) darüber entscheiden, was an Struktur der Organisation übrig bleibt. Sprenger formuliert es in etwa so: wir müssen aufhören für die Organisation zu arbeiten und wieder den Kunden ins Zentrum unseres Handelns rücken. Wo verschwenden wir wertvolle Energie, die besser in das Produkt investiert werden könnte? Kandidaten wären z.B. alle Mechanismen zur Kontrolle und Verwaltung von Ressourcen (also primär Mitarbeitern). Wer seine Mitarbeiter wie Menschen behandelt und nicht wie austauschbare Dinge (nichts anderes drückt Ressource aus) und ihnen vertraut, dass sie in Eigenverantwortung das bestmögliche Ergebnis finden werden, das die Situation hergibt, der muss nur helfen, aber nicht mehr kontrollieren oder verwalten.

Im Endausbau könnte es auf eine reine Netzstruktur von selbstorganisierten Teams hinauslaufen, wie Pfläging sie beschreibt. Er definiert zwei Kreise aus untereinander vernetzten selbstorganisierten Teams. Der äußere Kreis bedient den Markt, das entspricht unserer Produktentwicklung, der innere Kreis stellt notwendige Dienstleistungen bereit, die der äußere Kreis benötigt, um den Markt bedienen zu können (z.B. Infrastruktur). Die Vernetzung findet zwischen allen Teams statt, überschreitet also auch die Kreisübergänge, nach innen wie nach außen. Interessant wird sein, welche Strukturen diese Netze tatsächlich im Einzelfall ausbilden und inwieweit es noch einer konkreten Instanz der Steuerung des ganzen bedarf. In Pfläging’s Modell würde das vielleicht ein Team im inneren Kreis sein. Genauso gut könnte aber auch das Beziehungsgeflecht zwischen den Teams die Steuerung übernehmen.

Software-Fabrik 2.0

Beim Studium zum Industrie 4.0 Modell, das besonders auf die Produktion von individuell gestaltbaren Produkten zum Preis eines Massenprodukts bei gleichzeitiger Verkürzung der Innovationszyklen ausgelegt ist, kam mir für die Software-Entwicklung ein alter Begriff in den Sinn: die Software-Fabrik. In den 1980er war das mal eine Idee zur Integration von Software-Werkzeugen in einer Art Werkbank, um schneller Software entwickeln zu können. Ich glaube man sprach damals schon von Computer-Aided-Software-Engineering, dementsprechend von CASE-Werkzeugen. Allerdings war da noch nicht vorrangig von Objektorientierung die Rede.

Industrie 4.0 wird ein weiterer Beschleuniger sein. Die Vernetzungsdichte (Kruse) wird weiter zunehmen. Es wird zu erwarten sein, dass das nicht nur die Entwicklung von Embedded-Software-Systemen sondern die ganze Software-Entwicklung beeinflussen wird. Wir werden uns also darauf einstellen müssen, uns mit unseren Werkzeugen, Plattformen und Prozessen ebenfalls anzupassen. Denn die heutigen Entwicklungszeiten werden in wenigen Jahren nicht mehr marktgerecht sein. Alles wird sich noch mal ein Stück mehr standardisieren müssen bei gleichzeitig steigender Individualisierbarkeit ohne großen Mehraufwand. Ebenso wird es notwendig sein, Releases mit wenig Aufwand produktiv stellen zu können (bei gleichbleibend guter Qualität). Die Cloud könnte hier eine Antwort sein, wenn ich auf Knopfdruck Releases bereitstellen kann, die sich in der Cloud für Kunden dann individuell konfigurieren lassen. Das könnte ähnlich gut funktionieren, wie wir heute die Virtualisierung von Rechenleistung einsetzen.

Y-Gesellschaft

Die verändernden Märkte nehmen nicht nur Einfluss auf die Unternehmen. Jeder Bürger, ob nun als Mitarbeiter oder Konsument, nimmt Einfluss auf die Entwicklung. Das heißt für mich im Umkehrschluss auch, das jeder Einzelne und damit die Gesellschaft eine Transformation vollziehen muss. Die sozialen Implikationen der menschenleeren, hochautomatisierten und hochvernetzten Fabriken als Konsequenz des Industrie 4.0 Modells sind da nur ein Aspekt. Bereits heute lässt sich beobachten, dass Dueck’s Bildschirmrückseitenberater-Berufe auf dem Rückzug sind. Wir werden in vielen Bereichen Digitalisierung und Vernetzung als selbstverständlich hinnehmen und gleichzeitig daran arbeiten müssen, das diese Entwicklung nicht die Menschlichkeit komplett begräbt, wie es einst die industrielle Revolution mit Einführung der Dampfmaschine gemacht hat.

Im Unternehmenskontext setze ich weniger auf die Gewerkschaften, die in ähnlicher Weise wie viele Manager noch im Taylorismus verhaftet sind. Ihre Erfolge der Vergangenheit verhindern gerade, dass sich die Erkenntnis durchsetzt, dass auch mit dem besten Hammer nicht immer ein dazu passender Nagel zur Verfügung steht. Deshalb setze ich auf jene Mitarbeiter, die aktiv daran arbeiten ihre hinzugewonnenen Freiräume entsprechend selbstbewusst zu nutzen und die sich auch verantwortlich dafür fühlen an der stetigen Verbesserung der Organisation teilzuhaben.

Gesellschaftlich wird es uns mit den Politiker ähnlich gehen wie mit den Gewerkschaften. Immerhin haben schon einige erkannt, das Digitalisierung und Vernetzung ein wesentlicher Bestandteil des gesellschaftlichen Lebens geworden sind. Geben wir ihnen noch ein paar Jahre, die zugehörigen Implikationen zu verstehen. Somit bleibt auch hier nur der Bürger. Dieser wird sich fragen müssen, ob er das durch Erziehung gelernte und durch Gesellschaft manifestierte X gegen ein Y austauschen kann. Hierbei ist nicht so sehr das Selbstbild eine Herausforderung, Befragte siedeln sich stets im Y an, sondern schon eher das Bild von den Anderen. Die zentrale Frage wird sein, kann ich den Anderen vertrauen, ohne dass diese mir beweisen müssen, dass ich es sollte. Aber die Mühe wird es wert sein, allein schon um der eigenen Kinder willen und einer besseren Zukunft für uns alle ;-).