Projekt

Ich möchte 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 sie teilweise nicht gäbe. Ist das übertrieben? Mag sein – wenn ich das Thema aus der Froschperspektive ausgehende von der Definition eines Projektes angehen lichtet sich schon ein Teil des Nebels.

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 beschrieben?”. Hierzu fallen mir eine ganze Reihe von Antworten und Verdachtsmomente 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 dann auch pragmatisch beschritten werden könnten wäre dagegen wenig einzuwenden. De Realität sieht aber anders aus. Es wird versucht den vielen Pseudo-Projekten mit den falschen 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 Resourcenplanungen, 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

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