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.

Wo kommen die Projekte her? IT- Strategie Teil 1: Die Cloud

 nachdem ich mich in den vergangenen Beiträgen um Techniken im und ums Projektmanagement gewidmet habe, möchte ich mit diesem Beitrag den Fokus etwas erweitern: Machen wir uns jetzt auf zu einer quasi-esoterischen Suche nach dem Ursprung von IT- Projekten. 

Alles beginnt mit einer Vision - starkes Statement, daher erscheint es hier auch fett gedruckt. Was ist eine Vision? Im historisch- religiösen Kontext eine Eingebung oder eine außerordentliche Zukunftserfahrung, in unserer sachlich orientierten Gegenwart oftmals ein Traum, aus dem man gestresst aufwacht: "Mist, ich muss unbedingt noch Tabelle XY in die Präsentation Z bis morgen früh einarbeiten". Im Strategiekontext, um den es hier nebenbei ja auch gehen soll, handelt es sich um eine Planung in einem Zeitraum für ungefähr die nächsten 5 Jahre. 

Die nächsten 5 Jahre sind natürlich sehr schwer zu planen - daher ist die berühmt- berüchtigte Frage in Vorstellungsgesprächen "Wo sehen Sie sich in 5 Jahren" ja auch so gemein. Versuchen wir uns stattdessen an der verhältnismäßig einfacheren Aufgabe, nur 3 Jahre in die Zukunft zu planen und nennen diesen Zeitraum Strategie - das hört sich dann auch schonmal weniger abstrakt und etwas wissenschaftlicher an. 

Jetzt wissen wir, in welchem Zeitraum wir planen müssen - aber was soll im Rahmen einer IT- Strategie geplant werden? Die generelle Antwort ist leicht, die konkrete Ausarbeitung dann eher das Problem: Wir planen im Rahmen einer IT- Strategie hauptsächlich eine zukünftige Systemlandschaft, die unseren Anforderungen zur Erfüllung der zukünftigen Kundenbedürfnisse genügt. Die IT- Strategie ist somit untergeordnet der Unternehmensstrategie (Welche Kundengruppen und welche Geschäftsfelder wollen wir in Zukunft mit welchen Produkten bearbeiten?) und hat Auswirkungen auf die Hardwarelandschaft, auf die Personalplanung und -Schulung sowie auf die Budgetplanung.

So ist das korrekte Vorgehen, und alleine darüber werden mehr oder weniger gehaltvolle Bücher geschrieben. Das ist zum Einstieg in dieses Thema im Rahmen eines Blogs allerdings zu viel und eine ziemlich harte Kost, daher nehmen wir uns zunächst mal diejenige Fragestellung vor, die fälschlicherweise gemeinhin als IT- Strategie verstanden wird:

"Wann gehen wir in die Cloud?"

Um diese in meinen Augen vergleichsweise unspannende Frage zu beantworten, gucken wir uns mal an was "die" Cloud ist bzw. was die Alternativen sind:

Vor Urzeiten, als die Dinosaurier auf der Erde wandelten, hatten Unternehmen ihre IT- Infrastruktur auf eigenen Servern im Haus - das nennen wir "on Prem" und das ist exakt das Gegenteil "der" Cloud. On Prem bedeutet: Das Unternehmen muss einen oder mehrere Serverräume zur Verfügung stellen, diese entsprechend feuersicher einrichten & kühlen, die Hardware inkl. Sicherheitsreserven beschaffen (lassen), einen eigenen Hardware- Support vorhalten etc. Kurz gesagt: Sie haben ein eigenes Rechenzentrum. Dadurch entstehen diverse Kosten, sämtliche Daten und Programme befinden sich in den Händen Ihres Unternehmens. 

Wer hier interne Kosten sparen möchte, kann auf ein Hosting zurückgreifen. Das Hosting kann man als Einstiegsdroge in die Welt der Cloud bezeichnen. Bei einem reinen Hosting wird die unternehmenseigene Software ganz oder teilweise auf externen Servern installiert, das Unternehmen greift darauf aus der Ferne zu. Beim reinen Hosting stellt der Hosting -Provider "nur" die Hardware, also Speicherplatz und Rechenleistung zur Verfügung, den Support, Installation, etc. übernimmt weiterhin das eigene Unternehmen. Das Hosting spart zunächst nur interne Kosten - ob unterm Strich tatsächlich gespart wird hängt dann vom konkreten Angebot des Providers ab. Hosting Provider können natürlich Synergieeffekte durch den Betrieb von großen Serverräumen erzielen, zusätzlich können dem einzelnen Unternehmen leichter zusätzliche Kapazitäten zur Verfügung gestellt werden. Das Hosting und auch die Cloud stellen nüchtern betrachtet ein Outsourcing dar - allerdings ist dieser Begriff natürlich weniger modern.

Der nächste Schritt in der digitalen Drogenkarriere der IT- Welt ist die Multicloud - ein sehr cooler Begriff, da möchte man ja schon fast kaufen ohne nach dem genauen Inhalt zu fragen. Ich versuche mich trotzdem an einer Erklärung: Die meisten Software-Anbieter platzieren ihre Lösungen mittlerweile entweder als on- Prem- Installation oder als Software as a Service (SaaS).  Letzteres bedeutet, dass der Anbieter nicht nur das Hosting übernimmt, sondern auch noch seine Software auf einem gehosteten Server bereitstellt. Der Zugriff erfolgt dann für den Kunden natürlich online. Der Anbieter stellt meist noch die Wartung in Form von regelmäßigen Updates sicher - das ist für den Anbieter praktisch, weil er Patches etc. so zentral verteilen kann und für den Kunden, weil er sich nicht selber um Updates kümmern muss. Bei der SaaS schrumpft die interne IT- Abteilung im Vergleich zu den vorherigen Varianten weiter. Die eine Cloudlösung muss natürlich mit den anderen Softwarekomponenten im Unternehmen verbunden werden - befindet sich mindestens eine weitere Komponente in einer Cloud von einem anderen Anbieter, so haben wir eine Multicloud. Schwierig ist diese Architektur häufig dann, wenn es darum geht, Schnittstellen zwischen einzelnen Anwendungen zu implementieren oder zu erneuern - bei der Multicloudvariante müssen dann verschiedene Unternehmen mit unterschiedlichen Firewalls und Zugangsmodalitäten Zugriffe einrichten und sich abstimmen. 

Die letzte Stufe auf der Treppe der Cloudarchitektur ist dann "die" Cloud: Alle Anwendungen eines Unternehmens befinden sich in derselben Cloud. Der Betreiber stellt in der Regel die entsprechende Hardware zur Verfügung, dazu die Frameworks, die Ihre Anwendungen benötigen und in vielen Fällen eine entsprechende Entwicklungs- und Schnittstellenarchitektur. Die Anbieter versuchen dazu immer mehr Hersteller von Software auf ihre Cloudplattform zu bekommen, sodass sie entsprechende Standardschnittstellen zur Verfügung stellen können. Die Idee dahinter ist, dass Sie als Cloudkunde in Zukunft  einzelne Softwarelösungen modulartig bei ihrem Cloudanbieter dazu buchen können und diese direkt mit ihren restlichen Systemkomponenten sprechen können. Aus Wettbewerbsgründen zweifele ich mal an, ob dieses Ziel so überhaupt erreicht werden kann und soll - bis dahin werden Sie jedenfalls eine wachsende Anzahl von Anwendungen im Standard automatisch miteinander vernetzen  können, sie wären jedoch (noch) auf diejenige Auswahl angewiesen, welche Ihr Anbieter Ihnen vorgibt (es sei denn, sie fahren eine Multicloudstrategie mit den entsprechenden Anbietern). Bei dieser Variante haben Sie unternehmensintern den geringsten Personalbedarf für Ihre IT- Abteilung.

Die Darstellung der Alternativen soll folgendes verdeutlichen: Ich sehe die Cloudstrategie zwar als Teil der IT- Strategie, jedoch als (teil)Ergebnis der IT- Strategie und nicht als oberste Fragestellung. In  der Reihenfolge der Fragestellungen sollten wir uns zunächst nach der Geschäftsstrategie fragen, dann überlegen, mit welchen IT- Systemen wir diese Strategie zusammenhängend und ineinandergreifend am besten realisieren können und uns dann am Ende fragen, ob wir das jeweilige System unter Abwägung von Kosten- Nutzen- Gesichtspunkten on Prem oder in der Cloud nutzen wollen. 

Aber was ist denn jetzt die beste Variante? Tja, wenn es "Die" beste Lösung gäbe, dann hätte jedes Unternehmen diese eine Lösung und die IT- Welt wäre um einiges einfacher. Folglich besteht die Kunst darin, die beste Lösung individuell zu finden. Dabei mögen die folgenden Kriterien helfen:

Als Vorteil der (Multi)Cloud kann klar die Skalierbarkeit genannt werden - mehr oder weniger Kapazitäten können einfacher hinzugebucht werden, als dass Sie Server bei einer On Prem- Landschaft hinzukaufen können. Dies wirkt sich natürlich auf die Kosten aus: Viele Anbieter berechnen die Cloudkosten nach verursachtem Traffic. Möglicherweise können Sie die Kosten für Ihre benötigte Rechenleistung bei der erstmaligen Umstellung Ihres eigenen Rechenzentrums in eine Cloud jedoch schwer einschätzen. Die bessere Skalierbarkeit der Cloud dürfte heutzutage das treibende Argument sein: Durch die fortschreitende Digitalisierung entstehen in kürzeren Zeiträumen immer mehr Datenmengen - Ihr Rechenzentrum müsste demnach stetig wachen, um diese Datenmengen abbilden zu können. Hier bestehen natürliche Grenzen, denn Sie wollen Ihre Firmengrundstücke mutmaßlich noch für andere Zwecke nutzen, als sie mit Serverräumen zuzupflastern.

Die Ausfallsicherheit wird bei der Cloudlösung vom Anbieter zugesichert und vertraglich festgehalten - wenn es einen Ausfall gibt, dann müssen (bzw. können) Sie in Ihrem Unternehmen nicht mit Hochdruck dran arbeiten, die Services wieder ans Laufen zu bekommen - darum muss sich der Cloudanbieter kümmern. Den Schaden haben Sie im Endeffekt bei einem Ausfall trotzdem, wie beispielsweise der Ausfall der Amazon AWS- Cloud vor Kurzem gezeigt hat. Es kann zu einem sehr zeit- und kostenaufwändigen Geduldsspiel ausarten, den Cloudanbieter im Schadensfall auf die vertraglich zugesicherte Ausfallsicherheit festzunageln. Um einem Vollausfall vorzubeugen müssten Sie Ihre Anwendungen in verschiedene Clouds auslagern (Multicloudstrategie) oder Ihre Anwendungen gleichzeitig in mehreren Clouds betreiben - dann allerdings entstehen wiederum höhere Kosten.

Hinsichtlich der Effizienz Ihrer IT- Abteilung scheint die Cloud auf den ersten Blick gegenüber der On Prem - Variante überlegen: Sie müssen keine eigene IT- Abteilung inkl. Sicherheitsressourcen für den Störungsfall vorhalten, darum kümmert sich der Cloud- Anbieter. Der kann in der Theorie effizienter arbeiten, weil er Skaleneffekte erzielen könnte: Weniger Mitarbeiter können sich jeweils um die aktuellen Brennpunkte kümmern. Ob dies in der Praxis so eintritt kann ich nicht beurteilen, da ich nie bei einem Cloudanbieter gearbeitet habe - ich würde allerdings vermuten, dass auch der Cloudanbieter eher zu wenig als zu viele Mitarbeiter bezahlen möchte und dass er seine Überlaufkapazitäten daher gerne so gering wie möglich halten mag - dies würde dann bedeuten, dass auch beim Cloudanbieter im Falle eines Teil- und erst recht im Falle eines Vollausfalls zu wenig Kapazitäten zur Verfügung stünden, um eine schnelle Linderung zu schaffen - genauso wie es bei Ihrer internen IT- Abteilung wäre, nur mit dem Unterschied, dass Sie durch das Outsourcing davon dann wenigstens nichts mehr mitbekommen.

Ein wichtiger Aspekt ist natürlich noch die Datensicherheit: Hier hält sich hartnäckig das Gerücht, dass Ihre Daten sicherer wären, wenn Sie auf Ihren eigenen Servern in Ihrem eigenen Rechenzentrum im eigenen Keller lagern anstatt in irgendeiner Cloud. Ich kann Sie gerne beruhigen: Heutzutage sind Ihre Daten nirgendwo mehr sicher. Sofern Sie Ihre Systeme an mindestens einer Stelle ans Internet angebunden haben sollten, so können Ihre Daten, wo auch immer sie lagern mögen, von außerhalb manipuliert oder gestohlen werden. Nichtsdestotrotz müssen Sie natürlich auf DSGVO- Konformität, TOMs, Verschwiegenheitsklauseln etc. bei Verträgen mit Ihren Cloudanbietern achten - aber das müssen Sie ja auch intern in Ihrem Unternehmen tun.

Abschließend möchte ich noch auf die goldene Regel der Cloud Architektur hinweisen: 

Was in der Cloud ist, bleibt in der Cloud. 

Das bedeutet, dass es schwerer sein soll, seine Daten wieder aus der Cloud zurück in eine On- Prem - Architektur zu überführen als umgekehrt. Wenn Sie in die Cloud gehen möchten, helfen Ihnen die Anbieter bereitwillig - bei einem Wunsch, die Cloud zu verlassen soll man angeblich weniger Hilfe bekommen. Ihr Dealer Ihres Vertrauens beliefert Sie jederzeit gerne mit dem Stoff, aus dem die Träume sind, wenn Sie dann allerdings nicht mehr beliefert werden wollen, so müssen Sie die Entwöhnung aus eigener Kraft oder mit Hilfestellung von anderer Seite vornehmen.

Welchen Stellenwert bemessen Sie der Cloudstrategie im Rahmen Ihrer IT- Strategie zu? Welche Erfahrung haben Sie mit dem Wechsel in die Cloud und insbesondere von der Cloud auf lokale Server zurück? Fallen Ihnen weitere wichtige Kriterien zur Cloudstrategie ein?

Das Problem mit den Socken: Wie definieren wir sinnvoll Anforderungen?

Komm, wir spielen Lastenheft - Pflichtenheft: Ein Spiel, bei dem es nur Verlierer gibt - das Spiel für alle diejenigen, die eigentlich Romanautoren werden wollten, bei denen es aber doch nur zum Projektmanager gereicht hat. Hier kann sich der klassische Projektmanager noch voll austoben, seine Gedanken in Prosaform darlegen und das tolle ist ja: Je mehr wir als Auftraggeber schreiben, desto besser denken wir sind unsere Anforderungen dargelegt und desto mehr können wir auch in Form eines Pflichtenheftes vom Auftragnehmer erwarten. Trotzdem bemerken wir oft im laufenden Projekt, dass Auftraggeber und Auftragnehmer sich in wesentlichen Punkten nicht verstanden haben - das Projekt wird teurer oder verzögert sich. 

Ein Lastenheft enthält die Anforderungen des Auftraggebers. Das ist per se eine gute Sache: Wenn ich etwas tolles zu Weihnachten bekommen möchte, sollte ich eine Wunschliste schreiben, andernfalls kann ich mich nicht beschweren, wenn wieder nur Socken unter dem Christbaum liegen. Wenn ich als Stichwort "Auto" auf meinen Wunschzettel schreibe, kann dies von den geneigten Empfängern sowohl als Spielzeugauto als auch als Kleinwagen aufgefasst werden - da ist es also hilfreich wenn ich spezifiziere, dass ich schon gerne den neuen Porsche Taycan GTS in der Farbe Schwarz mit 598 PS und sämtlicher Sonderausstattung hätte. Dafür zeigt mir dann jeder in meiner Verwandtschaft einen Vogel und zur Strafe werde ich abermals mit Socken beschenkt - die Anforderung wurde zwar klar definiert, aber leider nicht auf Machbarkeit hin überprüft.

Im agilen Projektmanagement sagen wir uns von den Lastenheftromanen los und arbeiten stattdessen mit kurzen Userstories als Anforderungsbasis - eine Wunschliste aus Sicht des Kunden oder zumindest davon, was wir meinen, was der Kunde sich wünscht. Somit schreibe also ich als Product Owner  eine Wunschliste für jemand anderen, also etwa so: Ich habe vor kurzem mal mit meiner Frau gesprochen, sie hat im Winter oft kalte Füße und findet Socken generell ganz praktisch - also denke ich, dass meine Frau sich Socken zu Weihnachten wünscht. Schon ist die Userstory komplett.  

Die Userstory wird in Tasks aufgeteilt, also in Aufgaben umgewandelte Anforderungen - aber wie können wir die sinnvoll und objektiv priorisieren? In der Praxis kann nicht nach jedem Sprint ein lauffähiges Produkt entstehen und beim fortlaufenden Entwickeln von Verbesserungen entsteht regelmäßig ein höherer Testaufwand dieser Verbesserungen, als wenn Verbesserungen systematisch implementiert werden würden. 

Am Anfang eines Projektes stehen immer Anforderungen - darum geht es im Kern. Bleiben wir beim Bild der weihnachtlichen Wunschliste, die die meisten von uns aus Kindertagen kennen dürften. Wie bauen wir unsere Wunschliste am besten auf? 

Als Kinder haben wir die Wunschliste auf einen Zettel geschrieben, in Stichpunkten und evtl. mit Erläuterungen. Jetzt sind wir erwachsen, im Büro und können Excel bedienen. Zusätzlich wirkt es irgendwie klarer strukturiert, wenn wir in der ersten Spalte eine fortlaufende Nummer hinzufügen, das mag der Chef halt und wir können in nachfolgenden Dokumenten einfach auf die Anforderungsnummer verweisen, damit der Leser dann halt noch ein weiteres Dokument suchen muss und so die Gefahr verringert ist, dass er am Arbeitsplatz einschläft. 

Die aussagekräftige Gestaltung der Erläuterungsspalte ist gar nicht so leicht - überhaupt kann ich die ja eigentlich leer lassen, ich weiß ja, was gemeint ist, oder? Das Bild der Wunschliste zeigt sehr gut, dass nicht der Absender wissen muss, was gemeint ist, sondern dass die Empfänger es verstehen müssen - und das ist erfahrungsgemäß wesentlich schwieriger. Machen wir es uns an dieser Stelle leicht und verwenden wir ein Konzept zur Zieldefinition -SMART. Ziele müssen 

• Spezifisch
• Messbar
• Erreichbar
• Realistisch und
• Terminiert

sein, dann funktionieren sie als Leitplanken. Ziele sind nun nicht gleich Anforderungen, aber aus Anforderungen resultieren Ziele. Daher schadet es nicht, bereits die Anforderungen zum Verständnis in einem breiteren Empfängerkreis SMART zu definieren. AROMA ginge natürlich ebenfalls.

So, an dieser Stelle haben wir eine tolle Liste mit Anforderungen, bestehend aus 3 Spalten. Welche Anforderung realisieren wir nun zuerst? Das wissen wir noch nicht. Wir finden im Excel allerdings noch eine Menge leerer Spalten vor, also: Füllen wir eine davon. Nennen wir diese Spalte "Priorität" und legen wir eine Skala fest. 1 bis 5, Schulnoten, 1 bis 10. Gehen wir unsere Anforderungen durch um sie derart zu priorisieren, so stellen wir fest, dass natürlich alle Anforderungen wichtig sind- andernfalls hätten wir uns ja auch nicht die Mühe gemacht, sie nieder zu schreiben. Wir machen ja schließlich nichts unwichtiges. Schlimmer wird das Problem noch, wenn wir die Anforderungsliste sinnvollerweise in einem bereichsübergreifenden Team durchgehen - da findet jeder etwas anderes wichtig und keiner will seine Anforderungen hinter denjenigen der Anderen zurückstellen. Die Lösung: Wir benennen die Spalte "Priorität" um in "Rangfolge" - eine Rangfolge ist eindeutig, Prioritäten sind das nicht - mit anderen Worten: Ich kann eine unendliche Anzahl von Aufgaben auf der maximalen Priorität haben, nur eine Rangfolge gibt eine eindeutige Abarbeitungsreihenfolge wieder. Unsere Anforderungsliste sieht nun so aus: 

Wir bekommen das Projektteam dann irgendwie dazu, sich auf eine gemeinsame Rangfolge zu einigen und können glücklich sein?

Nein, leider noch nicht. Wer bis hierhin durchgehalten hat, kann nun schonmal eine tolle Anforderungsliste mit nur 4 Spalten erstellen, und die hilft wirklich enorm - der Clou kommt jedoch der Spannungskurve wegen natürlich am Ende: Die Rangfolge der Anforderungen stellt leider nur in den seltensten Fällen eine sinnvolle Abarbeitungsreihenfolge dar, insbesondere in komplexen Systemen. Auf die Abarbeitungsreihenfolge sollten wir jedoch bestenfalls bei der Anforderungsdefinition bereits achten, um dem nachfolgenden Realisierungsprojekt einen geschmeidigen Verlauf zu ermöglichen.

Nehmen wir ein Beispiel aus der Automobilindustrie: Das Team hat per Kundenbefragung herausgefunden, dass Reifen das wichtigste am Auto sind, die haben ja den Kontakt zur Straße - also Rang 1. Dicht gefolgt vom Motor, der muss kraftvoll sein und einen ordentlichen Sound haben - Rang 2. Also legen wir besonderes Augenmerk auf den Motor und lassen uns gute Reifen zuliefern - das können wir so nur leider nicht zusammen testen, dafür bräuchten wir mindestens noch die Karosserie - die ist allerdings aus Kundensicht Standard und vollkommen unsexy, also hat sie den letzten Platz bei der Rangfolge erhalten. Im schlimmsten Fall merken wir einen Konstruktionsfehler im Zusammenspiel der Komponenten unseres Autos dadurch erst kurz vor Fertigstellung. Das Beispiel mit dem Auto soll anschaulich sein - bei IT- Projekten ist es wesentlich schwieriger, eine sinnvolle Reihenfolge für Realisierungsschritte zu finden. 

Die absolut beste Lösung, welche ich für dieses Problem gefunden habe ist, anstatt eines langatmig ausformulierten Lastenheftes, einer vermeintlich kundenfreundlichen Userstory oder einer langweiligen Excel- Liste einen anschaulichen Sollprozess zu malen. In den meisten IT- Projekten kann der Sollprozess alle davor genannten Schritte ersetzen, auch wenn die beschriebene Anforderungsliste ein tolles Dokument zur zusätzlichen Spezifizierung der Anforderungen darstellt. Bei der Erstellung physischer Projektergebnisse wäre der Sollprozess nachgelagert der Anforderungsliste zu erstellen. 

Der Sollprozess gibt anschaulich eine praktikable Realisierungsreihenfolge vor: Als erstes werden diejenigen (System) Aufgaben realisiert, welche vorne im Sollprozess liegen - die können bereits getestet werden und liefern somit früh diejenigen Testgegenstände, welche auch nach Realisierung weiterer Prozessschritte benötigt werden. Testfälle müssen somit nicht für jeden Schritt neu erstellt werden, stattdessen werden sie zum Test nach Realisierung weiterer (System) Komponenten weiterverwendet. Anhand des Sollprozesses kann somit früh und mit möglichst wenig Aufwand mit zielführenden Tests begonnen werden.

Beherzigen Sie diese Hinweise, so haben Sie als Projektmanager mehr Zeit für die wesentlichen Dinge, die unsere Berufung erlebnisreich machen, z.B. das Schreiben von meterlangen Romanen per E-Mail oder dem Erstellen von umfangreichen Excel- Tabellen, die niemand außer Ihnen selbst versteht. 

Welche Erfahrung haben Sie mit der Anforderungsdefinition und deren Abarbeitung in Projekten sammeln können? Werden Ihre Lastenhefte vom Empfänger verstanden und verstehen Sie die Pflichtenhefte Ihrer Auftragnehmer? Wünschen Sie sich Socken zu Weihnachten? 

Lassen Sie es mich in Ihrem Kommentar wissen.

Warum ist die Stakeholderanalyse unsinnig?

 

Ein klassischer Projektmanager führt vor Projektbeginn eine Stakeholderanalyse durch - so steht es geschrieben und so machen wir es. Halt- warum machen wir das genau? Die gängigen Definitionen der Stakeholderanalyse geben darauf Antwort - natürlich um die beteiligten Interessensgruppen zu identifizieren...

Aaah... Die Identifikation der Stakeholder kann also nur und ausschließlich erfolgen, indem wir eine Matrix zeichnen und als Zeilen- und Spaltenbeschriftungen dann optional "Interesse", "Einstellung zum Projekt",  "Einfluss" oder noch schlimmer "Macht" eintragen? Hat jemand mal versucht, hier "Wichtigkeit" und "Größe des Autos" abzutragen? Das wären zugegebenermaßen sehr unkonventionelle Beurteilungsdimensionen, allerdings sind die zur reinen Identifikation von Personen nicht weniger geeignet, ja sogar wesentlich bildhafter, oder? Hilfreiche Faustregel dazu: Wichtige Leute fahren dicke Autos und sind somit im Bereich "Hoch/Hoch" anzusiedeln, weniger wichtige Leute können ohne Sorge im Feld "Niedrig/Niedrig" einquartiert werden. 

Kommen wir zum Ernst der Lage zurück - die reine Identifikation von Stakeholdern ist ein kreativer Prozess, welcher auch im Rahmen der klassischen Stakeholderanalyse als Brainstorming abgehalten wird - optimalerweise natürlich im Kreis des Projektteams, denn damit so ein Brainstorming wirklich effizient ist, macht der Projektleiter das am besten nicht völlig alleine. Ich gehe sogar so weit zu behaupten, dass für das Brainstorming überhaupt keinerlei Beurteilungsdimensionen benötigt würden - das Projektteam hat an dieser Stelle erfahrungsgemäß die wichtigsten unternehmensinternen Stakeholder deutlich vor Augen, und der Endkunde wird sowieso prinzipiell fast nie als Stakeholder genannt (achte Sie mal drauf). Feertiig - Stakeholder identifiziert, diesmal ganz ohne Beurteilungsdimensionen oder halt anhand ihrer Automobile. Nun können wir stolz zum Projektauftraggeber rennen und uns unser Fleißkärtchen abholen - Stakeholderanalyse gewünscht, Stakeholderanalyse geliefert.

Ach nein, da war doch noch was... Weiterführende Definitionen der Stakeholderanalyse in der einschlägigen Fachliteratur suggerieren, dass die Stakeholder nicht nur identifiziert, sondern auch noch benachrichtigt oder sogar einbezogen werden müssen - es muss also Kommunikation erfolgen...

Aktionen fallen manchmal schwer, Kommunikation mindestens ebenso - daher macht die klassische Stakeholderanalyse es uns an dieser Stelle leicht und stellt uns Normstrategien zur Kommunikation zur Verfügung. Diese sind mehr oder weniger aussagekräftig betitelt mit: repressiv, diskursiv, partizipativ und restriktiv... Das liest sich jetzt sehr toll in der Fachliteratur, manch einer mag sogar klug genug sein, diese Wörter auswendig zu lernen - aber intuitiv verständlich sind sie nicht, oder? Die Normstrategien haben natürlich den Vorteil, dass ich mich auf etwas berufen kann, wenn die Kommunikation schief läuft - in diesem Fall dient die Stakeholderanalyse dann jedoch nur als geduldiger Sündenbock, nicht als wertvolles Managementinstrument. Sind die vier knapp umschriebenen Normstrategien überhaupt noch zeitgemäß, oder kann der geneigte Projektleiter es sogar wagen, die entsprechenden Stakeholder zu fragen, wie und in welcher Frequenz sie am liebsten individuell einbezogen oder informiert werden wollen?

Überhaupt ist das Vorgehen bis hier nicht wirklich rund, wenn wir einmal drüber nachdenken: Wir sammeln in einem Brainstorming alle Stakeholder, sortieren sie anhand irgendwelcher Kriterien in Felder ein und kommunizieren dann mit diesen Menschen gruppenweise gleich anhand von wohlklingenden Normstrategien, weil wir unterstellen, dass uns im kreativen Prozess natürlich keine Fehler unterlaufen und dass dieses Brainstorming zu 100% exakt ist? 

An dieser Stelle muss ich noch einen Exkurs zu der Beurteilungsdimension "Macht" sowie zur Erweiterung der Stakeholderanalyse auf mehr als vier Felder einführen:

Warum ist die Beurteilungsdimension "Macht" völlig kontraproduktiv? Die Stakeholderanalyse sollte vorzeigbar sein - ich halte es für eine tolle Idee, diese beim Kickoff im größeren Kreis und natürlich auch unter Anwesenheit des Lenkungskreises und des Projektauftraggebers zu zeigen. Der Lenkungskreis besteht der Erfahrung nach aus hochrangigen Unternehmensvertretern - und nun stellen Sie sich vor, der Lenkungskreis besteht aus 2 Personen: Vorstand Herr Dr. Dr. X, über 60 Jahre alt, fährt ein sehr dickes Auto zur Demonstration seiner Macht, hat die letzten 40 Jahre intensiv und hauptsächlich damit verbracht, Macht aufzubauen. Dann noch Frau Y, ebenfalls Vorstandsmitglied, Mitte 40, fachlich sehr stark und die treibende Kraft hinter ihrem Projekt. Weil Frau Y Ihnen als fachkundiger Ansprechpartner während der Initiierungs- und Planungsphase zur Verfügung stand, steht Frau Y bei Ihnen zwar genau wie Herr Dr. Dr. X im Hoch/Hoch- Feld der Stakeholderanalyse - aber halt 2 cm weiter oben als Herr Dr. Dr. X - mit anderen Worten: Sie haben Frau Y als 2 cm mächtiger eingeschätzt als Herrn Dr. Dr. X! Ich verspreche Ihnen, dass sie den Zeitplan für den restlichen Kickoff getrost vergessen können, weiterhin werden sie sehr bald degradiert oder müssen das Unternehmen verlassen - Herr Dr. Dr. X wird eine ausufernde Diskussion darüber führen, dass die Stakeholderanalyse falsch ist, höchstwahrscheinlich ohne offen zuzugeben, dass er gerne in der Machteinschätzung über Frau Y stehen würde.

Aus diesem Grund tuen Sie sich selbst den Gefallen und verwenden sie "Macht" generell nicht als Beurteilungsdimension - in diesem Beispiel wäre sogar wiederum alles gut gewesen, wenn sie die Größe des Autos als Kriterium verwendet hätten - Herr Dr. Dr. X fährt ja wie beschrieben ein dickes Auto, Frau Y macht sich daraus nichts und wählt öffentliche Verkehrsmittel, dafür weist sie auch direkt, kurz und freundlich darauf hin, wenn sie sich in der Stakeholderanalyse falsch eingruppiert sieht - und schon geht der Kickoff wie geplant weiter.

Der allgemeine Trend geht dahin, die 4- Felder- Matrix der Stakeholderanalyse zu erweitern, nach dem Motto: Mehr ist besser! Wenn wir uns schwer tun, eine Beurteilungsdimension nur mit "Hoch" oder "Niedrig" zu bewerten, dann führen wir doch einfach noch ein "Mittel" ein, oder wir verschlimmbessern die Skala weiter mit numerischen Ausprägungen - dann können wir direkt "1 bis 5" oder auch "1 bis 9" bewerten. Der Bewertungsprozess ist natürlich weiterhin ein Brainstorming, welches intuitiv abläuft und daher lediglich subjektive Einschätzungen liefert - diese werden nicht umso genauer, je weiter wir differenzieren bzw. je mehr Unterteilungen wir der zugrundeliegenden Skala hinzufügen. Mein wichtigster Kritikpunkt an diesem Vorgehen ist jedoch: Bei diesen Erweiterungen werden im Ergebnis nicht entsprechend mehr Normstrategien hinzugefügt - wenn das Ergebnis dieses vermeintlich  genaueren Vorgehens jedoch wiederum nur 4 Normstrategien sind, wofür sollen wir dann die Skala erweitern? 

Ich möchte Ihnen zum Abschluss gerne mein Vorgehen zu einer sinnvollen Stakeholderanalyse darstellen, welche einen praxisrelevanten Nutzen ohne viel Schnickschnack bietet:

1. Brainstorming im Kreis des bis zu diesem Zeitpunkt bekannten Projektteams
• Beim Projektstartworkshop. Die Beurteilungsdimensionen "Einfluss & Interesse" können zur Hilfestellung verwendet werden, sind aber nicht dringend notwendig. Der Projektleiter sollte darauf achten, dass der Endkunde und alle externen Dienstleister als Stakeholder genannt werden - die werden meistens vergessen.
• Beim Brainstorming sollte Zeitdruck hergestellt werden - nach der Vorstellung der Aufgabenstellung kann der Projektleiter dem Team 10 bis 15 Minuten Zeit geben, um alle wichtigen Stakeholder zu erfassen. Die Erfahrung zeigt, dass die Ergebnisse bei längeren Zeiträumen nicht besser werden. Falls der Zeitdruck für das Team zu groß wird und eine Blockade einsetzt, so kann der Zeitrahmen bei Bedarf verlängert werden.
2. Benachrichtigung bzw. Befragung der neu bekannt gewordenen Stakeholder
• Im schnellsten Fall mit einer kurzen Mail: "Sie wurden als wichtiger Interessensträger im Projekt XY identifiziert- möchten Sie aktiv am Projekt teilnehmen, einen Vertreter ins Projekt entsenden oder regelmäßig informiert werden? Gerne können wir auch ein individuelles Vorgehen vereinbaren". Geht auch als Massenmail, ist effizient und individuell - bye, bye Normstrategie.
3. Regelmäßige Überprüfung und Kommunikation zu neu identifizierten Stakeholdern
• Macht kein Mensch in dieser systematischen Form, gehört aber eigentlich dazu.

Welche Erfahrungen haben Sie mit der Stakeholderanalyse gesammelt? Halten Sie die klassische Stakeholderanalyse für nützlich? Wie viele Felder hat Ihre Stakeholderanalyse und welche Beurteilungsdimensionen verwenden Sie? Fahren Sie ein dickes Auto? 

Schreiben Sie Ihre Gedanken dazu gerne als Kommentar.