Projektmanagement und Homeoffice

Corona ist offiziell beendet und in der als "Post-Corona-Zeit" bezeichneten Lebensphase können wir Projektleiter und Scrum- Master nun endlich wieder das tun, was wir am liebsten machen: Uns in unseren besten Anzügen vor möglichst vielen Leuten in Projektstartworkshops, Kickoffs und sonstigen Meetings präsentieren oder im Falle der Scrum- Master bunte Zettelchen mit großen Worten an echte Wände kleben, sie von links nach rechts schieben (lassen) oder die genannten Zettel von den entsprechenden Wänden entfernen.

Leider kommen wir aber nun doch noch nicht so recht dazu, denn irgendein Querulant hat immer ein Kind aus dem Kindergarten zu holen, ein Auto in der Werkstatt stehen oder einen anderen Grund, mindestens auf ein hybrides Meeting zu drängen. Somit müssen wir die in freudiger Erwartung ausgepackten Whiteboard- Marker wieder im eigens dafür angeschaffte Gürtelholster verschwinden lassen, uns von dem Lucky- Luke Gefühl beim schnellen Ziehen der Stifte verabschieden und die Post- Its und Stattys notgedrungen durch das digitale Trello- oder Jira- Board ersetzen. 

Aber mal im Ernst: Wie viel persönliche Präsenz muss in Projektmeetings heute noch sein? 

Projektbusiness ist Peoplebusiness. Wir arbeiten nie an einer Sache, um ein Ergebnis zu erzielen, wir arbeiten immer mit Menschen, um ein Ergebnis zu erzielen. 

Demzufolge ist es vordergründig ein verständlicher Wunsch, die Menschen, mit denen wir arbeiten wollen, persönlich kennen zu lernen und von Angesicht zu Angesicht mit ihnen Ideen zu entwickeln und zu realisieren. Wir wollen letztendlich in bereichsübergreifenden Projekten und teilweise zwischen Fremden ein Wir- Gefühl erreichen, ohne das das Projektergebnis nur schwer zu realisieren ist. 

So weit, so gut- aber da haben wir die Rechnung oftmals ohne den Wirt gemacht. Die Projektmitarbeiter wurden für das Projekt abgestellt, oftmals ohne ihren eigenen expliziten Wunsch, am Projekt mitzuarbeiten, freuen sich über jede kleine Freiheit und Zeitersparnis dadurch, dass sie nicht mehr jeden Tag in die Firma fahren müssen, und sollen jetzt auch noch wieder regelmäßig nur für das doofe Projekt  im Stau stehen? Da ist Widerstand vorprogrammiert und niemand mag Projekte! 

Wie schaffen wir also den Spagat zwischen dem aus unserer Sicht Notwendigen und dem aus Sicht unseres Teams Vertretbaren?

Ich glaube, dass jede Führungskraft, insbesondere aber der Projektleiter immer mehr als Motivator auftreten muss. Insbesondere in der am häufigsten vorherrschenden Matrixorganisation von Projekten, in welcher der Projektleiter keine direkte und alleinige Weisungsbefugnis hat und nicht als disziplinarischer Vorgesetzter agiert, sind Soft Skills, Einfühlungsvermögen und nachvollziehbare Begründungen gefragt.

Damit meine ich: Der Projektleiter muss einen Ausgleich schaffen, jedem Teammeeting einen nachvollziehbaren Sinn für persönliche Anwesenheit geben und dessen Notwendigkeit selbst am kritischsten hinterfragen. 

Ein paar Beispiele:

Ein Projektstartworkshop ist das erste Event noch vor Projektbeginn. Das mutmaßliche Team kommt zu ersten Mal zusammen, wird mit der Problemstellung des Projekts zum ersten Mal konfrontiert und kann (hoffentlich) eigene Ideen und Wünsche dazu äußern. Das ist ein Event, welches ich sehr gerne in persönlicher Anwesenheit abhalten möchte, einfach um ein Gefühl der möglichen Zusammenarbeit unter den potenziellen Teammitgliedern zu bekommen und für maximale Produktivität. Ich möchte aber auch, dass dass die Teammitglieder bei diesem Event ein Gefühl füreinander bekommen und exklusiv und ausschließlich für das Projektthema da sind und nicht nebenbei durch eventuelle Kurzmitteilungen über andere Kanäle gestört werden. 

Der Startworkshop erfüllt schonmal die Voraussetzungen, dass es sich für ihn lohnen würde, einen Tag ins Büro zu kommen, da er den Tag ausfüllen kann - die Gefahr "unnützer" Fahrzeit für ein kurzes Meeting ist somit minimiert. Zusätzlich zu meinem Unterziel des Meetings "Socializing" können wir noch ein gemeinsames Mittagessen oder sogar Bierchen- Trinken mit Abendessen anbieten -wenn das Projektteam letzteres wünscht. Eine entsprechende Workshopatmosphäre mit Freizeitaktivitäten  sollte das Projektteam ausreichend motivieren (Sie haben es erraten: Der Hauptmotivator in der ganzen Geschichte ist natürlich "Bier").

Analoges gilt für Sprintwechsel- Meetings, PI-Plannings etc. - alles, was mindestens einen Tag dauert rechtfertigt Fahrzeiten und kann mit Feierabendaktivitäten als Motivator ergänzt werden.

Einstündige Regelmeetings, Statusmeetings etc. haben hingegen meiner Meinung nach keine Rechtfertigung, um Präsenz zu fordern - kurze Meetings wiegen nicht die eventuelle Fahrtzeit auf und ich habe dafür keine Möglichkeit, mein Team entsprechend zu motivieren. Derartige Meetings führe ich weitestgehend digital oder freiwillig- hybrid durch, auch wenn es natürlich schöner ist, die Menschen real zu sehen statt nur über die Cam. 

Sollten wir die digitalen Tools als eine Übergangslösung betrachten oder stellen sie die nächste Evolutionsstufe dar, die die vorherige völlig abschaffen sollte?

Schlechte Zeiten für die bunten Kärtchen an der Wand - wenn ich mein Team nicht generell vor- Ort sehen kann, dann kann ich das Scrum-Board oder das Kanban-Board am besten digital aufbauen - also alle Artefakte, welchen einen dauerhaften Einsatz haben sollen, würde ich digital anlegen, auch wenn ich das reale Kärtchen- schubsen immer sehr genossen habe. 

Wie sind Ihre Meinungen und Erfahrungen zur Veranstaltung von digitalen- oder Präsenzmeetings? Wann würden Sie auf in-Person- Anwesenheit drängen und unter welchen Bedingungen nicht? Womit motivieren Sie ihr Team zur persönlichen Anwesenheit? Wünschen Sie sich mehr persönliche Interaktionen in Ihren Projekten? Lassen Sie es mich in Ihren Kommentaren wissen.

Das wirklich beste Projektmanagementtool

Sind Sie auf der Suche nach dem einen besten Projektmanagementtool? Der Wunderwaffe, der eierlegenden Wollmilchsau, dem Messias unter den Hilfsmitteln? Suchen Sie Tag und Nacht im Internet nach Templates, um Ihre Projekte noch besser, noch strukturierter gestalten zu können? Lesen Sie hier weiter und ersparen Sie sich weitere Irrwege!

MS Project, Jira, Trello, Monday, Teams, Zoom und alle weiteren Tools haben eines gemeinsam: Sie sind KEINE Projektmanagementtools. Wer denkt, dass ein Tool Projektmanagement macht, der denkt vermutlich auch, dass ein Zitronenfalter Zitronen faltet. Keiner der genannten Anbieter bezahlt mir übrigens Geld dafür, dass ich über die Grenzen seiner Tools aufkläre, aber das nur am Rande.

Was tut ein Projektmanager eigentlich, um ein Projekt erfolgreich zu managen? 

Im Kern kommuniziert ein Projektmanager - am besten wie ich finde persönlich, aber in einer fragmentierten post- Corona- Zeit zwangsläufig mit Kollegen im Homeoffice oder aus dem Homeoffice heraus. Dabei helfen Tools wie MS Teams, Zoom oder weitere. Sind diese Tools dann Projektmanagementtools? Entscheiden Sie selber. 

Kann ein Tool kommunizieren? Ich würde diese Frage aktuell mit "Nein" beantworten - man munkelt, dass ein intelligent konfiguriertes Dashboard den richtigen Adressaten die richtigen Informationen zum richtigen Zeitpunkt zur Verfügung stellen könnte, allerdings habe ich ein solches Dashboard noch nicht persönlich kennenlernen dürfen. Mit weiteren Fortschritten der KI möchte ich nicht ausschließen, dass diese in Zukunft viele Funktionen eines Projektmanagers übernehmen könnte - allerdings findet Projektmanagement auch immer auf der persönlichen Ebene statt und dahingehend wage ich zu bezweifeln, dass eine noch so intelligente KI einen Projektmanager als Führungspersönlichkeit vollkommen ersetzen kann.

Keines der genannten Tools kann eigenständig kommunizieren - und ich halte es für sehr wichtig klarzustellen, dass alle Tools Ergebnisse erzeugen, visualisieren oder strukturieren, welche kommuniziert werden müssen. Die falsche Nutzung von Tools kann die Kommunikation sogar verschlechtern: 

Stellen Sie sich den Projektmanager vor, der alleine im stillen Kämmerlein seinen Projektablaufplan schreibt und diesen wie Gollum als seinen Schatz auf seinem persönlichen Laufwerk ablegt, nur um alleine den Überblick zu behalten. Oder stellen Sie sich Teammitglieder vor, die emsig Jira- Karten schreiben und sie anderen Kollegen zuweisen ohne mit diesen zu kommunizieren - in der wahnsinnigen Vorstellung, die entsprechende Aufgabenstellung sei ja völlig klar beschrieben und die Aufgabe würde aufgrund dessen natürlich wie gewünscht erledigt werden können. In beiden Beispielen fehlt der Konsens des Projektteams über die zu leistende Arbeit, sowie das commitment, diese durchführen zu wollen - und genauso wird der Grundstein dafür gelegt, dass das Projekt scheitert. Leider stammen diese Beispiele aus der Praxis.

Was tut ein Projektmanager noch? Er benutzt bestimmte Methoden, um die Erfolgschancen seines Projektes zu erhöhen. Anforderungsdefinition, Stakeholdermanagement, Risikomanagement, Zieldefinition, Projektablaufpläne, etc. 

Keines der mir bekannten Tools unterstützt dabei mit allen Methoden - allerdings helfen hier einige Tools tatsächlich gut in denjenigen Bereichen, auf welche sie spezialisiert sind, wenn man sie richtig nutzt. Mit MS Project und natürlich auch seinen Freeware- clonen lassen sich tolle Projektablaufpläne erstellen, wenn der Projektleiter sie zusammen mit dem Projektteam erstellt, nutzt und entsprechend kommuniziert. Stakeholder- und Risikoanalysen lassen sich ebenfalls am besten im Team gestützt durch Flipcharts, Pinnwände, Stattys, Powerpoint oder Excel durchführen. Definitionen und Monitoring von Arbeitspaketen oder Tasks funktionieren super über Jira, Trello oder andere Systeme (begleitet von einer adäquaten Kommunikation). Eine übersichtliche Dateiablage kann in MS Teams, Sharepoint oder Confluence hergestellt werden, wenn die entsprechende Ablagestruktur mit allen Beteiligten abgestimmt ist. 

Was ist nun also das versprochene beste Projektmanagementtool?

Das beste Projektmanagementtool ist die Erfahrung und der Verstand des Projektleiters und des Projektteams.  Damit können Sie aus einer Vielzahl an nützlichen Tools auswählen, ihre Grenzen bestimmen und dem Versuch widerstehen, sich falschen Propheten und haltlosen Werbeversprechungen auszuliefern. Mit Ihrem Verstand können sie Tools nach Ihren individuellen Bedürfnissen kombinieren und ihnen den Platz geben, den sie verdienen: Als Unterstützung und nicht als übermächtiges Ordnungsprinzip, dem sich alle Projektmitglieder auf Gedeih und Verderben ausliefern müssen! 

Die Zukunft des Projektmanagers vor dem Hintergrund einer möglichen Bedrohung unseres Berufsstandes durch eine KI besteht darin, dass der Projektmanager menschlich führen kann, Emotionen wahrnehmen und weitergeben kann, das Team motivieren kann und somit emotional geführt kommunizieren kann.

Welche(s) Projektmanagementtool(s) nutzen Sie zu welchem Zweck? Kennen Sie das EINE Tool, welches all ihre Anforderungen erfüllt? Lassen Sie es mich in Ihrem Kommentar wissen. 

Krieg der Sterne: Klassisches gegen agiles Projektmanagement

Es war einmal vor langer Zeit in einer weit, weit entfernten Galaxis... Die Unternehmen brauchten eine wirkungsvolle Form des Projektmanagements und stritten sich, ob klassische Wasserfallmethoden oder das agile Projektmanagement besser seien. Wird dieser Beitrag die Macht wieder ins Gleichgewicht bringen? Ich versuche es einfach mal.

Beginnen wir beim Imperium, dem klassischen Projektmanagement:

Der klassische Projektmanager plant zu Beginn eines Projektes, und zwar das gesamte Projekt - genauso wie Palpatine seit langem geplant hat, die Galaxis zu erobern und als Imperator zu führen. Der Imperator ist in unserer Allegorie der Projektauftraggeber, die höchste strategische Ebene im Projekt (in der Praxis natürlich meist durch einen Lenkungskreis unterstützt, aber ein Imperator entscheidet lieber alleine). Der Projektmanager ist derjenige, der für die Erreichung des strategischen Planes hauptverantwortlich ist, der operative Planer, derjenige, welcher dem Imperator dabei hilft, seinen Plan zu realisieren und selbigem gestattet, etwas im Hintergrund zu bleiben und nur bei Eskalationsbedarf Machtblitze zu schleudern. Zum Bau des Todessterns war der Projektmanager: Daa daa dah da da daah da da daah  Darth Vader. 

Aus Sicht der imperialen Unternehmensführung ist das bequem: Es existiert eine Person, welche greifbar ist, und deren Erfolg an von dieser Person selbst definierten Solldimensionen gemessen werden können. Diese Denkweise passt sehr gut ins klassische Hierarchiedenken des Imperiums, Befehle fließen von oben nach unten, Informationen von unten nach oben - eine klar strukturierte Welt mit im Zweifelsfall klar definierten Schuldigen.

Unter welchen Bedingungen funktioniert das? Der Plan steht und fällt natürlich mit der Fähigkeit des Planers zu planen. Das für- und wieder dieser Problematik diskutierte Anakin Skywalker mit Padmé Amidala in "Angriff der Klonkrieger" auf Naboo, bevor er zu Darth Vader wurde: Wenn es den einen weisen Führer gäbe, der über vollständige Informationen und somit über vollständige Planungssicherheit verfügen würde, und der dazu noch zwischenmenschlich verständnisvoll handelt und agiert, dann wäre das Imperium ein toller Ort und klassisch geführte Projekte würden immer funktionieren - das ist aber nun mal beides nicht der Fall.

Ein Trost für den Imperator: Im klassischen Projektmanagement ist wenigstens der Projektmanager für das Gelingen des Projektes verantwortlich, bei Verzögerungen oder Scheitern ist somit immerhin klar, wer gemachtblitzt oder machtgewürgt werden kann. Für weitere Bedingungen, unter denen das klassische Projektmanagement funktioniert, steht Ihnen die vielzitierte Stacey- Matrix zur Verfügung, ich belasse es an dieser Stelle erstmal dabei.

Kommen wir zum agilen Projektmanagement, den Rebellen im Imperium der Projektmanager:

Die Rebellen agieren zunächst freiwillig, aus eigener intrinsischer Motivation heraus innerhalb kleiner Zellen. Das sind zufälligerweise die typischen Voraussetzungen, unter denen das agile Projektmanagement funktioniert und das ist der wesentliche Unterschied zum Hierarchiedenken des Imperiums: Interdisziplinäre Teams können selbst und weitestgehend demokratisch entscheiden. Der Scrum - Master ist der Servant - Leader, auf Seiten der Rebellen darf also nicht gemachtblitzt werden. Der Product - Owner gibt Aufgaben vor, das Team entscheidet selbständig, bis wann die Pläne des Todessterns gestohlen werden können (bzw. müssen) und welche Vorarbeiten dafür notwendig sind. 

Ist das besser? Der Vergleich des Imperiums vs. Rebellen legt dies an dieser Stelle nahe, aber ich gebe zu, dass der Vergleich hier nicht so eindeutig ist, wie es scheint:

Die Fähigkeit des Teams, gute Entscheidungen zu treffen, basiert auf der Annahme bzw. auf dem Menschenbild, dass das Team gute und fundierte Entscheidungen treffen kann. Ein Team voller Idioten wird demnach trotz der demokratischen Entscheidungsgrundlage idiotische Entscheidungen treffen oder anders ausgedrückt: Ein Team voller Imperatoren wird das Imperium nach erfolgreicher Rebellion wieder in ein Imperium zurückführen und gegeneinander um die Alleinherrschaft kämpfen. Der Imperator ist tot, lang lebe der Imperator! Nun ist die Wahrscheinlichkeit, dass ein ganzes Team voller Imperatoren existiert wesentlich geringer als jene, dass ein einzelner Imperator ein Idiot ist, aber der Demokratie reicht auch schon eine Idioten- Mehrheit von 51%, um sie ins Verderben zu stürzen.

Ebenfalls ist die beschriebene Einheit eines Teams recht leicht in kleinen Teams erreichbar - schwierig wird es, wenn die Sache größer wird und mehrere Teams zusammen arbeiten müssen. Das zeigt die Geschichte der Rebellen eindrucksvoll am Beispiel der Fliegerasse Cassian Andor und Poe Dameron, die beide erhebliche Probleme damit haben, Befehlen zu folgen und dadurch Probleme bekommen.

Befehle? Welche Befehle? Steht da nicht, dass agile Teams sich selbst organisieren? Ja, das steht da und das ist auch so gedacht. Am Anfang der Rebellion war es ausreichend, wenn einzelne Zellen lose und selbstbestimmt zusammen arbeiteten, je größer die Sache jedoch wurde, umso mehr hat sich auch bei den Rebellen eine Befehlsstruktur etabliert, jener des verhassten Imperiums nicht unähnlich, nur halt ohne Machtblitze, dafür mit humaneren Bestrafungsmechanismen, denn wo Befehle existieren, existiert zwangsläufig Ungehorsam.

Ein guter Einblick in diesen Widerspruch lässt sich anhand des Werdegangs von Prinzessin Leia Organa darstellen: Sie hat als engagierte, idealistische Rebellin in mit ihrem kleinen Scrum-Team begonnen, wurde zur Rebellenführerin und hat jene hierarchischen Strukturen maßgeblich mit etabliert, welche ihr den Zorn und den Ungehorsam von Poe Dameron entgegengebracht haben. Diesen Werdegang teilt Leia Organa mit einigen der Rebellenführern, welche in einer Skihütte auf dem Planeten Utah das agile Manifest entwickelt und unterzeichnet haben: Damals waren sie Softwareentwickler, heute sind viele von ihnen CIOs oder CEOs von ihren eigenen oder anderen Unternehmen. Manche dieser Rebellenführer haben sich übrigens mittlerweile von ihrem Manifest distanziert, weil sie in der Praxis damit bemerkt haben, dass das agile Arbeiten zwar einige der Probleme des klassischen Projektmanagements wie gewünscht löst, dafür jedoch an anderer Stelle Probleme verursacht. Letztendlich existiert keine Medizin ohne Nebenwirkungen.

Apropos Probleme: Eine weitere Beschränkung der agilen Arbeitsweise wird aus dem obigen Beispiel ersichtlich: Die Zusammenarbeit von vielen Teams oder vielen Menschen. Das ist im SCRUM nicht vorgesehen. Die Referenzsituation für SCRUM ist: Ein Team entwickelt ein Produkt - SCRUM ist daher auch streng genommen eher ein Produktmanagement - Framework als ein Projektmanagement - Framework. Dieses Problem versuchen unterschiedliche Ansätze auf unterschiedliche Arten zu heilen: SAFe, LeSS, Spotify - mit unterschiedlichem und individuellem Erfolg. 

Kommen wir zur Synthese und zum Fazit, bevor wir in den Details der Methoden und der Star Wars Galaxis versinken:

agile Methoden basieren auf einem modernen, positiven und erstrebenswerten Menschenbild, nämlich dem der Mündigkeit und der Fähigkeit sowie dem Wunsch zur selbstbestimmten Arbeitsweise. Sofern die Menschen in Ihrem Team dieses Bild erfüllen, ist die grundlegende Prämisse zur Einführung agiler Methoden gegeben. Wenn Ihr Unternehmen klein und jung ist, beispielsweise in einer Startup- Situation, wird SCRUM höchstwahrscheinlich funktionieren. In größeren Unternehmen, Imperien, um bei dem Beispiel zu bleiben, besteht zusehends die Gefahr, dass "Agil" zu "Chaotisch" wird. Auch die Rebellen benötigen mit wachsender Macht und wachsender Personenanzahl wachsende Strukturen, um sich verwalten zu können (Corporate Governance, Projekt- und Portfolio- Governance sowie  Prozessmanagement sind hier wesentliche Methoden). In einer solchen Situation macht es mehr Sinn, sich zum klassischen Projektmanagement hin zu entwickeln oder die angesprochenen Skalierungs - Frameworks für agile Methoden auszuprobieren. Ebenfalls wichtig ist, ob ein Spielraum existiert, lustig vor sich hin zu iterieren, bis das Produkt dann mal fertig ist, oder ob ein dringender Endzeitpunkt existiert, beispielsweise aufgrund von rechtlichen Zwängen. In ersterem Fall kann agiles Projektmanagement angewendet bzw. ausprobiert werden, in letzterem Fall wäre es ratsam, klassisches Projektmanagement anzuwenden.

Die beste Erfahrung habe ich mit hybriden Projektmanagement gesammelt: Das beste aus beiden Welten vereinen, um Projekte zum Erfolg zu führen. Die Fragestellungen dazu sind: Wo steht die Firma gerade? Wie selbstbestimmt können/ möchten die Kollegen arbeiten? Wieviel Reporting wird gewünscht? Wie wichtig ist ein fixer Endtermin und eine fixe Kostenkalkulation für das Projekt? Ist das Team (be)fähig(t), sinnvolle eigene Entscheidungen treffen zu können? 

Auch wenn nach Beantwortung der obigen Fragen das Barometer mehr in Richtung agil ausschlägt, würde ich Methoden des klassischen Projektmanagements zu Beginn des Projektes anwenden: Stakeholderanalyse, um eine Kommunikationsmatrix zu erstellen und um keine wichtigen Stakeholder im Projekt zu vergessen, Risikoanalyse, um Gegenmaßnahmen zu entwickeln und eine Zieldefinition, um Scope- Creep zu vermeiden. Die Methoden können auch innerhalb eines Projektes gemixt werden - ich habe gute Erfahrungen damit gesammelt, Testphasen zu agilisieren mit Daily - Standups und schneller Problemlösung, um sich nicht zu sehr in Details zu verirren und um die Kommunikation bereichsübergreifend zu stärken. Bei der Führung mehrere Dienstleister, bei welchen ein Teil klassisch arbeitet und ein Teil agil, kann ein klassischer Projektablaufplan erstellt werden. Der agile Teil kann dann innerhalb der Phasen sprinten - auf diese Weise können beide Sichtweisen parallel innerhalb eines Projektes vereint werden.

Wie sind Ihre Erfahrungen mit klassischen und agilen Projektmanagement? Fallen Ihnen weitere Anwendungsvoraussetzungen  für die beiden Methoden ein? Welche Methoden wenden Sie am liebsten an, wie kombinieren Sie diese? Welchen Star Wars Charakter mögen Sie am liebsten und arbeitet er eher agil oder klassisch?

Lassen Sie es mich in Ihrem Kommentar wissen.

Testmanagement in klassischen und agilen Projekten

Stellen Sie sich vor, Sie kaufen ein neues Auto - würden Sie den Vertrag unterzeichnen, bevor Sie eine Probefahrt gemacht haben? Und nun stellen Sie sich vor, ein guter Freund von Ihnen ist KFZ Mechaniker oder Mechatroniker - Sie würden höchstwahrscheinlich versuchen, ihn mal unter die Haube gucken zu lassen und seine Meinung wissen wollen?

Die Probefahrt oder der Check durch einen vertrauenswürdigen Experten beim Autokauf stellt letztendlich einen Test dar - Ihre Anstrengungen, zu aussagekräftigen Testergebnissen zu kommen, kann man als Testmanagement bezeichnen. Nun macht die Probefahrt im Neuwagen auf der leeren A3 ab 200 Km/h wesentlich mehr Spaß als das Testmanagement in Projekten, aber letztendlich verfolgt beides denselben Zweck - und sollten wir scheitern, fahren wir in beiden Fällen etwas sehr wertvolles gegen die Wand oder die Leitplanke.

Wenn zu Projektbeginn bei klassisch geleiteten IT- Projekten sauber und realistisch  geplant wird, die Experten befragt werden, wie lange einzelne Tasks benötigen, der Zeitbedarf gegen den Urlaubsplan gespiegelt wird und ein Puffer von nehmen wir mal 10% eingeplant wird, dann sollte es nur in Ausnahmefällen möglich sein, die erforderlichen Arbeiten völlig außerhalb des geplanten Zeitraums fertigstellen zu können.

Soo, und dann kommen wir in die Testphase - und hier habe ich leider in einem Großteil der Projekte bemerken müssen, dass die Testphase, diejenige Phase welche die letzte Phase vor dem Go Live darstellt, in der man eigentlich nur noch mal kurz alles überprüfen möchte bevor man endlich die langherbeigesehnte Projektabschlussparty feiern kann, für eklatante Verzögerungen sorgt. Und jetzt werden Sie sich denken: Dann plan die Testphase doch einfach länger. Habe ich getan. Ich habe schon für 3 Monate Projektarbeitszeit anschließend 2 Monate Testphase geplant, einfach als Experiment - und raten Sie mal: Hat auch nicht gereicht. Und ich finde, dass die Testphase weniger Zeit in Anspruch nehmen soll als die vorangehenden Arbeitsphasen - je nach Komplexität des Endproduktes, Erfahrung des Teams etc. mehr oder weniger, aber es ist schwer zu rechtfertigen, wenn eine Testphase beispielsweise die doppelte Zeit der Entwicklungsphase einnimmt. 

Verdeutlichen wir uns das am Beispiel des Autokaufs: Wenn Sie ein neues Auto kaufen möchten, dann checken Sie im Internet erstmal mögliche Alternativen, prüfen diese auf Eignung, fragen Kollegen und Freunde. Dann gehen Sie in ein paar Autohäuser und reden mit den Verkäufern. Sie schlafen ein paar Nächte darüber und entscheiden sich dann für Ihre 1 bis 2 Topmodelle für eine Probefahrt, üblicherweise von maximal 2 Std pro Modell. Der Testzeitraum stellt auch hier nur einen geringen Bruchteil des Entscheidungs- und Recherchezeitraumes dar, bevor Sie eine Entscheidung treffen. 

Warum ist der Testzeitraum in Projekten so schwierig?

Ich vermute, dass die menschliche Komponente eine große Rolle spielt: Man will fertig werden, und gedanklich ist man am Ende der Entwicklung fertig. Wurde ja alles geplant und alles wie geplant erstellt. Tests bedeuten Kontrolle - und wer lässt sich schon gerne kontrollieren? Das passt schon, wir machen sowas ja schon lange und sind Profis... Das reicht, wenn der Kollege Klaus mal kurz drüber guckt, der hat ja auch halbwegs Ahnung davon... 

Tja, in dem meisten Fällen reicht das dann leider nicht, und das ist nicht zwingend die Schwäche derjenigen, welche das Produkt erstellt haben, sondern die Schwäche der Planung und der Anforderungsdefinition. Wenn Anforderungen anfangs widersprüchlich oder nicht realisierbar waren, ohne dass es jemandem aufgefallen ist oder wenn Komponenten nicht zusammen passen, dann fällt dieses Problem im schlimmsten Fall erst in der finalen Testphase auf - und das gilt dann auch beim agilen Projektmanagement...

Apropos, im agilen Projektmanagement entstehen solche Probleme natürlich nicht, zumindest nicht nach Lehrbuch. Das agile Projektmanagement verfolgt den Gedanken, in kürzeren Zeiträumen zu entwickeln, legen wir einmal 2 bis 4 Wochen zugrunde, innerhalb dieses Zeitraumes zu testen und am Ende dann ein lauffähiges Produktinkrement erzeugt zu haben - nicht das Endprodukt wohlgemerkt, sondern nur eine verbesserte Version. Wann das Endprodukt erzeugt ist, ist dem agilen Projektmanagement herzlich egal, es wird so lange iteriert, bis das Produkt dann halt fertig ist. Der agile Autokauf sähe so aus, dass sie nicht so lange vorab planen und recherchieren, sondern sich möglichst schnell Probefahrten organisieren um sich durch trial and error zum Traumauto hin iterieren. Fangen wir mal mit einem Smart an, der ist schön preiswert...Hmm, fährt nicht spritzig genug? Dann testen wir mal einen Ferrari... Schon cool, aber ups, zu teuer... Dann fahren wir mal den Golf... Bingo, der fährt ganz gut und ist erschwinglich. Ob dieses Vorgehen letztendlich schneller und besser funktioniert als im klassischen Projektmanagement sei dahingestellt.

Der sinnvolle Grundgedanke des agilen Projektmanagements ist, möglichst schnell zu testen, bevor eine lange Entwicklung völlig für die Tonne war. Diesen Grundgedanken sollten eigentlich alle Projektmanager verfolgen, unabhängig davon, ob sie sich nun klassisch oder agil nennen. Es stellt sich die Frage, inwiefern dies möglich ist - sowohl im klassischen als auch im agilen Projektmanagement. Unit- Tests oder Komponententests, also die Tests einzelner Systemkomponenten, können und sollten  in beiden Arten des Projektmanagements möglichst schnell durchgeführt werden.  Integrationstests, die das Zusammenspiel des geänderten Systems mit anderen Systemen testen und der Systemtest, also der Test des gesamten Systems können ggf. erst am Ende der Entwicklung sinnvoll getestet werden. Je nach Situation entsteht hier beim agilen Projektmanagement sogar noch ein Mehraufwand gegenüber der klassischen Variante, wenn wirklich alle 14 Tage eine Änderung ausgebracht werden soll, welche im Verbund mit mehreren weiteren Systemen getestet werden muss. 

So, Traumauto gefunden, ob nun klassisch mit viel Vorbereitungszeit oder agil iterativ- Wie testen wir also?

Die Straßen, auf denen wir unser Auto Probefahren sind wichtig. Ein bisschen Autobahn, ein bisschen Landstraße und vielleicht sogar ein bisschen Feldweg - ganz nach gewünschtem Einsatzgebiet (Spoilerwarnung: Fahren Sie den Ferrari am besten nicht auf einem Feldweg Probe). Den Testaufbau und die Ergebnisse halten wir am besten in einer Testmatrix fest, dann ist das halbwegs revisionssicher und Ihr Ferrarihändler weiß hinterher auch wenigstens, woher die ganzen Kratzer auf dem schönen roten Lack kommen. 

Die Testmatrix beginnt mit der Definition der Testfälle. Ich fasse das als "Testvorbereitung" zusammen. Die Testfälle werden idealerweise ganz am Anfang des Projektes oder der Iteration definiert und ggf. fortlaufend ergänzt. Das ist extrem wichtig, weil: Testfälle hängen extrem eng mit Anforderungen zusammen. Letztendlich soll ja getestet werden, ob die zu Beginn festgelegten Anforderungen erfüllt werden (Traceability). Die Definition der Testfälle könnte für unser Beispiel so aussehen: 

Das Testschema offenbart, dass zu beginn die Anforderungen "Fahrverhalten", "Sound" und "Preis" festgelegt wurden. Diese Anforderungen wurden in der Testvorbereitung auf verschiedene Testsituationen (Landstraße, Autobahn, Feldweg) umgelegt. In unserem Beispiel sind somit bereits aus 3 Anforderungen 7 Testfälle geworden. Weitere Anforderungen & Testsituationen würden zu einer weiteren Vervielfältigung der Testfälle führen, beispielsweise wenn wir verschiedene Motorensetups hätten und oder verschiedene Reifengrößen.

Wenn wir die Tests nach bestem Wissen und Gewissen sauber definiert haben, können wir zur Testumsetzung, also zur Testdurchführung kommen. Diese muss natürlich dokumentiert werden. In unserem Beispiel könnte das so aussehen:

Der Tester soll zu jeder Testfallnummer das Testdatum und seinen Namen festhalten, sowie das vom definierten Sollverhalten abweichende Fehlerverhalten so kurz wie möglich, so lang wie nötig beschreiben. In der darauffolgenden Spalte "Anmerkungen Autohändler" erhält das Entwicklerteam oder der Dienstleister, in unserem Fall der Autohändler, die Gelegenheit zur konstruktiven Stellungnahme. In der Spalte "Status" kann der Lösungsstatus vom Entwicklerteam festgehalten werden, z.B. "Offen", "in Arbeit" oder "Erledigt". Im Fall von "Erledigt" kann der Tester den Fehlerfall noch einmal testen. In der Spalte "Prio" kann der Tester bei Bedarf eine Priorität zur Fehlerkorrektur für den Dienstleister bzw. das Entwicklungsteam hinterlegen - evtl. sind einige der gefundenen Fehler nicht unbedingt Go- Live- verhindernd und müssen somit lediglich mit niedrigerer Priorität als andere Fehler behoben werden.

Welche Erfahrungen haben Sie mit Projektverzögerungen ab der Testphase gemacht? Testen Sie systematisch oder nach Augenmaß? Haben Sie das Gefühl, dass Tests in agilen Projekten besser laufen als in klassischen Projekten? Schlägt ihr teurer Sportwagen auf Feldwegen auch immer auf dem Boden auf? Ich freue mich auf Ihre Kommentare.

Das Problem der Ampelfarben in Projekten

 

„Bei Rot sollst du stehen, bei Grün kannst du gehen“ sagt ein alter Kinderreim. Wie übertragen wir das sinnvoll auf unsere Projektstatusberichte, Risikoanalysen usw, kurz: auf alle Projektdokumente, in denen die allseits bekannte und gefürchtete Managementampel gewünscht wird? Und was soll uns die Farbe Gelb eigentlich sagen?

 In meinen vergangenen Blogs habe ich oftmals auf die Verwendung von Ampelfarben verwiesen, an dieser Stelle möchte ich mich an einer Definition versuchen, denn: Nichts scheint so eindeutig wie eine Farbe, gerade weil wir sie alle aus unserem täglichen Umgang im Verkehr zu kennen glauben – und gleichzeitig ist nichts so schädlich wie ein falsch verstandener Konsens wenn man merkt, dass doch jeder etwas anderes mit der betreffenden Farbe assoziiert.

 Beginnen wir mit einer einfachen Farbe: Grün.
„Wir sind grün miteinander“ bedeutet, dass wir uns gut verstehen, dass keine Unklarheiten die zwischenmenschliche Sphäre verunreinigen. „Alles im grünen Bereich“ sagen wir umgangssprachlich. Damit meinen wir: Alles ist gut. ALLES. Da muss niemand mehr etwas tun, niemand muss helfen. 

Für einen Projektstatusbericht im klassischen Projektmanagement sollten wir folglich eine grüne Ampel setzen, wenn das Projekt voll auf Kurs ist hinsichtlich ALLER Komponenten des magischen Dreiecks: Kosten, Zeit und Leistung.
 
Bei der Risikoanalyse signalisiert die grüne Farbe, dass das betreffende Risiko hinsichtlich der Eintrittswahrscheinlichkeit und Tragweite derart gering ist, dass wir keine Management - Attention darauf aufwenden müssen. Die Verwendung einer grünen, als positiv geltenden Signalfarbe ist dabei eigentlich eine Ironie des Schicksals, da es sich ja immerhin um ein Risiko handelt, also einen  negativen Einfluss aus dem sachlichen Projektumfeld - aber da wir uns ja leider bereits an die Ampelfarben gewöhnt haben, wäre die Einführung einer neuen Farbe, sagen wir mal Lila in diesem Kontext auch eher verwirrend als zielführend - somit belassen wir es wohl auch in Zukunft bei Grün. Oftmals bedeuten Risiken im grünen Bereich der Risikoanalyse, dass wir uns keine Gegenmaßnahmen für das betreffende Risiko überlegen müssen und die betreffenden Risiken gemäß der Normstrategie akzeptieren.

Etwas schwieriger ist die Farbe Rot. Rot ist eine Signalfarbe. Rot vermittelt Aggressivität. "Ich sehe rot" bedeutet: Ich bin kurz davor, auszurasten - zu eskalieren um es mit einem anderen Wort auszudrücken. Eine Eskalation im betrieblichen Zusammenhang stellt übrigens die Weitergabe eines Problems an die nächst höhere Stelle dar und ist somit erstmal frei von den negativen emotionalen Assoziationen, welche wir im privaten Alltag damit verbinden wenn wir sagen: "Da bin ich richtig eskaliert". 

Für einen Projektstatusbericht sollte die rote Farbe genau dieses ausdrücken: Der Projektleiter gibt damit zu erkennen, dass (mindestens) ein Problem existiert, welches er nicht mit seiner eigenen Kompetenz und innerhalb seines Entscheidungsspielraumes bewältigen kann. Er benötigt Hilfe, er eskaliert an die nächst höhere Instanz: Den Lenkungskreis bzw. Projektauftraggeber. Ich habe dabei häufig psychologische Hemmschwellen bemerkt, einen Statusbericht auf Rot zu setzen: Vielfach existiert die Angst, zu signalisieren, dass man seiner Aufgabe als Projektleiter irgendwie doch nicht gewachsen ist und die Scham um Hilfe zu bitten. So lässt sich vielfach beobachten, dass Projekte, welche nun schon doppelt so lange laufen wie ursprünglich geplant, im Statusbericht die Farbe Grün ausweisen - in diesem Zusammenhang dann wohl eher als die Farbe der Hoffnung zu interpretieren. Ein weiteres Phänomen der Farben konnte ich vielfach als Multiprojektmanager beobachten: Statusberichte wechseln die Farbe ruckartig von Grün auf Rot. Damit einher geht die Berichterstattung der Projektmanager: Zu einem Berichtszeitpunkt sei alles super, das Projekt laufe wie geplant - im nächsten Monat ist das Projekt bereits voll vor die Wand gefahren und knallrot. Verstehen Sie mich nicht falsch, das kann in Einzelfällen ja durchaus passieren; allerdings kann ich Ihnen versichern, dass es erwünscht ist, vor dem völligen Absturz eines Projektes die Farbe Gelb mal kurz gesehen zu haben. Allerdings ist diese Farbe meiner Ansicht nach auch die Schwierigste aller Farben im Statusbericht. Das scheinen unsere Städteplaner auch so zu sehen, da in einigen Verkehrssituationen mittlerweile Ampeln zum Einsatz kommen, welche nur noch aus den Farben grün und rot bestehen.

In der Risikoanalyse steht ein Risiko im roten Bereich für eine hohe Tragweite verbunden mit einer hohen Eintrittswahrscheinlichkeit. Rot bedeutet hier: Es müssen Gegenmaßnahmen entwickelt und  regelmäßig aktualisiert werden und das betreffende Risiko muss aufmerksam beobachtet werden. Die Risikonormstrategien legen dabei "Vermeidung" als adäquate Risikostrategie dar - logisch, aber im Einzelfall oft wenig hilfreich.

Widmen wir uns nun der schwierigsten aller drei Farben, nachdem wir die beiden vergleichsweise einfachen Extreme definiert haben: Gelb. Dem Mittelmaß, der Mischung aus Rot und Grün, nicht Fleisch, nicht Fisch - gelb ist stuck in the middle frei nach Porter, die Farbe derer, die sich nicht entscheiden können. Was machen wir, wenn eine Verkehrsampel Gelb zeigt? Noch schnell über die Kreuzung rennen? Schonmal vorsorglich anhalten und auf das nächste Grün warten? Ich weiß es ehrlich gesagt nicht und wenn ich mir das Verkehrsgeschehen so angucke dann bekomme ich den Eindruck, dass es viele andere Menschen ebenfalls nicht wissen. Jeder macht es situativ anders. Ist die Farbe Gelb damit eventuell sogar schuld an Unfällen, weil wir alle nicht wissen, was sie bedeuten soll? Mir fällt spontan nicht mal ein kluges umgangssprachliches Gleichnis für die Farbe Gelb ein. 

Im Rahmen der Projektstatusberichte kann ich Ihnen folgende Lösung zur Verwendung der Farbe Gelb präsentieren: Gelb kann verwendet werden um dem Lenkungskreis oder Projektauftraggeber zu signalisieren, dass das Projekt droht, hinsichtlich mindestens einer der 3 Projektdimensionen Kosten, Leistung oder Zeit aus dem Ruder zu laufen, dass der Projektleiter jedoch davon ausgeht, diese Probleme mit seiner eigenen Kompetenz und innerhalb seines eigenen Handlungsspielraumes handhaben und korrigieren zu können. Damit ist die Farbe Gelb auch inhaltlich sinnvoll zwischen Grün und Rot positioniert, sie gibt ein leichtes Warnsignal ab und behält sich sowohl den Rückweg zur Farbe Grün offen als auch den Gang nach Canossa zur Farbe Rot. 

Noch schwieriger gestaltet sich die Farbe gelb bei der Risikoanalyse. Ich gehe zur Vereinfachung  davon aus, dass die Risikoanalyse lediglich einen einzigen gelben Bereich hat. In der Praxis wird hier oft ein Farbspektrum von hellgelb bis dunkelorange dargestellt - das sieht zwar cool aus, hilft aber hinsichtlich der Risikohandhabung und Entwicklung der Gegenmaßnahmen wenig. Die Risikonormstrategien für den gelben Bereich lauten je nach Quelle "vermindern", "übertragen" oder "reduzieren", "überwälzen" etc. Damit gemeint ist unterm Strich die Hoffnung der Überführung der jeweiligen Risiken in den grünen Bereich - denn Grün ist die Hoffnung, das wissen wir ja bereits.

 Abgesehen von pauschalen Risikonormstrategien und schlau klingenden  Buzzwords müssen wir für Risiken im gelben Bereich genauso wie für diejenigen Risiken im roten Bereich ebenfalls konkrete Gegenmaßnahmen entwickeln, um diese in der Schublade vorrätig zu haben oder um sie direkt einzuleiten, falls wir die entsprechenden Risiken direkt in den grünen Bereich überführen wollen.  Gerade letzteres ist allerdings strittig: Die Einleitung von Gegenmaßnahmen kostet Zeit oder Geld oder beides - wollen wir wirklich knappe Ressourcen darauf verwenden, um gelbe Risiken grün werden zu lassen? Sollten wir das Geld nicht besser dafür aufwenden, um rote Risiken gelb werden zu lassen? Oder erstmal warten, bis die gelben Risiken rot werden, um dann Gegenmaßnahmen einzuleiten?  Eine schwierige Frage, die man nicht pauschal beantworten kann - und ein Problem welches wie dargestellt auch mit den Risiken im roten Bereich existiert. Wir müssen die Risiken in diesem Bereich in jedem Fall beobachten - allerdings nicht so kritisch wie diejenigen Risiken im roten Bereich. An dieser Stelle besteht leider die Gefahr, ja, das Risiko, dass die Risiken im gelben Bereich dann doch nicht weiter beobachtet werden, wir haben ja schließlich genügend Risiken im roten Bereich und mit denen genug zu tun.

Brauchen wir dann überhaupt den gelben Bereich bei der Risikoanalyse? Meiner Meinung nach nicht dringend - wenn wir uns dafür entscheiden, eine gewisse Schwelle an Erwartungswert und Tragweite der Risikoauswirkungen zu definieren, welchen wir akzeptieren und nicht weiter verfolgen (der grüne Bereich), dann müssen wir folglich farbunabhängig für die restlichen Risiken Gegenmaßnahmen entwickeln (der gelbe und rote Bereich). Den Einsatz von Gegenmaßnahmen müssen wir sowieso im Einzelfall entscheiden, egal ob sie auf Risiken aus dem vormals roten Bereich wirken oder auf den vormals gelben Bereich oder im Optimalfall auf mehrere Risiken aus beiden Bereichen. Nichtsdestotrotz lässt sich eine Risikoanalyse mit 3 Farben natürlich schöner darstellen und besser gegenüber dem Lenkungskreis verkaufen als eine völlig farblose Risikoanalyse oder eine ausschließlich rot eingefärbte solche. 

Welche Erfahrung haben Sie mit der Managementampel? Welche Abgrenzungskriterien der Farben haben sich in Ihrer Praxis als sinnvoll erwiesen? Haben Sie in einem Statusbericht jemals die Farbe Gelb gesehen oder verwendet? Wie verhalten Sie sich, wenn eine Verkehrsampel die Farbe gelb zeigt? Lassen Sie es mich in Ihrem Kommentar wissen. 

niemand mag Projekte

Wir Projektmanager lieben Projekte - schließlich sind wir den ganzen Tag davon umgeben und haben uns das Projektmanagement irgendwann (hoffentlich) mal freiwillig ausgesucht. Ist diese Einstellung überhaupt hilfreich und sozial akzeptabel? Um diese Frage zu beantworten beginne ich mal damit, womit jeder Projektmanager zu Beginn eine Projektes beginnt: Schauen wir uns die Motivation der internen Stakeholder näher an.

Der Projektauftraggeber möchte keine Projekte haben - er verlangt Ergebnisse. Kein Auftraggeber beginnt seinen Tag mit dem Gedanken: "Heute denke ich mir mal ein richtig schönes Projekt aus, es soll viele Kapazitäten binden und so richtig schön teuer sein". Stattdessen hat so ein späterer Projektauftraggeber erstmal ein Problem, welches er eigentlich am liebsten bis gestern gelöst hätte - und das am besten ohne Kosten. Wie das aber nun mal so mit komplexen strategischen Problemen ist, können diese nicht schnell und aufgrund der Linearität der Zeit nicht bis gestern gelöst werden - im besten Fall versteht das der Projektauftraggeber. Seine nächste logische Frage ist demnach: "Bis wann und zu welchen Kosten kann mein Problem mit welchem Vorgehen gelöst werden?" Diese Fragestellung spiegelt ziemlich genau das magische Dreieck des klassischen Projektmanagements: Kosten- Leistung- Zeit wider. Ein guter Auftragnehmer beantwortet diese Fragestellung zeitnah, die Methoden des Projektmanagements wie Kostenplan, Projektablaufplan, Anforderungsdefinition,... helfen, diese Fragen zu beantworten. Schwupps, da haben wir aus einem Problem ein Projekt gemacht, was eigentlich nicht beabsichtigt war, aber nun zumindest als ein notwendiges Übel angesehen werden kann. 

Das Zauberwort gegenüber dem Auftraggeber lautet hier folgerichtig: Ergebnis- bzw. Lösungsorientierung. Nur in dem Bewusstsein, dass der Auftraggeber das Projekt eigentlich nicht haben will, sondern schnellstmöglich, so preiswert wie möglich und kontrollierbar zu seinem Ziel gelangen will, können wir vermeiden, uns in Details zu verlieren und zu große Abweichungen in einer der Dimensionen des magischen Dreiecks zu tolerieren. Das muss sich auch in der Kommunikation zum Auftraggeber durchsetzen.

Das Projektteam möchte erst recht keine Projekte, zumindest nicht in der Linienorganisation und in der Stabsorganisation. Unabhängig davon, wer aus Ihrem Unternehmen im Projektteam mitarbeitet, bedeuten Projekte für jeden Kollegen erstmal zusätzliche Arbeit. Und da in keinem Unternehmen, welches ich bisher kennenlernen durfte, Überkapazitäten herrschen, führt jedes neue Projekt verständlicherweise erst einmal zu Unmut bei den Kollegen: "Boh, nicht noch ein Projekt", "Wir müssen uns erstmal um unsere Linienaufgaben kümmern", "Was jetzt soll ich noch mit Abteilung X im Projekt auf Augenhöhe zusammenarbeiten, obwohl das alles Vollhonks sind!?", "Das wird doch eh nichts, was die da oben sich ausgedacht haben, ich sitze das einfach aus" sind häufige Reaktionen auf enthusiastisch vorgebrachte (und oftmals gute) Projektideen.

 Um dem Schwall der ersten Ablehnung angemessen zu begegnen, muss der Projektleiter motivieren, kommunizieren und vor allem den Nutzen für die einzelnen Teams/ Abteilungen der Projektmitglieder, am besten sogar auf deren persönlicher Ebene herausarbeiten. Niemand ist begründet im Projektteam, wenn seine Mitarbeit nicht notwendig wäre und jedes Projektteammitglied sollte im Rahmen des Projektes eine Verbesserung seiner eigenen täglichen Arbeit erfahren dürfen oder eine Verbesserung für das gesamte Unternehmen herbeiführen können, andernfalls macht das Projekt evtl. wirklich wenig Sinn. Diese positive Kommunikation ist leider über die gesamte Dauer des Projektes notwendig und endet frühestens mit Projektabschluss - also eine der Hauptaufgaben für den Projektleiter.

Mittendrin in der Hierarchie zwischen Auftraggeber und Projektteam befindet sich der Projektleiter. Dieser versucht mit Elan und viel Optimismus, die Vorgaben eines Projektauftraggebers an das Projektteam heranzutragen und die Umsetzung seiner Pläne, die eigentlich niemand haben will, voranzutreiben - eine höchst masochistische Arbeit, wenn man mal so drüber nachdenkt. Der Projektleiter ist in dieser Konstellation der Einzige, der das Projekt des Projektes wegen cool findet wohlgemerkt. Gäbe es das Projekt nicht, so wäre der Projektleiter im schlimmsten Fall entweder arbeitslos oder hätte eine andere Aufgabe innerhalb der Organisation, welche er wahrscheinlich nicht so toll findet, weil er lieber Projektleiter wäre. Der Projektleiter ist also jemand, dessen Glas ständig halb voll ist, obwohl alle anderen sich intensiv darüber beschweren, dass das Glas halb leer sei und dass ihnen der Inhalt eh nicht schmeckt. 

Kann der Projektleiter seine Meinung und Ansichten zum Füllstand des Glases in dieser Form überhaupt öffentlich machen? Nun soll man ja nicht unbedingt zwingend mit dem Strom schwimmen, aber ein hilfloser Optimismus in einer Welt voller Pessimisten sorgt nun nicht gerade dafür, dass man sich Freunde macht, und auch Pessimisten können ja ganz nette Menschen sein. Erschwerend hinzu kommt: Wenn man etwas mag, dann möchte man ja nicht, dass es endet - denken wir an unseren letzten Strandurlaub mit reichlich Sonne und guten Cocktails an der Strandbar: Tolle Situation, sollte eigentlich nicht enden nach Möglichkeit. Alle anderen wollen aber möglichst schnell von der Strandbar weg weil es zu heiß ist und das Glas ja eh schon halbleer ist wie bereits beschrieben. 

Vielleicht sollten wir als Projektleiter unsere Projekte also nicht lieben, sondern sie besser hassen? Welche Vorteile hätte das? 

Gegenüber dem Projektauftraggeber könnten wir frischer und zielorientierter auftreten: "Ich habe Ihr Problem verstanden, zur Realisierung muss ich leider ein Projekt vorschlagen". Der Projektleiter, der sein ehrliches Problemverständnis teilt und sich für den ewig gleichen Lösungsweg entschuldigt ist zumindest origineller als derjenige Projektleiter, bei dem man schon bevor er zur Tür hereinkommt weiß, dass er enthusiastisch ein Projekt vorschlagen wird, weil er gerade wieder mal auf einer Fortbildung zum Thema Projektmanagement war.

Gegenüber dem Projektteam besteht weniger Gefahr, gegen das Team zu arbeiten, wenn man mental denselben Konsens offenbart: "Ich weiß, das das Projekt für alle hier eine zusätzliche Arbeit bedeutet und es tut mir wirklich leid. Langfristig verbessern wir dadurch jedoch X,Y, und sogar Z, was allen hier hilft, finden Sie nicht auch, dass es das wert sein wird?"  

In der Sache, also hinsichtlich des Projektergebnisses besteht weniger Gefahr, sich im Detail zu verlieren, wenn sich alle Beteiligten einig sind, dass sie das Projekt eigentlich nicht haben wollen, aber das Ergebnis dringend benötigt wird. 

An dieser Stelle noch eine Warnung: Dinge, die man intensiv hasst, erledigt man als Mensch in der Regel mit so wenig Aufwand wie möglich und so unbewusst wie möglich - eine schlechte Qualität ist die Folge. Wir dürfen unser Projekt also auch wiederum nicht zu intensiv hassen.

In diesem Sinne: Lassen Sie uns alle unsere Projekte ein bisschen hassen, um sie besser zu machen.

Mögen Sie Ihre Projekte? Wie gehen Sie mit Ablehnung Ihrer Projekte um? Wie führen Sie den Konsens im Projekt herbei? Ist Ihr Glas halb voll oder halb leer? Lassen Sie es mich in Ihrem Kommentar wissen.

Eigentlich fast fertig – die verflixten letzten 10%

 

Einer der häufigsten Sätze, die ein Projektmanager zu hören bekommt, dürfte sein: „Ich bin eigentlich fast fertig“.  Mathematisch begabte Projektmitarbeiter hinterlegen gerne noch den konkreten numerischen Wert: „ich bin zu 90% fertig“. Zeit vergeht linear, der Projektfortschritt jedoch nicht. Während wir auf die letzten 10% warten, sterben schnell mal die Dinosaurier aus, ganze Zivilisationen streben empor und zerfallen. Was können wir tun, um endlich ganz fertig zu werden?

Ich entschuldige mich vorab - dies soll ein Beitrag zur Projektfortschrittsverfolgung werden - leider nimmt einen großen Teil des Textes allerdings wieder einmal die Anforderungs- und Zieldefinition ein. Eine Fortschrittsverfolgung, die ja im Kern eine Soll - Ist - Gegenüberstellung ist, kann jedoch nicht durchgeführt werden, wenn das Soll nicht vorab definiert wurde. Stellen Sie sich vor, Sie laden Ihr Smartphone: Ein stylisher Ladebalken wandert vom roten Bereich linear auf 100% - das ist Ihre Fortschrittskontrolle. Stellen Sie sich nun vor, dieser Balken würde nicht existieren: Sie wüssten nicht vorher, wann der Akku Ihres Smartphones leer sein wird und sie wüssten nicht, wann es voll geladen sein würde. Sie wären im völligen Blindflug unterwegs. Im Projektmanagement sind die "100% Akku" die Anforderungen bzw. Ziele und der Ladebalken der Projektfortschritt.

Um ganz fertig zu werden, müssen wir also zunächst natürlich wissen, was "ganz fertig" bedeutet. Dazu verlangt das agile Projektmanagement eine anpassbare Definition von Fertig („Definition of Done“), im klassischen Projetmanagement wird versucht, das Problem über vorab formulierte Abnahmechecklisten, Abnahmekriterien für die zu Projektbeginn definierten Ziele oder Akzeptanzkriterien zu lösen.

Das erste Problem liegt somit im Bereich des Anforderungsmanagements oder auch Demandmanagement. Der Anforderer ist dafür verantwortlich, dass seine Anforderungen ernst genommen werden und überhaupt erst realisiert werden können. 

Wer ist der Anforderer eines Projektes? Formell natürlich der Auftraggeber, also eine Person, die in der Führungsriege zu finden ist. Allerdings kann auch ein Sachbearbeiter eine Projektidee geben, um eine Verbesserung aus operativer Sicht anzustoßen. Nicht zuletzt munkelt man, dass Projekte mitunter dazu dienen, um die Wünsche der Kunden besser befriedigen zu können - somit tun wir gut daran, die Anforderungen möglichst vieler Stakeholder zu kennen und sie systematisch aufzunehmen. Die Anforderer sollten sich dazu vorab Gedanken zu folgenden Punkten machen:

• Was ist das (Haupt)Ziel? 
• Welche Nebenziele existieren? 
• wie kann die Erreichung der Ziele gemessen und belegt werden?
• Was ist der Nutzen hinter der Anforderung? 
• Welche Ziele müssen zwingend erreicht werden, welche Ziele sind nur nützliches Beiwerk? (z.B. anhand der Muss- Kann- Soll oder MoSCoW- Priorisierungstechnik) 

Bei der Zielspezifizierung helfen wie bereits in meinem Beitrag zur Anforderungsdefinition beschrieben die üblichen Methoden wie  SMART, AROMA oder User- Stories, um nur einige Möglichkeiten zu nennen.

Was tut nun der Projektleiter, außer bei der Vorstellung der Anforderungen Kaffee zu trinken und so zu tun, als ob er zuhört? 

Der Projektleiter moderiert das entsprechende Meeting mit dem Ziel, ein einheitliches Verständnis der Stakeholder auf das kommende Projekt zu erwirken. Ziel dieses Abstimmungsprozesses ist, dass die Beteiligten sich von ihren individuellen Anforderungen auf ein gemeinsames Bild einigen - insbesondere hinsichtlich der angesprochenen Priorisierungen der Anforderungen. 

Wenn die Anforderungen klar sind, kann mit der Realisierung begonnen werden.

Ob wir nun zu Beginn einen klassischen Projektablaufplan erstellt haben oder uns die wichtigsten Anforderungen für den nächsten agilen Sprint rausgesucht haben, sei an dieser Stelle erst einmal unerheblich - wir wollen ja so langsam zum Kern dieses Blogs, nämlich der Fortschrittskontrolle kommen. An dieser Stelle wissen wir nun also, was "100% Akku voll" bedeutet.

Wie etablieren wir also eine wirkungsvolle Fortschrittskontrolle?

Das Zauberwort lautet wenig überraschend: Kommunikation. Fragen Sie Ihre Realisierungspartner in regelmäßigen Abständen nach dem Status. Geben Sie sich dabei nicht mit allgemeinen Aussagen wie „fast fertig“ oder „ca. 80%“ zufrieden – fragen Sie konkret nach: Welches Ziel wurde bereits erreicht, woran wird gerade gearbeitet? Was sind die nächsten Schritte? Jeder Fortschrittsbericht ist subjektiv: Schwarzseher werden ihre Fortschritte eher geringer einschätzen, optimistische Personen erledigen gefühlt schnell 90% der Arbeit und benötigen für die restlichen 10% länger. Ein persönliches Gespräch mit den Realisierungspartnern hilft, Missverständnisse zu vermeiden und eventuelle verschiedene Sichtweisen auf den Fortschritt kritisch zu hinterfragen. Die wichtigste Komponente im Projektfortschritt ist immer der Mensch: Sind die Projektmitarbeiter motiviert und kann der Projektleiter ihre Arbeitseinstellung und individuelle Sichtweise auf den Projektfortschritt richtig einschätzen, so ist ein genereller Projektfortschritt sichergestellt. Ob dies in dem festgelegten Maße geschieht, ist dann "nur" noch Feintuning. 

Ich verspreche Ihnen, dass die Wahrscheinlichkeit für Abweichungen zwischen Plan und Ist umso geringer ist, je besser die Anforderungen bzw. Ziele definiert sind und je intensiver Sie den Fortschritt kontrollieren.  "Intensiv" bedeutet dabei häufiger und genauer - kurz gesagt: Je mehr Zeit Sie als Projektleiter darauf aufwenden, Fragen zum Fortschritt zu stellen, desto eher können Sie bei Planabweichungen gegensteuern. Ja, richtig gelesen: Die Arbeit des Projektleiters ist nicht damit getan, Abweichungen festzustellen, das wäre ja noch recht einfach, letztendlich geht es darum, Gegenmaßnahmen umzusetzen um nach Möglichkeit wieder in den Plan zu kommen.

Trotz allem Verständnis und klassischer oder agiler Zieldefinition kann es leider zu Abweichungen kommen. Die Frage ist dann, wie wir darauf reagieren. 

Im klassischen Projektmanagement können wir "einfach" entlang des magischen Dreiecks entscheiden: Eine Fortschrittsverzögerung zu einem festgelegten Berichtzeitpunkts stellt eine Abweichung in der Leistungsdimension dar - diese kann durch die Dimensionen "Zeit" oder "Kosten" kompensiert werden, sprich: Wir benötigen halt länger oder wir setzen mehr interne oder externe Ressourcen ein, um die Leistungsabweichung zu kompensieren. Im agilen Projektmanagement haben wir evtl. ein Sprintziel durch die Leistungsabweichung nicht erreicht und kompensieren ebenfalls, indem wir das Ziel in einen folgenden Sprint aufnehmen oder das Backlog verlängern - auch hier kompensieren wir primär anhand der Dimension "Zeit" und indirekt in der Dimension "Kosten".

Genug der Theorie: Planabweichungen sind ärgerlich. Ob agil oder klassisch sollten wir diese im Team diskutieren und im Zuge einer Lessons Learned oder Sprint Review dafür sorgen, dass das gesamte Team daraus lernen kann, damit sich Abweichungen zumindest aus denselben Gründen nicht wiederholen. Sollten wir es dabei schaffen, das Team so zu motivieren, dass es diese Verzögerung zeitnah aus eigener Kraft aufholen möchte, so hat der Projektleiter ein episches Werk geleistet. Hier möchte ich den Aspekt der individuellen Entwicklung der Teammitglieder in den Fokus stellen: Wenn ein Kollege es nicht gewohnt ist, im Projekt zu arbeiten und seinen Arbeitsaufwand für ein bestimmtes Arbeitspaket oder einen Sprint zu schätzen, so wird er den Arbeitsaufwand tendenziell unterschätzen. Daraus resultiert höchstwahrscheinlich eine Verzögerung. Durch mehr Erfahrung in der Projektarbeit und einen Projektleiter, der den Lerneffekt fördert statt Verzögerungen bestraft, sollten sich die Schätzungen im Laufe der Zeit verbessern und Abweichungen so mit zunehmender Erfahrung des Projektteams (oder Scrumteams) verringern. 

Der große Vorteil der agilen Vorgehensweise liegt hinsichtlich der Fortschrittsverfolgung übrigens darin, dass Fortschritte in kleinen Zyklen von typischerweise 2 Wochen kontrolliert werden. Der klassische Projektleiter kann sich diese Philosophie nutzbar machen, indem er ebenfalls in kleineren Zyklen Fortschrittsbesprechungen ansetzt und insbesondere bei länger andauernden Projektphasen nicht erst zum Ende einer Phase hin Fortschrittscontrolling betreibt. So ist auch der Ladebalken in unserem Smartphone in aussagekräftige, gleichmäßige Teilschritte unterteilt - eine Einteilung, bei der der Ladebalken so lange auf 0% bleibt, bis er schließlich auf 100% springt macht keinen Sinn, genauso wie eine Fortschrittsanzeige in sagen wir mal zunächst 10%, dann bei 50% und schließlich bei 80% und 100% - wir könnten die Fortschrittsdauer mit diesen Fortschrittsmesszeitpunkten einfach nicht sinnvoll planen.

Wie und in welchen Zyklen verfolgen Sie den Status in Ihren Projekten? Wie gehen Sie mit Ihrem Projektteam bei Planabweichungen um? Wie entscheiden Sie, welche Gegenmaßnahmen Sie einleiten? Wie oft kontrollieren Sie den Ladebalken Ihres Smartphones? Lassen Sie es mich in Ihrem Kommentar wissen.