Inhalt : 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

• Mindset im Unternehmen paßt nicht bei der Einführung eines neuen Prozesses
• Blog Beitrag von Sven Tiffe: Wie man den Scrum Prozess sabotiert
• Über Prozess reden, ohne zu unterscheiden, ob es sich dabei um (Projekt-)Managementprozesse, operative (Projekt-)Leistungserstellungsprozesse oder (Projekt-)Unterstützungsprozesse handelt oder um einen technischen Prozess auf einer CPU.

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

• 6 behaviours that could ruin your project (Project Manager Education & Opinion, 21. Juni 2012)
• How to ruin a project (Canned Platypus, 3. Mai 2011)
• How to ruin a project? (Project Management Questions, Januar 2012)
• Zehn Tipps, wie Sie Ihr Projekt beim Start zuverlässig ruinieren (Projektmensch-Blog, 16. April 2012)
• Meeting Mania: Überlebensstrategien im Meetingzeitalter