Projektmanagementsünde 10 – Ressourcen

Zunächst haben aufmerksame Besucher bereits gesehen, dass ich die Titel dieser Serie geändert habe. Nach dem grauenhaften und sinnlosen  Morden in Norwegen, wurde mir wieder bewußt, wie schnell wir mit den Worten “Tod”, “Hass” und ähnlichem zur Stelle sind, diese Worte aber durch die Realität ganz andere, tiefere Bedeutungen bekommen können.

Zurück zum Thema. Das letzte dieser Reihe sind die Ressourcen:

Ach vergiss es… immer zu wenig, immer zu knapp. Wenn nicht, hast du was falsch gemacht. Siehe Punkte Finanzen, Umsetzung, Delivery Streams, Management.

Es ist ein Teil des natürlichen Wesens von Projekten, dass hier immer eine Knappheit von Ressourcen besteht. Diese Knappheit bedingt die extreme Fokussierung auf ein Projektziel und die Konzentration aller Kräfte auf die Erreichung desselben. Soweit die guten Seiten der begrenzten Mittel.  Dumm gelaufen ist das ganze nur, wenn es kein einheitliches Ziel, keine einheitliche Linie im Managment und keine Unterstützung aus den Abteilungen gibt (die vermutlich selbst extrem in ihren Zielen und Ressourcen eingeschränkt sind).

Nimmt man alle Punkte zusammen, die sich in der Reihe der Projektsünden ergeben, fügt sich ein wunderbares Bild zusammen, wie ein Projektleiter zu schlaflosen Nächten kommt. Wenn dazu noch eine Prise Perfektionismus und Erfolgsdruck dazukommen, ist der Schlammassel angerichtet.

Interessanterweise kann es noch besser kommen. Nämlich, wenn der Projektleiter ausserstande ist zu kommunizieren. Klingt ein wenig komisch, aber Menschen, die weder andere grüßen, noch nach Monaten die Namen ihrer Projektmitabeiterinnen kennen, die direkt neben ihnen sitzten, tuen sich schwer, das Projekt zu vertreten. Sogar noch einen Schritt weiter wage ich zu behaupten, sie tuen sich schwer, das Projekt zu verstehen. Damit ist das Disaster bereits vorgezeichnet.

Ist es wirklich so schlimm? Nun nicht ganz, aber nur durch Erfahrung und persönlichen Einsatz schafft man den Weg zum Projektsamurai [link zum artikel der informationsarchitekten] – ein Begriff, der mir durch die Bedeutung des Samurai in der historischen Gesellschaft gefällt: Ehre und Kampf. So kann Projektarbeit wieder Spaß machen.

Projektmangementsünde 9 – Management

Heute geht es weniger um die Tätigkeit des Managements als vielmehr um die Unterstützung des Managements bei einem Projekt. Nachdem sich Projekte in anderen Größenordnungen abspielen als tägliche Änderungen und Implementierungen, haben sie auch die Aufmerksamkeit der Führungsebene. Dabei spielt vor allem der Lenkungsausschuss eine große Rolle, der das Projekt begleiten, lenken und die Rahmenbedigungen scahffen soll. Hier geht es natürlich auch um Entscheidungen, die auf einer Eskalationsebene zu fällen sind.

Natürlich hat dir das Management sämtliche Unterstützung für das Projekt zugesagt. Natürlich bekommst du sie nicht. Erstens kannst du die nicht konkret genug in der richtigen Sprache formulieren (vor allem, wenn du den Punkte Struktur nicht eingehalten hast) und zweites stell dir selber mal die Frage: warum sollte ich als Führungskraft eine Entscheidung treffen, wenn der Projektleiter sie selbst treffen kann – immerhin ist er dann am Ende Schuld. Wenn alles gut geht, war natürlich jede einzelne Führungskraft mit Rat und Tat dabei. Wenn nicht, du weißt, welcher Kopf am Ende rollt.

So oder ähnlich passiert es wohl immer wieder. Vor allem, wenn der Projektleiter keine oder kaum Unterstützung aus der eigenen Abteilung hat, geschweige denn von den Fachbereichen, die sich über ihre Projektziele nicht einig sind. Diese Punkte wurden ja schon behandelt.

Dennoch überrascht es immer wieder, wie schnell ein  Projekt und damit auch dessen Leiter zum Spielball in einem Management Meeting werden kann. Da wird in Detailfragen nachgebohrt bis zum kleinsten gespaltenen Atom und in großen strategischen Überlegungen die Verantwortung auf den Projektleiter geschoben. Hält wunderbar ein paar Nächte lang an und denjenigen wach, der irgendwann mal “ja” zu diesem Wahnsinn gesagt hat.

Projektmanagementsünde 8 – Persönliches

Das Problem mit der Persönlichkeit eines Projektes erwächst nicht selten aus der Motivation heraus: ist diese von ureigensten Zielen und Antrieben definiert, ist es unmöglich, das Projektgeschehen nicht persönlich zu nehmen.

Niemals etwas persönlich nehmen – zumindest wird dir das immer wieder gesagt. Aber jede Kritik wirst du als Projektheini abbekommen, und das nicht zu knapp. Auch die Richtung von nützlichen und schwachsinnigen Kommentaren ist nicht vorher sehbar. Sei dir sicher, sie kommen von überall – denn jeder weiß schließlich am Besten, wie dieses Projekt zu machen ist (vgl. Motivation).

Gemeinsam mit den anderen Todsünden in dieser Sendereihe ist diese hier diejenige, die dir als Projektleiter den meisten Schlaf rauben wird. Das Projekt ist “dein Projekt” und wenn es dem Projekt gut geht, geht es auch dir gut. Schlimmerweise laufen lt. dem Chaos Report [link wikipedia] nicht mal 20% aller Projekte gut ab – ich kenne die Kritiken am Chaos Report, aber dennoch ist das immer wieder ein guter Orientierungspunkt.

Wenn wir den Wikipedia Artikel betrachten, dann finden wir unter den Erfolgsfaktoren  folgenden Eintrag:

Die festgestellten Haupterfolgsfaktoren sind:

1. Einbindung der Endbenutzer
2. Unterstützung durch das obere Management
3. Klare Anforderungen

Die Hauptpunkte, die zum Scheitern der Projekte führen sind:

1. fehlende Zuarbeit durch Benutzer
2. unvollständige/unklare Anforderungen
3. häufige Anforderungsänderungen

Siehe da, nicht besonders überraschend für mich, passen diese auf die Liste bei mir: Deadlines, Kommunikation, Anforderungen usw. finden sich bereits in der Aufstellung und zwei weitere kommen noch.

Zurück zur Persönlichkeit – sollte demnach ein Projekt keinen persönlichen Stil, keine individuelle Prägung erkennen lassen und nur aus Distanz mit Zahlen und Daten geführt werden? Meiner Meinung nach nicht, aber es muss von Beginn an klar sein, dass eine berufliche Rolle eine solche ist. Darauf sollte jeder im Projektumfeld eingestellt sein und eine Vorbereitung zu diesem ist Zeit, die nicht verschwendet ist.

Projektmanagementsünde 7 – Umsetzung

Nach der Anforderungsdefinition aus dem Fachbereichen, die sich selten auf ein Ziel einigen, kommt dann die Umsetzung auf die IT MitarbeiterInnen zu. Klar sind durch die Requirements die Wege vorgegeben, aber auch Schätzungen sind nur Schätzungen und damit auch mal falsch. Dazu kommen jedoch meist die optimistischen Aussagen, wie “wird sich schon ausgehen” oder “das schaffen wir schon”. Natürlich gibt jemand selten zu, sich bei einer Aufwandsabschätzung geirrt zu haben und noch weniger, mit der Arbeit innerhalb der genannten Zeit nicht zu Rande zu kommen. Denn das wäre doch wieder ein Eingeständnis von falschen Aussagen.

Vertraue niemals den EntwicklerInnen. Wenn du sie fragst, wird immer alles rechtzeitig fertig sein – sofern die Deadline nicht morgen ist (vgl. auch Deadlines). Andererseits ist niemals alles so definiert, dass ein Programmierer sofort mit seiner Arbeit beginnen kann, egal was der Fachbereich dokumentiert, sagt oder anfordert. Plane diese Kommunikationszeiten in deiner Planung ein. Vergiss aber nicht, niemanden den Puffer zu verraten (vgl. Finanzen).

Wieder  mal sehen wir eine nette Zwickmühle. Einerseits Deadlines einhalten, andereseits Definitionen innerhalb der Zeiten fertig zu bringen, die unterschiedlichen Zielsetzungen folgen und dann auch noch soweit strategisch zu planen, dass es einerseits nicht offensichtlichen Puffer gibt und andererseits nicht den kompletten Plan zerstört. Ein Dilemma, das sich umso sehr verschlimmert, wenn das Management auch nicht eine einheitliche Zielsetzung verfolgt, sondern sich auch auf Projektebene gegenseitig in die Flanken fällt.

Projektmanagementsünde 6 – Delivery Streams

Ein IT Projekt wird normalerweise nicht um seiner selbst willen umgesetzt, sondern bedarf immer eines Inputs bzw. einer Zielsetzung von aussen. “Aussen” meint in diesem Fall mindestens einen Fachbereich (Legal, Sales, Marketing, Customer Service, etc) und dessen Anforderungen, die mit der Projektimplementierung verbessert/eingeführt/realisiert werden. Bei einem größeren Projekt ist es selbstverständlich, dass mehrere Fachbereiche mitspielen und mit unterschiedlichsten Standpunkten und Definitionen von Zielen kommen und diese umgesetzt sehen wollen.

Dabei nimmt die IT einen besonderen Stellenwert ein. Einerseits hat sie selbst Auflagen (z.B. Sicherheitsrichtlinien) und Anforderungen (Wartbarkeit, Performance, Testbarkeit etc.), andererseits wird der IT die Entscheidung über die Umsetzung der verschiedensten Anforderungen aufgebürdet. Diese Bürde bedingt, dass der Projektleiter immer mehr zum Schiedsrichter zwischen den Fachbereichen wird und aus dem Schiedsrichter wird sehr schnell ein Spielball.

Politische Entscheidungen und strategische Allianzen enden nicht, wenn eine Tür zu einem Projektmeeting geschlossen wird. Schlimmer wird es nur, wenn das First-Line Management auch noch unterschiedliche Erwartungen bezüglich des Projektziels hat. Denn dann wird auch der Leitungsausschuss zu einem Haifischbecken für den Projektmanager bis hin zu der Tatsache, dass er Entscheidungen für das Unternehmen treffen soll (siehe einen der kommenden Punkte bezüglich Management).

Aber zurück zu unseren involvierten Fachbereichen – genau diejenigen, die ja keine Deadlines oder Meilensteine kennen (wollen). Wenn sich nun diese auf ein Projektziel einigen sollen oder das Projektziel definieren, kommt so ziemlich immer das selbe raus:

Versuche nie, es allen Fachbereichen frei zu lassen, was sie von deinem Projekt zu erwarten haben. Du bekommst niemals einen Scope. Alles ist immer wichtig und egal, wann der Fachbereich fertig wird, die IT ist sicher schuld, dass es nicht so umgesetzt wurde, wie angefordert. Es ist auch egal, wie die Anforderung definiert wurden, das Ergebnis ist nicht zufriedenstellen.

Was sehen wir hier? Erstens gibt es kein festgeschriebenes Ziel. Schwierig für jeden im Projekt, denn wonach ausrichten, wenn der wichtigste Leuchtturm fehlt? Zweitens (hängt sehr stark mit den Deadlines zusammen) kommt es immer zu Verzögerungen. Nachdem nun die IT die Anforderungen implementiert, beissen sie als letzten die Hunde. Klarerweise kommt dann immer die Fragestellung nach den Aufwänden der Umsetzung, aber nachdem die Requirements nicht definiert sind, können auch die Schätzungen nicht seriös abgegeben werden. Henne-Ei Problem somit.

Egal, schuld ist am Ende sowieso der Projektleiter, der zwischen den einzelnen Anforderungen, den politischen Spielchen der Fachbereiche und dem Druck der Umsetzungsziele zermalmt wird. Gibt es ein besseres Mittel zur Schlaflosigkeit?

Projektmanagementsünde 5 – Deadlines

Milestones und Deadlines, Deadlines und Milestones… ja, der Projektplan ist voll davon. Ist der erste nicht erreicht, dann geht es mit den Diskussionen los: wie gut liegen wir in der Zeit, welche Auswirkungen hat das, was müssen wir verschieben, wer kann das entscheiden usw. Altbekannt aus Funk und Fernsehen.

Um Planung dreht sich ja das halbe Projektleben und deshalb gibt es auch die wöchentlichen Projekt Meetings, die wöchentlichen Berichte, die täglichen Abstimmungen und die monatlichen Management Meeting. So weit, ok. Aber dass dann die Meinung vorherrscht, keiner kennt die Deadlines und Meilensteine ist doch eher gewagt. Klar ist, keiner kennt zu Beginn des Projektes die Auswirkungen, wenn Ziele nicht erreicht werden, aber der Plan wird permanent durchdiskutiert.

Darum gibt es die abschliessende Conclusio:

Setze Deadlines oft, viel und bestimmt ein. Wenn du es deinem Team überlässt, Limits zu setzten, wird dir das Management sagen, dass dein Team nicht weiß, bis wann es was zu liefern hat. Apropos Team: wiederhole die Deadlines täglich – du weißt was „täglich“ heißt? Jeden ver****ten TAG!

Scheint leider so zu sein. Lass anderen die Verantwortung und du wirst dafür verantwortlich gemacht. Lass anderen keine Verantwortung und sie werden dir ständig in den Ohren liegen, dass sich das NIE ausgehen wird. Was nun? Diskussionen sind nicht der Weisheit letzter Schluss und die Mühlsteine zwischen Deadline setzten und Deadline gesetzt bekommen mahlen unaufhörlich weiter.

Projektmanagementsünde 4 – Unterstützung

Auch oder gerade bei Projektarbeiten sind Projekte in einem Unternehmenskontext eingebettet und geniessen dort eine Art Sonderstellung. Denn der Inhalt sind zumeist Änderungen und Abläufe, die nicht dem gewohnten täglichen Standard entsprechen sondern grundlegende Changes zum Inhalt haben. Daher bekommen sie normalerweise die Aufmerksamkeit oder Unterstützung des gesamten Unternehmens. Richtig: normalerweise.

Denn es geht auch anders: das Projekt hat ein eigenes Budget und eine Ressourcen. Damit ist auszukommen, auch wenn die ursprüngliche Planung “für den Hugo war” (siehe auch Sünde 3 – Finanz) und sich Fragestellungen und Hindernisse auftun, die durch den täglichen Betrieb in kürzester Zeit zu lösen wären.

Erwarte nicht, dass die Abteilung, in der du bist, dich unterstützt. Wenn du zum Beispiel für den Abnahmetest keine Testumgebung von Beginn an geplant, angefordert und bezahlt hast, wirst du so einfach auch keine bekommen. Auch wenn im Unternehmen eine komplette „End to End“ Umgebung  - die nebstbei nur für 2 Tage/Monat benötigt wird – vor sich hin vegetiert – du bist im Projekt und hast dich selbst um eine zu kümmern.

Das ist natürlich frustrierend, denn zB ist der Aufwand und Betrieb einer weiteren Testumgebung ja nicht ein Pimpifax, sondern eine weitere Belastung für ein bereits überlastetes Team. Klar, verzichtet niemand so einfach auf eine Testumgebung oder die Leistung von MitarbeiterInnen, aber dennoch stellt sich dann die Frage der Unterstützung aus dem Unternehmen.

In diesem Fall wäre es vermutlich vernünftig gewesen, die Sache zu eskalieren und eine Entscheidung von ausserhalb zu erzwingen, als sich tagelang mit einer Alternativlösung oder Kompromissbereitschaft herumzuschlagen. Solche Überlegungen gehen an die Substanz, denn permanent das Gefühl zu haben, “da geht nichts weiter” und die zeitliche Druckkompomente wächst automatisch stetig, sind Faktoren, die durchaus den Schlaf rauben.

Projektmanagementsünde 3 – Finanzen

Stell dir vor, du planst etwas und diese Planung ändert sich. An und für sich kein Problem, möge man meinen, denn genau deshalb gibt es ein Projekt: plan, do, check, act – auch so eine feine kleine Methode, die fast jeder kennt, der sich im Projektumfeld befindet. Und wenn der “check” ein “act” erfordert, dann kommt es zur Anpassung von Planungen.

Nicht so bei einer strikten Budget Planung. Gib genau den Betrag aus, der Monate vor dem Projektbeginn für diesen Zeitraum geplant wurde. Ohne den Scope zu kennen, ohne das Projektteam zu kennen, ohne detaillierte Vorgehensweise und Planung. Hauptsache die Zahlen passen. Damit dieser Beitrag zum Thema “Todsünde” passt und nicht in die Kategorie “Hellsehen” wandert, ergibt sich aus einer solchen Haltung ein Problem:

Sage niemals, dass du einen Puffer geplant hast. Dein Budget ist bis auf den letzten Cent vom ersten Finanzplan an ausgebucht und verplant. Gibst du zu, dass du verantwortungsvoll genug bist, 20% deines Geldes für unvorhergesehene (aber sicher eintretende) Sonderfälle reserviert zu haben, wird es dir spätestens am Jahresende abgenommen. Egal, ob es bereits für dein Projekt freigegeben wurde oder nicht.

Niemals das Wort “Puffer” in den Mund nehmen. Nie. Große, fette Todsünde. So schnell bist du bis zu 20% deines Budgets los, so schnell kannst du “verantwortliche Planung” gar nicht aussprechen. Interessanterweise gilt das nur für Zahlen, die ein Euro Zeichen dahinter stehen haben. Denn eine Diskussion über Zahlen, die Personentage an Aufwand beziffern, werden permanent von allen möglichen und unmöglichen Menschen in Frage gestellt: dauert das wirklich so lange, das ist doch nicht eine so große Änderung, das kann ja nicht sein!

Hauptsache, der Euro stimmt auf jeden Cent genau nach einer Ausgabenplanung, die völlig aus der Luft gegriffen wurde, da niemand, wirklich niemand (ich war dabei) daran dachte, wie das Projekt ablaufen würde. Schon gar nicht wurden Zeiten intensiver Entwicklungsarbeit oder Testschwerpunkte berücksichtigt. Denn einfacher als nach dieser Formel geht es nicht: Projektbudget (€) / Projektdauer (m) = monatliche Ausgaben.

Daran ist nichts zu rütteln, sondern so muss es sein. Alles andere ist Schmafu und kann nicht so schön kontrolliert werden. Ja, sozusagen ist alles andere verantwortungslos!

Projektmanagementsünde 2 – Struktur

Wir alle kennen – sofern wir jemals in einem Projekt gearbeitet haben – verschiedene Vorgehensmodelle und gähnen jedes Mal, wenn ein Gantt Diagramm behauptet, die Wahrheit abzubilden. Ja, auch in diesem Unternehmen gibt es eine “normierte” Vorgehensweise, die jedoch völlig überbordet vor Dokumenten, Vorlagen und Excel Listen. Auf einen ersten Blick scheint es, als hätte sich da ein Projektmanager einen eigenen Standard erdacht und diesen einfach implementiert.

Das Problem, das sich daraus ergibt: es gibt nicht einen Weg, sondern mehrere. Es gibt nicht eine Wahrheit sonder viele. Aus dem Management sind die wenigsten mit den ganzen Varianten vertraut – in der “Working Class” überhaupt kaum wer. Klar macht man sich am Anfang Spielregeln aus, doch wenn der Projektsponsor und der Projektowner nicht mehr operativ tätig sind, dann sind diese Regeln hinfällig.

Also geht es mit Riesenschritten in die Falle der Todsünde 2 – abweichende Strukturen:

Denke niemals, dass du mit einer Nicht-Projekt Struktur durchkommst. Es kommen immer wieder dieselben Fragen vom Management und diese kannst du mit einer anderen – wie auch immer gearteter Vorgangsweise – ungleich schwerer beantworten. Damit kannst du sowohl das Management als auch MitarbeiterInnen in den Wahnsinn treiben… wenn du selbst nicht nach ein paar Wochen fertig bist.

Mit Nicht- Projekt Struktur ist alles gemeint, was nicht in ein klassisches Gantt Diagramm passt oder im MS Project abbildbar ist. Dazu gehören auch Methoden wie SCRUM, agile Entwicklung, XP oder testdriven Development.

Egal welche Methode zur Anwendung kommt, bei Gantt Erwartungen gibt es keinen Ausweg. Das ist beinahe so, als würdest du einen Mitarbeiter aus der Finanz/Controlling Abteilung mit einem Powerpoint kommen. Geht einfach net. Es kommt dir vor, als rennst du gegen eine Mauer. Nicht einmal sondern bei jedem ver****ten Meeting – das nervt, das zehrt an Kräften und das stürzt dich immer wieder in Eigenskepsis, denn zu Beginn warst du dir sicher: diese Methode funktioniert (sonst hättest du damit nicht begonnen). Traurigerweise scheint die Methode zu funktionieren, aber die Kommunikation läuft immer wie in einem falschen Film: Mongolisch mit vietnamesischen Untertiteln.

Projektmanagementsünde 1 – persönliche Motivation

Mittlerweile ist es ein Jahr her, dass ich ein Projekt übernommen habe und schon vier Monate seit ich es wieder abgegeben habe. In der Nachbetrachtung konnte ich eine persönliche Liste an Todsünden identifizieren, die mir so manche Nacht den Schlaf raubten und schlussendlich den Ausschlag gaben, das Projekt abzugeben. Also beginne ich mal mit Thema Nr. 1 – die Motivation.

Beginne nie ein Projekt aus einer persönlichen Motivation heraus. Schon gar nicht mit dem Ziel es besser zu machen als in einem anderen Projekt – Projekte sind niemals vergleichbar, darum stirbt diese Motivation in den ersten drei Wochen.

Und dann stehst du da – mit leeren Händen und ohne Aussicht auf Erfolgserlebisse. Denn woran misst du dich nun?

Das war wohl der erste Fehler: nur aus persönlichen Motiven heraus ein solches Projekt zu übernehmen, weil man meint, man könnte das doch besser als so manch anderer, ist ein Fehler. Dazu passend: weder über Gehaltserhöhungen und/oder Nachfolgeaufgaben zu sprechen, ist sofort der Folgefehler daraus. Denn dann gäbe es ja ein Ziel, auf das es hinzuarbeiten gilt, wenn der persönliche Antrieb weg fällt.

Diese Einstellung führt zur späteren täglichen Frage “Warum tue ich mir das blos an?”, die natürlich keine Antwort mehr findet. Gäbe es ein konkretes Ziel, ist die Antwort: “Weil ich mir dann den Porsche kaufen kann.”, die nach der Bedürfnispyramide [link wiki] nicht unbedingt das Gelbe vom Ei, aber dennoch ein Anreiz ist.

Ausserdem schafft eine solch persönliche Motivation einen enormen Eigendruck. Denn gemessen werden dann immer die eigenen Leistungen, aber an welcher Meßlatte? Natürlich an einer selbstdefinierten – und hier beisst sich die Katze in den Schwanz, denn wer kennt die Fehler und offenen Punkte am besten? Richtig: das Ego! Damit verfällt auch der schnell der letzte Rest an objektiver Beurteilung der eignen Leistung und der Druck, das perfekte Projekt (das es ja nicht gibt) abzuliefern steigt Tag für Tag, Fehler für Fehler. Teufelskreis? Klar doch und herzlich willkommen bei “der ersten Todsünde des Projektmanagements”.