Kunden haben nicht immer fertige Spezifikationen

Mit den festen Teams in der Produktentwicklung hat man keine Ressourcenkonflikte mehr, muss sich aber auf Lieferungen entsprechend der Leistungsfähigkeit des Teams einlassen. Damit geht eine entsprechende Ergebnisoffenheit einher, die für Eigenentwicklungen natürlich gut gelebt werden kann. Kunden hatten bisher jedoch meist feste Vorstellungen von beauftragten Liefergegenständen. Deshalb war es schwierig, diesen Ansatz auch für Kundenprojekte einzusetzen.

Wir beobachten zunehmend, dass Kunden in neuen und komplexen Umgebungen zwar Anforderungen haben, aber eben keine genaue Vorstellung von deren Umsetzung. Nachdem in immer kürzeren Abständen neue Technologien zur Verfügung stehen, ist es immer häufiger der Fall, dass Projektinhalte für Auftraggeber und Auftragnehmer absolutes Neuland sind.

In solchen Situationen kann es für beide Seiten sehr wohl hilfreich sein, zumindest die Spezifikation und den ersten Prototypen in regelmäßigen Iterationen oder Sprints von zwei Wochen zu erstellen. Mit entsprechendem Verhandlungsgeschick können Sie vielleicht sogar das ganze Vorhaben mit einem festen Team agil umsetzen. Fragen Sie Ihre Kunden, Sie werden immer öfter eine positive Antwort bekommen!

Es kommt auf die Taktung an

Wenn Sie also bei diversen Kunden mit ziemlich festen Teams in gleich getakteten Iterationen arbeiten, ist auch der Wechsel von Teammitgliedern einfacher zu organisieren. Die Entspannung der Ressourcensituation kommt wie in der agilen Produktentwicklung durch die Zusicherung der Personen für ganze Iterationen statt auf Zuruf.

Wir haben alle zwei Wochen ein Teamleitermeeting, in dem die Einteilung der Personen für Kundenprojekte und für interne Ziele für die nächsten Wochen vorgeschlagen wird. Unmittelbar danach folgt ein PMO-Meeting mit Teilnehmern aus der Geschäftsleitung, Entwicklungsleitung, Consultingleitung und Sales zur Bestätigung bzw. Konfliktlösung. Die dabei gesetzten Zuordnungen von Teammitgliedern bleiben dann für zwei bzw. vier Wochen konstant.

Wir haben also alle zwei Wochen einen genauen Stand der Projektplanungen mit den aktuellen Ressourcenanforderungen. Auf dieser Basis werden Ressourcen zugesichert. Die kommenden beiden Wochen bleiben dabei immer unangetastet, denn sie wurden schon im vorherigen Meeting fixiert.

Bild 1: Möglichst konstant vorausschauende Ressourcenzuweisungen vermeiden Konflikte

Wer eine Ressourcenanfrage hat, darf also fest mit einer Antwort aus den zweiwöchigen Meetings rechnen, aber eben nicht jederzeit. Wie die Antwort aussieht, ist natürlich ungewiss, aber sie wird von oberster Ebene mitgetragen. Echte Konflikte haben wir damit nur noch im Katastrophenfall. Die meisten Konflikte vermeiden wir durch den festen Planungs- und Zusicherungstakt.

Die eigene Schätzung ist die beste

Verspätungen in klassischen Projekten kommen oft daher, dass die Aufwandschätzung vom Projektleiter oder vom Verkauf gemacht und zugesagt wurde. Das eingesetzte Team hat aber leider nicht wie erhofft die erforderliche Erfahrung und manche Inhalte müssen generell erst erforscht werden. Und schon beginnt sich das Ressourcen-Karussell zu drehen: Personen werden ausgetauscht oder man versucht mit mehr Kapazität zu retten, was zu retten ist.

Dazu zieht man Personen von anderen Projekten ab und löst damit anderswo die nächsten Probleme aus. Nimmt man den Auftrag erst an, nachdem das Team seine Schätzung gemacht hat, – wie in der agilen Welt üblich – spart man sich diese Art von Problem weitestgehend. Es gibt einfach weniger Ressourcenkonflikte, weil weniger verschoben wird.

Steuern kann man nur, wenn man weiß, wo man steht

In der agilen Welt gibt es nach jedem Sprint ein Review für die Auftraggeber und eine Retrospektive mit dem Team. Für die Projektsteuerung in der klassischen Welt gibt es Statusmeetings, die vom Projektleiter einberufen werden. Dies geschieht aber leider nicht annähernd in vergleichbarer Häufigkeit wie die Sprint-Reviews, sondern nach Bedarf oder zur Vorbereitung von Meilensteinen bzw. Stage Gates. In der agilen Welt kommuniziert man jedenfalls regelmäßig und ausführlich um sicherzustellen, dass man am richtigen Weg ist.

Bei klassischen Projekten bemerkt man dagegen leider oft viel zu spät, dass man vom Weg abgekommen ist. Es wird Aufwand in falsche Aktivitäten gesteckt oder Inhalte einfach falsch ausgeführt. Bemerkt wird dies zufällig oder beim nächsten Statusmeeting in fünf Wochen. Der Aufwand, Fehler zu korrigieren, steigt aber mit der Entfernung zum richtigen Weg. Extraeinsätze von Ressourcen sind die Folge, die bei anderen Projekten wieder zu Konflikten führen.

Warum macht man in klassischen Projekten nicht öfter ein Statusmeeting, um zu zeigen, wo man steht? Vielleicht weil Statusmeetings eher als Rechtfertigungsrunden geführt und daher als unangenehm eingestuft werden? In Sprint-Reviews dagegen zeigen die Teammitglieder normalerweise gerne, was sie in den letzten beiden Wochen geschaffen haben. Das liegt aber auch daran, dass die Aufwände zu den Inhalten selbst geschätzt wurden, weswegen sie auch eine gute Chance hatten, fertig zu werden und zu glänzen.

Bild 2: Regelmäßige Statusmeetings helfen unnötige Ressourceneinsätze zu vermeiden

Nachdem ein Auftragsprojekt mit dem Kunden in Phasen und Meilensteinen geplant wurde, kann es zur besseren Steuerung intern in Iterationen bzw. Sprints eingeteilt werden. Statt ein Statusmeeting irgendwann einzuberufen, wenn der Projektleiter gerade Zeit hat oder wenn mal wieder etwas eskaliert ist, könnte man das ja auch ganz regelmäßig jede Woche, alle zwei Wochen oder wenigstens am Ende jeden Monats erledigen. Dann weiß man früher, was gerade läuft – und was nicht. Ein Eingreifen kann so rechtzeitig erfolgen und unnötige Ressourcenaufwände verhindert werden. Ich frage mich ohnehin, warum es nicht für jeden Projektleiter mittlerweile normal ist, ein Statusmeeting regelmäßig statt auf Zuruf einzurichten.

Mit Takt und Taktung zum Erfolg

Wenn man also mit einem möglichst festen Team arbeitet, das selbst die zu erledigenden Aufgaben schätzt und sich regelmäßig in kurzen Abständen über den Fortschritt austauscht, dann führt das sicher zu sehr guten Ergebnissen. Und weil in so einer Umgebung einfach weniger schief geht, kommt es automatisch zu weniger Ressourcenkonflikten. Das sagt der gesunde Menschenverstand.

Ob das nun klassisch, agil oder hybrid heißt, ist am Ende egal. Zentral erscheinen mir für beide Welten die beiden Ts Takt und Taktung: Damit meine ich zum einen eine respektvolle Haltung gegenüber allen Beteiligten und zum anderen einen konstanten zeitlichen Zyklus für die Steuerung und Durchführung des Projekts.