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.