Direkt zum Hauptbereich

Wie können wir definieren, was ein „ Projekt“ ist? (Und wozu brauchen wir in der Praxis überhaupt eine solche Definition?)

Auf verschiedenen Plattformen ist eine Diskussion darüber entbrannt, was überhaupt ein Projekt ist, ob es z. B. Sinn macht, von „agilem Projektmanagement“ zu reden und ob es nicht besser wäre, das Wort „Projekt“ überhaupt aus dem Vokabular zu streichen. /1/ Wir möchten gerne unsere Überlegungen zu dieser Diskussion beisteuern. Denn es geht darum, Begriffe so zu wählen, dass sie uns bei der Verständigung in unserer Projektmanagementpraxis optimal unterstützen.

Hinweis: Wir diskutieren bei Xing gerade über die Projektdefinition. Vielleicht möchten Sie etwas beitragen? https://www.xing.com/net/prif444ddx/projektkooperation/diskussionen-rund-um-das-projektmanagement-66955/nochmal-zur-diskussion-was-ist-ein-projekt-45014304/

Warum so viele Worte?

Wissen Sie, was ein Hügel ist? Wissen Sie, was ein Hochgebirge ist? Wenn Sie die beiden Worte kennen: wie würden Sie die Alpen einordnen? Wie den Weyerberg (Endmoräne bei Bremen, 55 m hoch)? Wie den Schwarzwald? Oder finden Sie das alles überflüssig und Sie würden das Wort „Hochgebirge“ am liebsten aus der deutschen Sprache streichen, weil es alles unnötig kompliziert macht?

Wir brauchen beide Worte – Hügel wie Hochgebirge -, weil sie uns bei der Auswahl unserer Wanderausrüstung unterstützen. Wenn ich einen Freund anrufe und sage: „Komm, wir machen eine Hügelwanderung“, dann wird er nicht sein Kletterseil einpacken. Gleichzeitig ist die Abgrenzung zwischen beiden (das Beispiel Schwarzwald zeigt es) nicht einfach: Wo hört der Hügel auf, wo fängt das Hochgebirge an? Ist das einfach eine Frage der Höhe („ab 1.000 m …“)? Oder gibt es andere Kriterien („enthält Felswände von über 100 m Kletterhöhe“)? Braucht man in der Praxis Zwischenbegriffe („Mittelgebirge“)?

Die natürliche Sprache grenzt die Begriffe nicht bewusst und exakt gegeneinander ab, und deshalb gibt es viele Grauzonen. So steht es derzeit mit dem Begriff „Projekt“. Dabei können wir nicht stehenbleiben. Für die Kommunikation in unseren Organisationen, außerhalb unserer Organisationen (z. B. mit Lieferanten) und in unseren Netzwerken brauchen wir eine Kunstsprache, die versucht, die Grauzonen zwischen den Begriffen zu verringern (auf Null werden wir sie nie bringen, denn die Wirklichkeit ändert sich).

Was sind im Sprachgebrauch Projekte?


Probieren wir es einmal mit einer ad-hoc-Heuristik. Ich erstelle eine Liste von Tätigkeiten oder Aufgaben, die ich „intuitiv“ als Projekt bezeichne oder auch nicht. Und Sie, liebe Leser, können mitmachen und prüfen, ob Ihre intuitive Einteilung mit meiner übereinstimmt.


Die Tatsache, dass ein Projekt ein Produkt erzeugt (z. B. eine technische Anlage oder ein OE-Verfahren wie eine Mitarbeiterbefragung), stellt demnach „intuitiv“ kein Argument dar, den Projektbegriff abzuschaffen. Im Gegenteil, je schärfer die begriffliche Trennung zwischen Projekt „Anlagenbau“ und Nicht-Projekt-Aufgabe „Anlagenwartung“ ist, um so besser wird in der Praxis die Verzahnung beider Aufgaben gelingen (zum Beispiel ganz simpel die Zusammenstellung einer routinetauglichen Anlagendoku im Projekt und ihrer Übergabe an das Wartungsteam).

Was haben aber jetzt die Aufgaben, die ich als „Projekt“ bezeichnen würde, gemeinsam?

Zum einen eine gewisse Komplexität. Mit "gewiss" meine ich - dem Sprachgebrauch folgend - eine Unschärfe, eine intuitive Ahnung, die es noch nicht zur nötigen Präzision gebracht hat. Jan versucht, dieser Komplexität mit dem Begriff der "Unsicherheit" auf die Spur zu kommen: „Ein Projekt zu führen bedeutet, mit Unsicherheit umzugehen.“ /2/

Aber wenn es „nur“ um Unsicherheit ginge, dann wäre ja auch das letzte Beispiel der Tabelle - die Spekulation mit Genussrechten - ein Projekt - denn diese Spekulation ist bestimmt sehr unsicher. Doch ist sie nicht komplex.

Mir geht eher eine Definition im Kopf herum folgender Art: ein Projekt ist eine Aufgabe, bei der Planung und Durchführung sich nicht sauber voneinander trennen lassen, sondern ineinander verwoben sind.

Einschub: Planung und Ausführung – zur Metaphysik hierarchischer Arbeitsteilung


Die Trennung der Arbeit in planende und ausführende Arbeit stellt eines der fundamentalen Paradigmen der klassischen Wirtschaftslehre dar. Um teamworkblog nicht wieder dem Verdacht auszusetzen, wir verbreiteten neoliberale Platitüden, zitieren wir einen in dieser Hinsicht gänzlich unverdächtigen Autor - Karl Marx:
"[…] eine Biene beschämt durch den Bau ihrer Wachszellen manchen menschlichen Baumeister. Was aber von vornherein den schlechtesten Baumeister vor der besten Biene auszeichnet, ist, dass er die Zelle in seinem Kopf gebaut hat, bevor er sie in Wachs baut. Am Ende des Arbeitsprozesses kommt ein Resultat heraus, das beim Beginn desselben schon in der Vorstellung des Arbeiters, also schon ideell vorhanden war." /3/

Was Marx hier als Besonderheit aller menschlicher Arbeit darstellt, bildet die Grundlage der Möglichkeit einer hierarchischen Organisation der Arbeit: nur ihre Teilung in Planen und Tun, in Kopfarbeit und Handarbeit birgt die Möglichkeit ihrer Verfestigung zu funktionalen Rollen: in planende Vorgesetzte und ausführende Untergebene. /4/

Die moderne Arbeitswelt bricht mit dieser starren Abfolge „erst planen, dann ausführen“. Sie bringt zunehmend Aufgaben hervor, bei denen der Plan während der Ausführung laufend überprüft und angepasst werden muss. Oder wie Jan es in seinem schon zitierten Vortrag beschreibt: „Für viele bedeutet Projekte managen etwas wie das Abarbeiten einer großen Todo-Liste. Doch es gibt Probleme mit dieser Liste: Sie ist niemals vollständig und wenn wir nicht aufpassen, ändert sich gerade der Inhalt.“

In der US-Literatur hat sich für diese Art von Aufgaben der Begriff knowledge work eingebürgert. Dieser Begriff bezieht sich darauf, dass bei Aufgaben wie oben in der Tabelle oft unvorhergesehene Situationen auftreten. Und in diesen Situationen benötigt der Ausführende Expertenwissen, um schnell die notwendigen Entscheidungen treffen zu können. /5/

Vorschlag für eine Definition von „Projekt“


Hilft uns der Begriff des knowledge work bei unserem Anliegen weiter? Ich denke, ja.

Ich denke, ein Projekt hat auf jeden Fall etwas mit knowledge work zu tun. /6/ Aber nicht jede knowledge-work-Aufgabe ist ein Projekt.

Sondern zum Projekt muss nach meinem Verständnis ein Maß an Komplexität hinzukommen, und zwar Komplexität durch Kooperation. Das heißt, an einem Projekt sind immer mehrere Menschen beteiligt, die verschiedene Interessen („Rollen“) verkörpern und die sich beim Eintreten unvorhergesehener Situationen über die möglichen Lösungen und zu treffenden Entscheidungen verständigen müssen. Und jeder verkörpert ein anderes Expertenwissen (und die verschiedenen Wissensarten und die verschiedenen Interessen leiten zu unterschiedlichen Entscheidungen hin).

Ein Beispiel: Es gibt eine Komplexität der Dinge, die nicht aus der Kooperation entspringt. Wenn ich für mich alleine eine Software programmiere und ich veranschlage dafür drei Personentage, kann ich mich verschätzen. Auch hier fallen nämlich Planung und Umsetzung nicht streng auseinander: die verschiedenen Stufen des Softwaredesigns stellen schon Umsetzungsschritte dar. Wenn ich nach zwei Tagen feststelle, dass ich statt drei in Wirklichkeit fünf Tage brauche, dann muss ich mich nur mit mir selbst streiten („Lohnt sich das noch? Mache ich Abstriche am Leistungsumfang?“). Das macht nach meinem Verständnis noch kein Projekt aus.

Wenn diese Software aber ein Baustein einer größeren Anwendung ist. Oder wenn sie im Kundenauftrag erstellt wird und mit diesem habe ich ein Budget verhandelt: dann bekommt das Ganze Projektcharakter. /7/ Wobei eine wirkliche Komplexität erst entsteht, wenn mindestens drei Parteien beteiligt sind. Also nicht einfach „Auftragnehmer und Auftraggeber“, sondern eher etwas wie „drei Auftragnehmer, ein Auftraggeber und fünf Endkunden“.

Also lautet mein vorläufiger Vorschlag für eine Projektdefinition: Ein Projekt ist eine Aufgabe komplexer Kooperation aus dem Bereich des knowledge work.
  • Mit komplexer Kooperation ist gemeint: Es sind mindestens drei verschiedene Parteien an der Aufgabe in verschiedenen Rollen beteiligt mit unterschiedlichen Interessen und/oder unterschiedlichem Expertenwissen.
  • Mit knowledge work ist gemeint: bei der Aufgabe können Planung und Ausführung nicht zeitlich (in ein Vorher und ein Nachher) getrennt werden. Vielmehr muss der Plan während der Ausführung immer wieder überprüft und ggf. geändert werden. Dies geschieht auf dem Wege von Verhandlungen zwischen den Parteien.
Sollte es irgendjemanden geben, dem diese Definition nicht einleuchtet?

Anmerkungen

  • /1/ Das Thema tauchte auf in Kommentaren zum TWB-Artikel „Wie man ein Projekt startet“ vom 29. Juli 2013, http://www.teamworkblog.de/2013/07/wie-man-ein-projekt-startet-uber.html. In der XING-Gruppe agile@large gibt es einen Dikussionsthread zwischen Hans-Peter Korn und Oliver Boeff, den man unter https://www.xing.com/net/pri610d2ex/agile-at-large/andere-diskussionen-und-fragen-zu-agile-large-761131/agil-passt-nicht-zum-management-von-projekten-und-programmen-sondern-zum-gesamten-leben-von-produkten-44263868.
  • /2/ Jan Fischbach: Wie viel Aufwand braucht mein Projektmanagement? Vortrag bei der GPM Region Düsseldorf/Rhein-Ruhr, Version vom 13.05.2013. Jan bezieht sich darin auf die Konzepte von Aaron Shenhar und Dov Dvir.
  • /3/ Karl Marx, Das Kapital. Band 1, MEW 23, S. 193; zitiert nach http://de.wikiquote.org/wiki/Biene.
  • /4/ Diese hierarchische Arbeitsteilung herrschte bekanntlich auch in den realsozialistischen Gesellschaften. - Den Gegenpol zur Abfolge von Planen und Ausführen bildet der Begriff der bricolage (Basteln, Bastelei), den Claude Lévy-Strauss 1962 in seinem Buch „Das Wilde Denken“ vorstellte. Beim Basteln verfertigt der Mensch aus gerade zufällig vorhandenem Material etwas Neues ohne vorher ein Ziel zu haben. Nach dem Motto „mal sehen, was herauskommt“.
  • /5/ Siehe zum Beispiel den Sammelband Keith D. Swenson u.a.: Mastering the Unpredictable, Meghan-Kiffer Press, 2012
  • /6/ Damit verlasse ich die Definition nach DIN 69901. Nach der DIN ist ein Projekt „ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation.“ (zitiert nach http://www.uni-duesseldorf.de/muendlichkeit/Projekt-Netz/DIN.htm). An die Stelle der „Einmaligkeit der Bedingungen“ würde nach meinem Verständnis eher die „Änderbarkeit der Bedingungen“ treten.
  • /7/ Hier beginnt übrigens für mich selbst der Punkt, an dem ich von meiner Intuition abweiche. Oben in der Tabelle hatte ich einen grundlegenden Berufswechsel als Projekt bezeichnet. Aber daran bin ja nur ich, nur eine Person beteiligt. Also würde ich aufgrund meiner eigenen Definition nicht mehr von einem Projekt sprechen.

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.