IT-Projekte scheitern häufiger als jede andere Art – meist, weil der Umfang unklar ist, Abhängigkeiten übersehen werden oder die Kommunikation schwach ist. Mit Trupeer können Sie Stunden bei der Planung sparen, indem Sie mit einer kostenlosen IT-Projektplan-Vorlage starten, sie mit Ihrer Brand Identity anpassen und den Plan in Video-Updates umwandeln, die technische und geschäftliche Stakeholder auf einer Linie halten.

Was ein IT-Projektplan ist und warum generische Vorlagen danebenliegen

Ein Projektplan ist das Dokument, das festlegt, was geliefert wird, bis wann, von wem und was dafür wahr sein muss, damit das geschieht. Jede Vorlage, die für diese Suche in den Rankings auftaucht, liefert Ihnen das – meist als Aufgabenliste mit Startdaten, Enddaten, Verantwortlichen und einer Gantt-Leiste.

Die Aufgabenliste ist nicht das Problem. Das Problem ist die Reihenfolge, in der Sie sie ausfüllen.

Generische Vorlagen beginnen mit Ihrer Arbeit. Listen Sie die Aufgaben auf, schätzen Sie die Dauer, ordnen Sie sie in eine Sequenz ein, fügen Sie Verantwortliche hinzu – und das Enddatum fällt unten heraus. Abhängigkeiten werden danach ergänzt, in einer Spalte, als Notiz.

IT-Projekte rutschen selten deshalb nach hinten, weil diese Schätzungen falsch waren. Sie rutschen nach hinten, weil etwas eintrifft, das nie im Plan stand und sich nicht wegdiskutieren lässt: ein Change-Freeze, der die Go-Live-Woche abdeckt, eine Security-Review mit einer sechs Wochen langen Warteschlange, ein Vendor, dessen Implementierungsberater bis zum Ende des Quartals ausgebucht sind, eine Lizenz, die sich erneuert, bevor der Ersatz bereit ist, oder ein Audit, das die Umgebung für einen Monat sperrt.

Keines davon sind Risiken. Ein Risiko ist etwas, das möglicherweise passiert. Das sind Dinge, die am Tag Ihres Planungsstarts bereits wahr sind – und jedes davon ist in der ersten Woche erkennbar, wenn jemand danach fragt.

Diese Vorlage dreht also die Reihenfolge um. Zuerst zeichnen Sie die Daten ein, die Sie nicht verschieben können. Dann stellen Sie fest, wie groß das verbleibende Zeitfenster tatsächlich ist. Danach planen Sie die Arbeit darin ein. Die Aufgabenliste existiert weiterhin – sie ist nur nicht mehr das Erste, was Sie schreiben.

So passen Sie diese Vorlage in Trupeer an

Schritt 1: Öffnen Sie den Bereich „Vorlagen“

Gehen Sie im Hauptmenü zum Bereich „Vorlagen“.

Schritt 2: Wählen und öffnen Sie eine Vorlage

Klicken Sie auf eine beliebige Vorlage, mit der Sie arbeiten möchten, um sie zu öffnen.

Schritt 3: Erweitern Sie die Vorlagenansicht

Falls nötig, erweitern Sie die Vorlagenansicht, um das vollständige Layout und die Details klar zu sehen.

Schritt 4: Bearbeiten Sie die Vorlage

Klicken Sie auf „Bearbeiten“, um mit der Anpassung der ausgewählten Vorlage zu beginnen.

Im Editor können Sie:

• Neue Abschnitte hinzufügen

• Formatierungsregeln definieren oder aktualisieren

• Ein Logo hinzufügen und seine Position sowie die zugehörigen Einstellungen anpassen

Schritt 5: Speichern Sie Ihre angepasste Vorlage

Nachdem Sie alle notwendigen Änderungen vorgenommen haben, klicken Sie auf „Speichern“, um die aktualisierte Vorlage als Ihre eigene zu sichern.

Schritt 6: Vorschau ansehen und die Vorlage feinjustieren

Wenn Sie sehen möchten, wie Ihre angepasste Vorlage aussieht, öffnen Sie die Vorschau.

Ausgehend vom Vorschau-Bildschirm können Sie bei Bedarf weiterhin direkt Anpassungen vornehmen – damit die Vorlage genau so erscheint, wie Sie es möchten.

Mit einer IT-Projektplan-Vorlage können Sie:

• Stunden bei der Planung sparen: Überspringen Sie die leere Seite mit einer Struktur, die für IT-Initiativen gebaut ist.

• Technische Komplexität steuern: Integrierte Abschnitte für Architektur, Abhängigkeiten und Risiken.

• Im Brand bleiben: Nutzen Sie Ihr Logo, Ihre Schriftarten und Farben mit Trupeer’s Brand Kit.

• Business und IT ausrichten: Wandeln Sie technische Pläne in Video-Updates um, die geschäftliche Stakeholder verstehen können.

• Projekte standardisieren: Verwenden Sie für jede IT-Initiative dieselbe Vorlage.

• Globale Teams erreichen: Übersetzen Sie Pläne und Updates mit einem Klick in 65+ Sprachen.

Die Unverschiebbaren – und wo Sie sie finden

Ein Unverschiebbares ist jedes Datum oder jede Dauer, die von jemandem festgelegt wird, der nicht dem Projektbericht unterstellt ist. Sie können es innerhalb des Projekts nicht verhandeln – und wenn Sie es zu spät entdecken, verwandelt es sich von einer Einschränkung in eine Krise.

Hier ist das Inventar, das Sie in Woche eins abarbeiten. Stellen Sie jedem Verantwortlichen zwei Fragen: Was ist Ihr Datum, und wie lange ist Ihre Vorlaufzeit?

Zwei davon verdienen besondere Aufmerksamkeit, weil sie am häufigsten übersehen werden. Ankündigungsfristen in Verträgen sind Unverschiebbare Daten, die vor dem Verlängerungsdatum liegen – das bedeutet, dass die echte Deadline früher ist als die im Kalender. Und Datenqualität im Quellsystem ist der einzige Unverschiebbare, dessen Umfang man nicht nachschlagen kann. Sie müssen ihn messen – deshalb gehört das Profiling der Quelldaten in Woche eins, statt in die Migrationsphase.

Zeichnen Sie diese auf einem einzigen Kalender ein, bevor Sie irgendetwas schätzen. Wonach Sie suchen, ist die Form der Lücke. Sehr oft ist die Lücke viel schmaler als die Projektdauer – und das ehrliche Gespräch über den Umfang findet in Woche zwei statt in Monat sieben statt.

Was in den Plan gehört

Sobald die Unverschiebbaren eingezeichnet sind, hat der Plan selbst zwölf Abschnitte. Kopieren Sie die Überschriften und füllen Sie sie in dieser Reihenfolge aus.

1. Zusammenfassung. Ein Satz: Was ändert sich, für wen, und was danach nicht mehr zutrifft.

2. Ergebnis und Erfolgskriterien. Messbar und datiert. Fügen Sie mindestens ein Kriterium zur ersetzten Sache hinzu, zum Beispiel: Das Legacy-System hat bis zu einem festgelegten Datum keinen Traffic und keine Lizenzkosten. Pläne, die beim Go-Live enden, sind der Grund, warum Unternehmen am Ende für zwei Systeme bezahlen.

3. Einschränkungs-Kalender. Die Tabelle der Unverschiebbaren oben ausfüllen – und das daraus resultierende Lieferfenster als Datumsbereich in Klartext angeben.

4. Umfang. Drei Listen: „In“, „Out“ und „Deferred“. Die „Deferred“-Liste ist die nützliche, denn dort landet der Umfang, wenn er gekürzt wird – und damit endet das gleiche Gespräch nicht viermal.

5. Phasen und Meilensteine. Meilensteine sind Ereignisse mit einer beobachtbaren Antwort, zum Beispiel „Security-Review bestanden“ oder „erstes Store-Live“, nicht „Design-Phase abgeschlossen“.

6. Work Breakdown. Aufgaben, Verantwortliche, Schätzungen, Sequenz. Das ist der Teil, mit dem jede andere Vorlage beginnt.

7. Abhängigkeiten. Teilen Sie intern von extern. Jede externe Abhängigkeit bekommt eine namentlich benannte Person beim anderen Unternehmen und ein Datum, auf das sie sich geeinigt haben – nicht ein Datum, das Sie angenommen haben.

8. Umgebungen und Daten. Welche Umgebungen existieren, welche Daten in jeder enthalten sind, wie Produktionsdaten im Test geschützt werden, und das Ergebnis des Profilings der Quelldaten.

9. Cutover und Rollback. Die stündliche Abfolge für den Wechsel, der Entscheidungspunkt, an dem Sie stoppen, wer diese Entscheidung trifft, und wie Sie zurückkommen. Schreiben Sie das als ausführbares Verfahren auf – hier gehört eine Method-of-Procedure-Vorlage hinein.

10. Risiken mit Auslösern. Keine Wahrscheinlichkeit- und Impact-Matrix. Jedes Risiko bekommt einen beobachtbaren Auslöser und die Aktion, die feuert, wenn der Auslöser gesehen wird. „Vendor-Berater bis zum 12. Mai nicht bestätigt“ ist ein Auslöser. „Vendor könnte spät sein“ ist keiner.

11. Kommunikation, Training und Adoption. Wer wird wann informiert – und was von den Nutzern am ersten Tag erwartet wird, dass sie es können.

12. Governance und Abschluss. Wer entscheidet, wer eskaliert, wie ein Decision Record aussieht, und unter welchen Bedingungen das Projekt als abgeschlossen gilt und an den Run übergeben wird.

Ein ausgearbeitetes Beispiel – und was es gekostet hat

Ashmore Retail, 84 Stores und drei Distributionszentren, plante im Februar den Austausch des Warehouse-Management-Systems in allen drei DCs. Neun Monate Arbeit, Go-Live für Mitte November geplant, im Kickoff-Deck als „komfortabel vor dem Peak“ beschrieben.

Am Tag dieses Kickoffs gab es zwei Unverschiebbare. Beide waren veröffentlicht. Keine davon stand im Plan.

Das erste war der Change-Freeze. Retail Operations veröffentlicht ihn jeden Januar und er läuft vom 1. November bis zum 15. Januar – inklusive Peak Trading. Während dieser elf Wochen kommt keine Produktion-Änderung irgendeiner Art hinein.

Das zweite war der Legacy-Vertrag. Er verlängerte sich am 31. Dezember um weitere zwölf Monate für 186.000 Pfund, wobei eine Kündigungsfrist von 90 Tagen erforderlich war – das setzte die echte Deadline auf den 2. Oktober.

Das Projekt lief über den Frühling hinweg nach Plan. Die Security-Review dauerte vier Wochen bei einem angegebenen SLA von zwei. Die Implementierungsberater des Vendors waren erst ab Oktober verfügbar, weil sie im Juli angefragt worden waren. Beide Verzögerungen wurden aufgefangen, indem der Go-Live von Mitte November auf Ende November verschoben wurde – das hat niemand bemerkt, weil niemand auf den Freeze-Kalender geschaut hat.

Der Freeze tauchte in einem Change Advisory Board Meeting Anfang September auf. Ein Go-Live im November war nicht möglich, und das nächste nutzbare Zeitfenster öffnete sich am 16. Januar.

Damit blieb bis zum 2. Oktober nur eine Entscheidung: Entweder kündigen Sie den Legacy-Vertrag und starten ab dem 1. Januar ohne Support für das System, von dem das gesamte Business abhängig war – oder Sie verlängern ihn und zahlen ein Jahr für ein System, das sie im November ohnehin abschalten wollten.

Sie ließen ihn verlängern. Das neue System ging am 4. März live. Der Legacy-Vertrag wurde für neun Wochen von seinem 52-Wochen-Zeitraum genutzt – das entspricht etwa 32.000 Pfund Wert gegenüber einer Rechnung von 186.000 Pfund. Ungefähr 154.000 Pfund kauften nichts.

Das Lehrreiche daran ist: Das Projekt war nie „zu spät“ im Sinne dessen, wie Menschen „late“ meinen. Die Arbeit wurde in einem angemessenen Standard und in einem angemessenen Tempo erledigt. Was schiefging, ist, dass das Zeitfenster sechs Wochen schmaler war als es irgendjemand eingezeichnet hatte – und die beiden Daten, die es definierten, standen seit vor dem Projektstart in einem veröffentlichten Kalender und in einem unterschriebenen Vertrag.

Hätte man den Einschränkungs-Kalender im Februar eingezeichnet, wäre die Reihenfolge offensichtlich gewesen. Go-Live vor dem 1. November, zurückgerechnet über eine vierwöchige Security-Review, die in Wahrheit sechs Wochen waren, eine sechs Wochen lange Beschaffung und Berater, die ein Quartal Vorlauf brauchten – das bedeutete, dass der Vendor-Vertrag bis Mitte April unterschrieben sein musste. Unterschrieben wurde er im Juli. Das Projekt musste nicht schneller laufen. Es musste seine Unverschiebbaren Abhängigkeiten elf Wochen früher starten.

Fünf Formen von IT-Projekten – und welche Abschnitte die Hauptlast tragen

Listen mit zwanzig IT-Projektvorlagen sind in dieser Suche üblich – von ITSM-Implementierung bis zu Infrastruktur-Upgrades und dem Aufbau eines PMO. In der Praxis fallen sie auf fünf Formen zusammen, und die Form sagt Ihnen, welche der Abschnitte oben die nötigen Details tragen.

Replacement. Ein laufendes System gegen ein anderes austauschen. Umfasst WMS, ERP, ITSM-Tools, Help-Desk-Plattformen, HR-Systeme. Abschnitte 3, 9 und 2 tragen die Hauptlast, weil die harten Teile das Zeitfenster, das Cutover und der Nachweis sind, dass das alte System tatsächlich aus ist.

Implementation. Etwas Neues ohne Vorgänger. Umfasst SLA-Management, IT-Governance- und Compliance-Programme, Asset Management, Knowledge Management. Abschnitte 11 und 2 tragen die Hauptlast, weil vorher nichts kaputt war – daher macht erst die Adoption es wirklich. Unser digital adoption implementation guide geht hier tiefer hinein.

Migration oder Upgrade „in place“. Dasselbe System, neue Version, neuer Host oder neue Region. Umfasst Virtualisierung, Konsolidierung, Cloud-Migration, Datenbank-Upgrades. Abschnitte 8 und 9 tragen die Hauptlast, weil Rollback das ganze Spiel ist.

Build. Softwareentwicklung und Prozessautomatisierung. Abschnitt 4 trägt die Hauptlast, weil der Umfang die Variable ist, die sich bewegt, und die Akzeptanzkriterien das sind, was verhindert, dass er leise weiterwandert.

Programm und Assurance. Aufbau eines PMO, IT-Audits, Portfolio Management, Risk Management, Security-Compliance. Abschnitt 12 trägt die Hauptlast, weil das Deliverable ein Nachweis und ein Sign-off ist – nicht ein laufendes System – und die Meilensteine Review-Daten sind, die von jemand anderem festgelegt werden.

Wenn Ihr Projekt nicht sauber in eine dieser Formen passt, sind es in der Regel zwei Projekte, die unter einem Namen zusammengefasst wurden.

Den Plan an einem Tag erstellen

Am Morgen: Zeichnen Sie die Unverschiebbaren ein. Senden Sie die zwei Fragen an jeden Verantwortlichen in der Tabelle, holen Sie zuerst die Antworten von Vendor und Security ein, weil diese die längsten Nachläufe haben, und tragen Sie jedes Datum, das Sie zurückbekommen, in einen einzigen Kalender ein. Formulieren Sie das resultierende Zeitfenster in einem Satz.

Am Nachmittag: Schreiben Sie die Abschnitte 1, 2 und 4, dann die Meilensteine. Lassen Sie die detaillierte Work-Breakdown-Arbeit für das Delivery-Team, die es in der Woche ausfüllt. Ein Plan ist sofort nützlich, sobald Zeitfenster und Umfang vereinbart sind – und er wird nicht dadurch nützlicher, dass er vierhundert Zeilen enthält.

Überprüfen Sie ihn bei jedem Governance-Meeting gegen das Zeitfenster. Die eine Frage, die sich lohnt, ist nicht „Sind wir im Plan?“, sondern „Hat sich ein Unverschiebbares bewegt?“. Freezes werden verlängert, Audits werden neu terminiert, und Vendors verlieren Berater. Diese Änderungen formen den Plan so um, wie es eine verschobene Aufgabe nie tut.

Was Sie weglassen sollten

Eine Gantt-Übersicht für jede einzelne Aufgabe gehört nicht in das Plan-Dokument. Sie gehört in das Tool, mit dem Sie planen, und wenn Sie sie in ein Dokument duplizieren, entstehen zwei Versionen, die sich innerhalb von zwei Wochen widersprechen.

Auch ein vollständiges Risikoregister mit Scores gehört hier nicht hin. Behalten Sie die Risiken mit Auslösern und Daten – und geben Sie den Rest ins Register.

Detaillierte Verfahren, wie die Arbeit erledigt wird, gehören in ein IT SOP, und die Beschreibung dessen, was Sie gebaut haben, gehört in IT documentation – nicht in den Plan. Eine Übergabe an das Run-Team lohnt sich, wenn sie richtig geplant wird – dafür ist ein knowledge transfer SOP da.

Wann Sie aufhören sollten, ein Dokument zu verwenden, und stattdessen Software nutzen

Ein Dokument ist das richtige Medium, solange über den Plan gestritten wird – das ist meistens der Großteil des ersten Monats. Es ist nicht mehr das richtige Medium, wenn drei Dinge gleichzeitig wahr werden: mehr als etwa dreißig Aufgaben sind live, mehr als vier Personen aktualisieren den Status, und Abhängigkeiten zwischen Aufgaben beginnen sich wöchentlich zu verändern.

An diesem Punkt verschieben Sie die Work Breakdown in Scheduling-Software und behalten das Dokument für die Abschnitte 1 bis 5 und 12, also die Teile, die von Menschen gelesen werden, die das Tool nie öffnen. Das Dokument hält die Vereinbarung fest. Das Tool hält den Zeitplan fest.

Den Plan in etwas verwandeln, dem das Delivery-Team wirklich folgt

Der Plan wird beim Kickoff und im Steering Meeting gelesen. Das Cutover-Runbook wird um zwei Uhr morgens von jemandem gelesen, der in keinem der Meetings dabei war.

Trupeer AI macht aus einer Bildschirmaufzeichnung einen dokumentierten Prozess, sodass die Cutover-Schritte in Abschnitt 9 und die Day-One-Aufgaben in Abschnitt 11 zu Walkthroughs Ihrer echten Systeme werden – statt zu Absätzen, die sie beschreiben. Zeichnen Sie die Abfolge einmal auf, und Sie erhalten eine Schritt-für-Schritt-Anleitung, ein Video und ein Dokument in Ihrer knowledge base – in Ihrem eigenen Branding.

Aufzeichnen. Brandmarken. Übersetzen. Trupeer-n.

Für die Adoption-Arbeit in Abschnitt 11 decken change management und training videos die Rollout-Seite ab, und documentation hält den Plan, das Runbook und das Übergabematerial zusammen. Setup-Anweisungen finden Sie in der document template setup guide.

Häufig gestellte Fragen

Gibt es eine kostenlose IT-Projektplan-Vorlage in Excel?

Nicht als Datei von uns – und es lohnt sich, das Thema offen anzusprechen. Excel ist tatsächlich der bessere Container für die Work Breakdown in Abschnitt 6, weil Daten, Abhängigkeiten und Rollups in Zellen gehören. Erstellen Sie dieses Sheet selbst mit Spalten für Aufgabe, Verantwortlicher, Start, Ende, Abhängigkeit, Status und Unverschiebbar-Flag. Behalten Sie die Abschnitte 1 bis 5, 9 und 12 als Dokument bei, weil dort über den Umfang in Fließtext gestritten wird und niemand den Umfang in einer Spreadsheet verhandelt.

Gibt es eine Word-Version oder einen kostenlosen Word-Download?

Die zwölf-Abschnitts-Struktur oben ist so geschrieben, dass Sie sie direkt in Word oder Google Docs kopieren können. Fügen Sie die Überschriften ein, behalten Sie die Nummerierung und füllen Sie sie in der angegebenen Reihenfolge aus. Es gibt keinen „Gated Download“ – das bedeutet auch, dass es kein Formular zwischen Ihnen und der Struktur gibt.

Gibt es eine PDF-Version?

Fügen Sie die Abschnitte in Ihren Editor ein und exportieren Sie sie als PDF, wenn der Plan vereinbart ist. Ein Plan ist es wert, als PDF an dem Punkt eingefroren zu werden, an dem er freigegeben wurde – und es lohnt sich, ihn davor editierbar zu halten. Daher ist es besser, Ihre eigene Kopie zum richtigen Zeitpunkt zu exportieren, statt von einer festen Datei auszugehen.

Gibt es eine PPT-Version für das Kickoff-Deck?

Das Deck ist ein anderes Dokument mit einer anderen Aufgabe. Sechs Slides sind normalerweise richtig: das Ergebnis, das Lieferfenster aus Ihrem Einschränkungs-Kalender, Umfang „in“ und „out“, Meilensteine, die benannten externen Abhängigkeiten und wer entscheidet was. Packen Sie die Work Breakdown nicht ins Deck. Niemand liest eine Gantt-Leiste auf einem Beamer.

Kann ich es kostenlos herunterladen?

Die Struktur, die Tabelle der Unverschiebbaren und das ausgearbeitete Beispiel sind kostenlos und ohne Einschränkungen. Nutzen Sie sie, bearbeiten Sie sie und legen Sie sie in Ihrer eigenen Template-Bibliothek unter Ihrem eigenen Namen ab.

Ist ein Projekt-Delivery-Plan das Gleiche wie ein Projektplan?

So nah beieinander, dass die Unterscheidung selten ihren Zweck erfüllt. Wenn Organisationen sie trennen, deckt der Projektplan das gesamte Leben des Projekts ab – einschließlich Business Case und Abschluss – und der Delivery-Plan deckt nur den Build- und Release-Teil ab. Wenn Ihre Governance beides verlangt, schreiben Sie den Plan oben und behandeln Sie die Abschnitte 5 bis 9 als Delivery-Plan.

Brauche ich zusätzlich eine separate Vorlage für Projektmanagement-Reports?

Ja – und halten Sie sie deutlich kürzer als Sie erwarten. Ein Statusbericht, der den Plan wiederholt, wird innerhalb eines Monats ignoriert. Berichten Sie vier Dinge: Hat sich ein Unverschiebbares bewegt? Ist das Zeitfenster noch breit genug? Welche Entscheidung brauchen Sie heute von dieser Gruppe? Und was wurde aus der Risikoliste seit dem letzten Mal ausgelöst?

Wie detailliert sollte ein IT-Projektplan sein?

Detailliert genug, dass ein neuer Einstieg weiß, was als Nächstes passiert – und nicht mehr. In der Praxis umfasst das Plan-Dokument für ein neunmonatiges Projekt etwa acht bis fünfzehn Seiten, wobei der Großteil aus den Abschnitten 8 und 9 besteht. Wenn das Dokument länger ist als das Cutover-Runbook, stimmt das Verhältnis nicht.

Wie oft sollte der Plan aktualisiert werden?

Die Abschnitte 6 und 7 ändern sich wöchentlich und gehören dorthin, wo Ihr Team ohnehin arbeitet. Die Abschnitte 1 bis 5 sollten selten geändert werden, und jede Änderung daran ist eine Entscheidung, die jemand genehmigen muss. Wenn Ihr Umfang-Abschnitt jede Woche still und leise bearbeitet wird, haben Sie keinen Plan – Sie haben ein Tagebuch.