Mind Mapping ist eine meine favorisierten Visualisierungstechniken – nicht nur im Projektmanagement.
Mind Maps sind nicht nur zum Brainstorming geeignet, sondern auch zur Einarbeitung in neue Themen, zur Erstellung von PSP/WBS, aber auch zur Moderation…
Mind Maps funktionieren ohne technische Unterstützung, aber trotzdem bin ich eifriger Nutzer des Mindmanagers (wer ohne MS Office- und MS Project-Integration auskommt ist auch mit XMind hervorragend bedient).
Stefan List hat jüngst eine Übersicht über die Verwendung von Map-Markierungen im Mindmanager zu einer Artikel-Serie von Michael Deutch zusammengetragen.

Mit Seth Godin und Tom Peters plädieren zwei Management-Gururs für das Blogging:

Ausgegraben von Bret L. Simmons.

Visualisierungen können im Projektalltag weiterhelfen. Das gute alte GANTT-Chart ist nur ein Beispiel, Visualisierungstechniken können für Analyse, Planung, Dokumentation und Kommunikation zum Einsatz kommen.
Ein paar gelungene Beispiele für Visualisierungen von SCRUM zeigt uns Xavier Quesada Allue im Visual Management Blog.

Quelle: Visual Management Blog

Die grafische Darstellungen entstammen aus der SCRUM-Methodik. Das Aufstellen einer solchen Pinwand mitten im Team hat aber vor allem auch gruppendynamische und teambildende Auswirkungen. Solche Darstellungen dürfen nicht zum Selbstzweck werden, der eine oder andere Projektcountdown zum Produktivstart wird schnell als reine Marketingmaßnahme entlarvt und verliert seine Wirkung (oder kehrt diese sogar noch um, wenn sich die Mitarbeiter nicht ernst genommen vorkommen). Die Gefahr besteht im Beispiel nicht, denn mit allem, was auf der Tafel zu sehen ist, wird in SCRUM auch gearbeitet.

Wie im vorangehenden Beitrag angekündigt, hier eine kurze Beschreibung zum Projektplan-Template:

• Die Datei hat drei Reiter, zwei davon mit Planungstemplates, einer mit Hilfsdaten. Auf den Einsatz von Makros wurde bewusst verzichtet.
• Aus den Angaben Projektbeginn (B2) und Projekteende (B3) in den Template-Reitern wird die Beschriftung der Datumsachse abgeleitet.
• Der Zellbereich A5:G1005 ist in den beiden Templates als Tabelle definiert. und dient der Erfassung der Planungsdaten.
• Im Reiter berechnete Dauer wird davon ausgegangenen, dass in der Tabelle Anfangs- und Enddatum zu jedem Vorgang erfasst werden. Die Berechnung der Dauer in Arbeitstagen (und nicht in Kalendertagen) erfolgt dann automatisch per Excel-Formel.
• Im Reiter berechnetes Ende wird wiederum aus der Eingabe von Vorgangsdauer und Anfangstermin, das Endedatum ermittelt.
• Für die Zuordnung der Verantwortlichen für einen Vorgang kommt die Namensliste aus dem Hilfsblatt (ebenfalls als Tabelle definiert) zum Einsatz. Mittels Gültigkeitsüberprüfung wird in den entsprechenden Eingabefeldern der Planungsreiter eine Dropdwonliste mit den Namen aus dem Hilfsblatt angezeigt.
• Die Vorgangsbalken, sowie die graue Hinterlegung der Wochenenden (zur besseren Orientierung) erfolgt über bedingte Formatierungen. Excel 2007 ist im Gegensatz zu den Vorgängerversionen hier nicht auf drei Regeln beschränkt.

Die Frage ist müßig: Warum sollte man ein GANTT-Chart (Balkendiagramm) in Excel erstellen? MS Project macht das doch automatisch.

Und trotzdem: Im Projektalltag verfolgen uns diese Excelplanungen dann doch. Nicht jeder, der den Plan lesen muss, hat auch einen Project Client, Excel ist sowieso zur Hand, diverse Listen und Planungen liegen bereits im Exel-Format vor,…

Ich glaube, ich habe schon mehr Excle-Templates für Planungen gesehen, als es PM-Tools gibt. Ignatz Schels ist ein Meister solcher Excel-Tools, aber auch im Internet wird man fündig: Stefan Hagen hat jüngst eine Variante mit GoogleDocs eingestellt, die sich nach Excel exportieren lässt. Bei Microsoft findet sich eine Variante, die die Diagramm-Funktionen von Excel nutzt. Hier ein ähnlicher Vorschlag auf Online-Excel.de. Auch im Abo-Dienst des Projekt-Magazins sind schon einige Beiträge zum Einsatz von Excel erschienen. Auch mein Testmanagement-Toolset im Projekt-Magazin, enthielt eine Variante. Als kleine Spielerei habe ich die darin enthaltene Lösung noch etwas aufgebohrt. Den Download für dieses Templates für Excel 2007(!) finden Sie hier. Die Datei ist bewusst im XLSX-Format, da einige Funktionen genutzt werden, die in älteren Excel-Versionen nicht zur Verfügung stehen. Eine Beschreibung zum Template finden Sie im nächsten Beitrag.

Agile PM-Methoden sind nicht nur populär sondern durchdringen immer mehr die traditionellen Schulen und Institutionen. Da widmet projektMANAGEMENT aktuell als Organ der GPM in der aktuellen Ausgabe 4/2009 das Titelthema SCRUM: Von der Planung zur Selbstabstimmung. Aber nicht nur bei der GPM finden die Themen Niederschlag, sondern auch beim PMI. So wurde jüngst die Agile Community of Practice des PMI® gestartet. Andreas Heilwagen berichtet.

Stefan Hagen widmet sich in einem lesenswerten Beitrag der Frage, wie man komplexe Probleme lösen kann und tritt dabei eine nicht minder spannende Diskussion in den Kommentaren los. Die Auseinandersetzung mit Komplexität an sich ist spannend. Nicht jede Komplexität ist beherrschbar, insofern sind wir mitunter gezwungen getreu der zitierten Formel VERSTEHEN-VEREINFACHEN-VERÄNDERN zu handeln. Die Kritik Probleme damit zu trivialisieren kann mittels „Learning Loops“ KONTINUIERLICH LERNEN & REFLEKTIEREN begegnet werden.

Die Kollaborationbsplattform Projectplace hat einen witzigen Wettbewerb ins Leben gerufen:

www.project-face.com will Projekten „ein Gesicht geben“ – schweißtreibende Meetings, überfüllte Baustellen, Kaffeepausen, glückliche Projektleiter oder überarbeitete Praktikanten … einfach passende Bilder, Videos oder Meldungen auf Picasa, YouTube und Twitter mit ‚projectface‘ taggen und das war’s schon! Auf Projectface erfolgt dann die Bewertung und Preise gibt es auch zu gewinnen.

Die bisherigen Postings haben mich zwar noch nicht vom Hocker gehauen, aber vielleicht kommt ja noch das eine oder andere.

Ist natürlich PR für Projectplace, dessen muss man sich bewusst sein.

Der kritische Ton in den vorangegangen Beiträgen soll keineswegs die Sinnhaftigkeit von BI-Lösungen in Frage stellen, aber auch hier gilt es das richtige Augenmaß zu finden.

BI-Projekte können erst dann als erfolgreich gewertet werden, wenn sie tatsächlich zu den Unternehmenszielen beitragen. Ist dies nicht der Fall, ist es egal ob es am falschen Umgang mit den Ergebnissen, den falschen Fragestellungen/Anforderungen, der Datengrundlage oder der Programmierung lag.

Wenn Sie weitere Informationen zum Thema BI suchen, empfehle ich Ihnen einige aktuelle Beiträge der Computerwoche:

• Sascha Alexander versucht in seinem Artikel einige Empfehlungen für den Start von Business Intelligence Projekten zu geben, damit Ihnen das nicht passiert.
• Heinrich Vaske beschreibt: So managen Sie BI-Projekte.
• Christa Manta schildert, dass CIOs beim Thema BI häufig in der Falle sitzen.

In diesem Sinne wünsche ich Ihren BI-Projekten zum Abschluss dieser kleinen Reihe:

Gutes Gelingen!

================
BI auf schlossBlog:
================

In Teil 1 der Reihe finden sie eine Definition von BI und grundlegende Anforderungen von Kennzahlsystemen.
In Teil 2 wurde das Anforderungsdilemma in BI-Projekten beschrieben.
In Teil 3 rückt das Augenmerk auf die Unternehmensleitung und deren Umgang mit BI.
Teil 4 beschäftigt sich mit den elementaren Themen Datenqualität und Datenbereitstellung.
Im vorliegenden fünften Teil wird resümiert, was ein erfolgreiches BI-Projekt ausmacht.

Seit Ur-Zeiten der IT gilt das alte Grundprinzip: Garbage in – garbage out.

Was nützen die besten Auswertungen und Bericht, wenn die Datengrundlage nichts wert ist. Und manches ERP-System oder andere Applikation strotzt nur vor Datenleichen. In fast allen Migrationsprojekten sind deshalb vor der eigentlichen Migration aufwändige Bereinigungen und Analysen erforderlich. In den Auswertungen hat bis dahin die schlechte Qualität offenbar nicht gestört…

Datenqualität ist eine Facette, die nächste Frage ist, ob nicht Äpfel mit Birnen verglichen werden. Gerade wenn unterschiedliche Vorsysteme einbezogen werden, ist beim besten Willen nicht selbstverständlich, dass alle Vorsysteme unter einer Größe  X auch das Gleiche verstehen, das sie gleiche Berichtszyklen haben, etc.  Die Tücke liegt im Detail. Schnell läuft man Gefahr sich in einer Scheingenauigkeit zu verlieren, die nichts anderes wiedergibt als die mittlere Krankenhaustemperatur. (Das Messen der Körpertemperatur eines Patienten mag für den Arzt ja aufschlussreich sein, aber der Durchschnittswert aller Patienten in einer Klinik ist nur mehr eine äußerst fragwürdige Größe.)