Warum externe Ressourcen keine Projekte retten

Wenn ein IT-Projekt ins Stocken gerät, ist der Reflex in vielen Organisationen erstaunlich ähnlich. Es werden zusätzliche Köpfe besorgt. Ein weiterer Entwickler, eine zweite Beraterin, ein dritter Freelancer, der „mit anpackt”. Die Annahme dahinter ist intuitiv: Wo mehr Hände sind, wird mehr fertig. In der Praxis lässt sich diese Rechnung jedoch nur selten aufstellen. Verzögerungen entstehen in den seltensten Fällen, weil zu wenige Menschen am Thema arbeiten. Sie entstehen, weil unklar ist, woran genau gearbeitet werden soll, wer das entscheidet und ob das, was nach oben gemeldet wird, mit der Realität im Projekt noch etwas zu tun hat.

Besonders deutlich wurde das in einem Projekt für einen öffentlichen Auftraggeber. Ziel war die Entwicklung eines modernen Desktops für die öffentliche Verwaltung gemäß der Deutschen Verwaltungscloud-Strategie (DVS). Eine bisher monolithische Softwareplattform sollte containerisiert und skalierbar gemacht werden – als MVP, in einem fest gesetzten Zeitrahmen von neun Monaten. Das Vorhaben wurde überwiegend mit Freelancern besetzt. Als wir dazukamen, lag das Projekt mindestens ein Jahr hinter Plan, zentrale Komponenten waren nicht containerisiert, und neu zu entwickelnde Bausteine existierten überhaupt nicht oder bestenfalls als Proof of Concept.

„Alles grün”, obwohl unten nichts lief

Der vielleicht bemerkenswerteste Befund war kein technischer. Die Projektleitung reportete nach oben verlässlich „alles grün”, während im Maschinenraum kaum etwas vorankam. Diese Lücke zwischen Statusbericht und Realität ist gefährlicher als jede einzelne technische Baustelle. Denn solange oben der Eindruck herrscht, alles laufe nach Plan, wird genau das getan, was die Lage verschärft: abgewartet, durchgehalten, im Zweifel weiter aufgestockt.

Hinzu kam: Im Team waren keine sinnvollen Prozessabläufe etabliert und gelebt. Es gab kein verbindliches Vorgehen, keine belastbaren Artefakte, keine Instanz, die Anforderungen bündelte und entschied. Und die angeheuerten Externen brachten zum Teil nicht die nötigen Kompetenzen mit und waren auch nicht willens, sich einzuarbeiten. Jeder zusätzliche Kopf erhöhte unter diesen Bedingungen nicht die Lieferfähigkeit, sondern die Zahl der Schnittstellen, an denen dieselben offenen Fragen neu interpretiert wurden.

Mehr Externe ist keine Antwort auf ein Strukturproblem

Externe Ressourcen lösen ein bestimmtes Problem sehr zuverlässig: Wenn die Aufgabe klar ist, die Anforderungen stabil sind und nur die Umsetzungskapazität fehlt, schaffen zusätzliche Hände tatsächlich Tempo. Genau diese Voraussetzungen sind in Projekten, die ins Stocken geraten, aber fast nie gegeben.

In diesem Vorhaben war der Scope unscharf, die Prozesse fehlten, und ein Teil der eingesetzten Kräfte konnte oder wollte die Lücke nicht füllen. Was wie ein Kapazitätsproblem aussah, war in Wahrheit ein Steuerungsproblem. Und Steuerungsprobleme lassen sich nicht über Ressourcen lösen. Sie werden durch zusätzliche Ressourcen sogar verstärkt: Mehr Beteiligte bedeuten mehr Abstimmungen, mehr Annahmen und mehr Varianten derselben unklaren Vorgabe.

Erst Transparenz, dann Tempo: die Neuausrichtung der Steuerung

An diesem Punkt setzte die Neuausrichtung an. Statt weitere Kapazität zu beschaffen, haben wir zuerst die Steuerung des Projekts neu aufgesetzt und Transparenz darüber hergestellt, wo das Vorhaben wirklich stand, nicht wo es laut Report stehen sollte.

Konkret hieß das: Wir haben Scrum eingeführt und sichergestellt, dass die Prozesse auch tatsächlich eingehalten werden und die notwendigen Artefakte existieren. Wir haben einen engen Austausch zwischen Entwicklung und Produktmanagement etabliert, um die Anforderungen an das MVP sauber zu ermitteln und – mindestens ebenso wichtig – den Scope bewusst zu begrenzen. Wir haben die Performance der eingesetzten externen Kräfte evaluiert und dort nachgesteuert, wo das nötige Skillset fehlte: durch gezielte Neubesetzung statt durch bloßes Aufstocken. Die zugelieferten Technologiekonzepte haben wir hinterfragt und nachschärfen lassen, statt sie ungeprüft zu übernehmen. Und auf dieser Basis haben wir eine neue, belastbare Zeitplanung aufstellen lassen.

Diese Schritte klingen formal, fast nach zusätzlichem Overhead. Tatsächlich entlasteten sie das Projekt sofort. Der entscheidende Nebeneffekt: Indem wir die Prozesse zwischen internen Entwicklern und externen Dienstleistern entzerrt haben, hielten wir beiden Seiten den Rücken frei. Jeder wusste wieder, woran er war und konnte seine Zeit auf Inhalte verwenden statt auf Abstimmungsschleifen.

Nachsteuern statt durchhalten

Ein zweiter, mindestens ebenso wichtiger Schritt war die Bereitschaft, das Projekt nicht einfach weiterlaufen zu lassen. In vielen Organisationen herrscht eine implizite Erwartung, dass ein einmal gestartetes Vorhaben durchgezogen wird, möglichst ohne sichtbare Korrekturen. Verzögerungen werden aufgefangen, Ressourcen aufgestockt, Umfänge stillschweigend verschoben, aber die ursprüngliche Planung bleibt unangetastet. Im schlimmsten Fall bleibt sogar der grüne Status unangetastet.

Diese Haltung kostet mehr, als sie verhindern soll. Wer durchhält, ohne nachzusteuern, akzeptiert, dass die Lücke zwischen Plan und Realität immer größer wird, bis sie nicht mehr zu schließen ist. Nachsteuern dagegen bedeutet, Annahmen, Umfang und Vorgehen zu definierten Zeitpunkten bewusst zu überprüfen und anzupassen und ehrlich zu benennen, was mit den vorhandenen Mitteln in der verfügbaren Zeit tatsächlich erreichbar ist. Genau das haben wir getan: den Scope auf ein lieferbares MVP fokussiert und die Mannschaft so zusammengestellt, dass sie das auch leisten konnte. Nachsteuern ist kein Eingeständnis eines Fehlers, sondern Ausdruck professioneller Projektführung.

Was klare Steuerungsentscheidungen bewirken

Die Wirkung dieser Entscheidungen war messbar. Das Projekt, das mindestens ein Jahr hinter Plan lag, wurde neun Monate später im Zeitplan abgeschlossen und das Produkt ausgeliefert. Aus einem Vorhaben mit Krisencharakter wurde wieder ein steuerbares Projekt.

Mindestens genauso wichtig war der nachhaltige Effekt. Es entstanden stabile Strukturen für die zukünftige Weiterentwicklung. Das Produkt war von Beginn an so angelegt, dass es nicht nur in diesem Projekt, sondern auch für weitere Kunden außerhalb genutzt werden kann. Der Kunde wird seitdem als lieferfähig, responsiv und verlässlich wahrgenommen. Daraus ergeben sich wiederkehrende Umsätze und konkrete Wachstumschancen. Aus einem Projekt, das zu scheitern drohte, wurde damit eine Grundlage fürs Geschäft.

Diese Effekte sind kein Zufall. Sie sind das vorhersehbare Ergebnis, wenn Steuerung als eigenständige Führungsaufgabe verstanden und ausgeübt wird, statt sie als Nebenprodukt der Umsetzung zu behandeln.

Ressourcen verstärken, was vorhanden ist

Externe Ressourcen sind ein wertvolles Werkzeug. Sie verstärken jedoch das, was bereits da ist. In gut gesteuerten Projekten verstärken sie Lieferfähigkeit. In schlecht gesteuerten Projekten verstärken sie Unklarheit. Wer in einer Krisensituation zuerst nach zusätzlichen Köpfen greift, ohne die Steuerungsfrage zu beantworten, beschleunigt das eigentliche Problem.

Genau hier setzt flowciety an. Wir helfen Unternehmen, vor der Frage nach mehr Ressourcen die wichtigeren Fragen zu beantworten: Wer entscheidet über Anforderungen? Welche Anforderungen gelten wirklich? Wie wird ehrlich nachgehalten, was im Projekt tatsächlich passiert? Erst wenn diese Grundlagen stehen, entfalten externe Partner die Wirkung, die von ihnen erwartet wird.

In unserem Whitepaper zur IT-Architektur zeigen wir, wie klare Rollen, ein begrenzter, belastbarer Scope und definierte Entscheidungswege Projekte stabilisieren, bevor zusätzliche Ressourcen ins Spiel kommen.

Quelle Titelbild: emwe studio