Systemtheorie – bei der ersten Begegnung hielt ich das ganze für akademisches Gesülze ohne praktischen Mehrwert. War ich naiv. Ein Haufen Projekte später und mit einem etwas mehr gefüllten Erfahrungsrucksack begegnete mir die Systemtheorie erneut. Im Buch die fünfte Disziplin erklärt Peter M. Senge, wie Systemarchetypen soziales Verhalten beeinflussen. Die Wirkung auf den Projekterfolg ist enorm.

Bis jetzt schauten wir vorwiegend darauf, wie Menschen in Projekten miteinander kommunizieren. Was passiert, wenn Alphatiere sich ins Gehege kommen. Warum wir nicht mehr, sondern besser kommunizieren sollten und das sich im Krisenfall mehr Kommunikation doch lohnt. In der zweiten Hälfte unserer kurzen Serie zum Projektmanagement möchte ich die Perspektive erweitern und das Ganze mehr aus der „Lego-Perspektive“ ansehen. Also, wie Projektteams zusammengebaut werden und wie sie miteinander funktionieren und was für Auswirkungen einzelne Aktionen haben. Immer noch mit dem Fokus, nicht das wie oder das was ist entscheidend, sondern das wer.

Systemarchetypen und Fehlerbehebung

Im Buch die fünfte Disziplin werden 10 häufig beobachtete Verhaltensmuster von Menschen beschrieben. Eines davon „ist die scheiternde Korrektur“. Dabei wird eine kurzfristige Scheinlösung für ein Problem gemacht, die unerwartete Konsequenzen hat. An dieser Stelle unterstehe ich mich, eine Anspielung auf die Minarettinitiative zu machen, sondern bleibe bei einem klassischen Internetprojekt.

Nehmen wir als Beispiel einen neu programmierten Onlineshop. Bei jeder Bestellung erhält der Endkunde ein Bestätigungsmail und der Onlinehändler ein Verwaltungsmail mit Direktlink zur Bestellung. Nach vier Wochen ruft der Onlinehändler an und moniert, die Endkunden bekommen alle Bestätigungsmails, ihm fehlen von 20 Bestellungen aber zwei Mails mit Direktlink in die Verwaltung. Wie reagiert der Entwickler? Vielleicht ist er unter Zeitdruck und muss dringend an einem anderen Projekt etwas fertig stellen. Die schnellste Lösung, er sendet bei jeder Bestellung das Bestätigungsmail nicht nur an den Kunden, sondern per BCC auch an den Onlinehändler. Damit hat er das Problem „gelöst“.

Dumm ist nur, er hat das Problem nicht gelöst. Er hat einen Verband um einen potenziellen Beinbruch gewickelt. Schnellen nämlich die Bestellungen beim Onlinehändler hoch und redet er nicht mehr von 20 Bestellungen im Monat, sondern von 20 Bestellungen im Tag, will der Onlinehändler eine richtige Lösung. Er verliert nämlich das Vertrauen in das System, weil Mittlerweilen auch Kundenmails verloren gehen. Das Mail-Problem liegt tiefer. Weil der Onlineschop in der Zwischenzeit weiter entwickelt wurde, ist die Lösung nun aufwendiger, als wenn der Programmierer beim ersten Anruf das Problem richtig gelöst hätte. Also muss er eine Nachtschicht einschieben, die er nicht verrechnen kann und ein anderes Projekt bleibt liegen…

Was lernen wir daraus?

Wer in die „Scheiternde Korrektur“ Falle tritt, hat nur eine einzige Möglichkeit. Er muss sein Lösungsmuster radikal ändern und in Zukunft gründliche Fehlersuche betreiben. Unsere hauseigene Software DEMANDIT, mit der wir sämtliche Kundenprojekte der letzten 5 Jahre umsetzten, hat knapp 600‘000 Zeilen Code. Zum Vergleich Joomla hat einen Core-Code von knapp 300’000 Zeilen. Wer in dieser Grössenordnung Software erstellt, muss schnell lernen, an welchen Stellen Flickwerk später teuer bezahlt wird. Warum? Weil ein Systemfehler ohne Weiteres vier Mannwochen verschlingt. Das fällt auf. Und so haben unsere Entwickler eine gute Nase entwickelt, bei welchen Fehlern sie in die Tiefe des Codes absteigen müssen und ich unterstehe mich, ihnen in diesen Fällen Termine zu setzten. Im Gegenteil, es ist meine Aufgabe dafür zu sorgen, dass sie genügend Zeit erhalten, „Grundprobleme“ auch grundsätzlich zu lösen.

Die 10 Systemarchetypen helfen zu verstehen, welches Verhalten zur Gefahr für jedes Projekt wird. Eine gute Einführung bietet die fünfte Disziplin. Spass zum Lesen macht auch die Logik des Misslingens – damit Ihr nächstes Projekt gelingt ;-)

Teil 1: Der Kunde ist König und warum Projekte scheitern
Teil 2: Alphatiere bringen noch jedes Projekt zu Fall
Teil 3: Frauen im Projekt – warum nicht?
Teil 4: Projektanfänger: Wir müssen mehr kommunizieren
Teil 5: Wann Sie im Projekt (doch) besser mehr Kommunizieren

yigg this! — save to del.icio.us