Wikis sind derzeit in aller Munde.  Die Unternehmen experimentieren mit diesen einfachen Tools, um das vorhandene Wissen zu bündeln.  Auch ich habe bereits eine Wiki-Plattform eingeführt und wenn man nach der vermeintlich besten Strategie zur Einführung sucht, wird man schnell fündig. Zu nennen einerseits der Blog von //SEIBERT/MEDIA oder vielleicht ein Beitrag in der Computerwoche zur Einführung eines Wikis.
Vorerst meine Meinung. Ich denke nicht, dass jede Abteilung oder Firma geeignet ist ein Wiki zu nutzen, da es doch sehr stark die vorhandenen Denk- und Arbeitsweisen in Frage stellt.  Häufig sind auch die kreativen Freiräume, die ein Wiki gewährt, vom Management nicht gewünscht. Daher muss dies bereits in der Vorplanung mit berücksichtigt werden.  Darüberhinaus gibt es zwei Arten der Wiki-Einführung.

1. Als schleichender Prozess, der meist von der IT-Abteilung initiiert wird
2. Als geplantes Projekt

Ich  beschäftige  mich mit dem zweiten Ansatz, der allerdings höhere Erwartungen an das Wiki stellt und den Beteiligten eine kürzere Lernphase abverlangt.  Die genannten Punkte habe ich mal in einer Mindmap zusammen getragen und hoffe so, anderen eine Arbeitsgrundlage zur Verfügung stellen zu können.

Wiki-Einführung

Im Rahmen meiner Diplomarbeit beschäftige ich mich gerade mit dem Teilthema Systemintegration. Insgesamt habe ich zwei Ziele der Integration von Systemen identifiziert.

1. Konsistenzsicherung
   Die Integration wird zur Vermeidung von Mehrfacherfassungen eingesetzt, damit die Daten in allen beteiligten Systemen konsistent sind.
2. Informationsintegration
   Die Integration wird für den globalen Zugriff auf die Unternehmensdaten genutzt. Alle beteiligten Informationssysteme werden integriert, damit auf die unternehmensrelevanten Daten zugegriffen werden kann.

Da ich allerdings bei meiner täglichen Arbeit auch immer wieder mit dem Thema konfrontiert werden, prägte ein Kollege bei einer Diskussion ein weiteres Ziel der Integration: Integration durch Armut. Dieser eher scherzhaft gemeinten Aussage kann ich aber durchaus was abgewinnen. Denn man neigt schon eher dazu, viele kleine Systeme die vielleicht sogar Open-Source-Systeme sind aufgrund der Informationsintegration zu verbinden. Würde die IT-Landschaft nun aus einer großen sehr teuren Anwendung bestehen (sagen wir SAP), hätte man vermutlich weniger komplett integrierte und vermischte Anwendungen. Man würde sich einfach damit zufrieden geben was man hätte und nicht ständig nach einer Möglichkeit suchen doch noch den bereits vorhandenen Datenbestand zu nutzen…

Ich habe heute ein tolles Plakat zum Thema Scrum entdeckt. Es wurde von der InterFace AG in Zusammenarbeit der TU-München und der TEG erstellt und ist unter folgender Stelle zu finden.
Wie ich finde ist das Plakat inhaltlich gelungen und auch die Idee es auf einem A4 – Drucker auszudrucken finde ich toll.

Verfügbar ist es in englischer oder deutscher Sprache in den Formaten A2 / A1. Aufgehängt bietet es einen guten Überblick über den agilen Prozess Scrum.

Ich habe einen etwas älteren aber dennoch aktuellen Beitrag von Jens Wagener in seinem Blog gefunden, der sehr viel über das Verhalten von uns allen in Projekten widerspiegelt.

In diesem Beitrag geht es konkret darum Regeln in agilen Projekten zu hinterfragen.

Regeln können und müssen jederzeit hinterfragt werden. Wer das nicht tut und stattdessen dumme Antworten sang und klanglos akzeptiert, ist selber schuld und wird nie an die Bananen gelangen.

Ich würde sogar noch einen Schritt weiter gehen:

Wir müssen “Um-Die-Ecke-Denken” um auch zukünfig in Projekten oder im Tagesgeschäft erfolgreich zu sein. Wer dies nicht tut, trägt dazu bei in einer “Bananenrepublik” zu arbeiten.

Da ich in der Vergangenheit auch zu den Leidtragenden gehörte, die aufgrund von ungenauen Vorgaben Termine nicht einhalten konnte, ist es sicherlich auch hier einmal Zeit einen Beitrag zum Thema Anforderungsmanagement zu widmen.Aber zuerst eine Definition:

Anforderungsmanagement (engl. Requirements Management) ist eine Managementaufgabe für die effiziente und fehlerarme Entwicklung komplexer Systeme. Es umfasst die Anforderungserhebung  Requirements-Engineering) sowie Maßnahmen zur Steuerung, Kontrolle und Verwaltung von Anforderungen, also Risikomanagement, Änderungsmanagement und Umsetzungsmanagement.

Quelle: Wikipedia

Bei meiner Suche zum Thema agiles Anforderungsmanagement, bin ich auf einen Vortrag von Detlef Buder und Alexander Fischbach gestoßen, in dem sie die Fragen beantworten:

• Benötigen agile Entwicklungsmethoden überhaupt ein Anforderungsmanagement im klassischen Sinne?
• Wie viel ist “soviel Dokumentation wie nötig” in Bezug auf die Anforderungsanalyse?
• Wie viel muss ich über ein zu erstellendes System wissen, damit ich mit der iterativ / inkrementellen Entwicklung starten kann?

Ich sehe das Anforderungsmanagement als eines der Kernthemen im Projektmanagement, bleibt zu klären, in wie weit es sich in agile Vorgehensmodell integrieren läßt.

Dieser Artikel hat mich mal wieder bestätigt. Es geht darum, dass wir häufig auf das hören, das wir bezahlt haben. Grundlage ist ein Artikel von Francesca Ginoa (“Do we listen to advice just because we paid for it?”) in dem die Autorin in einem kontrollieren Experiment genau das nachweist.

In kaum einem anderen Bereich wird dies so deutlich, wie im IT-Consulting. Ich erlebe es immer wieder in Projekten, in denen blind auf die Beratungleistung der Consultants vertraut wird, ist der Prophet im eigenen Lande nichts wert. Allerdings erhält mein Wort deutlich mehr Gewicht, wenn ich als externer Berater in einem Unternehmen meine Meinung äußere, als bei meinem eigenen Arbeitgeber. Schlimm wird es erst, wenn man aus Projekten aufgrund einer “kritischen” Meinung herausgehalten wird. Das erinnert mich an die Fabel von James Thurber: “The Owl Who Was God”. Hier ergeht es einem wie dem Fuchs in der Fabel, der von der Gemeinschaft der Tiere verstoßen wird.

In diesem Sinne – schönes Wochenende.