Projektbrief: Was er ist und wie man einen schreibt
Ein Projektbrief ist ein kurzes, grundlegendes Dokument, das dein Team darauf ausrichtet, was ein Projekt ist, warum es existiert und wie ihr es umsetzen werdet, bevor ihr mit der Arbeit beginnt. Meiner Erfahrung nach ist das Überspringen eines solchen Dokuments eine der schnellsten Möglichkeiten, wie ein Projekt scheitert: Der Umfang wächst schleichend, Stakeholder ziehen in unterschiedliche Richtungen, und niemand kann sich darauf einigen, wie „fertig“ aussieht.
Dieser Leitfaden behandelt alles – von den Inhalten und der verantwortlichen Person bis hin zu häufigen Fehlern und dem richtigen Zeitpunkt für eine Aktualisierung. Außerdem gehe ich darauf ein, wie Projektmanagementsoftware das Erstellen und Teilen von Projektbriefs für verteilte Teams deutlich erleichtern kann.
Was ist ein Projektbrief?
Ein Projektbrief ist ein kurzes Dokument, das festlegt, was ein Projekt ist, warum es durchgeführt wird und wie ihr es umsetzen wollt. Es hält die wesentlichen Punkte fest: Ziele, Umfang, Zeitplan, Stakeholder und Budget – alles an einem Ort, bevor die Arbeit beginnt.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Er ist die zentrale Informationsquelle, auf die sich dein Team bezieht, wenn es eine Erinnerung daran braucht, wofür das Projekt tatsächlich gedacht ist.
Warum ein Projektbrief wichtig ist
Das leistet ein guter Projektbrief für dein Team:
- Richtet Stakeholder frühzeitig aus: Alle einigen sich darauf, wie Erfolg aussieht, bevor die Arbeit beginnt – nicht erst danach.
- Begrenzt den Umfang: Ein schriftlich festgehaltener und genehmigter Umfang bietet dir eine konkrete Grundlage, auf die du dich beziehen kannst, wenn die Anforderungen ausufern.
- Beschleunigt die Einarbeitung: Neue Teammitglieder erhalten schnell den nötigen Kontext, ohne an einem 30-minütigen Gespräch teilnehmen zu müssen.
- Reduziert Entscheidungsmüdigkeit: Wenn mitten im Projekt Abwägungen erforderlich werden, bietet der Projektbrief den Teams einen Rahmen für ihre Entscheidungen.
- Schafft Verantwortlichkeit: Benannte Verantwortliche und klar definierte Ergebnisse lassen weniger Raum für Unklarheiten darüber, wer wofür zuständig ist.
Ein Projektbrief verhindert die beiden häufigsten Gründe dafür, dass Projekte aus dem Ruder laufen: nicht übereinstimmende Erwartungen und ein wachsender Umfang. Die Forschung des PMI hat ergeben, dass bei 52 % der Projekte der Umfang schleichend wächst oder unkontrollierte Änderungen auftreten. Meiner Erfahrung nach sind es vor allem die Projekte, bei denen ein Projektbrief übersprungen wurde, die am wahrscheinlichsten in dieser Statistik landen.
Vorlage für einen Projektbrief
Hier kannst du meine Vorlage für einen Projektbrief und ein Beispiel für einen Projektbrief herunterladen. Du kannst die Vorlage an deine eigenen Projektbriefs anpassen (und das Logo sowie das Branding deiner Organisation hinzufügen). Das Beispiel zeigt dir genau, was in die einzelnen Abschnitte gehört.
Beispiel für einen Projektbrief
So könnte dein Projektbrief nach der Fertigstellung aussehen:
| Auftragsdetails | |||
|---|---|---|---|
| Kunde & Marke | Aston Baby / Rebecca Miller | AM | Hannah McNamee |
| Auftragsname & -nummer | Website-Aktualisierung / AB5099 | PM | Ben Aston |
| Budget | $250,000 inkl. Rückstellung | Fristen | Online – 1. Okt. |
| Warum? – Die geschäftliche Herausforderung des Kunden |
|---|
| Der Umsatz von AB ist in den vergangenen 6 Monaten erheblich zurückgegangen; dieses Projekt ist in erster Linie vertriebsorientiert Der Website-Traffic ist gesunken, die Zahl der E-Mail-Anmeldungen ist rückläufig, die Produktaufrufe sind zurückgegangen und der Warenkorbabbruch hat zugenommen. Das Hauptziel besteht darin, den Umsatz zu steigern durch: eine Erhöhung der Aufrufe/Besuche auf 4 Seiten/Besuch (gegenüber derzeit 2), eine Verringerung des Warenkorbabbruchs (von 60 % auf 30 %) und eine Erhöhung der E-Mail-Anmeldungen auf 20 pro Tag (gegenüber derzeit 5). |
| Was? – Die Dinge, die wir tun/erstellen werden, um diese Herausforderung zu meistern |
|---|
| Die Startseite aktualisieren, um Produkte besser zu präsentieren und mehr Lifestyle-Bilder einzubinden Die Produktdetailseite aktualisieren, um andere Produkte für Cross-Selling und Upselling hervorzuheben Die Kategorieseiten und den Checkout-Ablauf vereinfachen Die Sichtbarkeit des E-Mail-Anmeldeformulars erhöhen |
| Wann? – Der Projektzeitplan |
|---|
| Kick-off mit dem Kunden am 20. September Livegang – 1. November (die Frist wird durch die vorab gebuchte Feiertagskampagne für bezahlte Medien vorgegeben.) |
| Wie? – Der Prozess, den wir befolgen müssen |
|---|
| AB bevorzugt, mit einer Analysephase zu beginnen und einen Backlog mit priorisierten Verbesserungen zu erstellen Das Projekt wird anschließend in iterativen UX-/Design- und Entwicklungs-Sprints durchgeführt Priorität hat es, kurzfristig umsetzbare Erfolge zur Steigerung der Conversion am unteren Ende des Trichters so schnell wie möglich anzugehen und anschließend die größeren Probleme der Website im Rahmen des Budgets und Zeitplans zu bearbeiten. |
| Wer? – Die beteiligten Personen |
|---|
| Kunde: Rebecca Miller (wichtigste Ansprechpartnerin) DPM-Projektteam: Simon (CD), Suze (Text), Dave (Strategie), Warren (UX), Rory (Technik), Ben (AM) |
| Sonst noch etwas? |
|---|
| Der Kunde möchte die Website weiterhin auf Woocommerce und WordPress betreiben Die bisherige Strategiearbeit zum Wachstum von astonbaby.com sollte während dieses gesamten Projekts geprüft und berücksichtigt werden |
Projektauftrag im Vergleich zu anderen Projektdokumenten
Ein Projektauftrag wird häufig mit Dokumenten verwechselt, die anderen Zwecken dienen. Anhand dieser Tabelle kannst du nachvollziehen, wo ein Projektauftrag im Verhältnis zu anderen gängigen Projektdokumenten einzuordnen ist:
| Dokument | Zweck | Typischer Umfang | Wann es erstellt wird |
|---|---|---|---|
| Projektauftrag | Das Team auf Ziele, Umfang und Vorgehensweise ausrichten | 1–2 Seiten | Projektinitiierung |
| Projektcharta | Das Projekt formell genehmigen; die Befugnisse des Sponsors definieren | 2–5 Seiten | Vor der Initiierung oder während der Initiierung |
| Projektplan | Detaillierte Aufschlüsselung der Aufgaben, Zeitplan und Ressourcenplanung | 5–20+ Seiten | Planungsphase |
| Kreativbriefing | Kreative Ergebnisse anleiten (Design, Texte, Kampagnen) | 1 Seite | Vor Beginn der kreativen Arbeit |
| Projektvorschlag | Eine Begründung für die Finanzierung oder Genehmigung liefern | Variiert | Vor der Genehmigung des Projekts |
| Zusammenfassung für die Führungsebene | Ergebnisse für die Führungsebene zusammenfassen | 1 Seite | Am Ende des Projekts oder für die Berichterstattung |
Der Projektauftrag ist detaillierter als eine Projektcharta, aber bei Weitem weniger granular als ein vollständiger Projektplan. Wenn dir jemand aus deinem Team ein 15-seitiges Dokument übergibt und es als Projektauftrag bezeichnet, handelt es sich um einen Plan.
Wer einen Projektauftrag wann verfasst
In der Regel ist der Projektmanager für den Projektauftrag verantwortlich, doch seine Erstellung ist ein gemeinschaftlicher Prozess. Du holst Beiträge von Stakeholdern, Fachexperten und der Person ein, die als Sponsor des Projekts fungiert. Der Projektauftrag spiegelt deren Beiträge wider, auch wenn du ihn selbst verfasst.
Verfasse den Projektauftrag während der Initiierung, bevor eine Planung oder Ressourcenbereitstellung stattfindet. Wenn du Zeitpläne finalisierst oder Aufgaben verteilst, bevor der Projektauftrag genehmigt wurde, arbeitest du in der falschen Reihenfolge.
Typischerweise tragen folgende Personen zu den einzelnen Abschnitten bei:
- Projektmanager: Erstellt das Dokument, sorgt für die Genehmigung und pflegt es während des gesamten Projekts.
- Projektsponsor: Bestätigt die geschäftliche Begründung und genehmigt Umfang und Budget.
- Wichtige Stakeholder: Validieren die Ziele, machen Einschränkungen sichtbar und bestätigen ihre Rollen.
- Fachliche Experten: Liefern Informationen zum technischen Umfang, zur Machbarkeit und zum Ressourcenbedarf.
Ich würde vorschlagen, vor der Erstellung eine kurze Auftaktsitzung mit den Beteiligten durchzuführen. Das nimmt weniger Zeit in Anspruch, als ein Briefing zu korrigieren, das die Projektziele nicht richtig widerspiegelt.
Wichtige Elemente eines Projektbriefings
Jedes Briefing sieht je nach Projekt etwas anders aus, aber diese Elemente sind im Allgemeinen immer enthalten.
Hintergrund und Kontext
Erkläre, warum dieses Projekt existiert. Welches geschäftliche Problem, welche Chance oder welcher Auslöser steckt dahinter? Dieser Abschnitt vermittelt später Hinzukommenden und neuen Stakeholdern das Bild der Ausgangssituation. Beschränke dich auf zwei oder drei Sätze.
Ziele und Erfolgskennzahlen
Formuliere, was du erreichen möchtest und woran du erkennst, dass du es erreicht hast. Formuliere Ziele nach dem SMART-Rahmen (spezifisch, messbar, erreichbar, relevant und zeitgebunden). Vage Ziele wie „die Benutzererfahrung verbessern“ benötigen ein messbares Ergebnis, etwa „die Abbruchrate beim Onboarding bis zum zweiten Quartal um 20 % senken“.
Umfang
Definiere, was enthalten ist und was nicht. Elemente innerhalb des Umfangs sind Ergebnisse und Aufgaben, für die das Team verantwortlich ist. Elemente außerhalb des Umfangs sind ausdrückliche Ausschlüsse, die andernfalls möglicherweise vorausgesetzt würden. Eine präzise Definition verhindert, dass Stakeholder nach sechs Wochen noch „eine Sache“ hinzufügen.
Zeitplan und Meilensteine
Führe die wichtigsten Termine auf: Projektstart, bedeutende Meilensteine und das angestrebte Abschlussdatum. Du brauchst kein vollständiges Gantt-Diagramm, aber eine Handvoll Ecktermine vermittelt allen ein gemeinsames Gefühl für Tempo und Dringlichkeit.
Zielgruppe
Beschreibe, für wen das Projektergebnis bestimmt ist. Bei einer Produktfunktion ist das der Endnutzer. Bei einer internen Initiative kann es sich um eine bestimmte Abteilung handeln. So bleiben Entscheidungen auf diejenigen ausgerichtet, die tatsächlich von der Arbeit profitieren.
Stakeholder und Rollen
Nenne die beteiligten Personen und stelle klar, wofür jede einzelne Person verantwortlich ist. Verwende eine RACI-Matrix oder bei kleineren Projekten eine einfache Liste, wenn eine vollständige Matrix übertrieben erscheint. Entscheidend ist, dass niemand raten muss, ob es in seiner Verantwortung liegt, eine Entscheidung zu treffen.
Budget und Ressourcen
Gib das genehmigte Budget und alle wesentlichen Ressourcenzusagen an (z. B. Personalbestand, Tools, Anbieter und Infrastruktur). Eine Aufschlüsselung nach einzelnen Positionen ist im Briefing nicht erforderlich. Für diese Phase reichen ein Höchstbetrag und die wichtigsten Ressourcenbeschränkungen aus.
Kommunikationsplan
Lege dar, wie das Team auf dem gleichen Stand bleibt. Nimm die Sitzungshäufigkeit, das Format der Statusberichte und die Empfänger der jeweiligen Aktualisierungen auf. Das muss nicht aufwendig sein. Schon ein einziger Satz wie „wöchentliche Status-E-Mail an die Sponsoren jeden Freitag“ ist hilfreicher als gar keine Angabe.
So erstellst du ein Projektbriefing: Schritt für Schritt
Befolge diese Schritte, um ein Briefing zu erstellen, das vom ersten Tag an nützlich ist:
- Trage vor dem Schreiben den Kontext zusammen: Sprich mit dem Projektsponsor und den wichtigsten Stakeholdern. Verstehe den geschäftlichen Anlass, bekannte Einschränkungen und die Vorstellung der wichtigsten Beteiligten von einem erfolgreichen Ergebnis.
- Erstelle zuerst den Hintergrund und die Ziele: Beginne mit dem „Warum“, bevor du dich dem „Was“ widmest. Sobald der Zweck klar ist, lässt sich der Rest des Briefings leichter konsistent formulieren.
- Definiere den Umfang ausdrücklich: Liste auf, was enthalten ist und was nicht. Beziehe die Stakeholder in diesen Schritt ein. Unstimmigkeiten über den Umfang lassen sich in einem Entwurf deutlich leichter lösen als mitten in der Umsetzung.
- Füge Ecktermine und Namen der Verantwortlichen hinzu: Selbst grobe Meilensteintermine und benannte Rollen sind besser als Platzhalter. Präzision schafft Verantwortlichkeit.
- Ergänze Budget und Ressourcen: Lass dir vom Sponsor vor der Fertigstellung eine bestätigte Budgetspanne geben. Nicht genehmigte Schätzungen führen später zu Problemen.
- Verfasse den Kommunikationsplan: Vereinbare mit deinem Sponsor die Häufigkeit und das Format der Aktualisierungen. Dieser Teil dauert fünf Minuten, spart aber Stunden an spontaner Kommunikation.
- Lege den Entwurf zur Prüfung vor und hole die Genehmigung ein: Sende den Entwurf an alle wichtigen Stakeholder. Arbeite das Feedback ein und hole anschließend eine schriftliche Genehmigung ein.
- Teile ihn mit dem gesamten Team: Veröffentliche ihn an einem Ort, den alle finden können, etwa in deinem Projektmanagement-Tool, auf einem gemeinsamen Laufwerk oder auf der Dokumentationsplattform deines Teams.
Häufige Fehler bei Projektbriefs, die Sie vermeiden sollten
Bei den meisten Problemen mit Projektbriefs geht es nicht um den Inhalt des Dokuments, sondern darum, wie es erstellt oder verwendet wurde. Achten Sie auf Folgendes:
- Erstellung im Alleingang: Ein Brief, der ohne die Einbeziehung der Beteiligten erstellt wurde, muss überarbeitet werden, oft mehr als einmal. Beziehen Sie die richtigen Personen frühzeitig ein.
- Unklare Angaben zum Umfang: „Das Dashboard verbessern“ ist keine Umfangsdefinition. Unklarheit führt zu Annahmen, und Annahmen führen zu einer schleichenden Ausweitung des Projektumfangs.
- Verzicht auf die Liste der nicht enthaltenen Leistungen: Wenn Sie nur definieren, was enthalten ist, werden die Beteiligten die Lücken selbst füllen (normalerweise zu ihren Gunsten).
- Ziele ohne Messgrößen festlegen: Ziele ohne messbare Ergebnisse können nicht bewertet werden. Wenn Sie etwas nicht messen können, können Sie nicht bestätigen, dass es erledigt ist.
- Nach dem Projektstart ablegen: Der Brief sollte eine fortlaufend aktuelle Referenz sein und kein einmaliges Dokument. Wenn er nicht leicht zu finden ist, wird er nicht verwendet.
Werkzeuge zur Optimierung Ihres Projektbriefs
Hier sind einige Werkzeuge, die den Prozess schneller machen und das Ergebnis nützlicher gestalten:
Klicks auf die untenstehenden Links können eine Provision einbringen, die unsere unabhängige Überprüfung und Bewertung von Software und Dienstleistungen unterstützt. Erfahren Sie mehr darüber, wie wir Transparenz gewährleisten.
Wann Sie Ihren Projektbrief aktualisieren oder überarbeiten sollten
Ein Projektbrief sollte während der gesamten Projektlaufzeit aktuell bleiben. Das bedeutet, dass Sie ihn erneut prüfen sollten, wenn sich Dinge ändern.
Aktualisieren Sie Ihren Brief, wenn eines der folgenden Ereignisse eintritt:
- Änderungen des Umfangs: Jede formal genehmigte Ergänzung oder Entfernung von Ergebnissen sollte im Brief festgehalten werden.
- Verschiebungen im Zeitplan: Wenn sich wichtige Meilensteine verschieben, aktualisieren Sie den Brief, damit er Ihrem aktuellen Plan nicht widerspricht.
- Änderungen bei Beteiligten oder Verantwortlichkeiten: Neue Entscheidungsträger müssen benannt und ausgeschiedene ersetzt werden.
- Budgetänderungen: Genehmigte Änderungen am Budget sollten im Brief dokumentiert werden und nicht nur in einer Tabellenkalkulation.
- Weiterentwicklung der Ziele: Wenn sich das Geschäftsziel während des Projekts ändert, sollte der Brief das neue Ziel widerspiegeln.
Wenn Sie den Brief aktualisieren, vermerken Sie die Version und die vorgenommenen Änderungen. So bleibt die Änderungshistorie sichtbar und die Beteiligten erhalten eine klare Aufzeichnung darüber, warum sich das Projekt weiterentwickelt hat. Ich behandle Versionsnotizen als unkompliziertes Änderungsprotokoll. Das dauert zwei Minuten und erspart viele Gespräche nach dem Muster: „Moment, ich dachte, wir hätten vereinbart, dass …“
Starten Sie Ihr nächstes Projekt auf der richtigen Grundlage
Ein solider Projektbrief ist eine der klarsten Möglichkeiten, sich als vorbereitete und gut abgestimmte Projektleitung zu präsentieren. Wenn Sie weitere Werkzeuge wie dieses nutzen möchten, um Ihre Arbeitsweise bei der Umsetzung zu verbessern, melden Sie sich für unseren kostenlosen Newsletter und unsere Mitgliedschaft an. So erhalten Sie Zugriff auf Vorlagen, Leitfäden und Einblicke von anderen Projektmanagerinnen und Projektmanagern, die im Zeitalter der KI arbeiten.
