Projektdatei-Management: Best Practices für Teams

Gutes Projektdatei-Management beruht auf fünf Gewohnheiten: ein flacher, vorhersehbarer Ordnerbaum (maximal drei Ebenen tief), eine schriftliche Namenskonvention, die beim Onboarding vermittelt wird, eine einzige Quelle der Wahrheit pro Dateityp (eine Figma-Datei, ein Master-.docx, eine kanonische .xlsx), eine Versionsaufbewahrung von mindestens 180 Tagen und eine geplante Archivierung beim Projektabschluss. Das meiste Projektkhaos ist kein Tooling-Problem – es ist ein Entscheidungsproblem. Teams, die das 30-minütige Gespräch zu Beginn darüber überspringen, wo Dinge abgelegt werden, enden mit sieben doppelten Budget_Final.xlsx-Dateien in drei Tools.

Die Drei-Ebenen-Ordnerregel

Ordner, die tiefer als drei Ebenen sind, werden unfindbar. Selbsttest: Können Teammitglieder das Design-Review-Deck von Q2 2026 in unter 30 Sekunden finden? Wenn der Pfad /Clients/Acme/2026/Q2/Design/Reviews/June/Deck_v3.pptx ist, lautet die Antwort Nein.

Eine funktionsfähige Struktur sieht so aus:

/Projekte
  /2026-Q2-Acme-Rebrand
    /01-briefing
    /02-arbeitsversionen
    /03-final
    /04-archiv

Numerische Präfixe erzwingen die Sortierreihenfolge, der Projektoderordnername kodiert Quartal und Kunden für die sofortige Auffindbarkeit per Suche, und die vier Unterordner bilden tatsächliche Workflow-Zustände ab. Alles Neue landet in 01-briefing oder 02-arbeitsversionen. Bei Lieferung zieht es in 03-final um, und die Arbeitsversionen werden gelöscht oder archiviert. Teams, die dieses Muster übernehmen, reduzieren „Wo ist die Datei?"-Slack-Nachrichten im ersten Monat um 60 bis 80 %.

Namenskonventionen, die mit der Realität in Berührung kommen

Eine Namenskonvention funktioniert nur, wenn jedes Teammitglied sie ohne Nachdenken anwenden kann. Das Format, das in den meisten Branchen funktioniert:

JJJJ-MM-TT_ProjektCode_DokTyp_Beschreibung_vNN.ext

Beispiel: 2026-06-12_ACME-RB_briefing_leistungsumfang_v03.pdf

Fünf Regeln machen dies nachhaltig:

ISO-8601-Datumsformat (JJJJ-MM-TT) – sortiert korrekt und wird in jedem Gebietsschema geparst
Projektcodes, keine vollständigen Namen – ACME-RB schlägt Acme Rebranding 2026 Projektdateien
Keine Leerzeichen – Bindestriche oder Unterstriche verwenden, niemals beides im selben Feld
Zweistellige Versionsnummern – v03 sortiert korrekt bis v09, v3 nicht
Kleinbuchstaben wo möglich – Groß-/Kleinschreibung greift in manchen Dateisystemen

Aufschreiben. In das Onboarding-Dokument aufnehmen. Nicht konforme Dateien in der wöchentlichen Projektsynchronisation für zwei Wochen überprüfen – danach wird es zur Gewohnheit.

Quelle der Wahrheit und Arbeitskopien

Jede Datei eines Projekts fällt in einen von zwei Behältern: die kanonische Quelle oder eine Arbeitskopie. Die kanonische Quelle ist das, was ausgeliefert wird, wogegen abgerechnet wird, was Stakeholder prüfen. Arbeitskopien sind Entwürfe, Zweige, Experimente.

Das größte Projektmanagement-Versagen ist der Verlust des Überblicks, welche Kopie kanonisch ist. Abhilfen:

Die kanonische Datei sperren – die meisten DAMs (Bynder, Frontify) und sogar Dropbox haben Sperren beim Auschecken. SharePoints Check-in/Check-out wird zu wenig genutzt, ist aber solide.
Arbeitskopien mit einem Eigentümerpräfix benennen: jmuster_WIP_2026-06-12_ACME-RB_hero.psd
Finalisierte Assets zu 03-final verschieben und die Arbeitsversionen beim Sprint-Abschluss löschen. Nicht archivieren – löschen. Archive werden für „Ausgangspunkte" geplündert und das Problem beginnt von vorn.

Dateiverfolgung über Tools hinweg

Echte Projekte spannen Jira, Linear, Notion, Slack, Google Drive und ein Kundenportal auf. Eine Datei, die in einem Jira-Ticket erwähnt wird, lebt in Drive; dieselbe Datei wird in Slack geteilt, in eine Notion-Seite eingebettet und über einen Dropbox-Link an den Kunden geliefert. Zu verfolgen, wo Kopien sind, ist manuell unmöglich.

Zwei Ansätze helfen:

Verlinken, nicht anhängen: Wenn die kanonische Datei in Drive ist, den Drive-Link überall teilen. Das Anhängen in Slack erstellt eine abweichende Kopie, die sofort veraltet.
Eine Datei-Metadatenschicht verwenden: Tools wie Airtable oder Notion-Datenbanken mit einer „Dateien"-Basis können jedes kanonische Asset mit Spalten für Eigentümer, Status, letztes Überprüfungsdatum, Aufbewahrungsrichtlinie und externe Links katalogisieren. Aufwändig zu pflegen über 500 Assets, aber für regulierte Projekte lohnenswert.

Versionsaufbewahrung und Rollback

Die meisten Sync-Tools behalten standardmäßig begrenzte Versionshistorie – Google Drive hält 100 Versionen oder 30 Tage auf dem kostenlosen Tier, Dropbox Business hält 180 Tage, Box 50 Versionen auf Business und unbegrenzt auf Enterprise. Überprüfen Sie Ihre Standardwerte; wahrscheinlich haben Sie weniger Aufbewahrung als gedacht.

Für regulierte Projekte (DSGVO Artikel 5 Absatz 1 Buchstabe e Speicherbegrenzung, HIPAA 6-Jahres-Aufbewahrung) benötigen Sie eine Aufbewahrungsrichtlinie, die der Regulierung entspricht, nicht dem Tool-Standard. Automatisierten Export in Cold Storage einrichten (AWS S3 Glacier Deep Archive bei 0,00099 US-Dollar/GB/Monat, Wasabi bei 6,99 US-Dollar/TB/Monat) für alles, das über das Aufbewahrungsfenster des Tools hinaus überleben muss.

Rollback-Drills sind die unspektakuläre Version der Notfallwiederherstellung. Einmal pro Quartal soll jemand eine zufällige Projektdatei auswählen, behaupten sie sei gestern beschädigt worden, und messen, wie lange es dauert, die vorherige Version wiederherzustellen. Dauert es länger als 10 Minuten, hat der Aufbewahrungsprozess Lücken.

Große Lieferungen und externe Sends verwalten

Finale Projektergebnisse passen selten durch E-Mail. Ein 4K-Videoschnitt ist 40+ GB, ein vollständiges PSD-Quellpaket mit Ebenen läuft 2 bis 10 GB, Architektur-BIM-Dateien erreichen routinemäßig 5 GB. Das Projektmanagementsystem braucht ein klares Protokoll für Ergebnisübergabe.

Das funktionierende Muster: Kanonische Dateien bleiben in Ihrem DAM oder Sync-Tool, aber die finale Kundenlieferung erfolgt über einen dedizierten Übertragungsdienst mit Tracking. Dienste wie WeTransfer Pro, Smash, SwissTransfer oder HexaTransfer ermöglichen das Senden von bis zu 10 bis 250 GB mit Link-Ablauf, Download-Belegen und – bei Ende-zu-Ende-verschlüsselten Diensten wie HexaTransfer – clientseitiger AES-256-GCM-Verschlüsselung, sodass der Anbieter nicht auf den Inhalt zugreifen kann. Jede Kundenlieferung standardmäßig passwortschützen, auch für nicht sensible Dateien – es zwingt Empfänger zu bestätigen, dass sie den richtigen Link bekommen haben.

Archivierung: Der Schritt, den alle überspringen

Projekte enden. Dateien nicht. Ein Jahr nach Projektabschluss muss noch beantwortet werden: „Was war das finale Logo, das wir für Acme geliefert haben?" Aber das Arbeits-Chaos in /Projekte/2026-Q2-Acme-Rebrand/02-arbeitsversionen/ ist jetzt 14 GB Lärm.

Archivierungsdisziplin beim Projektabschluss:

03-final nach /Archiv/JJJJ/KundenCode/ als schreibgeschützt kopieren
Ein Projektmanifest exportieren: eine .md-Datei, die jedes finale Asset, seinen Zweck und den genehmigenden Stakeholder auflistet
02-arbeitsversionen löschen, sofern keine Regulierungen eine Aufbewahrung erfordern
Einen Kalender-Reminder für 12 Monate setzen, um die Archivaufbewahrung neu zu bewerten

Dieses Manifest ist das nützlichste einzelne Dokument für jeden, der ein Folgeprojekt für denselben Kunden übernimmt. Die 30 Minuten beim Abschluss investieren – das künftige Ich wird es danken.

HexaTransfer unter https://hexatransfer.com testen – kostenlos, kein Konto, bis zu 10 GB.