Immer schön bei der Wahrheit bleiben

Kein Kommentar

Das ist der erste Artikel in der Reihe “Projektkommunikation — 10 Erfolgsgesetze” — die weiteren Teile gibt es hier!

Gesetz #2: Immer schön bei der Wahrheit bleiben!

Die Wahrheit sagen ist mehr als nicht lügen (siehe Tipp #1). Die Unwahrheit tarnt sich oft in Wesenszügen, die besonders bei sprachlich Begabten anzutreffen sind.

Sarkasmus ist der Weinkrampf der Starken.

Ironie, Sarkasmus und hintersinnige Wortspiele erzählen zwar nicht die Unwahrheit, führen das Gegenüber aber in die Irre. Ich hatte während meines Praktikums im Studium einen Mentor, der als Vollzeit-Sarkast fortwährend die Wirklichkeit aus seiner Sicht präsentierte. Nach kurzer Zeit gab ich auf – ich konnte die Funken der Wahrheit in seinem Wort-Feuerwerk nicht mehr erkennen. Dies hatte zur Folge, dass mir dieser Mensch nichts beigebracht hat und ich kostbare Zeit verschwendet habe. Schlimmer noch: ein paar seiner Anekdoten verharren immer noch als “Wahrheiten” in meinem Gedächtnis.

Mehr …

MS-Excel Tipps für Projektleiter

Kein Kommentar

Viele Projektleiter verwenden MS-Excel jeden Tag … und verzweifeln spätestens beim SVERWEIS oder Pivot-Tabellen.

Heute habe ich ein tolles Blog gefunden, auf dem Excel für “Nicht-Nerds” erklärt wird. Ein paar Beispiele:

Meistens kann man die Excel-Dateien herunterladen und sofort verwenden, nicht so aber bei dem Top-Tipp:

Das Project Management Bundle kostet je nach Excel-Version 30$ – 45$, enthält aber 24 cool aussehende Templates, die ein Projekleiter täglich braucht. Habe ich sofort gekauft und sind schon im Einsatz …

Noch ein Tipp: wer Schwierigkeiten hat, die englischen Formularbezeichnungen ins Deutsche zu übersetzen, findet hier eine gute Übersetzung für Excel 2007.

Hier noch ein kleiner Tipp von mir:

Duplikate finden

Lösung 1: In einer sortierten Liste, vergleiche aktuelle Zelle mit der vorherigen. Wenn gleich, habe ich ein Duplikat.

Duplikate in sortierter Liste

Duplikate in sortierter Liste

In Zelle “A3″, gib’ folgenden Code ein:

=WENN(A3=A2;"Duplikat";"OK")

Das funktioniert auch ganz gut, allerdings ausschließlich in einer sortierten Liste. Das Gleiche geht aber auch in einer unsortierten Liste mit …

Lösung 2: In einer unsortierten Liste, vergleiche die aktuelle Zelle mit dem Rest der Spalte (nach oben gerichtet). Wenn mehr als einmal vorhanden, dann ist es ein Duplikat.

Duplikate in unsortierter Liste

Duplikate in unsortierter Liste

Gib’ diesmal den folgenden Code in Zelle “A2″ ein:

=WENN(ZÄHLENWENN($A$2:A2;A2) > 1; "Duplikat"; "OK")

Alle Duplikate werden markiert.

Am Schluss noch ein Link zu einem Buch: Projektmanagement mit Excel. Kostenlos zu lesen auf PaperC.

Viel Erfolg!

Projektmanagement mit Excel

Linktipps Produktivität

Kein Kommentar

Oft kämpfe ich dafür, Projektteams zusammen zu ziehen und an einem Ort zu versammeln — meist, um sich gezielt einem Problem anzunehmen. Im Nachhinein habe ich immer das Gefühl, dass es etwas gebracht hat. Leider muss ich jedes mal wieder argumentieren, besonders mit externen Dienstleistern.

Jetzt habe ich Munition gefunden:

Alles stammt aus einer Yahoo! Gruppe namens scrumdevelopment. Hört, hört!

Supporting Distributed Team Work

Über das Retten von notleidenden Projekten

1 Kommentar

Neulich erschien ein guter Artikel auf PM Hut zum Thema “Retten von notleidenden Projekten“. Die Kernthesen:

  1. Führung austauschen
  2. Mitarbeiter austauschen
  3. Zusammenarbeit fördern
  4. Kommunikation ändern
  5. Meetings streichen
  6. Prioritäten überarbeiten
  7. Informationen an das Management verbessern

Wohl dem, der als Feuerwehr berufen wird und diese Autorität eingeräumt bekommt. Besonders der erste Punkt ist oft schwer durchführbar — wann kann ich schon die wichtigsten Stakeholder austauschen?

Oft liegt der Grund für notleidende Projekte darin, dass die Stakeholder nur unzureichend identifiziert wurden. Das führt dazu, dass Anforderungen vergessen wurden und im Nachhinein als Killerkriterium berücksichtigt werden müssen. Insbesondere Abhängigkeiten und Folgeeffekte von komplexen Prozessen werden gerne übersehen und stellen sich als Stolpersteine für das Projektziel heraus. Dies oft zu einem Zeitpunkt, wenn die Design- und Erstellungsphase abgeschlossen sind: während des Tests — mit echten Usern!

Daher muss der erste Schritt immer ein Kassensturz sein:

  • wer sind die Stakeholder?
  • sind diese ausreichend informiert/involviert?
  • sind alle Anforderungen klar und abgestimmt (abgezeichnet)?
  • sind die Seiteneffekte auf angrenzende Prozesse aufgezeigt, verstanden,berücksichtigt und kommuniziert (Blick über den Tellerrand)?

Manchmal neigt das Management dazu, hier den entscheidenden Fehler zu machen:

Lass’ uns mal nicht alle involvieren, da wecken wir nur Begehrlichkeiten. Dann wird das Projekt zu groß und wir bekommen es nicht genehmigt oder es wird ein Endlos-Projekt!

Diese Entscheidung kann sich bitter rächen! Besser ist es, einen klaren Fahrplan zu vereinbaren und eventuell Folgeprojekte in Aussicht zu stellen. Sollte sich ein guter Business-Case ergeben, steht einem Anschlussprojekt bestimmt nichts im Wege.

In einer Projektkrise hilft immer:

  • Stakeholder (neu) identifizieren
  • Anforderungen erkennen
  • … und neu priorisieren
  • neues Ziel: kurzfristige Erfolge!

Auch sind Mitarbeiter nicht beliebig austauschbar — jedoch ist ein kleiner Trick hilfreich: Installieren von Fokus-Gruppen. Dies beschreibt auch Barry Otterhold in seinem Artikel. Rufe die richtigen Mitarbeiter (am Besten räumlich) zusammen und bringe einzelne Probleme in den Brennpunkt dieser Gruppe. Bestimme einen (temporären) Teilprojektleiter für jede Fokus-Gruppe und verlange regelmäßige (tägliche) Updates. Die Zusammensetzung jeder Gruppe muss dem Problem folgen — oft stellt man hier fest, dass die bisherige Zusammensetzung von Teams nicht sinnvoll war. In komplexen Prozessen muss sicher gestellt sein, aus allen Bereichen fähige (die Besten!) Mitarbeiter in eine fruchtbare Arbeitssituation zu bringen. Wieder mit dem Ziel: kurzfristige Erfolge!

Ich bin der Erste, der überflüssige Meetings von der Agenda streicht.

Wir sind ständig in Meetings — wann sollen wir unsere Arbeit machen?

… ist ein klassischer Einwurf. Gerade in Not-Situationen nimmt die Meeting-Inflation zu — die Unsicherheit steigt, jeder will irgendwie richten, fühlt sich nicht gut informiert, usw. Es macht nicht nur daher Sinn, die Meeting-Struktur zu überdenken und überflüssige Meetings zu streichen. Gerade Mitglieder einer Fokus-Gruppe müssen weiträumig freigeschaufelt werden!

Auf der anderen Seite geben Meetings (Rituale) Sicherheit für alle Projektbeteiligten. Ich bin sehr für klare und kommunizierte Checkpoints (Jour-Fixe) für bestimmte Teilnehmerkreise:

  • Arbeits-Meetings (Workshops) können die Mitarbeiter selbst bestimmen und einberufen. Bitte hierfür “War-Rooms” bereitstellen und nicht mit Meeting-Räumen geizen! Dedizierte Projekt-Räume sind Gold wert (sehr lesenswert: How Does Radical Collocation Help a Team Succeed?)
  • Update-Meetings aus den Fokus-Gruppen sollten regelmäßig einberufen werden. Hier werden aber nicht die Probleme gelöst, sondern es werden 3 Dinge kommuniziert:
    • was wurde erreicht?
    • was steht an (Ziel bis zum nächsten Checkpoint)?
    • welche Probleme gibt es die einer Entscheidung bedürfen, die nicht auf Arbeitsebene beschlossen werden können?
  • Steering-Board

Mit kleinen Mitteln kann schon viel erreicht werden. Für meine Feuerwehr-Einsätze wähle ich selten die Axt, sondern gesunden Menschenverstand und versuche, Ordnung und Sicherheit wieder herzustellen. Na klar: in einer Krise müssen auch manchmal drastische Maßnahmen folgen — aber nicht als erstes Mittel der Wahl.

Das bringt mich zum Thema “kurzfristige Erfolge” — ist das neue Überdenken der Ziele, Prototyping und der iterative Ansatz nicht Kern-Bestandteil des “Extreme Project Management“?

Projektkommunikation — 10 Erfolgsgesetze

1 Kommentar

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 …

  1. Lügen haben kurze Beine
  2. Immer schön bei der Wahrheit bleiben
  3. Auch Kommunikation muss geplant werden
  4. Nutzen Sie das Potential von Meetings
  5. Sinnvolle Protokolle werden sogar gelesen
  6. Nur gezielte Kommunikation findet den Empfänger
  7. Choleriker haben keine Chance
  8. Storytelling ist der Schlüssel zu verspannten Gehirnen
  9. Projektmanagement ist nicht Schow-Business für Häßliche
  10. Manchmal ist Wissen eine Holschuld

In den nächsten Tagen werde ich einzeln auf diese Punkte eingehen.

Das neue ABC des Projektmanagements

Kein Kommentar

Na gut — so neu ist es nicht. Trotzdem toll, dass jemand diese drei Punkte als Eckpfeiler des eigenen Management-Ansatzes macht:

  1. Anticipate. Also so etwas wie Vorausahnung, Weitblick oder Weitsicht. Probleme erkennen, bevor sie offensichtlich sind und diese mit geeigneten Waffen in die Flucht schlagen
  2. 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
  3. 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.

Der “agile” PMP

Kein Kommentar

Ein Thema interessiert mich seit Längerem: was können wir “klassischen” Projektleiter von agilen Methoden ala Scrum lernen?

  1. 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
  2. kurze Iterations-Zyklen mit klaren Zielvorgaben helfen dabei, frühzeitig Design-Fehler zu erkennen oder das Produkt neuen Anforderungen anzupassen
  3. im Vordergrund steht ein funktionierendes Produkt, “Schmuck am Nachthemd” wird vermieden oder bewusst implementiert
  4. letztendlich sind die Methoden des agilen Managements perfekt auf die obigen Anforderungen zugeschnitten und können mit ein wenig Anpassung perfekt übernommen werden

Huppala: das sind die Werte des agilen Manifests!

“Individuen und Interaktionen gelten mehr als Prozesse und Tools”

“Funktionierende Programme gelten mehr als ausführliche Spezifikation”

“Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen”

“Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans”

Da wird ein Buch draus — versprochen! Bis dahin versprühe ich meine Gedanken hier ;-)

Interessanter Link zum gleichen Thema: The Agile PMP

Sag’s mit einer Geschichte!

1 Kommentar

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 …

Manager-Tools: Serie über Projektmanagement

Kein Kommentar

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!

TiddlyWiki als Projektdokumentation

2 Kommentare

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!