Wie gehen wir an das nächste Projekt heran? Klassisch oder agil? Was sind die Vor- und Nachteile der einzelnen Methoden? Aus meiner Sicht sind dies die falschen Fragen.
Es gibt in den sozialen Netzwerken regelmäßig Diskussionen über klassische und agile Projektarbeit (hier ein aktuelles Beispiel aus meiner Filterblase: https://www.linkedin.com/feed/update/urn:li:activity:6831095849062297600/). In solchen Gedankenaustauschen ist der Kontext nicht klar genug definiert. Jeder Teilnehmer ist zugleich im Recht und im Unrecht. Hinzukommen Anekdoten und Mythen, die alle in einen Topf geworfen werden. Ich kann einer einzelnen Person nicht widersprechen, die ihr Kraftwerk klassisch oder agil gebaut hat. Das ist die Erfahrung dieser Person. Selbst wenn ich im selben Projekt war, habe ich das vielleicht anders wahrgenommen.

Auf die gleichen Probleme treffen wir bei jeder Diskussion: Was ist Digitalisierung? Wie verbessern wir das Schulwesen oder die Arbeit in unseren Krankenhäusern?
Als mündige Bürgerin oder Bürger, als mündige Mitarbeiter*innen brauchen wir eine gemeinsame Basis für die Diskussion. Wir können die Arbeit nicht allein Experten überlassen, weil es auch um unsere Entscheidungen geht. Sei es auf politischer Ebene, sei es im persönlichen Arbeitsalltag. Die klaren Begriffe machen Zusammenarbeit möglich.
Was ist Projektarbeit?
Ich habe zwei Punkte, durch die ich Projektarbeit seit langem definiere:
- Projektarbeit bedeutet, Ergebnisse unter Unsicherheit zu liefern.
- Projekte werden nicht genehmigt, sondern finanziert.
Heute würde ich beim ersten Punkt noch „gemeinsam“ ergänzen: Projektarbeit bedeutet, gemeinsam Ergebnisse unter Unsicherheit zu liefern.
Diese (persönliche) Definition lenkt meine Aufmerksamkeit auf folgende Dinge:
- Welche Ergebnisse brauchen wir?
- Wie arbeiten wir dafür zusammen?
- Woher kommt die Unsicherheit (am Markt, bei der Technologie, in der Zusammenarbeit, beim Zeitdruck)?
- Warum haben wir bei dem ganzen Aufwand trotzdem am Ende einen Vorteil?
Das ist aus meiner Sicht die Essenz von professioneller Projektmanagementliteratur (u. a. PMBoK, PRINCE2, GPM/IPMA, Earned Value Management/ANSI 748C, Shenhar/Dvir, Scrum, Cynefin).
Bevor wir über Methoden reden, wäre es aus meiner Sicht angebrachter, diese Fragen zuerst zu klären.
Wie kommen wir zu klaren Begriffen?
Das Problem bei den Diskussionen, wie wir sie am Beispiel „klassische Projektarbeit vs. Agilität“ sehen, liegt in den unklaren Begriffen. Wir benutzen vielleicht sogar die gleichen Fachbegriffe, aber sind wir uns einig, was alles an diesem Begriff hängt? Für die eine Person bedeutet Agilität vor allem Scrum und XP, für die andere Person ist es ein Führungskonzept.
Ich nutze drei Wege, um die Begriffe zu klären.
- Ideengeschichte: Eine Ideengeschichte beschreibt nicht die Historie der Ereignisse, sondern wie Begriffe entstanden sind und sich weiterentwickelt haben. Für die Ideengeschichte des Projektmanagements fand ich die Werke von Morris, Shenhar/Dvir und Lenfle/Loch sehr wichtig.
- Literature Reviews: Wenn ich noch nicht genug verstehe, gebe ich bei Google Scholar mein Thema + „literature review“ ein. Wenn ich Glück habe, hat sich jemand schon einmal die Mühe gemacht, die wesentliche Literatur zum Thema zu beschreiben.
- Diskussionen mit Bildern: Ich diskutiere die Begriffe mit anderen. Am besten zeichnen wir dazu ein Modell, um die Begriffe abzugrenzen oder Schnittmengen zu finden.
Der Aufwand für die Recherche der Ideengeschichte ist sicherlich der größte und dauert zum Teil Jahre. Eine Literaturrecherche liefert schon nach einem halben Tag brauchbare Ergebnisse. Die Diskussion im Team geht eigentlich immer und führt schon nach wenigen Minuten zu zufriedenen Gesichtern.
Vorteile von klaren Begriffen
Ohne eine gemeinsame Sprache drehen wir uns nur im Kreis. Gemeinsame, klare Begriffe sind das gedankliche Gerüst, mit dem wir unser Ideenbauwerk aufrichten können. Sie sind tragfähig und gestatten uns in die Höhe zu bauen. Das Bauwerk hält, weil das Fundament hält. Es ist die Basis für Fortschritt und Innovationen in Prozessen und Produkten.

Stellen wir uns ein Projektteam vor, das sich vor allem mit dem PMBoK und PRINCE2, nicht aber mit Scrum oder Agilität auskennt. Es hat sich ein solides Verständnis der Begriffe „Ergebnis“ und „Unsicherheit“ erarbeitet. Es findet heraus, dass es eine gute Strategie, mit Unsicherheit umzugehen, ist, häufiger Feedback einzuholen. Je höher die Unsicherheit, desto mehr Feedback. Es ändert an seiner bisherigen Arbeitsweise fast nichts. Aber es verkürzt die Zyklen, an Feedback zu gelangen. Innerhalb der vereinbarten, mehrmonatigen Projektphasen legt das Team von Woche zu Woche fest, welche Ergebnisse es sehen will und wie man möglichst viel Feedback erzeugt.
Wie Wissenschaftler notieren sie ihre Erkenntnisse. Sie lernen, wovon die Ergebnislieferung abhängt. Sie erfahren, wie viel Vorlauf bestimmte Lieferanten tatsächlich brauchen oder wie viel Puffer auf bestimmte Aktivitäten aufgeschlagen werden muss. Sie finden früh heraus, welche Alternativen es noch gibt. Das Team verbessert so seine Planungs- und Steuerungsfähigkeiten.
In den Köpfen der Teammitgliedern haben sich die PM-Fachbegriffe in ganz konkrete Vorstellungen verwandelt, mit denen sie intuitiv umgehen.
Nehmen wir uns doch bei der nächsten hitzigen Diskussion eine Auszeit und fragen einander: Was bedeutet für Dich dieser Begriff? Was noch? Was hängt damit zusammen, was nicht? Gibt es gemeinsame Begriffe für uns? Wo liegen wir auseinander?
Alle Projektteams wollen gute Ergebnisse liefern.