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. 

Das Problem der Erbse - Der Unsinn der Risikoanalyse

Kennen Sie den: Es kullern zwei Erbsen über die Straße, da sagt die Eine: "Pass auf, da vorne ist eine  Trep- pe - pe - pe - pe ..."

Ok, der ist nicht allzu witzig - aber noch weniger witzig ist, dass die Risikoanalyse unserer Erbse hervorragend funktioniert hat - sie hat das Risiko "Treppe" völlig richtig und als bedrohliche Situation erkannt! Genauso läuft die Risikoanalyse in der Praxis häufig ab: "Oh, da ist ein Risiko - toll, ich habe es erkannt - Risikoanalyse zu den Akten legen, Schulterklopfer vom Chef abholen und damit ist der Prozess beendet.

Aber wie bekommen wir das besser hin? 

Fangen wir mal beim Namen an, der ist schon stark irreführend: "Risikoanalyse" - wird jemand mit einer Risikoanalyse beauftragt, so hat er ja fast keine andere Möglichkeit, als den Prozess nach der Analyse mit den Worten: "Vorsicht, da kommt eine Treppe" zu beenden. Sinn und Ziel der Sache ist es eigentlich, Gegenmaßnahmen zu entwickeln  - in unserem Beispiel hätte die Erbse in eine andere Richtung kullern können, langsamer kullern oder ganz bremsen sollen, dann hätte sie erfolgreich eine Gegenmaßnahme eingeleitet. Treiben wir die Wortklauberei nicht auf die Spitze - die Risikoanalyse ist ein notwendiger erster Schritt um Gegenmaßnahmen entwickeln zu können, beides bildet zusammen mit der fortlaufenden Beobachtung ein wirkungsvolles Risikomanagement. Wichtig ist an dieser Stelle, dass die Risikoanalyse nur der erste Schritt im Risikomanagement darstellt - und dass der Risikomanagementprozess fortlaufend weit über die Risikoanalyse hinausgeht.  Nur durch einen wirkungsvollen Risikomanagementprozess können wir in Zukunft tausende Erbsen vor den Treppen retten und mindestens ebenso viele Lemminge vor dem Sprung von der Klippe bewahren - denn ein Sprung von der Klippe stellt möglicherweise keine adäquate Gegenmaßnahme auf ein identifiziertes Risiko dar, aber dazu später mehr. 

Wie betreiben wir ein wirkungsvolles Risikomanagement?

Zunächst brauchen wir eine Risikoanalyse - und die können wir ja noch von unserer Erbse lernen: Die Erbse guckt sich einfach aktiv um und sucht nach Gefahren. Nichts anderes ist die Risikoanalyse im Kern. Der Erbse ist allerdings in ihrer kullernden Laufbahn der Unterschied zwischen einer geringen Gefahr wie einer leicht abschüssigen Rampe und einer großen Gefahr wie einer hohen Treppe intuitiv klar - diesen eindeutigen Blick haben wir in komplizierten und bereichsübergreifenden Projekten oftmals nicht. Deshalb haben kluge Leute beschlossen, dass wir Risiken anhand deren Eintrittswahrscheinlichkeit in Prozent und deren Auswirkung in € bewerten, beide miteinander multiplizieren und so den Risikowert erhalten. 

Damit haben Universitätsprofessoren, zertifizierte Risiko- und Projektmanager einen Heidenspaß, das durchschnittliche Projektteam allerdings eher weniger. Das Projektteam sollte beim Brainstorming der Risiken und deren Bewertung jedoch dringend aktiv mitmachen, da es für den Projektmanager sehr schwer ist, Risiken aus unterschiedlichen Unternehmensbereichen zu erkennen und zuverlässig zu bewerten - leichter ausgedrückt: Der Projektmanager weiß nicht notwendigerweise, ab welcher Steigung eine Rampe für eine Erbse kritisch ist, das muss die Erbse selber am besten wissen. Das Problem ist lediglich, dass die Erbse weder in Prozent noch in tausend €- Dimensionen denkt, also erlösen wir die Erbse von dieser Aufgabe, die zugegebenermaßen nur geübten Akteuren gut gelingen kann, selbst bei häufiger Anwendung immer noch eine ungefähre Schätzung bleibt und niemals eine exakte Wissenschaft darstellen kann. Dazu kommt, dass die Risikoanalyse nur den ersten Schritt darstellt, daher wollen wir dazu auch nicht zu viel Zeit aufwenden - es geht uns ja letztendlich zielorientiert um die Gegenmaßnahmen.

Wie führen wir die Risikoanalyse am besten durch?

Ich habe gute Erfahrungen damit gesammelt, das Konzept der Risikoanalyse zwar in seiner epischen mathematischen Breite dem Projektteam vorzustellen, das nachfolgende Brainstorming und die Kategorisierung der Risiken jeweils anhand der Skala 1 bis 5 sowohl für die Dimension der Eintrittswahrscheinlichkeit als auch in der Dimension der Tragweite durchzuführen - das ist wesentlich alltagstauglicher für ein Projektteam: 

Die Zahlen innerhalb der Felder stellen übrigens den Risikowert dar, bevor Sie anfangen nachzurechnen. Das Brainstorming lässt sich auf diese Art einfach an einem Whiteboard, einer Pinnwand oder, meine bevorzugte Variante, mit Stattys an irgendeiner Wand durchführen. Die Projektmitglieder können ihre Zettel mit Risiken einfach frei an der Wand verteilen, die grundlegenden Fragestellungen lauten nur:

• Wird das Risiko auf jeden Fall eintreten (Eintrittswahrscheinlichkeit Wert 5)?
• Wird dieses Risiko das Unternehmen insolvent gehen lassen (Auswirkung Wert 5)? 

Eine nachfolgende Diskussionsrunde kann helfen, dass Projektmitglieder anderer Abteilungen Stellung beziehen und das Projektteam sich so auf eine gemeinsame Betrachtung einigt. 

Ich habe übrigens folgende Beobachtung gemacht: Je länger solche Diskussionsrunden gehen, desto mehr werden die einzelnen Zettel mit den Risiken im Millimeterbereich verschoben. An dieser Stelle können Sie die offene Diskussion dann getrost beenden, denn der Kern der Risikoanalyse ist erstmal der Text, der auf dem betreffenden Zettel steht, nicht so sehr seine millimetergenaue Einordnung. 

Wie Sie an der Ampel- Farbcodierung bereits sehen können, teilen wir die Risiken danach eh wiederum  zumindest gedanklich in die üblichen managementtauglichen 3 Kategorien ein: Rot - Gelb - Grün. Vor diesem Hintergrund scheint es umso widersinniger, dass wir uns vorher die Mühe des Denkens in Prozenten und tausend € machen sollen und das ganze Zeug auch noch multiplizieren müssen, finden Sie nicht auch?

So, die Risikoanalyse steht, jetzt sind wir genauso klug wie die Erbse. Fangen wir an, klüger als selbige zu sein: Widmen wir uns den Gegenmaßnahmen. 

Jedem Risiko sollte mindestens eine Gegenmaßnahme zugeordnet werden, die wir dann in der Schublade haben, falls wir das betreffende Risiko eintreten sehen. Die Gegenmaßnahmen können ebenfalls prima im Kreis des Projektteams gebrainstormt werden, falls wir das Team vorher nicht mit dem Denken in Prozenten und in exorbitanten Kostendimensionen oder beim exzessiven Verschieben von Zetteln zu sehr beansprucht haben sollten. 

Das Finden der Gegenmaßnahmen ist auf der quantitativen Ebene genauso ein kreativer Brainstormingprozess wie das Finden von Risiken. Uuuund jetzt kommen wieder die unkreativen Universitätsprofessoren hervor: Wenn wir ja vorher schon in Prozent und Gelddimensionen gedacht haben, dann machen wir das einfach direkt nochmal und bewerten unsere Gegenmaßnahmen anhand deren erwarteter Wirksamkeit (in Prozent) und deren Kosten (in €). Uuuund jetzt komme ich: Oder wir machen es etwas einfacher und wir lassen die erwartete Wirksamkeit weg - die ist eh grob geschätzt und für eine Maßnahme, die erstmal in der Schublade liegt jetzt nicht wirklich dringend notwendig. Die Kosten der Gegenmaßnahme sollten wir dafür dann so weit wie möglich in Erfahrung bringen, denn danach wird uns der Lenkungskreis mit hoher Wahrscheinlichkeit fragen (auch ohne konkrete Prozentangabe gültig). 

Wie bringen wir die Kosten für Gegenmaßnahmen in Erfahrung? 

Jetzt wird es wirklich unangenehm - wir müssen mit Menschen sprechen oder mit Zahlen rechnen oder im Zweifelsfall beides tun. Ein Beispiel: Für die üblichen Risiken "Projektverzögerung durch Personalmangel" oder "Projektverzögerung durch parallele Linienaufgaben" lässt sich die Gegenmaßnahme "kurzfristige Personalbeschaffung" formulieren. Dazu können wir z.B. beim Zeitarbeitsvermittler unseres Vertrauens anrufen und Verfügbarkeiten sowie Stundensätze in Erfahrung bringen. Der Stundensatz multipliziert mit den erwarteten Stunden im Ausfallzeitraum ergibt die halbwegs seriös geschätzten Kosten dieser Gegenmaßnahme. 

Wenn unsere Erbse die Kosten ihrer Gegenmaßname "Der Treppe ausweichen" hätte kalkulieren wollen, so hätte sie die Dauer des erwarteten Umwegs als Zeitkosten kalkulieren können und / oder die Opportunitätskosten dieses Zeitverzugs  als monetäre Kosten. 

Da dieser Kalkulationsprozess wirklich unangenehm ist, ist es praktikabel, Gegenmaßnahmen nach der vorgestellten Ampel- Farbcodierung mit dem Lenkungskreis abzustimmen: Im roten Bereich der Risiken sollten Gegenmaßnahmen recherchiert werden, im gelben Bereich reicht möglicherweise eine Schätzung und im grünen Bereich werden häufig keinerlei Gegenmaßnahmen definiert oder eingeleitet.

Abschließend sei noch erwähnt, dass wir diejenige Gegenmaßnahme zuerst einleiten, welche die höchste Effizienz verspricht  und die niedrigsten Kosten verursacht. Erfahrungsgemäß ist es jedoch am besten, bei einem eingetretenen Risiko die möglichen bzw. erforderlichen Gegenmaßnahmen mit dem Lenkungskreis abzustimmen.

Damit sind wir am Ende des Risikomanagementprozesses.... Halt, doch nicht, das habe ich vergessen, weil es eigentlich alle vergessen: Wir müssen die Risikoanalyse und die Aufstellung der Gegenmaßnahmen regelmäßig aktualisieren. 

Genauso wie im Laufe eines Projektes Stakeholder hinzukommen oder wegfallen können, kann dies auch mit Risiken passieren. Zusätzlich können sich Risiken hinsichtlich ihrer Eintrittswahrscheinlichkeit oder Auswirkung ändern, ebenso können sich die Kosten für die Gegenmaßnahmen ändern oder Gegenmaßnahmen können aufgrund technischer Machbarkeit wegfallen oder neue Gegenmaßnahmen möglich werden. Je länger ein Projekt dauert, je mehr es kostet und je wichtiger es ist, desto wichtiger ist es, die beschriebenen Schritte zu wiederholen. 

Jetzt war es das aber wirklich. 

Führen Sie in Ihren Projekten Risikoanalysen zusammen mit dem Projektteam durch? Welche Erfahrungen haben Sie dabei machen können? Definieren Sie vor Projektbeginn bereits Gegenmaßnahmen? In welchen Zyklen aktualisieren Sie Ihre Risikoanalyse?

Wer lenkt den Lenkungskreis?

Der Lenkungskreis ist die oberste strategische Entscheidungsebene im Projekt und besteht aus den Projektauftraggebern. Die Aufgabe des Lenkungskreises ist es, Entscheidungen zu treffen, die die Entscheidungskompetenz des Projektleiters übersteigen. Das kann man in der Projektmanagementliteratur lesen. 

Aber was braucht der Lenkungskreis, damit er entscheiden kann und wie bekommen wir gemeinsam sinnvolle Entscheidungen hin? Muss der Lenkungskreis nicht auch gelenkt werden?  Wer lenkt den Lenkungskreis? 

Es ist ein Freitag am Monatsende - Termin für den Lenkungskreis. Der motivierte Projektleiter X hat gestern Nacht noch den Statusbericht für sein Projekt erstellt: Meilensteinberichte, Kostenberichte, Leistungsberichte, alles da. Am Ende des Foliensatzes befindet sich der gefürchtete "Entscheidungsbedarf für den Lenkungskreis". Der Projektleiter bereitet den angemieteten Meetingraum vor, beamt die Folien an die Wand und wartet ungeduldig auf das Erscheinen des Lenkungskreises. Es gibt viele Themen und er hofft, dass nicht zu viele Rückfragen kommen und dass die angesetzte Zeit reicht. 

Die Mitglieder des Lenkungskreises erscheinen - alle zu spät. Das vorherige Meeting hat länger gedauert, das Wochenende wird sehnsüchtig erwartet, und überhaupt: Welcher Idiot kommt auf die Idee, am Freitag am Monatsende ein Meeting anzusetzen?  Wahrscheinlich will der Projektleiter wieder irgendwelche Entscheidungen haben, erklärt das Problem nicht ausreichend und schläfert die Entscheider vorher noch mit den immergleichen Standardfolien ein. Herr Dr. Y entschuldigt sich kurz und holt sich erstmal einen Kaffee, noch bevor der Projektleiter den Lenkungskreis begrüßt, weil ihn schon beim Gedanken an die folgende Präsentation der Sekundenschlaf überfällt. 

So beginnt ein Lenkungskreismeeting - und, spulen wir kurz vor, viele Lenkungskreise enden damit, dass der Lenkungskreis weiteren Informationsbedarf bis zum nächsten Meeting im nächsten Monat adressiert ohne die aus Projekt(leiter)sicht wichtigen Entscheidungen getroffen zu haben: "Können Sie die Vor- und Nachteile noch weiter ausarbeiten?" "Bitte gehen Sie bei der Kostenstruktur der Alternativen noch etwas weiter in die Tiefe" "Fragen Sie dazu bitte nochmal den Kollegen Z, der hatte glaube ich mal ein ähnliches Problem, vielleicht kann der helfen". Abgesehen vom Kaffee war das Meeting unterm Strich wieder einmal verschenkte Zeit.

Wie können wir das vermeiden und im Zuge einer erfolgreichen Projektkultur und natürlich auch einer effizienten Meetingkultur ergebnisorientierte Lenkungskreismeetings durchführen? 

Am Anfang war das Ziel, und das sollte in die niedergeschriebene Agenda des Meetings und in die Begrüßung mit einfließen: "Ich möchte ein Update zum Projektfortschritt geben und den Entscheidungsbedarf adressieren". Ebenso gehören in die Termineinladung die Folien inklusives des Entscheidungsbedarfs, daher sollten die entsprechenden Folien nicht wie in obigem Beispiel in der Nacht vorher fertiggestellt werden, sondern etwas eher. Hier befindet sich der Projektleiter natürlich in einer Zwickmühle: Ergibt sich kurzfristiger Entscheidungsbedarf, so muss der natürlich asap offengelegt und adressiert werden, damit das damit zusammenhängende Problem zeitnah gelöst werden kann. 

Dazu ist die vertrauensvolle offene Kommunikation zwischen Projektleiter und Lenkungskreis notwendig: Der Lenkungskreis muss soviel Vertrauen in den Projektleiter haben, dass er davon ausgeht, dass der Projektleiter Risiken so früh wie möglich vorhersieht und den damit zusammenhängenden Entscheidungsbedarf so früh wie möglich adressiert, dass auf der anderen Seite jedoch Probleme kurzfristig entstehen können und sich nicht unbedingt nach dem vollen Terminplan des Lenkungskreises richten. 

Wo wir gerade bei der Kommunikation sind: Es empfiehlt sich, den Lenkungskreis genauso wie das Projektteam mit möglichst wenigen Personen zu besetzen, um Abstimmungswege kurz zu halten. Darauf kann der Projektleiter schon vor Projektbeginn hinarbeiten: In den meisten Fällen existiert ein Auftraggeber, dem das Projekt wichtig ist. Wenn dieser Auftraggeber bei der Vorbesprechung versucht, den Lenkungskreis mit einer Armee von weiteren Entscheidern zu besetzen, so sollte der Projektleiter hier bereits lenkend tätig werden. Ich habe die besten Erfahrungen mit kleinen Lenkungskreisen, sogar mit nur einem einzigen Auftraggeber gesammelt. Egal, wie voll die Terminkalender des Projektleiters und des Auftraggebers sind, eine halbwegs spontane Abstimmung ist in dieser Konstellation immer zeitnah möglich, im schlimmsten Fall beim Mittagessen. Bei Bedarf kann der Kreis der Entscheider ja situativ erweitert werden, dann aber für einzelne, spezifische Problemstellungen und nicht generell als festes regelmäßiges Meeting im großen Kreis.

Unabhängig von der Größe des Lenkungskreises ist die Vorbereitung seitens des Projektleiters ausschlaggebend für die Entscheidungen des Lenkungskreises. Dabei möchte ich nicht auf die Form der Statusberichte eingehen, sondern auf deren Inhalte:

Projekte werden in den Dimensionen Zeit-Kosten-Leistung beurteilt, das weiß jeder Projektleiter und strukturiert seine Statusberichte dementsprechend. Wissen das auch die Mitglieder des Lenkungskreises? Wollen sie überhaupt einen derart strukturierten Bericht? In den meisten Fällen wollen die obersten Entscheidungsträger eine kurze Kategorisierung - die Ampelfarben rot, gelb, grün haben sich dazu erfolgreich etabliert. Was genau gewünscht wird, sollte mit dem Lenkungskreis abgesprochen werden - ein Statusbericht mit mehr Text als die Morgenzeitung ist mit Sicherheit falsch, ebenso falsch kann es aber auch sein, in minimalistischem Eifer lediglich eine gelbe Ampel als Statusbericht zu präsentieren. Hier kann der Lenkungskreis vom Projektleiter gelenkt werden, indem der Projektleiter aktiv gewünschte Inhalte des regelmäßigen Statusbericht abspricht, Vor- und Nachteile und insbesondere den Zeitbedarf zur regelmäßigen Präsentation der Statusberichte erläutert. Wenn der Lenkungskreis alles genau wissen möchte, dann dauert es halt länger, alle Details zu berichten. Best Practise ist da aus meiner Sicht das Management by Exception: Der Lenkungskreis erhält regelmäßig kurze Berichte und erst detaillierte Informationen, wenn etwas schief läuft und eine Entscheidung notwendig wird. 

Somit sind wir jetzt beim Knackpunkt der Geschichte: Entscheidungsbedarf. Ein Projektleiter, der seine Standardpräsentation mit der offenen Fragestellung: "So, hier habe ich ein Problem, was soll ich tun?" beendet, wird zu recht aus dem Meetingraum, aus dem Unternehmen und zum Teufel gejagt. Auf dieser Basis kann kein Mensch eine fundierte Entscheidung treffen. Die Aufarbeitung und Darstellung des Entscheidungsbedarfs ist enorm wichtig, um den Lenkungskreis zu einer sinnvollen Entscheidung lenken zu können. Dazu hat sich folgender Aufbau bewährt:

• Ausgangssituation (Wo stehen wir)
• Problemstellung/Risiko (Was ist unerwartetes passiert?)
• Lösungsvorschlag (Was ist die Empfehlung des Projektleiters? Was kostet das an Zeit und Geld?)

Der Lösungsvorschlag sollte bei hoher Komplexität noch in Alternativen aufgesplittet werden - um den Entscheider nicht zu überfallen sind 3 Alternativen meistens ausreichend. Ebenfalls zu den Alternativen gehren dann Pro- und Contra- Betrachtungen. Bei den Alternativen sollte der Projektleiter auch wiederum die Vorarbeit leisten, eine der Alternativen zu empfehlen. Auf diese Art wird es dem Lenkungskreis in annehmbarer Zeit ermöglicht, eine fundierte Entscheidung zu treffen, welche nicht auf der grünen Wiese und auf Rätselraten begründet ist, sondern auf einem durch den Projektleiter gelenkten Entscheidungsprozess. 

Um die eingangs gestellte Frage nun noch explizit zu beantworten: Die Lenkung des Lenkungskreises erfolgt für operative Probleme durch den Projektleiter. 

Wozu benötigen wir dann überhaupt einen Lenkungskreis, wenn der Projektleiter durch seine Empfehlungen quasi selbst entscheidet? 

Ganz einfach: Wir benötigen den Lenkungskreis für strategische Fragestellungen, z.B. ob das Projekt weitergeführt werden soll, ob es weiterhin zur Unternehmens- und Projektportfoliostrategie passt. ob weitere Ressourcen zur Verfügung gestellt werden sollen etc. Hier wird der Lenkungskreis durch die Unternehmensstrategie und -Vision geleitet, die dem Projektleiter in der Regel nicht oder nur zu geringen Teilen bekannt sind. 

Lenken Sie Ihren Lenkungskreis? Haben Sie weitere Hilfsmittel oder Methoden, um aktiv Entscheidungen herbeiführen zu können? Wie viele Personen haben Sie typischerweise in Ihren Lenkungskreisen und Projektteams? Lassen Sie es mich gerne 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.

Wo kommen die Projekte her? IT- Strategie Teil 3: IT- Roadmap entwickeln

In Teil 1 und Teil 2 habe ich einige Grundüberlegungen zu einzelnen Bereichen der IT- Strategie mit Ihnen geteilt - widmen wir uns nun dem Großen Ganzen der IT- Strategie.

Am Anfang steht das Ziel - haben wir keinen Hafen, den wir mit unserem Schiff ansteuern wollen, so werden wir auf offener See herumirren. Was ist das Ziel der IT- Strategie, abgesehen davon, dass wir IT- Strategen Arbeit geben und wahnsinnig wichtig klingende Strategiemeetings abhalten können? 

Eine Strategie ist ein Plan, um Ziele zu erreichen. Hier zeigt sich, warum die IT- Strategie der Unternehmensstrategie folgen muss: Sie wollen keine theoretisch schöne IT- Landschaft haben, um damit auf dem nächsten Kongress angeben zu können - Sie wollen eine funktionale IT - Landschaft haben, die Sie bei Ihren Unternehmenszielen optimal unterstützt. Sie wollen Ihre Prozesse digitalisieren, den Kundennutzen maximieren, die Shoppingerfahrung Ihrer Kunden verbessern oder neue Geschäftsfelder erobern. Daran muss die IT- Landschaft kontinuierlich ausgerichtet werden und somit Ihrer Geschäftsstrategie folgen. 

Das Ziel der IT Strategie ist somit ein Plan, um die Unternehmensziele im Hinblick auf die einzusetzenden IT- Systeme erreichen zu können. Die IT- Strategie alleine hilft da natürlich nicht viel, zusätzlich benötigen Sie noch weitere Strategien, z.B. eine Personalstrategie (welche Rollen benötige ich wann in meiner Organisation, um die Geschäftsziele zu erreichen?), eine Investitionsstrategie (Welchen Organisationsbereichen stelle ich wann wieviel Budget zur Verfügung?) und letztendlich eine Strategie für jeden einzelnen Organisationsbereich (Welchen Output muss der Bereich erstellen, um die Geschäftsstrategie zu erreichen?). Der Weg zur Entwicklung der einzelnen Strategien ist letztendlich zumindest methodisch derselbe, aber da dies hier ein Blog und kein Buch ist: Widmen wir uns der IT- Strategie.

Der Plan, welcher entwickelt werden soll, wird auch als Roadmap bzw. in diesem Fall als IT- Roadmap bezeichnet und könnte so aussehen:

Jeder einzelne Balken im Gantt- Diagramm ist ein Projekt und wird bei der konkreten Planung vom Projektleiter in einzelne Teilprojekte und Arbeitspakete aufgesplittet. Die IT- Roadmap ist somit aus Projektmanagementsicht ein Projektportfolio: Eine Sammlung von Projekten als permanente Aufgabe, denn das Portfolio muss regelmäßig überprüft und angepasst werden.

Wie kommen wir nun dazu, die Roadmap zu entwickeln? 

1. Bestandsaufnahme /Systematisieren

Zunächst müssen wir wissen, welche Systeme wir bereits im Einsatz haben, andernfalls können wir schwer entscheiden, was wir noch benötigen. Die groben Austauschbeziehungen zwischen den einzelnen Systemen zu kennen hilft ebenfalls enorm. Wer es gerne technisch mag, kann dafür zur Excel- Tabelle greifen, ich schlage eine grafische Darstellung vor. Zur Erstellung der Bestandsaufnahme sollen die Kollegen sämtlicher Unternehmensbereiche befragt werden. Das Ergebnis könnte so aussehen:

Anhand der Bestandsaufnahme wird erkannt, welches Schiff wir haben und wofür es ungefähr reichen könnte - stellen wir fest, dass wir ein Tretboot haben, so sollten wir uns damit nur auf einem ruhigen See bewegen, ein Ruderboot könnte für offenes Gewässer in Küstennähe reichen und ein Hochseedampfer kann wochenlang ohne Pause gefahrahrlos auf dem Meer schippern.

2. Top- Down: Gegenüberstellung mit der Unternehmensstrategie

Jetzt müssen wir wissen, wohin wir mit unserem Boot fahren wollen, also wohin sich das Unternehmen entwickeln möchte: Wollen wir mehr Kunden gewinnen? National oder International? Wollen wir unseren (Neu)Kunden einen besseren Service bieten? Wollen wir interne Prozesse für unsere Kollegen verbessern, verschlanken oder eine höhere Qualität durch eine verbesserte Zusammenarbeit zwischen einzelnen Abteilungen erreichen? Am Ende der Kette stehen die Fragen, ob die vorhandenen IT- Systeme für die jeweiligen Zwecke vorhanden sind, eingeführt werden müssen oder verbessert werden sollen/ müssen.

3. Bottom-Up: Operative Schwachstellensuche

Nicht nur die Strategie der Geschäftsführung ist relevant, sondern auch die täglichen Probleme der Sachbearbeiter. Ein vorhandenes System kann aus Sicht der Geschäftsführung seinen Dienst tun, in der täglichen Arbeit allerdings umständlich sein und für eine Menge Effizienzverlust sorgen. Daher sollten auch die Mitarbeiter bzw. Keyuser nach Verbesserungswünschen befragt werden - IT soll schließlich das gesamte Unternehmen unterstützen. Auch hier schließen sich die Fragen an, ob zur Verbesserung der operativen Prozesse (im Hinblick auf die gewünschten Unternehmensziele) vorhandene Systeme weiter genutzt werden können, verbessert werden sollen oder so verbrannt / kaputtgecustomized sind, sodass am besten ein neues System eingeführt werden soll. Im übertragenen Sinne fragen wir die Crew, wie sie den Zustand unseres Schiffes einschätzen, denn selbst wenn wir bei der Bestandsaufnahme festgestellt haben, dass wir einen Hochseedampfer haben, so sollten wir nicht ohne weiteres damit auf eine Antarktis- Expedition aufbrechen. Die Crew des Schiffes kann am besten einschätzen, wo weitere Schwachstellen liegen und ob unsere Expedition von Erfolg gekrönt sein könnte.

4. Konkurrenzanalyse: Blick nach außen

Die Konkurrenz schläft nicht - selbst wenn wir "nur" unsere Marktanteile beibehalten wollen, müssen wir unsere Systeme regelmäßig anpassen. Daher lohnt sich die Frage nach der Standortbestimmung im Konkurrenzmarkt, nicht nur aus Gesamtunternehmenssicht, sondern auch im Hinblick auf die verwendeten IT- Systeme: Welche Shoptechnologie nutzen unsere Konkurrenten, sind automatische Pakettrackingfunktionen sauber angebunden? Hat die Konkurrenz ein CRM, werden von dort aus regelmäßig Marketingkampagnen an die Kunden gestartet? Das alles kann man recht einfach ohne die Gefahr der Betriebsspionage durch Testkäufe herausfinden. Strapazieren wir das Schifffahrt- Beispiel noch ein wenig: Welchen Seeweg benutzen andere Schiffe? Können wir dieselben Wege nutzen oder wollen wir das Risiko eingehen, neue Wege zu erkunden? 

5. Sonstige Methoden

Die bisher dargestellten Methoden sollte ein recht klares Bild ergeben, welche IT- Systeme im Unternehmen vorhanden sind und was noch fehlt, um in Zukunft weiterhin erfolgreich sein zu können und die Unternehmensstrategie umzusetzen. Es existieren noch eine Reihe weiterer Konzepte, welche zur Abrundung des Gesamtbildes verwendet werden können:

• Lebenszykluskonzept
• Auch Technologie hat einen Lebenszyklus (Entwicklung, Einführung, Wachstum, Reife, Rückgang, Abschaffung). Die identifizierten Systeme können anhand ihres Fortschritts im Lebenszyklus beschrieben werden, um Handlungsoptionen abzuleiten
• Hierbei werden die jeweiligen Systeme lediglich anhand einer starren zeitlichen Beurteilungsdimension bewertet, ein konkreter Bezug zu individuellen Unternehmenszielen oder aktuellen Schwachpunkten fehlt leider
• BCG- Matrix
• eine angepasste BCG- Matrix liefert Normstrategien zum Umgang mit den jeweiligen Systemen:

• Mit dem Ergebnis, 4 Normstrategien entwickelt zu haben, ist der geneigte Projektmanager ja bereits bei der Stakeholderanalyse glücklich. Die angepasste BCG- Matrix stellt zumindest einen Ausgangspunkt dar, um bei Bedarf in einem weiteren Schritt dann individuelle Strategien für das jeweilige IT- System entwickeln zu können
• SWOT- Analyse
• Auch die SWOT- Analyse kann auf Fragestellungen betreffend der IT- Strategie angewendet werden

Planen Sie Ihre IT- Strategie systematisch anhand einer Roadmap? Welche Methoden wenden Sie dazu an? Welche Methoden würden Sie gerne einmal ausprobieren? Welchen Schiffstyp würden Sie für welchen Zweck nutzen? Lassen Sie es mich in Ihrem Kommentar wissen.

Wo kommen die Projekte her? IT- Strategie Teil 2: Monolithen vs. Best of Breed

Eine grundlegende Frage der IT- Systemarchitektur, die zu Beginn eines IT- Strategieprozesses auf strategischer Ebene oder zumindest im Verlauf der Entwicklung einer IT- Strategie mit dem Feedback aus allen Unternehmensebenen geklärt werden sollte, ist: Bauen wir einen Monolithen oder setzen wir auf eine Best of Breed- Systemarchitektur?

Eine monolithische Systemarchitektur bedeutet, dass EIN Systemanbieter DAS führende System zur Verfügung stellt. Genau wie ein Monolith aus einem Stück einsam in der Landschaft steht, so steht dieses führende System als allmächtiges Bauwerk unantastbar und weitestgehend unzerstörbar in der IT- Landschaft Ihres Unternehmens. Beworben wird eine solche Architektur von den Anbietern mit "Alles aus einer Hand" oder "Keine Schnittstellenprobleme mehr". Der Monolith ist der Supermarkt der IT- Landschaft: Sie kaufen Ihr Fleisch, Ihren Käse, Ihre Süßigkeiten, Ihre Putzmittel und Getränke alle im selben Laden. 

Das ist eigentlich eine praktische Sache, solange Sie dem Anbieter vertrauen. Sie müssen sich um wenig "Drumherum" kümmern, bei Problemen können Sie immer dieselbe Nummer anrufen und die Consultants Ihres Systemanbieters kennen mit der Zeit Ihr Unternehmen und Ihre Wünsche sehr gut. 

Allerdings existieren natürlich wie bei Allem im Leben Nachteile: Ihr Supermarkt kann zweifelsohne nicht sein gesamtes Sortiment in einer derart hohen bzw. an Ihre individuellen Wünsche angepassten Qualität anbieten, wie ein Metzger sein Fleisch anbietet und ein Feinkostspezialist seine handgemachten Köstlichkeiten. Das Sortiment eines Supermarktes ist das mit Großlieferanten verhandelte Standardpaket: Alles für Ihren täglichen Bedarf ist vorhanden, einige Produkte haben eine gute Qualität, andere eher weniger. Manche Produkte bekommen Sie zu einem fairen Preis, andere sind  überteuert - in Ihrer Wahrnehmung des Gesamtwarenkorbs zählt jedoch nur der Durchschnitt. 

So sind die heutigen monolithischen Systemanbieter wie man so schön sagt "historisch gewachsen". In vielen Fällen haben sie als Anbieter eines Enterprise-Resource-Planning (ERP) Systems begonnen. So ein ERP steht traditionell in dem Mittelpunkt einer IT- Landschaft und hat notwendigerweise viele Schnittstellen zu den umliegenden Systemen. Schnittstellen sind immer problematisch - egal, was Ihnen die Anbieter sagen - daher ist es für den ERP-Anbieter lohnenswert, sich die umliegenden Systeme einzukaufen und sie unter seinem eigenen Namen weiter zu entwickeln - so bekommt er die Schnittstellen besser unter Kontrolle und ein größeres Stück vom Kuchen, weil er Ihrem Unternehmen mehr Lizenzgebühren, mehr Beratungsdienstleistung und mehr Customizing verkaufen kann. Einen Monolithen bekommen Sie zudem nicht mehr so leicht abgeschafft, das sichert dem Anbieter Ihre Aufträge auch in der Zukunft.

Die Vor- und Nachteile der monolithischen Systemarchitektur lassen sich gut mit folgender Fragestellung zusammenfassen: Ist die eine Hand, aus der Sie Ihre Systeme bekommen, eine treuumsorgende Hand? Oder presst diese Hand Ihnen die Luft aus den Lungen?

Im Gegensatz zur monolithischen Systemarchitektur steht die Best of Breed Architektur: Damit ist gemeint, dass Sie viele verschiedene, hochspezialisierte kleine Systeme in Ihr Unternehmen integrieren und miteinander vernetzen. Um bei dem Beispiel zu bleiben: Sie kaufen Ihr Fleisch beim Metzger, fahren danach zum Wochenmarkt um Gemüse zu kaufen, dann in den Getränkemarkt für die Getränke. Die Best of Breed Architektur ist Ihr Speedboot im Gegensatz zum Ozeanliner des Monolithen: Sie ist wendig, schnell und Sie können zügiger einen Richtungswechsel einleiten, falls Sie merken, dass Sie in die falsche Richtung gebrettert sind. 

Das hat den Vorteil, dass sie die jeweiligen Waren in derjenigen Qualität bekommen können, in der Sie sie benötigen (bzw. in der Sie auf die Wünsche Ihrer Kunden eingehen möchten, denn wir betreiben IT ja nicht zum Selbstzweck :-)). Sie kaufen also nicht wie beim monolithischen Ansatz das eine Kundenportal, welches Ihr ERP- Anbieter nebenbei mit anbietet, sondern sie entscheiden sich unabhängig für dasjenige spezialisierte Kundenportal, welches Sie jetzt und in der planbaren Zukunft benötigen. 

Diese Spezialisierung hat natürlich ebenfalls Nachteile: Zunächst sollten Sie Ihre Anforderungen definieren, die Anbieter suchen, finden und auswählen. 

Ihre Fahrten zu den spezialisierten Anbietern kosten Zeit und Mühe. Diese Fahrten sind in diesem Fall die zu fürchtenden Schnittstellen. Sie müssen die Schnittstellen konfigurieren (lassen), hinsichtlich der zu transferierenden Daten und  prozessbezogen. Auch wenn die Anbieter "Standardschnittstellen" anbieten, so müssen diese mit einiger Mühe aufeinander abgestimmt und vor Allem getestet werden. 

Die Schnittstellenproblematik können Sie mit der Einführung einer Middleware oder eines Enterprise Service Bus mindern. Die Arbeit der Vermittlung zwischen den verschiedenen Systemanbietern, das Monitoring und die fortlaufende Verbesserung der Systeme und Schnittstellen verbleibt in der Regel in Ihrem Unternehmen und verursacht Ihnen mehr Arbeit im Gegensatz zur monolithischen Systemarchitektur.

Die passende Fragestellung zur Best of Breed Architektur ist: Möchten oder müssen Sie Wettbewerbsvorteile durch eine stakt individualisierte Systemlandschaft erreichen und sind Sie bereit, dazu interne Ressourcen vorzuhalten?

Beide Architekturen haben also Vor- und Nachteile - es bleibt die Frage: Welche der beiden Bauweisen soll ich anwenden?

Diese Frage kann leider nicht pauschal beantwortet werden und ist besonders von Ihrer Unternehmensstrategie und Ihrer Marktsituation abhängig. Auch in meinem vorherigen Blog zur IT- Strategie habe ich es geschrieben, und weil es so wichtig ist wiederhole ich es hier: Die IT- Strategie ist abhängig von der Geschäftsstrategie und muss dieser zwingend folgen, nicht vorauseilen. 

Somit kann ich Ihnen lediglich managementtauglich die folgenden exemplarischen Entscheidungsdimensionen an die Hand geben:

Welche der beiden Bauweisen wenden Sie an? Welche Entscheidungsdimensionen sind bei Ihnen ausschlaggebend? Kaufen Sie Ihre Lebensmittel im Supermarkt oder beim Fachmann? Lassen Sie es mich in Ihrem Kommentar wissen.