Das Monopol der Projekte

In der heutigen Arbeitswelt sind Projekte das Standard-Organisationsmittel geworden, um interdisziplinär zusammenzuarbeiten. Ich habe manchmal den Eindruck, als ob viele Leute gar keine andere Möglichkeit (mehr) kennen. Darüber hinaus hat sich in den letzten Jahrzehnten die Anzahl der gleichzeitig laufenden Projekte pro Organisation drastisch erhöht. Der Projekte-pro-Mitarbeiter-Quotient liegt heute im Industrieschnitt bei 5-7, die Spitzenwerte liegen bei über 14!

Ich werde häufig gefragt, ob und wie man in bei einem solchen Umfeld agil arbeiten kann. Meine Gegenfrage daraufhin lautet, wie man denn unter solchen Bedingungen überhaupt arbeiten kann! Sechs Projekte bedeuten ja auch sechs Projektmeetings, sechs Projektleiter sowie ständige Prioritäts- und Aufgabenwechsel.

Im folgenden Artikel möchte ich einmal beleuchten, wie sich das Arbeiten in Projekten historisch entwickelt hat, was das heutige Monopol der Projekte bewirkt und welche Alternativen es gibt, insbesondere bei Produktherstellern, bei denen sich die Projekte oft stark ähneln.

Produktentwicklung gestern

Arbeiten in der fachlichen Linie

• Durch die erste Spezialisierungswelle in der Industrie war es erst einmal natürlich, dass Abteilungen nach Wissensbereichen und Tätigkeiten strukturiert wurden, da der Vorgesetzte i.d.R. selbst das beste dazu gehörende Wissen hatte (Beispiel: Verkauf, Werkstatt, Einkauf)
• Diese Strukturen wurden auch auf die Produktentwicklung übertragen (Beispiel: Elektronik-Entwicklung, Mechanik-Entwicklung)
• Dies hatte die Vorteile, dass Mitarbeiter, die die gleichen Tätigkeiten hatten und die gleichen Werkzeuge einsetzten, voneinander lernen konnten und im Bedarfsfall Arbeiten voneinander übernehmen konnten
• Einfachere Arbeiten konnten so gut erledigt werden, da die Koordination über die Vorgesetzten geregelt wurde.

Anmerkung: Viele Organisationen verwenden heute noch dieses Modell und nutzen zusätzlich das Projekt und den Projektleiter zur Definition der Arbeiten, wobei die Verteilung und Priorisierung weiter beim Gruppenleiter liegt oder jeder Mitarbeiter (mindestens) zwei Chefs hat, was gerne als Matrixorganisation bezeichnet wird.

Projekte als Ausnahme für komplexe Vorhaben

Erste Projekte

• Für komplexere Vorhaben wurden interdisziplinäre Projekte eingeführt, bei denen die Mitarbeiter direkt über einen Projektleiter koordiniert wurden.
• Für Projekte wurden Mitarbeiter i.d.R. zu 100% abgestellt
• Die Projekte waren Ausnahmefälle
• Beispiele für frühe große Projekte:
  • Manhattan-Projekt: Bau der ersten Atombombe
  • Apollo-Programm: erster Flug zum Mond

Heute: Das Projekt als Standardorganisationsform

• Heute wird nahezu jede Entwicklungsarbeit in einem Projekt organisiert. Es gibt schlicht keine andere Idee der interdisziplinären Zusammenarbeit
• Die heutigen Produktentstehungsprozesse schreiben das Arbeiten in Projekten meist sogar vor!
• Bei kleineren Projekten werden Mitarbeiter zu Projektleitern. Dies ist häufig auch die einzige Möglichkeit beruflich aufzusteigen, neben einem Aufstieg in das Linienmanagement. Dies betrifft hauptsächlich Organisationen, die keinen technischer Karrierepfad vorsehen. Damit wechseln oft brillante Techniker (Wissenträger) in eine Managerlaufbahn, in der sie ggf. nicht so brilliant sind.
• Bei mehreren Bearbeitern aus einem Silo der Linienorganisation wird meist ein Mitarbeiter zum Fachgruppenleiter, der dann „sein Team“ in den Projekt-Meetings vertritt, was zu „Stille-Post-Effekten“ und Missverständnissen führt.

Ungünstige Folgen und Auswirkungen

• Jeder bedient mehrere bis viele Projekte
• Die Anzahl der (Projekt-)Meetings nimmt stark zu → Die Kalender sind voll
• Mitarbeiter können nicht mit anderen Projektmitgliedern zusammensitzen und arbeiten → Effektive Kommunikation geht verloren
• Mitarbeiter müssen irgendwie selbst einschätzen, wann und wie viel sie für welches Projekt arbeiten. Persönliche Prioritäten durch Vorlieben und Aversionen führen zu Projektverzögerungen
• Mitarbeiter dienen mehreren Herren: Hoher Druck führt zu Überlastung der Mitarbeiter → niedrigere Motivation und Leistungsbereitschaft
• Projektleiter kämpfen gegeneinander um Mitarbeiter und Ressourcen → Diese werden zu 100% (manchmal mehr!) verplant und ausgelastet
• Die Projekte sind stark miteinander verkoppelt: Kleinste Änderungen haben große Auswirkungen (Stau) → Abteilungen versuchen sich lokal zu optimieren um vermeintlich mehr zu schaffen
• Das Management hat keinen Überblick mehr, was die Organisation als Ganzes leisten kann. Da Projekte regelmäßig zu spät liefern, werden zu viele neue Projekte gestartet → Das Vertrauen des Managements in die Organisation geht verloren → Terminpläne werden zwischen Produktmanagement und Entwicklung verhandelt, da der (leider richtige) Eindruck entsteht, dass die Entwicklungsorganisation zu langsam ist
• Zusätzliche „Task Forces“ (noch mehr Projekte!) können einzelne Vorhaben retten, verzögern aber alle anderen Projekte um so mehr

Beliebigkeit des Projektbegriffs

Ein weiteres Problem ist die Beliebigkeit des Projekts, d.h. die freie Definition:

• Da Projekte immer länger dauern, werden sie immer größer geschnitten, in der Hoffnung dass die Arbeiten dann irgendwie schneller fertig werden.
• Projekte bekommen beliebig kombinierte Ziele. Manchmal machen widersprechende Ziele einen Erfolg von vorn herein unmöglich.
• In großen Entwicklungsprojekten lassen sich z.B. auch mehrere Produktvarianten mit stark unterschiedlichem Nutzen bündeln. Wenig wertschöpfende Produktvarianten können so durch Bündelung „versteckt“ werden, da Projekte im Projektportfolio meist als ganzes priorisiert werden

Was können wir tun? Den Teufelskreis durchbrechen!

• Die Organisation so umbauen, dass der Großteil der Arbeiten wieder in stabilen Teams geleistet werden kann (Projekte als Ausnahme)
  • Interdisziplinäre Teams mit Produktverantwortung (Feature-/Applikationsteams, cyan im P4-Framework)
  • Modulteams mit Komponentenverantwortung (magenta im P4-Framework)
  • Service-Teams  für spezielle Kompetenzen, Expertisen und Themen (z.B. wenn in speziellen Laboren gearbeitet wird; gelb im P4-Framework)
  • Einrichtung von sogn. „ Communities of Practice“ für den Kompetenzaustausch von Mitgliedern interdisziplinärer Teams
• Durch Transparenz die Leistungsfähigkeit der eigenen Organisation wieder einschätzbar und vorhersagbar machen (d.h. auch die jedes einzelnen Teams). Dadurch Vertrauen bei dem Management und bei Stakeholdern zurückgewinnen
• Produktvarianten innerhalb von Entwicklungsvorhaben einzeln bezüglich Nutzen und Aufwand betrachten
• Eindeutige Prioritäten für alle Entwicklungsvorhaben, z.B. durch Ermittlung des ROI (= Nutzen / Aufwand)

To project or not to project: That is the question! Eine Entscheidungshilfe

Hier meine Checkliste für die Entscheidung, ob ein Vorhaben als neues Projekt gestartet werden sollte oder nicht:

• Ist das Vorhaben so einzigartig, dass es eine eigene Organisationsstruktur rechtfertigt?
  • Projektleiter, eigene Meetings, Planungs- und Reporting-Struktur
  • Unsicherheit und Performance-Einbruch zu Beginn durch Teambildungsphasen
  • Negative Beeinflussung der bereits laufenden Teams und Projekte
• Sind geeignete Mitarbeiter und Ressourcen wirklich in ausreichendem Maß verfügbar? Ideal: zu 100%.
• Steigt das Risiko von Verzögerungen durch die Querabhängigkeiten zwischen den laufenden Projekten nur in akzeptablem Maß?
• Sind die Zusammenarbeitsmodelle zwischen den Projektpartnern genügend erprobt, um eine relativ verlässliche Planung zu ermöglichen? (Vertrauen, eingespielte Prozesse, …)
• Sind auch die Stakeholder für eine eigene Organisationsstruktur genügend verfügbar?

Fazit: Oft ist die Arbeit in stabilen Teams die bessere Alternative zum Projekt

Projekte sind eine gute Idee zu Bearbeitung von besonderen Vorhaben. Sie sind aber nicht immer und nicht für alles geeignet. Moderne agile Organisationsformen ermöglichen die Arbeit in stabilen Teams, die trotzdem eine interdisziplinäre Zusammenarbeit ermöglichen, wo dies notwendig und sinnvoll ist. Das hardScrum P4-Framework sieht hierfür die sogenannten „Team-Flavours“ (in etwa Team-Geschmacksrichtungen) vor.

Zu diesem Thema siehe auch Projekte funktionieren nicht in einem Ressourcen-limitierten System.