Kategorie-Archiv: Projektmanagement

Können kleine Systeme komplex sein?

Komplexität ist eine Eigenschaft, die einer Systemstruktur zugeordnet ist (1). Die heutige Welt ist insofern komplexer als vor 50 Jahren, weil hauptsächlich Verkehrs- und Informationstechnologien neue globale Netzwerke ermöglicht und verursacht haben.

Verschiedene Kategorien

Das Zustandekommen von Komplexität ist im Allgemeinen ein Massenphänomen. Beispielsweise ist die Struktur einer Stadt komplex und kommt durch das Zusammenspiel von Hundertausenden von Menschen zustande. Städtebauliche Massnahmen und Gesetze tragen allenfalls dazu bei, dass die Entwicklung kompliziert wird und nicht so sehr zur eigentlichen Komplexität.

Dieses Nebeneinander von Kompliziertheit und Komplexität verleitet oft dazu, beide Kategorien in Verbindung zu bringen. Das wohl bekannteste Beispiel ist das Cynefin-Framework. So, wie es meist dargestellt wird, stellt es unglücklicherweise „kompliziert“ und „komplex“ nebeneinander, als wäre ein System entweder kompliziert oder komplex. Die beiden Kategorien korrelieren etwas so viel miteinander, wie die Inhalte des Hubraums und des Gepäckraums eines Autos.

Dave Snowden hat in sieben Blogbeiträgen geschrieben, wie er zum Cynefin-Model kam. Ausgehend von Max Boisots Information-Space, hat er zunächst ein Modell des Wissensmanagements und des Lernens gesucht. Boisots I-Space hat drei Dimensionen und zeigt den Weg von Wissen bei sozialem Lernen.

I-SpaceDie Entwicklung vom I-Space zum Cynefin-Framework kann ich im I-Space selbst nachvollziehen. Snowdens erstes Modell hatte die Dimensionen „Abstraktion“ und „Kultur“. Danach setzte sich das Vierfeldermodell mit „kompliziert“ und „komplex“ durch, war aber noch mit einer Metapher angereichert, die der Katastrophentheorie von René Thom entstammte(4). Damit das Modell aber verständlich blieb, durchlief es die „Diversity Reducing Phase“ und wird mittlerweile als ordentliches, starr kodiertes Bildchen in jeder Lebenslage präsentiert. Ich vermute, dass das nicht in Snowdens Sinn ist. Er schreibt in The Origins of Cynefin – Part 1:

Far too may people read up on something quickly and use the language without real real understanding

Projektkomplexität

Es stellt sich die Frage, ob auch ein „kleines“ System Komplexität aufweisen kann. Projekte sind Beispiele von „kleinen“ Systemen. Das sind Systeme, die aus Dutzenden bis höchstens ein paar Tausend Subsystemen bestehen. In einem Projekt gibt es meist ein paar Dutzend bis ein paar Hundert Stakeholder. Es ist ein kleines System. Ist es zur Komplexität fähig? Kann bereits Selbstorganisation entstehen? (2) Und da erinnere ich mich an Tierschwärme, die durchaus Selbstorganisation aufweisen. Es brauchen nicht einmal Herden zu sein, die aus über 100‘000 Individuen bestehen. Schon in relativ kleinen Vogelschwärmen können Strukturen emergieren. Als Beispiel habe ich einen Taubenschwarm aufgenommen, der regelmässig „Flugtraining“ absolviert. Es gibt vermutlich keinen „Führer“. Eine spontane Richtungsänderung wird weder vereinbart noch befohlen, sondern kommt per Selbstorganisation zustande. Die Tiere fliegen auch nicht schön geordnet und parallel zueinander, wie Soldaten bei der Zugschule. Es gibt durchaus Querflieger und Ausreisser.

Beachten Sie die Unsicherheit nach der ersten Runde und vor der abrupten Richtungsänderung!


Das ist ein Beispiel für eine Projektkomplexität (für die Vögel ist es ein Projekt), wie sie sich bereits in einer kleinen Gruppe bildet. Landet der Schwarm, ist das Projekt beendet und die Komplexität verschwunden. Nur die Umwelt konserviert die Komplexität unter Umständen. Das Projekt hinterlässt Strukturen, z.B. ein Haus oder ein entwickeltes Digitalprodukt. Es ist die vornehmste Aufgabe eines Projekts, die Komplexität der Welt ein wenig zu erhöhen.

Anmerkungen:

(1) Ich weiss, dass es viele Definitionen von Komplexität gibt und fast jedes Individuum seine eigene Meinung darüber hat. Sie dürfen mir also gerne widersprechen. Es macht keinen Sinn, über den Begriff zu streiten.

(2) Selbstorganisation ist nicht mit Selbstmanagement zu verwechseln.

Projektabschluss per Führungsentscheid

Zum Auftakt der PMCamp-Saison beschäftige ich mich wieder vermehrt mit Fragen zum Projektmanagement. Dabei ist mir eingefallen, wie wichtig es ist, Projekt und Betrieb zu trennen.

Der Rework Cycle

Ich habe hier auch schon darauf hingewiesen, dass Projekte oft gar kein Ende haben. Es gibt hier noch etwas zu flicken und dort etwas aufzuräumen, und so zieht sich der Abschluss des Projekts oft über Wochen und Monate hin. Das hat mit dem Rework Cycle zu tun, dem bestuntersuchten Phänomen des Projektmanagements. Im Nachhinein entpuppen sich bereits erledigte Arbeiten manchmal als mangel- oder gar fehlerhaft und müssen nachgebessert werden. Das kann zu beträchtlichen Verzögerungen führen. Ich habe hier den Rework Cycle schon mehrmals vorgestellt(1).

Verspätet auftauchende Mängel führen zu einem „langen Schwanz“ von Nacharbeiten. Auf der einen Seite ist der Druck des Controllings, das Projekt abzuschliessen, auf der anderen Seite weigert sich der Betrieb, die Mängel zu erben. Das führt dann zu einer manchmal monatelangen Überlagerung von Projekt und Betrieb.

Zwischen dem Projekt und dem Betrieb muss ein deutlicher Schnitt stattfinden.
Zwischen dem Projekt und dem Betrieb muss ein deutlicher Schnitt stattfinden, indem ab einem gewissen Zeitpunkt keine Nachbesserungen mehr gestattet werden.

Parallel- oder Schattenorganisationen

Vor allem in Weltkonzernen kann das oft beobachtet werden, wenn z. B. verschiedene Regionen ein System gestaffelt einführen. Während das Integrationsprojekt in Region A bereits abgeschlossen sein sollte, startet es in Region B gerade. Daher ist es nicht so wichtig, dass das Projekt in der Region A auch wirklich abgeschlossen wird. Schlimmstenfalls können Nacharbeiten zum Projekt in der Region B gerechnet werden, das fällt ja gar nicht auf. Während in Region A das System formal bereits dem Betrieb übergeben wurde, ist es in Region B noch in Einführung begriffen. Testuser in Region B wenden sich dann plötzlich an den Support in Region A, etc.

Solcherlei Vermischungen können oft zu einem jahrelangen Überlagerungszustand von Projekt und Betrieb führen. Ich habe schon Unternehmen gesehen, in denen das „Projekt“ zu einer ständigen Organisationseinheit wurde, die parallel zum Betrieb („Maintenance& Support“) existierte. Organigramme führten das Projekt tatsächlich als Kästchen und subordinierten es einem Linienmanager, obwohl ein Projekt definitionsgemäss zeitlich begrenzt sein sollte.

Das Projekt degenerierte so zu einer Parallelsupportorganisation. Es ist ein Führungsentscheid, dass ab einem gewissen Zeitpunkt das Projekt beendet ist und keine weiteren Nachbesserungen mehr erwartet und gestattet sind.

 

(1) Addor, P. Projekten in den Rachen geschaut. August 2008
und Addor, P. Die effektivste Massnahme, um Projektverzögerungen zu minimieren. August 2014

Ein übles Projekt

Eine erneute Blogparade fragt nach Projekterfahrungen, insbesondere diejenigen des erfolgreichsten und des übelsten Projekts(1).

Über ein erfolgreiches Projekt kann ich hier nicht berichten. Meine Projekte hatten keinen Anfang und kein Ende und waren stets problembeladen. Das mag auch darin gründen, dass ich als Projektberater oft als Troubleshooter geholt wurde.

Insofern waren alle Projekte, in die ich involviert war, relativ übel. Hier erzähle ich von einem Projekt, dessen unternehmerischer Kontext gar keinen Erfolg zuliess(2).

Das wirft die Frage auf, inweifern sich der Projektmanager im unternehmerischen Kontext eines Projekt engagieren soll und kann.

Der Projektkontext

Der Projektvertrag bestand zwischen dem Kunden und der nationalen Niederlassung eines internationalen Systemintegrators. Die Projektleitung und –durchführung oblag aber irgendeinem Competence Center im Ausland, das gleichzeitig mehrere Rollouts durchführte und sich natürlich auf diejenigen fokussierte, die am grössten und damit am lukrativsten waren.

Wenn immer der Kunde etwas zu bemerken oder gar bemängeln hatte, wandte er sich an seinen Vertragspartner, die Zweigniederlassung des Systemintegrators. Diese hatte aber keine Kompetenzen und musste alles dem Competence Center weiter geben. Dessen Ressourcen waren jedoch in Parallelprojekten beschäftigt und oft nicht verfügbar.

Eine detailliertere Sicht des Projektkontextes habe ich hier dargestellt:

pojekterfahrung

 

Das Verhalten der nationalen Niederlassung

Zunächst hat das Competence Center die Notwendigkeit jeglicher Aufwendungen der Zweigniederlassung abgestritten, während der Kunde das Risiko erkannt und mehrmals deutlich darauf hingewiesen hat, dass er volle Aufmerksamkeit für sein Projekt erwarte.

Die Zweigniederlassung konnte das Competence Center schliesslich überzeugen, dass der heikle Kunde Vorortbetreuung benötige. Die Zweigniederlassung funktionierte zunächst als Kommunikationsdrehscheibe zwischen dem Kunden und dem Competence Center.

Am Anfang konnte die Zweigniederlassung lediglich Druck auf das Competence Center machen, mehr Projektressourcen zu allozieren und diese lokal zu stationieren. Später warf das Competence Center der Zweigniederlassung dafür vor, ihre Kunden nicht im Griff zu haben.

Ich versuchte, dem CEO der Zweigniederlassung begreiflich zu machen, dass er in der Linie intervenieren soll, weil das Projekt in diesem Kontext zum Scheitern verurteilt sei. Leider konnte ich mich entweder nicht deutlich genug ausdrücken oder er hatte keine Möglichkeit, sich im Europäischen Management durchzusetzen.

Das Projekt endete mit einem grossen Knall, in welchem sich alle gegenseitig beschuldigten und keiner die Verantwortung übernehmen wollte. Dass das System nach Aufzehrung jeglicher Marge und mit einer Verzögerung von ca. 50% dennoch erfolgreich zum Laufen kam, war nebensächlich.

Es geht nicht um Systeme, sondern um Geschichten.

(1) JFtOptimizingPartner: Blogparade: Erfolgreichstes vs. Übelstes Projekt. 23. Januar 2015

(2) P. Addor, Projektdynamik – Komplexität im Alltag. Liebeig-Verlag, 2010. S. 40ff

Komplexitätsreduktion? Läuft bei mir nicht.

Am PMCamp in Dornbirn 2014 kam einmal mehr das Thema Komplexitätsreduktion auf. Erstaunlich, wie sich so etwas hält, trotz jahrzehntelanger Diskussion. 1956 publizierte Ashby sein berühmtes Gesetz(1). Obwohl er nicht der erste und einzige ist, der die Notwendigkeit der Komplexität oder Varietät verstand, ist seine Aussage doch die von der Öffentlichkeit am meisten akzeptierte.

Jeder hat seine eigene Vorstellung von Komplexität

In einem Pausengespräch sagte mir jemand, dass man doch nicht immer die ganze Welt in Betracht ziehen könne und sich auf einen Ausschnitt beschränken müsse. Wie wahr! Nur kümmert das die Welt nicht. Wer Mist baut und dieser anderen auf den Kopf fällt, darf sich nicht der Verantwortung entziehen. Was soll man also tun?

Das Problem beginnt mit dem Begriff „Komplexität“. Alle verwenden ihn, niemand weiss, was er bedeutet, bzw. jede Person versteht darunter etwas anderes(2). Die meisten Menschen setzen Komplexität einfach mit Intransparenz, Unordnung und hoher Varietät gleich. Für mich hat Komplexität aber weniger mit dem Sein als vielmehr mit dem Werden zu tun. Komplexität ist Dynamik, Rückkopplung und Potential zur Emergenz!

Dynamik ist in einem Projekt förderlich

Wird z.B. in einem Projekt die Dynamik und Rückkopplung reduziert, indem man strukturiert, Regeln aufstellt und Vorschriften erlässt, dann kann das dazu führen, dass das Projekt erstarrt und zusammenbricht, ins Abseits läuft oder abgebremst wird. Wenn das Projekt stoppt, kann nichts mehr schief, aber auch nichts mehr richtig gehen. Insofern erachte ich Dynamik, Rückkopplungen und Emergenzen in Projekten als förderlich, auch wenn das bedeutet, dass die Stakeholder vermehrt unter Stress stehen. Dann ist es eben eine Frage der Sichtweise, ob man Komplexität als grundsätzlich schlecht oder als hilfreich ansieht.

Vertrauen ist gut, Kontrolle ist besser?

NebelDas Problem liegt an unserem Drang, alles kontrollieren zu wollen. Das ist irgendwie ein menschliches Bedürfnis, kommt aber langsam in die Jahre. Unsere Welt ist überaus komplex geworden und kann längst nicht mehr kontrolliert werden. Wir müssen vielmehr lernen, mit Komplexität und Ungewissheit zu leben. Wir müssen uns fragen, wie wir uns im Nebel bewegen, wenn wir die Beschaffenheit des Weges vor unseren Füssen nicht mehr erkennen. Vielleicht wären Werkzeuge nützlich, wie z.B. ein Blindenstock oder ein Radar. Mit ihnen können wir zwar den Weg nicht vollständig kontrollieren, aber mindestens so viel, dass wir nicht ständig stolpern. (Zwar hinkt die Nebelmetapher! Den Weg gibt es, auch wenn wir ihn nicht sehen, die Zukunft gibt es noch nicht, sie liegt nicht im Nebel).

Das magische Dreieck der Komplexität

Es gibt solche Werkzeuge. Jedoch kommt hier ein ähnliches Gesetz, wie das von Ashby, zum Zuge: Das „Thorngatesche Postulat der angemessenen Komplexität“. Es besagt, dass von den drei metatheoretischen Tugenden „Allgemein, Genau und Einfach“ bloss stets zwei wahrgenommen werden können und die dritte vernachlässigt werden muss(3). Das bedeutet: allgemeingültige und einfache oder vereinfachende Handlungsanweisungen oder Methoden für Projekte sind Beliebigkeiten, d.h. Blahbla.

Modelle helfen, den Weg zu finden

ProjectscopeDaher würde ich auf Allgemeingültigkiet und Präzision setzen und die Forderung nach Einfachheit fallen lassen. Die gesuchten Werkzeuge, um in ungewissen und hochdynamischen Projekten zu bestehen, sind Modelle und Modellbildung. Mit Modellen lässt sich zwar auch nicht die ganze Welt einfangen, aber es kann zumindest untersucht werden, wo das Projekt „klemmt“ und welche Auswirkungen unsere Policies haben, auch ausserhalb des Projekts. Hier denke ich insbesondere an

  • Causal Loop Diagrams
  • System Dynamics
  • Bayesianische Netze
  • agentenbasierten Modelle.

Mit den heute zur Verfügung stehenden Möglichkeiten im Web 2.0, können alle, die sich dafür interessieren, unkompliziert die kompliziertesten Modelle bauen(4).

Quallen:

(1) R. Ashby: An introduction to Cybernetics. Wiley, New York 1956.

(2) M. Sussman: Ideas on Complexity in Systems – Twenty Views. 2000

(3) Karl E. Weick: Sources of order in Underorganized Systems: Themes in Recend Organizational Theory. In: Karl E. Weick (Hrsg.): Making Sense of the organization. University of Michigan/ Blackwell Publishing, Malden, MA 2001, ISBN 0-631-22317-7, S. 32–57

(4) Insightmaker für System Dynamics, Causal Loop Diagramme und agentenbasierte Modelle. GeNIe für bayesianische Netze. Beide sind gratis und dennoch professionell. Beide habe ich getestet und viel Erfahrung damit gesammelt.

Die rezipive Verzerrung durch des Kaisers neue Kleider

nackter_KaiserIn Köln stehen fünf kleine Fassaden-skulpturen, die das Märchen Des Kaisers neue Kleider von Hans Christian Andersen darstellen. Zwei Betrüger verkaufen dem Kaiser teure Gewänder, die angeblich nur von Personen gesehen werden, die ihres Amtes würdig und nicht dumm seien. Tatsächlich geben die Betrüger nur vor, Stoffe zu weben und Kleider zu schneidern. Aus Eitelkeit und Unsicherheit gibt der Kaiser nicht zu, dass er die Kleider auch nicht sehen kann, während die Menschen, denen er die angeblichen Kleider vorführt in Begeisterungsstürme ausbrechen ob derart nobler Bekleidung.

In unserer Zeit gibt es immer mehr Kaiser mit „neuen Kleidern“

Das Märchen endet leider etwas schwach. Ein Kind rief: „Aber der Kaiser ist doch nackt“, wodurch der Schwindel aufflog. Konsequenterweise könnten ja eben gerade Kinder die Kleider gar nicht sehen, da sie kein würdiges Amt haben und noch nicht die nötige Weisheit. Aber das Motiv ist verbreitet. Es wird auch in den Erzählungen Der Hauptmann von Köpenick und Kleider machen Leute aufgegriffen.

In sehr komplexen Umgebungen fallen die Menschen tatsächlich gerne auf Vereinfachungen und Verblendungen herein. Mir scheint, dass sich in den letzten Jahren die Fälle häuften, wo eine Marke, ein Managementkonzept oder ein Führungsstil hochgejubelt wird, auch und vor allem wenn gar nichts Geniales dahinter steckt. Und in allen Fällen finden diese „neuen Kleider“ viele Bewunderer, sogar auch in akademischen Kreisen. Es kommt zu regelrechten Fangemeinden, die sich über Social Media Kanäle nährt.

Ich denke z.B. an gewisse Projektmanagementmethoden, die regelrechte Schulen bilden und durch unabhängige Stellen kostenpflichtig zertifiziert werden; oder Computermarken, die zu einer Szene hochstilisiert werden und inkompatible Zusatzgeräte einen lukrativen Markt bilden. Ähnlich sind auch viele Management- und Führungskonzepte zu werten, die oft aus nicht mehr als einem Reizwort bestehen, das dann zuweilen monatelang durch die Social Media geistert, um crowdfunding Kapital zu generieren.

Nicht Eitelkeit, sondern Ausweg aus einer Kompliziertheitserstarrung

Allen Fangemeinden gemeinsam ist ein gewisser Fundamentalismus. Wer einmal auf den Zug einer virulenten Idee ausgesprungen ist, der verteidigt sie z.T. unter Verunglimpfung der „Nichtgläubigen“. Ein Beispiel ist die nicht endend wollende und oft unsachlich geführte Diskussion um das beste Betriebssystem von Computern.

Was hat dieses Phänomen zu bedeuten? Eines ist klar: Die Marken- und Konzeptidole sind nicht eines Kaisers neue Kleider. Während sowohl im Märchen, als auch beim Schneidergesellen Wenzel Strapinski oder beim Schuhmacher Friedrich Wilhelm Voigt Eitelkeit der treibende Faktor war, ist es hier Angst vor Kompliziertheit. Ein Konzept oder eine Technik entwickelt sich immer weiter und wird dabei immer komplizierter, bis zur Erstarrung. Dann fühlen sich die Anwender unwohl, verstehen nichts mehr und suchen nach etwas Einfacherem. Sobald sich am Horizont etwas auftut, wird es sofort als Erlöser vor dem überdrüssig gewordenen  willkommen geheissen. Später auftauchende, ebenso vielversprechende Konzepte, haben kaum mehr eine Chance. Dank Social Media findet die Aggregation einer Fangemeinde rasant statt. Sie kapselt sich sofort gegen konkurrenzierende Neuerungen ab. Ein gutes Beispiel ist das Projektmanagement. Während die Menschen seit Jahrtausenden Projekte machen, wurde Projektmanagement erst im Zweiten Weltkrieg begründet. Danach wurde es so lange weiterentwickelt, bis es zu einem regelrechten Moloch wurde, mit dem immer weniger Projekte erfolgreich abgewickelt werden konnten. In der 1990er Jahre entstanden neue Ideen, von denen vor allem das agile Projektmanagement viele Bewunderer fanden, von denen viele die konkurrenzierenden Ansätze nicht kennen  oder sie schlicht leugnen.

Abkapselung als komplexitätsvermeidene Heuristik

Ebenfalls gemeinsam ist allen diesen Marken- und Konzeptidolen, dass sie von ihren Anhängern in oft unzulässiger Weise verallgemeinert und in allen möglichen und unmöglichen Situationen angewendet oder empfohlen werden. Einerseits wird jeweils kaum sachlich untersucht, was die neue Idee taugt und andererseits werden auch keine Voraussetzungen angegeben, unter denen das neue Konzept praxistauglich ist. Wozu auch? Es ist über jeden Verdacht erhaben, und wer das in Zweifel zieht, ist ein Ewiggestriger. Auf diese Weise ist schon manches hohle Konzept zur Religion erhoben worden.

Zwar ist die Motivation nicht dieselbe, wie im Märchen von Des Kaisers neue Kleider, wohl aber das Tamtam, das um solche Marken- und Konzeptidole gemacht wird. Leider gibt es keine Kinder, die sie entlarven. Kritische Erwachsene werden hingegen schnell mundtot gemacht. Der englische Arbeitspsychologe James Reason, der sich mit der Erforschung menschlicher Handlungsgewohnheiten, die oft zu Fehlern führen können, einen Namen gemacht hat, nennt Abkapselung als eine häufig angetroffene Heuristik, um Komplexität auszuweichen(1). Dietrich Dörner spricht von vertikaler Flucht(2). Das Hochjubeln von wenig durchdachten Konzepten, nur weil die traditionellen zu kompliziert geworden sind, ist eine solche vertikale Flucht. Das anschliessende Abkapseln der Community gegenüber den „Ungläubigen“ nenne ich die rezipive (Wahrnehmungs-)Verzerrung (vom Lateinischen „zurücknehmen, befreien, annehmen“). Es ist möglicherweise eine Spielart der narrativen Verzerrung, die Nassim Taleb in seinem Schwarzen Schwan beschrieben hat(3).

 

(1) James Reason. Menschliches Versagen – Psychologische Risikofaktoren und moderne Technologien. S. 97. Spektrum Akademischer Verlag. Heidelberg 1994

(2) Dietrich Dörner. Die Logik des Misslingens – Strategisches Denken in komplexen Situationen. Rowohlt Verlag. Reinbek bei Hamburg 2003.

(3) Nassim Nicholas Taleb. Der Schwarze Schwan – Die Macht höchst unwahrscheinlicher Ereignisse. Hanser Verlag. München 2008

 

Haben Projekte ausgedient? – Beyond Project Management

Ein Projekt dauert eine bestimmte Zeit. Ein komplexes Projekt noch länger. Ist es im Zeitalter emergenter Organisationen überhaupt noch sinnvoll, Projekte anzureissen?

Projekte passen nicht zu emergenten Organisationen

Adrian W. Fröhlich stellte in seinem Buch Mythos Projekt(1) bereits 2002 fest, dass eine emergente Organisation in ständigem Wandel begriffen ist. In ihr ist die Konsensfindung unter den Mitarbeitern eine Daueraufgabe, ohne dass immer wieder Verantwortungsbereiche zur Disposition gestellt und soziale Umverteilungen vorgenommen werden. Fröhlich schreibt, dass Stabilität immer weniger erwartet und verlangt wird. Das Ziel sei nicht mehr das Festland, sondern bloss noch das schwankende Überwasserhalten. Was wirklich zählt, ist die Eleganz, mit der geschwankt wird (S. 151). Dabei folgt Fröhlich Truex et al. (2).

Daraus leitet Fröhlich ab, dass projektbasierte Analyse und Design veraltet seien. Wenn sich intensive Analysephasen in einer einigermassen stabilen Organisation noch gerechnet haben, weil der Projektgegenstand danach ja mehrere Jahre genutzt werden konnte, sei in der emergenten Organisation laufend Analyse notwendig.

Ebenfalls veraltet sei das Anstreben voller Benutzerzufriedenheit und die vollständige Erhebung von widerspruchsfreien Anforderungen. Nutzer können keine endgültige Meinung mehr haben, weil sich das organisatorische Umfeld ja ständig ändere.

Der neue Zielraum sei demzufolge permanente Analyse, dynamischer Anforderungsermittlung, lebendige Spezifikationen, Adaptierbarkeit bestehender Lösungen und kontinuierliche Umprogrammierung der laufenden Systeme.

Projekte lösen sich auf, wenn Entwicklung, Planung, Durchführung und Nutzung zusammenfallen und verfliessen.

Den Betrieb neu erfinden

Insbesondere Adaptierbarkeit bestehender Lösungen und kontinuierliche Umprogrammierung der laufenden Systeme erfordern die Abschaffung der herkömmlichen Projektmetapher, was um das Jahr 2000 noch ketzerisch geklingt haben mag. Ich habe noch 2005 ein Projekt geleitet, das zum Ziel hatte, ein Voice Messaging System zu migrieren. Das alte System kam mit 100‘000 Abonnenten an seine Grenzen und musste durch ein neues System ersetzt werden, das bis zu 300‘000 Abonnenten bedienen konnte. Das neue System bestand sowohl aus Hard- als auch aus einer Software, die mit der alten nicht kompatibel war, obwohl sie vom selben Hersteller stammte. Noch heute spricht man bei IT-Systemen von „end of life“ und erlaubt ihnen, einfach zu zerfallen. Dann muss die Organisation solange den Atem anhalten, bis ein neues System das zerfallende ersetzt (Fröhlich, S. 153ff).

Bis vor ungefähr zehn Jahren wurden die meisten Systeme organisationsintern eingesetzt und zur Aussenwelt hin isoliert. Heute jedoch sind alle Systeme vernetzt. Wenn eines zerfällt und ausfällt, hat das Auswirkungen auf ganze Supply Chains oder Märkte. Cloud-Konzepte wie SaaS und IaaS lösen Projekte auf und verweisen sie in den laufenden Betrieb.

lebensfaehigSolange jedoch „laufender Betrieb“ als Business as usual verstanden wird, kann er Projekte nicht aufnehmen. Der Betrieb muss sicherstellen, dass die Systeme lebensfähig sind und bleiben(3). Systeme sind lebensfähig, wenn sie sich an laufend verändernde Bedingungen anpassen können und resilient sind. „Betrieb“ heisst demzufolge nicht, die Systeme vor Changes und instabilem Umfeld schützen, sondern im Gegenteil, sie so zu betreiben, dass sie die Veränderungen mitschwingen können. Das bedeutet durchaus, dass ein aktueller Zustand lebensfähiger Systeme immer nur improvisiert und provisorisch ist. Er muss sich ja im nächsten Moment ändern.

Nicht nur in der IT sind Projekte veraltet

Projektmanagement kommt (leider) aus dem militärischen Bereich. Grosse Operationen, wie beispielsweise die Operation Overlord, mussten geplant und unter Risiken durchgeführt werden. Sie hatten Termine, Meilensteine und ein Ziel. Das ist heute kaum mehr denkbar. Kriege haben keine Fronten mehr. Es gibt keine Operationen mehr, die monatelang vorbereitet werden können, auch nicht zuletzt wegen der völligen Transparenz dank Satelliten und Informationstechnologien. Planung und Durchführung von Operationen finden in modernen Kriegsszenarien gleichzeitig statt.

Auch in der Organisationsentwicklung hat man, so paradox es klingt, Projekte gemacht. Beispielsweise gibt es eine Broschüre „Veränderungsprojekte erfolgreich planen und umsetzen“ oder einen Kurs „Planung und Steuerung von Veränderungsprojekten“ (4). Schon die Titel sind irreführend und atmen den Geist der 90er Jahre. Veränderung findet nicht in Projekten statt. Veränderung hat keinen Endtermin und kein Ziel. Die Projektmethodik ist zu träge, als dass sie die Veränderung transportieren könnte, die Unternehmen heute durchlaufen.

Dieser Artikel erscheint im Rahmen der Blogparade Beyond Project Management

1)Adrian W. Fröhlich. Mythos Projekt – Projekte gehören abgeschafft. Ein Plädoyer. Galileo Press GmbH, Bonn 2002. ISBN 3-89842-153-8

(2) D. Truex, R. Baskervill, H. Klein. Growing Systems in Emergent Organizations. Communications in the ACM, August 1999

(3) A. Ninck, L. Bürki, R. Hungerbühler, H. Mühlemann. Systemik – Vernetztes Denken in komplexen Situationen. Verlag Industrielle Organisation. 4. Auflage. 2004. S. 121ff

(4) Veränderungsprojekte erfolgreich planen und umsetzen und Planung und Steuerung von Veränderungsprojekten

Die effektivste Massnahme, um Projektverzögerungen zu minimieren

Am PM Camp in München, Ende Juli 2014, habe ich den Rework Cycle vorgestellt. Im Prinzip ist es ein Hauptschlüssel für erfolgreiches Projektmanagement. Das Rework Cycle Modell geht davon aus, dass vermeintlich erledigte Arbeiten nachgebessert oder wiederholt werden müssen, z.B. wegen Fehlern oder weil Policies geändert haben.

Der Rework Cycle

Der Bauingenieur David Ford berichtet von zwei Atomkraftwerkbauten (1). Während der Bauzeit flossen aus Erfahrungen beim Betrieb anderer AKW neue Bauvorschriften ein. Ich konnte das in meinen IT-Migrationsprojekten bestätigen. Die Systeme, die wir installierten, waren kurz vorher woanders in Betrieb genommen worden. Uns erreichten Meldungen über Laufzeitfehler, die unter Last auftraten. Das führte dazu, dass wir gewisse Tests wiederholen mussten, neue Lastverteilungsmassnahmen einbauen oder die geplanten Konfigurationen ändern mussten. Solche unvorhergesehenen Massnahmen sind die Ursache des Rework Cycle.

Die in realen Projekten gewonnen Daten stimmen so gut mit der Simulation des Modells überein, dass es heute ausser Zweifel steht, dass der Rework Cycle in jedem Projekt auftritt und es aufbläst. Wer den Rework Cycle ausser Acht lässt, wird sich regelmässig über Projekte wundern, die ihr terminliches Ziel nicht erreicht haben und die Ursache in Bereichen suchen, die gar nichts mit dem Problem zu tun haben, z.B. Kommunikation oder Management Awareness.

Wie umgeht man den Rework Cycle?

Gar nicht! Er ist Gesetz. Man kann aber die terminverzögernden Auswirkungen dämpfen, wenn man das Modell kennt. Dieses geht davon aus, dass die durchgeführten Arbeiten nicht gleich auf den Haufen „Erledigt“ kommen, sondern zuerst auf einen Haufen „zu begutachten“. Erst diejenigen Arbeiten, die sich bei der Kontrolle als gut erweisen, kommen auf den Haufen „Erledigt“. Die anderen müssen nachgebessert oder wiederholt werden. Sie kommen daher vorläufig auf den Haufen „Rework“.

ReworkCycleBasisMan sieht nun deutlich: Das Projekt wird nur dadurch fertig, indem man sich des Haufens „zu begutachten“ annimmt. Natürlich müssen die Originalarbeiten auch gemacht werden, aber „durchgewunken“ werden sie erst durch die Kontrolle. Das bedeutet, dass häufige Kontrollen das Projekt mehr voranbringen, als z.B. nur eine einzige Endkontrolle. Peter Lancy von der PA Consulting Group will das sogar genau wissen (2). Er hat gezeigt, wie sich die Laufzeit eines Projekts erhöht, wenn nur eine „grosse“ Schlusskontrolle, statt vier über das Projekt verteilte Kontrollen, gemacht wird. Aus seiner Grafik entnimmt man z.B., dass ein Projekt, in welchem die „Qualität“ (= Anteil an Arbeiten, die bei der Kontrolle auf den Haufen „Erledigt“ kommen) 0.85 beträgt dreimal länger geht als geplant, wenn nur eine Kontrolle gemacht wird und unwesentlich länger als geplant, wenn vier Kontrollen gemacht werden.

ProjektLaufzeit_Rework_LancyDer Anteil derjenigen Arbeiten, die bei der Kontrolle auf den Haufen „Erledigt“ kommen, werden in Lancys Grafik „Qualität“ genannt. In der Tat hängt es von diesem Anteil ab, ob das Projekt je fertig gestellt werden kann oder nicht. Es gibt einen „Kipp-Anteil“ (sog. tipping point), bei welchem das Projekt sozusagen an Ort tritt. Ist der Anteil höher als dieser Kippanteil, kommt das Projekt voran, andernfalls fällt es immer mehr zurück.

Damit heisst der Haupterfolgsfaktor: In einem Projekt so oft Reviews und Kontrollen machen, wie es nur geht! Das klingt einfach und selbstverständlich. Aber unterlassene Kontrollen sind der Hauptgrund für Verzögerungen in Projekten!

(1) Taylor, T./Ford, D. Tipping point failure and robustness in single development projects. Syst. Dyn. Rev. 22, 51–71, (2006)

(2) Lancy, P. Development Inefficienties – Managing the „Rework Cycle“ in Complex Projects. Australian Construction Law Newsletter ACLN, Issue #55, 1997

Ist das Web kaputt?

Zweifellos tragen Internet und Web in hohem Masse zu der Komplexität in Wirtschaft und Gesellschaft bei. Ohne Internet geht gar nichts mehr. Vor allem das Web befindet sich in einem Phasenübergang, was Sascha Lobo zum Urteil bewegte, es sei „kaputt“.

Daten sollten öffentliches Gut sein

Es zeigen sich Probleme, die zu Beginn des Webs nicht vorstellbar waren. Vorratsdatenspeicherung, Internetzensur, Erstellen von Verhaltensmuster durch Big Data Analysen, Handel mit persönlichen Daten, rechtliche Fragen betreffend Schutz der Privatsphäre, etc. Zwar wurde Frau Merkel ausgelacht, als sie sagte, dass das Web Neuland sei, aber sie hatte völlig recht. Die Problemstellungen, die das Web heute aufwirft, sind völlig neu und stellen uns alle vor grosse Herausforderungen. Wer soll sie lösen?

Ursprünglich war die Idee des Webs, dass alle daran gleichermassen partizipieren können. Für viele waren Daten ein öffentliches Gut, wie Luft und Wasser. Nur für die Aufbereitung des letzteren fallen Gebühren an. Daten müssen öffentlich sein, sonst könnte man keine webweiten Recherchen machen (viele nennen das „googeln“, aber es gibt noch andere Suchmaschinen). Zu diesem Zweck wurde auch die Creative Commons Lizenzen entwickelt. Netizen (Netzbürger) stellen ihre Werke als Gemeingut zur Verfügung. Auf meinen Artikeln und Fotos will ich kein Copyright beanspruchen.

Der Sinn des Webs liegt im Recherchieren

Webrecherchen sollen alle machen dürfen. Weiter ist es jedem freigestellt, die Recherchenresultate für Auswertungen zu speichern. Die israelitische Datenexpertin Kira Radinsky hat kürzlich ein interessantes Modell vorgestellt, mit der sie eine Pestepidemie vorhersagen konnte. Dazu sammelte sie u.a. auch Millionen von Facebook- und Twittereinträge und wertete diese mittels Big Data Algorithmen aus. Das ist bestimmt eine gute Sache!

Es wird nicht möglich sein, den Geheimdiensten zu verbieten, dasselbe zu tun. Hingegen ist es moralisch nicht vertretbar, wenn sie Unternehmen zwingen, ihre Daten herauszugeben. Wenn allerdings diese Unternehmen die Daten so oder so verhökern, dann können sie auch von Geheimdiensten gekauft werden.

Der Moloch „Allgemeine Geschäftsbedingungen“

Die Frage ist also, inwieweit Unternehmen, wie z.B. Google, auf Daten, die durch ihre Server rauschen, zugreifen und sie kopieren dürfen. Ein Jurist würde vielleicht nach den Allgemeinen Geschäftsbedingungen fragen (AGB). Wenn Sie eine Dienstleistung von Google beanspruchen, dann akzeptieren Sie Google’s AGB. Und wenn in diesen AGB steht, dass es Google erlaubt ist, alles, was Sie versenden, weiter zu geben, dann wird die Sache kompliziert.

Hannes Grassegger (1) hat zum Thema AGB einen interessanten Artikel veröffentlicht, den jeder Netizen lesen sollte. Für mich ist das Fazit nicht „Das ist ja ungeheuerlich!“, sondern „Hier gibt es noch viel zu tun“, denn Grassegger suggeriert eigentlich nur die Ablehnung der AGB. Wenn ich aber googeln will, habe ich keine Wahl, ob ich Googles AGB annehmen will. Ich will die Dienstleistungen von Facebook nutzen. Dann bleibt mir keine andere Wahl, als ihre AGB zu akzeptieren

Ich habe meinen Projektverträgen immer AGB beilegen müssen, und in zwei bis drei Fällen sogar eigene verfasst. Es war schon immer üblich, dass Dienstleistungserbriger die AGB vorschreiben. Z.B. ist der Gerichtsstand stets am Ort des Dienstleistungserbringers. Gerade, wenn ein Erbringer Millionen von Kunden hat, die auf der ganzen Welt verstreut sind, kann er nicht für jeden individuellen Kunden einen anderen Gerichtsstand definieren.

Neu ist, dass Dienstleistungen quasi in der Wolke erbracht werden können, dass also kein Erbringungsort identifiziert werden kann. Neu ist auch die Dimension, mit der Millionen von Kunden gleichzeitig gleiche oder ähnliche Dienstleistungen beanspruchen können. Es gibt keinen Check-out, wo man abrechnet. Diese Dimension setzt eine ungeheure Infrastruktur voraus. Die Netzkultur fordert aber, dass zumindest Basisdiensleistungen im Web gratis sind.

Vorratsdatenspeicherung kann auch eine gute Seite haben

Der Vorwurf, dass Google (und andere) unsere Daten speichert, kann ich schlecht nachvollziehen. Ich hoffe doch sehr, dass meine Daten gespeichert und verbreitet werden. Es wird das einzige sein, das von mir übrig bleibt. Wer sich schon mal in der eigenen Familiengeschichte umgesehen hat, der weiss, wie wertvoll Kirchenrodel sind. Da stehen zuweilen auch schon mal intime Dinge drin. Dass sich ein Vorfahre von mir beschwert hat, weil die Gemeinde an seiner Hochzeit keine Musikkapelle stellte, kann noch als lustige Anekdote angesehen werden. Wenn aber die ledige Mutter im Kindbett gezwungen wird, den Namen des Kindvaters rauszurücken (damit die Gemeinde nicht zahlen muss), dann wird’s schon heikler.

Heute gibt es keine Kirchenrodel mehr. Ich freue mich, wenn ich z.B. auf http://archive.org/web/ die Entwicklung meiner Website von 1996 bis heute nachvollziehen kann, weil sie auch ohne mein Einverständnis periodisch gespeichert wurde. Ich freue mich, wenn Google Newsgroup-Einträge „auf immer und ewig“ speichert und ich dort stets die Antworten nachschlagen kann, die mir auf meine Fragen gegeben wurden. Ich freue mich, wenn WordPress meinen Blog möglichst ewig speichert und offen hält.

Was soll man tun?

Ich möchte nicht den Eindruck erwecken, als würde ich die Entwicklung des Webs nur rosig sehen. Im Gegenteil: sie macht mir manchmal Angst. Wie ich eingangs erwähnt habe, gibt es grosse Herausforderungen zu meistern. Alles kann zum Guten und zum Schlechten genutzt werden. Es wäre aber falsch, wenn Gesetzgeber das Web zu regeln versuchen. Genau das wollen wir nicht. Wir müssen uns vielmehr dafür einsetzen, dass staatliche Eingriffe und Zensurmassnahmen abgebaut werden und zwar nicht mit der lapidaren Forderung „löschen statt sperren“.

Webabstinenz ist jedenfalls kein hilfreicher Ansatz. Niemand kann sich aus dem Einfluss des Webs fern halten. Die Welt findet zum grossen Teil im Web statt und wirkt sich auf alle aus, ob sie nun teilnehmen oder nicht.

(1)    Grassegger, Hannes. Schlechter Deal. Das Magazin, 23/2014. S. 18. 7. Juni 2014.

Können charismatische Persönlichkeiten die Gesetze von Zahl und Wahrscheinlichkeit austricksen?

Im Siebenjährigen Krieg hatte sich Friedrich der Grosse gegen Österreich, Frankreich, Russland und das übrige Deutschland gestellt. Eigentlich hätte Preussen gegenüber der zahlenmässigen Übermacht seiner Gegner keine Chance gehabt.

Der Zufall kommt zu Hilfe

K1024_friedrich_der_grose-3Dennoch glaubte Friedrich in enormer Selbstüberschätzung an einen Sieg. Er verstand zwar, dass er sich in einer Alles-oder-nichts-Situation befand, glaubte aber daran, dass die Siegeschancen nicht zu gering seien.

Zufälligerweise starb die Zarin, während ihr Nachfolger als Bewunderer Friedrichs mit Preussen sofort einen Friedens- und Bündnisvertrag schloss. Das hatte Signalwirkung und schwächte die Koalition der Preussengegner dermassen, dass sie zerfiel und der Krieg mit der Festsetzung des Status quo ante bellum beendet wurde.

In einer Friederich-Dokumentation, die der Sender ZDF_neo am Donnerstag, 3. April 2014, ab 08:05 Uhr, ausstrahlte, sagte ein Historiker über Friederichs Auseinandersetzung gegen eine Übermacht:

Daraus hat die Nachwelt im Ersten Weltkrieg, im Zweiten Weltkrieg, geschlossen, dass wenn man nur die richtige Einstellung hätte, wenn man so handeln würde wie Friedrich, wenn solche Personen an der Spitze sind, dann könne man die Gesetze von Zahl und Wahrscheinlichkeit erneut ausser Kraft setzen

Wird das nicht sogar in Führungsseminarien gelehrt? Geniessen heute nicht „charismatische Persönlichkeiten“ und „Macher mit Selbstvertrauen“ grosses Prestige?

Genügt allein der feste Glaube, um alles zu erreichen?

Mir scheint, dass wir in den letzten Jahrzehnten wenig dazu gelernt hätten. Noch immer wird propagiert, dass man alles erreichen könne, wenn man nur fest daran glaube. Das ist Quatsch und fördert Selbstüberschätzung, die nicht nur zu aussichtlosen Projekten verleitet, die scheitern müssen, sondern auch grosse wirtschaftliche Schäden und sogar unsägliches menschliches Leid verursachen können.

Immerhin forderte der Siebenjährige Krieg über eine halbe Million Soldatenopfer und nochmals so viele zivile Opfer. Die Zahl der Kriegsversehrten ist unbekannt, dürfte aber die Zahl der Toten weit überschreiten. Armut und Hunger verbreitete sich. Für die Bevölkerung waren die Kriegsfolgen katastrophal. Der Bankrott des Königreichs Frankreich hat der Siebenjährige Krieg mitverursacht. Der Bäckermeister Abelmann aus Hannover schrieb:

Verheerte Länder, in welchen die Dörfer von Menschen leer… Thränende Augen! Blutende Wunden! verstümmelte Glieder zu Tausenden! … Gemißhandelte, Barbarisch Gemißhandelte!

P.M.Magazin, 27.3.2013
P.M.Magazin, 27.3.2013

In „Selbstüberschätzung ist positiv“ erklärt P.M. Online, dass Forscher herausgefunden haben wollen, dass Selbstüberschätzung von der Evolution begünstigt wurde.(1) Das ist zweifellos richtig, und ohne Selbstüberschätzung wären wir nicht da, wo wir heute sind, sondern würden vielleicht immer noch in Höhlen wohnen. Damals befähigte sie uns, ein Haus zu bauen.

Das heisst aber nicht, dass Selbstüberschätzung für immer und ewig positiv bleiben muss. Ich behaupte, dass sie heute nicht mehr vorteilhaft ist.

Wie weit können wir uns auf unsere Intuition verlassen?

Die Überschätzung der Intuition und Infragestellung der Rationalität geht mitunter auf den Eindruck zurück, der Friedrichs Handeln angesichts einer Übermacht hinterlassen hat. Seine Intuition sagte ihm, dass er gegen alle Vernunft die Gesetze der Wahrscheinlichkeit aushebeln könne. Dass seine Intuition falsch war und er nur aufgrund von Zufällen – also gerade dank der Wahrscheinlichkeit – vor einer Niederlage verschont blieb, interessiert im Nachhinein offenbar niemand mehr.

Die Überschätzung der Intuition verhindert ein analytisches Hinterfragen von Zusammenhängen und verleiht falsche Sicherheit. Das ist meines Erachtens in einer Zeit hochkomplexer technischer, gesellschaftlicher und wirtschaftlicher Systeme gefährlich. Der alte Fritz hätte die Verhältnisse vielleicht noch halbwegs überblicken können. In unserer Zeit ist das definitiv vorbei. Wir sind auf unsere Ratio und denkunterstützende Werkzeuge angewiesen!

(1) Dräger, Juliane. Selbstüberschätzung ist positiv. P.M. Online, 27.03.2013

Projekte sind so verschieden wie Einfamilienhäuser, Hochregallager und Spitäler

In Diskussionen über Projekte wird meist so getan, als gäbe es das Phänomen „Projekt“ schlechthin. Manchmal kennen sich die Diskussionsteilnehmer aber nur in ihrer Projektart aus und schliessen dann aus ihren Erfahrungen unzulässig auf andere Projektarten.

Das ist auch nicht verwunderlich. Ein Projekt dauert oftmals mehrere Jahre. Wenn es erfolgreich war, wird der Projektmanager in einem ähnlichen wieder eingesetzt. Bis er um die zehn Projekte durchgeführt hat, sind 20 bis 30 Jahre vergangen. Dann hat er grosse Projekterfahrung, aber eben meist ausschliesslich in dieser einen Projektart.

Man kann Projekte nicht schubladisieren

Projekte so verschieden, wie Gebäude. Das Projektmanagement verschiedener Projekte unterscheidet sich, wie das Leben in verschiedenen Gebäuden. In einem Einfamilienhaus zu leben „fühlt“ sich ganz anders an, als in einem Hochregallager zu arbeiten. Für den Betrieb eines Spitals gilt das Augenmerk auf anderen Dingen, als es für den Betrieb einer Universität. Niemand käme auf die Idee, das Management einer Schule mit demjenigen eines Hochregallagers auf einen Nenner zu bringen, nur weil es in beiden z.B. eine Eingangstüre gibt.

Nur betreffs Projektmanagement ist man immer noch der Überzeugung, dass es einen gemeinsamen Nenner geben muss. Warum unterscheiden wir nicht deutlich zwischen so verschiedenen Dingen wie Strassen- und Hochbauprojekte oder IT-Entwicklungs- und Migrationsprojekten?

Es spielt eine Rolle, ob der Auftraggeber unter demselben Dach ist oder nicht

Allenfalls wird zwischen IT- und Bauprojekten unterschieden, obwohl es viele IT-Projekte gibt, die näher an Bauprojekten sind, als an anderen IT-Projekten. Ein IT Entwicklungsprojekt gehorcht ganz anderen Gesetzmässigkeiten als ein IT Migrationsprojekt. Diese Gesetzmässigkeiten werden noch viel zu wenig berücksichtigt, wenn es darum geht, ein Projekt zu beurteilen.

Kürzlich wurde im Fernsehen gezeigt, was es braucht, um einen Sender an den Olympischen Spielen zu installieren. Das Schweizer Fernsehen musste tonnenweise Kisten nach Sotchi verschicken,  mit Dutzenden von Bildschirmen, elektronischen Geräten, Kabel, Stellwände, Kameras, etc. Material, das am Bestimmungsort angekommen ist, muss geprüft, installiert und getestet werden.

Das brauchte eine sehr professionelle Planung, Koordination und Projektleitung. Das Projekt ist eng verwandt mit einem IT Integrationsprojekt. Während für das TV-Projekt der Auftraggeber und der Projektführer zu derselben Unternehmung gehören, sind in einem IT-Projekt Auftraggeber und Projektführer zwei unterschiedliche Unternehmen, zwischen denen grundsätzlich Misstrauen herrscht.

Zwar haben in beiden Projekten die Auftraggeber Tausende von Endkunden, aber im TV-Projekt ist der Auftraggeber angestellt, während er im IT-Projekt eine Unternehmung ist, deren Existenz wesentlich vom Projekterfolg abhängt. Die Interessenlagen, Befindlichkeiten, organisatorischen Gegebenheiten, Machtstrukturen und Motivationen sind jeweils ganz verschieden.

IT heisst nicht einfach nur programmieren 

Noch unterschiedlicher sind z.B. ein IT-Entwicklungsprojekt und ein IT-Migrationsprojekt. Auf ein Entwicklungsprojekt kommen hoffentlich 100 Integrations- und Migrationsprojekte, in welchen das einmal entwickelte Produkt ausgerollt und verkauft werden kann.

IT heisst nicht a priori entwickeln und programmieren. Der grössere Teil des „Kuchens“ nimmt eher der Betrieb ein. Obwohl Betrieb stetig und ohne Ende ist, wird er von vielen kleineren und grösseren Projekten begleitet. Jedes Mal, wenn ein System „end of life“ ist, muss es ersetzt werden. Das macht man in einem Migrationsprojekt. Da wird nichts entwickelt, sondern eingekauft, installiert, getestet und eingeführt. Das kann schon mal ein paar Monate dauern.

Fehler, die in den Tests manifest werden, müssen vom Produktemanagement wohl gefixt werden, aber das ist eher Produkteunterhalt und nicht mehr Entwicklung. Das Entwicklungsprojekt ist möglicherweise längst abgeschlossen, obwohl ihm die zutage geförderten Fehler angelastet werden müssten. Insofern weiss man beim Abschluss eines Entwicklungsprojekts nicht einmal, wie erfolgreich es war. Das ist in Bauprojekten völlig anders. Wenn die Brücke einstürzt, wir der Projektleiter zur Rechenschaft gezogen, während der Projektleiter eines Entwicklungsprojektes meist längst woanders arbeitet, wenn gravierende Produktefehler auskommen.

Die Umstände sind in jedem Projekt so verschieden, dass man nicht allgemeine Projektmanagementregeln aufstellen kann. Weder kann man behaupten, dass am Anfang eines jeden Projekts eine Breakdown Structure stehen müsse, noch dass jedes Projekt mit agilen Methoden durchgeführt werden kann. Das sind bloss undifferenzierte Betrachtungsweisen.