Das wirklich beste Projektmanagementtool

Sind Sie auf der Suche nach dem einen besten Projektmanagementtool? Der Wunderwaffe, der eierlegenden Wollmilchsau, dem Messias unter den Hilfsmitteln? Suchen Sie Tag und Nacht im Internet nach Templates, um Ihre Projekte noch besser, noch strukturierter gestalten zu können? Lesen Sie hier weiter und ersparen Sie sich weitere Irrwege!

MS Project, Jira, Trello, Monday, Teams, Zoom und alle weiteren Tools haben eines gemeinsam: Sie sind KEINE Projektmanagementtools. Wer denkt, dass ein Tool Projektmanagement macht, der denkt vermutlich auch, dass ein Zitronenfalter Zitronen faltet. Keiner der genannten Anbieter bezahlt mir übrigens Geld dafür, dass ich über die Grenzen seiner Tools aufkläre, aber das nur am Rande.

Was tut ein Projektmanager eigentlich, um ein Projekt erfolgreich zu managen? 

Im Kern kommuniziert ein Projektmanager - am besten wie ich finde persönlich, aber in einer fragmentierten post- Corona- Zeit zwangsläufig mit Kollegen im Homeoffice oder aus dem Homeoffice heraus. Dabei helfen Tools wie MS Teams, Zoom oder weitere. Sind diese Tools dann Projektmanagementtools? Entscheiden Sie selber. 

Kann ein Tool kommunizieren? Ich würde diese Frage aktuell mit "Nein" beantworten - man munkelt, dass ein intelligent konfiguriertes Dashboard den richtigen Adressaten die richtigen Informationen zum richtigen Zeitpunkt zur Verfügung stellen könnte, allerdings habe ich ein solches Dashboard noch nicht persönlich kennenlernen dürfen. Mit weiteren Fortschritten der KI möchte ich nicht ausschließen, dass diese in Zukunft viele Funktionen eines Projektmanagers übernehmen könnte - allerdings findet Projektmanagement auch immer auf der persönlichen Ebene statt und dahingehend wage ich zu bezweifeln, dass eine noch so intelligente KI einen Projektmanager als Führungspersönlichkeit vollkommen ersetzen kann.

Keines der genannten Tools kann eigenständig kommunizieren - und ich halte es für sehr wichtig klarzustellen, dass alle Tools Ergebnisse erzeugen, visualisieren oder strukturieren, welche kommuniziert werden müssen. Die falsche Nutzung von Tools kann die Kommunikation sogar verschlechtern: 

Stellen Sie sich den Projektmanager vor, der alleine im stillen Kämmerlein seinen Projektablaufplan schreibt und diesen wie Gollum als seinen Schatz auf seinem persönlichen Laufwerk ablegt, nur um alleine den Überblick zu behalten. Oder stellen Sie sich Teammitglieder vor, die emsig Jira- Karten schreiben und sie anderen Kollegen zuweisen ohne mit diesen zu kommunizieren - in der wahnsinnigen Vorstellung, die entsprechende Aufgabenstellung sei ja völlig klar beschrieben und die Aufgabe würde aufgrund dessen natürlich wie gewünscht erledigt werden können. In beiden Beispielen fehlt der Konsens des Projektteams über die zu leistende Arbeit, sowie das commitment, diese durchführen zu wollen - und genauso wird der Grundstein dafür gelegt, dass das Projekt scheitert. Leider stammen diese Beispiele aus der Praxis.

Was tut ein Projektmanager noch? Er benutzt bestimmte Methoden, um die Erfolgschancen seines Projektes zu erhöhen. Anforderungsdefinition, Stakeholdermanagement, Risikomanagement, Zieldefinition, Projektablaufpläne, etc. 

Keines der mir bekannten Tools unterstützt dabei mit allen Methoden - allerdings helfen hier einige Tools tatsächlich gut in denjenigen Bereichen, auf welche sie spezialisiert sind, wenn man sie richtig nutzt. Mit MS Project und natürlich auch seinen Freeware- clonen lassen sich tolle Projektablaufpläne erstellen, wenn der Projektleiter sie zusammen mit dem Projektteam erstellt, nutzt und entsprechend kommuniziert. Stakeholder- und Risikoanalysen lassen sich ebenfalls am besten im Team gestützt durch Flipcharts, Pinnwände, Stattys, Powerpoint oder Excel durchführen. Definitionen und Monitoring von Arbeitspaketen oder Tasks funktionieren super über Jira, Trello oder andere Systeme (begleitet von einer adäquaten Kommunikation). Eine übersichtliche Dateiablage kann in MS Teams, Sharepoint oder Confluence hergestellt werden, wenn die entsprechende Ablagestruktur mit allen Beteiligten abgestimmt ist. 

Was ist nun also das versprochene beste Projektmanagementtool?

Das beste Projektmanagementtool ist die Erfahrung und der Verstand des Projektleiters und des Projektteams.  Damit können Sie aus einer Vielzahl an nützlichen Tools auswählen, ihre Grenzen bestimmen und dem Versuch widerstehen, sich falschen Propheten und haltlosen Werbeversprechungen auszuliefern. Mit Ihrem Verstand können sie Tools nach Ihren individuellen Bedürfnissen kombinieren und ihnen den Platz geben, den sie verdienen: Als Unterstützung und nicht als übermächtiges Ordnungsprinzip, dem sich alle Projektmitglieder auf Gedeih und Verderben ausliefern müssen! 

Die Zukunft des Projektmanagers vor dem Hintergrund einer möglichen Bedrohung unseres Berufsstandes durch eine KI besteht darin, dass der Projektmanager menschlich führen kann, Emotionen wahrnehmen und weitergeben kann, das Team motivieren kann und somit emotional geführt kommunizieren kann.

Welche(s) Projektmanagementtool(s) nutzen Sie zu welchem Zweck? Kennen Sie das EINE Tool, welches all ihre Anforderungen erfüllt? Lassen Sie es mich in Ihrem Kommentar wissen. 

Digitalisierung, Digitalisierungsstrategie & Digitalisierungsprojekte

"Wir arbeiten mit Computern, also sind wir digital" wenn Sie diesen Satz unterschreiben würden oder ihn schon zu oft gehört haben, sollten Sie unbedingt weiterlesen.

Um zu klären, was Digitalisierung eigentlich ist und noch wichtiger: Worin der Nutzen der Digitalisierung für Ihr Unternehmen liegen kann, möchte ich zunächst 2 Beispiele anführen, was Digitalisierung nicht ist. Beide Beispiele habe ich selber erlebt.

1. Beispiel: Buchbestellung: Es war an einem Wochenende, ich beschloss, dass ich ein Buch benötige- Projektmanagement Fachliteratur, was sonst? Das Buch war nur bei einem einzigen speziellen  Händler erhältlich (nein, nicht der bekannte große Händler, auf den kommen wir aber später noch). Nun hatte ich 2 Möglichkeiten: Zum Einen eine Bestellung des physischen Buchs, das wäre dann irgendwann in der nächsten Woche gekommen, und ich wollte ja am Wochenende schon lesen - also wählte ich Option 2, die Bestellung der digitalen Variante. Ich klickte mich also durch den Shop, wählte die digitale Variante aus, Bezahlung via PayPal, damit das Geld direkt ankommt und beendete die Bestellung. Ich erhielt kurz danach die automatisch generierte Bestätigungsmail. So weit so digital. Es folgte die Enttäuschung: Der Text der Mail sagte sinngemäß: Vielen Dank für Ihre Bestellung. Ein Mitarbeiter prüft Ihren Zahlungseingang und wird Ihnen den Downloadlink zum Buch senden. Super. An diesem Wochenende konnte ich nicht mehr lesen. 

2. Beispiel: Rechnungseingang im Unternehmen. Vielleicht kennen Sie diesen Prozess? Eine Rechnung kommt im Unternehmen physisch an, wird eingescannt und per E-Mail an den Adressaten weitergeleitet (wir sind ja digital). Der druckt sie aus, um sie unterschreiben zu können, scannt sie wieder ein und leitet sie an die FiBu weiter. Die FiBu druckt die Rechnung aus, um sie gegenzeichnen zu können, scannt sie ein und legt das physische Exemplar in einem Ordner ab (Aufbewahrungspflicht muss man ja schließlich physisch wahren, so meinen viele).

Die Schwachstellen der beschriebenen Prozesse sind aus der Vogelperspektive offensichtlich. Und mit dieser Feststellung können wir schon mal schlussfolgern, dass sich erfolgreiche Digitalisierung auf Prozesse beziehen muss - damit meine ich End-to-End-Prozesse, also von der Entstehung eines Kundenwunsches bis zu seiner Erfüllung, vom Procure to Payment oder von der Personalbeschaffung bis zur Personalfreisetzung um nicht nur Markt- bzw. Bestellprozesse, sondern auch gleich Finanzprozesse oder Personalprozesse mit einzubeziehen. 

Mein Lieblingszitat dazu stammt von Thorsten Dirks, CEO der Telefónica Deutschland: "Wenn Sie einen Scheißprozess digitalisieren, dann haben Sie einen scheiß digitalen Prozess“.

Wie würden die beschriebenen Prozesse besser ablaufen können? 

Im Falle des ersten Beispiels kennen wir alle einen tollen Bestellprozess von demjenigen Großhändler, der anfing Bücher zu verkaufen und mittlerweile jeden Scheiß vertickt (und leider schlecht mit seinen Mitarbeitern umgeht). Besagter Großhändler hat einen vollkommen digitalen und vor Allem schlanken Bestellprozess aufgesetzt, von der Bestellung bis zur sofortigen Lieferung eines digitalen Buchs. Auch für die Bestellung physischer Güter hat sich der Großhändler optimiert: Lieferung am nächsten Tag inkl. völliger Transparenz des Versandstatus. Aftersales- Support läuft hervorragend über gut konfigurierte Chatbots, unproblematische Rücksendung mit digitalen Versandetiketten. Da bin ich als Kunde zufrieden - und das ist auch einer der herausragenden Nutzen der Digitalisierung: Kundenzufriedenheit (beim Bestellprozess, die Digitalisierung anderer End-to-End-Prozesse verfolgt andere Nutzendimensionen). Auch nach der Bestellung werden mir in der App des Händlers weitere mögliche Güter vorgeschlagen, die ich aufgrund eines cleveren Algorithmus interessant finden könnte. Darin spiegelt sich eine weitere wichtige Dimension der Digitalisierung wider: Die massenhafte Erstellung & intelligente Nutzung von Daten. Ich komme gleich darauf zurück.

Im Falle des zweiten Beispiels würde eine Rechnung digital ankommen (oder zumindest einmalig gescannt werden, denn es ist leider immer noch schwer, jeden Lieferanten von den Vorzügen einer digitalen Rechnungsstellung zu überzeugen). Die digitale Rechnung würde automatisch digital an die entsprechende Stelle weitergeleitet werden, indem eine künstliche Intelligenz die Rechnung ausliest, der Empfänger unterschreibt digital (per revisionssicherem Mouseklick). Anschließend erkennt der hinterlegte Workflow (bzw. "Prozess" auf deutsch, um die Prozesssicht zu stärken), dass die Rechnung freigegeben ist und vergleicht den Rechnungsbetrag mit dem im System geplanten Rechnungsvolumen. Befindet sich der Ist- Rechnungsbetrag innerhalb der vordefinierten Toleranzgrenze, so wird die Rechnung ohne weiteres manuelles Eingreifen archiviert & bezahlt - also vollautomatisch. Sollte sich der Rechnungsbetrag außerhalb der Toleranzgrenze befinden, so muss eine manuelle Aussteuerung erfolgen. Der Nutzen dieses digitalen Procure-to-Pay- Prozesses  liegt in der Effizienz  - das Unternehmen spart Ressourcen, Zeit, Kosten. Und auch in diesem Prozess werden Daten erstellt und genutzt - systemübergreifend durch intelligente Vergleichsalgorithmen.

Zusammenfassend bedeutet Digitalisierung eine End-to-End Prozessoptimierung und - Automatisierung durch intelligente Erstellung & Nutzung von Daten und durch die Vernetzung von Systemen. 

Der Zusammenhang zwischen Prozessen und Daten besteht darin, dass Prozesse Daten erzeugen - das tut jeder Prozess zwangsläufig. Es ist nur ein Unterschied, ob sie Daten manuell in Excel- Tabellen tippen und auf Ihrem persönlichen Laufwerk C:\Datenfriedhof ablegen oder dieselben Daten strukturiert in standardisierten Systemen unternehmensweit nutzbar machen.

So weit zur Digitalisierung - was ist nun mit der Digitalisierungsstrategie? 

Die Digitalisierungsstrategie leitet sich wie die IT- Strategie von der Unternehmensstrategie ab. Jetzt wird es noch abstrakter als die ganze Digitalisierungsgeschichte es eh schon ist - ich bleibe daher bei meinen Beispielen: Die Unternehmensstrategie könnte unter Anderem vorsehen, die Kundenzufriedenheit in den nächsten 3 Jahren um 15 % zu steigern, sowie Kosteneinsparungen in der Rechnungsbearbeitung um 10% im selben Zeitraum zu realisieren. 

An dieser Stelle kommt nun der Digitalisierungsberater, der CIO oder der Projektportfoliomanager ins Spiel, fängt den Ball der Unternehmensstrategie auf und verwandelt sie zusammen mit anderen Entscheidungsträgern in eine Digitalisierungsstrategie . Die Digitalisierungsstrategie könnte sinnvollerweise auf der Optimierung der bereichsübergreifenden Prozesse aufbauen, die vorhandenen Daten bereinigen und die zukünftigen Datenströme vereinheitlichen und auswertbar machen. Zusätzlich wird mit ziemlicher Sicherheit dafür die bestehende IT- Systemlandschaft und deren Schnittstellen in Frage gestellt werden und die Einführung neuer IT- Systeme vorschlagen. Die Digitalisierungsstrategie ergibt somit ein Digitalisierungsportfolio.

Und damit kommen wir schon auf die Ebene der Projekte - denn das Digitalisierungsportfolio besteht aus einem bunten Strauß von Digitalisierungsprojekten. Es ist schwer, dafür Beispiele zu nennen, denn die konkreten Projekte richten sich danach, was bereits im Unternehmen vorhanden ist. Mögliche Projekte wären: Einführung einer Datagovernance, Einführung einer Prozessgovernance oder eines einheitlichen Prozessmanagements, Einführung eines (neuen) BI- Tools, Einführung eines Chatbots, Einführung eines (neuen) Endkundenshops,... 

Und damit wären wir am vorläufigen Ziel angelangt - die Digitalisierungsstrategie ist erstellt und in Projekte eingegossen, welche wir bequem anhand der üblichen Projektdimensionen  Kosten, Leistung und Zeit tracken können.

Was bedeutet Digitalisierung für Sie? Wie wird die Digitalisierungsstrategie in Ihrem Unternehmen gehandhabt? Wie oft haben Sie schon den Satz: "Wir arbeiten mit Computern, also sind wir digital" schon gehört? Lassen Sie es mich in Ihrem Kommentar wissen.

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.

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.