Es gibt klassische Verhaltensmuster in IT-Projekten, die fast überall gelebt und gepflegt werden. Einige dieser Verhaltensmuster sind definitiv erfolgsverhindernd und drohen, Projekte in die Katastrophe zu kippen.
Als Teammitglied weiss man oft nicht, ob man lieber Lachen oder Weinen soll, wenn einem diese Verhaltensmuster wieder begegnen.
Chris Rupp präsentiert die wichtigsten dieser Muster, die Auswirkungen und die Ausstiegsszenarien.
Vortrag von Chris Rupp, Sophist GmbH, am Swiss Requirements Day 2012.
Projekte sind meist ein gruppendynamisches Happening. Mit allen Vor- und Nachteilen…
Was sind typische Verhaltensmuster?
- Totentwickeln eines Systems
- Reportismus oder Managerismus
- Von komplizierten und komplexen Sachverhalten
- Blitzverblödung
Verhaltensmuster sind wiederkehrende Verhaltensweisen: Begegnet wir Menschen zum ersten Mal, so wissen wir wie wir die Hand schütteln, uns vorstellen, etc. Erst danach müssen wir unser weiteres Verhalten evaluieren. Wir beginnen also mit einem Mikromuster, das hilft schon mal, und sehen dann weiter.
1. Totentwickeln eines Systems
Dieses Phänomen tritt meist eher in grösseren Unternehmen auf. Grosse Projekte starten oft mit einer grossen Vision, visualisierbar mit einem grossen starken Pferd. Nach einem Jahr Projektarbeit ist das Pferd zum Klepper mutiert und nach noch einem Jahr wissen eigentlich alle Projektteilnehmer, dass der Gaul tot ist, sprich das Projekt wird kein Erfolg.
Oft meinen die Projektteilnehmer, sie seien kurz vor dem Ziel. Deshalb wird das tote Pferd über die vermeintliche Ziellinie gezogen.
Reportismus oder Managerismus
Dieses Phänomen tritt auf, wenn man ein vermeintlich einfaches Projekt startet und nach und nach weitere Requirements dazukommen. Man verwendet dann viel Zeit für das Verwalten der Change-Requests und zusätzlichen Anforderungen, statt das ursprüngliche Projekt zu stemmen.
Ringsherum wird immer mehr Verwaltungs-Overhead aufgebaut und man wundert sich, dass am Ende des Releases so wenig herauskommt. Im Setup von Auftraggeber und Auftragnehmer kommt dies besonders häufig vor.
Von komplizierten und komplexen Sachverhalten
Gewachsene Systeme weisen oft eine sehr hohe Komplexität auf, die niemand mehr beherrscht. Man versucht dann die Ablösung durch ein einfacheres, neues System. Befragt man dann aber die verschiedenen Fachbereiche, so ist das neue System nicht wirklich einfacher.
Blitzverblödung
Hat man sich in Meetings auf gewisse Punkte geeinigt, so geschieht es oft, dass kurz darauf dasselbe Thema wieder neu diskutiert wird. Die Teilnehmer scheinen plötzlich alle Abmachungen vergessen zu haben, man dreht sich im Kreis, die Frustrationen nehmen bei allen Beteiligten zu.
Lösungsansätze
Man sollte sich zuerst die Symptome ansehen: Weshalb tun die Leute dies und das? Hat man die darunterliegenden Gründe identifiziert, kann man allfällige Lösungen evaluieren.
Benennt man ein Verhaltensmuster, so bricht das Schweigen und die Leute werden konstruktiv.
Projekte werden totentwickelt, wenn es keine Zieldokumente gibt. Wird das Ziel oft geändert, so ist das für ein Projekt tödlich. Diskutiert man nicht über das Ende eines Projektes, wird es schnell emotional und man spricht über alles andere als über das Projekt. In der Schlussphase sollte man nicht mehr fragen, «wer eigentlich der Kunde sei».
Die Gründe liegen oft im Entstehungsprozess eines Projektes: Wer hat es initiiert, wessen Projekt ist es? Diese Person wird sich wehren und dessen Vasallen auch. Hier geht es oft um die Sicherung eines Jobs.
Man bleibt als Mitarbeiter lieber in toten Projekten, als in ein potentiell noch schlimmeres Projekt zu kommen…
Auch das Augen-zu-und-durch-Prinzip wird oft angewendet. Man glaubt gar nicht mehr an erfolgreiche Projekte.
Externe Audits können einen Ausweg aus der Situation bieten. Man muss der verantwortlichen Person die Möglichkeit geben, den Kopf aus der Schlinge zu ziehen.
Eine präzise Kosten-Nutzen-Analyse hilft, die nächsten Schritte zu evaluieren und künftige Reissleinen aufzubauen: Bei welchen Szenarien wird ein Projekt abgebrochen?
Die Ziele sollten von Beginn weg gut abgegrenzt werden!
Lösen von Reportismus
Statusmeetings können zeitlich ein so hohes Mass annehmen, dass man keine Zeit mehr hat für inhaltliche Arbeiten. Projektmanagement fordert oft eine umfassende Dokumentation, um Standards zu erfüllen und vermeintlich um Fehler zu verhindern. Ineffiziente Prozessvorgaben sollten getailored werden. Tut man dies zu stark und das Projekt läuft schief, so riskiert man den eigenen Kopf. Tut man es nicht, riskiert man einen tödlichen Overhead. Hier sollte man also mutig sein und den Overhead auf das spezifische Projekt anpassen.
Unerfahrenen Projektleitern sollte man erfahrene Coaches zur Seite stellen. Der Ressourcenaufwand für die Dokumentation sollte vorgängig bestimmt werden, denn es kostet Zeit und damit Geld. Der Sponsor muss Dokumentation also wollen.
Persönliche Gespräche bauen Vertrauen auf und sollten einer umfasenden Dokumentation vorgezogen werden. Ein klares Priorisierungssystem hilft, die richtigen Features umzusetzen und die Komplexität zu limitieren. Die «kleinen Ausnahmen» sind wegzulassen.
(Zu) Komplizierte oder komplexe Projekte
Man sollte klar festlegen, welche Anforderungen die Software erfüllen sollte.
Die «kleinen» Ausnahmen sind zu minimieren, sie können den Aufwand unproportional aufblähen.
Man hat die Wahl: Entweder man bricht radikal mit dem Vorgängersystem, oder man integriert es bewusst in das neue System.
Blitzverblödung
Die Gründe umfassen Widerstand gegen das Projekt, unklare Verantwortlichkeit, übertriebene Matrixorganisation,
Die Lösung liegt im Aufdecken des Verhaltens. Hier hilft Zuckerbrot und Peitsche. ein Stakeholdervertrag (willst Du dabei sein?), schriftliches Vorgehensmodell. Auch sollte man eine Ãœberlastung des Personals auflösen.
Liveblog: Verhaltensmuster in der IT-Systementwicklung http://t.co/f9QFeUgI #srd12 #requirements #software #projekt
— Walter Schärer (@WalterSchaerer) June 20, 2012
