Wer schneller werden will, sollte die Anzahl parallel laufender Projekte möglichst gering halten. Unter anderem, weil so einige Projekte früher abgeschlossen werden, was Verzögerungskosten spart; und weil weniger Projekte weniger Multitasking bedeuten.

Es lohnt sich also, die Ursachen für die große Anzahl parallel laufender Projekte zu ergründen. Vielleicht können wir ja schon etwas besser werden, indem wir einige der Ursachen angehen?

Es gibt kein Problembewusstsein. Der Parameter “Anzahl parallel laufender Projekte” spielt bei der Jahresplanung kaum eine Rolle. Solange wir den geplanten Aufwand in das Raster aus Ressourcen und Zeit einfüllen können, ist es egal, ob viele Leute über einen kurzen Zeitraum oder wenige über einen langen Zeitraum an etwas arbeiten.

Wir können ja schon mal anfangen. Es gibt dem Kunden (ob extern oder intern) ein gutes Gefühl, wenn wir sagen: “Wir haben das Projekt schon angefangen”. Auch wenn vielleicht wochenlang nichts oder nur sehr wenig passiert, kann man das verborgen halten. In der Zwischenzeit laufen aber trotzdem die Verzögerungskosten anderer Projekte sowie die Kosten für Multitasking auf (siehe unten),

Wir müssen ausgelastet sein, alles andere wäre Verschwendung. Wenn es immer genug Projekte gibt, erscheint die IT-Organisation nie unausgelastet. Andernfalls könnte ja der Eindruck von Überkapazitäten entstehen, was eine Einladung zur Kürzung von Budgets und Stellen wäre. Eine höhere Auslastung geht aber auf Kosten der Durchlaufzeit. Wer nämlich immer ausgelastet sein will, braucht immer einen Vorrat an unerledigter Arbeit. Und so hat die ausgelastete IT-Organisation ein Portfolio von Projekten, von denen viele überfällig sind und umso ungeduldiger erwartet werden.

Zum Auslastungsdenken wäre Einiges mehr zu sagen, lassen Sie es mich einfach auf den Punkt bringen mit dem Slogan: “Durchlaufzeit minimieren statt Auslastung maximieren.”

Wir können nicht so viele Leute auf ein Projekt setzen. Ab wann bringt zusätzliches Personal kaum noch einen Zuwachs an Produktivität, weil sich alle auf die Füße treten? Irgendwann ist die maximale sinnvolle Anzahl Teammitglieder erreicht.

Wenn ein System besser strukturiert ist, können mehr Leute parallel daran arbeiten. So sparen z.B. gut durchdachte und dokumentierte Schnittstellen erheblich Koordinationsaufwand zwischen Menschen, und gute Unit-Tests entdecken Änderungen mit problematischen “Nebenwirkungen” frühzeitig.

Projekte werden zu spät fertig Wenn Projekte häufig in die Verlängerung gehen müssen, steigt natürlich die Zahl parallel laufender Projekte. Die Kapazität bleibt ungefähr gleich, der wachsende Zeitdruck (wir sind schon beim Start des neuen Projekts spät dran) führt zu faulen Kompromissen bei der Qualität und Struktur des Codes, beim Testen usw. Auch hier gilt es, lieber den Scope zu kürzen statt das Projekt zu verlängern.

Die Kosten für Multitasking werden nicht berücksichtigt. Auf Organisationsebene fallen diese Kosten für alle an, die mit dem Projektportfolio als ganzes beschäftigt sind (PMO). Außerdem betrifft es Querschnittsfunktionen wie etwa die Rechtsabteilung, Sicherheit, Architektur, die zum Flaschenhals werden, weil sich so viele Projekte bei ihnen stauen. Auf Mitarbeiterebene kommt es früher oder später dazu, dass ein Mitarbeiter mehrere Projekte parallel bearbeitet. Jedes zusätzliche Projekt ist eine weitere Quelle für Unterbrechungen, sei es durch “Ich hab da kurz mal ‘ne Frage…” oder durch “Wir haben hier eine Krise, lass alles steh’n und liegen!”.

Es gibt keine Pausetaste für Projekte. So wie die Abneigung, ein Projekt noch nicht zu starten, scheint es eine Abneigung zu geben, ein Projekt für angehalten (“on hold”) zu erklären. Andererseits gibt es natürlich immer mal wieder Projekte, an denen de facto nicht gearbeitet wird, weil andere Dinge Priorität haben.

Manchmal ist die Pause auch der Anfang vom Ende des Projekts, womit man dann einen Misserfolg eingestehen muss. Trotzdem kann es sinnvoll sein, ein Projekt zeitweise zu parken, und das nicht als Katastrophe zu sehen. Vor so einer Entscheidung brauchen wir natürlich eine Bewertung des Projektportfolios, damit wir diejenigen Projekte mit den geringsten absoluten Verzögerungskosten zum Anhalten auswählen.

Wir können das Projekt jetzt nicht beenden. Manchmal würden so viele halbfertige Themen auf der Strecke bleiben, dass man lieber weitermacht, anstatt das verspätete Projekt jetzt zu beenden oder wenigstens zu pausieren. Auch für ein Projekt, das voll im Zeitplan liegt, kann ein vorzeitiges Projektende sehr sinnvoll sein. Ich könnte z.B. freiwillig auf die letzten 5% an Features verzichten, wenn ich dafür die frei werdende Kapazität anderswo profitabler einsetzen kann.

Es ist daher wichtig, so früh wie möglich “Release-fähig” zu werden, und die Features nach Wichtigkeit abzuarbeiten. Wir haben beim Thema regelmäßige Releases über Feature-Switches berichtet, mit denen unfertige Features wenigstens verborgen werden können. Das ist besser als nichts.

Auf einem anderen Blatt stehen Projekte, die man schon längst hätte abbrechen müssen, z.B. weil sie in’s Nirgendwo führen, oder weil sie nicht mehr wirtschaftlich sind. Hoffen wir mal, dass es bei Ihnen nicht allzu viele davon gibt.

Matthias Berth