“Man könnte dann später…” – Ein How-To für Projektmanagement

image20160123_112425449
Christ Church, Oxford University – Keinerlei Verbindung zu Projektmanagement, einfach ein wunderschöner Anblick (Photo: Jennifer Bunselmeier)

“Man könnte dann später…” – ein Satz, der regelmäßig in Projekttreffen fällt und der in jedem Projektmanager, jeder Projektmanagerin die Alarmglocken schrillen lassen sollte. Ich bin im Bereich der digitalen Editionen zu Hause, in denen Geisteswissenschaftler und IT-Fachleute zusammen an einer digitalen Publikation arbeiten und hier ist dieser Satz oft ein Indikator für einen Mangel an realistischer Einschätzung der zur Verfügung stehenden Ressourcen im Angesicht unendlich scheinender digitaler Möglichkeiten.

Aus meiner Praxiserfahrung heraus habe ich einige Lösungsstrategien zusammengestellt, mit denen typischen Situationen mit hohem Konflikt- oder Frustrationspotential vorgebeugt werden kann.

“Wer wir sind und was wir machen”-Treffen abhalten

Damit die Kooperation von konventioneller und digitaler Arbeitswelt funktioniert, sind auf beiden Seiten realistische und ehrliche Einschätzungen zum Arbeitsaufwand wichtig. Das bedeutet für die digitale Seite, Verständnis dafür zu wecken, dass hinter jeder “per Knopfdruck”-Funktionalität zunächst der Einsatz von Arbeitskraft, Zeit und Know-how steckt. Die häufig impulsiv als Reaktion auf eine Extra-Feature-Anfrage gegebene Antwort “Gar kein Problem” ist ausgesprochen kontraproduktiv. Zwar ist es tatsächlich kein unlösbares “Problem”, z. B. eine Suchfunktion zu implementieren, aber die Antwort “Gar kein Problem” weckt falsche Machbarkeitsvorstellungen und wertet die digitale Arbeit ab.

Umgekehrt bedarf es auf Editorenseite mitunter einiger Überzeugungskraft, um zu vermitteln, dass es durchaus nicht verschroben ist, wenn im Kritischen Apparat auf einer Unterscheidung von “omisit” und “deest” beharrt wird, oder andere, möglicherweise antiquiert erscheinende “Kleinigkeiten” diskutiert werden, wenn diese der gängigen editorischen Praxis entsprechen und wenn Änderungen oder experimentelle Modernisierungen beim anvisierten Nutzer Irritationen hervorrufen würden.

Ein “Wer wir sind und was wir machen”-Treffen hat sich gerade bei neu anlaufenden Projekten als äußerst hilfreich herausgestellt, um den jeweils anderen Fachbereich besser verstehen und kennenzulernen.

Ziele frühzeitig und einvernehmlich festlegen

Viele Konflikte und zeitraubende einseitige Nacharbeiten können vermieden werden, wenn die Ziele eines Projektes gleich zu Beginn klar und vor allem realistisch festgesetzt werden. Das gilt insbesondere für geisteswissenschaftlich interdisziplinär angelegte Projekte, da Theologen, Linguisten oder Historiker in ein und demselben Projekt mitunter ganz unterschiedliche Schwerpunkte setzen möchten. Alle Seiten müssen von Anfang an mit den Zielvereinbarungen einverstanden sein und sich mit ihren Ideen und Ansprüchen repräsentiert fühlen, andernfalls wird der Konflikt lediglich verschleppt und führt zu Eigenbröteleien und im Ergebnis zu Uneinheitlichkeiten und Unstimmigkeiten innerhalb der Dokumente.

“fertig”-Stadium definieren

Bei einer Printedition ist es einfach – “fertig” ist, was der Verlag zur Druckerei gibt. Im digitalen Raum ist das anders. Jede Veröffentlichung kann jederzeit geändert, aktualisiert oder gänzlich gelöscht werden. Das hat zur Konsequenz, dass jedes Projekt dezidiert ein eigenes “fertig”-Stadium für seine Dokumente definieren muss. Grundsätzlich zu klärende Fragen sind z. B.: Wann müssen Dokumente spätestens veröffentlicht sein (Stichwort Gutachter)? Soll es work in progress Veröffentlichungen geben (Stichwort Visibility)? Welche inhaltlichen und technischen Mindeststandards muss ein Dokument erfüllen, bevor es veröffentlicht wird? Wer führt nach Ablauf der Projektlaufzeit Änderungen durch und welche Änderungen sind dann noch erlaubt? Welche Funktionalitäten müssen wann umgesetzt sein?

Funktionalitäten beschränken auf wenige gute, nicht viele schlechte

Wenn angedachte Features nicht gründlich auf ihren Kosten-Nutzen-Faktor hin überprüft werden, kann es passieren, dass bei Projektende unfertige Funktionalitäten Fehlermeldungen produzieren, oder dass im Extremfall überhaupt keine Publikation zustande kommt, weil Kernfunktionalitäten nicht umgesetzt sind. Wenige solide umgesetzte Funktionen sind besser als viele nicht umgesetzte extravagante Gimmicks.

Arbeitsweise der Mitarbeiter beachten

Manche Mitarbeiter arbeiten lieber wie mit einer Reihe von immer feinmaschiger werdenden Sieben und erstellen erst eine vollständige Transkription, ohne irgendetwas nachzuschlagen, dann folgt ein Arbeitsschritt Worterläuterungen, dann der komplette Sachapparat, dann Personentagging usw. Andere wiederum arbeiten sich lieber von einer Textstelle zur nächsten vor und gehen erst weiter, wenn die Tiefenerschließung abgeschlossen ist. Auf diese unterschiedlichen Arbeitsweisen muss bei der Festlegung von Milestones und ToDo-Listen Rücksicht genommen werden, da diese sonst eher frustrieren als helfen.

Bereitschaft der Mitarbeiter zur Arbeit mit digitalen Werkzeugen prüfen

Eine für mich als “digital native” überraschende Erkenntnis war, dass nicht jeder, der an einem digitalen Projekt arbeitet, auch per definitionem von den neuen digitalen Methoden begeistert oder von ihrer Sinnhaftigkeit überzeugt ist. Aber warum arbeitet jemand, der selber nie oder nur in geringem Maße digitale Ressourcen nutzt und im Zweifelsfall immer zunächst zum altbekannten, vertrauten Buch greift, in einem digitalen Projekt? Der Grund ist so einfach wie ernüchternd: das Geld. Ohne irgendeinen digitalen Anteil ist es schlicht schwer, Fördermittel zu bekommen. In dem Fall ist vor allem viel Überzeugungsarbeit gefragt und auf extravagante, experimentelle neue Tools sollte besser verzichtet werden.

Überzeugungsarbeit leisten und Vorteile des Digitalen hervorheben, ohne dabei die Printedition abzuwerten

Von digitaler Seite werden die Printedition mitunter als veraltet und ihre Anhänger als Fossilien betrachtet. Wird diese Einstellung so auch nach Außen getragen, erzeugt das bei Editoren naturgemäß eher Widerstand als Bereitschaft, sich auf das Neue einzulassen. Man kann die Vorteile einer digitalen Edition auch hervorheben, ohne dabei die Printedition abzuwerten.

Arbeitsmittel und Ausgabe am Grad der digitalen Kompetenz ausrichten

Die Wahl der Arbeitsmittel (Oxygen oder Word?) und der Ausgabe(-formate) (interaktive Website oder schlichter HTML-Text?) hängt stark davon ab, wie hoch der Grad an digitaler Kompetenz bei den Mitarbeitern ist.

Gerade der Wechsel vom Arbeiten in Word zum Arbeiten mit XML verlangt von Editoren ein grundsätzliches strukturelles Umdenken, da nicht nur die Oberfläche, sondern auch die Herangehensweise eine völlig andere ist. In Word wird das Layout der Ausgabe gestaltet, in XML hingegen die Struktur festgehalten, die erst in einem zweiten Schritt in eine Ausgabe übersetzt wird. Etwas abstrakt zu kodieren, ohne sofort die gewohnte Ausgabe vor sich zu sehen, ist für viele Editoren ungewohnt und unangenehm.

Ich finde es nicht verwerflich, wenn in einem digitalen Projekt nicht in XML, sondern mit Word gearbeitet wird, besonders, wenn noch wenig digitale Kompetenz oder großer Zeitdruck (und somit wenig Zeit zum Einarbeiten) vorhanden sind. Es ist besser, von Word-Erfahrenen viele einheitlich durch Formatvorlagen gegliederte Worddokumente zu bekommen, die in einem zweiten Schritt in saubere, einheitliche XML-Dokumente umgewandelt werden, als in nur einem Schritt von XML-Neulingen viele uneinheitliche, fehlerhafte XML-Dokumente geliefert zu bekommen, die dann erst arbeits- und zeitintensiv bereinigt werden müssen.

Erlaubt sollte sein, was ein gutes Ergebnis liefert.

Notwendigkeit und Umsetzbarkeit von Schulungen prüfen

Sind Schulungen (in Word, Oxygen, XML, html) nötig? Sind sie zeitlich und finanziell machbar? Wie wahrscheinlich ist es, dass zwischendrin neue Mitarbeiter und Hilfskräfte geschult und eingearbeitet werden müssen?

Gerechte und realistische Schnittstelle zwischen Editoren und IT finden

Bei digital erfahrenen Mitarbeitern, die einen Großteil der Kodierungsarbeit selber übernehmen (korrekte Kodierung, Metadaten, Validierung), kann der Arbeitsanteil der digitalen Seite geringer ausfallen, bzw. es bleibt mehr Raum für das Erproben innovativer Methoden. Liegt der umgekehrte Fall vor, muss für die digitale Nacharbeit (Worddokument in XML-Dokument wandeln, unsaubere XML-Dokumente bereinigen, Validierung und Nachkodierung übernehmen etc.) mehr Zeit und Arbeitskraft eingerechnet werden (Stichwort halbe Stelle / ganze Stelle?)

Projektmanagement als eigenständigen Aufgabenbereich einplanen

Das Projektmanagement sollte von vornherein ein zentraler und eigenständiger Aufgabenbereich sein und nicht “nebenbei” betrieben werden. Ein gut organisiertes Projektmanagement kostet Zeit (und somit Geld), rechnet sich aber, denn es erspart den Projektmitarbeitern zeitraubende Eigenorganisation und enorm viel Sucharbeit und lässt ihnen so mehr Zeit für inhaltliche Arbeit. Ein gutes Projektmanagement muss die Frage: “Wo findet sich der aktuelle Stand der Projektdaten” schnell, eindeutig und ohne lange Erklärungen beantworten können (Stichworte Dokumentation und Masterdateien).

Verantwortlichkeiten und Ansprechpartner ausweisen

Es sollte immer für jeden ersichtlich sein, wer an welchen Dokumenten und Listen arbeitet und wer Ansprechpartner bzw. Verantwortlicher ist.

Infrastruktur festlegen

Für das Projektmanagement hat sich das Dariah Wiki bewährt, als Datenspeicher trotz aller Vorbehalte Dropbox, da die meisten Mitarbeiter mit dem System vertraut sind.

Praktikable Workflows festlegen

Eine große Gefahr bei Projekten mit mehreren Mitarbeitern und mehreren Dokumenten ist die, dass gleichzeitig an unterschiedlichen Dokumentversionen gearbeitet wird. Ein klarer Workflow beinhaltet daher idealerweise 1. die Reihenfolge, in der Mitarbeiter auf Dokumente zugreifen (Editor (Transkription) > Korrektor (Kommentar) > Editor (Nachbearbeitung) > IT (digit. Aufbereitung) >…) und “sperrt” die Dokumente für die jeweils anderen Gruppen, 2. die klare Festlegung, wo welches Dokument liegt (Ordnerstruktur, Masterdateien).

Masterdateien pflegen

Für jede Editionseinheit wird eine Masterdatei geführt, die per Definition als “aktueller Stand” gilt. Lokale Kopien, selbst wenn sie einen neueren Stand darstellen, sind zwar ein legitimes und praxisnahes Arbeitsmittel, gelten aber aus Projektsicht als non existent. Versionen mit typischen Endungen wie “_alt”, “_test”, “_(2)” oder “_kopie” haben im Masterordner nichts zu suchen.

Editorische Praxis schriftlich fixieren

Editionsrichtlinien, Terminologie im Kritischen Apparat etc. sollten frühzeitig verbindlich festgelegt und an prominenter, leicht zugänglicher Stelle schriftlich fixiert werden, um Wildwuchs zu vermeiden. Falls Editoren mit Ausdrucken dieser Richtlinien arbeiten, muss sichergestellt werden, dass sich die Regeln nicht permanent ändern.

Übersichtslisten führen

Bei einer großen Zahl von Editionsdateien ist eine Übersichtsliste (Nummer, Titel, Bearbeiter, Referenz-ID,…) sinnvoll, z. B. um ein einheitliches projektinternes Zitieren zu ermöglichen. Auch Kurztitel für zitierte Literatur oder Namensansetzungen entwickeln ohne Konvention schnell ein Eigenleben.

ToDo-Listen führen und pflegen

Achtung: bei öffentlich geführten ToDo-Listen droht Gefahr einer Überwachung der Mitarbeiter. Priorisierte Listen mit Dringlichkeitsstufen hoch, mittel und niedrig sowie einer Kommentarspalte für Anmerkungen oder Rückfragen haben sich bewährt.

Praktikable, kleinschrittige Milestones festsetzen und abhaken

Es bietet sich an, Milestones pro Dokument anzusetzen, z. B. “Transkription vollständig”, “Sachkommentar bereit zur Veröffentlichung”, “Korrekturdurchgang duch xy erfolgt”, “Korrekturen eingearbeitet”, “Rechtschreibung geprüft”, “an IT-Stelle weitergegeben”, “validiert gegen Schema xy”,…

Deadlines festlegen und einhalten

Eine gut geführte Übersicht über Deadlines ist nutzlos, wenn es niemanden gibt, der dafür sorgt – sorgen kann –, dass sie auch eingehalten werden. Eine gut gepflegte Milestones-Liste kann ein mögliches Instrument sein, um Mitarbeiter auch bei hierarchischem Schiefstand auf eventuelle Defizite hinzuweisen.

Externe Rahmenbedingungen (Projektmittel und Projektlaufzeit) im Auge behalten

Wenn nicht sichergestellt werden kann, dass die Umsetzung einer neuen Idee innerhalb der gegebenen Zeit und mit den vorhandenen finanziellen und personellen Mitteln umsetzbar ist, muss sie leider ein Desiderat bleiben. Je weiter fortgeschritten das Projekt ist, desto sorgfältiger müssen radikale Umwälzungen (z. B. Umkodierungen) durchdacht werden.

Dokumentation pflegen

Für alle Entscheidungen, Kodierungsrichtlinien, Infrastruktur etc. gilt: Was nicht schriftlich am dafür vorgesehenen Ort (Ordner für Protokolle, Kodierungsrichtlinien im Wiki,…) festgehalten wird, existiert nicht. Diskussionen per Mail haben die Tendenz, ergebnislos zu bleiben oder, wenn es eine Entscheidung gibt, verliert sie sich im Emailpostfach. Um diese Ergebnisse zu bewahren, müssen sie in die Dokumentation übertragen werden.

Backup und Versionskontrolle der Projektdaten sicherstellen

Wenn dem Backup-System nicht vertraut wird, beispielsweise weil im Ernstfall Daten erst nach Wochen wieder hergestellt werden, oder weil unbemerkt und ungewollt Überschreibungen passieren können, gibt es schnell eine große Anzahl an privaten Backups und ein begründetes Misstrauen gegenüber dem Masterdateien-System.

Generelle Gefahrenstellen

  • von Beginn an Uneinigkeit über Projektziele
  • fehlendes Wissen über (und daraus resultierend Verständnis für) die Arbeit der anderen
  • fehlende Projektleitung (keine Kontrolle über die Durchsetzung der Ziele und Einhaltung von Festlegungen)
  • mangelhaftes Projektmanagement (keinen Überblick über Deadlines, Aufgaben, Workflows)
  • fehlende Dokumentation (Aufgaben, Ziele, Workflows, Editionsrichtlinien, Zitierweisen,…)
  • fehlende Protokolle über Entscheidungen (in der Gruppe oder auch zwischen Einzelpersonen)
  • fehlende konsequente und praktikable Workflows
  • ungeklärte (oder nicht vertrauenswürdige) Versionierungs- und Backupworkflows
  • Versionswirrwarr (persönliche Kopien, Korrekturversionen, Testversionen)
  • unüberlegte Hauruckaktionen weil eine schnelle Lösung gewünscht wird

Und noch ein praktischer Tipp zum Schluss: wenn auf den eingangs angeführten Satz “Man könnte dann später…” reagiert wird mit: “Wer ist man und wann ist später?”, erledigen sich viele Dinge plötzlich ganz von selbst.

Advertisements

2 thoughts on ““Man könnte dann später…” – Ein How-To für Projektmanagement

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s