Kategorie: Methodik & Frameworks
Infografik: 5 Schritte zur strukturierten Ressourcenplanung
Was ist Ressourcenplanung?
Ressourcenplanung ist der Abgleich zwischen dem Ressourcenbedarf aller Vorgänge und der tatsächlich verfügbaren Kapazität, mit dem Ziel, Überlast vor ihrem Eintreten sichtbar zu machen. Nach DIN 69901 ist eine Ressource jedes zur Durchführung einer Aufgabe nötige Mittel, also Personal, Sachmittel und Finanzmittel (Quelle). Die Norm verwendet dafür den Begriff Einsatzmittelplanung; DIN 69901-2:2009 beschreibt den Prozess Ressourcenplan erstellen mit den Bestandteilen Bedarfsschätzung und Einsatzterminierung (Quelle).
Der PMBOK Guide führt dieselbe Aufgabe im Wissensgebiet Project Resource Management, das die Prozesse zur Identifikation, Beschaffung und Steuerung der benötigten Ressourcen bündelt (Quelle). Relevant für die Planung sind vor allem Plan Resource Management, Estimate Activity Resources, Acquire Resources und Control Resources (Quelle).
Der häufigste Fehler steckt schon in der Ausgangsgröße: Anwesenheitszeit wird mit produktiver Projektzeit gleichgesetzt. Nettokapazität ist Bruttoarbeitszeit abzüglich Urlaub, Krankheit, Feiertagen und administrativer Tätigkeiten (Quelle).
Wann lohnt sich formale Ressourcenplanung und wann nicht?
Formale Ressourcenplanung lohnt sich, sobald dieselben Personen in mehreren Projekten gleichzeitig arbeiten. Das ist im Engineering der Normalfall: Ein Konstrukteur bedient parallel drei Aufträge, ein Inbetriebnehmer vier. Der Konflikt entsteht nicht im Projekt, sondern zwischen Projekten, und ist deshalb im Einzelprojektplan strukturell unsichtbar.
Sie brauchen sie ebenso, wenn Engpassrollen existieren, die nicht kurzfristig zugekauft werden können: Steuerungsprogrammierer, Schweißfachingenieur, Zulassungsverantwortlicher.
Verzichten können Sie in drei Fällen. Erstens bei dedizierten Teams, die genau einem Projekt zugeordnet sind. Zweitens wenn die Planungsgranularität feiner wäre als die Datenqualität: Eine Tagesplanung auf Basis von Aufwänden mit 30 Prozent Unsicherheit erzeugt Scheingenauigkeit. Drittens in Projekten unter etwa vier Wochen Laufzeit, in denen ein Abgleich länger dauert als die Umplanung selbst. Die sinnvolle Granularität liegt in den meisten Engineering-Organisationen bei Kalenderwoche und Rolle, nicht bei Tag und Person.
Welche 5 Schritte führen zu einer belastbaren Ressourcenplanung?
- Bedarf aus dem Projektstrukturplan ableiten
Ziel: Jede geplante Stunde hat einen Verursacher im PSP.
Vorgehen: Sie gehen vom Projektstrukturplan auf Arbeitspaketebene aus und ordnen jedem Paket Rolle, Stundenbedarf und den Zeitraum aus der Terminplanung zu. Aggregiert wird nach Rolle und Kalenderwoche, nicht nach Person. Personen werden erst im Zuordnungsschritt verplant.
Typischer Fehler: Nur Kernarbeit erfassen. Abstimmung, Nacharbeit nach Designreviews und Dokumentation machen im Engineering regelmäßig einen zweistelligen Prozentsatz aus und fehlen im PSP.
- Verfügbarkeit ermitteln und Nettokapazität berechnen
Ziel: Eine Kapazitätszahl, gegen die man planen kann, ohne sie später stillschweigend zu korrigieren.
Vorgehen: Sie starten bei der Sollarbeitszeit, ziehen Feiertage, geplanten Urlaub, statistische Krankheitsquote und den Anteil nicht projektwirksamer Arbeit ab. Die Nettokapazität ist die verbleibende projektwirksame Zeit; der Auslastungsgrad ergibt sich als geplante Arbeitslast geteilt durch Nettokapazität (Quelle).
Typischer Fehler: Mit 40 Stunden je Woche und Person rechnen. Realistisch sind im Engineering 28 bis 32 projektwirksame Stunden. Der Fehler beträgt 25 Prozent und wirkt auf jede Woche jedes Projekts.
- Ressourcen den Vorgängen zuordnen
Ziel: Aus Rollenbedarf wird namentliche Zuordnung mit Qualifikationsnachweis.
Vorgehen: Sie ordnen Personen zu und berücksichtigen dabei Qualifikationsprofil, Einarbeitungszeit und Vertretungsregelung. Engpassrollen werden zuerst verplant, weil sie die Reihenfolge aller anderen Zuordnungen bestimmen. Im PMBOK entspricht das dem Prozess Acquire Resources (Quelle).
Typischer Fehler: Zuordnung nach Verfügbarkeit statt nach Qualifikation. Wer den freien Kollegen statt den passenden nimmt, verschiebt den Aufwand in die Einarbeitung und macht ihn unsichtbar.
- Abgleichen: Leveling oder Smoothing
Ziel: Jede Überlast ist entweder aufgelöst oder als bewusste Entscheidung dokumentiert.
Vorgehen: Sie stellen Bedarf und Nettokapazität je Woche und Rolle gegenüber und wählen dann zwischen zwei Techniken. Resource Leveling passt Start- und Endtermine an die Ressourcenbeschränkung an; es kann den kritischen Pfad und damit den Projektendtermin verändern (Quelle). Resource Smoothing verschiebt Vorgänge ausschließlich innerhalb ihrer Puffer, hält eine definierte Obergrenze ein und lässt den kritischen Pfad unverändert (Quelle). Die Reihenfolge ist damit vorgegeben: erst Smoothing versuchen, erst danach Leveling (Quelle).
Typischer Fehler: Überlast durch Erhöhung der angenommenen Kapazität auflösen. Damit verschwindet der Konflikt aus der Tabelle, nicht aus dem Projekt.
- Überwachen und nachsteuern
Ziel: Die Planung bleibt während der Durchführung entscheidungsfähig.
Vorgehen: Sie vergleichen in festem Takt Plan- und Ist-Stunden je Rolle, prüfen Restaufwand statt Fertigstellungsgrad und aktualisieren Urlaube und Krankheitsausfälle. Der PMBOK-Prozess Control Resources deckt genau diese Rückkopplung ab (Quelle). ISO 21502:2020 ordnet Ressourcen als eigene Praktik in die Projektsteuerung ein (Quelle).
Typischer Fehler: Fertigstellungsgrad statt Restaufwand abfragen. Die Antwort 90 Prozent ist mit jedem Restaufwand vereinbar und liefert keine Planungsinformation.
Wie sieht der Kapazitätsabgleich an einem konkreten Beispiel aus?
Ausgangslage: Eine Konstruktionsabteilung im Sondermaschinenbau hat drei Konstrukteure und vier laufende Projekte. Betrachtet wird der Zeitraum KW 12 bis KW 17.
Schritt 2, Nettokapazität je Konstrukteur:
Position | Stunden je Woche |
|---|---|
Sollarbeitszeit | 40,0 |
abzüglich Urlaub und Krankheit (12 %) | -4,8 |
abzüglich interne Meetings, Admin, Angebotsunterstützung (15 %) | -5,3 |
Nettokapazität | 29,9, gerundet 30 |
Teamkapazität: 3 x 30 = 90 Stunden je Woche. In KW 14 und KW 15 ist ein Konstrukteur im Urlaub, dort beträgt die Kapazität 60 Stunden.
Schritt 1 und 4, Bedarf gegen Kapazität:
Woche | P1 | P2 | P3 | P4 | Bedarf | Kapazität | Auslastung | Delta |
|---|---|---|---|---|---|---|---|---|
KW 12 | 40 | 25 | 20 | 0 | 85 | 90 | 94 % | -5 |
KW 13 | 45 | 30 | 25 | 10 | 110 | 90 | 122 % | +20 |
KW 14 | 35 | 30 | 25 | 20 | 110 | 60 | 183 % | +50 |
KW 15 | 20 | 25 | 20 | 25 | 90 | 60 | 150 % | +30 |
KW 16 | 10 | 15 | 10 | 25 | 60 | 90 | 67 % | -30 |
KW 17 | 0 | 10 | 5 | 20 | 35 | 90 | 39 % | -55 |
Summe | 150 | 135 | 105 | 100 | 490 | 480 | 102 % | +10 |
Zwei Befunde stehen nebeneinander. Erstens eine strukturelle Lücke von 10 Stunden über sechs Wochen, also rund 2 Prozent. Die ist gering. Zweitens eine massive zeitliche Fehlverteilung: 183 Prozent Auslastung in KW 14, 39 Prozent in KW 17. Verschieben löst das zweite Problem, nicht das erste.
Abgleich, Schritt für Schritt.
Zuerst Smoothing innerhalb vorhandener Puffer. P2 hat zwei Wochen freien Puffer. 30 Stunden aus KW 14 und 10 Stunden aus KW 13 wandern in KW 16 und KW 17, dazu 5 Stunden aus KW 15. Der Endtermin von P2 bleibt unverändert, weil der kritische Pfad nicht berührt wird.
Danach Leveling für P4. P4 hat niedrigste Portfolio-Priorität und drei Wochen Gesamtpuffer. Der gesamte Vorgang wird um drei Wochen nach hinten verschoben. Das ist Leveling, kein Smoothing: Der Endtermin von P4 verschiebt sich um drei Wochen und wird als Entscheidung dokumentiert, nicht als Planungsdetail.
Ergebnis nach dem Abgleich:
Woche | Bedarf vorher | Bedarf nachher | Kapazität | Auslastung nachher |
|---|---|---|---|---|
KW 12 | 85 | 85 | 90 | 94 % |
KW 13 | 110 | 90 | 90 | 100 % |
KW 14 | 110 | 60 | 60 | 100 % |
KW 15 | 90 | 60 | 60 | 100 % |
KW 16 | 60 | 70 | 90 | 78 % |
KW 17 | 35 | 55 | 90 | 61 % |
Keine Woche liegt mehr über 100 Prozent. Der Preis ist explizit: drei Wochen späterer Endtermin für P4 und 70 verbleibende P4-Stunden in KW 18 bis KW 20. Die restliche Lücke von 10 Stunden wird über eine einmalige Überstundenfreigabe in KW 13 gedeckt und nicht in die Planung eingerechnet.
Entscheidend ist der Zeitpunkt: Die Überlast in KW 14 ist in KW 10 sichtbar. Wird sie erst in KW 14 sichtbar, existiert keine der beiden Optionen mehr, weil der Puffer von P2 dann verbraucht ist.
Fazit
Ressourcenplanung scheitert selten an der Methode und fast immer an der Eingangsgröße. Wer mit 40 statt 30 projektwirksamen Stunden rechnet, plant jede Woche 25 Prozent Überlast ein und merkt es erst, wenn Termine reißen.
Zwei Größen entscheiden über den Nutzen: die Ehrlichkeit der Nettokapazität und der Vorlauf, mit dem ein Konflikt sichtbar wird. Ein Kapazitätskonflikt, der drei bis vier Wochen vor Eintritt auf dem Tisch liegt, ist eine Terminentscheidung mit mehreren Optionen. Derselbe Konflikt in der betroffenen Woche ist nur noch die Wahl zwischen Überstunden und Verzug.
Quellen
- Ressourcenplanung, REFA-Lexikon (DIN 69901, Ressourcenbegriff) — https://refa.de/service/refa-lexikon/ressourcenplanung (Abruf 2026-09)
- Einsatzmittelplanung (DIN 69901-2:2009, Prozess Ressourcenplan erstellen) — https://www.ibim.de/projekt/3-5.htm (Abruf 2026-09)
- Die Bedeutung der DIN 69901 im Projektmanagement — https://scrummasterjournal.de/din/din-69901-projekt/ (Abruf 2026-09)
- PMBOK Guide, Project Management Institute — https://www.pmi.org/standards/pmbok (Abruf 2026-09)
- A Guide to the Project Management Body of Knowledge, Kapitel 9 Project Resource Management — https://www.oreilly.com/library/view/a-guide-to/9781628251845/part_1-9.xhtml (Abruf 2026-09)
- Project Resource Management According to the PMBOK — https://www.projectengineer.net/project-resource-management-according-to-the-pmbok/ (Abruf 2026-09)
- Resource leveling, Wikipedia — https://en.wikipedia.org/wiki/Resource_leveling (Abruf 2026-09)
- Resource smoothing, Wikipedia — https://en.wikipedia.org/wiki/Resource_smoothing (Abruf 2026-09)
- Resource Leveling vs Resource Smoothing, BrainBOK — https://www.brainbok.com/guide/pm-study-notes/resource-leveling-vs-resource-smoothing (Abruf 2026-09)
- ISO 21502, Wikipedia — https://de.wikipedia.org/wiki/ISO_21502 (Abruf 2026-09)
- Produktivität berechnen: Netto-Kapazität und Auslastungsgrad, ZEP — https://www.zep.de/blog/produktivitaet-berechnen (Abruf 2026-09)
Weiterführend: 5 Methoden der Aufwandsschätzung im Vergleich und Projektmanagement im Sondermaschinenbau: die 5 typischen Stolperfallen.
Mehr zu Projektmanagement für technisch komplexe Projekte: Aligia



