21 Oktober 2021

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. 

07 Oktober 2021

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. 

Projektmanagement und Homeoffice

Corona ist offiziell beendet und in der als "Post-Corona-Zeit" bezeichneten Lebensphase können wir Projektleiter und Scrum- Master...