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.