Mein Blog-Kollege Jan Poczynek hat eine interessante Präsentation zum Management des Projektmanagements erstellt. Er beschäftigt sich mit dem Spannungsfeld, das Projekte innerhalb von Stammorganisationen erzeugen und welche Maßnahmen ergriffen werden können die Integration zu verbessern.
Aber seht selbst:
Einen Vertiefung ist mit dem ausführlichen Artikel möglich.
Es gibt derzeit ja viele Doku-Soaps im deutschen Fernsehen. Zwischen den ganzen weniger brauchbaren Sendungen finde ich eine dennoch erwähnenswert, “Rach, der Restauranttester”. Diese Sendung ist wunderbar geeignet für Projektmanger oder Berater, da die Konzepte sich sehr gut auf die IT-Projekte übertragen lassen. Vielleicht sollte ich damit anfangen, was Christian Rach überhaupt macht:
Er besucht pro Folge ein Restaurant, das kurz vor der Pleite steht. Seine Aufgabe ist es, das Lokal vor dem Ruin zu retten. Dazu testet er die Küche, den Service und die Führung der Gastronomie.
Das ist alles!
Genau das machen viele Berater aber auch. Sie zeigen auf, dass die Kommunikation unter den Abteilungen schlecht ist, keine klare Aufgabenverteilung besteht und dass bestimmte Bereiche zusammengelegt werden sollen – in Form von Kompetenzzentren. So, oder so ähnlich werden die Vorschläge wohl lauten. Allerdings macht es Rach etwas anders. Er adaptiert nicht ein Schema F auf alle Restaurants, sondern jeder muss sich selbst treu bleiben.
Aber was kann man davon auf IT-Projekte übertragen?
Zuerst die Vorgehensweise:
Tell me and I´ll forget;
show me and I may remember;
involve me and I´ll understand.
Genau an diese Punkte hält sich Christian Rach, wenn er ein Restaurant unter die Lupe nimmt. Nach einer Analyse, spricht er die Probleme offen an – und das mehr als deutlich. Er bezieht von Anfang an die Beteiligten mit ein und verlangt ihnen eigene Ideen zur Problemlösung ab. Dabei versucht er nicht einem traditionellen Wirtshaus eine System-Gastronomie aufzudrücken. Während der Umsetzung findet Rach immer wieder Worte des Lobs, um die Mitarbeiter zu motivieren (sofern diese es verdient haben).
Viele dieser Punkte werden von Projektmanagern und IT-Beratern bereits so umgesetzt, lediglich der vierte Punkt ist mir ein Dorn im Auge. Diesem Punkt wird leider nicht genug Beachtung geschenkt. Das zeigt die zunehmende Verbreitung von Standardsoftware auch in den Bereichen, in denen bisher aufgrund der speziellen Besonderheiten individuell entwickelt wurde.
Physikalische Grenzen werden von den meisten Menschen akzeptiert. So besitzt das Licht eine nicht beeinflussbare Geschwindigkeit und kein Mensch wird jemals die 100m in sieben Sekunden laufen. Kein Handwerker baut Möbel nach Augenmaß und kein Architekt ein Haus ohne Berechnung der Statik. Dennoch werden genau diese Gesetzmäßigkeiten bei IT-Projekten immer wieder versucht zu umgehen. Es wird ein Projektplan aufgesetzt, der die Grenzen des Machbaren außer Acht lässt. Wenn also ca. 6 Personenmonate veranschlagt werden, ist es nicht mit 6 Personen in einem Monat realisiert. Oder anders ausgedrückt: „Wenn ein Schiff vier Tage braucht um den Atlantik zu überqueren, wie lange brauchen also zwei Schiffe…“.
Für jeden gegeben Funktionsumfang eines Software-Systems existiert eine minimale Projektlaufzeit und ein minimales Budget, welches kein Projektteam der Welt in der Lage ist zu unterschreiten. Ich kann mir also nur vorstellen, dass es sich um Wunschdenken im Management handelt solche Projekte zu verabschieden (siehe Punkt 6 in diesem Beitrag).
Die Grenzen der Machbarkeit beruhen auf einfachen Prinzipien wie ich in diesem Beitrag bereits erwähnt habe. Und wer ein Projekt mit unrealistischen Rahmenbedingungen unternimmt sollte vielleicht doch noch mal den Zollstock zur Hand nehmen 
Bildquelle: www.piqs.de/ Knipsermann, Wir bauen ein Haus!
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.
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.
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.
