Wer mich einmal von einer anderen Perspektive als der Projektsicht kennen lernen will sollte zur Vernissage am 17. März 18:00 Uhr kommen. Ich werde vor Ort sein und auch eine kurze Einführungsrede zu den gezeigten Bildern halten.

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.

Jens Hofmann fragt Sind Projekte schädlich für Ihr Unternehmen? . Er greift die Fragestellung auf ob der Projektbegriff in einer agilen Welt überhaupt sinnvoll ist. Auch die umfangreiche Diskussion ist sehr spannend. Roland Dürre denkt in seinem Unternehmertagebuch über diese Diskussion noch weiter nach: Unternehmertagebuch #66 Was ist das eigentlich – Projekt Management? (Definitionsversuch II)

Selbst dieses wahrhaft erschreckende Beispiel wurde inzwischen getoppt. Eine “irgendwas” Implementierung, die sich Scrum nennt, verzichtet praktisch auf alles was Scrum ausmacht. Keine der Rollen ist besetzt, es gibt kein Backlog, daily scrum findet nicht statt. Das Einzige was es gibt sind “Sprints”. Dafür wird deren Ergebnis von außen vorgegeben. Sprints – das hört sich so schön schnell an, da kommt mehr dabei heraus – außerdem lassen sich Teams schneller takten, die Leute leisten mehr. Ein minimales agiles Zugeständnis gibt allerdings noch: Kundenvertreter wurden mit ins Team gesteckt. Das Mikromanagement wird durch Gruppendruck ersetzt. Die Arbeitsbelastung steigt und steigt. Gleichzeitig steigt die Angst aufzubegehren, weil der Druck von zwei Seiten kommt.

Mir schwillt der Kamm wenn ich so etwas erlebe. Sicher möchte ein Arbeitgeber, dass die Arbeitsergebnisse zählbar und gut sind. Wenn es aber nur noch um Taktung geht, die Mitarbeiter ausgepresst werden und jede Idee, die noch mehr Leistung verspricht, völlig einseitig aufgesetzt wird, hat der “Scrum-but”-Spaß ein Ende. Ja – ein gutes Team kann große Leistungen erbringen. Um diese zu erbringen benötigt es aber die eigenverantwortliche Freiheit selbst zu bestimmen was im nächsten Sprint erledigt werden soll. Organisationen, die derartige “Scrum-irgendwie” Ansätze verfolgen, handeln in meinen Augen unethisch. Die Dualität von Rechten und Pflichten, die Verantwortung für die Mitarbeiter wird ignoriert. Ich befürchte, dass der geschilderte Fall kein Einzelfall ist. Möglicherweise werden viele Änderungen, die unter den Flaggen “agil”, “Team”, “Verantwortung” usw. segeln insgeheim nur vorgenommen um den Leistungsdruck erhöhen zu können.

Eine (ggf. höhere) Leistung, die aus echter Verantwortung der Mitarbeiter resultiert, ist nicht von heute auf morgen zu bekommen. Die Einführung neuer Arbeitsweisen – wie z.B. Scrum – wird in der Regel die scheinbare Leistung erst einmal verringern. Es ist vergleichbar mit einer Investition – auf die Rendite muss man ein wenig warten.

Warum schreibe ich das Ganze? Ich hinterfrage gerade selbstkritisch ob all die Lobeshymnen für die häufig genannten Ansätze nicht kontraproduktiv sind. Eine kurze Übung auf einem Scrum-Training, die eindrucksvoll demonstriert wie schnell und um welche Größenordnungen sich die Geschwindigkeit für eine bestimmte Aufgabe im Team erhöhen lässt ist das Eine. Den langen Weg diesen Effekt auch bei komplexen Aufgaben zu erzielen ist das Andere. Die Verheißung eines Hochleistungs-Teams erinnert mich ein wenig an die Renditeversprechen von Wertpapieren. Im Gegensatz zum reinen Finanzmarkt geht es in Projekten jedoch um reales Arbeiten – dazu gehört auch Anstrengung und zwar von ALLEN Seiten.