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.

Wo hört der Prozess auf, wo fängt das Projekt an?

Mein Beruf ist Projektmanager, als eine Art Hobby betriebe ich seit Jahren aktiv und begeistert Prozessmanagement. Daher weiß ich: Der Unterschied zwischen einem Prozess und einem Projekt ist in der Theorie schnell geklärt: Ein Prozess ist eine regelmäßig wiederkehrende Aufgabe, während ein Projekt per Definition ein einmaliges Vorhaben ist. Diese Abgrenzung funktioniert für Projektmanager unter folgender Bedingung: Jemand sagt mir, ich solle ein Projekt initiieren, also tue ich das - und habe folgerichtig ein Projekt. In einem strategischen Optimierungsprozess muss man sich hingegen fragen: Soll eine Veränderung als Prozessoptimierung durchgeführt werden oder als ein Projekt? 

Beginnen wir mit einem konkreten Beispiel: Produktentwicklung. Wir kennen den "Produktentwicklungsprozess" - und damit ist ja linguistisch schon einmal geklärt,  worum es sich handelt, oder nicht? Ein Unternehmen entwickelt fortlaufend neue Produkte, denken wir uns, sollte demnach Expertise darin haben und die Produktentwicklung sollte somit ein Regelprozess sein. Unsere Produktentwicklung könnte allerdings je nach Produkt in sehr langen Zyklen vom Entwurf bis zum finalen Test und zur Markteinführung ablaufen - und jedes Produkt wird ja nur einmal entwickelt - handelt es sich unter dieser Bedingung dann nicht vielleicht doch eher um ein Produktentwicklungsprojekt?

Im Gegensatz dazu wird ein CRM einmalig im Unternehmen eingeführt, es handelt sich somit klar um ein Einführungsprojekt - hier würde wohl niemand von einem Einführungsprozess sprechen? Allerdings kursieren viele gute und hilfreiche Schaubilder, welche den klassischen und agilen Projektmanagementprozess darstellen - und wie könnten wir Projektmanager uns in standardisierten Methoden zertifizieren lassen und Erfahrung damit sammeln, wenn das Projektmanagement nicht letztendlich selbst ein Prozess ist? Software hat im Unternehmen eine gewisse Lebensdauer, bis sie ersetzt werden muss - üblicherweise 3 bis 5 Jahre, aufgrund der fortschreitenden Digitalisierung munkelt man, dass sich die Zyklen weiter verkürzen. Also muss in ein paar Jahren das nächste CRM eingeführt werden - handelt es sich damit etwa um einen Einführungsprozess?

Fragen wir uns nach dem Ursprung und nach dem Ziel unseres Optimierungswunsches: 

in unserem Beispiel funktioniert der Produktentwicklungsprozess evtl. nicht zufriedenstellend, es kommt zu Informationsverlust an wichtigen Übergabeschnittstellen - beispielsweise von der Produktentwicklung im Labor zum Marketing. Dies soll optimiert werden, damit der Prozess effizienter läuft- wichtige Informationen sollen von der einen Abteilung an die Andere standardisiert übergeben werden. Machen wir daraus eine (kurze) Prozessoptimierung oder setzen wir ein Projekt mit dem vom Topmanagement gefürchteten großen Tamtam dafür auf? 

In diesem einfachen Beispiel würde ich es eine Prozessoptimierung nennen, in wenigen Meetings gemeinsam mit den beiden beteiligten Abteilungen den Istprozess aufnehmen (falls nicht bereits vorhanden), anschließend den Sollprozess definieren sowie die bei der Übergabe benötigten Daten und Datenformate. Sollten mehr Abteilungen beteiligt sein, der Datenaustausch Anpassungen an Datenbanken und Systemen erfordern und sollte bei dem Prozess in der Vergangenheit viel Geld verloren gegangen sein, so wäre es eine sinnvolle Alternative, den Prozess im Rahmen einen (kleinen) Projektes zu optimieren und einmalig innerhalb einen Projektes gemeinsam mit den beteiligten Abteilungen zu durchlaufen - nachdem die im Projekt durchgeführten Änderungen als Verbesserung validiert wurden, kann der Prozess dann erstmal in der Linie als Prozess weiterlaufen und benötigt hoffentlich die nächsten Jahre kein Verbesserungsprojekt mehr. Kleinere Prozessoptimierungen könnten im Rahmen eines regulären Prozessmanagements durchgeführt werden.

Wie sieht es bei unserem CRM- Projekt aus? Ursprung und Ziel können ähnlich beschrieben werden - wir führen keine neue Software zum Selbstzweck ein und damit der Projektmanager und die beteiligten Mitarbeiter fleißig Überstunden leisten dürfen... Ziel eines IT- Einführungsprojektes ist immer eine Optimierung von Prozessen (ggf. Schnittstellen) und/oder eine verbesserte auswertbare Datenbasis - beim CRM im allgemeinen eine verbesserte Abwicklung der Kundenbestellungen verbunden mit nutzbaren Customer Insights. Die Einführung eines CRM stellt also eine große Prozessverbesserung im Vergleich zur Situation ohne CRM dar - zusätzlich werden höchstwahrscheinlich noch eine Reihe von Folgeprozessen um das CRM herum neu eingeführt - daran müssen viele Personen und Abteilungen beteiligt werden. Dabei wird deutlich, dass sich der Aufwand eines Projektes lohnt - ähnlich wie bei der Antwort zum Produktentwicklungsprozess haben wir es mit vielen Abteilungen zu tun und mit einer Reihe von optimierten und sogar neuen Prozessen.

Fassen wir nun managementtauglich zusammen, in welchen erweiterten Dimensionen wir eine Prozessoptimierung von einem Projekt abgrenzen können:

Wie grenzen Sie ein Projekt von einem Prozess ab? Haben Sie weitere oder eindeutigere Abgrenzungskriterien? Schreiben Sie Ihren Kommentar. 

Sich nicht im Detail verlieren: Design Thinking für IT-Entwicklungsprojekte

IT- Entwickler arbeiten gerne genau: Jedes Detail muss stimmen, damit das Endprodukt alle Anforderungen erfüllt. Bei der Entwicklung hat gerade der kreative Entwickler gerne noch eine spontane Idee, wie das Produkt noch besser wird - und weil er gerade eh dabei ist, wird die vermeintlich kleine Änderung direkt noch mit programmiert - mehr ist schließlich besser.

Der kaufmännisch orientierte Projektleiter hat dafür wenig Verständnis: Er lebt im Dreieck zwischen Kosten, Leistung und Zeit. Mehr Leistung muss nicht sein, dauert länger und überhaupt muss mehr Leistung mit dem Kunden abgesprochen und bestenfalls vorab bepreist sein. Ein Spannungsfeld zwischen Entwickler und Projektleiter entsteht - was hilft dagegen?

Zieldefinition

Der klassische Projektleiter definiert vor Projektbeginn Ziele oder Anforderungen, Prozesse, Usecases, Customerjourneys etc. - bestenfalls zusammen mit dem Auftraggeber und dem Projektteam. Je länger das Projekt dauert, desto mehr neigen diese initialen Bemühungen zumindest beim Projektteam in Vergessenheit zu geraten. Dazu ist es natürlich hilfreich, die entsprechenden Projektunterlagen auf einem Projektlaufwerk abzulegen und die finale Version dem Team vorzustellen. Jetzt ist jeder formell informiert… Der Stress im laufenden Projekt, Auslastung aus anderen Projekten, mangelndes Verständnis für vermeintlich sinnlose bürokratische Dokumente und weitere Engpässe sorgen jedoch dafür, dass das Projektteam sich nicht mehr damit beschäftigt. Die Ziele können im Projektmeeting wieder herausgekramt und noch einmal verdeutlicht werden - echt jetzt!? Wir versinken hier im Chaos, der Projektleiter fordert Fortschritte ein, alle machen Überstunden, und jetzt wird die Meetingzeit noch auf eine Präsentation von Zielen von vor 6 Monaten verwendet, die eh nicht mehr aktuell ist? 

Der agile Projektleiter definiert die Ziele pro Sprint, also in einem kürzeren Zeitraum von 2 bis 4 Wochen. Auch dabei sind die Entwickler nicht vor spontanen Eingebungen sicher - der Entwickler kann beim Daily Standup vergessen, von seiner tollen Idee zu berichten, im Optimalfall stellt er sie am Ende des Sprints vor, im schlimmsten Fall crasht etwas bei einem späteren Sprint. Aus der Rolle des Servant Leaders heraus ist der Scrummaster nicht direkt befugt, den Rückbau einer spontan im Sprint realisierten Idee einzufordern - falls der kreative Programmierer seine Idee vorstellt, das Dev Team sie als gut empfindet und voller Überzeugung dem Product Owner vorstellt, kann es passieren, dass auch der Product Owner überzeugt wird. Dies animiert das Scrumteam natürlich, in weiteren Sprints wieder kreativ zu werden - es besteht die Gefahr, dass der Kunde am Ende etwas in weiten Teilen anderes erhält, als das, was er bestellt hat.

In beiden Systemen, klassisch und agil, ist die Zielverfolgung somit stark von der Selbstdisziplin und Kommunikationsbereitschaft der Projektbeteiligten abhängig, da kein Projektleiter seine Projektmitarbeiter detailliert anleiten und überwachen kann und möchte. 

Design Thinking und Design Sprint

Ein zumindest langfristig ausgelegter Besserungsansatz kann im Design Thinking liegen - das hört sich immerhin schonmal modern an und kann daher auch gut verkauft werden. Die aus meiner Sicht in diesem Kontext wesentlichen Kernaspekte (bzw. Ziele) beim Design Thinking und beim Design Sprint sind: 

Es soll schnell ein marktfähiger Prototyp entwickelt werden. 

Das ist unterm Strich natürlich auch nur alter Wein in neuen Schläuchen - ein kluger klassischer Projektleiter arbeitet auf dieses Ziel natürlich genauso hin wie ein Scrummaster in jedem einzelnen Sprint. Warum also meine ich, dass dieser Ansatz helfen kann?

Die Maxime: “schnell einen marktfähigen Prototypen entwickeln” kann in einem klassischen Projekt als (Ober) Ziel aufgenommen werden. Somit muss sich erstmal kein Projektleiter völlig umgewöhnen. In einem agilen Projekt kann der Satz über dem Taskboard aufgehangen werden und/ oder in jedem einzelnen Sprint verankert werden. Der Formalität ist damit genüge getan.

Der Nutzen dieses einen Satzes kann jedoch wesentlich besser dorthin transportiert werden, wo das Projekt eigentlich stattfindet: In die Köpfe der Projektmitarbeiter bzw. des Scrumteams. Er kann kurz und knackig als Mantra verankert werden und die Menschen somit ohne hohen Zeitaufwand fokussieren. Im klassischen Projekt zu Projektbeginn bei der Vorstellung der Zielhierarchie als ganz wichtiges Ziel betont und fortlaufend in jedem Projektmeeting.  Im Daily Standup bei der eingehenden Frage des Scrum Masters: Was wollen wir heute tun, um schnell einen marktfähigen Prototypen zu entwickeln? Das alles kostet sehr wenig Zeit, den einen Satz können sich alle Projektmitarbeiter schnell merken und leichter verinnerlichen als eine eventuell umfangreiche Zielhierarchie oder diverse Taskkärtchen. “Prototyp” ist zumindest noch ein nicht so abgenutztes Wort wie “Ziel” - Ziele haben wir irgendwo alle, Ziele sind weit entfernt und an Zielen muss man ja auch nicht jeden Tag dringend mit vollem Nachdruck arbeiten - das macht man eher langfristig, wenn mal zwischendurch Zeit ist. Ein Prototyp ist fresh, innovativ, spacig und ohne Schnörkel - den geht man doch viel lieber an als ein langweiliges Ziel, oder?

Da auch die Idee des Prototypen mittlerweile schon etwas etablierter ist, wurde schon die nächste Sau gefunden, die durchs Dorf getrieben werden kann: Das Minimum Viable Product (MVP) -  ein Minimalprodukt mit Basisfeatures - wieder ein neuer Schlauch für unseren alten Wein. Dieser Anglizismus mitsamt moderner Abkürzung ist jedoch erklärungsbedürftig und dürfte vom durchschnittlichen Projektteam nicht intuitiv verstanden werden - ein “Prototyp” weckt hingegen direkt bildhafte Assoziationen. Somit eignet sich das MVP gut für Berater, um erklärende Präsentationen zu halten und dafür Stunden schreiben können, nicht jedoch für die breite Masse um ein gemeinsames Verständnis zu erlangen.  

Konnten Sie bereits ein Projektteam (agil oder klassisch) zu hoher Selbstdisziplin führen? Wie haben Sie es geschafft? Welche Erfahrung haben Sie mit Zieldefinitionen und Design Thinking oder Design Sprints? Welches Modewort sollen wir verwenden, wenn auch der “Prototyp” irgendwann abgenutzt ist? Schreiben Sie ihren Kommentar.