Scrum ist eine Möglichkeit Projekte durchzuführen. Ich will nicht Scrum abstrahieren, sondern den gemeinsamen Nenner aller Möglichkeiten Projekte durchzuführen finden. Es gibt Dinge (ich habe sie Anforderungen genannt) die in jedem Projekt so oder eben anders gemacht werden müssen. Diese Anforderungen bilden den Rahmen in den sich die konkreten Methoden, wie z.B. ein Product Backlog zur Verwaltung des Umfangs eines Projekts, einsortieren lassen müssten.

Gerade bei Scrum kommt dann aber nichts mehr Vernünftiges dabei raus. Scrum ist bereits auf das Wesentliche zusammengedampft worden, so daß man nichts mehr weglassen kann vom Framework. Dazwischen bietet es allerdings eine Menge Raum für kreative Ausgestaltung ;-).

Danke für Deinen Kommentar! Die Gefahr der Vereinnahmung von openPM in eine Glaubensrichtung ist mir bewusst.

Mich nervt die Forderung nach Standardisierung mit dem Hinweis, dass jede (Dienst)Leistung immer gleich sein müsse. Ich will gar nicht gleichgeschaltete und standardisierte Projektmanager.

Da stimme ich Dir voll und ganz zu: Standardisierung an sich ist ein durch und durch tayloristisches Ansinnen und macht für anspruchsvolle Führungsaufgaben in Projekten keinen Sinn.

Vielmehr müsste man sich endlich überlegen, zu was ein Projektmanager überhaupt fähig ist. Wolf Singer sagt: “Wir sind unfähig, nichtlineare Phänomene zu erfassen. Das klingt zwar abstrakt, erklärt sich aber aus der Evolution: Im Kleinen, und nur darauf ist unser Gehirn eingestellt und nur daran ist es angepasst, verhält sich die Welt linear. Diese Unfähigkeit sei auch kein Wunder, denn nichtlineare Vorgänge sind nicht vorhersagbar, das Hirn als prädiktives System wäre also überfordert”. Anstatt (unrealistische) Praktiken zu diskutieren, wäre es wichtiger, ein paar Schritte zurückzutreten.

Auch das finde ich eine lohnende Denkrichtung. Um zu verstehen zu was ein Projektmanager fähig sein müsste, wäre es meiner Meinung nach sinnvoll erst Mal die paar Schritte von der konkreten Methodik zurückzutreten und zu verstehen was ein Projekt ausmacht, welche Anforderungen man dort findet und wie diese zusammenhängen.

Ist tatsächlich etwas ketzerisch, aber im Kern auch wahr. Ich würde sogar soweit gehen, wenn die Mitarbeiter Spaß an dem haben, was Sie arbeiten, stellt sich Erfolg auch ein. Ich ziehe einen Vergleich mit der Realisierung von openPM. Es gab kein detailliertes Anforderungspapier, keinen CEO/kein Mgmt. Board, geschweige denn Budgets. Trotzdem gibt es die Plattform jetzt. Und alle hatten Spaß daran, das Projekt openPM zu realisieren.

Wobei wir vielleicht in der Diskussion etwas differenzieren müssen, von welchen Arbeiten/Unternehmen/Märkten wir sprechen. Ich denke bei Projekten und Projektmgmt. z.B. immer gleich an IT Projekte :)

Nur ist diese Suche nach den geeigneten Methoden derzeit mühsam. Es gibt zu viele Methoden, die als „silver-bullet“ gepriesen werden ohne je darüber nachgedacht zu haben, welche Anforderung sie lösen, unter welchen Umständen sie anwendbar sind und welche Wechselwirkungen sie mit anderen Methoden haben. Eigentlich müsste jede konkrete Umsetzung einer Anforderung wie ein Medikament einen Beipackzettel bekommen.

Du hast vollkommen recht: jeder Standard, jedes Modell muss angepasst werden. Stur nach Vorschrift angewendet, ist alles gleich schlecht geeignet.

openPM ist ein toller Ansatz, droht aber in der Agilitätsaffinität unterzugehen. Denn so wie PM Verfechter in den 90er sind heute die Agilos am Werk.
“Open your (PM) mind” würde ich allen Methoden-Freaks gerne zurufen … aber ich weiss nicht, ob das ankommt :-)

Doch das kommt an. Im Mission-Statement von openPM gibt es ein ganz wichtiges Wort: Vielfalt. Im Moment fehlt uns allerdings noch ein wenig Struktur, um diese Vielfalt abzubilden. Dazu möchte ich gerne zurück zu abstrakten, allgemein gültigen Anforderungen, um dann über Umsetzungen der Anforderungen mit spezifischen Voraussetzungen, Paradigmen und Rahmenbedingungen.

Interessante Gedanken! Ich picke mir Mal zwei raus.

Unter diesem Licht wären Anforderungen ein hilfreicher Ansatz, die Unterschiede im Bedarf der Welt von heute und morgen gegenüber dem zu verstehen, was uns noch vor Jahrzehnten getrieben hat, dicke Standards zu verfassen

Ich glaube, dass Anforderungen an das Management von Projekten zeitlos sein können und sollten. Jedes Projekt braucht ein gewisses Maß an Planung und Verfolgung beispielsweise. Wie das umgesetzt wird, in welchem Kontext sich die spezifische Umsetzung eignet und in welchem nicht, das wäre zu untersuchen. Da kann es dann auch historische Artefakte geben, also Umsetzungen die zwar früher funktionierten, aber heute nur in Ausnahmefällen anwendbar sind.

Und das bringt mich wieder zu meinem Ausgangsgedanken über die “Konstruktion” von Modellen zurück. Nämlich mit der Frage, ob es bloss um den Einsatz der passenden Methode in der geeigneten Situation geht, oder ob da noch mehr dahinter steckt? Ich glaube an Letzeres – wie wir es in den Scrum Trainings vermitteln … es geht eben nicht um den Scrum-Prozess, um die Artefakte, die Zeremonien … es geht um das Mindset … das Mindset als Grundlage für Lernen, für Veränderung, für Emergenz.

Dem stimme ich zu. Es geht sicherlich um mehr als bloß einen möglichst vollen Werkzeugkasten bereitzustellen. Dennoch könnte ich mir vorstellen, dass ein Cross-over einen gewissen Charme hätte: wenn die verschiedenen Umsetzungen und Methoden nebeneinander stünden, könnten eigentlich agile Methoden in klassischen Projekten Anwendung finden und umgekehrt. Wir könnten ja für jede Umsetzung einer Anforderung definieren / erforschen, welche Paradigmen im Unternehmen bzw. im Umfeld gegeben sein müssen, damit eine Anwendung möglich ist.

Die Beispiele befinden sich ganz bewusst auf der Metaebene. Denn dorthin möchte ich zurück. Nicht zum Selbstzweck, sondern als Fundament und Rahmen. Natürlich will jedes Projekt ein konkretes Ziel erreichen oder ein konkretes Problem lösen. Ich glaube aber, dass das es dafür allgemein gültige Anforderungen gibt, z.B. eben die Festlegung des Umfang, Planung, Verfolgung der Abarbeitung. Und die würde ich gerne von der konkreten Umsetzung und Ausprägung trennen wollen. Nicht um dann auf der Metaebene ein Glasperlenspiel zu betreiben, sondern um im zweiten Schritt sauber über verschiedene Umsetzungen reden zu können, über deren Eignung für bestimmte Probleme und über Abhängigkeiten und Ausschlüsse.

Alles andere spielt aus meiner Sicht keine Rolle.