Plan3t.info

Bibliothekarische Stimmen. Independent, täglich.

Bibliothekswesen scheitern nicht!

| 14 Kommentare

Bibliothekswesen scheitern nicht! Zumindest geben sie es nicht zu. Diesen Eindruck muss man bekommen, wenn man die einschlägigen Zeitschriften durchblättert. Ja, durchblättert. Für Nicht-BibliothekarInnen: wir reden ständig über Open Access und E-Journals, verstecken unsere Erkenntnisse aber am liebsten in Printausgaben von Vereinszeitschriften.

Schon hier scheitert das Bibliothekswesen also an seinen eigenen Ansprüchen. Bei genauerer Überlegung fallen vielleicht noch zwei oder drei weitere Aspekte ein, die Optimierungspotential bieten. Vielleicht noch ein paar mehr? Seien wir ehrlich und sagen wir es ganz deutlich: es gibt haufenweise Projekte, die mit voller Kraft in den Sand gesetzt wurden.

Das Open-Access-Journal Libreas hat genau dazu einen Call for Papers für die 20. Ausgabe verfasst. Der erste Call for Papers seit Monaten, wenn nicht Jahren, der mich wirklich begeistert! Es geht ums Scheitern:

„Die 20. Ausgabe der LIBREAS soll sich dem gesamten Themenbereich des Scheiterns widmen: Was scheitert wieso? Kann man das verhindern und sollte man es überhaupt verhindern? Was kann man aus dem Scheitern lernen? Mit welchen rhetorischen Kniffen maskiert man Scheitern am besten und wie deckt man diese wieder auf? Wir rufen dazu auf, diese Debatte erfolgreich werden zu lassen und sich an ihr mit Berichten, Artikeln, Meinungsäußerungen zu beteiligen.“

Die Ideen für Artikel sprudeln nur so! Da ich diese unmöglich alle selbst schreiben kann, werfe ich ein paar mögliche Titel einfach in den Raum und hoffe darauf, dass sie jemand aufgreift:

Das Spektrum des Scheiterns im Bibliothekswesen ist groß und bunt. Weitere Ideen für Artikel bitte in den Kommentaren sammeln! Ich bin gespannt, was noch zusammenkommt!

14 Kommentare

  1. Mir fällt sofort ein: Vascoda. Das ist nicht böse gemeint. Aber warum Vascoda gescheitert ist, muss für die Planung von zukünftigen Portalen dokumentiert werden. Die Fehler müssen nicht wiederholt werden.

    • Ganz ehrlich: vascoda ist nicht am Portal gescheitert. Jedenfalls nicht nur und nicht in erster Linie. vascoda ist aus meiner Sicht an strukturellen und (förder)politischen Problemen gescheitert. Und ja, diese Probleme sollten auch mal aufgearbeitet werden. Die Frage dabei ist aber, ob sich das jemand (zu)traut oder gelassen wird … ;-)

  2. Mir fällt libreas ein
    http://www.ib.hu-berlin.de/~libreas/libreas_neu/index.html
    – ist nicht gescheitert und vollelektronisch.

  3. Eines meiner Lieblingsprojekte ist immer noch „Weblogs als Steuerungsinstrument in Hochschubibliotheken“ über das ich mehrfach in netbib geschrieben habe. Die Beteiligten würde es evtl. nicht als gescheitert betrachten.
    Auch „Fragen Sie Hamburger Bibliotheken“ war zumindest für die Beteiligten (u.a. ich) auf jeden Fall lehrreich, aber nicht unbedingt erfolgreich. Ich könnte jetzt noch diverse andere Projekte aufzählen, aber evtl. muß man noch „gescheitert“ definieren

    • Ich glaube doch, darum geht es hier gerade: Definition von Scheitern als etwas Normales, Lehrreiches, weg vom Totschweigen und weg vom Bashing der „Gescheiterten“.

      • So würde ich es auch sehen. Wenn man in die einschlägigen Zeitschriften guckt und sich Vorträge auf Konferenzen anhört, kann man sich vom erfolgreichen, fast perfekten Ablauf aller Projekte informieren. Will man wissen, was wirklich war oder welche Projekte erst gar nicht beendet wurden, muss man die Pausengespräche suchen.

  4. In der Softwareentwicklung ist das Gegen-die-Wand-Fahren geradezu klassisch – ich denke das ein auch ein Teil der gescheiterten Projekte im Bibliotheksbereich auf gescheiterte IT-Projekte zurückgeht. Angeblich ist die beste Methode dagegen ein schneller Feedback-Zyklus, d.h. schneller, öfter und kleiner scheitern statt erst wenn nichts mehr zu retten ist. Dieses Verfahren wird als agile Softwareentwicklung bezeichnet, hat aber auch seine Tücken – in der Praxis habe ich im Bibliotheksbereich noch kein größeres Projekt gesehen, dass agile Entwicklung sauber mit Tests und Refactoring umsetzt. Gleichwohl lässt sich sicher etwas von der Methode lernen – allein das Konzept von automatisierten Unit-Tests besteht ja schon darin, dass regelmäßig geprüft wird, ob eine Funktion scheitert.

  5. Holla,

    ich (also jetzt als jemand von der libreas) bin ja erfreut darüber, dass unser CfP so gut ankommt. Ich hoffe, dass ihr alle schon an Texten für die Ausgabe sitzt…
    Aber ehrlich: Gut, dass wir offenbar nicht die einzigen sind, die den Umgang mit dem Scheitern im Bibliotheksbereich als etwas komisch wahrnehmen.

  6. Bei den Bibcamps zumindest in Hamburg und Hannover war das schon Dauerthema. Tenor: „Scheitern zulassen!“

    Ein Ursache für diesen verkrampften Umgang mit dem Scheitern scheint mir, dass es einfach nicht vorgesehen ist. Im Projektantrag steht, dass dieses und jenes erreicht wird. Ziel ist es nicht, Möglichkeiten zu erforschen, sondern definitiven Erfolg zu haben. Auch Umwege sind doch oft nicht vorgesehen.

    Der klassische Weg ist doch:
    a) Projektantrag stellen
    b) Projektziel erreichen
    c) Mit dem Erfolgsbericht um ein weitere Projekt bewerben

    Hat hier jemand Erfahrung damit, wie Geldgeber/Vorgesetzte reagieren, wenn man b) umformuliert in „Projektscheitern dokumentieren“?

    • Wenn man so offen mit einem Scheitern umgeht, muss man wenn nicht sogar Geld- dann zumindest einen Imageverlust befürchten. Meistens sind die Projektziele doch nur zu einem bestimmten Teil als „erreicht“ angegeben. Andere Teile werden dann eben im Folgeprojekt fortgesetzt. Projekterfolg ist auch, die eigene Kompetenz glaubhaft zu vermitteln. Scheitert man (zu oft) erscheint man also als inkompetent und hat es in Zukunft mit neuen Projektanträgen schwerer. Über die Zeit verliert man zusätzlich noch an politischem Gewicht. Transparenz kann auch weh tun.

      Für ein Umsteuern bzw. eine Anpassung der Zielvorgaben gibt es ja (theoretisch) die Zwischenberichte. Hier hat man nochmal die Chance den Kopf ein Stück weit aus der Schlinge zu ziehen. Solange diese Überprüfung aber nicht greift, erzwingt sie auch keine Maßnahmen seitens der Antragsteller. Aus der Sicht der Protagonisten ist das Procedere eingehalten und das Projekt am Ende ein Erfolg. Eine Triebfeder für Veränderungen sind dann vielleicht noch die beteiligten Projektmitarbeiter, die nach mehreren solcher „regulären Projekterfolge“ bereits frustriert ins nächste Projekt starten.

      • Wären nicht die sogenannten Labs, z.B. ZBW Labs http://zbw.eu/labs/, die geeigneten Orte bzw. Strukturen für Projekte, bei denen Scheitern erlaubt ist?
        Der Imageverlust wäre nicht so groß, wenn mal was nicht klappt. Dem steht entgegen, dass die Labs momentan rein als Marketinginstrumente eingesetzt werden (das ist jedenfalls mein Eindruck).

    • Pssssssst – der wahre klassische Weg:
      http://www.phdcomics.com/comics.php?f=1431

  7. Pingback: Gelesen in Biblioblogs (38.KW’11) « Lesewolke

  8. Pingback: Frisch veröffentlicht: Roving in der Bibliothek der Hochschule Hannover – Infobib

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.