Projektmanagement scheitert am Faktor Mensch

Knapp 80 Prozent aller Projekte überschreiten die festgelegte Projektdauer um mehrere Monate. Zu dieser Erkenntnis kommt eine Untersuchung des Marktforschungsinstituts IDC, das die deutschen Top500-Unternehmen nach ihren Aktivitäten im Bereich Portale fragte. Als Hauptproblem nennen die Befragten nicht etwa DV-Probleme wie heterogene Landschaften oder das Deployment, sondern das Projekt-Management.
“Im eigenen Unternehmen habe ich es erlebt”, erzählte kürzlich Martha Bennett kopfschüttelnd, Chef-Analystin der Giga Information Group. Es ging um die elektronische Kommunikation zwischen zwei Fachabteilungen – genauer: Um ein Kabel, vielleicht fünf Meter lang, das jedoch durch eine Wand zwei Abteilungen mit zwei Chefs verbinden sollte. Es gab endlose, technische und organisatorische Details zu klären. Doch die Leitung ist nie verlegt worden. Der Grund: Die beiden Bereichsverantwortlichen vertrugen sich nicht und wollten schlichtweg keine Verbindung.

Tom DeMarco ist in der IT-Szene vermutlich der bekannteste Autor, der mit solchen Fällen viele Bücher gefüllt hat. Ausgerechnet auf einer Konferenz über Software-Qualität erläuterte DeMarco einmal, dass Pflichtenhefte in der Regel minutiös sämtliche Drucker und Workstations auflisteten. Doch verschleierten solch dicke Anforderungskataloge oft nur, dass nur jeder Fachbereichsleiter über dasselbe Statussymbol verfügen will wie der aus der Nachbarabteilung.

Deshalb sei es Zeit, das Projekt-Management den tatsächlichen Bedürfnissen anzupassen. Das fordern unter anderem Buchautor und OOSE-Geschäftsführer Bernd Oestereich, sowie die Berater und Projektleiter Jutta Eckstein und Nicolai Josuttis. Denn auch ausgefeilte Vorgangsmethoden vom Wasserfallmodell bis zu iterativen heuristischen Verfahren verschleiern nur, dass sie den Faktor Mensch vergessen oder unterbewerten.

<b>Positives aus der Entwickleranarchie</b>

Josuttis und Eckstein haben bereits in kleinen Projekten gute Erfahrungen mit sogenannten Agilen Prozessen gemacht und übertragen die Prinzipien nun auf große Vorhaben. Hier sind zum Teil mehr als 100 Entwickler, Berater, Software-Ingenieure, -Designer, -Tester und -Architekten beteiligt. Denn das Agilitätsmanifest schreibt einige Werte fest, die sonstige Verfahren vermissen lassen.

Zum Beispiel rangieren Individuen und die Interaktion höher als Prozesse und Tools. Auch Software, die funktioniert, wird höher bewertet als verständliche Dokumentationen. Die Zusammenarbeit mit dem Kunden bedeutet mehr als Verträge und die zügige Reaktion auf erkannte Notwendigkeiten zur Änderung des Produkts mehr, als einen Plan umzusetzen.

Zur Verdeutlichung, hier noch einige Punkte aus dem sogenannten Manifest:
– Software muss frühzeitig und zwar ausführbar und in einem steten Fluss ausgeliefert werden.
– Änderungen sind willkommen.
– Geschäftsleute (Kunden) und Entwickler arbeiten eng zusammen.
– Vertraue motivierten Mitarbeitern!
– Konversation findet von Angesicht zu Angesicht statt.
– Der Fortschritt des Prozesses wird an der Software gemessen, die funktioniert.
– Das Entwicklungstempo ist gleichmäßig.
– Es zählen technisch hervorragende Leistungen und gutes Design.
– Die Hauptsache ist Einfachheit.
– Die Teams organisieren sich selbst.
– Das Team reflektiert den Projektstatus und berichtigt seine Fehler.

<b>Abkehr von der reinen Lehre</b>

Dabei allerdings wird sofort erkennbar, dass einige Forderungen für die Übertragung auf Großprojekte erheblich modifiziert werden müssen. Zu Beispiel dürfte die Face-to-Face-Kommunikation in großen Projekten für nur wenige Teammitglieder machbar sein. So haben Eckstein und Josuttis festgestellt, dass es gut ist, verschiedene Kommunikationsmedien und -wege zu nutzen und vor allem das Hauptmedium nach einer Weile zu wechseln. Wenn E-Mails den Arbeitsplatz überfluten, ist ein unbesehenes Wegklicken die Folge. Ähnliche Abnutzungserscheinungen gibt es auch bei anderen Kommunikationskanälen.

Außerdem empfehlen die beiden, die auch als Autoren aktiv sind, Kommunikationsbeauftragte zu ernennen. Deren Aufgabe ist es, die verschiedenen Projektteams über den jeweiligen Status Quo zu unterrichten. Gruppen, in denen sich die Mitglieder nicht verstehen, blockieren den Projektfortschritt. Diese sind aufzulösen beziehungsweise umzuformen.

<b>Kleine und kleinste Projekteinheiten</b>

Für einen möglichst gleichmäßigen Projektfortschritt können vergleichsweise kurze Entwicklungs-Zyklen sorgen. Eckstein und Josuttis bringen ihre Erfahrungen auf die Formel: Je größer das Team, desto kürzer sollten die Zyklen sein: Iterationen wöchentlich und interne Releases monatlich. Releases, die nach draußen gehen, finden am besten alle drei Monate statt.

Auch Oestereich kann auf profunde Erfahrungen im iterativen Vorgehen verweisen. Unter Iteration versteht er mehrfach vorkommende Abschnitte eines IT-Projekts. Seine Vorschläge planen zum Beispiel Puffer in die Arbeitsaufträge für jede Iteration ein. In herkömmlichen Verfahren, etwa im Phasenmodell des Unified Process, wird der Aufwand für das Gesamtprojekt geschätzt und dann ein Puffer von vielleicht 30 Prozent eingeplant. Bei der Aufteilung in viele Teilschritte gelten dagegen die Ziele immer bestens erreicht, wenn 70 Prozent des Plans erfüllt werden.

Das mag manchem einfach als rein psychologischer Dreh erscheinen. Oestereich aber kann mittlerweile aus fünf Jahren nachweisen, dass nur zum Teil fertige Arbeitsaufträge im Schnitt zwei Drittel ihres Plansolls erreichen. Auch der Verfahrensguru macht die Iterationsdauer von der Teamgröße abhängig. Bei nur vier Mitarbeitern geht er von zweiwöchentlichen Zyklen aus. Übersteigt die Anzahl der Teammitglieder die Zahl 40, liegt die Obergrenze bei sechs bis zehn Wochen.

Die Selbstorganisation der Teilteams dürfte für viele Projektleiter unheimlich sein. Die Selbsteinschätzung der Gruppen ist Bestandteil der Selbstorganisation. Die Mitarbeiter müssen bekannt geben, was sie bis zu welchem Zeitpunkt geschafft haben wollen und können. Laut Oestereich liegt die Schätzfehlerrate bei nur drei Prozent. Dabei hebt sich der Anteil derer, die sich überschätzen, mit denen, die sich permanent unterschätzen nahezu auf.

<b>Ein paar Probleme</b>

Einige Forderungen der Agilen Prozesse oder auch aus dem ähnlichen Konzept des Extreme Programming lassen sich jedoch kaum auf große Projekte übertragen. So gestaltet sich eine direkte Zusammenarbeit mit der Kundschaft schwierig. Oftmals ist es schon eine Kunst, den eigentlichen Kunden zu identifizieren. Nicht nur der Auftraggeber und die Anwender sind unterschiedliche Personen, es gibt auch viele Zwischenebenen. Im Zweifelsfall, so Eckstein und Josuttis, ist das Gesamtprojekt als Kunde zu definieren.

Schwierig gestalten sich auch die Integrationsarbeiten, um die Arbeiten der einzelnen Gruppen zusammenspielen zu lassen. Nach Darstellung von Eckstein und Josuttis aber verschieben sich die Risiken und Probleme nur. Werden die Bausteine in herkömmlicher Weise sukzessive integriert, braucht es zum Beispiel nur Stunden bis eine ziemlich unvollständige und vorübergehende aber ausführbare Version erzeugt ist. Entwickler sprechen von einem “Build”.

Eine Framework-Build dauert etwa 2,5 Stunden, ein Domain-Build rund 6 Stunden und das Testen eines Moduls vielleicht 4 Stunden. Typischer Weise finden Builds in der Nacht statt – und die ist irgendwann vorbei. Das Herstellen einer lauffähigen Software stößt demnach ständig an zeitliche Limits. Bei einem kollektiven Vorgehen bei der Integration braucht es ein bis zwei Jahre bis ein nächtliches Build überhaupt stattfinden kann. Zudem besteht die Gefahr, die Übersicht zu verlieren.

Dennoch scheinen Oestereichs Erfolge Eckstein und Josutis recht zu geben. Sie können auf weniger Fehler in den ausgelieferten Produkten und kürzere Projektlaufzeiten verweisen. Zum Teil konnten ihre Projekte die Planung für das Gesamtprojekt um 20 Prozent und mehr unterschreiten.