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. 

Digitalisierung, Digitalisierungsstrategie & Digitalisierungsprojekte

"Wir arbeiten mit Computern, also sind wir digital" wenn Sie diesen Satz unterschreiben würden oder ihn schon zu oft gehört haben, sollten Sie unbedingt weiterlesen.

Um zu klären, was Digitalisierung eigentlich ist und noch wichtiger: Worin der Nutzen der Digitalisierung für Ihr Unternehmen liegen kann, möchte ich zunächst 2 Beispiele anführen, was Digitalisierung nicht ist. Beide Beispiele habe ich selber erlebt.

1. Beispiel: Buchbestellung: Es war an einem Wochenende, ich beschloss, dass ich ein Buch benötige- Projektmanagement Fachliteratur, was sonst? Das Buch war nur bei einem einzigen speziellen  Händler erhältlich (nein, nicht der bekannte große Händler, auf den kommen wir aber später noch). Nun hatte ich 2 Möglichkeiten: Zum Einen eine Bestellung des physischen Buchs, das wäre dann irgendwann in der nächsten Woche gekommen, und ich wollte ja am Wochenende schon lesen - also wählte ich Option 2, die Bestellung der digitalen Variante. Ich klickte mich also durch den Shop, wählte die digitale Variante aus, Bezahlung via PayPal, damit das Geld direkt ankommt und beendete die Bestellung. Ich erhielt kurz danach die automatisch generierte Bestätigungsmail. So weit so digital. Es folgte die Enttäuschung: Der Text der Mail sagte sinngemäß: Vielen Dank für Ihre Bestellung. Ein Mitarbeiter prüft Ihren Zahlungseingang und wird Ihnen den Downloadlink zum Buch senden. Super. An diesem Wochenende konnte ich nicht mehr lesen. 

2. Beispiel: Rechnungseingang im Unternehmen. Vielleicht kennen Sie diesen Prozess? Eine Rechnung kommt im Unternehmen physisch an, wird eingescannt und per E-Mail an den Adressaten weitergeleitet (wir sind ja digital). Der druckt sie aus, um sie unterschreiben zu können, scannt sie wieder ein und leitet sie an die FiBu weiter. Die FiBu druckt die Rechnung aus, um sie gegenzeichnen zu können, scannt sie ein und legt das physische Exemplar in einem Ordner ab (Aufbewahrungspflicht muss man ja schließlich physisch wahren, so meinen viele).

Die Schwachstellen der beschriebenen Prozesse sind aus der Vogelperspektive offensichtlich. Und mit dieser Feststellung können wir schon mal schlussfolgern, dass sich erfolgreiche Digitalisierung auf Prozesse beziehen muss - damit meine ich End-to-End-Prozesse, also von der Entstehung eines Kundenwunsches bis zu seiner Erfüllung, vom Procure to Payment oder von der Personalbeschaffung bis zur Personalfreisetzung um nicht nur Markt- bzw. Bestellprozesse, sondern auch gleich Finanzprozesse oder Personalprozesse mit einzubeziehen. 

Mein Lieblingszitat dazu stammt von Thorsten Dirks, CEO der Telefónica Deutschland: "Wenn Sie einen Scheißprozess digitalisieren, dann haben Sie einen scheiß digitalen Prozess“.

Wie würden die beschriebenen Prozesse besser ablaufen können? 

Im Falle des ersten Beispiels kennen wir alle einen tollen Bestellprozess von demjenigen Großhändler, der anfing Bücher zu verkaufen und mittlerweile jeden Scheiß vertickt (und leider schlecht mit seinen Mitarbeitern umgeht). Besagter Großhändler hat einen vollkommen digitalen und vor Allem schlanken Bestellprozess aufgesetzt, von der Bestellung bis zur sofortigen Lieferung eines digitalen Buchs. Auch für die Bestellung physischer Güter hat sich der Großhändler optimiert: Lieferung am nächsten Tag inkl. völliger Transparenz des Versandstatus. Aftersales- Support läuft hervorragend über gut konfigurierte Chatbots, unproblematische Rücksendung mit digitalen Versandetiketten. Da bin ich als Kunde zufrieden - und das ist auch einer der herausragenden Nutzen der Digitalisierung: Kundenzufriedenheit (beim Bestellprozess, die Digitalisierung anderer End-to-End-Prozesse verfolgt andere Nutzendimensionen). Auch nach der Bestellung werden mir in der App des Händlers weitere mögliche Güter vorgeschlagen, die ich aufgrund eines cleveren Algorithmus interessant finden könnte. Darin spiegelt sich eine weitere wichtige Dimension der Digitalisierung wider: Die massenhafte Erstellung & intelligente Nutzung von Daten. Ich komme gleich darauf zurück.

Im Falle des zweiten Beispiels würde eine Rechnung digital ankommen (oder zumindest einmalig gescannt werden, denn es ist leider immer noch schwer, jeden Lieferanten von den Vorzügen einer digitalen Rechnungsstellung zu überzeugen). Die digitale Rechnung würde automatisch digital an die entsprechende Stelle weitergeleitet werden, indem eine künstliche Intelligenz die Rechnung ausliest, der Empfänger unterschreibt digital (per revisionssicherem Mouseklick). Anschließend erkennt der hinterlegte Workflow (bzw. "Prozess" auf deutsch, um die Prozesssicht zu stärken), dass die Rechnung freigegeben ist und vergleicht den Rechnungsbetrag mit dem im System geplanten Rechnungsvolumen. Befindet sich der Ist- Rechnungsbetrag innerhalb der vordefinierten Toleranzgrenze, so wird die Rechnung ohne weiteres manuelles Eingreifen archiviert & bezahlt - also vollautomatisch. Sollte sich der Rechnungsbetrag außerhalb der Toleranzgrenze befinden, so muss eine manuelle Aussteuerung erfolgen. Der Nutzen dieses digitalen Procure-to-Pay- Prozesses  liegt in der Effizienz  - das Unternehmen spart Ressourcen, Zeit, Kosten. Und auch in diesem Prozess werden Daten erstellt und genutzt - systemübergreifend durch intelligente Vergleichsalgorithmen.

Zusammenfassend bedeutet Digitalisierung eine End-to-End Prozessoptimierung und - Automatisierung durch intelligente Erstellung & Nutzung von Daten und durch die Vernetzung von Systemen. 

Der Zusammenhang zwischen Prozessen und Daten besteht darin, dass Prozesse Daten erzeugen - das tut jeder Prozess zwangsläufig. Es ist nur ein Unterschied, ob sie Daten manuell in Excel- Tabellen tippen und auf Ihrem persönlichen Laufwerk C:\Datenfriedhof ablegen oder dieselben Daten strukturiert in standardisierten Systemen unternehmensweit nutzbar machen.

So weit zur Digitalisierung - was ist nun mit der Digitalisierungsstrategie? 

Die Digitalisierungsstrategie leitet sich wie die IT- Strategie von der Unternehmensstrategie ab. Jetzt wird es noch abstrakter als die ganze Digitalisierungsgeschichte es eh schon ist - ich bleibe daher bei meinen Beispielen: Die Unternehmensstrategie könnte unter Anderem vorsehen, die Kundenzufriedenheit in den nächsten 3 Jahren um 15 % zu steigern, sowie Kosteneinsparungen in der Rechnungsbearbeitung um 10% im selben Zeitraum zu realisieren. 

An dieser Stelle kommt nun der Digitalisierungsberater, der CIO oder der Projektportfoliomanager ins Spiel, fängt den Ball der Unternehmensstrategie auf und verwandelt sie zusammen mit anderen Entscheidungsträgern in eine Digitalisierungsstrategie . Die Digitalisierungsstrategie könnte sinnvollerweise auf der Optimierung der bereichsübergreifenden Prozesse aufbauen, die vorhandenen Daten bereinigen und die zukünftigen Datenströme vereinheitlichen und auswertbar machen. Zusätzlich wird mit ziemlicher Sicherheit dafür die bestehende IT- Systemlandschaft und deren Schnittstellen in Frage gestellt werden und die Einführung neuer IT- Systeme vorschlagen. Die Digitalisierungsstrategie ergibt somit ein Digitalisierungsportfolio.

Und damit kommen wir schon auf die Ebene der Projekte - denn das Digitalisierungsportfolio besteht aus einem bunten Strauß von Digitalisierungsprojekten. Es ist schwer, dafür Beispiele zu nennen, denn die konkreten Projekte richten sich danach, was bereits im Unternehmen vorhanden ist. Mögliche Projekte wären: Einführung einer Datagovernance, Einführung einer Prozessgovernance oder eines einheitlichen Prozessmanagements, Einführung eines (neuen) BI- Tools, Einführung eines Chatbots, Einführung eines (neuen) Endkundenshops,... 

Und damit wären wir am vorläufigen Ziel angelangt - die Digitalisierungsstrategie ist erstellt und in Projekte eingegossen, welche wir bequem anhand der üblichen Projektdimensionen  Kosten, Leistung und Zeit tracken können.

Was bedeutet Digitalisierung für Sie? Wie wird die Digitalisierungsstrategie in Ihrem Unternehmen gehandhabt? Wie oft haben Sie schon den Satz: "Wir arbeiten mit Computern, also sind wir digital" schon gehört? Lassen Sie es mich in Ihrem Kommentar wissen.

Die Suche nach dem Sinn: Der Nutzen von Projekten

 

Wenn Sie diesen Beitrag lesen, dann werden Ihre Projekte besser. 

Was bewirkt dieser Satz in Ihnen? Denken Sie sich: Och nöö, nicht noch so ein dummes Werbeversprechen? Weckt er Hoffnung in Ihnen? Oder Motivation, diesen Beitrag bis zum Ende zu lesen? Ich hoffe ehrlich gesagt auf Hoffnung und Motivation, denn obwohl der eingangs postulierte Satz zwar Plump formuliert ist, sollte er Ihnen etwas mitgeben: Die Aussicht auf einen konkreten Nutzen für Sie - und deshalb hoffe ich, dass Sie weiterlesen.

Wie sieht es mit dem Nutzen von unseren Projekten aus? Wem nutzen sie wann? Haben Sie da mal drüber nachgedacht?

Spätestens seit dem Meister der Produktpräsentationen und der Verkaufsargumente Steve Jobs wissen wir, dass dem Kunden einen Nutzen geben müssen. Der Kunde ist somit ein wichtiger Stakeholder, um das aufs Projektmanagementdeutsch herunter zu brechen. 

Hand auf´s Herz: Taucht der Endkunde in Ihren Stakeholderanalysen überhaupt auf? Ich frage, weil er häufig vergessen wird. Und wenn wir uns Mühe geben, an den Endkunden zu denken, dann taucht er im Quadranten niedrig/ niedrig auf- folglich hat er am Projekt wenig Interesse, wenig Einfluss aufs Projekt, wenig Macht, oder wie auch immer Sie Ihre Achsen beschriften wollen - der Endkunde hat wenig vom Projekt selbst.

Jaa, aber der Endkunde sehnt sich doch nach dem Projektergebnis? Bleiben wir beim Beispiel von Steve Jobs und dem IPhone: Das Produkt ist prinzipiell ja schon eine tolle Sache - wir, die Kunden wussten davon jedoch nichts, bis es auf den Markt kam. Demzufolge war uns allen das entsprechende Produktentwicklungsprojekt völlig egal. Wir wären sogar glücklicher gewesen, wenn das Entwicklungsprojekt eher begonnen hätte und schneller abgeschlossen gewesen wäre, denn: Niemand mag Projekte. Wenn wir in einem Projekt ein Produkt entwickeln, entsteht durch das Produkt (hoffentlich) ein vorzeigbarer Kundennutzen - klar, denn der Kunde soll am Ende schließlich kaufen.  Dazu ist es wichtig, dass vor Projektbeginn die entsprechenden Anforderungen klar definiert sind - und es hat sich als sehr hilfreich erwiesen, den Kunden als Stakeholder ins Projekt einzubeziehen, um ihm sein Dasein im untersten Quadranten der Stakeholderanalyse etwas schmackhafter zu gestalten, beispielsweise durch Design- Thinking- das wirkt sich dann auch extrem positiv aufs Projektergebnis aus, munkelt man.

In IT- Digitalisierung- und Organisationsprojekten sieht es wesentlich schlechter für den Endkunden aus: Fragestellungen wie: Möchtest du, lieber Kunde, dass wir ein CRM- System einführen? Würde der Kunde selbst im Zuge des Design- Thinkings wahrheitsgemäß nur mit "Ist mir völlig egal" beantworten können. Selbst wenn wir spezifischer fragen: "Möchtest du, dass wir deine Beschwerden und Anliegen zielgerichteter bearbeiten können" - welche andere Antwort außer "Ja, na klar" sollten wir uns erhoffen? Bei derartigen Projekten ist der Kundennutzen stark indirekt und wir investieren in einen Nutzen für das Unternehmen, nicht primär für den Kunden. IT- Digitalisierungs- und Organisationsprojekte sind somit folglich eine betriebswirtschaftliche Selbstbefriedigung, die zunächst viel Geld kostet und danach dem Unternehmen selbst hilft, wettbewerbsfähig zu bleiben, effizienter zu arbeiten etc. Nichtsdestotrotz sind solche Projekte natürlich wichtig, das schreibe ich voller Überzeugung als IT- Projektmanager.

Halten wir fest, dass wir zur Erstellung von Nutzen für den Endkunden diesen so weit es geht ins Projekt einbeziehen sollen - in Form von Umfragen oder Design- Thinking vor Projektbeginn, Produktpräsentationen während des Projektes oder in Form von Newslettern, Aushängen und unter Nutzung sonstiger Kommunikationskanäle.

Noch mehr? Klar... Widmen wir uns nun der größten Gruppe an Stakeholdern in unseren Projekten: Dem Projektteam, also denjenigen Kästchen, die im Organigramm in unterschiedlichen Formen unter dem Projektmanager stehen. Da das Projektteam letztendlich die Arbeit im Projekt erledigt, sind sie eine extrem wichtige Stakeholdergruppe.

Und nun kommen wir zum 2. Teil, dem eigentlichen Kern der Sache: Dem Nutzen für das Projektteam. Das Projektteam taucht ebenfalls in den wenigsten Stakeholderanalysen auf - meist in Form eines Vorgesetzten, auf den wir zugehen müssen, damit er jemanden für´s Projekt abstellt. Und das ist wörtlich gemeint, den viele Projektmitarbeiter fühlen sich dann auch im Projekt wie abgestellt: Der Projektleiter predigt irgendwelche High- Level- Ziele, die erfüllt werden müssen, stellt enthusiastisch einen Ablaufplan vor, fordert Ergebnisse ein, welche die Projektmitarbeiter irgendwie auf den letzten Drücker halbherzig realisieren, weil das Projekt eine zusätzliche Belastung für sie ist. Nutzen? Fehlanzeige! Die fühlen sich eher be-nutzt oder ausge-nutzt.

Und gerade diesen Mißstand können wir als Projektleiter sehr einfach ändern - ich rede nicht nur von der obligatorischen Projektabschussparty am Ende des Projektes und dem halbherzigen Bauchpinseln in Form einer Lessons- Learned- Session zum Projektende. 

Der Nutzen für das Projektteam geht eng einher mit deren Motivation. Die Frage, wie wir Nutzen schaffen kann also in Einklang mit der Frage beantwortet werden, wie wir Motivation schaffen. Und diese Frage können wir zunächst einfach anhand der Stakeholderanalyse beantworten: Machen wir die Projektmitarbeiter betroffen, wecken wir ihr Interesse, erhöhen wir ihren Einfluss - also ziehen wir sie in den Hoch/ hoch Quadranten der Stakeholderanalyse, um ihre Motivation zu wecken. Diesen Gedanken verfolgen ebenfalls die agilen Methoden wie SCRUM. Aber wie schaffen wir das?

Naheliegend ist einer der einfachsten Wege: Fragen wir die Projektmitarbeiter zu Projektbeginn doch einfach: "Welchen Nutzen schafft das Projekt für euch?" und "Was müssten wir im Projekt noch tun, um einen Mehrwert für euch zu schaffen?" 

Ich verspreche, dass ein kurzes Brainstorming von 10 Minuten und eine kurze Diskussion von 20 Minuten hier bereits Wunder wirken - die Projektmitarbeiter fühlen sich eingebunden, wertgeschätzt, motiviert. Natürlich müssen wir die Ergebnisse dann noch in Form von Zielen im Projekt verankern. Die genannten Fragen sollen keinesfalls leere Floskeln sein, um zum Schein Nutzen zu schaffen, sondern sie müssen im Projekt verankert werden - dafür muss der Projektleiter sorgen. 

Die Verankerung der Antworten der Projektmitarbeiter im Projekt gibt den Projektmitarbeitern einen höheren Einfluss, weckt (hoffentlich) deren Interesse, gibt ihnen mehr Macht - tadaaa, schon sind die Projektmitarbeiter zu einem wichtigen Stakeholder aufgestiegen, sind relevant für das Projekt geworden - und somit in der Stakeholderanalyse mindestens in einen "hoch" Quadranten aufgestiegen. 

Eventuell ist es nicht einmal notwendig, weitere Ergebnisziele ins Projekt aufzunehmen - möglich sind auch Vorgehensziele. Ein Beispiel: Motivation und Nutzen können auch durch Teamarbeit entstehen auf dem Weg, die Ziele des Top-Managements zu erfüllen. "Ich wünsche mir regelmäßige Zusammenarbeit mit den Kollegen aus anderen Bereichen" wäre ein Beispiel - die Fokussierung auf Teamwork im Projekt, anstelle der Arbeit des Einzelnen. Immerhin heißt es ja auch "Projektteam" -  in diesem Fall kann der Projektleiter helfen, den Teamgedanken gezielt zu stärken.

Auch während des Projektes lohnt es sich, das Projektteam aktiv einzubinden und echtes Interesse an den Befindlichkeiten des Teams zu haben und in Richtung des Projektauftraggebers zu vermitteln. Damit meine ich, dass ein guter Projektleiter nicht nur Ziele von Oben nach Unten durchdrückt ohne Rücksicht auf Verluste, sondern Befindlichkeiten des Projektteams zum Auftraggeber trägt und in der Königsdiziplin der Kommunikation Ideen hat, wie man Ziele von Oben und Befindlichkeiten von Unten im Win-Win vereint. Konsensfindung ist das Stichwort und eine kreative Eigenschaft, die der täglichen Arbeit des  Projektleiters Mehrwert verschafft.

Was den Projektmitarbeitern hilft, hilft oftmals auch dem Kunden - und wenn wir letzteren schon nicht befragen, so helfen uns evtl. die Projektmitarbeiter, mehr Kundennutzen zu erzeugen. 

Wie schaffen Sie Nutzen für Ihre Projekte, insbesondere im Projektteam? Wie sorgen Sie für Motivation im Projektteam? Lassen Sie es mich in Ihren Kommentaren 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.