1. ein in Worten beschreibbares Ziel oder Arbeitsergebnis,
   das in dieser Form noch nicht existiert,
2. einen Termin an dem mit den Arbeiten begonnen wird,
3. einen Termin an dem das Arbeitsergebnis vorliegen soll,
4. mindestens zwei Personen, die zum Arbeitsergebnis beitragen,
5. sowie mindestens eine weitere Person,
   an die das Arbeitsergebnis geliefert wird.

Diese Minimaldefinition ist gewissermaßen eine Konkretisierung der in der EN ISO 9000:2005 enthaltenen Definition:

Ein Projekt ist ein einmaliger Prozess, der aus einem Satz von abgestimmten und gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Kosten und Ressourcen ein Ziel zu erreichen, das spezifische Anforderungen erfüllt.

Die nebenstehende Mindmap fasst die Merkmale zusammen und bezieht den Aspekt der temporären Organisation mit ein. Mit dieser Definition wird deutlich, dass der Begriff weiterhin sinnvoll ist. In einer Diskussion auf g+ wurde kürzlich ein eindrückliches Beispiel genannt. Eine Stadt hat Jubiläum, an einem Termin X soll ein Fest mit verschiedenen Veranstaltungen im Stadtgebiet verteilt stattfinden. In der Vorbereitung sind Vertreter der Stadt, von Vereinen, und Bürger beteiligt. Die Aufgabenpalette reicht von der Beschaffung von mobilen Toiletten, über Vertragsgestaltung mit Künstlern, Absperrung von Parkplätzen, Ticketverkauf bis hin zur Anlieferung von Strohballen für ein historisches Bogenturnier. Es werden Landwirte, Juristen, Kaufleute in der Vorbereitung benötigt … und zu guter Letzt begrenzt der Gemeinderat das Budget. Für dieses Vorhaben fällt mir kein besserer Begriff als “Projekt” ein. Zudem liegt auf der Hand, dass eine temporäre Organisation benötigt wird, die neben der normalen Organisation einer Stadtverwaltung arbeitet. Das normale Arbeitsaufkommen einer Stadtverwaltung ist im Jubiläumsjahr schließlich genauso hoch wie in allen anderen Jahren.
Wenn alle “Projekte” diesen Kriterien genügen würde wäre die Welt übersichtlicher. Ich erlebe es allerdings immer wieder, dass alles was irgendwie nach Veränderung und Neuerung riecht reflexartig als Projekt bezeichnet wird. Die Wartung einer bestehenden Software, die regelmäßig weiter entwickelt wird ist kein Projekt auch wenn ein ganzes Team an der Software entwickelt. Vielleicht genügt ein großer Release-Sprung den Anforderungen eines Projektes. Der Wechsel von 5.1.7 auf 5.1.8 ist aber kein Projekt. Die Beschaffung von Umzugskartons und Büromöbeln ist kein Projekt – vor allem nicht in einer Organisation in der Umziehen zum Tagesgeschäft gehört. Eine umfangreiche Aufgabe, die sich mittels vieler gleichartiger Arbeitsschritte vollständig parallelisieren lässt ist kein Projekt. Eine Aufgabe, die kein Ende kennt ist ebenfalls kein Projekt. Auf dem Hintergrund kann ich agil arbeitende Teams gut verstehen wenn sie sich gegen den Projektbegriff wehren, vor allem wenn sie verpflichtet werden klassische PM Aufgaben als Pflichtübung mitzuerfüllen. Ich habe mehr als ein Dauer-Entwicklungsteam kennen gelernt, das regelmäßige Berichte mit unsinnigen Gantt-Diagrammen und Ampeln abliefern musste. Die Frage, die sich mir stellt, ist: “Warum wird dieser notorische Etikettenschwindel betrieben?”. Hierzu fallen mir eine ganze Reihe von Verdachtsmomenten ein:

• Mitarbeiter werden mit Pseudo-Titeln angefüttert um mehr Aufgaben zu erledigen. Es werden Aufgaben bei einem Mitarbeiter konzentriert, das Etikett Projekt wird aufgeklebt und der Mitarbeiter zum Projektleiter ernannt.
• Organisatorische Änderungen werden aus unterschiedlichen Gründen verschleppt und nicht umgesetzt. Nicht zugeordnete Mitarbeiter werden in “Projekten” geparkt. Am Ende wird dies zum Prinzip erhoben und eine Projektorganisation definiert.
• Verschleierung von Verantwortungen: Statt Entscheidungen zu treffen werden strategische Projekte aufgesetzt, die gewissermaßen Entscheidungsvarianten ausprobieren. Erweisen sich alle Ideen als schlecht hat man in Gestalt des Projektleiters ggf. einen Schuldigen zur Hand.
• Umwidmen von Tagesgeschäft in Projekte um Defizite in Prozessen und Organisation zu kaschieren.

Den letzten Punkt möchte ich provokativ ergänzen und erläutern. Im IT-Bereich wird sehr häufig von Projekten gesprochen obwohl eigentlich in vielen Fällen ein fundamentales Interesse bestehen müsste keine Projekte sondern Standard-Installationen mit so wenig wie möglich Anpassungen durchzuführen. Echte Individualentwicklungen, die am ehesten die Merkmale eines Projektes erfüllen, sind auf jeden Fall weniger häufig als es die Unmengen von Pseudoprojekten vermuten lassen. Es kommt sogar vor, dass Projekte durchgeführt werden weil die bereits vorhandene Lösung nicht mehr gefunden wird  ¹.

Dass nicht jede Organisation perfekt funktioniert liegt auf der Hand. Dass Umwege gesucht werden um die Aufgaben zu lösen und die Umwege als Projekte bezeichnet werden, könnte man auch entspannt als “gesunden Pragmatismus” bezeichnen. Wenn man die Umwege pragmatisch beschreiten dürfte wäre dagegen wenig einzuwenden. De Realität sieht jedoch anders aus. Es wird versucht den vielen Pseudo-Projekten mit den ungeeigneten Methoden zu Leibe zu rücken. Viele gute Ansätze werden abgenutzt wenn nicht gar vergeudet um Probleme zu lösen, die es nicht gäbe wenn der Etikettenschwindel aufhören würde. Multiprojektmanagement, mehrdimensionale Resourcenplanung, Aufteilung von Arbeitszeiten einzelner Mitarbeiter über mehrere Projekte hinweg und vieles mehr wäre unnötig wenn man sich an die zwei folgenden Grundsätze halten würde:

• nur echte Projekte machen
• jede( r ) nur ein Projekt

Zu 100% werden sich diese Grundsätze nie einhalten lassen aber es lohnt sich den Weg zu beschreiten. Wenn ein Handwerker einen Nagel mit dem Griff eines Schraubendrehers einklopft liegt die Unsinnigkeit auf der Hand. Defiziten in der Organisation mit Verbesserung von Projektmanagement-Methoden entgegenzutreten ist in meinen Augen ähnlich unsinnig  ².

Wenn ich die bisher geäußerten Gedanken in eine Grafik fassen wollte sehe ich drei Ecken: Projekte, Stabile Organisationen und Organisationen im Wandel. Dass von stabilen Organisationen Projekte gestartet werden können ist trivial. Spannend ist der Bereich zwischen sich im Wandel befindlichen Organisationen und Projekten. Wie schon geschrieben ein simples Ausdehnen von Projekt-Werkzeugen und Methoden auf die Organisation halte ich nicht für geeignet. Was sich hinter dem Fragezeichen verbergen könnte ist noch nicht zu Ende formuliert wird aber im Laufe der Woche folgen.

1. Das mit der unauffindbaren Lösung ist leider kein Witz sondern eine konkrete Erfahrung. Im fraglichen Fall wurde ein Teilprojekt für Datenbeschaffung und Datenerfassung aufgesetzt. Es handelte sich hierbei um Daten, die bereits erfasst wurden, die Organisation aber nicht mehr in der Lage war zu ermitteln wo die Daten gespeichert wurden. Ein Teil der Daten wurde dann von noch vorhandenen ausgedruckten Dokumenten abgetippt.
2. Ergänzung zu Anspruch und Wirklichkeit. Ich selbst habe auch schon Nägel mit dem Griff eines Messers eingeklopft. Das ging irgendwie und ist im Einzelfall vielleicht sogar schneller als das Herbeiholen eines Hammers. Als grundsätzliches Arbeitsprinzip für das Einschlagen von Nägeln taugt das aber nicht. Dann ist es besser dafür zu sorgen, dass ein Hammer in der Nähe ist.

Im Nachgang hat mich die Frage beschäftigt wie es zu der durchaus vorhandenen Begriffsverwirrung kommt. Ich sehe dies inzwischen als Resultat einer Überhöhung des Manager-Begriffs. Der Manager ist überspitzt formuliert der Leitungsträger und Heilsbringer der Leistungsgesellschaft. Projekte werden heute nicht mehr geleitet sondern gemanaged, also brauchen wir Projektmanager, die genauso wichtig sind wie richtige Manager. Unternehmerisch denken müssen beiden, also wird der Unternehmer auch noch in den Topf geworfen. Genug der Ironie – die drei wesentlichen Akteure sind jetzt benannt:

• Unternehmer
• Manager
• Projektleiter

Dass es Ähnlichkeiten der Tätigkeiten und Anforderungen an diese Akteure gibt ist klar. Ich möchte aber bewusst eine Abgrenzung der Begriffe versuchen. Für die Abgrenzung verwende ich unter anderem folgende Aspekte:

• Der Unternehmer trägt Gesamt-Risiko und wirtschaftliche Verantwortung.
• Unternehmer beschäftigen Manager.
• Ein bestehendes Geschäft muss gesteuert und optimiert werden und sollte so lange es der Markt erlaubt profitabel sein.
• Projekte sind in größere Kontexte eingebettet.
• Projekte haben eine begrenzte Laufzeit.
• Ein Projekt liefert ein Ergebnis an den Auftraggeber.
• Ein Projekt ist nicht profitabel, lediglich aus dem Ergebnis des Projektes lässt sich (manchmal) ein profitables Geschäft machen.

Risiko und wirtschaftliche Verantwortung sind für mich der wesentliche Unterschied (und das größte Missverständnis) zwischen einem Unternehmer und einem Manager. Die mächtigsten Manager, die Milliarden Umsätze verantworten selbst Millionen-Gehälter beziehen tragen keine persönliche wirtschaftliche Verantwortung. Ein guter Manager hat in seinem Vertrag eine Klausel stehen, dass der Arbeitgeber eine Versicherung¹ abschließt, die für die wirtschaftlichen Schäden, die er eventuell anrichtet aufkommt. Der klassische Unternehmer steht jedoch auch mit seinem Privatvermögen in der Verantwortung.

Der Manager optimiert im Auftrag des Unternehmers ein bestehendes Geschäft. Der Unternehmer hat das Geschäft aufgebaut und baut ggf. weitere Geschäfte auf. Der Unternehmer arbeitet kreativer, der Manager steuernd und kontrollierend. Controlling ist der Partner des Managers nicht des Unternehmers. Aus Controlling Sicht wären viele Unternehmen gar nicht erst entstanden.

Und wo verstecken sich das Projekt und der Projektleiter? Die kleinen Mosaiksteinchen werden leicht übersehen. Der Projektleiter ist immer (!) in einen größeren Kontext eingebettet. Er erhält einen Auftrag vom Unternehmer oder Manager. Auch wenn Projekte häufiger, größer und wichtiger werden bleiben Sie doch immer Teil eines größeren Ganzen. Der Projektleiter liefert ein Ergebnis, danach wird das Projekt beendet. Das Projekt kann in gewisser Weise die Früchte seiner Arbeit nicht ernten. Projekte können zwar Bausteine für den Aufbau eines neuen Geschäftes sein sind aber nicht das neue Geschäft selbst. Dieses Kleinreden von Projekten aus dem Munde eines Projektleiters mag sich seltsam anhören. Ich bin jedoch der festen Überzeugung, dass ein “größer reden” der Projekt-Disziplin nicht weiter hilft.

Dass sich die drei Aspekte (Unternehmen, Management, Projekte) überlappen und Gemeinsamkeiten haben liegt auf der Hand, man sollte aber gelegentlich den Blick schärfen und auf die Ecken des Diagramms schauen und nicht in der Mitte einen Einheitsbrei anrühren.

1. http://www.finanzberatung-versicherungsvergleiche.de/vergleich_sachversicherungen/managerhaftpflicht_D&O_haftpflicht_versicherung.htm

1. ein in Worten beschreibbares Ziel oder Arbeitsergebnis, das in dieser Form noch nicht existiert,
2. einen Termin an dem mit den Arbeiten begonnen wird,
3. einen Termin an dem das Arbeitsergebnis vorliegen soll,
4. mindestens zwei Personen, die zum Arbeitsergebnis beitragen,
5. sowie mindestens eine weitere Person, an die das Arbeitsergebnis geliefert wird.

Wenn ich beispielsweise für mich selbst etwas programmiere – so schwierig das Problem auch sein mag – ist es kein Projekt, da ich Auftraggeber und Projektmitarbeiter in einer Person wäre. In der IT Branche gibt es gelegentlich Aufträge, die vollständig von einer Person abgearbeitet werden. Solche Aufträge weisen bis auf die Personenzahl (Punkt 4) alle Merkmale eines Projektes auf und erfordern ein straffes Management. Hier handelt es sich aber eher um Selbst-Management als um Projektmanagement, das immer auch einen Aspekt der Koordination verschiedener Mitarbeiter enthält. Auch die W-Fragen des Projektmanagements ergeben erst dann einen Sinn, wenn ein Vorhaben oder Auftrag diese Merkmale aufweist.

Dieser Text ist unter Creative Commons BY NC ND (Namensnennung – Nicht Kommerziell – Keine Bearbeitung) lizenziert. Er ist Teil des Buchprojekts “Menschen im Projekt”. Er gehört zum Abschnitt 3A, siehe Mindmap zu Inhalt und Struktur.

In der EN ISO 9000:2005 findet sich folgende Definition:

Ein Projekt ist ein einmaliger Prozess, der aus einem Satz von abgestimmten und gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Kosten und Ressourcen ein Ziel zu erreichen, das spezifische Anforderungen erfüllt.

Diese Definition ist weitreichend und beinhaltet auch schon einen Hinweis auf das Projektmanagement. Sie ist allerdings meines Erachtens in Bezug auf das “Ziel” noch nicht präzise genug. Um den Begriff des Zieles besser zu fassen, lohnt es einen Blick auf die Entstehung eines Projektes zu werfen. Am Anfang steht die Idee etwas Neues zu erschaffen. Das “Neue” kann ein neues Produkt, eine Software, eine Organisationsform oder etwas anderes sein. Wichtig ist dass sich das Ziel (in messbarer Form) beschreiben lässt. Die Beschreibung des Ziels stellt gewissermaßen die Dokumentation der oben genannten spezifischen Anforderungen dar. Ein Aspekt, der in obiger Definition nicht bzw. nur implizit enthalten ist der folgende: Das Ziel eines Projektes ist schwierig zu erreichen und übersteigt die Kapazität und die Fähigkeiten eines einzelnen. Zum Projektstart ist es eine arbeitende Gruppe, im Laufe des Projektes sollte aus der Gruppe möglichst schnell ein Team werden.Die Arbeit in einem echten Projekt muss also von einer Gruppe von Menschen geleistet werden. Die Gruppe von Menschen, die im Projekt arbeitet benötigt zudem ein organisatorisches Arbeitsumfeld, das sich von dem unterscheidet in dem die Mitarbeiter außerhalb des Projekts arbeiten. Dies ist von großer Bedeutung, da in vielen Projekten die Mitarbeiter aus unterschiedlichen Abteilungen oder Organisationen stammen. Ich möchte daher die Definition um die Aspekte “komplexes Ziel”, “Projektteam” und “temporäre Organisation” ergänzen und in Form einer Mindmap darstellen.

Und wozu die ganze Wortklauberei ?

Nicht überall wo Projekt drauf steht ist auch Projekt drin. Viele Aktivitäten oder Vorhaben werden leichtfertig als Projekt bezeichnet. Oft wird für ein Projekt ein spezielles Vorgehensmodell eingesetzt oder bestimmte Regularien müssen eingehalten werden, die eine einfachere Nicht-Projekt-Aufgabe gehörig erschweren können. Eine saubere Definition und Prüfung, ob für ein Vorhaben wirklich ein Projekt benötigt wird, ermöglicht eine bewusste Entscheidung für Projekmanagement oder für eine andere passendere Managementform. Am Beispiel des Statusberichtes, der in irgendeiner Form Bestandteil jedes Projektverfahrens, ist wird die Bedeutung dieser Entscheidung deutlich. So ist z.B. eine Aufgabe, die von einem Mitarbeiter alleine bewältigt werden kann, kein Projekt. Es macht keinen Sinn die Arbeitszeit noch mit Schreiben von Projekt-Statusberichten zu vergeuden. Sein Arbeitsfortschritt muss sich problemlos von seinem normalen Vorgesetzten verfolgen lassen. Falls dies nicht funktioniert besteht eher ein Führungsproblem, das sich auch mit Projektmamnagement nicht lösen lässt. Für Vorhaben, die mehrere Mitarbeiter mit ähnlichen und wenig komplexen Aufgaben beschäftigen, gilt entsprechendes. Erst wenn die Aufgabe groß und komplex wird und mehrere Mitarbeiter mit unterschiedlichen Aufgaben betraut werden müssen, lässt sich der Arbeitsfortschritt nicht mehr im Rahmen der normalen Organisation und durch die direkten Vorgesetzten überwachen. Jetzt ist es an der Zeit ein Projekt zu definieren, die notwendige Projektorganisation aufzubauen und mit dem Projektmanagement zu beginnen.

Merke: Projektmanagement lohnt sich erst ab einer bestimmten Größe und Komplexität der Aufgabe.