Schlagwort-Archive: Migrations- und Integrationsprojekte

Ist agiles Projektmanagement immer anwendbar?

Im Umgang mit Komplexität sind agile Methoden heute in aller Leuten Munde. Wenn man unter einer komplexen Situation aber eine Situation versteht, die

  • unübersichtlich
  • vernetzt
  • unbestimmt

ist, dann sind agile Methoden im Umgang mit Komplexität meines Erachtens nicht notwendigerweise hilfreich. In Entwicklungsprojekten ist agiles Projektmanagement ein sehr nützlicher Ansatz, wenn man aus einem Produktebacklog gerade so viele Funktionen entnehmen kann, wie man in einer bestimmten Zeit entwickeln mag. Für Migrations- und Intregrationsprojekte (MIP) sind agile Techniken jedoch weniger geeignet1. Um das einzusehen, erinnern wir uns, dass Migrations- und Integrationsprojekte oft mit der Aufgabe starten, gelieferte Hardware zu entpacken, in einem Rack zu montieren, an ein Netz anzuschliessen und in Betrieb zu nehmen. Dazu gehören natürlich erste Funcional Tests, insbesondere Pingtests zu gewissen Servern in der bestehenden Umgebung.

Für die Montage und Grundinstallation sind z.B. 10 Tage geplant. Wenn die agile Projektmethodik eine Timebox von 4 Wochen vorgesehen hat, lässt sich aus der Montage keine Timebox machen.
Das agile Prinzip, innerhalb einer Timebox keine Changes zuzulassen, greift hier auch nicht, denn Changes sind in einem MIP nicht das grosse Schreckgespenst. Wenn der Kunde das Rack innerhalb des Serverraums zig Mal umplazieren will, nervt das zwar, ist aber weiter kein Problem. Changes machen auch noch keine Komplexität aus. Das Schwierige in MIP sind Ereignisse, die sowohl für den Kunden als auch für den Lieferanten gleichermassen unvorhergesehen sind. Eine typische Unvorhersehbarkeit während einer Montage ist die Tatsache, dass irgendwelche Firewalls nicht richtig konfiguriert sind (das ist mittlerweile derart typisch, dass es schon keine Unvorhersehbarkeit mehr ist, sondern als vorhersehbares Risiko behandelt werden kann. Aber sagen Sie das einmal dem Kunden…).

Ein weiteres agiles Prinzip ist der Kundennutzen. Jede Iteration soll einen bestimmten Kundennutzen haben. Jede weitere Iteration erhöht den Kundennutzen. Eine Reihe von Iterationen werden zu einem Release zusammen gefasst, der eigentlich schon ein fertiges Produkt darstellt. Das geht bei MIP nicht. Das Resultat der Monatge enthält kaum Kundennutzen, musst aber dennoch gemacht werden. Daraufhin folgt die Installation der Software und anschliessend monatelange Tests bis zur Migration oder der Abnahme. Man kann nicht eine Iterationfolge „ein bisschen Montage, ein bisschen Software, ein bisschen Tests“ machen, um einen ersten Release zu haben. Das geht in MIP nicht. MIP sind wie eine Schwangerschaft: man installiert einen bestimmten Release; alles oder nichts. Ein weiterer Release ist ein neues MIP.
Da eine vollständige Benutzerdokumentation zum Lieferumfang eines MIP gehört, gilt auch das agile Prinzip „funktionstüchtige Produkte vor umfangreicher Dokumentation“ hier nicht. Ob das Produkt funktionstüchtig ist, liegt nicht in der Macht des MIP, sondern des vorangegangenen Entwicklungsprojekts. Eine vollständige und umfangreiche Dokumentation ist jedoch ein typisches Deliverable eines MIP.

Für Entwicklungsprojekte mögen agile Techniken eine hervorragende Methode sein. Auf ein Entwicklungsprojekt kommen hoffentlich viele Migrations- und Integrationsprojekte. Schliesslich will man das entwickelte Produkt oft verkaufen und ausrollen. Agile Techniken sind aber für das Management von Migrations- und Integrationsprojekten nicht sehr geeignet.

1Addor, P. Projektdynamik – Komplexität im Alltag. Liebig Verlag, Frauenfeld 2010, S. 65ff

Bye, bye Requirements Engineering

Im Zusammenhang mit Anforderungen sind die Funktionen eines Systems zentral. Auch blosse Eigenschaften können Funktionen sein. In Zertifiziert für das Unmögliche: Anforderungen formulieren habe ich gesagt, dass in Migrations- und Integrationsprojekten meistens Standardsysteme zum Einsatz kommen, die allenfalls customized werden. Solche Projekte können nicht vollständig spezifiziert werden, weil niemand in der Lage ist, alle Funktionen eines (Standard-)systems zu kennen. Denken Sie z.B. an ein Automobil, genauer gesagt, einen Personenwagen (PW). Glauben Sie, sie könnten die Funktionen eines PW aufzählen? Wahrscheinlich sind Sie nicht einmal in der Lage, auch nur 10% aller Funktionen eines PW aufzuzählen, und dies nicht nur wegen des Problems unterspezifizierter Initialkonditionen, von dem Fischhoff et al. berichten1. Es gibt immer auch hidden functions. Klaus Pohl berichtet, dass allein die Steuerung einer PW-Elektronik 2’500 Funktionen umfasst2. Jede dieser Funktion ist auch eine Funktion des PW. Natürlich interessieren Sie sich allenfalls für ein halbes Dutzend dieser Elektronikfunktionen, der Rest sind eben hidden functions, mit denen Sie sich gar nicht erst auseinandersetzen wollen. Aber können Sie sicher sein, dass sich nicht eine dieser 2’500 Funktionen für Sie negativ manifestieren wird? Es könnte doch sein, dass sich eine dieser unzähligen Funktionen mit der Zeit für Sie als lästig bemerkbar machen wird. In vollständigen Anforderungen an das System PW hätten Sie diese Funktion ausdrücklich untersagt, wenn Sie sie im Voraus gekannt hätten. Hidden Functions von IT-Systemen, die in komplexe Umgebungen eines informationsintensiven Unternehmens integriert werden müssen, stören oft andere Systeme, weil die Entwickler nicht alle Umgebungen kennen konnten, in welchen ihr System jemals in Einsatz gelangt.

Im übrigen gibt es Funktionen, die eigentlich Funktionenkomplexe sind. Beispielsweise ist doch die wichtigste Funktion eines PW, dass er fahren möge. Meinen Sie „fahren“ oder „transportieren“? In jedem Fall verbirgen sich hinter beiden Funktionenkomplexen viele Einzelfunktionen, wie z.B. vorwärts fahren, rückwärts fahren, im Schritttempo vorwärts fahren, sehr schnell vorwärts fahren. Meinten Sie „transportieren“, so sind Einzelfunktionen eine Person transportieren, mehr als eine Person transportieren, im Rahmen des Strassenverkehrsgesetz transportieren, Waren transportieren, mehr als einen Kubikmeter Waren transportieren, usw. Die Unterteilung eines Funktionenkomplexes ist sehr willkürlich. Wann haben Sie hinreichend unterteilt? Wann haben Sie zu sehr fragmentiert? Was ist überhaupt noch eine Funktion? Schliesslich gibt es Sekundärfunktionen. Z.B. kann ein PW auch die Funktion haben, Ihnen gesellschaftliches Ansehen zu verleihen, oder zumindest Ihnen den Eindruck zu geben, dass Sie wegen Ihres PW zu mehr gesellschaftlichem Ansehen gelangen.

Ein System kann auch implizite Funktionen haben. Das sind solche, die niemand spezifiziert und entwickelt hat. Alle die 2500 Funktionen der Elektroniksteuerung mussten einzeln spezifiziert und implementiert werden. Auch die Funktion, gesellschaftliches Ansehen zu verleihen, wurde zumindest teilweise explizit spezifiziert, z.B. durch ein schnittiges Design oder durch entsprechendes Marketing. Ein Porsche kostet nicht nur so viel, weil er wirklich so gut ist, sondern auch, um eben den Namen Porsche als Nobelmarke zu platzieren. Aber ein PW kann auch Funktionen haben, die nicht spezifiziert worden sind.

Wie wir sehen ist es nie möglich, abschliessend zu sagen, wieviele Funktionen ein System hat oder haben kann. Bye, bye Requirements Engineering!

1B. Fischhoff, P. Slovic & S. Lichtenstein. Fault Trees: Sensitivity of estimated failure probabilitiesto problem representation. Journal of experimental psychology: Human Perceptions and Perfomance. 4/1978, 330-334

2Klaus Pohl. Leitfaden für modellbasiertes Requirements Engineering und Requirements Management softwareintensiver Eingebetteter Systeme
gefördert durch das BMBF im Rahmen der Forschungsoffensive „Software Engineering 2006“

Das Alte war gut. Die Entwickler des Neuen haben keine Ahnung!

In seinem Buch Die Kritische Kette sinniert Eliyahu Goldratt auf der Basis der Theory of Constraints über die Wahrscheinlichkeit nach, mit der ein Task, eine Phase oder ein ganzes Projekt nach einer bestimmten Zeit terminiert wird1. Er macht dabei den Vergleich zu dem Nachhauseweg nach der Arbeit. Unter 20 Minuten können Sie nicht zu hause sein. Meist sind es 30 Minuten. Wenn viel Verkehr ist, dann benötigen Sie sogar 40 Minuten. Und wenn Sie noch einen Kollegen treffen und mit ihm ein Bier trinken, sind Sie nicht vor 120 Minuten zu hause. Goldratt fragt dann, mit welcher Terminierungswahrscheinlichkeit wir planen sollen. Meines Erachtens ist das in Migrations- und Integrationsprojekten (MIP) die falsche Frage. Ganz abgesehen davon, dass Sie die Terminierungswahrscheinlichkeiten für einzelne Tasks und Phasen in MIP gar nicht kennen, werden typische MIP-Tasks nie fertig. Das kommt daher, dass z.B. bei einer Migration ein bestehendes System abgelöst werden soll und das neue System den Kunden vorerst niemals zufrieden stellen kann, weil es doch etwas anderes ist, als das ihm vertraute alte System. Stets vergleicht er das neue System mit dem abzulösenden, dem er tief in seinem Herzen eine Träne nachweint. Zudem kennt er das neue System noch nicht so gut und muss die Bedienung vieler Funktionen zuerst kennen lernen. Wer von uns kennt das nicht? Bis man mit einem Gerät wirklich vertraut ist und seine Stärken und Macken kennt, muss man es viele Male bedient haben, um nicht zu sagen, man müsse es in sein Leben integriert haben. Unsere Fernseher, Waschmaschinen, Autos, PCs oder Musikanlagen sind doch ein Teil unseres Lebens geworden. Wenn wir ein solches Teil jemals ersetzen müssen, finden wir eine Menge von Mängel am neuen Teil. Aber nach paar Wochen ist auch das neue Gerät ein Teil unseres Lebens geworden, und wir wissen schon gar nicht mehr, wie das alte bedient werden musste. Das Projekt „neues Gerät anschaffen und in Betrieb nehmen“ ist beendet, wenn das neue Gerät angeschlossen und betriebsbereit ist. Genau in dieser Phase haben wir allerlei zu bemängeln und herum zu nörgeln. Ich nenne das das Umgewöhnungssyndrom. Leider können wir als kleine Endkunden dem Lieferanten das Gerät nicht um die Ohren schlagen. Wenn aber z.B. eine Bank von einem Systemhaus eine neue Bankenlösung kauft und für die Migration Dutzende, wenn nicht Hunderte von Millionen bezahlt, dann kann sie den Lieferanten solange festnageln, bis sie sich endlich an das neue System gewöhnt hat. Das verzögert das Projekt ungemein.

Sehr schön studieren kann man den eben beschriebenen Effekt bei Acceptance Tests, die ein wichtiger Teil von jedem MIP sind. Dazu wird ein Testdrehbuch benötig, das die durchzuführenden Tests enthält zusammen mit Angaben über Durchführungsdauer, Start- und Endzeitpunkt, Testverantwortliche, zu erwartende Resultate, etc. Sollen z.B. 100 Tests durchgeführt werden die je 15 Minuten dauern, dann wird die Projektplanung 25 Stunden vorsehen. Erfahrungsgemäss sieht die Planung und die dazugehörende Fortschrittskurve so aus:

 

Eine solche Planung passt eher in ein Straflager. Auch noch so arbeitsame Mitarbeiter gehen mal einen Kaffee holen oder müssen die Toilette besuchen. Ab und zu muss das Testdrehbuch diskutiert oder ein Bedienungsmanual konsultiert werden. Zudem kommen Telefone und die Mails müssen gecheckt werden. Die effektive Produktivität einer Ressource beträgt normalerweise zwischen 70 und 80 Prozent.
In den letzten paar Jahren habe ich die effektiven Testfortschritte aus mehreren Projekten ausgewertet und stets folgendes gefunden:

 

Am Anfang wird ein Initialaufwand dazu führen, dass die Ausführung der Tests der Planung etwas hinten her hinkt, weil der Projektleiter die Rüstzeiten vergessen hat. Diese sind aber schnell eingeholt, und weil alles so gut geht überholen die aktuellen Tests die Planung sogar. Das kommt daher, dass man zuerst die einfachen und unproblematischen Tests durchführt. Der Projektleiter muss bei jeder Steeringboard-Sitzung den Projektfortschritt vorweisen. Er wird quasi am Fortschritt gemessen. Daher wird er solange unproblematische Tasks oder Pfade bearbeiten, wie er kann. Goldratt schreibt: Weil ein Fortschritt auf einem Pfad eine Verzögerung auf einem anderen Pfad kompensiert. Also scheint ein rascher Fortschritt auf einem beliebigen [auch nicht-kritischen] Pfad angebracht2. Das schafft Vertrauen. Doch dann beginnt es zu harzen. Einige Tests müssen wiederholt werden. Schwererwiegende Probleme müssen sogar mit der Entwicklung besprochen werden. Es gibt Fälle, in denen das Verhalten des Systems zunächst unerklärlich ist und analysiert werden muss. Das kostet viel Zeit, die nie mehr eingeholt werden kann. Und schliesslich wird der Kunde genau in diesem Zeitpunkt, in welchem die Fortschrittskurve abflacht, vom Umgewöhnungssyndrom erfasst. Das neue System passt ihm (noch) nicht so recht, weil er es noch nicht kennt. Er möchte, dass es wie das alte funktioniert und wird viele Einwände, Wünsche oder zumindest Fragen haben. Er wird verlangen, dass Testfälle ein wenig verändert und wiederholt werden. Das Problem ist also weniger die Terminierungswahrscheinlichkeit, die die Theory of Constraints untersucht, noch der Rework Cycle, wie er von System Dynamics vorausgesagt wird. Das Problem in Migrations- und Integrationsprojekten ist das Umgewöhnungssyndrom. Daher werden die Acceptance Tests nie fertig. Man muss sie irgend einmal einfach „gewaltsam“ als abgeschlossen erklären. Ganz ähnlich verhält es sich mit ganzen Migrations- und Integrationsprojekten. Auch diese werden nie so richtig fertig.

1Eliyahu Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a.M. 2002.
2 ebenda, S. 80.

Selbstverständlichkeiten müssten doch nicht gefordert werden, oder?

Für letzten Samstag musste ich ein Clubfest mit 90 Personen organisieren. Ich wollte das Fest an einem etwas originelleren Ort durchführen, als in einem Hotel. Aber wo nimmt man gleich einen Festraum für 90 Personen her? Ich beauftragte also eine mir bekannte Eventagentur zur Durchführung des Anlasses. Damit ist die vertragliche Rahmenstruktur eines Migrations- und Integrationsprojektes gegeben.

Ein Lieferant (L) mit möglicherweise einem oder mehreren Unterlieferanten (UL), ein Kunde (K) und eine Menge von Endkunden oder -benutzern, die vom Kunden bedient werden. Die Projektpartner sind der Kunde und der Lieferant. Mit den vertraglichen Abmachungen zwischen dem Lieferanten und seinen Unterlieferanten hat der Kunde nichts zu tun, genau so wenig, wie der Lieferant mit den Endbenutzerverträgen etwas zu tun hat. Typisch ist ein Telekommunikationsanbieter, der bei einem Lieferanten beispielsweise einen Voice Switch bestellt und damit Tausenden von Endkunden einen Telefonservice anbieten will. Die Material- und Informationsflüsse hingegen, können sich durchaus über die vertraglichen Bindungen hinweg setzen. So kann es sein, dass ein Unterlieferant Material direkt beim Kunden anliefern muss, während Endkunden Retouren direkt zum Lieferanten schicken können.

In meinem Eventprojekt musste ich zunächst dem Organisator meine Erwartungen bezüglich eines Raumes spezifizieren, in welchem das Fest stattfinden soll. Das ging Hand in Hand mit dem gewünschten Rahmenprogramm. Dazu legte er mir einen Katalog vor. Ich wählte „Erlebniszene Schweiz“ mit vielen bäuerlichen und ländlichen Szenen drin. Dazu passte die Scheune eines Bauerhofs als Veranstaltungslokal perfekt. Der Organisator suchte also eine Scheune in dem Raum, den ich vorgängig bestimmt hatte. Er fand ihn in Form eines Neubaus, der vom Bauherrn, dem Bauer, gerade noch nicht bezogen worden ist. Somit musste der Bauer nur noch überredet werden, die Scheune zu vermieten, was dem Organisator gelang. Nun konnte die Feinorganisation beginnen. Wer ist wofür verantwortlich? Einen Anlass „off shore“ zu organisieren ist immer teurer, als wenn der Anlass z.B. in einem Hotel stattfindet, denn man muss jeden Dessertlöffel mitbringen. Alle Tische, jeden Stuhl, jedes Salzfässchen, einfach alles muss transportiert werden, ja sogar Toilettenhäuschen mit fliessendem Wasser. Dazu brauchte es einen Wasseranschluss, die mobile Küche benötigte einen zusätzlichen Stromanschluss, etc. Es steckt viel hinter der Organisation eines solchen Anlasses, was sich im Preis der Bankettkarte niederschlug. Dennoch reichte nicht, was die Gäste zahlten. Der Club musste subventionieren. Aber eine Clubkasse ist meist bescheiden gefüllt, so dass wir uns bei jedem Extra wohl überlegten, ob oder ob nicht. Wir waren uns bewusst, dass es in der zweiten Septemberhälfte nicht mehr laue Abende gibt, entschieden uns aber dennoch gegen eine Heizung. Es genügte, dass sich in der Erfahrung des Organisators eine Heizung erübrigte. Wir hatte noch viele andere, wichtigere Dinge zu überdenken und die Zeit drängte. Soviele Leute in einem relativ kleinen Raum werden diesen schon aufwärmen. Das entsprach zwar der Erfahrung des Organisators, hat sich dann nicht bewahrheitet. Es lag vor allem an der Tatsache, dass just in diesen Tagen ein empfindlicher Kälteeinbruch stattfand und an der Architektur des Raumes: grosse, einfach verglaste Fensterscheiben erzeugten eine Kaltluftkonvektion. Hinzu kam, dass sich in der Diele eine Luke befand, so dass jedesmal, wenn die Türe geöffnet wurde, ein Zug entstand. Und die einzige und kleine Türe war fast permanent offen, weil immer jemand der Servicecrew etwas bringen oder holen musste. Resultat: alle Gäste froren und verliessen das Fest beim erst möglichen Aufbruchzeitpunkt mit der Bemerkung, dass eine Heizung ja doch eine Selbstverständlichkeit gewesen sei.

Genau das ist es, was in Migrations- und Integrationsprojekten sehr oft zu Streitereien führt. Entweder glauben die Endkunden ? oder noch schlimmer ? der Kunde, dass etwas, das nicht im Anforderungskatalog steht, eine Selbstverständlichkeit sei. Der Lieferant argumentiert, es sei nie gefordert gewesen, während der Kunde behauptet, das sei auch nicht nötig gewesen, denn es sei ja klar, dass das dazu gehöre. Mit „das“ kann eine Leistung, eine Einrichtung oder ein System gemeint sein.
In den meisten Fällen handelt es sich um etwas, woran weder Lieferant noch Kunde zuvor gedacht haben. In unserem Fall haben wir den Einsatz einer Heizung sogar noch diskutiert. Aber eine Heizung mit entsprechendem Kaliber hätte das ganze wesentlich verteuert. Dazu kommt, dass sich der Organisator auch nicht darum riss, noch eine Heizung zu installieren. Somit war die Heizung weder im Interesse des Lieferanten, noch des Kunden. In einem solchen Fall verschiebt sich Unzufriedenheit vom Kunden zu den Endkunden, so dass sie das Projekt nur indirekt tangiert. Aber grundsätzlich bleibt das Problem dasselbe: Geht etwas schief, wird eine Partei ? normalerweise der Lieferant ? zum Sündenbock erklärt, der eine Selbstverständlichkeit vergessen hat. In den meisten Fällen führt das dazu, dass der Lieferant einen Preisnachlass gewähren muss und so eine gewichtige Margeneinbusse verzeichnet.
Fast immer ist der Grund für die Unterlassung einer „Selbstverständlichkeit“ in einer Reihe von wissenbasierten Fehlern zu entdecken.
Hang zur Bestätigung: Eine vorläufige Hypothese, die auf ersten, ziemlich dürftigen Daten basiert, stört spätere Interpretationen reichhaltiger Daten1. Die Erfahrung des Organisators, dass in der zweiten Septemberhälfte noch keine Heizung nötig ist, hat uns beim Augenschein des Lokals „blind“ gemacht. Wir haben die Luke in der Diele sowie die grossen, einfach verglassten Fensterscheiben als Kältequelle übersehen.
Übermässiges Vertrauen: Beim Planen versucht man, den einmal eingeschlagenen Handlungsstrang zu rechtfertigen, indem man sich auf Anhaltspunkte konzentriert, die diese Handlungsweise nahe legen, und indem man widersprüchlichen Anzeichen keine Beachtung schnekt. Dazu kommt noch eine Bewertungsverzerrung durch einen abgeschlossenen Handlungsplan. Ein Plan ist auch eine Theorie über den zukünftigen Zustand der Welt. Er bringt Ordnung mit sich und verringert die Besorgnis1. Unser Plan hat alle beruhigt. Er enthielt die Theorie, dass es am 20. September nicht so kalt sein werde, dass man heizen müsse. Die meisten, die mit der Organisation etwas zu tun gehabt haben, haben den Plan als genügend bewertet.
Verzerrte Überprüfung: Der Planer wird zu einem bestimmten Zeitpunkt seinen Plan nochmals in Gedanken durchgehen und alle in Betracht kommenden Faktoren überprüfen. Diese Suche wird wahrscheinlich mit einer scheinbar zufriedenstellenden Anzahl berücksichtigter Faktoren enden1; doch Shepard2 wies darauf hin: „Obwohl wir uns erinnern, dass wir zum einen oder anderen Zeitpunkt jeden der verschiedenen Faktoren bedacht haben, merken wir nicht, dass wir selten mehr als einen oder zwei gleichzeitig in Erwägung gezogen haben“. Reason spricht hier von der „alles-klar-Täuschung“.
Rückschaufehler: Das Wissen um den Ausgang eines vergangenen Ereignisses führt zu einem Anstieg der wahrgenommenen Wahrscheinlichkeit dieses Ausgangs. Langer3 nannte dies „Kontrollillusion“1. Dass der Organisator im September schon oft ähnliche Anlässe mit Erfolg ohne Heizung durchgeführt hat, erhöhte die wahrgenommene Wahrscheinlichkeit, dass es auch diesmal ohne Heizung geht. Man beachte, dass nur die wahrgenommene Wahrscheinlichkeit gestiegen ist, die mit der moteorologischen Wahrscheinlichkeit, dass es im September warm genug ist, um ohne Heizung auszukommen, nichts gemeinsam hat.
Reduzieren der Komplexität: Wenn immer jemand das Gefühl hat, etwas sei selbstverständlich und einfach, dann hat er einfach die dahinter steckende Komplexität nicht verstanden, bzw. sie in Gedanken derart reduziert, dass sie kein Problem mehr darstellt. Das kann Ignoranz sein oder einfach nur Unwissen. Die Komplexität der heutigen Welt ist dermassen hoch, dass sie alles durchzieht, wie lokal und detalliert es auch sein mag. Wir haben Komplexität als höhere Strukturiertheit begriffen. Um etwas Selbstverständliches zu erreichen, müssen wir also bestehende Strukturen entwirren und neu knüpfen. Das ist so aufändig und zeitintensiv, dass es nicht mehr selbstverständlich ist. Der Vorwurf, jemand sei bloss zu bequem oder zu geizig, um eine Selbstverständlichkeit zu leisten, ist wahrscheinlich ebenso verfehlt, wie der Vorwurf, dass Vergesslichkeit auf Faulheit basiere. In beiden Fällen ist es eine Überforderung unseres 10’000 Jahre alten Gehirnmodells gegenüber der Komplexität, wie sie sich in den letzten paar Dutzend Jahren gebildet hat.

1James Reason. Menschliches Versagen. Spektrum Akademischer Verlag. Heidelberg 1994
2R.N. Shepard. On subjectively optimum selections among multiattribute alternatives. In M. Shelley & G. Bryan (Eds.), Human Judgements and Optimality. Wiley. New York, 1964
3E.J. Langer. The illusion of control. Journal of Personality and Social Psychology, 7/1975, pp185-207

Wasch mir den Pelz, aber mach‘ mich nicht nass

Migrations- und Integrationsprojekte (MIP) sind immer auch Veränderungsprojekte. Jedes System widersteht aber Veränderungen, wie wir schon bei der Bildung der Bénard-Zellen gesehen hatten. Ein grosses Problem bei der Durchführung von MIP ist die Tatsache, dass man ihr Veränderungspotential unterschätzt. Es ist allgemein anerkannt, dass ein Organisationsentwicklungsprojekt selbstreferentiell ist und daher ein grosses Veränderungsmoment entwickelt. Bei MIP denkt man, es gehe „bloss“ um die Integrierung eines technischen Subsystems, also von ein bisschen Blech und paar gespeicherten Daten oder gar „nur“ um die Migration einer bereits im Einsatz stehenden technischen Apparatur. „Störungen“, wie sie durch MIP hervorgerufen werden, können in komplexen Organisationen jedoch grosse Probleme nach sich ziehen. Komplexität zeichnet sich durch eine hochentwickelte Differenzierung des Systems aus und daher durch eine gewisse Inkohärenz in Bezug auf

  • Interpretation von Unternehmenszielen durch einzelne Abteilungen
  • Aufeinander bezogene Handlungszusammenhänge
  • Partikuläre Interessen
  • Homogenität, bzw. Heterogenität der Datenbestände
  • Flexibel definierte Aufgaben1

In einem MIP werden diese Inkohärenzen manifest und stellen die Organisation in ihrem bisherigen Funktionieren mehr oder weniger global in Frage. Auch ein sehr lokales Projekt kann weite Wellen schlagen. So habe ich mehrmals eine Migration eines sehr begrenzten Subsystems begleitet, die bei einem für den Gesamtkonzern des Lieferanten relativ unbedeutenden Kunden durchgeführt werden musste. Dennoch waren von der Entwicklung über das Produktmarketing und die weltweite Rollout-Abteilung bis zur lokalen Handelsgesellschaft mehrere Organisationsbereiche betroffen. Eskalationen des Kunden erschütterten jeweils ganze Managementketten quer durch das Lieferantenunternehmen.
Man kann davon ausgehen, dass sich technischer und organisatorischer Wandel im Fall einer Integration von Informationstechnologien in die Prozesslandschaft einer Organisation nicht trennen lassen1. Trotzdem verliert sich das Bewusstsein dieser Verknüpfung im Zuge der Konzeptrealisierung immer mehr, so dass es bei der Planung letzen Endes jeweils nur noch um Technik geht2. Meiner Meinung nach sollten Projektleiter von MIP weniger Engineers sein als vielmehr Systemiker. Das hat auch eine Bedeutung für die Curricula von Ausbildungsstätten für Wirtschaftsinformatiker. Diese sind in der Regel viel zu techniklastig, haben aber wenig Ahnung von systemdynamischen Zusammenhängen, wie sie in diesem Blog dargeboten werden. Zwar wissen unsere Wirtschaftsinformatiker wie man mit dem Chinesischen Restsatz Daten verschlüsselt, aber wie das Gehirn eines Projektleiters funktioniert oder welche unterschiedlichen Verzögerungen es in MIP geben kann, weiss selten einer. Auch Institute, die dedizierte Projektmanagementausbildungen anbieten sowie die bekannten Zertifizierer, wie IPMA oder PMI, beziehen den Projektmanagementprozess fast ausschliesslich auf die Lösung technischer Fragen. Sogar in einem Kapitel zum Thema „Kommunikation“ werden vor allem Fragen behandelt, in denen es darum geht, wie man über die technische Lösung kommunizieren soll. Zwar haben Lullies et al. schon 1990 darauf hingewiesen, dass bei verschiedenen Stellen verschiedene Vorstellungen, Ideen und Perspektiven zu einem Planungsthema bestehen und MIP stets Machtpositionen zur Disposition stellen, aber Verfahren fehlen, um unterschiedliche Sichtweisen zu integrieren2. Dass es sich dabei nicht nur um ein Kommunikationsproblem handelt, sondern dass es letztendlich um unbewusste Denkfallen und archetypische Handlungsmuster geht, die unter Umständen schlecht an den Komplexitätsgrad eines MIP angepasst sind, wird in den gegenwärtigen Curricula nicht thematisiert. Solange das so bleibt, werden MIP unter dem Motto „Wasch mir den Pelz aber mach‘ mich nicht nass“ durchgeführt, und die Zahlen im Chaos Report der Standish Group werden sich kaum zum Besseren entwickeln (s. Migrations- und Integrationsprojekte sind anders).

1Hans-Dieter Burkhard und Werner Rammert. Integration kooperationsfähiger Agenten in komplexen Organisationen. Technical University Technology Studies Working Papers. Institute for Social Sciences. Berlin 2000
2V. Lullies, H. Bollinger, F. Weltz. Konfliktfeld Informationstechnik – Innovation als Managementproblem. Campusverlag, Frankfurt a.M. 1990

Reisen Sie in jeder Jahreszeit in eine andere Region!

Kürzlich wurde mir eine wunderbare Aufgabe gestellt. Vier Personen wollen vierteljährlich eine Reise in eine von vier Regionen unternehmen. Jedes Jahr soll jede Region genau einmal besucht werden. Keine Region soll zweimal hintereinander und je in derselben Jahreszeit besucht werden. Abwechslungsweise sollen die vier Personen die Reisen organisieren. Keine Person soll zweimal hintereinander eine Reise organisieren müssen. Darüber hinaus soll jede Person eine Reise in eine Region und in einer Jahreszeit nur einmal organisieren müssen.

Es wird schnell klar, dass die Reiserei nach vier Jahren die Bedingungen erschöpft hat. Länger als vier Jahre lassen sich die Bedingungen nicht aufrecht erhalten. Trotzdem ist schon nur die Formulierung der Aufgabe ein Problem für sich. Zwar sollten die meisten Menschen rasch verstehen, was Sache ist, aber eine präzise Formulierung aller Bedingungen ist schwierig. Ich bin mir noch nicht sicher, ob obige Aufgabenstellung die Bedingungen vollständig enthält und die Aufgabenstellung eindeutig beschreibt. Erstaunlich, wenn man bedenkt, dass die Situation nur ein paar hundert Möglichkeiten offen lässt, dass es nur um dreimal vier Elemente geht und diese nur während vier Jahren gespielt werden. Für eine so einfache Situation bietet die Formulierung der Anforderungen bereits ein Problem.

Eine mathematische Aufgabe ist in jedem Fall ein Projekt. Zum Beispiel könnte sie am Anfang einer Dissertation stehen. Die Dissertation und damit die Lösung der Aufgabe ist das Projekt. Manchmal sprengt sie die Terminvorgaben. Es gibt Aufgaben, die erst nach Jahrhunderten gelöst werden. Die einfache Aufgabe, zu entscheiden, ob jede gerade Zahl (grösser als 2) die Summe zweier Primzahlen sei, ist seit 1742 immer noch ungelöst (auf die 1 Mio Dollar ausgesetzt ist). Wenn eine mathematische Aufgabe ein Projekt ist und in unserer (einfachen) Reise-Aufgabe die Formulierung der Anforderungen schon Schwierigkeiten macht, wieviel schwieriger ist es, die Anforderungen in einem wirklich komplexen Projekt zu formulieren?

Die Beschäftigung  mit der Problemstellung erhöht unser Wissen, auf was man achten muss, womit sie zu tun haben könnte, welche Zusammenhänge bestehen, usw. Z.B. wird einmal klar, dass wir es bei der Aufgabe mit einer binären Relation auf der Menge der Permutationen von vier Elementen zu tun haben. Es gibt 24 Permutationen von vier Elementen. Man kann sie als Deckbewegungen eines Teraeders interpretieren. Was hat die Reisetätigkeit zweier Paare mit einem Tetraeder zu tun? Es ist genau wie in einem Migrations- und Intergrationsprojekt: die Beschäftigung mit dem Projektgegenstand erhöht unser Wissen, worauf zu achten ist und welche Fragen wir stellen müssen. Es ist unmöglich, am Anfang eines Projekts die richtigen Fragen zu stellen, denn wir haben noch gar nicht das relevante Wissen dazu. In unserer Reiseaufgabe steht am Anfang natürlich die Frage nach den vier Jahresprogrammen. Wenn man sich etwas mit der Aufgabe beschäftigt kommt der Verdacht hoch, dass die Aufgabe nicht lösbar sei. Dann möchte man wissen, warum sie nicht lösbar ist und welches die Lösung ist, die die Bedingungen am wenigsten verletzt. Auch in Migrations- und Integrationsprojekten könnte sich herausstellen, dass die gewünschte Aufgabe nicht so zu erfüllen ist, wie man sich das ursprünglich vorgestellt hatte und auch dort geht es dann darum, die bestmögliche Lösung zu finden. Eine solche Einsicht verändert die Laufzeit des Projekts, stellt die Budget- und Terminvorgaben in Frage und kann zu Konflikten führen.

In unserer Reise-Aufgabe muss man nun die Fragestellung ändern. Aber wie formuliert man die neue Problemstellung? Man stellt z.B. irgend einmal fest, dass zwei Permutationen a und b dann miteinander in Relation stehen, wenn die zweite Stelle von a gleich der dritten Stelle von b ist, nämlich z.B. dann wenn im Sommer Region 3 besucht wurde. Man möchte jetzt wissen, wie viele Permutationspaare sich in einer gewissen Relationsklasse befinden und wie sich zwei Relationsklassen überschneiden. Aber wie formuliert man das? Was ist genau abzuklären? So können auch während eines Projekts Fragen auftauchen, die die Projektmitarbeiter, sowohl auf Kunden- als auch auf Lieferantenseite, nicht genau formulieren können. Man weiss nur, das es da irgend etwas abzuklären gilt. Aber was? So ist die Gefahr gross, dass man einfach mal los testet und prüft und schraubt, einfach in der Hoffnung, einmal auf eine Erkenntnis zu stossen, die genau das ist, wonach man gesucht hat. Das ist natürlich fatal, denn damit kann man viel Zeit verlieren.
Ich möchte damit sagen, dass unser Wissen mit der Projektarbeit zunimmt, und wir erst ab einer gewissen Menge an Wissen überhaupt sagen können, was wir eigentlich erwarten oder eben nicht erwarten. Zielformulierung, Wissen und Beschäftigung mit dem Gegenstand bedingen einander. Ohne dass wir uns eingehend mit dem Projektgegenstand beschäftigt haben, haben wir zu wenig Wissen, um die richtigen Fragen zu stellen und sagen zu können, was wir wollen.

Projekten in den Rachen geschaut

Eines der ersten Projektmodelle veröffentlichte Ed Roberts 19641. In den frühen achtziger Jahren ebnete das Modell von Pugh-Roberts2 den Weg zum berühmten Modell mit dem sogenannten Rework Cycle. Ausgehend von einem Bestand an unerledigter Arbeit, der entsprechend der vorhandenen Produktivität abgearbeitet wird, fliesst ein Teil der erreichten Resultate in einen Bestand an erledigter und abgeschlossener Tasks, während ein anderer Teil Fehler enthält und in einen Bestand undiscovered Rework fliesst. Das sind also solche Tasks, die unbrauchbar sind und später nachgearbeitet werden müssen. „Später“ ist dann, wenn das Projektteam die Fehler wahrgenommen hat. Dann existiert ein Bestand an unerledigter Rework, der neben der geplanten Arbeit zusätzlich gemacht werden muss. Das führt zu einer Verzögerung in der Projektabwicklung. Folgende moderne Darstellung des sogenannten Rework Cycle lieferte Cooper 19933:

Zum Vergrösseren klicken Sie auf die Figur, die aus dem Überblicksartikel von Lyneis und Ford stammt4. Nach diesem Modell flacht der Fortschritt während der Laufzeit des Projekts vorübergehend ab, bevor er wieder anwächst. Das führt zum bekannten 90 % Syndrom. Nähere Einzelheiten hat James Lyneis in einer aufschlussreichen Powerpointpräsentation festgehalten5. Der Rework Cycle ist eines der best untersuchten Phänomenen im Projektmanagement. Unglücklicherweise betreffen alle diese Untersuchungen vor allem Entwicklungsprojekte und nicht so sehr Migrations- und Integrationsprojekte. Für diese steht ein valides Modell noch aus. In Migrations- und Integrationsprojekte kommt neben dem Rework Cycle vor allem ein „New work Cycle“ in’s Spiel, der viel gravierender ist.

Quellen:

1Ed B. Roberts. The Dynamics of Research and Development. Harper and Row. New York 1964

2Richardson, George P. and Pugh III, Alexander L. Introduction to System Dynamics Modeling with Dynamo. MIT Press. Cambridge, MA 1981

3Kenneth G. Cooper (1993). The Iteration Cycle: Benchmarks for Project Managers. Project Management Journal. Vol. 24, No. 1 and
Kenneth G. Cooper (1993). The Iteration Cycle: How Projects are Missmanaged. Project Management Journal. Vol. 24, No. 1

4James M. Lyneis and David N. Ford. System dynamics applied to project management: a survey, assessment, and direction for future research. In System Dynamics Review, 23/2007, No. 2-3. S. 157-189.

5James M. Lyneis. Dynamics of Project Performance (2003). Powerpoint Presentation. Massachusetts Institute of Technology MIT

Jede Anwenderumgebung verhält sich anders

Migrations- und Integrationsprojekte (MIP) sind deshalb so schwierig, weil sie von lokalen Integratoren durchgeführt werden, die nur beschränkte Produkte- und Engineeringwissen haben können. Sie nehmen Produkte aus dem eigenen Konzern oder von Drittanbieteren und integrieren diese in den Umgebungen der Auftraggeber. Da die Produkte proprietär sind, kann der Integrator von den Produkteinternals nur beschränkt Kenntnisse haben. Damit fehlen ihm fast sämtliche Hebeln.

Wenn das Produkteverhalten nicht den Erwartungen entspricht, kann häufig nur der Hersteller sagen, ob es sich um einen Produktefehler oder um einen Installations- oder Bedienungsfehler handelt. Da aber die Experten beim Hersteller ebenfalls rar sind, kann das Projekt unter Umständen lange warten, bis schlüssige Informationen vorliegen. Der lokale Integrator ist jedoch der Geschäftspartner des Kunden, so dass sich dieser nicht interessiert, ob der Hersteller Zeit und Lust hat, das Projekt zu supporten. Nicht selten führt dieser Umstand zur völligen Erosion der Marge des Integrators.

Gibt es das nur in der IT? Auch im Bauwesen sind Integratoren am Werk. Ein Fensterlieferant oder ein Bauschlosser müssen Teilgewerke in einem Hauptgewerk intergrieren. Auch sie haben die Produkte vielleicht nicht selber gemacht, sondern von einem Lieferanten eingekauft und an die projektspezifischen Gegebenheiten angepasst. Dabei könnte es sich durchaus auch zeigen, dass die Produkte Mängel haben, die eine Integration an Hauptgewerk beinahe verunmöglichen. Aber ein grosser Unterschied besteht gegenüber der IT. Die Subsysteme im Bauwesen sind statisch, während sie in der IT ein Laufzeitverhalten aufweisen, das Unbestimmtheit über die eigentliche Installation hinaus mit sich bringt.
Neue Subsysteme verhalten sich fast immer instabil bei der Integration in spezielle Kundenumgebungen, auch wenn sie die Entwicklungstests (Factory Acceptance Tests) bestanden haben. Aber jede Kundenumgebung ist anders. Die Firma mValet hat 2007 eine Umfrage unter 10 der Fortune 500 IT-Anwendern durchgeführt, um tieferen Einblick in die versteckten Kosten von Migrationsprojekten zu erhalten.

Fazit:

Frequent inconsistencies and errors in so-called „environmental variables“ – applications that work in development experience difficulties when promoted into QA or other pre-production phases owing primarily to environmental differences (e.g., configuration settings of application infrastructure components being out of sync)1.

Die vielen Fehler und Instabilitäten, die während der Integration auftauchen, verlangen eine minutiöse Analyse und Reproduktion im Labor des Integrators. Er muss die Fehler genau dokumentieren, bevor er sie an den Hersteller oder ins Entwicklungscenter weiter geben kann. Ohne detaillierte Dokumentation des Fehlers, hören die Entwickler gar nicht erst zu. mValet schreibt dazu:

High change rates for applications in pre-production phases – these changes contribute to system instability and extended troubleshooting efforts which result in scheduling delays. Extensive analysis that wastes hours and days of IT staff time is required to diagnose and remediate the configuration setting differences that cause this issue1.

mValet errechnete, dass die Migrationsprojekte pro befragtem Unternehmen einen Anteil an den direkten Lohnkosten von zwischen 500 und 800 Tausend Dollars jährlich verschlingt. Eigentlich unverständlich, warum sich die Literatur vor allem auf Entwicklungsprojekte fokussiert, wo doch MIP viel mehr Unbestimmtheit aufweisen!

1mValet. Large Application Migration Projects Consume Significant and Consistent Hidden Costs. Business Wire 2007-12-12

Migrations- und Integrationsprojekte sind anders

Der Standish Chaos Report erscheint seit 1994 alle zwei Jahre. Er beruht auf einer Umfrage unter mehr als 300 amerikanischen Entwicklungsunternehmen und untersucht über 8000 Projekte. Aus der Reihe der bisher erschienenen Reports geht hervor, dass der Anteil erfolgreicher Projekte bei ungefähr 28% konstant blieb, während der Anteil derjenigen Projekte, bei denen der Kosten- oder Zeitrahmen beträchtlich gesprengt wurde, zu Lasten der abgebrochenen Projekte konstant angewachsen ist. Aber es handelt sich ausschliesslich um Softwareentwicklungsprojekte. Als Grund, dass immer weniger Projekte abgebrochen werden, wird die Anwendung formaler Methoden angegeben1. Aber trotz dieser formalen Methoden – was immer das für welche sind – schiessen doch um 70% aller betrachteten Projekte an den Zielen vorbei. Als wichtiger Grund für das Scheitern von Entwicklungsprojekten ist die ungenügende Benutzereinbindung genannt. Wie soll denn das geschehen? Wie soll z. B. Microsoft die hunderten von Millionen Benutzer einbeziehen, die auf der ganzen Welt verstreut sind und in verschiedenen Kulturkreisen leben? Erhöhte Komplexität aufgrund der Globalisierung lässt grüssen. Microsoft kann nicht einmal ein signifikantes Sample von Benutzern begrüssen, das ist schlicht unmöglich. Selbstverständlich gehört eine tiefgehende Marktuntersuchung allem voran, aber von einer Benutzereinbindung kann keine Rede sein. Oder wie soll ein Hersteller von Telekommunikations- oder Bankenlösungen die Benutzer einbeziehen? Benutzer sind nämlich nicht die Betreiber, die die Lösungen kaufen und bezahlen, sondern deren ihre Kunden, also die vielen Millionen Endkunden, die telefonieren oder via E-Banking ihre Zahlungen machen.

Interessanterweise werden in der Literatur fast ausschliesslich Softwareentwicklungen untersucht, wenn es um IT-Projekte geht. Andere IT-Projekte werden eher stiefmütterlich behandelt. Dabei sollten doch auf ein Entwicklungsprojekt mehrere Dutzend Migrations- und Integrationsprojekte (MIP) folgen, denn schliesslich möchte man ja auch ausrollen, was man einmal mühsam entwickelt hat. Warum denn MIP in der Literatur ein derart steifmütterliches Dasein fristen, kann ich nicht verstehen. Es ist zu befürchten, dass sich die Zertifizierer, wie PMI und IPMA, und auch andere Herausgeber formaler Projektmanagementmethoden, an den Gegebenheiten von Entwicklungsprojekten orientieren. Aber die viel zahlreicheren MIP gehorchen anderen Gesetzen. Der mangelnde Einbezug des Kunden ist da z. B. kein Thema. Vielmehr laufen MIP die Gefahr, dass der Anwender den Hersteller zu wenig einbezieht. Es besteht momentan ein Trend weg vom Projektleiter des Herstellers. Die Anwender denken, dass es reicht, wenn sie den Projektleiter stellen. Aber wie man sich denken kann, funktioniert das nie, denn wer sorgt z.B. dafür, dass dem Projekt genügend Expertise seitens Hersteller-Entwicklungscenter zukommt? Sicher nicht der Projektleiter des Kunden, der aus der Sicht des Entwicklungscenters irgendwo auf der Welt in einem unbedeutenden Land sitzt. Sie erinnern sich ja an den Beitrag Staus im Projektmanagement vom 25. Juli 2008. Natürlich sind das Angelegenheiten, für die sich der Kunde nicht interessiert, und natürlich ist es verständlich, wenn er in der Offerte keinen entsprechenden Posten sehen will. Aber der Projektleiter des Lieferanten ist am Abend auch hungrig und kann die Arbeit nicht für Gottes Lohn machen. Hier entwickelt sich gerade eine neue Mode, die zur Komplexität beiträgt. Die Kräfte, welche die Randbedingungen liefern sind:
• Preisstandards für die Services, die mit dem System angeboten werden sollen
• Globalisierte Herstellerorganisationen vs. national operierende Betreiber
• Zunehmende Spezialisierung der Systeme für immer mehr konvergierende Applikationen
Die Players sind die Hersteller und ihre Subcontractors, die Betreiber entlang einer mehrstufigen Supply Chain sowie Millionen von Endbenutzern. Alle diese Players richten sich im herrschenden Kräftefeld so aus, dass sie das kleinste Leid haben, so wie sich ein Windzeiger in den Wind stellt, damit er der Windkraft am wenigsten ausgesetzt ist. Das führt möglicherweise zu einer Mode, die die Players „versklavt“, so dass sie schlussendlich ihre Ausrichtung nicht mehr selber wählen können. Was die Begriffe Mode und versklaven anbelangt erinnern Sie sich gewiss an den Beitrag Was ist komplex am Bierspiel vom 21. Juli 2008.

1 Wiki Softwaretechnik, Artikel Chaos-Report

Investieren Sie in Expertenwissen!

Ich möchte nochmals auf die gestrige Geschichte zurück kommen, weil sie in Projekten wichtig ist. Es handelt sich nämlich auch wieder um so eine Mode, die alle Beteiligten – sehr zu ihrem Nachteil – gemeinsam generieren. Jeder meint, der andere sei schuld, aber tatsächlich hat jeder zu gleichen Teilen Schuld an der Misere. Es ist wie im Bierspiel, wo alle dem jeweils anderen oder externen Faktoren die Schuld geben. Hier meint der Kunde, der Lieferant schlampe, ist aber nicht bereit, mehr zu bezahlen. Das Projektmanagement des Herstellers nervt sich über den lausigen Support des Competence Centers (Entwicklung und/oder Produktemanagement), ist aber nicht bereit, das Projekt zu stoppen, wenn nicht mehr Expertenwissen zur Verfügung steht. Das Competence Center klagt darüber, dass das Management zuwenig Ressourcen bereit stellt, ist aber nicht bereit, den Support von zusätzlichen Projekten abzusagen. Das Management schliesslich schimpft auf die Projektleitung, die das Projekt dermassen schlecht abwickelt, dass die Kunden Penaltyforderungen stellen oder gar davon laufen, ist aber nicht bereit, in zusätzliche Ressourcen zu investieren.

Diese Situation wird klarer, wenn wir sie in einem Diagramm darstellen. Sie können das Diagramm vergrössern, indem Sie darauf klicken.

Starten Sie im Kreis B1 bei der Anzahl Migrations- und Integrationsprojekten, die ein Konzern weltweit durchführt. Je mehr das sind, desto mehr kommt der Produktmanager unter Druck, desto weniger Wissen ist also in den einzelnen Projekten verfügbar. Das Projekt kommt in’s Stocken, weil die offenen Fragen nicht schnell genug beantwortet werden können. Der Kunde ist unzufrieden. Die Marktnachfrage nach Produkten dieses Konzerns sinkt, die Anzahl Projekte geht zurück (und damit auch der Erfolg dieses Konzerns). Hier treffen wir wieder eine alte Bekannte, nämlich die Verzögerung. Zwischen der Unzufriedenheit einzelner Kunden und dem Rückgang des Erfolgs ist eine grosse zeitliche Lücke. Wenn das Management den kriechenden Geschäftsgang jedoch wahrnimmt, ist es meistens schon zu spät, um Gegenmassnahmen zu treffen.

Gehen Sie jetzt in den Kreis B2: Jeder Kunde hat eine gewisse Schwelle, ab der er ernstlich böse wird. Dann muss der Hersteller Penalties bezahlen. Spätestens dann stellt das Management fest, dass eigentlich in zusätzliche Expertise investiert werden müsste. Tut es dies dann auch, dann kann das verfügbare Wissen erhöht werden und die Projekte laufen weit erfolgreicher ab. Das Erreichen der angestrebten Expertenkapazität verzögert sich wieder einmal beträchtlich gegenüber dem Zeitpunkt der Investition. Das ist der Grund, weshalb solche Managementinterventionen meist zu spät greifen. Das Management übersieht die eingebauten Verzögerungen.

Der Kreis R1 generiert einfach neue Projekte. Indem der Konzern interessante Produkte anbietet, kann er sie in Migrations- und Integrationsprojekten ausrollen. Je mehr er das tut, desto bekannter werden die Produkte und desto grösser die Nachfrage in Form von RFQs.

Dieses Muster heisst Growth and Underinvestment. Peter Senge hat es 1990 in seinem Buch Die Fünfte Disziplin zusammen mit neun anderen sogenannten Archetypen beschrieben1.
In Growth and Underinvestment nimmt die Variable, an derer Stelle die Anzahl Migrations- und Integrationsprojekte steht, zunächst zu, flacht dann ab und kollabiert danach mehr oder weniger schnell. Dieses Schicksal ereilt jeden Bestand, der anfangs erfreulich wächst, wenn nicht ganz von Anfang an und dann immer parallel zum Wachstum in Kapazitäten investiert wird. Das ist der einzige Hebel, den Sie in diesen Zusammenhängen in der Hand haben. Nutzen Sie ihn!

1Peter Senge. Die Fünfte Disziplin – Kunst und Praxis der lebenden Organisation. Klett-Cotta. Stuttgart 1997