Inhaltsverzeichnis

• Vorwort
  • Was sind die Auswirkungen?
  • Überblick über unsere Werkzeuge
  • An wen richtet sich dieses Buch?
  • Erst die Struktur, dann die Software!
  • Fragen Sie uns
• Kapitel 1 Was ist ein Projekt?
• Kapitel 2 Wie eine E-Mail- und Dokumentenflut entsteht
  • Wohin mit den E-Mails?
  • Fall 1: Frage nach Dokumenten
  • Fall 2: Abstimmung von Aufgaben
• Kapitel 7 Ablage für Ad-hoc-Projekte (PM-Methode 1)
  • Beispiel und Definition
  • Die Zeit als führendes Merkmal
  • Klammerordner
  • Ein- und Auschecken von Dokumenten aus den Klammerordnern
  • Archivordner
  • Passen Sie die Ablage an
  • „Meine Ablage würde aber ganz anders aussehen!“
• Kapitel 8 Ablage für Wasserfallprojekte (PM-Methode 2)
  • Was ist ein Projekt mit festen Phasen?
  • Kanban-Boards
  • Ablage in Projekten mit festen Phasen
  • Musterordner
• Kapitel 10 Ablage für agile Herangehensweisen (PM-Methode 4)
  • Beispiel und Definition
  • Die Iterationen (Sprints) als führendes Merkmal
  • Klare Verantwortung für die Ablage
  • Häufige Probleme bei agilen Teams
• Über die Autoren

Vorwort

„Durcheinander auf dem Server“, „Chaos in der Projektablage“ – das sind gängige Lagebeschreibungen, wie wir sie beim Start unserer Projekte immer wieder hören. Für Leute, die mit größtem Enthusiasmus an ihren Projekten arbeiten und für die jedes abgeschlossene Arbeitspaket Quelle größter Freude und Zufriedenheit ist – quasi ein Wunschkind -, ist die Projektablage bestenfalls ein ungeliebtes Baby. Sie wird entsprechend stiefmütterlich behandelt.

Stiefkinder aber rächen sich, sobald sie können. Die Folgen sind entsprechend. Um nur einige zu nennen:

• Nicht alle Projektbeteiligte können auf einen gemeinsamen Projektordner zugreifen oder es gibt einen solchen gar nicht.
• Die gleichen Dateien werden mehrfach per E-Mail verteilt.
• Die gleiche Datei ist an verschiedenen Orten gespeichert. Welche die aktuelle Version ist, ist unklar.
• Wichtige Dateien werden auch gar nicht abgespeichert, weil die Zuständigkeit dafür nicht klar ist.
• Zu tiefe Staffelung der Ordner - Dateien gehen nicht auf.
• Es gibt keine Regeln für die Ablage von E-Mails oder sie werden nicht eingehalten.
• Die E-Mail-Flut ist fast nicht zu bewältigen.
• Eine Übersicht über den tatsächlichen Projektstand ist nicht schnell zu bekommen.
• Dauernde Fragen der Art: Wo kommen Fotos von Anlageteilen hin, die wir vielleicht in 3 Jahren wieder brauchen?

Kommt Ihnen das bekannt vor? Nein? Dann klappen Sie das Buch wieder zu und lesen Sie etwas Schöneres.

Ach, Sie haben noch weiter gelesen? Dann herzlich willkommen. Wir hoffen, Ihnen ein paar nützliche und sogar interessante Stunden bereiten zu können.

Was sind die Auswirkungen?

Den meisten Projektbeteiligten ist gar nicht klar, in welch gigantischem Ausmaß eine unstrukturierte Projektablage eine Verschwendung an Zeit, Nerven, Energie und Erfolg darstellt.

• Unnötiger Aufwand zum Ablegen: Ich weiß nicht, wo’s hinkommt. Also muss ich länger überlegen und tu’s schnell auf den Desktop oder ich speicher’s ein paar Mal ab.
• Unnötiger Aufwand, um ein Dokument zu finden.
• Doppelarbeit, wenn ich ein Dokument nicht finde und nochmal schreiben muss oder wenn ich die falsche Version verwende und alle Änderungen umsonst waren.
• Ich kann auf ein Dokument nicht zugreifen, weil es keine gemeinsame Projektplattform gibt. Also muss ich es von einem anderen Projektmitglied anfordern. Also entstehen bei mir Wartezeiten und Unterbrechungen.
• Und das andere Projektmitglied, das ich anrufe oder dem ich eine Mail schreibe, wird auch unterbrochen und verliert an Produktivität. In projekt-orientierten Unternehmen (IT, Bau usw.) machen die internen E-Mails oft schon den Hauptteil der E-Mail-Flut aus.
• Die Wartezeiten und Unterbrechungen zwingen zum Multitasking. Der Work in Progress kann nicht sinnvoll begrenzt werden. Hektik und Stress nehmen zu.
• Manchmal geht der Überblick über die eigenen anstehenden Aufgaben verloren. Das führt zu schlechtem Gewissen und Angst.
• Schließlich können nicht auffindbare Dokumente zu Einnahmeverlusten führen. Zum Beispiel, wenn man dem Kunden nicht nachweisen kann, dass er eine bestimmte Auftragserweiterung abgezeichnet hat.

Viele dieser negativen Auswirkungen sind messbar oder zumindest verlässlich schätzbar. Nach unseren Erfahrungen kostet eine unstrukturierte Ablage zwischen 4% und 12% der Personalkosten in Projekten. (Erscheint Ihnen das zu hoch geschätzt? Dann fordern Sie unseren Selbstbewertungsbogen an und machen sich selbst ein Bild von Ihrer Situation. Bezugsquellen am Ende des Buchs.)

Überblick über unsere Werkzeuge

Um die schlechte Nachricht gleich vorwegzunehmen: Es gibt nicht „die“ Lösung.

Die Probleme stellen sich in vielen Unternehmen, Behörden und freigemeinnützigen Einrichtungen ähnlich dar. Aber daraus folgt leider nicht, dass es auch die gleiche Medizin ist, die hilft. Sondern je nach Größe der Projekte, ihrem Projektprofil und auch der Struktur des Unternehmens (an einem oder mehreren Standorten, mit stark hierarchischem Aufbau oder eher einer Teamkultur usw.) bieten sich verschiedene Ablageformen an.

Daher erklären wir am Anfang dieses Buches, was überhaupt ein Projekt ist, welche unterschiedlichen Projektprofile es gibt und welche verschiedenen Ablagetypen sich daraus ergeben.

Dann folgen verschiedene Kapitel, pro Ablagetyp eines:

• Wir widmen ein Kapitel dem Ad-hoc-Projektmanagement. Wie legen wir Dokumente am besten in kleineren Projekten ab.
• Dann folgen zwei Kapitel über die Ablage in Wasserfallartigen Projekten. Das sind Projekte, die sich gut in Phase aufteilen lassen.
• Das nächste Kapitel zeigt Vorschläge für die Ablage in agilen Projekten, z. B. solchen bei den Scrum als Gestaltungsrahmen benutzt wird.
• Auch für komplexe Projekte, bei denen die Einzelteile zu einem Gesamtergebnis montiert werden, haben wir uns eine Ablagestruktur überlegt.
• Zum Schluss stellen wir eine Lösung für Projekte unter sehr hohem Zeitdruck vor.

Davon müssen Sie nur das oder die Kapitel lesen, die ihre Projekttypen betreffen. Wir haben Wert darauf gelegt, das Buch so aufzubauen, dass jeder Leser nur die Abschnitte studieren muss, die ihm auch wirklich einen Nutzen stiften.

Wir plädieren in diesem Buch sehr stark für eine gemeinsame Ablage. Daher finden Sie am Ende auch noch ein Kapitel über die Nutzung von Dropbox als gemeinsame Ablageplattform.

An wen richtet sich dieses Buch?

Beim Schreiben haben wir oft an unsere Kunden und Kollegen und an ihre jeweiligen Projektsituationen gedacht. Wir haben uns immer wieder gefragt, wie wir deren Arbeit gut unterstützen können. Viele Lösungen, die wir an anderer Stelle gefunden haben, überzeugten uns nicht. Sie sind nur mit großer Disziplin umsetzbar, unverständlich und gehen nicht auf die Besonderheiten der Projekte ein. Unsere Lösungsvorschläge richten sich an Projekte in folgenden Branchen:

• Bauprojekte
• IT-Projekte, Softwareentwicklung (klassische und agile Herangehensweisen)
• Projekte bei öffentlichen Organisationen und kommunalen Betrieben
• Projekte im Dienstleistungsbereich

Ablage von Projektdokumenten lindert sofort die Schmerzen von E-Mail-Flut. Jeder kann sich um das Thema Ablage kümmern. Beim Schreiben haben wir vor allem an folgende Rollen gedacht:

• Projektleiter, Projektmanager
• Mitarbeiter in Projekten
• Mitarbeiter und Verantwortliche in Programmbüros und Projektunterstützungsbüros
• Qualitäts- und Dokumentenmanagementbeauftragte
• Bereichs- und Abteilungsleiter
• IT-Verantwortliche

Erst die Struktur, dann die Software!

„Hast du ein Problem, dann beschaff dir eine Software.“ – So lautet unser Ansatz nicht.

Wir stellen Ihnen im Buch die passenden Ordnungsstrukturen vor, die Sie in Ihren Projekten optimal unterstützen. Wenn wir zu diesen Ordnungsstrukturen Beispiele bringen, dann immer in Form von Windows-Ordnern. Ganz einfach deshalb, weil wir davon ausgehen, dass ein großer Teil von Ihnen darüber hinaus überhaupt keine Software benötigt, um eine gute Übersicht über ihre Projekte zu erhalten. Diese Darstellung hat für Sie einen sehr großen Vorteil: Sie können gleich loslegen und die hier vorgestellten Rezepte ausprobieren. Sie müssen nicht erst eine Software beantragen und beschaffen und installieren und customizen und schulen.

Unser Motto lautet: „Intelligente Software für intelligente Strukturen – nicht anstelle intelligenter Strukturen.“ Der neue moderne Sharepoint-Server ist völlig für die Katz‘, wenn Sie sich nicht vorher genau überlegt haben, welche Projektstruktur Sie dort wie abgebildet haben wollen. Aber wenn Sie diese Vorarbeit geleistet haben und Ihre Projekte so groß sind, dass ein Sharepoint oder ein Dokumentenmanagementsystem, dann ist auch dafür gesorgt, dass eine derartige Investition sich lohnt.

Fragen Sie uns

Wir hoffen natürlich, dass dieses Buch all Ihre Fragen beantwortet. Sollte aber doch eine Frage offen geblieben sein oder wenn Sie Anregungen und Kritik haben, dann lassen Sie es uns wissen. Sie können uns zum Beispiel eine E-Mail schreiben, und wir antworten Ihnen prompt (es sei denn, die E-Mail geht in unserer Ablage verloren).

Die Kontaktmöglichkeiten finden Sie am Anfang des Buches.

Kapitel 1 Was ist ein Projekt?

Über dieses Kapitel

• Inhalt dieses Kapitels: Dieses Kapitel zeigt, warum Projekte aus Sicht der Ablage besondere Situationen sind.
• Zielgruppe dieses Kapitels: Alle Projektbeteiligten, die operativ mitarbeiten, d. h. Dokumente und E-Mails lesen und erstellen.

Sie, liebe Leserin und lieber Leser, wissen sehr gut, was ein Projekt ist und wir ersparen Ihnen die üblichen Definitionen. Für das Erste reicht es zu wissen, dass ein Projekt eine „Ich-bin-mir-nicht-sicher-Aufgabe“ ist. Das Gegenteil von Projekt ist Routine. Tabelle 1 zeigt Bereiche, in denen sich Projekt- und Routineaufgaben unterscheiden.

Im Laufe des Projekts sollte die Unsicherheit weichen und Gewissheit entstehen. Mit Projektmanagement wollen wir die Unsicherheit in den Griff bekommen.

Wenn Menschen in Projekten zusammenarbeiten, erledigen sie zwei Arten von Aufgaben:

• Sie erzeugen Ergebnisse. Das können Konzepte oder Leitfäden sein, eine geänderte Aufbauorganisation oder Softwareprogramme.
• Sie regeln die Abläufe, um die Ergebnisse zu erzeugen. Wir bezeichnen dies als Projektmanagement oder Projektsteuerung.

Die zweite Art von Arbeit – das Projektmanagement – wird oft als notwendiges Übel oder Bürokratie angesehen. Aber sie ist leider wichtig, weil ohne sie die erste Art von Arbeit – das Erzeugen von Ergebnissen – nicht möglich ist.

Aus Sicht der Ablage stellt ein Projekt eine besondere Situation dar:

• Das Projekt wird von einem Team bearbeitet, das sonst nicht zusammenarbeitet.
• Es gibt keine definierten Prozesse und damit keine definierten Ablageorte für Dokumente.
• Es gibt Leute, die innerhalb und außerhalb der eigenen Organisation mitarbeiten. Dokumente werden daher überwiegend über E-Mails ausgetauscht.

Die Zusammenarbeit erhöht die Unsicherheit noch weiter. Mit Projektmanagementmethoden versuchen Organisationen, die Unsicherheit zu beherrschen. Eine Methode ist das Gegenteil von Versuch und Irrtum. Wer eine Methode anwendet, greift auf das Wissen derer zurück, die viele Fehler gemacht haben.

In unserer Beratungspraxis treffen wir auf folgende Methoden:

• PRINCE2: PRINCE steht für Projects in controlled environments. Diese Projektmanagement-Methode war ursprünglich in Großbritannien von der Regierung als Standard für IT-Projekte entwickelt worden. Sie wurde aber bald auch für ganz andere Projekte angewendet, weil sie unabhängig von den konkreten Inhalten des Projekts ist. Typisch für PRINCE2 ist das Denken in Projekt-Produkten. Hierbei unterscheidet sie zwischen Ergebnisprodukten (also Produkten, die nach Projektende noch benötigt werden) und Produkten zur Projektsteuerung (“Managementprodukten”). Diese Unterscheidung spielt auch eine große Rolle in unserer Projektablage. (Copyright-Hinweis: PRINCE2® is a Registered Trade Mark of the Cabinet Office.)
• Scrum: Scrum ist ein Rahmen für die Zusammenarbeit im Team. Die Autoren von Scrum lehnen es ab, Scrum als Methode zu bezeichnen. Für sie bildet Scrum einen Gestaltungsrahmen. Dennoch ist es für uns eine Methode für Teams.
• Ad-hoc: Diese Methode ist am weitesten verbreitet. Aber eigentlich ist sie überhaupt keine Methode. Hier wird nach keinem Plan oder Verfahren vorgegangen. Man kann aber trotzdem auch in Ad-hoc-Projekten eine sinnvolle Ablagestruktur definieren, und deshalb haben wir ihr auch ein Kapitel gewidmet.

Es gibt noch eine Vielzahl von weiteren allgemeinen und spezifischen Verfahren, um Projektaufgaben zu bearbeiten. Diese Methoden sind gut dokumentiert. Unserer Erfahrung nach findet sich in der Dokumentation selten ein Hinweis auf die Ablage. Ein Großteil der Dokumente, die Projektteams heute erzeugen, bearbeiten, weiter verwenden oder als Ausgangsbasis für Planungen oder andere Ergebnisse benutzen, wird elektronisch erzeugt.

Daher brauchen Projektteams eine Anleitung dafür, wie mit elektronischen Dokumenten umgegangen wird. Dies versuchen wir mit diesem Buch.

Wo Sie weiterlesen können:

Wenn Sie gerne etwas tiefer hinter die Kulissen von Projekten schauen wollen, machen Sie mit den nächsten beiden Kapiteln weiter. Wenn Sie aber lieber schnell zur Praxis kommen wollen, springen Sie gleich zu Kapitel 6 „Verschiedene Projektmanagement-Methoden“. Dort können Sie erfahren, was für ein Projekttyp bei Ihren Projekten vorliegt und in welchem Kapitel Sie die entsprechende Ablage beschrieben finden.

Kapitel 2 Wie eine E-Mail- und Dokumentenflut entsteht

Über dieses Kapitel

• Inhalt dieses Kapitels: Dieses Kapitel zeigt, wie die Anzahl von E-Mails und Dokumenten ansteigt, wenn man keine gemeinsame Ablage und keine gemeinsame Aufgabenliste benutzt.
• Zielgruppe dieses Kapitels: Alle Projektbeteiligten, die operativ mitarbeiten, d. h. Dokumente und E-Mails lesen und erstellen.

Wohin mit den E-Mails?

Als wir mit dem Projektteam unseres Kunden über Ablage redeten, lief die Diskussion solange gut, bis wir sagten: „Am besten legt man E-Mails in die (gleiche) Ablage wie alle anderen Dokumente auch.“ Die Äußerungen der übrigen Teilnehmer der Runde lässt sich sozusammenfassen: „Wer meint, dass E-Mails in die Ablage gehören, verkennt die Situation. Wenn man die vielen E-Mails (auch noch) ablegen muss, kommt man gar nicht mehr zur eigentlichen Arbeit.“

Stimmt das Argument? Was ist denn nun ein sinnvoller Umgang mit E-Mails?

Das Problem in solch einer Diskussion ist nicht die Ablage der E-Mails, sondern die hohe Zahl von E-Mails, die die Mitarbeiter bekommen. Passend dazu hatte das Handelsblatt am 27.11.2012 die Titelgeschichte mit dem Thema „Der E-Mail-Wahnsinn“ (Handelsblatt 2012). Warum bekommen die Mitarbeiter überhaupt soviele E-Mails?

Aus unserer Sicht gibt es zwei Hauptursachen für die E-Mail-Flut:

• Fall 1: Die Kollegen finden nicht die Dokumente, die sie brauchen. Beispiel: “Kann mir jemand den aktuellen Projektplan schicken?”
• Fall 2: Die Kollegen haben kein besseres System, um Aufgaben zu verteilen und zu erledigen. Beispiel: “Kannst Du bitte den Projektplan aktualisieren und ihn mir dann schicken?” Macht das wirklich soviel aus? Rechnen wir die Fälle einmal durch.

Fall 1: Frage nach Dokumenten

Nehmen wir mal an, Alice fragt Bob und Charlie nach dem aktuellen Projektplan. Bob hat ihn, Charlie nicht. Das führt zu folgenden Nachrichten:

• t0: Ausgangsituation, 1 Dokument.
  • Alice: 0 E-Mails
  • Bob: 0 E-Mails und 1 Datei in der Ablage
  • Charlie: 0 E-Mails
• t1: Alice an Bob und Charlie: “Kann mir jemand den aktuellen Projektplan schicken?” Das macht zusammen 4 Dokumente.
  • Alice: 1 neue E-Mail in der Outbox
  • Bob: 1 neue E-Mail in der Inbox (und 1 Datei in der Ablage)
  • Charlie: 1 neue E-Mail in der Inbox.
• t2: Charlie an Alice, cc an Bob: “Ich habe den Plan nicht.” Dies sind zusammen 7 Dokumente (3 E-Mails mehr).
  • Alice: 1 neue E-Mail in der Inbox
  • Bob: 1 neue E-Mail in der Inbox
  • Charlie: 1 neue E-Mail in der Outbox
• t3: Bob an Alice, cc an Charlie: “Hier ist der Plan.” Die Postfächer schwellen nun auf 13 Dokumente an (3 E-Mails und 3 Dateien mehr).
  • Alice: 1 neue E-Mail und 1 neue Datei in der Inbox
  • Bob: 1 neue E-Mail, 1 zus. Dateikopie in der Outbox
  • Charlie: 1 neue E-Mail und 1 neue Datei in der Inbox
• t4: Alice legt den Plan ab und bedankt sich bei Bob: “Danke für den Plan.” Jetzt sind es schon 16 Dokumente (2 E-Mails und 1 Datei mehr).
  • Alice: 1 neue E-Mail in der Outbox und 1 zus. Dateikopie in der Ablage
  • Bob: 1 neue E-Mail in der Inbox
  • Charlie: keine Änderung

Sind Sie noch da? Eine einfache Anfrage nach einem Dokument unter 3 Teamkollegen führt zur Ablage von 11 E-Mails und 4 Dateien (1-mal war der Plan ja schon da). Die Tabellen 2.1 und 2.2 zeigen die Zusammenfassung. Die Anzahl erhöht sich, wenn mehr Leute mitreden.

Wundern Sie sich noch über die E-Mail-Flut? Sie ahnen schon, was die Lösung sein könnte. Doch sehen wir uns an, was passiert, wenn man Kollegen per E-Mail bittet, eine Aufgabe zu erledigen.

Fall 2: Abstimmung von Aufgaben

Alice bittet Bob, den Projektplan zu aktualisieren und nimmt Charlie in cc.

• t0: Ausgangsituation, 1 Dokument.
  • Alice: 0 E-Mails, 1 Datei in der Ablage
  • Bob: 0 E-Mails
  • Charlie: 0 E-Mails
• t1: Alice an Bob: „Kannst Du bitte den Projektplan aktualisieren und ihn mir dann schicken?“ Damit erzeugt Alice 6 Dokumente.
  • Alice: 1 E-Mail und 1 Datei in der Outbox
  • Bob: 1 E-Mail und 1 Datei in der Inbox
  • Charlie: 1 E-Mail und 1 Datei in der Inbox
• t2: Bob an Alice, cc an Charlie: „Projektplan ist überarbeitet (siehe Anhang).“ Auch Bob erzeugt damit 6 weitere Dokumente.
  • Alice: 1 E-Mail und 1 Datei in der Inbox
  • Bob: 1 E-Mail und 1 Datei in der Outbox
  • Charlie: 1 E-Mail und 1 Datei in der Inbox

Auch hier sehen wir, dass eine einfache Anfrage zu 6 E-Mails und 5 weiteren Dokumenten führt (siehe Tabellen 2.3 und 2.4).

In beiden Fällen steigt die Zahl der Dokumente und E-Mails, wenn …

• … sich mehr Kollegen abstimmen müssen,
• … die Kollegen mehr Nachrichten brauchen, um das richtige Dokument zu finden,
• … mehr Systeme beteiligt sind.

Schätzen Sie einmal für sich selbst ab, wie oft Sie solche E-Mails an Ihr Team schreiben (oder von ihm bekommen). Nehmen wir an, Alice, Bob und Charlie bekommen und senden pro Woche jeweils 100 E-Mails. Das sind zusammen 300 E-Mails. Jeder Fall tritt einmal am Werktag auf.

• Im Fall 1 hilft eine gemeinsame Ablage. Jeder weiß, wo die Dokumente liegen. Dies reduziert die Gesamtzahl um 55 Stück (5 Tage x 11 eingesparte E-Mails).
• Im Fall 2 braucht das Team eine gemeinsame Aufgabenliste und Routinen. Zum Beispiel sollte jeder einmal am Tag auf die Liste sehen. Die gemeinsame Liste und die Routine sparen dem Team 30 E-Mails (5 Tage x 6 eingesparte E-Mails).

Durch zwei Maßnahmen reduzieren die drei Kollegen die Anzahl von 300 auf 215. Alice, Bob und Charlie bekommen pro Woche 28% weniger E-Mails. Eine E-Mail-Flut ist vor allem an vielen internen E-Mails zu erkennen.

Kapitel 7 Ablage für Ad-hoc-Projekte (PM-Methode 1)

Über dieses Kapitel

• Inhalt dieses Kapitels: Eine einfache Methode der Projektablage für kleinere Projekte wird vorgestellt.
• Zielgruppe dieses Kapitels: Alle, die in Projekten mit wenig Unsicherheit arbeiten. Die Zahl der Dokumente im Projekt sollte 500 nicht übersteigen.
• Nötige Vorkenntnisse: Sie sollten Kapitel 6 über die verschiedenen Projektmanagement-Methoden gelesen haben.

Beispiel und Definition

Beispiel: Die Thüringer Heimstiftung (THS) ist ein gemeinnütziges Unternehmen, das zehn Einrichtungen für Pflegebedürftige, Behinderte und Jugendliche betreibt. Die THS will ein Beschwerdemanagement für ihre Klienten und deren Angehörigen aufbauen. Projektleiter wird der neue Qualitätsmanagementbeauftragte (QMB), Herr Meinrath. In einem ersten Teilprojekt sollen fünf Heime und die zentrale Verwaltung der THS in das Projekt einbezogen werden.

Herr Meinrath möchte eine gemeinsame Informationsplattform für alle Projektbeteiligten aufbauen, um größtmögliche Transparenz zu gewährleisten und den E-Mail-Verkehr zu minimieren.

Zu Projektstart wird ein Projektplan aufgestellt. Er enthält erst einmal 10 festgelegte Termine und eine Grobplanung für den weiteren Verlauf. Das Projekt birgt keine besonderen Risiken. Seine Komplexität ist gering. Es hat zwar einen Zielzeitpunkt des Projektabschlusses, aber dieser ist nicht unverrückbar. Die Zahl der Projektbeteiligten ist mit rund 12 Personen überschaubar.

Ein derartiges Projekt bezeichnen wir als Ad-hoc-Projekt. Es ist keine Standard-Projektmanagement-Methode festgelegt, und es wird viel „von Mal zu Mal“ geplant.

Die Zeit als führendes Merkmal

In Ad-hoc-Projekten spielen Zeiträume und Termine eine Hauptrolle. Es gibt Sitzungen, Besprechungen und Präsentationstermine. Daher bietet sich an, die Zeit als führendes Merkmal zur Ablage zu nutzen. Es ist besonders trennscharf, d.h. es spart Denkaufwand beim Ablegen.

Beispiel: Der Projektleiter, Herr Meinrath, führt sogenannte Meilensteinordner ein, über die ein Bezug zu einem bestimmten Termin hergestellt wird (siehe Abb. 7.1).

Alle Dokumente, die für einen bestimmten Termin benötigt werden, kommen in diesen Ordner. Das kann zum Beispiel eine Agenda sein oder Materialien, mit denen sich Teilnehmer auf die Sitzung vorbereiten können. Auch das Protokoll einer Sitzung kommt noch in diesen Meilensteinordner.

In der Abbildung sind neun Meilensteinordner aufgeführt. Jeder Ordner erhält einen Namen nach folgender Regel: Mxx Teilnehmerkreis Art_des_Termins Datum

Also z. B. der Ordner “M04 PG Vorort_Johanneswerk 2013-01-27” enthält alle Unterlagen, die im Vorfeld eines Vorort-Termins der Projektgruppe beim Johanneswerk am 27. Januar 2013 erstellt wurden, inklusive eines eventuellen Ergebnisprotokolls.

Es ist nicht das Ziel, eine perfekte Ablage zu schaffen, bei der die Anwender überhaupt keine Zeit mehr auf das Suchen verwenden müssen. Es geht darum, die Summe der Zeit für Suchen und Ablegen zu minimieren. Es ist wichtig, dieses Ziel zu verstehen, damit die Ordnung im Team akzeptiert und in der Realität angewendet wird.

Klammerordner

Beispiel: Zusätzlich zu den Meilensteinordnern hat Herr Meinrath meilensteinübergreifende Ordner erstellt (siehe Abbildung 7.2). In diese Ordner werden Dokumente abgelegt, die als Nachschlagewerke dienen, regelmäßig genutzt und in den einzelnen Meilensteinen verändert werden.

In der Regel gibt es mindestens zwei Meilenstein-übergreifende Ordner. In den ersten Ordner kommen die Projektergebnisse. Deshalb heißt der Ordner auch (Ergebnisdokumente). Das sind die Dokumente, die nach Abschluss der Projektarbeit noch benötigt werden, also in den Routinebetrieb übergehen. In unserem Beispielprojekt kann das das neue Konzept des Beschwerdemanagements sein, ein Ablaufplan dafür usw.

In den zweiten Ordner (Steuerungsdokumente) kommen Dokumente, mit denen das Projekt sich selbst steuert. Das sind zum Beispiel Planungs- und Qualitätsmanagementdokumente wie Projektplan oder Business Case.

Wir nennen diese Verzeichnisse Klammerordner, denn die Klammer bewirkt, dass die Ordner immer oben stehen. Die Dokumente in diesen Ordnern stellen die Wissensdokumente des Projekts dar.

Ein- und Auschecken von Dokumenten aus den Klammerordnern

Wenn Sie aktiv mit den Wissensdokumenten arbeiten, brauchen Sie Regeln zum Ein- und Auschecken der aktuellen Version. Folgende Regeln stellen nur Vorschläge dar. Sie haben sich aber bei verschiedenen unserer Projekte bewährt:

1. Von jedem Wissensdokument gibt es genau eine Version, die die Endung „_token“ trägt. Diese Version ist die aktuelle Version. Wer einen eigenen Beitrag zu einem bestehenden Wissensdokument leisten möchte, muss dazu die token-Version nehmen.
2. Das Dokument wird aus dem Klammerordner in den Meilensteinordner kopiert.
3. Die Version im Klammerordner erhält das Namensende „(token = Mxx)“. Dadurch wird jeder, der das Dokument in diesem Ordner aufruft, darauf verweisen, dass im Meilenstein Mxx gerade eine Überarbeitung dieses Dokuments stattfindet. Alternativ ist natürlich auch eine Verknüpfung möglich.
4. Immer die aktuell gültige Version im Meilensteinordner (= Arbeitsordner) erhält die Namensendung „_token“.
5. Während der Überarbeitung des Dokuments entstehen mehrere Zwischenversionen. Die letzte Version erhält immer die Namensendung „_token“.
6. Die Schlussversion wird zurück in den Klammerordner kopiert. Die vorher noch dort stehende Version mit „(token=Mxx)“ am Ende wird gelöscht.
7. Die letzte Version im Meilensteinordner bekommt das „_token“ am Ende wieder entfernt.

Beispiel: Wir befinden uns in Meilenstein 27 des Projekts und Herr Meinrath möchte den Projektplan überarbeiten. Um zu verhindern, dass eine andere Person seine Zwischenversion versehentlich liest, geht er nach dem o. g. Vorschlag vor:

• Die aktuelle Version des Projektplans befindet sich im Ordner “(Steuerungsdokumente)” und hat den Namen “Projektplan_token.xlsx”.
• Herr Meinrath kopiert diese Token-Version in den Meilensteinordner 27.
• Die Version im Ordner “(Steuerungsdokumente)” wird von “Projektplan_token.xlsx” in “Projektplan (token=M27).xlsx” umbenannt.
• Nach der Überarbeitung kopiert Herr Meinrath die überarbeitete Version “Projektplan_token.xlsx” wieder in den Ordner “(Steuerungsdokumente)”, damit jeder den aktuellen Plan benutzen kann.
• Im Ordner “(Steuerungsdokumente)” wird die “Projektplan (token=M27).xlsx” gelöscht, damit es nur eine aktuelle Version gibt.
• Im Meilensteinordner 27 wird die Datei von “Projektplan_token.xlsx” auf “Projektplan.xlsx” geändert, damit es nur eine Token-Version gibt.

Archivordner

Meilensteinordner, die schon älter sind, kommen in einen Archivordner (siehe Abbildung 7.3). Sonst muss man nämlich mit den Augen ständig alte Meilensteinordner überspringen oder man muss das Fenster scrollen. Für uns sind dies Verursacher von Mikrozeitverschwendungen.

Passen Sie die Ablage an

In Projekten tut sich viel. Die Ablagestruktur muss sich anpassen. Sonst wird sie nicht benutzt.

• Überlegen Sie sich die Namensregeln für die Meilensteinordner, die für Ihr Projekt am besten passen.
• Eventuell brauchen Sie noch andere Klammerordner als die von uns vorgestellten. Zum Beispiel für Vorlagen und Formulare. Oder für Wissensdokumente wie das Organigramm des Unternehmens. Die Entscheidungskriterien dafür sind ganz pragmatisch: Welche Dokumente werden immer wieder „quer“ zu den Meilensteinordnern benötigt?

„Meine Ablage würde aber ganz anders aussehen!“

Die von uns vorgeschlagene Ordnung stößt fast nie auf spontane Zustimmung von Projektleitern und Projektgruppen. Auf der anderen Seite haben nach diesem ersten Zögern viele Projektgruppen diese Struktur praktiziert und sind einigermaßen zufrieden damit. Woher kommt das anfängliche Unbehagen? Zum einen denken wir Menschen eher in „festen Dingen“ als in „Flüssen“. Spontan kommt uns eine Ordnung der Art von Abbildung 7.4 natürlicher vor als eine, die sich einfach an Sitzungen – also an Abläufen - orientiert.

Aber dann kommen die Probleme. Ein Architekt ist ein Lieferant, der u. a. Baupläne liefert. Auf einer Sitzung („Versammlungen mit Externen“) stellt der Architekt vom Büro MA3000 („Lieferanten“) einen ersten Bauplan vor („Pläne“). In welchen dieser drei möglichen Ordner kommt das Dokument jetzt?

Der Projektleiter tut es in das Fach „Pläne“. (Dabei ist, nebenbei, der Zusammenhang zur Sitzung schon zerrissen – denn das Sitzungsprotokoll liegt unter „Versammlungen“). Dann werden von den Bauherren Änderungswünsche geäußert, und der Architekt liefert in der Folge drei neue Versionen: von jedem der vier Stockwerke jeweils einen Übersichtsplan und für jede der acht Wohnungen nochmal einen. Das Fach „Pläne“ beginnt, sich kräftig zu füllen, und wird unübersichtlich. Also wird ein Unterordner „ehemalige Pläne“ angelegt. Die Ordnung wächst spontan und ohne Regeln weiter.

Dieser spontanen Ordnung gegenüber hat unser Meilensteinsystem zwei entscheidende Vorteile:

1. Es ist schlank. Es gibt keine tiefe Staffelung. Man erhält schnell einen Überblick über die Gesamtstruktur, ohne umständliches Klicken.
2. Die Ablage ist trennscharf. Bei der Frage „Wo kommt das Dokument hin?“ gibt es fast nie Probleme.
3. Beim konkreten Arbeiten in der Struktur brauche ich fast nie hin und her zu springen. Wenn ich mich zum Beispiel auf eine Sitzung vorbereite, finde ich alle Vorbereitungsdokumente von anderen eben im nächsten Sitzungsordner. Es kann höchstens mal passieren, dass ich in einem Klammerordner ein übergreifendes Dokument nachschlagen muss. Aber das dauernde „Klick auf – Klick zu“, wie bei thematisch sortierten Strukturen, kommt praktisch nicht vor.
4. Die Ablage bleibt übersichtlich. Die Meilensteinordner veralten schnell, und ich kann sie ab und zu mühelos ins Archiv schieben. Während themenorientierte Ordner dazu neigen, immer länger und länger zu werden.

Das sind unsere Argumente. Probieren Sie die Methode doch einfach mal in einem kleineren Projekt aus.

Wo Sie weiterlesen können:

Wenn Sie Projekte haben, die von vornherein eine feste Struktur haben (quasi vordefinierte Meilensteine), dann lesen Sie das folgende Kapitel. Wenn Sie Projekte haben, die viel komplexer sind, dann sind die darauf folgenden Kapitel für Sie geeignet.

Kapitel 8 Ablage für Wasserfallprojekte (PM-Methode 2)

Über dieses Kapitel

• Inhalt dieses Kapitels: Manche Unternehmen führen bestimmte Projekte immer wieder durch, und diese Projekte durchlaufen immer wieder die gleichen Phasen. Das hat Auswirkungen auf die Projektablage.
• Zielgruppe dieses Kapitels: Organisationen, die ihre Kernprozesse oder Teile davon als Projekte organisieren.
• Nötige Vorkenntnisse: Sie sollten Kapitel 6 über die verschiedenen Projektmanagement-Methoden gelesen haben.

Was ist ein Projekt mit festen Phasen?

Bestimmte Projekte laufen immer wieder nach dem gleichen „Schema F“ ab. Ein einfaches Beispiel: Ein Rechenzentrum definiert für alle Änderungen an der Software- oder Hardware-Umgebung einen Request for Change (RFC), der immer dem gleichen Phasenmuster gehorchen soll.

1. Phase: Analyse und Konzept-Erstellung
2. Phase: Entwicklung (Codierung)
3. Phase: Dokumentation verfassen
4. Phase: Test
5. Phase: Produktivsetzung

Solche Vorgänge wollen wir als Wasserfall-Projekte bezeichnen, weil sie am ehesten dem klassischen Wasserfallmodell gleichen. Die Diskussion, ob man bei „Routine-Projekten“ überhaupt von Projekten sprechen kann, soll hier nicht geführt werden. Und auch die Frage, ob die weit verbreitete Kritik am Wasserfall-Modell berechtigt ist oder nicht, darf uns in diesem Buch nicht interessieren. Hier ist das Thema: Wenn „Wasserfall“ weit verbreitet ist, dann liefern wir dazu die passende Ablagestruktur.

Oft handelt es sich dabei um Projekte, die zum Kerngeschäft einer Organisation gehören. Jede Organisation hat aber auch Projekte, die sie nur einmal alle paar Jahre oder noch seltener durchführt. Zum Beispiel, wenn ein Automobilzulieferer ein neues Verwaltungsgebäude erstellt, besitzt dieses Bauprojekt aus seiner Sicht sicher keine festen Phasen. Sondern er erstellt sich für diesen speziellen Anlass einen einmaligen Projektplan, und seine Ablage kann so aussehen wie in Kapitel 7 beschrieben.

Für die Baufirma aber, die der Automobilzulieferer als Generalunternehmer beauftragt, handelt es sich bei dem Bau um ihr Kerngeschäft, für das sie festgelegte (wenn auch variable) Muster-Projektpläne anwendet. Aus ihrer Sicht also handelt es sich um Projekte mit festen Phasen.

Kanban-Boards

Aber zurück zu unserem RFC-Projekt. Häufig wechselt mit den Phasen auch die Zuständigkeit: Das Konzept wird von einem Programm-Designer erstellt, aber die Codierung macht jemand anderes. Der verfasst dann zwar auch die Dokumentation, aber für den Test ist wiederum ein Dritter zuständig. Oft werden derartige Abläufe über ein Kanban-Board gesteuert (vgl. [Anderson 2011]).

Ablage in Projekten mit festen Phasen

In solchen Projekten kann es sein, dass die Ablagestruktur sich fast vollständig an den Phasen orientiert:

Dokumente, die in einer Phase entstehen, werden im entsprechenden Phasenordner abgelegt. Zum Beispiel würde der Designer im Ordner Phase 1 IT-Konzept arbeiten. Der Software-Codierer dann in den Ordnern Phase 2 Umsetzung und Phase 3 Dokumentation verfassen usw.

Es gibt auch hier einen Klammerordner (Steuerungsdokumnete) mit Dokumenten, die keiner einzelnen Phase zugeordnet werden können. Dabei kann es sich z. B. um den Business Case oder (bei externen Auftraggebern) um Angebot und Auftrag handeln. Der Klammerordner ermöglicht, diese Dateien immer wieder quer zu den Phasen zu konsultieren und anzupassen.

Gegenüber der Ablage nach ad-hoc-Meilensteinordnern, die wir in Kapitel 7 vorgestellt haben, weist diese Ablage nach Phasen bestimmte Besonderheiten auf:

a) Die Ablagestruktur wird schon zu Projektbeginn angelegt und nicht nach und nach, im Rhythmus des fortschreitenden Projekts selbst. b) Es gibt keinen Klammerordner „(Ergebnisdokumente)“. Sondern die Ergebnisse, die in bestimmten Phasen erarbeitet werden, bleiben in diesen Phasenordnern stehen. Im obigen Beispiel steht die Dokumentation – in der Regel das wichtigste Ergebnisdokument eines RFC – im Ordner der Phase 3.

Aus Punkt a) folgt, dass man der Ablagestruktur nicht auf einen Blick ansieht, in welcher Phase sich ein Projekt gerade befindet. Denn auch schon ganz am Projektanfang gibt es den Ordner „Phase 5“, obwohl das Projekt sich erst in Phase 1 befindet. Manche Teams haben dieses Problem dadurch gelöst, dass sie den jeweils aktiven Phaseordner zeitweise mit einem Underscore am Anfang versehen haben. Dann rutscht die aktive Phase in der Sortierung nach oben, gleich hinter den Klammerordner.

Andere Teams fanden es unästhetisch, dass sich die Reihenfolge der Ordner veränderte, und sie setzten ein Ausrufezeichen hinter die aktive Phasennummer. Dann muss man etwas genauer hinschauen, um den aktiven Ordner zu finden.

Musterordner

Eine weitere Konsequenz aus diesem Punkt a) ist, dass es Musterordner mit Vorlagen geben kann.

Im Unterordner „Phase 1“ des Musterordners kann jetzt zum Beispiel bereits eine Vorlage Konzept RFC.doc stehen, die den Standardaufbau des entsprechenden Dokuments der Organisation enthält.

Wenn Sie ein Projekt neu anlegen, dann legen Sie zuerst den neuen, leeren Projektordner an. Dann kopieren Sie die Unterordner aus dem Musterordner in den neuen Projektordner. Auf diese Weise haben Sie nicht nur die Unterordnerstruktur schnell angelegt, sondern auch schon die passenden Vorlagen in diesen Unterordnern.

Wo Sie weiterlesen können:

Wenn sich Ihre Projekte nicht strikt an die Standard-Phasenreihenfolge halten, sondern es zu Rücksprüngen kommen kann, so lesen Sie das folgende Kapitel. Für jede andere Projektmanagement-Methode finden Sie im Folgenden ein Kapitel. Wählen Sie evtl. noch weitere die Kapitel aus, die für Ihre Projekte zutreffen.

Kapitel 10 Ablage für agile Herangehensweisen (PM-Methode 4)

Über dieses Kapitel

• Inhalt dieses Kapitels:Eine einfache Methode der Projektablage für agile Projekte wird vorgestellt.
• Zielgruppe dieses Kapitels: Alle, die in Projekten mit Unsicherheit arbeiten.
• Nötige Vorkenntnisse: Sie sollten Kapitel 6 über die verschiedenen Projektmanagement-Methoden gelesen haben.

Beispiel und Definition

Beispiel: Die Firma Agilomatik stellt Software her und hat 25 Mitarbeiter. Sie liefert ihre Produkte an größere Firmen, z. B. für die Automobilindustrie oder für Medienunternehmen. Frau Faber arbeitet im Vertrieb und hat einen neuen Auftrag für ein großes Medienhaus gewonnen. Mit ihrem Team von 6 Softwarespezialisten wird sie eine Anwendung für Smartphones und Tablet-Computer erstellen. Der Kunde von Frau Faber hat eine ungefähre Vision, was er mit der Anwendung erreichen will. Aber er kann keine konkreten Anforderungen liefern, weil er in diesem Bereich keine Erfahrung gemacht hat. Statt den Kunden vertraglich zu einem Pflichtenheft zu zwingen, schlägt Frau Faber vor, alle drei Wochen eine Zwischenversion zu liefern, bei der der Kunde seine wirklichen Anforderungen erkunden und testen kann. Erfahrungsgemäß dauert das Projekt zwischen 6 und 8 Monaten.

Bei einer solchen Ausgangslage ist eine agile Herangehensweise ein guter Weg. Häufig organisieren sich die Teams nach Scrum. Scrum ist ein Gestaltungsrahmen für Teams, der dabei hilft, komplexe Probleme zu lösen. Scrum ist nicht die einzige agile Herangehensweise, aber die am weitesten verbreitete. Andere Vertreter dieser Gattung sind Extreme Programming (XP), Feature Driven Development (FDD), Crystal oder DSDM Atern.

Scrum lässt sich schnell erklären. Wie jede der beschriebenen Herangehensweisen kennt auch Scrum feste Rollen. Neben dem Team, das die eigentliche Arbeit macht, gibt es einen Product Owner, der die Business-Entscheidungen trifft, und den sog. Scrum Master, der auf das Einhalten von Spielregeln achtet. Mehr Informationen zu Scrum gibt es im offiziellen Scrum Guide (siehe [Scrum Guide 2013]).

Die Iterationen (Sprints) als führendes Merkmal

Interessant für die Ablage ist die iterative Arbeitsweise von Scrum-Teams. Die Teams arbeiten in sehr kurzen Phasen, meist 1-4 Wochen. Sie liefern die Projektsalami scheibchenweise.

Diese kurzen Phasen werden Iterationen, bei Scrum „Sprints“, genannt. Jeder Sprint beginnt mit einer gemeinsamen Planungssitzung, in der das Arbeitspensum besprochen wird. Dabei ist der Product Owner dafür zuständig, die Anforderungen in einem bestimmten Format zu liefern. Alle Anforderungen werden im Sprintplanning in konkrete Aufgaben zerlegt. Das Team bearbeitet diese Aufgaben und stimmt sich täglich über den Fortschritt ab.

Am Ende eines Sprints stellt das Team seine Zwischenergebnisse dem Product Owner vor und bekommt sofort ein Feedback, ob die entwickelte Lösung dem Wunsch des Product Owners entspricht. Mit diesem Feedback und neuen Anforderungen geht es dann in die Planung für den nächsten Sprint, und der Zyklus beginnt von neuem. So wird Sprint für Sprint das Endergebnis komplettiert und verbessert. Speziell ausgebildete Scrum-Master achten darauf, dass die Scrum-Regeln eingehalten werden, damit das Team Ergebnisse liefern kann. Sehr wichtig ist das Einhalten der Sprint-Termine. Sprints sind fest getaktet, und auf das Ende eines Sprints folgt schon der Beginn des nächsten. Wenn ein Team sich einmal für eine Sprintlänge (z. B. drei Wochen) entschieden hat, wird dieser Rhythmus auch beibehalten. Diese feste zeitliche Taktung können wir gut für unsere Ablagestruktur verwenden.

Abbildung 10.1 zeigt ein Beispiel für eine Ablagestruktur. Wir sehen jeweils einen Ordner für jeden Sprint. Für jeden neuen Sprint wird ein neuer Ordner hinzugefügt. Zudem sehen wir jeweils einen Ordner für Ergebnisdokumente und für die Projektplanung (Steuerungsdokumente).

Im Kapitel über die Ad-Hoc-Projekte haben wir Meilensteine als Unterordner genommen. Wir nutzen hier das gleiche Prinzip, nur dass wir statt Meilensteine die Sprints als Unterordnerbezeichnungen verwenden. Wie vorher schon beschrieben, können wir abgeschlossene Sprints ebenfalls archivieren.

Wie die Sprintordner weiter unterteilt werden, ist Angelegenheit der Teams. Wichtig sind folgende Punkte:

• Es gibt einen Klammerordner für das aktuelle Sprint-Backlog, in dem die Anforderungen für den aktuellen Sprint festgehalten werden.
• Es gibt einen Klammerordner, in dem Anmerkungen, Zeichnungen, Designvorgaben etc. zu den einzelnen Anforderungen gespeichert werden.
• Es gibt einen Ordner für Testprotokolle o. ä., die für einen Review aufbewahrt werden müssen.
• Alle E-Mails werden gemäß den vereinbarten Regeln im Sprintordner aufbewahrt.

Klare Verantwortung für die Ablage

In agilen Projekten gibt es immer einen Prozessverantwortlichen. Bei Scrum wird diese Rolle vom Scrum Master wahrgenommen. Er oder sie hat damit auch dafür zu sorgen, dass es einen Verantwortlichen für die Ablage gibt. Gemäß einem agilen Prinzip, dass sich das Team selbst organisiert, wird er diese Aufgabe mit dem Team besprechen.

Der oder diejenige, die die Verantwortung übernimmt, ist auch für das Anlegen und Archivieren von Sprint-Ordnern zuständig. Wenn der nächste Sprint beginnt, kopiert der Ablageverantwortliche alle Dokumente, die aufgehoben werden müssen, in den entsprechenden Klammerordner oder den Ordner für den nächsten Sprint. Der Ordner des abgeschlossenen Sprints wird archiviert.

Häufige Probleme bei agilen Teams

Was wir in agilen Projekten häufig vorfinden, ist eine Vielzahl von Sekundärsystemen, die zur Verwaltung eingesetzt werden. Hier ein typisches Beispiel:

• Die Liste mit Aufgaben und die Details werden in der Webanwendung JIRA verwaltet. Zusätzlich gibt es ein physikalisches Bord im Teamraum, auf dem man die laufenden Aufgaben sehen kann. Zum Teil werden elektronische Dokumente an einzelne Stories in JIRA angehängt.
• Die Quelltexte für die erstellte Software werden in Versionskontrollsystemen wie Subversion oder Git gespeichert.
• Fehler werden in Bugzilla verwaltet und per E-Mail kommuniziert.
• Sog. Build-Systeme automatisieren den Zusammenbau der einzelnen Softwareteile. Dabei laufen auch verschiedene Tests, die ihre Ergebnisse per E-Mail verkünden.
• Für Programmierrichtlinien, vereinbarte Standards, Systemdokumentation und Hilfetexte wird ein Wiki benutzt, über das sich jeder informieren kann.
• Hauptkommunikationsmittel ist das E-Mail-System.

Wegen dieser Vielfalt der Systeme rückt die eigentliche Ablage im Dateisystem in den Hintergrund. Sie wird nicht unbedingt als aktives Steuerungsinstrument wahrgenommen. Das ist zum einen verständlich, weil man wegen der Vielfalt nicht noch ein weiteres System benutzen will. Zum anderen sei an dieser Stelle darauf zur Wiederholung hingewiesen, dass die gemeinsame Ablage sich viel besser eignet, den Austausch der Dokumente im Team zu steuern.

Ohne gemeinsame Ablage ist das Team gezwungen, in allen vorhandenen Systemen nach Informationen zu suchen. Fehlende Dokumente werden wieder per E-Mail angefragt und verschickt. Jede Anfrage nach einem Dokument verursacht Wartezeiten und weitere Fehler.

Der Scrum Master ist daher gut beraten, Ablage zum Thema im Team zu machen. Das Team sollte sich klare Regeln geben:

• Es muss für alle Beteiligten klar sein, in welchem System welche Informationen gespeichert werden.
• Das Team sollte sich selbst verpflichten, keine Dokumente per E-Mail zu verschicken, wenn jeder im Team Zugriff auf die gemeinsame Ablage hat.
• E-Mails gehören in die gemeinsame Ablage.
• Das Team sollte sich Metriken geben, mit denen es selbst seinen Umgang mit E-Mails und elektronischen Dokumenten messen kann, um im Rahmen der kontinuierlichen Verbesserung rechtzeitig etwas gegen E-Mail-Flut und Co. zu unternehmen.

Die Vielzahl von Systemen erhöht die Ausfallwahrscheinlichkeit der gesamten Systemkette. Daher lohnt es sich, die gemeinsame Dateiablage als einen sicheren Ort zu nutzen, an dem man die Bauanleitungen für alle anderen verwendeten Systeme findet und zu dem man die Daten aus den anderen Systemen sichert.

Wo Sie weiterlesen können:

Falls Sie es mit komplexen Projekten zu tun haben, in denen verschiedene Teile integriert werden, sollten Sie einen Blick auf das folgende Kapitel werden.

Über die Autoren

Jan Fischbach ist Organisationsberater bei der Common Sense Team GmbH. Seine Schwerpunkte sind Verträge im IT-Bereich (keine Rechtsberatung), Pricing für IT-Leistungen, Projektvorbereitung (PRINCE2, Scrum, Scaled Agile Framework) und Dokumentation. Besuchen Sie sein Profil bei Xing.com oder senden Sie ihm eine E-Mail an j.fischbach@commonsenseteam.de, um mit ihm in Kontakt zu treten.

Wolf Steinbrecher ist Organisationsberater bei der Common Sense Team GmbH. Seine Schwerpunkte als Berater und Trainer finden sich auf den Gebieten Dokumentenmanagement und Activity-Flow-Management. Er hat das Konzept der Prozessorientierten Ablage entwickelt und darüber publiziert. Aktuell beschäftigt er sich mit Adaptive Case Management, also der Unterstützung von schwach strukturierten Prozessen und Wissensprozessen. Sie können ihm eine E-Mail senden an w.steinbrecher@commonsenseteam.de oder auf Xing.com mit ihm kommunizieren.

Wenn Sie Fragen und Anmerkungen zum Thema Projektablage haben, nehmen Sie Kontakt mit uns auf.

Kontaktdaten
Common Sense Team GmbH
Kaiserstrasse 209
76133 Karlsruhe
Deutschland
www.commonsenseteam.de
www.teamworkblog.de