Engpässe entstehen selten dort, wo man sie sucht. Sie entstehen, wo mehrere Vorhaben unabhängig voneinander dieselbe knappe Qualifikation einplanen — und sie werden schlimmer, wenn dieselbe Zeit auch die Urlaubszeit ist.
Das Beispiel ist der Jahreswechsel eines IT-Dienstleisters mit vier gleichzeitigen Vorhaben auf einem Stamm von 30 Personen: die ERP-Einführung, ein Kundenportal, ein Dokumentenmanagementsystem und ein BI-Berichtswesen.
Schritt 1: Der Befund#
Bild 1 von 3 — Vier Vorhaben, ein Team: Aufgeklappt zeigt die Zeile, woraus die Bindung besteht — Sprints und Datenmigration des ERP-Projekts, Suche und Fehlerbehebung des Portals, die Ablage des Dokumentenmanagements und die Ladeprozesse des Berichtswesens, elf Vorgänge aus vier Vorhaben. Darunter stehen die neun Entwickler mit ihren Urlaubstagen (U). Genau dort, wo beides zusammenfällt, steigt der Bedarf auf 12 gegen 8 verfügbare: −15 Personentage, sechs Prozent des Bedarfs. Das Diagramm zeigt es als orangen Aufsatz über der grünen Kapazitätslinie.
Schritt 2: Wer ihn verursacht#
Bild 2 von 3 — Eine Ebene tiefer steht, wer den Engpass verursacht — und die Antwort lautet: nicht einer allein. Das ERP-Projekt bringt 133 der 243 Personentage mit, das Kundenportal 20; Dokumentenmanagement und Berichtswesen stehen unterhalb des Bildausschnitts. Sogar das kleine Portal trägt eine eigene Unterdeckung: −3 (4 Prozent) an den zwei Tagen um Weihnachten. Keiner der Vorgänge ist für sich zu groß — das ist der Grund, warum solche Konflikte in Einzelplänen unsichtbar bleiben.
Schritt 3: Die Gegenprobe#
Bild 3 von 3 — Und hier die Gegenprobe, die den Befund erst zur Aussage macht: Nimmt man dasselbe Fenster und dasselbe Team, aber nur ein Vorhaben, ist von einem Engpass nichts zu sehen. Im Diagramm liegen die Bedarfsbalken bei 1 bis 2 unter einer Kapazitätslinie von 8. Wer nur sein eigenes Projekt plant, hat keinen Grund zur Sorge — und genau deshalb merkt es niemand.
Was die drei Bilder zusammen sagen#
| Portfolio | Kundenportal allein | |
|---|---|---|
| Aufwand Backend | 243 PT | 20 PT |
| Bedarf je Tag | 10 bis 12 | 1 bis 2 |
| Kapazität | 8 | 8 |
| Unterdeckung | −15 (6 %) | — |
Dieselben Daten, dieselbe Ansicht, dasselbe Team — und zwei gegensätzliche Antworten. Der Unterschied ist allein der Ausschnitt: Wer nur sein Projekt plant, plant an der Wirklichkeit vorbei.
Der Unterschied zwischen Überlast und Unterdeckung#
Diese Ansicht sagt: Die Qualifikation Backend deckt den Bedarf nicht. Sie sagt nicht, dass eine bestimmte Person zu viel auf dem Tisch hat — das wäre eine Aussage der Personalansicht und eine andere Frage. Wer beides verwechselt, diskutiert über Überstunden, wo eine Einstellung, eine Verschiebung oder ein Nachunternehmer die Antwort wäre.
Warum hier keine Verschiebung hilft#
Der naheliegende Reflex — den unkritischsten Verursacher in seinen Puffer schieben — läuft an diesem Portfolio ins Leere, und zwar messbar: Jeder der vier unkritischen Verursacher wurde probeweise verschoben (um drei bis neun Arbeitstage), und jede dieser Verschiebungen bricht die Terminierung mit einem Konflikt ab. Der Grund steht im Kalender: Alle vier Vorhaben laufen auf fixierte Jahresend-Meilensteine zu — „Entwicklung abgeschlossen" am 28. Dezember, „Umsetzung abgeschlossen" am 8. Januar. Zum Jahreswechsel gibt es keinen Puffer mehr, in den man ausweichen könnte.
Das ist keine Schwäche des Plans, sondern seine Auskunft: Wo nichts mehr verschiebbar ist, heißen die Antworten Priorisierung, Besetzung oder Nachunternehmer — und diese Entscheidung soll jemand treffen, nicht die Terminierung im Stillen.
Wie eine Verschiebung aussieht, wenn sie den Konflikt wirklich auflöst — weil der Puffer da ist —, steht auf Basisplan und Soll-Ist-Vergleich.
Wie Rillsoft Project Kapazitäten rechnet, steht auf der Produktseite zur Ressourcenplanung in der Rillsoft Cloud. Zurück zur Übersicht IT-Dienstleister.