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.

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.

Nachdem BI die Unternehmensziele im Visier hat, geniessen BI-Projekte meist auch eine überproportionale Management Attention. Mitunter tappt dann auch die Unternehmensleitung selbst in das Anforderungsdilemma. Interessant ist, was mit den Ergebnissen aus den BI-Systemen passiert:

Dienen sie als Entscheidungsgrundlage?

Oder lediglich der Rechtfertigung längst getroffener Entscheidungen?

Werden Sie überhaupt genutzt?

In einem Unternehmensbereich eines Großkonzerns wurden aufwändig die FuE-Kosten ermittelt. Es wurde eigens ein zusätzliches Kontierungstool mit SAP-Anbindung eingeführt. Die Berichterstattung ging an drei Köpfe in der Bereichsleitung. In einem Gespräch Jahre später bestätigte mir der Assistent einer der drei Köpfe, dass zwei der drei Adressaten nie auch nur einen der Berichte angeschaut hätten. Der Dritte nahm die Berichte um seine eigenen Hochrechnungen in Excel zu plausibilisieren. Ausschlaggebend war aber Excel und nicht die Kostenauswertung aus SAP.

Josh Nankivel bringt es auf PM-Student auf den Punkt:

Project Managers Focus Too Much On Tools.

Tools Don’t Manage Projects. You Do.

Agile Softwareentwicklung hat auch bei Microsoft Einzug erhalten. Ein Bericht in Spiegel online hat zahlreiche Reaktionen in den einschlägigen PM- und Sofftwareentwicklungs-Blogs gefunden, z.B. bei Jens Coldewey, Danny Quick und last but not least Andreas Heilwagen.

Hier war schon von einer Rückbesinnung auf das Wesentliche im Projektmanagement im Sinne eines Simplify your projects die Rede. Ähnlich fällt mitunter das Stichwort von einem Lean Project Management, was man gerne mit „schlankem Projektmanagement“ übersetzen möchte. Aber klassisches Lean Management hat einige Konotationen. In der Zweiten Revolution in der Automobilindustrie (Amazon Affiliate Link) von Womack, Jones und Roos werden nämlich 5 Grundsätze eingefordert:

1. Den Wert aus Sicht des Kunden definieren
2. Den Wertstrom identifizieren
3. Das Fluss-Prinzip umsetzen
4. Das Pull-Prinzip einführen
5. Perfektion anstreben

Das mag ja alles irgendwie richtig sein, trifft aber nicht den Kern dessen, was ich unter einem schlanken Projektmangement verstehen möchte. Ich würde vor allem auf zwei Aspekte fokussieren:

1. Transparenz
2. Kommunikation

Transparenz schließt nicht nur die Vorgehensweise im Projekt und die Projektergebnisse mit ein, sondern zuallererst den Projektauftrag.
Innerhalb des Projekts und zwischen Projekt und Stakeholdern spielt die Kommunikation die entscheidende Rolle, um die erforderliche Transparenz zu schaffen.
Kommunikation spielt aber darüber hinaus auch im sozialen System „Projekt“ einen wesentlichen Part. Deshalb kann beispielsweise Dokumentation Kommunikation nicht ersetzen. Dokumentation sorgt zwar ebenfalls für Transparenz, unterstützt aber nur nachrangig die Interaktion der Projektbeteiligten.

Auf diese zwei Aspekte zu fokussieren heißt natürlich nicht, alles, was im Projektmanagement an Werkzeugen und Theorien entstanden ist, einfach über Bord zu werfen. Vor dem Methoden-Overkill ist der Einsatz einer Methode aber immer zu hinterfragen:

Inwieweit trägt eine Maßnahme, Methode, Theorie oder Tool im Projekt zu Transparenz und Kommunikation bei?
Und natürlich: Inwieweit trägt sie zum Projektziel bei?

Lynda Bourne setzt sich mit der Neuauflage von PRINCE2 auseinander und zieht einen Vergleich zum PMBOK des PMI:

PRINCE2 sees the project starting much earlier and continuing through to the realisation of value by the organisation. This is quite likely correct from the perspective of an organisation initiating and managing internal projects.

There is very little difference in terms of the processes used to run a project between PRINCE2 and the PMBOK. What is different is PRINCE2 is totally focused on managing internal projects with organisational managers having a direct say in the management of the overall process and it provides an effective methodology for this circumstance. The PMBOK® Guide is a pure PM standard and has a more generic set of processes that can be adapted to a much wider range of circumstances and used in any situation (eg, a traditional project where the client contracts the project delivery organisation).

Das Scheitern von Projekten hatten wir hier schon wiederholt als Thema. Jahr für Jahr analysiert die Standish Group mit dem CHAOS-Report mögliche Ursachen. Wie Richard Joerges  und Eberhard Huber zurecht anmerken, unterscheiden sich die Ergebnisse (unabhängig von der Wirtschaftskrise) kaum von den Vorjahren. In einem anderen Beitrag weist Eberhard Huber auch darauf hin, dass es gar nicht so einfach ist, zu beurteilen, ob ein Projekt erfolgreich war oder nicht.

Passend dazu auch eine aktuelle Umfrage von Stefan Hagen, warum Projekte scheitern. Ursache Nummer 1 ist demnach vor allem mangelnde Kommunikation. Diese Aussage kann ich nur unterstreichen. Der zweite wesentliche Grund fehlt allerdings in der Aufzählung, bzw. versteckt sich hinter einer Reihe anderer Gründe: mangelhafte Projektaufträge/Auftragsklärung. Weitere Kommentare zu Stefan Hagens Umfrage finden sich bei Andreas Heilwagen oder wieder bei Richard Joerges.

Um die Diskussion hier fortzuführen noch zwei weitere kritische Anmerkungen:

(1) Die 90-9-1 Regel gilt auch für Microblogging

//SEIBERT/MEDIA zitiert die 90-9-1 Regel für Wikis im Wissensmanagement. Sie dürfte sich aber analog auch auf das Microblogging übertragen lassen.

Im Internet (…) steuert lediglich ein Prozent der User den Großteil der nutzergenerierten Inhalte bei, neun Prozent beteiligen sich gelegentlich an der Content-Produktion und neun von zehn Nutzern erstellen niemals Web-Inhalte, sondern konsumieren ausschließlich.

Vollständigkeit und Zuverlässigkeit sind somit fraglich.

(2) Kommunikation ist zielgerichtet, Microblogging nicht

Kommunikation ist im Idealfall ein bewußter, zielgerichteter Akt zwischen Sender und Empfänger. Microblogging ist mir an dieser Stelle viel zu unspezifisch. Jetzt könnte man kritisch anmerken, dass dies auch für jeden Blog (also auch für diesen hier) gilt. Dem ist sicher auch so, wenn nicht (wie ich es hier versuche) die Inhalte in einen konkreten Kontext gestellt werden.