Ein Projekt richtig starten

Die entscheidenden Fehler passieren am Projektanfang, gleich beim Aufsetzen des Projektes. Sie kennen das: Wieviel Aufwand wird die Entwicklung kosten? Niemand weiß es, weil die Anforderungen noch nicht klar sind. Trotzdem wird ein Termin gesetzt, denn man will ja irgendwann fertig werden! Außerdem setzt man gern viele Leute auf einmal von Anfang an ins Projektteam, denn dann geht die Arbeit schneller voran, richtig?

Sie merken an meinem ironischen Unterton, dass ich nicht wirklich an dieses Vorgehen glaube. Zu oft habe ich in den Projekten, in denen ich unterwegs bin, gesehen, dass uns die Praxis eines Besseren belehrt. Woher kommt’s und vor allem: Was kann man tun?

Die vier Variablen

Die Erfahrung zeigt: Der Verlauf eines jeden Projektes ist eine Funktion von vier Variablen:

Projektverlauf = f(s, u, t, q)

s = Teamgröße, Anzahl Personen im Team

u = Umfang, z.B. Anzahl der zu implementierenden Funktionen

t = Termin

q = Qualität

Diese vier Parameter eines Projektes beeinflussen sich gegenseitig, das wäre an sich noch zu ertragen. Sie tun es jedoch zeitverzögert und nicht-linear, also der Alptraum für einen Projektmanager schlechthin. Hier ein paar Beispiele:

Teamgröße beeinflusst Termin

Nehmen Sie an, Ihr Projekt sei zeitlich “hinten dran”, also eine Schwäche bezüglich der Variable “t”. Sie fügen nun mehr Entwickler hinzu, also eine Stärke in der Variablen “s”, in der Hoffnung, die Schwäche in “t” kompensieren zu können. Was passiert? Die Neuen müssen erst eingearbeitet werden, und zwar von wem? Von den erfahrenen Leuten in Ihrem Projekt, also ausgerechnet von denen, die wegen “t” unter Druck stehen. Folglich sinkt die Arbeitsgeschwindigkeit des Projektteams zunächst ab, um dann später anzusteigen, wenn die Neuen sich sicher fühlen und “auf Trab” gekommen sind. Nebenbei steigt der Aufwand für Kommunikation im Projekt nicht-linear, das heißt, Sie bekommen aus einem doppelt so großen Team nicht automatisch eine doppelt so hohe Schlagzahl heraus.

Nun, das dürfte wohl die bekannteste Wechselwirkung zwischen zweien der vier Variablen sein. Die Lektionen, die wir alle in der Branche über die Jahre gelernt haben, lauten: 1. Fangen Sie mit wenigen Leuten an, denn diese müssen viel miteinander kommunizieren, bis die Requirements klar und die erste Architektur definiert sind. 2. Fügen Sie dann rechtzeitig Leute zum Team hinzu, so dass Sie die Delle in der Teamperformance noch vor Projektende wieder mehr als ausgeglichen haben.

Umfang beeinflusst Termin

Zunächst noch etwas Einfaches: Der Kunde möchte gern mehr Features in der zu entwickelnden Software sehen, also einen größeren Umfang “u”. Folglich wird Ihr Team, wenn Sie die Teamgröße konstant lassen, mehr Arbeit pro Person haben und deshalb länger brauchen. Ein größeres “u” bewirkt direkt ein späteres “t”. Als guter Projektmanager haben Sie dem Kunden natürlich sofort gesagt, dass das ein Change Request ist, der extra bezahlt werden muss, richtig? Doch es gibt weitere Wechselwirkungen, die teilweise viel subtiler sind.

Termin beeinflusst Qualität

Die Zeit, die Sie sich für Ihr Projekt nehmen, beeinflusst direkt die Qualität, die Sie realisieren können. Wenn die Zeit zu knapp bemessen ist, werden die Teammitglieder dazu tendieren, mehr neue Fehler zu machen und die alten Fehler mangels Zeit mit Workarounds zu kompensieren versuchen. Jedes neu eingebaute Feature erzeugt woanders einen Bug. Das ergibt eine Abwärtsspirale, die Sie beim kleinsten Anzeichen sofort bekämpfen müssen. Tipp: Sofort Refactoring als Gegenmittel ansetzen, egal wieviel Zeit Sie noch zu haben glauben. (Ich spreche aus Erfahrung: Wir arbeiteten im Projekt ca. ein Jahr lang im Glauben, wir hätten zu wenig Zeit – was denken Sie, was kam dabei heraus?)

Was passiert, wenn Sie Ihrem Team dagegen zu viel Zeit geben? (Gibt es diesen Fall überhaupt?) Nun, hier besteht die Gefahr, dass “goldene Wasserhähne” in die Software eingebaut werden, die teuer, komplex, wartungsintensiv oder vielleicht für die Funktionalität, die der Kunde sehen wollte, sogar schlicht überflüssig sind. Mein Tipp: Setzen Sie die Zeit bis zum ersten sichtbaren Feature ein klein wenig zu knapp an, holen sich vom Kunden anhand eines Prototypen ausführliches Feedback und geben dann dem Team genügend Zeit, die Architektur angemessen zu überarbeiten und die tatsächlich gewünschten Features qualitativ hochwertig zu bauen.

Qualität beeinflusst Teamgröße

Wie bitte? Was soll das eine mit dem anderen zu tun haben? Jetzt kommen wir in den Bereich der Soft Skills, bitte beim Lesen das Gefühl mit einschalten! Es gibt nämlich “Stars” unter Ihren Leuten. Diese Stars wollen immer gute Arbeit abliefern, denn darüber definieren sie ihr Selbstverständnis. Wenn nun in Ihrem Projekt der Workaround-Virus umgeht (zum Beispiel wegen zu eng gesetzten Termins), arbeiten die Stars eine Weile dagegen und refaktorisieren, was das Zeug hält, in der Hoffnung, zur Qualität zurückkehren zu können. Nach einiger Zeit, sobald sie das Gefühl haben, dass es nichts mehr hilft, werden sie sich nach einem besseren Projekt umsehen und letztendlich das Team verlassen.

Termin beeinflusst Teamgröße

Das versteht man sofort. Stress will keiner gerne, schließlich soll noch Zeit für Familie und Freunde bleiben. Daher werden zu eng gesetzte Termine (wenn sie zur Regel werden) zur Verringerung Ihres Personals führen.

Qualität beeinflusst Termin

Es gibt manche Mitglieder von Projektteams, die glauben, einen Termin halten zu können, wenn sie auf geplante Testphasen verzichten oder notwendige Refactorings aufschieben bis nach dem Release. Das funktioniert immer nur kurzfristig. Es ist einer Kreditaufnahme vergleichbar: in nicht allzu ferner Zeit muss der Kredit zurückgezahlt werden, sonst geht man pleite. Deshalb: Der sicherste Weg, die Arbeitsgeschwindigkeit zu halten, ist es, die Qualität immer so hoch wie möglich zu halten. Warum? Je höher die Qualität (z.B. sauber definierte Anforderungen, stimmiges, intaktes Design mit angemessener Architektur), desto leichter kann das Team Feature für Feature dem System hinzufügen, ohne dass das System bricht.

Das bedeutet: Qualität spart Zeit. Wildes Hacken verbraucht Zeit, obwohl es vermeintlich schneller geht. Messen Sie im Zweifelsfall öfters nach: Wie lange hat Ihr Team gebraucht, um ein Feature F13 einzubauen? Ungefähr so lange wie bei Feature F7, das Sie als “gleich dick” einschätzen? Dann ist noch alles in Ordnung. Wenn Sie beim Messen feststellen, dass Features F25, F26, F27 plötzlich regelmäßig erheblich länger brauchen als F13, obwohl Sie dieselbe Aufwandsschätzung abgeben würden, dann ist vermutlich mit der Variablen “q” etwas im Busch! Fragen Sie beim Team nach – einer weiß bestimmt, woran es liegt. Wenn nicht, holen Sie einen externen Coach, der findet es beim Review heraus.

Fazit: Was tun?

Nun wollen Sie sicherlich wissen: Wie müssen Sie die vier Variablen gegeneinander ausbalancieren, damit das Projektteam aus dem eingesetzten Kapital des Kunden ein Maximum an Qualitätssoftware macht und dabei noch Freude hat? Mein Tipp: Machen Sie es so:

• Setzen Sie die Qualität “q” so hoch wie möglich an, um zügig und sicher arbeiten zu können.
• Setzen Sie den Termin “t” fest, unverrückbar.
• Nehmen Sie die Teamgröße “s” nur so groß wie eben nötig und halten Sie sie dann zunächst fest.
• Passen Sie den Umfang “u” mit dem Kunden so an, dass “t” getroffen wird.
• Überdenken Sie das Verhältnis u,s,t regelmäßig und nehmen Sie Anpassungen sorgfältig vor.

Also “q” und “t” fest, “s” streckenweise fest, “u” variabel.

Ausblick

“t” aushandeln und “s” rechtzeitig wachsen lassen – dafür gibt es Muster, so genannte Organisationspatterns. Diese besprechen wir in einem späteren Artikel.