In Projekten wird gelogen, dass sich die Balken biegen. Ich rede jetzt noch nicht mal von den alltäglichen Übertreibungen oder dem Verschweigen (siehe gesetz #2), sondern von “echten” Lügen. Je nach Druck werden Wahrheiten verbogen, Ammenmärchen in die Welt gesetzt oder Hörensagen (aka Flurfunk) als absolute Wahrheiten verkauft.
Gerne passiert das im Vergleich mit anderen Kollegen im Projekt: “Der Müller ist doch auch noch nicht soweit, da können wir uns ganz entspannt zurücklehnen – wir haben alle Zeit der Welt!” ist ein Klassiker. Diese Lügen werden lanciert, um vom eigenen Fahlverhalten abzulenken, sei es, dass man noch nicht so weit wie gehofft ist oder unerwartet Hürden auftreten. Diese Nebelbomben sind tödlich, vermiesen das Projektklima und errichten Schutzwälle. Der Klassiker in jedem Projektmanagement-Seminar ist das grandiosa Scheitern des Projektes am Flughafen von Denver. Dort wurde das Gepäckabfertigungssystem so dermaßen in den Sand gesetzt, dass die Mehrkosten und Verzögerung schlimmste Dimensionen annahmen. Der Grund: Verzögerungen in diesem Bereich wurden erst dann offenbar, als alle anderen (kleineren) Probleme gelöst waren. Dieser Teilprojektleiter hat demanch ganz Arbeit geleistet und die eigenen Probleme bis zum Schluss unter der Decke gehalten.
Lügner haben es besonders schwer im eigenen Team. Nicht unbedingt wird jedes Mitglied zum Mittäter oder “Lügner aus Not”, trotzdem ist jede Aussage fragwürdig. “Hidden Agendas” werden überall vermutet und entsprechend bedient. Besonders schlimm trifft es den Lügner dann, wenn es am wenigsten passt: in Krisensituationen. Wie will ein Projektleiter jetzt sein Team mitreißen, es überzeugen von der (R)Wichtigkeit der Mission? Der lügende Projektleiter steht jetzt zimlich einsam da — er leitet per “Order Mufti”, alleine auf Basis seiner Stellenbeschreibung.
Entlarven Sie Lügner, diese stellen sich gerne als Opfer dar oder es sind dienjenigen, die wild um sich treten.
Ermutigt durch die Erkenntnisse des PROJEKTMANAGEMENT BLOG über die Gründe, warum Projekte scheitern, habe ich den Top-Grund unter die Lupe genommen. Mangelhafte Kommunikation ist also der Nährboden für scheiternde Projekte? Dann misten wir mal aus …
Anticipate. Also so etwas wie Vorausahnung, Weitblick oder Weitsicht. Probleme erkennen, bevor sie offensichtlich sind und diese mit geeigneten Waffen in die Flucht schlagen
Build a Good Team. Eigentlich irgendwie logisch, leider aber nicht selbstverständlich. Das heißt nämlich auch, sich selber zurückzunehmen und (eigene) Eitelkeiten zu erkennen
Communicate. Schade, dass dieser Punkt aufgrund sprachlicher Tradition nicht oben stehen darf — denn für micht gibt es nichts Wichtigeres
Der Artikel beweist mal wieder, warum PM übersetzt auch “People Management” heißt.
P. S.: Der Artikel erschien zuerst im Nasa Magazin.
Ein Thema interessiert mich seit Längerem: was können wir “klassischen” Projektleiter von agilen Methoden ala Scrum lernen?
der unbedingte Einbezug des Kunden zu jeder Zeit des Projektes ist sicherlich eine gute Idee. Weg mit Zwangsterminen (Lenkungsgruppen-Sitzungen), die nur pro forma gehalten werden und Fernbleiben ein beliebter Soprt ist
kurze Iterations-Zyklen mit klaren Zielvorgaben helfen dabei, frühzeitig Design-Fehler zu erkennen oder das Produkt neuen Anforderungen anzupassen
im Vordergrund steht ein funktionierendes Produkt, “Schmuck am Nachthemd” wird vermieden oder bewusst implementiert
letztendlich sind die Methoden des agilen Managements perfekt auf die obigen Anforderungen zugeschnitten und können mit ein wenig Anpassung perfekt übernommen werden
PRINCE2 (projects incontrolled environments) ist eine aus England stammende Projektmanagement-Methode, ähnlich (aber nicht wirklich vergleichbar) mit PMI oder GPM.
Wer mal eben schnell wissen will, wie PRINCE2 funktioniert, schaut sich das Video an:
Seit Langem habe ich die Projektgeschichten von Sigrid Hauer per RSS abonniert. Sigrid erzählt den Projektalltag in kleinen Geschichten mit Lerneffekt. Dabei wird das Erzählte aus dem Projekt-Kontext heraus gezogen und in eine Geschichten- oder Märchenform gebracht. Es fällt viel leichter, auf dieser abstrakten Ebene (peinliche) Wahrheiten zu akzeptieren oder sich auf einen Punkt zu konzentrieren, wenn der Wald mal wieder nicht sichtbar ist.
In Ihrem neuesten Beitrag schreibt Sigrid, wie Sie die Geschichten erfindet und lädt uns ein, das auch mal zu probieren. Dabei fällt mir ein, dass ich versuche, meine Geschichten an Dingen des Alltags aufzuhängen die jeder wieder erkennt.
Stellen wir uns vor, wir bauen ein Haus … da wird geplant, Statik berechnet, gemauert, Dach drauf … und die Inneneinrichtung kommt zuletzt.
Immer wieder schön für die richtige Priorisierung — first things first! Andere “Gleichnisse” die ich gerne verwende:
Auto fahren (Wagenlenker vs. Mechaniker — also unterschiedliche Kenntnissstufen, Anforderungen etc)
Party vorbereiten (sich in Andere hinein versetzen)
offensichtliche Design-Schwächen oder Unzulänglichkeiten an Gegenständen des Alltags verdeutlichen (1 Vorwärtsgang und 6 Rückwärtsgänge)
Aber vielleicht werde ich demnächst auch entführte Prinzessinnen, furchtlose Ritter und schreckliche Drachen einbauen — mal sehen …
Einer der besten Podcasts der Welt beschäftigt sich in einer Serie mit Projektmanagement. Bisher sind zwei Folgen erschienen (Teil 1) (Teil 2). Kernaussagen:
es geht um das Erledigen Aufgaben und nicht um das Managen des Projekts
viele sehen zwar den Wald vor lauter Bäumen nicht — ohne die Bäume gibt es aber keinen Wald! Hier sind die Bäume die Aufgaben und der Wald das Projekt …
Projekte werden von Menschen erledigt und nicht von Tools. Schlechte Leistungen können niemals durch gute Tools kompensiert werden, schlechte Tools aber durch herausragende Leistungen ausgeglichen werden
Budget-Management ist keine Hexerei
Ergänzung: Gutes Projekt-Management schafft die Bedingungen, die herausragende Leistungen ermöglichen.
Es ist noch nicht klar, wie viele Folgen erscheinen werden, am Besten per iTunes abonnieren!
Für meine Projekte verwende ich seit geraumer Zeit ein Wiki zur begleitenden Dokumentation:
Links zu anderen Dokumenten (Design- Dokumente, Projektplänen, …)
Tipps und Tricks
Listen mit Telefonnummern, Telekonferenz-IDs, Verantwortlichen Personen, Systemnamen, …
Erklärungen zu Fehlermeldungen, Statuscodes, Feldinhalten von Tabellen
Checklisten
Besprechungsprotokolle
…
Ich verwende mit wachsender Begeisterung TiddlyWiki:
es besteht nur aus einer Datei
… ist dadurch extrem transportabel und einfach “installierbar” (einfach irgendwo ablegen, aufrufen, fertig — ein Webserver wird nicht benötigt)
simpel zu erlernen
erweiterbar (z. B. mit Exportfunktion, so habe ich auch immer alles auf meinem PDA zur Verfügung)
Multi-User-fähig: das gesamte Team kann mitarbeiten und damit Wissen zur Verfügung stellen
die Information sind an einem zentralen Ort verfügbar
Das Gute ist: als Projektleiter kann ich den Einsatz dieser Plattform oft bestimmen — wer jedoch einmal die Vorteile verstanden hat, will es eh’ nicht mehr missen.
Eine weitere Beobachtung: Wikis haben von Anfang an eine höhere Qualität als “geschriebene” Dokumentation. Das liegt zum Einen an der Öffentlichkeit, den jeder Beitrag automatisch hat und auch an den Kollegen, die schnell und einfach Fehler korrigieren können.
Bitte mal ausprobieren, Fragen stellen und Feedback geben!
Twitter
Xing
Linked.in
Facebook
Flickr
eMail
RSS
Letzte Kommentare