Ãœber Etikettenschwindeleien im Projektgeschäft hatte ich schon letzte Woche geschrieben, sie sind auch Thema des heutigen Cartoons. Darüber hinaus möchte ich den Gedanken von Jens Hofmann aufgreifen, der die Fragestellung ob der Projektbegriff in einer agilen Welt überhaupt sinnvoll ist diskutiert hat. Ich stimme ihm zu, dass sich der Projektbegriff nicht überholt hat, ich kann aber auch die radikale Gegenposition, dass der Projektbegriff überflüssig sei ein Stück weit nachempfinden. Warum? Der Projektbegriff wird m.E. bis zur Schmerzgrenze und darüber hinaus überstrapaziert. Projekte wohin man schaut, Projektleiter, Teilprojektleiter, Projektmanager, Projektmanagement-Büros, PM-Systeme und vieles mehr geistern durch die Organisationen und Firmen und versuchen Probleme zu lösen, die es ohne die Pseudoprojekte nicht gäbe. Ist das übertrieben? Ich möchte das Problem gewissermaßen aus der Froschperspektive der ursprünglichen Definition eines Projektes angehen und stelle die Frage: “Was ist ein Projekt?” Ein Projekt hat folgende Merkmale:

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  1.

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  2.

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. [↩]