Worst Practice

Worst Practice für erfolgreiche Projekte oder Wie bringen wir ein Projekt garantiert zum scheitern?

Best Practice Ansätze und Erfahrungswerte sind gut, lehrreich, nützlich und in aller Munde. Aber seien wir doch mal ehrlich, häufig auch ein bisschen langweilig! Ist es nicht viel spannender aus Fehlern zu lernen! Diese Überlegung hat uns zur neuen Rubrik Worst Practice“ im Projektmanagement angeregt: wie können wir Projekte zuverlässig behindern, beschädigen oder sogar zum Scheitern bringen!

Viel Spaß beim Lesen und wie wär es mit Deinen/Ihren „Worst Practice“ Beispiele und Geschichten? Wir sind gespannt darauf!

Die Ergebnisse der Session vom PM-Camp 2012, sie sind mit einem * gekennzeichnet

Übersicht Worst Practice Methoden

Für eine bessere Übersicht haben wir die Worst Practice Methoden und Ansätze in verschiedene Gruppen klassifiziert und eingeteilt. Wir möchten zu möglichst vielen Worst Practice Methoden eine Unterseite mit Zitaten und Erfahrungswerten anlegen. Alle openPM Nutzer sind eingeladen Ihre Erfahrungen weiterzugeben.

Auftraggeber, Führung und Management

  • Als Projektleiter den besten Fachspezialisten auswählen
  • Risikomanagement ist etwas für „Angsthasen“, unsere Projektleiter sind erfahrene „Firefighter“, die schaffen das auch ohne!
  • Information als Machtabsicherungs-Instrument nutzen, z.B. den Projektplan vor dem Team geheim halten
  • Ziele möglichst unklar definieren *
  • Projektscope nachträglich erweitern - ohne Anpassung von Zeit und Budget *
  • Zu viele Projekte geichzeitig - trotz Ressourcenmangels
    ein Projekt geht immer noch rein! *
  • Parallele Projekt sind Konkurrenz *
  • vollkommen unmögliche Termine festsetzen, nach dem Motto, es muss doch schneller gehen! * (sportliche Termine - Für Finger Pointing kann man ja immer noch eine/n Projektmitarbeiter/in finden, wenn die Termine nicht eingehalten werden.)
  • das Budget vom Controlling festsetzen lassen - ohne Mitsprache des Projektleiters oder des Teams *
  • Projektmanagement brauchen wir nicht, wir machen einfach eine Task-Force *
  • Immer "Nicht-Entscheidungsbefugte" als Stellvertreter in wichtige Meetings schicken *
  • Ein HIPPO hat immer recht - "Highest Paid Person's Oppinion" *
  • 160 % Auslastung für Projektmitarbeiter - aber nicht transparent machen *
  • 100 % Effizienz fordern*
  • Auftraggeber entscheiden flexibel nach dem Motto: "Was kümmert mich mein Geschwätz von gestern" *
  • Wir sind für Ideen und Lösungen offen! (Sie dürfen aber keine Kosten verursachen!)
  • Projektleiter und Team Projektbasiert entlohnen (Bonussystem - Sie werden alles für den Bonus tun, aber nichts für die Zielerreichung)
  • "...der Projektleiter hat die Gesamtverantwortung" (Management sieht bei Verbrauch des halben Budgets und der Hälfte der Projekdauer und 20% FGR und Status "grün" keine Notwendigkeit des Eingreifens oder eine Erklärung vom PL zu fordern).
  • Als Manager der Linie in die Rollendefinition des Projektes eingreifen und den PL dadurch bloßstellen.
  • AL " Wenn die Fachkollegen UML nicht verstehen ist das wohl das falsche Werkzeug."
  • Das Projekt ist in Verzug: egal welche Probleme zu lösen sind, stocken sie das Projekt personell auf....
  • Das Projekt ist außerhalb des Budgets: egal, entlassen sie die teueresten externen Mitarbeiter....und reduzieren sie die geschätzten Aufwände damit diese auf das reduzierte Team passen.
  • Mittleres und oberstes Management geben den Projektmitgliedern direkt Anweisungen, ohne den PL zu informieren und über dessen Kopf hinweg. (Anm.: könnte auch in die Rubrik "Kommunikation" gehören)

Projektleitung

  • Teammitglieder sind nicht wirklich wichtig, man kann sie jederzeit austauschen und Projektteams mit Druck und Geringschätzung führen (bekannt als Zuckerbrot und Peitsche).
  • Als Projektleiter „Everybodys Darling“ sein wollen. (Everybodys darling, ist everbodys Depp).
  • Unbedingt einen MS-Project-Plan machen, mehr braucht man nicht!! *
  • Planung ist unnötig - je eher wir starten, desto früher sind wir fertig *
  • Umterschiedliche Kulturen ignorieren *
  • Der Aufwand für die Projektleitung ist für alle Projekt gleich, Projektmanagement kostet genau 13,4 % vom Budget * (Anm.: O-Ton aus der Praxis: "Bei uns ist der PM-Aufwand immer so 3 bis 4 Tage pro Monat, egal wie groß das Projekt ist.")
  • Vorgehensweise bzw. Vorgehenswmodelle immer festlegen, bevor das projekt überhaupt startet:
    Scum oder Wasserfall oder V.Modell ist immer besser *
  • Als Projektleiter selbst operativ tätig sein (selbst Konzepte schreiben, selbst Entwickeln, konzipieren, planen, usw.)
  • Sicherstellen, dass Teilprojektleiter und Teammitglieder keinesfalls ein "Big Picture" erhalten, sondern immer nur so wenig wie möglich Informationen erhält.
  • nicht dafür sorgen dass Team-Regeln erstellt werden (wie wird was kommuniziert, wie gehen miteinander um, vor allem abr einfach vergessen: Probleme des Teams bleiben Probleme des Teams und werden im Team gelöst)
  • Tool der Wahl: EXCEL. für Anforderungen, Tickets, Abstimmungsrunden....anstatt JIRA mit Workflow.....(warum: weil der PL nur EXCEL kennt); verhindern sie als PL mit der Wahl des richtigen Werkzeugs dass Kommunikation über verteilte Teams hinweg funktionieren kann. Behalten Sie am besten als "Owner" der jeweilgen aktuellen Version der Datei stehts den Überblick (und wehe es ändert jemand etwas ohne dass sie es mitbekommen...)
  • "Wir (und damit meine ich mich) Imperator Rex" (Anm.: des Bearbeiters: sorry, den muss ich bringen...)
  • Nur ein PL, wobei die Projektgröße mehrere Teams mit Teil-PL's erfordern würde.

Projektteam

  • In Projekten nur die eigenen Lieblingsideen verfolgen
  • Konflikte meiden *
  • Risikomanagement ist etwas für "Weicheier"
    konsequentes und erfolgreiches Ignorieren von Risiken läßt das Projekt besser aussehen *

  • immer schnelle Entscheidungen einfordern
  • Wir wissen doch was und wie es zu tun ist, wir brauchen keine Prozesse. Lasst uns einfach loslegen.
  • Eine gemeinsame Teamkultur entwickeln? Wir sind doch nicht im Kindergarten und auch keine Selbsterfahrungsgruppe.
  • jeder Konflikt im Team wird an die nächst höhere Instanz (Abteilungsleiter, Bereichsleiter) eskaliert, nach dem Motto "Kollege xy, will nicht so spielen wie ich will."
  • am Besten eskalieren sie alles....selbst eine nicht mögliche Reisebuchung....trennen sie keinesfalls wichtige Probleme von trivialen und nerven sie das Management permanent mit Kleinigkeiten.

Reporting und Kommunikation

  • Kommunikation ist etwas Passives *
  • "Eh klar!"-Moderation *
  • "Wassermelonen-Reporting" sorgt dafür, dass nach Oben Grün gemeldet wird, auch wenn Rot drin ist *
  • "Techniker tuscheln technikverliebt"
  • Mitarbeiter geben exakte Antworten, nur wenn sie gefragt werden und nur auf die Frage *
  • Schriftliche Berichte Lösen Probleme *
  • am Besten kommuniziert es sich mit großem Verteiler per Email - CC: und BCC: *
  • möglichst umfangreiche Präsentationen nach den Methoden
    KDV (für Kinder, Deppen, Vorstände) oder
    BBBB (Bunte Bilder für blöde Bosse) *
    KLV (Kinder, Laien, Vorstände)
  • Meetingkultur - lange Meetings mit vielen Teilnehmern definieren und erhöhen den eigenen Status *
  • Nach dem Projekt ist vor dem Projekt -keine Reviews oder "Lessons Learned"
  • Team "Basisentwicklung", "Entwicklung" und "Fachbereich" reden nicht mit einander, Man hat Schnittstellen-Personen benannt die die Kommunikation zwischen den Gruppen übernehmen.-> Man hat "stille Post"-Kommunikation verordnet, mit der Androhung der Entlassung wenn sich jemand nicht daran hält.
  • Der PL organisiert kein JoureFix, keine Workshops, Selbstorganisation von Teams ist gefragt in einer sonst chaotischen Organisation.
  • PL: "Ich habe folgende Ansage: ...." 
  • "Machen Sie doch einfach, aber hören Sie auf zu denken." (PL an einen BusinessAnalysten)
  • Ein Glossar fehlt

Selbstmanagement als PL

  • Sich als PL um alles kümmern (Zugangsberechtigungen, Rechnungen, Hotelbuchungen etc.) anstatt sich dafür eine Assistenz zu organisieren.

Stakeholder

  • In einem strategisch wichtigen Projekt Verträge der vermeintlich teuren externen Spezialisten ohne Vorwarnung canceln und diese durch interne Mitarbeiter (frisch von der Schulbank) ersetzen, die ansonsten nichts zu tun hätten. Scope und Termine bleiben hierbei selbstverständlich erhalten.
  • Stakeholder - vor Allem die unbequemen - ignorieren * (Anm.: aussondern, die haben nämlich ein "Kommunikationsproblem")
  • Führen Sie das Projekt am besten ohne (End-)Kunden durch, der stört sowieso nur.

Prozess

Noch nicht zugeordnete Punkte

  • Projekte starten bevor überhaupt Personal zur Verfügung steht *
  • Kein Ramp-up *
  • stellen sei keinesfalls die Arbeitsfähigkeit des Teams her, machen sie das im laufenden Betreib, legen sie mit dem Projekt sofort los.
  • Minimale Standards werden nicht eingehalten, gesunden Menschenverstand (Hausverstand) gibt es nicht *
  • sich übergenau an alle Regeln halten *
  • Complicance steht über allem....geht soweit, dass Arbeiten über VPN nicht möglich ist, weil zu "unsicher".....-> Shizophrenie und Hochsicherheit für "nicht kritische Software"
  • bei der Anforderungsanalyse werden rechtliche Aspekte ignoriert
  • Nichtfunktionale Anforderungen werden nicht erhoben.

Input #pmcamp12 ( ist inzwischen eingestellt und mit * markiert)

(Bild in Originalgröße, 9,3 MB)

Literaturempfehlungen

  • Das kleine Handbuch für den Projektsaboteur, 
    D. Kotteman und J. Gietema, Wiley-VCH, Weinheim, 1. Auflage 2010
  • Anleitung für Projektvernichter, 
    H.W. Kötting, Books on Demand, Norderstedt, 2007
  • The 77 Deadly Sins of Project Management, 
    Management Concepts, Vienna VA 22182, 2009
  • Adrenalin Junkies & Formular Zombies - Typisches Verhalten in Projekten, 
    Tom DeMarco und KollegInnen, Carl Hanser, München und Wien, 2007
  • Die nackte Wahrheit über Projektmanagement,
    W. Reiter, Orell Füssli, Zürich 2003 

Links zum Thema

Twittern

13 Comments

  1. Sehr schöner Anfang! Die Übersichtsdarstellung in Tabellenform erscheint mir persönlich etwas misverstänlich, da zumindest ich geneigt war, innerhalb einer Zeile einen inhaltlichen Zusammenhang zu vermuten (smile) Hat jemand Einwände gegen eine Umstellung auf eine Listendarstellung?

    1. Danke , finde ich übersichtlicher.

    2. Finde ich ok so. Vielleicht müssen wir dann später für die Gruppen einzelne Unterseiten anlegen, wenn wir richtig viele Worst Practice haben. Bei >40 Listenelementen müßte man dann viel scrollen. Aber gucken wir mal wieviel Input in den nächsten Tagen kommt (smile)

  2. Keine Einwände. Einfach ausprobieren.

  3. Gib es das Bild vom #pmcamp12 in einer höheren Auflösung?

  4. Ralf Eichner Ich habe unter dem eingebetteten Bild das Originalbild (9,3 MB) verlinkt. Du kannst auf das vorhandene Bild auch drauf klicken, dann geht es größer auf.

  5. Dazu gibt es auch einen Podcast von Mario Neumann http://www.dasabenteuerleben.de/die-letzten-artikel/detailseite-artikel/dapr34-wie-man-projekte-in-den-sand-setzt-51.html

    DAPR34 - Wie man Projekte in den Sand setzt

    Kennen Sie das auch, dass Projekte zu lange dauern, teurer werden als geplant und im Vergleich zu den Erwartungen ein eher enttäuschendes Ergebnis liefern?

    Wer kennt das nicht? Ein Projekt wurde „eigentlich“ von A bis Z geplant, aber je näher der Abschluss-Termin rückt, desto mehr holpert es bei der Umsetzung. Das Projektteam zieht nicht an einem Strang, dem Projektleiter schwimmen die Felle davon und von allen Seiten gibt es Störfeuer. Am Ende liegen die Nerven blank. Es wird nur ein Bruchteil der ursprünglichen Projektziele realisiert und jeder schiebt die Schuld auf den anderen. In der 34. Folge meines „Abenteuers Projekte“ möchte ich Ihnen zeigen, wie man Projekte gezielt in den Sand setzt.

  6. Ich konnte bei der entsprechenden Session auf dem #pmcamp12 leider nicht mitmachen, dann ergänze ich jetzt einfach (smile)

  7. Habe ein paar Links eingefügt und auch einen auf einen eigenen Blog-Beitrag. Ist das "zulässig" oder eher unerwünscht?

  8. Ich habe mal einen Punkt ergänzt unter "Führung" - Bonussysteme im Projektgeschäft sind schädlich!

    Interessant zu dem Thema finde ich das Buch von Edward Yourdon "Death March Projects" (Todesmarsch-Projekte - Ein Auszug aus dem Buch).

    Im Buch definiert er Todesmarsch-Projekte wie folgt:

    1. Die Zeitplanung wurde um die 50% gekürzt (geht ja alles schneller)
    2. Das Budget wurde um 50% gekürzt 
    3. Das Team wurde um 50% verkleinert
    4. Technische Rahmenbedingungen für das Projekt sind doppelt so hoch wie unter normalen umständen

    Zu 4)
    Das betrifft beispielsweise folgendes Szenario: Kunde möchte das Projekt durchführen, jedoch möchte er die Software auf einem Server installieren das nur halb so schnell ist wie es üblicherweise der Fall ist. Oder, er möchte doppelt so viele Features, Produkte, Benutzer auf dem System haben trotz gleichbleibender Hardware. 

  9. Ich möchte ergänzen:

    Priorisierung ist nicht notwendig, alle Punkte sind die Wichtigsten! Die werden dann gern noch mit den Überwichtigen "Jetzt sofort!" Aufgaben ergänzt.

    Das gilt für Management, Projektleitung,Projektdefinition bis zu den Workpacks.

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen