Projektinformationssystem aufbauen

In 15 Minuten startet das Weekly

Mittwoch, 9:45 Uhr im Projektbüro. In 15 Minuten startet das Weekly zum Shop-Relaunch. Du sollst den aktuellen Status zusammenfassen. Die Infos liegen verstreut: drei E-Mail-Threads, ein Chat-Kanal, eine veraltete Excel-Liste. Zur Designfreigabe findest du zwei widersprüchliche Aussagen. Zehn Leute warten auf klare Antworten, und jede Woche Verzögerung beim Go-Live kostet mehrere tausend Euro.

Die Rollenverteilung im Team habt ihr sauber geklärt: Product Owner, Entwicklung, QA, Stakeholder-Koordination. Jede Person weiß, was sie tut. Aber niemand weiß, wo die aktuellen Ergebnisse liegen. Das Problem ist nicht die Zusammenarbeit. Das Problem ist das fehlende Projektinformationssystem.

Vier Elemente, die zusammenspielen müssen

Ein Projektinformationssystem besteht aus vier Elementen:

1. Dokumentenablage - ein zentraler Ort für alle Projektdokumente (Briefings, Wireframes, Verträge). Typische Tools: Wiki, Cloud-Speicher wie SharePoint oder Google Drive.
2. Aufgabenverwaltung - wer macht was bis wann? Du kennst das Prinzip vom Kanban-Board. In der Praxis: Ticketsysteme wie Jira, Trello oder Asana.
3. Statusberichte - regelmäßige Updates über Fortschritt, Risiken und nächste Schritte. Format: Wochenbericht, Dashboard oder Standup-Protokoll.
4. Kommunikationskanäle - festgelegte Wege für Abstimmung, Entscheidungen und Ad-hoc-Fragen. Beispiele: Chat, E-Mail, Videokonferenz.

Fehlt eines der vier Elemente, entstehen genau die Lücken, die du gerade erlebst.

🔮 Bevor du weiterliest: Welcher der vier gängigen Kanäle - E-Mail, Chat, Wiki, Ticketsystem - schneidet bei Nachvollziehbarkeit wohl am schlechtesten ab?

Vier Kanäle in der Bewertungsmatrix

Drei Kriterien helfen dir bei der Kanalwahl:

• Transparenz - können alle Beteiligten die Information sehen, ohne aktiv danach zu fragen?
• Nachvollziehbarkeit - lässt sich später rekonstruieren, wer wann was entschieden hat?
• Aktualität - zeigt der Kanal immer den neuesten Stand?

E-Mail: Nur Empfänger:innen sehen die Info, Threads verzweigen, Anhänge veralten. Chat: Schnell, aber Nachrichten verschwinden im Strom. Wiki: Alle sehen denselben Stand, Versionshistorie dokumentiert Änderungen, aber Updates erfordern aktives Pflegen. Ticketsystem: Aufgaben, Zuständigkeiten und Fristen an einem Ort, automatische Statusänderungen.

Die Empfehlung für ein Remote-Team

Für ein zehnköpfiges Remote-Team reicht kein einzelner Kanal. Die Matrix zeigt: E-Mail schneidet bei allen drei Kriterien am schwächsten ab. Trotzdem hat sie eine Rolle - für formale Kommunikation nach außen (Auftraggeber, externe Dienstleistende).

Intern setzt du auf die Kombination: Ticketsystem für die Aufgabenverwaltung (höchste Werte bei Nachvollziehbarkeit und Aktualität) plus Wiki für die Dokumentenablage (höchste Transparenz). Chat ergänzt als schneller Kanal für Ad-hoc-Fragen - aber nie für Entscheidungen, die dokumentiert werden müssen.

Faustregel: Je wichtiger die Entscheidung, desto nachvollziehbarer der Kanal.

⚖️ Vergleich im Kopf: Eine Designentscheidung fällt im Chat versus im Wiki. Wo findest du sie drei Wochen später wieder - und wo nicht?

Tools und Zugriffsrechte

Für den Shop-Relaunch brauchst du mindestens zwei Tools:

1. Jira (Ticketsystem) für die Aufgabenverwaltung. Aufgaben lassen sich Sprints zuordnen, Abhängigkeiten zwischen Tickets abbilden und Statusänderungen automatisch tracken.
2. Confluence (Wiki) für die Dokumentenablage. Direkter Link zu Jira-Tickets, Versionshistorie, Kommentarfunktion für Reviews.

Nicht alle brauchen denselben Zugriff. Drei Rollen, drei Rechte-Stufen:

• Projektleitung: Vollzugriff. Kann Strukturen anlegen, Rechte vergeben, Berichte exportieren.
• Entwicklung/QA: Lese- und Schreibzugriff auf technische Bereiche (Tickets, technische Dokumentation). Kein Zugriff auf Budgetdaten.
• Auftraggeber: Lesezugriff auf Statusberichte und freigegebene Meilenstein-Dokumente. Kein Zugriff auf interne Diskussionen oder Ticket-Details.

Ablagestruktur in drei Ebenen

Eine dreistufige Ordnerstruktur verhindert, dass Dokumente in einem flachen Chaos landen:

Ebene 1 - Projektphase: 01_Initiierung, 02_Planung, 03_Umsetzung, 04_Abschluss

Ebene 2 - Themenbereich: Innerhalb jeder Phase z.B. Design, Technik, Content, Freigaben

Ebene 3 - Dokumenttyp: z.B. Wireframes_v2.1, Testprotokoll_Sprint3, Freigabe_Auftraggeber_2024-07-15

Die Versionsnummer im Dateinamen ersetzt die Suche nach "der neuesten Version" in der E-Mail-Kette. Im Wiki wird zusätzlich die aktuelle Version oben auf der Seite verlinkt.

Drei Arten von Statusberichten

Ein funktionierendes Berichtswesen braucht nicht einen Bericht, sondern drei verschiedene Arten:

1. Daily Standup - täglich, 15 Minuten, mündlich im Videocall. Empfängerkreis: Kernteam (Entwicklung, QA, Projektleitung). Inhalt: Was habe ich gestern geschafft? Was steht heute an? Wo hänge ich?
2. Wochenbericht - freitags, schriftlich im Wiki. Empfängerkreis: alle zehn Beteiligten inklusive Auftraggeber. Inhalt: Meilenstein-Fortschritt in Prozent, offene Risiken, Entscheidungsbedarf.
3. Meilenstein-Review - nach jeder abgeschlossenen Phase, Präsentation mit Demo. Empfängerkreis: Auftraggeber und Projektleitung. Inhalt: Ergebnisse der Phase, Abweichungen vom Plan, nächste Schritte.

Dein Weekly in fünf Minuten

Zurück zum Mittwochmorgen. Mit einem funktionierenden Projektinformationssystem sähe deine Vorbereitung so aus: Du öffnest das Jira-Board, filterst nach Sprint 3 und siehst sofort, welche Tickets erledigt sind, welche hängen und wer blockiert ist. Im Wiki klickst du auf den aktuellen Wochenbericht. Die Designfreigabe steht dort mit Datum, Entscheidung und Link zum freigegebenen Entwurf. Kein Durchsuchen von E-Mail-Threads. Keine widersprüchlichen Excel-Versionen.

Fünf Minuten, verlässlicher Überblick. Das leistet ein System, in dem alle vier Elemente zusammenspielen.

🧑‍🏫 Erkläre es im Kopf: Stell dir vor, du erklärst einer neuen Projektmitarbeitenden, warum ein geteilter Ordner allein kein Projektinformationssystem ist. Welche drei Elemente fehlen dabei, und was geht ohne sie konkret schief?