Projektcharta: Vorlage und wichtige Abschnitte 2026

Ein Projektauftrag, der nicht auflistet, was vom Leistungsumfang ausgeschlossen ist, öffnet Tür und Tor für alle möglichen zukünftigen Anfragen. Und ohne einen designierten Entscheidungsträger zur Beilegung von Meinungsverschiedenheiten beginnt jede Schlichtung die Diskussion von Neuem. Djaboo bietet ein spezielles Modul dafür an: Projektvorlagen.

Was ein Projektauftrag festlegt und was er nicht festlegt

Ein Projektauftrag ist keine Präsentation, die das Ziel in ansprechenderen Worten formuliert. Dieses Dokument hat eine spezifische Funktion: Es legt vor Arbeitsbeginn die Punkte fest, die ohne explizite Entscheidung nicht mehr geändert werden können. Es handelt sich um eine Rahmenvereinbarung, nicht um ein Motivationsinstrument. Wenn Ihr Auftrag einer Verkaufsbroschüre ähnelt, ist er im Streitfall nutzlos.

Konkret legt eine Projektcharta acht Punkte fest: das nachvollziehbar formulierte Projektziel, den Projektumfang mit seinen Ausschlusskriterien, den Namen der Person, die im Streitfall die endgültige Entscheidung trifft, die jeweilige Rolle jedes Beteiligten, die zu erbringenden Leistungen und deren Abnahmekriterien. Meilensteine Diese acht Punkte, die einen wichtigen Meilenstein darstellen, umfassen das zugesagte Budget und die bereitgestellten Ressourcen sowie die zu Beginn identifizierten Risiken und Annahmen. Diese Punkte reichen aus, um ein Kleinstunternehmensprojekt unabhängig von seiner Größe zu strukturieren.

Was die Charta jedoch nicht regelt, sind die Details der täglichen Arbeit. Sie legt weder fest, wie das Team seine Tage organisiert, noch welches Tool es zur Aufgabenverfolgung verwendet oder in welcher Reihenfolge die Entwickler die Funktionen programmieren. Diese Details fallen in den Zuständigkeitsbereich der Geschäftsleitung. Projektmanagement Es geht um das Tagesgeschäft, nicht um den ursprünglichen Rahmen. Die Verwechslung der beiden ist einer der Gründe, warum manche Satzungen zu dreißigseitigen Dokumenten werden, die niemand jemals wieder liest.

Die folgende Tabelle fasst die Abschnitte einer Charta, deren Inhalt und die jeweilige Frage zusammen, die jeder Abschnitt beantwortet. Behalten Sie die Tabelle beim Schreiben Ihrer eigenen Charta vor sich: Können Sie eine der Fragen nicht beantworten, ist der entsprechende Abschnitt noch nicht fertig.

Abschnitt der Charta	Was steht dort geschrieben?	Eine Frage, auf die sie antwortet
Ziel	Das erwartete Ergebnis, formuliert in messbarer und datierter Weise	Wie sieht der Erfolg des Projekts aus?
Eingeschlossener und ausgeschlossener Umfang	Was geliefert wird und was nicht explizit geliefert wird	Wo endet das Projekt?
alleiniger Entscheidungsträger	Der Name der Person, die im Falle einer Meinungsverschiedenheit die endgültige Entscheidung trifft.	Wer hat das letzte Wort?
Vorbesteller	Wer macht was, und wer entscheidet was unter ihnen?	Wer ist beteiligt und welche genaue Rolle spielen die einzelnen Personen?
Liefergegenstände und Abnahmekriterien	Was wird übergeben, und wie lässt sich beurteilen, wann es abgeschlossen ist?	Woran erkennen wir, dass die Arbeit erledigt ist?
Jalons	Die Meilensteine, die einen wirklich bedeutenden Fortschritt markieren.	Wie ist der aktuelle Stand des Projekts?
Budget und Ressourcen	Der zugesagte Betrag, der Stundensatz, die geschätzten Stunden und die von den einzelnen Personen aufgewendete Zeit	Womit wird das Projekt finanziert?
Risiken	Was könnte schiefgehen und welche Gegenmaßnahmen sind für jeden Fall geplant?	Was tun wir, wenn das tatsächlich passiert?
Annahmen und Abhängigkeiten	Etwas, von dem das Projekt abhängt, das aber nicht vom Team kontrolliert wird.	Worauf basiert das Projekt ohne jegliche Gewährleistung?
Validierung	Wer hat die Charta genehmigt und an welchem ​​Datum?	Hat das Projekt tatsächlich schon begonnen oder wird es noch diskutiert?

Der Zeitpunkt seiner Entstehung, und warum er zu früh oder zu spät erfolgte, macht ihn nutzlos.

Der ideale Zeitpunkt für die Erstellung eines Projektchartas liegt zwischen zwei bestimmten Stichtagen. Sie sollten das erste Gespräch mit dem Kunden geführt haben, in dem dieser seine allgemeine Absicht darlegt, aber noch nicht mit der eigentlichen Produktion begonnen haben. Wenn Sie den Charta zu früh, direkt nach dem ersten Gespräch, verfassen, erhalten Sie ein Dokument voller unbestätigter Annahmen. Sie werden das Budget, die Deadline und die Prioritäten des Kunden nur schätzen. Ein solcher Charta wird sich spätestens in der zweiten Projektwoche als unzutreffend erweisen.

Umgekehrt ist ein zu spät verfasstes Charta, wenn das Team bereits mit der Arbeit begonnen hat, aus einem einfachen Grund nutzlos: Die darin festgelegten Entscheidungen wurden bereits informell per E-Mail, kurzer Nachricht oder spontan getroffen, ohne alle Beteiligten zu informieren. In diesem Stadium dokumentiert das Charta lediglich bereits Erreichtes. Es verliert seine Funktion als vorläufiger Rahmen und wird zu einem verkappten Bericht.

Ein sicheres Zeichen dafür, dass der Zeitpunkt gekommen ist, ist, wenn der Kunde drei Fragen klar beantwortet hat: Welches konkrete Ergebnis erwartet er, mit welchem ​​Budget und bis zu welchem ​​Termin? Sobald diese drei Antworten vorliegen, selbst wenn sie nur annähernd da sind, können Sie den Projektauftrag entwerfen. Dieser dient genau dazu, die ungefähren Antworten in präzise Verpflichtungen mit Ausnahmen und einem benannten Entscheidungsträger umzuwandeln. Wenn Sie mit dem Schreiben warten, bis Sie absolute Gewissheit haben, werden Sie nie etwas schreiben, denn ein Projekt ist erst dann wirklich abgeschlossen, wenn es fertiggestellt ist.

Es empfiehlt sich, die Erstellung des Projektchartas zur Voraussetzung für den Arbeitsbeginn zu machen: Vor der Unterzeichnung des Chartas dürfen keine abrechenbaren Stunden berechnet, keine Aufgaben zugewiesen und keine Entwicklungsarbeiten begonnen werden. Diese einfache Regel verhindert, dass die Arbeit beginnt, solange das Rahmenwerk noch im Entwurfsstadium ist.

Formulieren Sie das Ziel auf eine überprüfbare Weise.

Ein schlecht formuliertes Projektziel gleicht eher einer bloßen Absichtserklärung. „Die Online-Präsenz des Kunden verbessern“ ist kein Ziel, sondern ein Wunsch. Am Ende des Projekts lässt sich nicht beurteilen, ob dies erreicht wurde, da keine Überprüfungskriterien definiert sind. Ein sinnvolles Ziel in einem Projektauftrag sollte es einem Dritten, der an keinen Meetings teilgenommen hat, ermöglichen, unabhängig zu beurteilen, ob das Ergebnis den Planungen entspricht.

Nehmen wir das vorherige Beispiel noch einmal und formulieren es um: „Eine E-Commerce-Website mit den 40 Backwaren des Kunden und einem funktionierenden Online-Zahlungssystem soll bis spätestens 30. November online gehen und geliefert werden.“ Dieser Satz enthält ein konkretes Ergebnis, einen quantifizierten Umfang, ein benanntes Merkmal und ein Datum. Jeder kann am 1. Dezember überprüfen, ob das Ziel erreicht wurde oder nicht.

Drei Voraussetzungen machen ein Ziel überprüfbar. Erstens ein beobachtbares Ergebnis: etwas, das man sehen, testen oder zählen kann, nicht nur einen Eindruck. Zweitens ein Datum: Ohne Frist bleibt ein Ziel theoretisch; es verpflichtet niemanden langfristig. Drittens eine Erfolgsbedingung, die nicht von subjektiver Einschätzung abhängt: „Der Kunde ist zufrieden“ ist nicht überprüfbar, aber „Der Zahlungsprozess verarbeitet eine Testbestellung erfolgreich“ schon. Dieselbe Anforderung der Überprüfbarkeit gilt, Anforderung für Anforderung, für die funktionale Spezifikationen Darin wird dann detailliert beschrieben, was uns das Ergebnis ermöglichen sollte.

Hier ist eine einfache Übung, um die Aussagekraft eines Ziels zu prüfen, bevor Sie es in die Charta aufnehmen: Fragen Sie sich, ob zwei verschiedene Personen, die denselben Satz lesen, zu gegensätzlichen Schlussfolgerungen über den Erfolg des Projekts gelangen könnten. Lautet die Antwort „Ja“, ist das Ziel noch nicht präzise genug. Überarbeiten Sie es so lange, bis diese Mehrdeutigkeit beseitigt ist. Diese Umformulierung dauert nur zehn Minuten und erspart Ihnen wochenlange Auseinandersetzungen.

Der Anwendungsbereich und insbesondere die Liste der davon ausgeschlossenen Punkte

Dieser Abschnitt ist am schlechtesten umgesetzt und paradoxerweise gleichzeitig der nützlichste. Wir beschreiben detailliert, was das Projekt umfasst: die Webseiten, die Funktionen, die erwarteten Ergebnisse. Dann belassen wir es dabei, zufrieden, alles abgedeckt zu haben. Das Problem ist, dass ein allein durch seinen Inhalt beschriebener Projektumfang ein offenes Versprechen bleibt: Nichts hindert den Kunden daran, eine zusätzliche, unerwähnte Anfrage als „selbstverständlich“ anzusehen und deren Umsetzung ohne zusätzliche Kosten oder weitere Absprache zu erwarten.

Genau durch diese Lücke geraten Projekte außer Kontrolle. Der Kunde wünscht sich eine englische Übersetzungsfunktion, weil „eine professionelle Website heutzutage mehrsprachig sein sollte“. Niemand hat je behauptet, diese Funktion sei nicht enthalten, daher kann niemand sie ablehnen, ohne den Anschein unlauteren Handelns zu erwecken. Der einzig wirksame Schutz besteht darin, schriftlich und unmissverständlich festzuhalten, was nicht im Projekt enthalten ist – und zwar genauso detailliert wie die enthaltenen Leistungen.

Eine gut formulierte Ausschlussklausel bedeutet nicht einfach nur „Nein“. Sie legt klar fest, was ausgeschlossen ist, und beseitigt so jegliche Unklarheit. „Die Website wird nicht übersetzt“ ist weniger präzise als „Die Website wird nur auf Französisch geliefert; Übersetzungen werden separat angeboten.“ Letztere Formulierung schließt die Möglichkeit aus, lässt aber gleichzeitig eine klare Option offen, falls der Kunde diese Dienstleistung weiterhin wünscht, sie aber außerhalb des ursprünglichen Leistungsumfangs in Anspruch nehmen möchte.

Die folgende Tabelle veranschaulicht anhand eines konkreten Beispiels eines E-Commerce-Website-Projekts für eine Bäckerei, wie diese Ausschlüsse spiegelbildlich zu dem formuliert werden können, was eingeschlossen ist.

Innerhalb des Umfangs enthalten	Vom Umfang ausgeschlossen
Katalog mit 40 Gebäckreferenzen	Katalog für Catering- und Restaurantprodukte vor Ort
Online-Zahlung per Kreditkarte	Zahlung in Raten und Zahlung bei Lieferung
Französische Version der Website	Übersetzung ins Englische oder in eine andere Sprache
Lieferung im französischen Mutterland	Lieferung nach Korsika, in Überseegebiete und international
Eine Stunde Schulung zur Nutzung des Backoffice	Unbegrenzter telefonischer Support nach der Inbetriebnahme
Integration mit dem bereits vom Kunden verwendeten Buchhaltungstool	Datenmigration von der alten Website oder der alten Kassensoftware

Jede Zeile in der rechten Spalte schützt das Projekt konkret vor einer bestimmten Kostenüberschreitung. Ohne sie würde die entsprechende Anfrage irgendwann eintreffen, getarnt als „nur eine kleine Anpassung“, und müsste entweder in angespannter Atmosphäre abgelehnt oder ohne Entschädigung auf Kosten der Gewinnspanne und des Zeitplans akzeptiert werden.

Benennen Sie einen einzelnen Entscheidungsträger und legen Sie fest, wer die endgültige Entscheidung trifft.

Eine Charta kann ein perfektes Ziel, einen klaren Geltungsbereich und gut formulierte Ausschlüsse enthalten, bleibt aber dennoch wirkungslos, wenn sie eine einfache Frage nicht beantwortet: Wer trifft die endgültige Entscheidung bei Meinungsverschiedenheiten? Ohne eine klare Zuständigkeit in diesem Bereich führt jede Meinungsverschiedenheit zu einer erneuten Diskussion des gesamten Projekts, da jeder berechtigterweise annehmen kann, ein Mitspracherecht zu haben.

Der Entscheidungsträger ist nicht zwangsläufig die ranghöchste Person im Organigramm. Es ist die Person, die die tatsächliche Macht hat, Ressourcen bereitzustellen und die Konsequenzen einer Entscheidung zu tragen. In einem sehr kleinen Unternehmen, das für einen Kunden arbeitet, gibt es in der Regel zwei Entscheidungsträger zu benennen: einen auf Kundenseite, oft den Geschäftsführer oder Budgetverantwortlichen, und einen auf Anbieterseite, üblicherweise den Projektleiter, der das Team führt.

Die Charta muss die Entscheidungsbefugnisse jeder Partei klar definieren. Der Entscheidungsträger auf Kundenseite entscheidet über Umfang, Budget und Fristen: Er genehmigt oder lehnt eine Verlängerung ab, bestätigt Meilensteine ​​und entscheidet über einen Kompromiss zwischen Qualität und Geschwindigkeit. Der Entscheidungsträger auf Anbieterseite entscheidet über die Durchführung: Welche Methodik wird angewendet, wie wird die Arbeit im Team verteilt und welche Priorität wird den technischen Aufgaben zugewiesen? Diese Aufteilung der Verantwortlichkeiten verhindert, dass Einzelpersonen mit Entscheidungen außerhalb ihres Aufgabenbereichs überfordert werden und dass technische Meinungsverschiedenheiten unnötigerweise an den Kunden eskalieren.

Eine einfache Regel für die Projektcharta: Bei Uneinigkeit zwischen mehreren Beteiligten gilt die Entscheidung des designierten Entscheidungsträgers sofort, auch wenn sie nicht alle zufriedenstellt. Die Diskussion kann anschließend fortgesetzt werden, um weitere Entscheidungen anzupassen, aber das Projekt gerät nie ins Stocken, während auf einen Konsens gewartet wird, der möglicherweise nie erreicht wird. Allein diese Regel verhindert wochenlange Blockaden bei Projekten, bei denen vier oder fünf Personen glauben, das letzte Wort zu haben.

Die Beteiligten, ihre tatsächliche Rolle und die Erwartungen an jeden Einzelnen

Eine Charta, die lediglich Namen und Rollen auflistet, ist nutzlos. Entscheidend ist, für jeden Beteiligten genau festzulegen, was von ihm erwartet wird, insbesondere ob er Entscheidungsbefugnis hat oder nur beratend tätig ist. Viele Projekte geraten ins Stocken, weil jemand ohne Entscheidungsbefugnis so handelt, als ob er sie hätte, nur weil die Charta dies nicht ausdrücklich festlegt.

Ein nützliches Instrument zur Klärung dieser Rollen ist das RACI-MatrixDadurch wird klar definiert, wer die Ausführung übernimmt, wer verantwortlich ist, wer konsultiert werden muss und wer lediglich informiert werden muss. Diese Unterscheidung in die Charta aufzunehmen, selbst ohne eine vollständige RACI-Matrix zu erstellen, hilft, die häufigsten Missverständnisse zu vermeiden: Ein Marketingmanager, der seine Meinung zu den Texten äußert, hat nicht dasselbe Gewicht wie ein Sponsor, der das Budget genehmigt.

Kehren wir zum Beispiel des E-Commerce-Website-Projekts zurück, um diese Rollen konkret zu veranschaulichen.

Stakeholder	Was wird von ihr erwartet?	Was sie beschließt
Auftraggeber (Bäckereibesitzer)	Inhalte und Fotos bereitstellen, jeden Meilenstein bestätigen	Umfang und Budget reduzieren
Projektmanager auf Agenturseite	Das Team leiten und die angekündigten Fristen einhalten	Ausschnitt aus den technischen Umsetzungsentscheidungen
Backend-Entwickler	Einen funktionsfähigen und getesteten Zahlungstunnel bereitstellen	Keine Festlegung der Rahmenbedingungen, die genehmigten Entscheidungen werden umgesetzt
Grafiker	Die Modelle müssen innerhalb der vorgegebenen Fristen geliefert werden.	Bietet Optionen an, trifft aber nicht allein die endgültige Entscheidung.
Marketingmanager des Kunden	Prüfen Sie den Inhalt und geben Sie Feedback zum Tonfall.	Ausschließlich beratende Funktion, keine Entscheidungsbefugnis
Online-Zahlungsanbieter (Drittanbieter)	Konfigurieren Sie das Händlerkonto innerhalb des vereinbarten Zeitraums.	Keine Entscheidung, Ausführung auf vertraglichen Wunsch

Dieses Diagramm beugt einer häufigen Konfliktquelle vor: Wenn der Marketingmanager Einwände gegen eine Farbe oder Formulierung äußert, ermöglicht ihm der Styleguide, den Kunden ruhig daran zu erinnern, dass seine Rolle beratend ist und die endgültige Entscheidung beim Auftraggeber liegt. Ohne diesen klaren, schriftlichen Rahmen können solche Meinungsverschiedenheiten leicht zu einer Pattsituation führen.

Liefergegenstände und deren Abnahmekriterien

Ein schlecht definiertes Lieferergebnis lässt sich an einem einfachen Merkmal erkennen: Niemand kann am Tag der Abgabe sagen, ob es fertiggestellt ist oder nicht. „Die Website“ ist kein Lieferergebnis, das in einer Charta verwendet werden kann, da diese Formulierung weder den genauen Inhalt noch die Kriterien für die Beurteilung der Erfüllung der erwarteten Standards festlegt. Ein sinnvolles Lieferergebnis wird stets von Abnahmekriterien begleitet, also einer Liste objektiver Bedingungen, die eine positive oder negative Bewertung des Lieferergebnisses ermöglichen.

Für das E-Commerce-Website-Projekt gilt der Online-Shop als akzeptabel, sobald er bestimmte Bedingungen erfüllt: Der Katalog zeigt alle 40 Produkte mit Fotos und Preisen an, der Zahlungsprozess verarbeitet eine Testzahlung per Kreditkarte erfolgreich, die Startseite lädt auf Mobilgeräten in weniger als drei Sekunden und die Website wird in den gängigsten modernen Browsern korrekt angezeigt. Diese vier Kriterien verwandeln ein zunächst ungenaues Ergebnis in etwas, das sich innerhalb einer Stunde im Test überprüfen lässt.

Um den Fortschritt dieser Ergebnisse zu verfolgen, ohne den Überblick zu verlieren, verlassen sich viele Teams auf ein Kanban-BoardDabei wird der Status jedes Liefergegenstands visuell von „Zu erledigen“ bis „Erledigt“ dargestellt, wobei die Abnahmekriterien überprüft werden. Diese Methode zur Nachverfolgung, die zwar nicht im Projektplan selbst beschrieben ist, ergibt sich direkt aus der Definitionsarbeit in diesem Abschnitt: Je präziser die Kriterien, desto einfacher lässt sich der jeweilige Liefergegenstand zu jedem Zeitpunkt in die richtige Spalte einordnen.

Ein Projektplan, der die zu erbringenden Leistungen ohne Abnahmekriterien auflistet, verschiebt Meinungsverschiedenheiten bis zur Lieferphase – dem denkbar ungünstigsten Zeitpunkt, um ein Missverständnis aufzudecken. Werden die Kriterien hingegen im Vorfeld schriftlich festgehalten, selbst in einfacher Form, verkürzt sich die Klärung auf zehn Minuten Diskussion, anstatt eine Woche ungeplanter Überarbeitungen zu verursachen.

Meilensteine ​​und wie man sie so auswählt, dass sie Bedeutung haben

Ein Meilenstein ist kein willkürlich im Kalender festgelegtes Datum, das einen Rhythmus vortäuschen soll. Ein guter Meilenstein markiert einen realen, nachweisbaren Projektstatus, der erst erreicht werden kann, wenn die entsprechenden Arbeiten tatsächlich abgeschlossen sind. „Woche 4“ ist kein Meilenstein. „Vom Kunden freigegebene Entwürfe“ hingegen schon, denn entweder sind die Entwürfe bis zu diesem Datum freigegeben oder nicht – ein Mittelweg existiert nicht.

Ein klassischer Fehler ist es, das Projekt in gleich lange Abschnitte zu unterteilen und jeden Abschnitt als Meilenstein zu bezeichnen, ohne zu berücksichtigen, was zu diesem Zeitpunkt tatsächlich gegeben sein sollte. Diese Unterteilung vermittelt ein trügerisches Gefühl der Kontrolle: Man glaubt, den Projektfortschritt zu verfolgen, obwohl man lediglich dem Zeitplan folgt, was noch nie verhindert hat, dass ein Projekt vom Kurs abweicht.

Um sinnvolle Meilensteine ​​festzulegen, fragen Sie sich in jeder Phase, was an diesem Datum nachweisbar sein muss und was passiert, wenn diese Bedingung nicht erfüllt wird. Lautet die Antwort „nichts Bestimmtes“, handelt es sich nicht um einen Meilenstein, sondern um einen internen Folgetermin. Die Erstellung dieses Meilensteinkalenders entspricht den üblichen Arbeitsabläufen des Teams. Retro-Zeitplan, wobei wir vom endgültigen Liefertermin ausgehen und uns rückwärts durch die Zwischenschritte arbeiten, die zuvor unbedingt unternommen werden müssen.

Für das E-Commerce-Website-Projekt reichen vier Meilensteine ​​aus, um das gesamte Projekt abzudecken: Validierung der Mockups am 15. September, Abschluss der technischen Integration am 15. Oktober, Test der Website beim Kunden am 10. November und finaler Launch am 30. November. Jeder dieser Meilensteine ​​entspricht einer überprüfbaren Projektphase, und eine Verzögerung bei einem Meilenstein wirkt sich direkt auf die anderen aus. Dadurch können Maßnahmen ergriffen werden, bevor die Verzögerung bis zur letzten Woche nicht mehr sichtbar wird.

Das Budget und die zugesagten Ressourcen, einschließlich der Arbeitszeit der Mitarbeiter

Ein Projektbudget ist nicht einfach nur der dem Kunden in Rechnung gestellte Gesamtbetrag. Ein umfassender Projektauftrag legt die gewählte Abrechnungsmethode fest – Festpreis oder Zeitaufwand –, den gegebenenfalls angewandten Stundensatz, die geschätzte Stundenzahl für jede Hauptphase und vor allem die Zeit, die die internen Mitarbeiter zusätzlich zu den dem Kunden in Rechnung gestellten Kosten für das Projekt aufwenden werden.

Kehren wir zum Beispiel des E-Commerce-Website-Projekts zurück, das stundenweise abgerechnet wird. Der Stundensatz beträgt 65 €. Das Team schätzt den Arbeitsaufwand auf 280 Stunden, aufgeteilt zwischen Projektmanager, Entwickler und Grafikdesigner. Die Berechnung ist einfach: 280 Stunden multipliziert mit 65 € ergeben ein Budget von 18.200 €. Indem diese Berechnung in den Projektauftrag aufgenommen wird, anstatt nur den Endbetrag anzugeben, kann jeder die Herkunft der Zahl nachvollziehen und die Auswirkungen einer Überschreitung der geplanten Stunden auf die Endkosten sofort erkennen.

Der Zeitaufwand der internen Mitarbeiter verdient besondere Beachtung, da er oft in den Budgets fehlt, obwohl er die Projektrentabilität genauso stark beeinflusst wie das dem Kunden in Rechnung gestellte Budget. Verbringt der Projektmanager beispielsweise fünf Stunden pro Woche in unbezahlten internen Meetings, muss diese Zeit erfasst werden; andernfalls erscheint das Projekt zwar auf dem Papier profitabel, schmälert aber stillschweigend die tatsächliche Gewinnspanne des Unternehmens. Ladeplan ermöglicht es Ihnen, die tatsächlich verfügbare Zeit und die bereits für dieses und andere Projekte eingeplante Zeit für jede einzelne Person zu visualisieren, wodurch vermieden wird, im Laufe des Projekts festzustellen, dass eine Schlüsselperson tatsächlich mit drei parallel laufenden Projekten überlastet ist.

Die schriftliche Fixierung dieser Zahlen im Projektvertrag, selbst in einfacher Form, wandelt das Budget von einer intuitiven Schätzung in eine überprüfbare Verpflichtung um. Überschreitet das Projekt beispielsweise 320 Stunden, kann jeder sofort berechnen, dass die entsprechenden Kosten auf 20.800 € steigen, und eine fundierte Entscheidung treffen, ob diese Mehrkosten übernommen, als zusätzliche Ausgabe abgerechnet oder durch eine Reduzierung des Projektumfangs vermieden werden sollen.

Die zu Beginn identifizierten Risiken und das, was darüber geschrieben wird

Risiken aufzulisten, ohne konkrete Maßnahmen für deren Eintritt zu spezifizieren, ist genauso wenig hilfreich wie eine Liste von Sorgen. Die Charta muss jedem identifizierten Risiko eine konkrete, vorab festgelegte Gegenmaßnahme zuordnen, anstatt eine improvisierte Reaktion erst dann vorzusehen, wenn das Problem tatsächlich auftritt.

Um die Risiken zu priorisieren, die in einem Chartervertrag zuerst angegangen werden sollen, Eisenhower-Matrix Ein risikobasierter Ansatz hilft dabei, zwischen wahrscheinlichen und folgenreichen Risiken und solchen mit geringer Bedeutung zu unterscheiden. Ein unwahrscheinliches Risiko mit geringen Auswirkungen verdient in der Projektcharta nicht dieselbe Aufmerksamkeit wie ein wahrscheinliches Risiko, das das gesamte Projekt zum Scheitern bringen könnte.

Für das E-Commerce-Website-Projekt sieht dieser Abschnitt folgendermaßen konkret aus.

Risiko erkannt	Mögliche Auswirkungen auf das Projekt	Parade geplant
Verzögerung bei der Lieferung der vom Kunden erstellten Fotos	Direkte Verzögerung bei der Katalogintegration	Die vertragliche Frist beträgt zehn Tage nach dem Start; andernfalls verzögert sich der nächste Meilenstein entsprechend.
Späte Auswahl des Online-Zahlungsanbieters	Blockierung der Entwicklung des Zahlungstunnels	Vor Erreichen des zweiten Meilensteins ist eine Entscheidung erforderlich, andernfalls wird dieser Meilenstein verschoben.
Anfragen nach zusätzlichen Funktionen im Laufe der Zeit	Umfang- und Budgetabweichungen	Anfragen, die nicht in den Projektumfang fallen, müssen als Änderungsantrag eingereicht und vom Entscheidungsträger genehmigt werden.
Nichtverfügbarkeit des Hauptentwicklers	Verlangsamung der technischen Entwicklung	Ein zweiter Entwickler wurde geschult, um neben kritischen Aufgaben zu arbeiten.
Unterschätzung des Zeitaufwands für das Schreiben von Inhalten	Überschreitung des geschätzten Budgets	Die Schreibstunden werden separat budgetiert und wöchentlich erfasst.

Der Wert dieses Abschnitts liegt nicht in der Genauigkeit der Prognose – niemand kann mit Sicherheit sagen, ob der leitende Entwickler erkranken wird oder nicht. Entscheidend ist, dass die Reaktion auf jedes Risiko bereits im Vorfeld festgelegt wird. So wird vermieden, dass improvisiert und unter Zeitdruck zum denkbar ungünstigsten Zeitpunkt im Projekt eine Lösung gefunden werden muss.

Annahmen und Abhängigkeiten: der Teil, den jeder vergisst

Fast jeder Projektauftrag lässt diesen Abschnitt aus oder reduziert ihn auf eine vage Zeile am Ende des Dokuments. Dabei ist er einer der wichtigsten, da er aufzeigt, worauf das Projekt basiert, ohne dass das Team die vollständige Kontrolle darüber hat. Eine Annahme ist eine Bedingung, die für die Erstellung von Zeitplan und Budget als erfüllt vorausgesetzt wird, ohne dass sie endgültig überprüft wurde. Eine Abhängigkeit ist ein externer Faktor, von dem der Projektfortschritt abhängt, ohne dass das Team den Fortschritt beschleunigen kann.

Für das E-Commerce-Website-Projekt liegen dem gesamten Zeitplan mehrere Annahmen zugrunde, auch wenn diese zum Zeitpunkt der Vertragsunterzeichnung nicht formell überprüft wurden. Es wird davon ausgegangen, dass der Kunde die Beschreibungstexte für die 40 Produkte bis zum 20. September bereitstellt. Weiterhin wird angenommen, dass die Marke des Kunden bereits eingetragen ist und keine Namenskonflikte den Start verzögern. Schließlich wird davon ausgegangen, dass der gewählte Hosting-Anbieter während der gesamten Projektlaufzeit verfügbar und betriebsbereit bleibt.

Abhängigkeiten hingegen betreffen Elemente, die außerhalb des direkten Einflussbereichs des Teams liegen. Das Projekt ist darauf angewiesen, dass der Zahlungsanbieter das Händlerkonto validiert. Dieser Prozess kann je nach Fall einige Tage bis mehrere Wochen dauern. Es hängt außerdem von der Verfügbarkeit des vom Kunden gewünschten Domainnamens ab, die vor der Festlegung eines Starttermins überprüft werden muss.

Die schriftliche Fixierung dieser Annahmen und Abhängigkeiten im Projektplan schützt das Team vor späteren unberechtigten Vorwürfen: Ist der gewünschte Domainname bereits vergeben und verzögert sich das Projekt dadurch um eine Woche, wird diese Verzögerung von Anfang an als externe Abhängigkeit dokumentiert und nicht als Planungsfehler des Teams. Diese Unterscheidung, die vor dem Auftreten des Problems schriftlich festgehalten wird, verändert den Verlauf der nachfolgenden Gespräche grundlegend.

Wie und von wem wird die Charta genehmigt?

Eine nicht validierte Charta bleibt ein Entwurf, unabhängig von der Qualität ihres Inhalts. Die Validierung wandelt ein Arbeitsdokument in eine gemeinsame Verpflichtung um, und diese Umwandlung verleiht der Charta ihre Stärke im Falle von Meinungsverschiedenheiten. Ohne formelle Validierung kann jede Partei behaupten, den Inhalt der Charta nie wirklich akzeptiert zu haben.

Die Validierung muss von zwei bestimmten Personen und nicht von einer vagen Gruppe durchgeführt werden: dem benannten Entscheidungsträger auf Kundenseite und dem benannten Entscheidungsträger auf Anbieterseite. Diese beiden Personen lesen das Dokument vollständig, stellen alle Fragen und erteilen ihre ausdrückliche schriftliche Zustimmung, selbst in einfacher Form wie einer Bestätigungs-E-Mail oder einer digitalen Signatur. Eine mündliche Vereinbarung während eines Meetings ist nicht ausreichend, da sie keine Aufzeichnung hinterlässt, die im Falle von Meinungsverschiedenheiten über die vereinbarten Punkte später herangezogen werden kann.

In der Praxis ist die Organisation eines kurzen Validierungstreffens nach wie vor die effektivste Methode. Das Dokument wird einige Tage im Voraus versandt, jede Partei ergänzt es mit ihren Fragen, und das Treffen dient dann dazu, verbleibende offene Punkte zu klären, anstatt den Inhalt live zu besprechen. Anschließend wird ein Entwurf erstellt. Protokoll der Sitzung Das Dokument, in dem die vorgenommenen Änderungen festgehalten und die endgültige Vereinbarung bestätigt werden, dokumentiert klar den genauen Zeitpunkt, zu dem das Projekt tatsächlich begonnen hat, und zwar mit der Zustimmung beider Entscheidungsträger zur endgültigen Fassung des Dokuments.

Nach der Genehmigung muss die Charta dem gesamten Team zugänglich sein, nicht nur den beiden Entscheidungsträgern, die sie unterzeichnet haben. Ein Entwickler, dem nicht bewusst ist, dass die englische Übersetzung ausdrücklich nicht im Leistungsumfang enthalten ist, riskiert, aus Übereifer mit dieser Arbeit zu beginnen oder dem Kunden eine Lösung zu versprechen, für deren Umsetzung er nicht befugt ist. Die Verteilung der genehmigten Charta ist ein integraler Bestandteil ihrer Validierung und darf nicht erst im Nachhinein erfolgen.

Dies führt während des Projekts zu einer Überarbeitung der Projektcharta.

Ein Projektvertrag, der während der gesamten Projektlaufzeit unverändert bleibt und keine Überarbeitungsmöglichkeit bietet, verliert zwangsläufig den Bezug zur Realität. Ein Projekt entwickelt sich weiter, ein Kunde ändert seine Meinung, ein identifiziertes Risiko tritt tatsächlich ein. Es geht daher nicht darum, jegliche Überarbeitung zu verhindern, sondern im Voraus festzulegen, wann eine Überarbeitung gerechtfertigt ist, um zu verhindern, dass jede noch so kleine Anpassung das gesamte Dokument ungültig macht.

Vier Ereignisse rechtfertigen eine formelle Überarbeitung des Projektchartas. Erstens: Ein Antrag auf Änderung des Projektumfangs, der einen vordefinierten Schwellenwert überschreitet, beispielsweise mehr als zehn zusätzliche Arbeitsstunden oder mehr als tausend Euro zusätzliches Budget. Zweitens: Eine Überschreitung des geschätzten Stundenbudgets um mehr als einen festgelegten Prozentsatz, beispielsweise fünfzehn Prozent über der ursprünglichen Schätzung. Drittens: Eine Verzögerung, die einen im ursprünglichen Projektcharta als kritisch definierten Meilenstein betrifft. Viertens: Das Auftreten eines neuen Entscheidungsträgers, beispielsweise die Einstellung eines neuen Kundenmanagers, der bestimmte Entscheidungen überprüfen möchte. Ein während eines Projekts beschlossener Rückzug vom Projektumfang. Projektüberprüfung löst die gleiche Überprüfung in umgekehrter Richtung aus: Was bei der Arbeit herauskommt, muss auch in der Charta festgehalten werden.

Jeder dieser Auslöser muss in der Charta selbst als präziser Schwellenwert und nicht als vage Formulierung wie „im Falle einer wesentlichen Änderung“ festgelegt werden. Ein quantifizierter Schwellenwert vermeidet unnötige Debatten darüber, was eine so wesentliche Änderung darstellt, dass sie eine Überarbeitung rechtfertigt.

Der Überarbeitungsprozess folgt dem gleichen Verfahren wie die ursprüngliche Validierung: Die Änderung wird dokumentiert, datiert, beiden Entscheidungsträgern vorgelegt und vor ihrer Umsetzung ausdrücklich genehmigt. Eine mehrfach überarbeitete Charta ist kein Zeichen von Misserfolg; im Gegenteil, sie beweist, dass sie ihre Rolle als lebendiges Dokument erfüllt hat, das die tatsächlichen Projektänderungen aufnehmen kann, ohne jemals ihre Funktion als klarer Rahmen zu verlieren.

Eine vollständige, Abschnitt für Abschnitt ausgearbeitete Charta für ein konkretes Mikro-Unternehmensprojekt

Hier folgt Abschnitt für Abschnitt die vollständige Projektbeschreibung des Projekts, das in diesem Artikel als Beispiel dient: die Erstellung einer E-Commerce-Website für die Bäckerei Ferrand, durchgeführt von der Agentur Atelier Kolibri.

Ziel

Starten Sie eine E-Commerce-Website, die die 40 Backwaren der Bäckerei Ferrand präsentiert, mit einem funktionierenden Online-Zahlungssystem, die spätestens am 30. November geliefert werden soll.

Umfang enthalten

Vollständiger Katalog mit 40 Artikeln inklusive Foto und Preisangabe, Online-Zahlung per Kreditkarte, nur in französischer Sprache, Lieferung innerhalb Frankreichs (Festland), eine Stunde Backoffice-Schulung für den Kunden, Integration mit dem bereits von der Bäckerei verwendeten Buchhaltungssystem.

Ausgeschlossener Umfang

Catering- und Restaurantproduktkatalog, Zahlung in Raten oder bei Lieferung, Übersetzung der Website ins Englische oder in jede andere Sprache, Lieferung nach Korsika, in Überseegebiete und international, unbegrenzter telefonischer Support nach der Online-Schaltung, Datenmigration von der alten Website.

Entscheidungsträger

Frau Ferrand, die Inhaberin der Bäckerei, trifft die endgültigen Entscheidungen bezüglich Umfang und Budget. Julie, Projektmanagerin bei Atelier Kolibri, trifft die endgültigen Entscheidungen bezüglich der technischen Umsetzung und der Teamorganisation.

Vorbesteller

Frau Ferrand, Auftraggeberin. Julie, Projektmanagerin. Ein Backend-Entwickler. Ein Grafikdesigner. Der Marketingmanager des Kunden in beratender Funktion. Der Online-Zahlungsanbieter als externer Dienstleister.

Liefergegenstände und Abnahmekriterien

Eine funktionsfähige E-Commerce-Website: Katalog mit 40 Artikeln wird korrekt angezeigt, Zahlungsabwicklung erfolgreich an einer realen Bestellung getestet, Ladezeit der Homepage auf Mobilgeräten unter drei Sekunden, Kompatibilität mit den gängigsten aktuellen Browsern geprüft.

Jalons

Die Prototypen wurden am 15. September freigegeben. Die technische Integration wurde am 15. Oktober abgeschlossen. Die Website wurde am 10. November beim Kunden getestet. Der endgültige Start erfolgte am 30. November.

Budget und Ressourcen

Die Abrechnung erfolgt auf Basis des Zeitaufwands mit einem Stundensatz von 65 Euro, bei geschätzten 280 Stunden, was insgesamt 18.200 Euro ergibt. Der interne, nicht abgerechnete Zeitaufwand, der auf 20 Stunden für die Koordination während der Projektlaufzeit geschätzt wird, wird vom Projektmanager separat erfasst.

Risiken

Verzögerte Lieferung von Produktfotos, späte Wahl des Zahlungsanbieters, Anfragen nach zusätzlichen Funktionen, Nichtverfügbarkeit des Hauptentwicklers, Unterschätzung des Zeitaufwands für die Texterstellung – für jedes dieser Probleme gibt es eine Lösung, die bereits weiter oben in diesem Artikel beschrieben wurde.

Annahmen und Abhängigkeiten

Der Kunde muss die beschreibenden Texte bis zum 20. September bereitstellen. Der Markenname ist bereits registriert und es sind keine Konflikte bekannt. Das Projekt steht unter dem Vorbehalt der Validierung des Händlerkontos durch den Zahlungsanbieter und der Verfügbarkeit des gewünschten Domainnamens.

Validierung

Das Dokument wurde am 25. August versandt, Fragen wurden in einem Treffen am 28. August geklärt, eine schriftliche Vereinbarung wurde am 29. August von Frau Ferrand und Julie unterzeichnet. Das Projekt beginnt offiziell am 1. September.

Häufige Fehler und wie man sie korrigiert

Manche Fehler treten in Projekten immer wieder auf, fast immer in derselben Form. Werden sie im Voraus erkannt, können sie korrigiert werden, bevor sie Zeit oder Geld kosten.

Häufiger Fehler	Wie sie sich selbst korrigiert
Zielsetzung vage formuliert, ohne überprüfbare Ergebnisse	Formulieren Sie das Ergebnis so um, dass es ein messbares Ergebnis darstellt, wenn möglich numerisch, und ein konkretes Datum enthält.
Der Umfang wird ausschließlich durch das beschrieben, was er umfasst.	Fügen Sie immer eine explizite Liste der ausgeschlossenen Elemente hinzu.
Es wurde kein Entscheidungsträger ernannt; die Schlichtung obliegt einem Komitee.	Die endgültige Entscheidung soll von einer einzelnen Person getroffen werden, auch wenn ein Ausschuss weiterhin berät.
Die Charta wurde erst entworfen, nachdem die Arbeiten bereits begonnen hatten.	Schreiben Sie es vor dem Start, sobald Ziel, Budget und Zeitrahmen feststehen.
Risiken ohne zugehörige Gegenmaßnahmen aufgeführt	Notieren Sie für jedes Risiko die geplante Maßnahme, falls das Risiko tatsächlich eintritt.
Die Charta wurde trotz bedeutender Veränderungen im Laufe der Zeit nie überarbeitet.	Legen Sie präzise Revisionsschwellenwerte fest und wenden Sie diese ausnahmslos an.

Diese sechs Fehler haben eines gemeinsam: Sie verzögern notwendige Klärungen, bis die Kosten deutlich höher ausfallen als ursprünglich angenommen. Zur Behebung dieser Fehler ist kein zusätzliches Fachwissen erforderlich, sondern lediglich größere Sorgfalt genau zum Zeitpunkt der Erstellung des Projektvertrags, bevor das Projekt an Dynamik gewinnt.

Übersetze die Charta ins Djaboo, sobald sie geschrieben ist.

In Djaboo hat ein Projekt einen Namen, einen Kunden, eine Beschreibung, einen Status, ein Startdatum, ein Fälligkeitsdatum, eine Abrechnungsmethode, Kosten, einen Stundensatz, eine geschätzte Stundenzahl und einen Fortschritt, der sich aus den Aufgaben berechnen lässt. Projektmeilensteine ​​haben einen Namen, eine Beschreibung, ein Startdatum, ein Fälligkeitsdatum, eine Reihenfolge und eine Farbe. Jeder Meilenstein kann für den Kunden ausgeblendet werden. Teammitglieder werden dem Projekt zugeordnet. Jedes Projekt verfügt über einen Diskussionsbereich mit Kommentaren, Notizen und Dateien. Jede Datei kann für den Kunden sichtbar oder ausgeblendet werden. Aufgaben sind mit dem jeweiligen Projekt und Meilenstein verknüpft.

Djaboo bietet weder Projektcharta noch Vorlagen zum Ausfüllen oder Felder für Umfang, Ausschlusskriterien oder Akzeptanzkriterien. Es gibt kein Risikoregister innerhalb des Tools. Ein formaler Projektvalidierungsprozess existiert nicht: In Djaboo wird nichts unterzeichnet oder genehmigt.

Die bewährte Methode besteht darin, die Projektcharta in einem separaten Dokument mit den in diesem Artikel beschriebenen Abschnitten zu verfassen und deren Inhalt nach der Genehmigung in Djaboo zu übertragen. Ziel und Umfang werden in die Projektbeschreibung integriert. Die einzelnen Schritte werden in der festgelegten Reihenfolge als Meilensteine ​​mit Start- und Endterminen definiert. Das Budget wird gemäß der gewählten Abrechnungsmethode in Projektkosten und geschätzte Arbeitsstunden umgerechnet. Die in der Projektcharta genannten Personen werden zu Projektmitgliedern und den entsprechenden Aufgaben zugeordnet.

Damit die Projektcharta aktiv bleibt und nicht in Vergessenheit gerät, empfiehlt es sich, ihre Überprüfung in Djaboo als wiederkehrende Aufgabe – beispielsweise alle zwei Wochen – einzuplanen und mit dem Projekt zu verknüpfen. Diese Aufgabe ersetzt nicht die Projektcharta selbst, sondern dient als regelmäßige Erinnerung, zu prüfen, ob das im Tool verfolgte Projekt noch der ursprünglichen Vereinbarung entspricht, und eine Überarbeitung auszulösen, falls einer der in der Charta definierten Schwellenwerte überschritten wird.

Ein Projektauftrag wird niemals nach der Qualität seiner Zielsetzung oder der Anzahl der Seiten, die den zu erbringenden Leistungen gewidmet sind, beurteilt. Er wird nach der Präzision dessen beurteilt, was er ausschließt, denn nur diese Liste verhindert, dass das Projekt stillschweigend außer Kontrolle gerät und immer neue Anforderungen hinzukommen.

Es wird auch anhand einer einzigen Zeile beurteilt, oft der kürzesten im Dokument: dem Namen der Person, die im Streitfall die endgültige Entscheidung trifft. Fehlt diese Zeile, wird jede Unstimmigkeit das gesamte Projekt neu aufrollen und ein Rahmendokument zu einer bloßen Erinnerung an die ursprünglichen Erwartungen verkommen lassen.