Projektplanung ist nicht Terminplanung: der entscheidende Unterschied für realistische Fristen

Zwei Teams, dieselbe Aufgabe, zwei Terminpläne, die zum Verwechseln ähnlich aussehen: gleiche Laufzeit, gleiche Zahl an Meilensteinen, gleiches Tool. Vierzehn Wochen später hält nur eines der beiden Projekte seine Frist. Der Unterschied lag weder in der Software noch im Einsatz der Beteiligten, sondern in dem, was geschah, bevor das jeweilige Team seinen Projektzeitplan erstellen konnte: Das eine hat geplant, das andere nur Termine verteilt.

Diese Szene wiederholt sich in Agenturen, IT-Abteilungen und Fertigungsbetrieben gleichermaßen. Ein Wunschtermin steht im Raum, der Kalender ist offen, und an einem Nachmittag entsteht ein Plan, der ordentlich aussieht und trotzdem auf Sand gebaut ist. Termine einzutragen, geht schnell. Ob sie halten, hängt von Fragen ab, die zu diesem Zeitpunkt noch niemand gestellt hat.

Einen Projektzeitplan erstellen heißt, die für die Durchführung relevanten Aufgaben und Arbeitspakete mit Dauer, Reihenfolge und Verantwortlichen zu versehen und daraus verbindliche Termine abzuleiten; das Ergebnis wird auch Terminplan oder Projektterminplan genannt. Er eignet sich für Projektleiter und Teams, die ein Vorhaben mit festem Endtermin über Wochen oder Monate steuern. Sinnvoll wird er in dem Moment, in dem Ziele und Umfang eines Projekts geklärt sind und daraus ein überprüfbarer Fahrplan werden soll. Ein sauber aufgebauter Zeitplan liefert drei Dinge: Fristen, an denen sich alle Beteiligten messen lassen können, frühe Warnsignale bei Verzug und eine gemeinsame Sicht darauf, wer wann was erledigt.

Der rote Faden dieses Artikels ist ein durchgerechnetes Beispielprojekt: ein Kundenportal für einen Maschinenbaubetrieb, das wir einmal nur terminieren und einmal vollständig planen - mit zwei sehr unterschiedlichen Ergebnissen. Unterwegs zeigt sich, warum Projektplanung und Terminplanung zwei getrennte Arbeitsschritte sind und wie aus einem Projektplan Fristen entstehen, die auch Abweichungen und Störungen im Projektalltag besser standhalten. Die Aufgaben- und Projektfunktionen von Bitrix24 mit Gantt-Ansicht, Abhängigkeiten, Meilensteinen und Aufwandserfassung dienen dabei als praktisches Beispiel für die Umsetzung.

Warum ein Terminplan noch kein Projektplan ist

Beide Begriffe werden im Alltag so selbstverständlich miteinander vermischt, dass der Unterschied kaum noch auffällt. Unter Terminplanung im Projektmanagement versteht man den Arbeitsschritt, der Aufgaben in eine zeitliche Reihenfolge bringt, ihre Dauer und Abhängigkeiten berücksichtigt, Verantwortliche beziehungsweise Ressourcen zuordnet und ihnen Anfangs- und Endtermine zuweist. Sie ist ein Teil der Projektplanung, nicht ihr Ersatz. Wer einen Projektplan erstellen will, beantwortet zuerst die Fragen nach Zielen, Umfang, Ressourcen, Risiken und Abhängigkeiten - und erst auf dieser Grundlage bekommen Termine ein Fundament.

Die typische Verwechslung sieht so aus: Die Geschäftsführung fragt: „Wann seid ihr fertig?“, und der Projektleiter öffnet das Planungstool, statt zuerst ein Blatt Papier zu nehmen. Er zieht Balken über zwölf Wochen, verteilt Namen und verschickt das Ergebnis als „Projektplan“. Formal sieht das Dokument aus wie ein Plan. Inhaltlich ist es eine Sammlung von Hoffnungen mit Datumsangaben.

Die Folgen zeigen sich zeitversetzt, dafür aber zuverlässig. Termine ohne geprüfte Grundlage werden intern schnell als Fiktion erkannt, und ab diesem Moment verliert der Plan seine Steuerungswirkung. Wer weiß, dass die Frist gewürfelt wurde, richtet seine Arbeit nicht danach aus. Einzelne bauen stille Reserven in ihre Zusagen ein, andere ignorieren den Plan komplett, und bei der ersten Verschiebung pflegt ihn niemand mehr weiter. Das Dokument existiert dann noch, gesteuert wird das Projekt aber nur noch über Zuruf.

Der Terminplan steht also nicht am Anfang der Planung, sondern baut auf mehreren vorgelagerten Entscheidungen auf. Welche das sind, klärt der nächste Abschnitt.

Was eine echte Projektplanung vor dem ersten Datum klärt

Bevor das erste Datum in den Kalender wandert, braucht das Projekt Antworten auf sechs Fragen. Sie bilden zusammen den Projektplan - das Dokument, aus dem später der Zeitplan abgeleitet wird. Als Checkliste sieht das so aus:

• Ziele: Woran erkennen Auftraggeber und Team am Ende, dass das Projekt gelungen ist? Ein messbares Ziel („Kunden rufen Auftragsstatus und Dokumente selbst ab, das Service-Team spart sich Rückfragen per Telefon“) trägt weiter als ein vages Ziel („modernes Portal“).
• Projektumfang festlegen: Was gehört ausdrücklich ins Projekt, was ausdrücklich nicht? Die Abgrenzung nach außen verhindert später den schleichenden Zuwachs an Wünschen.
• Ressourcen: Wer arbeitet mit, und mit wie viel realer Verfügbarkeit? Eine Entwicklerin mit 60 Prozent Projektanteil liefert in vier Wochen zwölf Arbeitstage, nicht zwanzig.
• Risiken: Was kann das Projekt bremsen - der Urlaub eines Schlüsselansprechpartners, eine unklare Schnittstelle, eine ausstehende Freigabe? Benannte Risiken lassen sich durch Puffer und einen Plan B abfedern, unbenannte nicht.
• Abhängigkeiten: Welche Aufgaben warten aufeinander, welche Zulieferungen kommen von außen? Abhängigkeiten zwischen Aufgaben bestimmen später die Reihenfolge im Zeitplan.
• Projektphasen: Welche groben Etappen strukturieren das Vorhaben, etwa Konzept, Umsetzung, Test und Einführung? Phasen geben dem Projekt Kontrollpunkte, an denen Kurskorrekturen möglich sind.

Der Aufwand dafür ist überschaubar. Für ein Projekt von drei bis vier Monaten reichen erfahrungsgemäß drei bis fünf Arbeitstage Planung, verteilt auf einen Workshop mit den Beteiligten und etwas Schreibtischarbeit. Gemessen an der Laufzeit sind das wenige Prozent, gemessen an dem, was eine geplatzte Frist kostet, fast nichts.

Mit diesen sechs Antworten in der Hand verwandelt sich die Terminplanung von einem Ratespiel in eine Rechenaufgabe. Wie groß der Unterschied in der Praxis ausfällt, zeigt das Beispielprojekt im nächsten Abschnitt.

Werkzeugkasten: Leistungsumfang in realistische Fristen übersetzen

Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten

Ich bestätige hiermit, dass ich die Bedingungen der Datenschutzpolitik von Bitrix24 vollständig gelesen und verstanden habe.

Das Beispielprojekt: einmal nur terminiert, einmal vollständig geplant

Das Szenario: Ein Maschinenbaubetrieb mit 120 Mitarbeitenden will ein Kundenportal einführen. Kunden sollen den Auftragsstatus einsehen, Serviceanfragen stellen und technische Dokumente herunterladen können. Das Team besteht aus zwei Entwicklern (einer davon zu 60 Prozent verfügbar), einer Designerin und einem Projektleiter. Die Geschäftsführung wünscht den Start zur Herbstmesse in 14 Wochen. Dasselbe Projekt, dieselben Menschen - zwei Vorgehensweisen.

Variante A: Der Projektleiter terminiert sofort

Am Nachmittag nach dem Kick-off öffnet der Projektleiter sein Planungstool und rechnet rückwärts vom Messetermin: drei Wochen Design, sechs Wochen Entwicklung, zwei Wochen Test, zwei Wochen Korrekturen und Go-live-Vorbereitung. Macht 13 Wochen, eine Woche Luft, der Plan geht an alle. Niemand hat gefragt, was genau entwickelt wird, wer wann wirklich verfügbar ist und wovon die Aufgaben abhängen.

Die Realität meldet sich in Woche zwei. Beim ersten Fachgespräch stellt sich heraus, dass der Auftragsstatus live aus dem ERP-System kommen muss - eine Schnittstelle, die im Plan schlicht nicht vorkommt und allein zwölf Personentage kostet. Die Designerin steckt parallel in einem zweiten Projekt und liefert statt in drei Wochen erst nach fünf Wochen. Der Entwickler mit 60 Prozent Verfügbarkeit schafft pro Woche drei Projekttage, gerechnet wurde stillschweigend mit fünf. Die Freigabe des Designs durch die Geschäftsführung dauert acht Arbeitstage statt der erhofften zwei. Jede dieser Überraschungen verschiebt alles Nachfolgende. Das Portal geht in Woche 19 live, fünf Wochen nach der Messe, auf der es Kunden hätte überzeugen sollen.

Variante B: Erst planen, dann terminieren

Im zweiten Durchlauf nimmt sich derselbe Projektleiter fünf Arbeitstage für die Planung, denn er will den Projektzeitplan erst erstellen, wenn Umfang und Aufwände feststehen. Ein halbtägiger Workshop mit Vertrieb, Service und IT klärt den Umfang: Auftragsstatus, Serviceanfragen und Dokumenten-Download gehören hinein, das zusätzlich gewünschte Rechnungsarchiv wandert bewusst in eine zweite Ausbaustufe. Dabei fällt die ERP-Schnittstelle sofort auf, weil jemand aus der IT am Tisch sitzt und die Frage nach der Datenquelle in zwei Minuten stellt.

Danach folgt die Aufwandsschätzung je Arbeitspaket, abgegeben von den Personen, die die Arbeit ausführen werden: 18 Personentage Design, 36 Personentage Portalentwicklung, 12 Personentage ERP-Schnittstelle, 10 Personentage Test - zusammen 76 Personentage. Auf Grundlage der tatsächlichen Verfügbarkeiten (ein Entwickler voll, einer mit drei Tagen pro Woche, die Designerin mit halber Kapazität) ergibt sich eine Laufzeit von 15 Wochen ohne jede Reserve. Der Projektleiter weist zwei Wochen Puffer aus und landet bei 17 Wochen - drei mehr, als bis zur Messe zur Verfügung stehen.

Jetzt passiert das Wertvollste an der ganzen Übung: Die Diskussion über den Termin findet vor dem Projekt statt, nicht in Woche zwölf. Geschäftsführung und Projektleiter verschieben gemeinsam die Funktion für Serviceanfragen in die zweite Ausbaustufe; zur Messe starten Auftragsstatus und Dokumenten-Download. Der reduzierte Umfang von 64 Personentagen ergibt rechnerisch zwölf Wochen plus zwei Wochen Puffer - Woche 14, exakt zur Messe, mit einer Zusage, die auf belastbaren Zahlen beruht. Als der ERP-Ansprechpartner wie im Risikoregister festgehalten für zwei Wochen in Urlaub geht, kostet das vier Tage aus dem Puffer, mehr nicht.

Der direkte Vergleich macht den Unterschied greifbar:

Bemerkenswert ist, was die Tabelle nicht zeigt: Variante B war zu keinem Zeitpunkt langsamer. Dieselben Menschen haben dieselbe Arbeit erledigt. Der Unterschied besteht darin, dass unangenehme Wahrheiten - Schnittstelle, Verfügbarkeiten, Umfang - in Variante B vor der Terminzusage auf dem Tisch lagen und in Variante A erst danach. Wer einen Projektzeitplan erstellen möchte, der solchen Wahrheiten standhält, braucht zuvor eine fundierte Planung.

Vom Projektplan zum Zeitplan: fünf Schritte zu realistischen Fristen

Aus dem Beispiel lässt sich der Weg verallgemeinern. Wenn Sie auf Basis eines fertigen Projektplans einen Projektzeitplan erstellen, führen fünf Schritte von der groben Struktur zu belastbaren Terminen.

Schritt 1: Arbeitspakete aus dem Umfang ableiten

Zerlegen Sie den festgelegten Umfang in Pakete mit einer Größe von etwa drei bis zehn Arbeitstagen. Kleinere Einheiten erzeugen Verwaltungsaufwand, größere verstecken Verzug: Ein Paket über sechs Wochen kann fünf Wochen lang „im Plan“ wirken und in der letzten Woche kippen. Bei handlichen Paketen fällt eine Abweichung nach Tagen auf, nicht nach Monaten.

Schritt 2: Aufwand schätzen, und zwar durch die Umsetzenden

Die Aufwandsschätzung gehört in die Hände derer, die die Arbeit später ausführen - der Projektleiter moderiert, schätzt aber nicht allein. Bewährt hat sich die Dreipunktschätzung je Paket: bester Fall, wahrscheinlicher Fall, schlechtester Fall. Liegen bester und schlechtester Fall weit auseinander, ist das ein Signal für ungeklärte Fragen im Paket. Wichtig bleibt die Trennung von Aufwand und Dauer: Zwölf Personentage Aufwand bedeuten bei einer Person mit drei Projekttagen pro Woche vier Kalenderwochen Dauer.

Schritt 3: Abhängigkeiten zwischen Aufgaben ordnen

Klären Sie für jedes Paket, worauf es wartet und welche Pakete auf sein Ergebnis warten. Aus diesen Abhängigkeiten zwischen Aufgaben entsteht die Reihenfolge - und damit der kritische Pfad: die Kette von Paketen, deren Verzögerung den Endtermin direkt verschiebt. Im Beispielprojekt läuft dieser Pfad über die ERP-Schnittstelle, weshalb sie so früh wie möglich eingeplant wird. Ein Gantt-Diagramm macht solche Ketten auf einen Blick sichtbar, dazu später mehr.

Schritt 4: Verfügbarkeiten gegenrechnen

An dieser Stelle beginnt die Ressourcenplanung im Projekt: Wer steht in welcher Woche mit wie vielen Tagen zur Verfügung? Rechnen Sie ehrlich - eine Vollzeitkraft kann nach Abzug von Meetings, Support und Tagesgeschäft selten mehr als vier produktive Projekttage pro Woche einbringen; Urlaub und Feiertage kommen noch dazu. Der Abgleich von Aufwand und Verfügbarkeit verwandelt Personentage in Kalenderwochen und deckt Engpässe auf, etwa zwei Pakete, die in derselben Woche dieselbe Person brauchen.

Schritt 5: Meilensteine definieren und realistische Deadlines setzen

Zum Schluss setzen Sie Kontrollpunkte. Meilensteine definieren Sie an den Übergängen zwischen Projektphasen, jeweils mit einem prüfbaren Kriterium: „Design freigegeben“ statt „Design fertig“. Erst jetzt lassen sich realistische Deadlines setzen, denn jede Frist stützt sich nun auf geschätzten Aufwand, geklärte Reihenfolge und reale Verfügbarkeit. Ein Termin, der diese drei Prüfungen bestanden hat, lässt sich auch gegenüber der Geschäftsführung verteidigen.

Nach diesen fünf Schritten steht ein Zeitplan, der Auskunft geben kann - aber noch kein Zeitplan, der Störungen aushält. Dafür fehlen zwei Stellschrauben.

"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht."

Geschäftsführer, Alexander Dortmann

DortmannKids

KOSTENFREI STARTEN

Pufferzeiten und Abhängigkeiten: die Stellschrauben für belastbare Termine

Kein Projekt läuft exakt wie geschätzt, und genau dafür gibt es Reserven. Wer Pufferzeiten einplanen will, steht vor zwei Fragen: wie viel und wo. Bei der Menge hilft ein Blick auf die Unsicherheit der Schätzung. Für Aufgaben, die das Team in ähnlicher Form schon mehrfach erledigt hat, genügt ein kleiner Aufschlag von rund zehn Prozent. Für Neuland wie die ERP-Schnittstelle im Beispiel darf der Puffer ein Viertel bis ein Drittel der geschätzten Dauer betragen, weil dort der beste und der schlechteste Fall der Dreipunktschätzung am weitesten auseinanderlagen.

Beim Wo gilt: Sammelpuffer schlagen Einzelpuffer. Wird jede Aufgabe einzeln gepolstert, verschwindet die Reserve unbemerkt, denn Arbeit dehnt sich erfahrungsgemäß auf die Zeit aus, die zur Verfügung steht. Sinnvoller ist ein sichtbarer Block vor jedem Meilenstein und ein größerer vor dem Endtermin. So bleibt nachvollziehbar, wie viel Reserve das Projekt schon verbraucht hat: Sind nach der Hälfte der Laufzeit bereits drei Viertel des Puffers aufgebraucht, ist das ein Frühwarnsignal, lange bevor der Endtermin wackelt.

Die zweite Stellschraube sind die Abhängigkeiten selbst. Interne Abhängigkeiten lassen sich gestalten: Manche Aufgaben, die scheinbar aufeinander warten, können teilweise parallel laufen, etwa das Schreiben von Testfällen, während die Entwicklung noch andauert. Externe Abhängigkeiten - Freigaben, Zulieferungen, Dienstleister - verdienen dagegen besondere Vorsicht, denn auf ihre Dauer haben Sie wenig Einfluss. Für die Designfreigabe im Beispielprojekt wurde deshalb vorab ein festes Zeitfenster von drei Arbeitstagen mit der Geschäftsführung vereinbart, statt auf eine schnelle Antwort zu hoffen.

Wann selbst der beste Projektzeitplan an seine Grenzen stößt

So sorgfältig ein Zeitplan auch erstellt sein mag, drei Situationen bringen ihn immer wieder an seine Grenzen - und alle drei verlangen eher Haltung als Technik.

Externe Abhängigkeiten stehen dabei an erster Stelle. Eine behördliche Genehmigung, die Zulieferung eines Partners oder das Feedback eines Kunden richten sich nicht nach dem eigenen Zeitplan, egal wie sauber er durchgerechnet ist. Puffer mildern die Wirkung, ersetzen aber keine aktive Nachverfolgung: Wer den Genehmigungsantrag in Woche eins stellt statt in Woche sechs und mit dem Zulieferer feste Liefertermine schriftlich vereinbart, verwandelt einen unkontrollierbaren Faktor wenigstens in einen beobachtbaren.

Scope-Änderungen sind die zweite Bruchstelle. Kommt mitten im Projekt eine neue Anforderung dazu, hilft nur eine feste Regel: Jede Änderung durchläuft dieselbe Rechnung wie die ursprünglichen Pakete - Aufwand schätzen, Auswirkungen auf den kritischen Pfad prüfen, dann bewusst tauschen. Entweder verlässt etwas anderes den Umfang, der Termin verschiebt sich, oder das Team wird verstärkt. Das beiläufige „Das nehmen wir noch mit“ ist die höfliche Formulierung für eine Terminverschiebung, die niemand ausgesprochen hat.

Bleibt die laufende Neubewertung. Ein Zeitplan ist eine Momentaufnahme mit Verfallsdatum, und je unsicherer das Vorhaben, desto kürzer ist seine Gültigkeit. Für Projekte mit hohem Neuigkeitsgrad - ein Produkt, das es so noch nie gab, eine Technologie, die das Team zum ersten Mal einsetzt - lohnt sich eine rollierende Planung: Nur die nächste Phase wird im Detail terminiert, alles danach bleibt bewusst grob und bekommt erst dann feste Termine, wenn die Erkenntnisse aus der laufenden Phase vorliegen. Das ist kein Eingeständnis schlechter Planung, sondern ihre ehrlichste Form.

So hilft Bitrix24, wenn Sie einen Projektzeitplan erstellen

Spätestens bei der wöchentlichen Pflege zeigt sich, ob ein Plan lebt oder nur abgelegt wurde. Die fünf Schritte aus diesem Artikel lassen sich in Bitrix24 mit den Funktionen für Aufgaben und Projekte abbilden: Arbeitspakete werden zu Aufgaben und Teilaufgaben mit Verantwortlichen, geplantem Aufwand und Fristen, während die Gantt-Ansicht die Aufgaben als Balken auf der Zeitachse darstellt. Der Plan aus dem Workshop wird damit zu einem lebenden Dokument und nicht zu einer Excel-Datei, die im Archiv verschwindet.

Aufgabenabhängigkeiten verknüpfen die Pakete untereinander: Verschiebt sich die ERP-Schnittstelle aus dem Beispiel um drei Tage, ändern sich auch die Termine der entsprechend verknüpften Aufgaben, sodass die Auswirkungen auf den weiteren Zeitplan sofort sichtbar werden. Wichtige Kontrollpunkte lassen sich als entsprechend benannte Aufgaben oder Zwischenergebnisse abbilden. Über die Zeiterfassung in den Aufgaben hält das Team fest, wie viel Zeit tatsächlich in jedes Paket geflossen ist. Der Vergleich mit dem geplanten Aufwand liefert eine bessere Grundlage für künftige Schätzungen.

Für das Kundenportal aus dem Beispiel sähe das so aus: rund ein Dutzend miteinander verknüpfte Aufgaben mit zusammen 64 Personentagen für den beschlossenen Kernumfang, vier als Aufgaben oder Zwischenergebnisse angelegte Kontrollpunkte von „Umfang freigegeben“ bis „Go-live“ und sichtbar eingeplante Zeitpuffer vor den entscheidenden Übergängen. Beim wöchentlichen Blick auf die Gantt-Ansicht erkennt der Projektleiter in wenigen Minuten, ob sich Verzögerungen entlang der entscheidenden Aufgabenkette auf den Endtermin auswirken.

Wenn Sie Ihren nächsten Projektzeitplan erstellen und dabei Aufgaben, Abhängigkeiten und Termine an einem Ort bündeln möchten, legen Sie ein kostenloses Bitrix24-Konto an und bilden Sie Ihr Projekt in der Gantt-Ansicht ab - mit weiteren Funktionen für die Planung, Zusammenarbeit und Steuerung Ihrer Projekte.

FAQ