Ein erfundenes Beispiel (Ähnlichkeiten mit realen Projekten sind rein zufällig...):Ein neues Projekt soll ins Leben gerufen werden. Dazu wird von der Geschäftsführung ein Projektteam bestimmt (Auswahl ressourcenbasiert, d.h.: wer ist gerade frei und hat die nominelle Qualifikation) sowie ein Projektleiter eingesetzt. Teammitglied A hatte schon früher mit Teammitglied B zu tun und hat die Erfahrung gemacht, dass dieser gerne fremde Ideen zu seinem Nutzen vereinnahmt. Er hält sich mit Äußerungen in Gegenwart von B stets zurück und meidet den Gedankenaustausch mit diesem. Das Projekt jedoch erfordert eine stetige Abstimmung zwischen beiden. Der Projektleiter ist für alle Teammitglieder ein unbeschriebenes Blatt. Man weiß, er hat bisher in anderen Teams mitgewirkt und bekommt nun die erste Projektleitung. Der Projektleiter will seine Fähigkeiten und Autorität gleich von Anfang an außer Zweifel wissen und erarbeitet gleich vor dem ersten Zusammentreffen sein Konzept, das er den Projektmitgliedern im Kick-off-Meeting vorgibt. Die Mitarbeiter fühlen sich übergangen und sehen zudem einige praktische Schwierigkeiten aus ihrer Erfahrung, die der Projektleiter aber gleich abwiegelt. Die Mitarbeiter haben sich das Urteil gebildet, dass der neue PL nicht zuhört und wenig Ahnung von der Praxis hat. Dadurch entsteht ein Kommunikationsloch zwischen PL und Teammitgliedern. Da sich die Teammitglieder C, D und E nicht kennen und im Kick-Off-Meeting kein besonderer Kontakt ergab, haben sie am Anfang des Projektes Berührungsängste und kommunizieren nur das Nötigste. Das Projekt und die Arbeit startet, es tauchen erst mal keine Probleme auf. Alles scheint plangemäß zu laufen. Einige Wochen später werden die Ergebnisse der Arbeit aller Teammitglieder zusammengebracht (z.B. Alpha-Version einer Software wird kompiliert und getestet). Dabei zeigt sich, dass die Einzelmodule nicht zusammenpassen, da von teilweise verschiedenen Schnittstellen ausgegangen worden ist. Der Projektleiter ist verärgert und verpflichtet die Mitarbeiter die Schnittstellen im kleinen Kreis abzugleichen. Mit 2 Wochen Verzögerung gelingt es nun, eine lauffähige Alpha-Version der Software anzufertigen. Die Tests zeigen nach und nach aber die konzeptionellen Mängel, die manche Teammitglieder schon beim Kick-Off vorausgesehen haben. Nach tagelangem hin- und her, in dem kaum eine verwertbare Arbeit geleistet wird, wird das Konzept schließlich verändert – mit einem Mehraufwand von 3 Wochen. Der Projektleiter erkennt, dass das Projekt bereits 5 Wochen im Verzug ist und schafft es, innerhalb 1 Woche, einen zusätzlichen Programmierer aus einem anderen Projekt abzuziehen. Dieser wird dem Programmierer zugeordnet, der den meisten Änderungsaufwand zu bewältigen hat. Leider muss dieser das neue Teammitglied zunächst einmal einweisen, bevor er effektiv etwas beitragen kann, was in Summe ca. 2 Wochen seiner Zeit kostet. Das neue Teammitglied schüttelt den Kopf über die bisherigen Fehlleistungen und äußert sich negativ über die Arbeit und den Projektleiter. Es bilden sich 2 Gruppen: Die, die sich durch die Kritik angegriffen fühlen und das neue Teammitglied auflaufen lassen, wenn sich eine Gelegenheit ergibt und die, die sich gegen den Projektleiter verbünden. Dieser Mobbingprozess beansprucht ca. 5% der Arbeitszeit. Der Projektleiter hat das Gefühl, dass das Projekt immer noch stark in Verzug ist und fordert jeden dazu auf, einen Statusbericht abzugeben. Der angegebene Status in % entspricht dem der Planung, da die Programmierer sich nicht selbst schlecht darstellen wollen und meinen, den Rückstand „schon irgendwie aufholen“ zu können, ohne dass es einer merkt. Nur Teammitglied D liegt mit seiner Angabe 3 Wochen hinter dem Plan. Dieser bekommt eine Standpauke vom Projektleiter und wird zur Leistung von Überstunden aufgefordert. Er findet zudem Erwähnung im Bericht des PL an die Geschäftsführung. Die Teammitglieder fühlen sich darin bestätigt, einen plangerechten Status abgegeben zu haben. Es etabliert sich ein System, in dem jeder eine heile Welt vorspielt. Deshalb wagt auch niemand, auftauchende Probleme mit den Anderen zu besprechen – er könnte ja enttarnt werden. Mitglied D wird gemieden, ist frustriert und vollzieht eine innere Kündigung. Als der Termin kommt, an dem die fertige Software verlinkt und getestet werden soll, gibt es erneut Probleme mit den Modul-Schnittstellen. Nach 1 Woche hat man dann das fertige Programm – das die meisten Mängel aufzeigt. Der PL erfährt vom Test-Team, dass die Software nur 70% der Funktionen enthält und sehr unzuverlässig läuft. Er konfrontiert die Teammitglieder damit und verweist auf die Statusberichte. Das Team bekommt eine Zurechtweisung von Seiten der Geschäftsführung, als der PL eine Terminverzögerung von 6 Wochen meldet. Der PL ordnet Überstunden an und überwacht z. Tl. persönlich die Arbeit der Mitarbeiter. Diese bemühen sich, die Zeit wieder aufzuholen aber machen dabei mehr Fehler. Teammitglied D läuft das Fass über und wechselt zu einem Konkurrenzunternehmen. Das „neue“ Teammitglied muss seine Arbeit übernehmen. Als er jedoch den Programmcode analysiert erkennt er, dass der frustrierte D kaum nachvollziehbare Strukturen generiert hat und braucht sehr lange, bis er Veränderungen an diesem Modul vornehmen kann. Teammitglied B, der nebenbei für Backups und Datensicherheit zuständig ist, vernachlässigt diesen teil der Tätigkeit, weil er seiner Programmierarbeit nachkommen muss. Ein anderes Teammitglied überschreibt versehentlich Teile des Projektverzeichnisses. Das letzte Backup ist 1½ Wochen alt. Nachdem es eingespielt ist, dauert es 2 Wochen, bis jedem klar ist, welche Version womit verbunden ist, was im Vergleich fehlt und die Differenzarbeit geleistet ist. Inzwischen gerät der Projektleiter in Panik und muss der Geschäftsleitung einen geschätzten Terminverzug von 9 Wochen + Extrakosten von ca. 70 Mannwochen vermelden. Die Geschäftsführung entbindet den PL von seiner Aufgabe, es nimmt sich ein neuer Projektleiter aus dem Kreis der Geschäftsführung dem Projekt an. Die Mitarbeiter haben Angst um ihre Arbeitsstelle und versuchen alle Schuld dem gegangenen Projektleiter in die Schuhe zu schieben. Dafür geht natürlich auch wieder Zeit verloren. Das Team braucht außerdem ein paar Tage, bis nach dem Weggang der bisherigen Leitfigur die Projekt-Struktur wiederhergestellt ist. Schließlich wird die Software mit einer Verzögerung von 11 Wochen (Einnahmeverlust von 30% über die Lebensdauer der Software) und einem Mehraufwand von 90 Mannwochen auf den Markt gebracht. Durch den Zeitdruck hat man bei Tests und Fehlerbehebung gespart sowie ein Auge zugedrückt. Die Software ist sehr fehlerbehaftet und verursacht um 50% höhere Supportkosten als geplant. Die Supportkosten machen heute bis zu 80% der Softwarekosten aus. Die Folgeversion des Programms braucht erhebliche Ressourcen, da der Sourcecode durch die unstrukturierte Vorgehensweise sehr chaotisch und „quick and dirty“ programmiert wurde. An eine Wiederverwendbarkeit der Routinen in anderen Projekten ist nicht zu denken. Die Firma gerät in Liquiditätsprobleme, muss Zukunftsprojekte einstellen und die beteiligten Mitarbeiter ausstellen. Dadurch sinkt nach und nach der Profit, da immer mehr alternden Produkte im Portfolio stehen. ... Der Geschäftsleiter fragt sich, was die Ursache für den Konkurs dieser Firma war. Christoph Mayer, www.evult.de |
