Warum Projekt Management?

Brauchen agile Systementwicklungs und -integrationsprojekte klassisches Projektmanagement? Unter Umständen macht das Sinn. Ein Überblick….

Bei allen agilen Entwicklungen der letzten Jahre kommt leicht die Frage hoch, was denn mit dem mitunter als „klassisch“ gekennzeichneten Projektmanagement ist. Es schien sich zeitweilig auf ein Abstellgleis zu begeben. Aber gänzlich abgeschrieben wurde es dann doch nicht. Unter Anderem zeigt sich das, wenn man sich den Anfragen auf dem Markt für freiberufliche Projektmanager anschaut. Dort aber auch in verschiedenen Publikationen sieht man in diesem Zusammenhang häufig den Begriff „Hybrides Projektmanagement“. Gemeint ist die kombinierte Anwendung von agilen und klassischen Prinzipen und Methoden.

Zunächst eine Klarstellung: Agile Methoden, wie beispielsweise Scrum oder Kanban sind von ihrem Ursprung her primär Software-Entwicklungs- und weniger Projektmanagement Methoden. Beispielsweise redet Mike Cohn als einer der wichtigen Vordenker von Scrum von „Software development using Scrum“ und eben nicht von „Project management using Scrum“(1).

Bekanntermaßen umfasst Scrum auch Management Aspekte, in dem es beispielsweise Vorschläge macht zur Gestaltung von Meetings (Daily/Stand-up), Planung (inkrementell, Sprints, Backlog) und Führung (facilitierend, self-organizing). Gleichwohl haben Entwicklungs-technische Aspekte ein großen, wenn nicht sogar größeren Bedeutung. Gemeint sind hier Prinzipien und Praktiken wie Continuous Integration, Continuous Improvement, Pair Programming, weniger Dokumentation vorab und stattdessen mehr Interaktion mit dem Benutzer, Design for Change, Test Driven Development und Fokus auf Test Automation.

Dabei zu bedenken ist, dass „klassisches“ Projektmanagement zu all diesem keine Aussagen trifft, gleichwohl diese Praktiken auch keineswegs ausschließt, ist sie doch schließlich keine Entwicklungsmethodik.

Man kann Scrum selbstverständlich in Projekten anwenden die Software Entwicklung umfassen, aber eben auch hervorragend in Situationen, wo es sich gerade nicht um ein Projekt handelt, sondern um eine operative/betriebliche Situation; nicht jede Software Entwicklung ist gleich ein Projekt.

Projekt oder nicht; wo liegt der Unterschied?

Ein Projekt hat für den Beteiligten einen Charakter von Einzigartigkeit und Einmaligkeit. Es hat ein klares zeitlich und inhaltlich begrenztes Ziel, worauf hingearbeitet wird. Das Team wird/wurde einzig und allein zum Erreichen dieses Ziels zusammengestellt und stammt sehr wahrscheinlich aus verschiedenen Organisationseinheiten oder gar Unternehmen. Dabei ist schon klar absehbar, wann es aufhören wird zu existieren. Das Projekt-Ergebnis ist für die beauftragende Organisation strategisch bedeutend. Es markiert u.U. sogar einen Meilenstein in der Organisationsgeschichte. Es stellt nicht lediglich eine von viele Schritten dar, sondern die Vollendung einer Reise, die im Idealfall einer klaren Vision entsprungen ist.

PMI drückt dieses kurz und knapp zusammengefasst folgendermaßen aus: „a temporary endeavor, undertaken to create a unique product, service or result” (2)

In einer operativen Situation existiert ein festes Team, dessen Lebensdauer nicht explizit definiert ist. Es wird in einer Art Fabrikmodus gearbeitet und das einen nach dem anderen Release turnusmäßig - augenscheinlich unendlich - produziert. Die einzelnen Releases übergeordnete Entwicklungstätigkeit solch eines Teams unterstützt somit zwar die (strategischen) Organisationsziele, stellt aber in sich selbst kein zeitlich und inhaltlich definiertes Ziel dar.

Nicht selten begegnet man einer Situation, die als Projekt wahrgenommen oder gar bezeichnet wird, sich bei genauerer Betrachtung aber eher als operatives Geschäft erkennen lässt. Das ist zum Beispiel der Fall, wenn vor einigen Jahren ein neues CRM-System als Projekt entwickelt und eingeführt wurde, das Team weiterhin existiert und über Jahre weitere Releases mit neuen Features produziert. In der Unterscheidung zwischen einem Projekt und dem operativen Betrieb gibt es oft eine gewisse Grauzone.

Zurück nun zur ursprünglichen Frage; warum Projektmanagement? Oder anders gesagt; wann macht Projektmanagement sinn?

Klar ist, dass in einer operativen Situation Projektmanagement wenig Mehrwert liefert. Dagegen kann Anwendung einer Entwicklungsmethodik wie Scrum in solch eine Situation sehr hilfreich sein. Die darin enthaltene Management-Komponente hinsichtlich Planung und Verfolgung von Aufgaben reicht hier völlig aus.

Scrum hat hier in den vergangenen Jahren sehr viele Verbesserungen gebracht, vor allem dort wo vorher keinerlei definierte Methodik angewendet wurde oder versucht wurde, hier fälschlicherweise Projektmanagement anzuwenden in dem jeder noch so kleine Anfrage aus dem Fachbereich als „Projekt“ deklariert wurde.

Kommen wir nun zu „echten“ Projekte.

Braucht man hier Projektmanagement? Oder reicht auch hier die Anwendung einer Entwicklungsmethodik wie Scrum aus?

Die Antwort lautet: es kommt darauf an.

Unternehmerisch betrachtet ist jedes Projekt ein Investment, sprich: eine zielgerichtete Anwendung von knappen Ressourcen. Knapp in dem Sinne, dass diese Ressourcen auch anderweitig hätten angewendet werden können. Mit der bewussten Entscheidung für die Durchführung des Projektes hält das Unternehmen also die gewählte Anwendung für die am meist gewinnbringenden (im weitesten Sinne).

Dieser Entscheidungs-Aspekt im Falle eines Projektes und dabei die Tatsache, dass hier von gewissen Annahmen und Erwartungen ausgegangen wird, ist elementar. Denn der ureigene Sinn von Projektmanagement besteht genau darin dieses zu überwachen beziehungsweise die Maßnahmen durchzuführen die dazu führen, dass die unternehmerischen Erwartungen der Auftraggeber (Investitionsrendite) weiterhin getroffen werden. Und dabei immer wieder zu prüfen, ob die Investitions-Entscheidung weiterhin valide ist oder vielleicht revidiert werden muss, sprich das Projekt aufgelöst und die Ressourcen umgeschichtet werden sollten.

Die Frage, ob und wenn ja wieviel Projektmanagement ein Projekt braucht, hängt in erster Linie von der Haltung der beauftragenden Organisation und Personen bezogen auf der oben beschriebene Investitionsbetrachtung ab:

• Betrachten sie ein Projekt tatsächlich als eine Investitionsentscheidung, was sich beispielsweise daran erkennen lässt, dass ein Business Case erstellt und dann auf dessen Basis zur Durchführung des Projektes entschieden wurde ? Oder halten sie das Projekt vielleicht einfach für alternativlos?

• Wollen oder müssen sie ihre Investitionsentscheidung sehr explizit überwachen?

• Wie genau rechnen die Auftraggeber, wenn sie entscheiden?

• Besteht eine Organisationskultur mit extensiven und sehr genauen Kalkulationssheets, Budgetverantwortung und Berichten?

Wann braucht man es nicht?

In einigen Fälle werden oben beschriebene Fragen ablehnend beantwortet. Das spricht dann eher weniger dafür Projektmanagement Methoden an zu wenden, jedenfalls nicht im vollem Umfang.

Ein weiterer Faktor is die vom PMI beschriebenen Einfluss der Organisationsstruktur auf Projekte. Sie macht dabei einen Unterschied zwischen Projekt- und Nicht-Projekt basierten beziehungsweise funktional aufgestellte Unternehmen. Beide werden zueinander in einer Matrix dargestellt (2):

Organizational structure influences on projects (Quelle: PMI)

Projekte, die in funktional oder als „schwache Matrix“ aufgestellten Organisationen stattfinden, und wo dem Projektmanager wenig Autorität zugesprochen wird, verlangen weniger Projektmanagement Methodik.

Manchmal legt der Auftraggeber seinen Fokus rein auf den zeitlichen Aspekt und sieht Projektmanagement lediglich als all das, was derjenige tut der sich darum kümmert, dass „alle Aufgaben erledigt werden“; der Projektmanager betrachtet er als „Kümmerer“. Eine Aufgabenliste mag in solch einem Fall eventuell ausreichen.

Wann braucht man es wohl?

Es gibt im Wesentlichen drei Gründe für die Anwendung von Projektmanagement, die ich nachfolgend beschreibe:

1. Investitionsüberwachung

2. Überwachung externe Abhängigkeiten

3. Selbst- und Teamorganisation

1. Investitionsüberwachung

Projekte, dessen Auftraggeber eine Investitions-Überwachung verlangen, brauchen Projektmanagement im klassischen Sinne, nach allen Regeln der Kunst. Konkret bedeutet dies, dass das allbekannte „Projektmanagement-Dreieck“ im Vordergrund steht:

1. Inhalt (Qualität)

2. Zeit

3. Budget

Die Investitionsentscheidung des Auftraggebers geht mit einer Renditeerwartung einher, die auf eine bestimmte Annahme basiert, was das inhaltlichen Ergebnis angeht (Inhalt), wann dieses geliefert wird (Zeit) und wieviel es kosten wird (Budget).

Diese drei Dimensionen des Projektes müssen nun so balanciert werden, dass die Renditeerwartung erfüllt wird; die Kernaufgabe des Projektmanagers.

Es möge deutlich sein, dass dies nicht etwas Statisches ist, sondern sich dynamisch ändernde Umstände entlang aller drei Dimensionen miteinschließt. Zentraler Punkt ist, dass es dem Auftraggeber zu jedem Zeitpunkt möglich sein sollte auf Basis einer immer wieder den sich ändernden Umstände angepassten, geplanten Zustand über seine Investition informiert erneut zu entscheiden. Dieses steht und fällt mit fundierten und realistischen Schätzungen, sowie Planung.

Die hier oben beschriebene Situation wird vornehmlich auf Organisation zutreffen die in der PMI Terminologie als „Projectized“ oder „Strong Matrix“ gekennzeichnet werden.

2. Überwachung externe Abhängigkeiten

Aber auch wenn keine Investitionsüberwachung (vom Projektmanager) verlangt wird, kann die Anwendung von klassischen Projektmanagement Methoden sinnvoll sein. Das ist insbesondere der Fall, wenn bedeutsame externe Abhängigkeiten existieren, die eine gründliche und übergreifende Überwachung von Zeit und Inhalt verlangen. Zum Beispiel ist in Zusammenhang mit dem Abschluss eines Projektes welchem Prozesse automatisiert eine Personalabbau geplant. Manchmal gibt es gesetzliche Vorgaben für eine Umsetzung. Eine Zusammenführung zweier Unternehmen und ihre vollständige IT-Integration kann zu umfangreichen und komplexen Abhängigkeiten führen, die eine genaue Planung und Projektmanagement zur dessen Einhaltung verlangen.

3. Selbst- und Teamorganisation

Selbst wenn weder Investition noch externe Abhängigkeiten zu überwachen sind, kann Anwendung von Projektmanagement Methoden unter Umstände sinnvoll sein. Denn sie helfen auch dem Projektmanager selbst seine koordinierende Arbeit, sowie die Arbeit im Team zu organisieren und helfen damit auch seinem Team. Das gilt insbesondere bei komplexen Projekten.

So kann es beispielsweise sogar dann noch sinnvoll sein einen Statusbericht zu erstellen, wenn es von niemandem gelesen wird (wer kennt das nicht), in dem das Erstellen dem Projektmanager hilft (zwingt) über sein Projekt nachzudenken, sich über Zustände zu informieren, Prioritäten zu stellen und auf Probleme zu antizipieren.

Ein gut erstellter Projektplan liefert einem Projektteam Orientierung und Motivation; es befriedigt das Bedürfnis der Beteiligten, die wissen wollen, wohin die Reise (über den nächsten Sprint hinaus) führt.

Nicht zuletzt bieten Projektmanagement Methoden sehr gute Anhaltspunkte für das Management von Programmen und Projektportfolien.

Schließen agile Methoden und „klassisches“ Projektmanagement sich gegenseitig aus?

Aus den oben beschriebenen Ausführungen sollte sich erkennen lassen, dass dem nicht so ist. Beide bedienen unterschiedliche Bedürfnisse und ergänzen sich gegenseitig; Jedes Software Entwicklungsprojekt braucht so oder so eine Entwicklungsmethodik; so viel ist klar. Und momentan existiert ein breiter Konsensus, dass agile Methoden, allen voran Scrum, hier das Mittel der Wahl sind.

Dieses kann beziehungsweise sollte gegebenenfalls um „klassisches“ Projektmanagement ergänzt werden.

Ob und wenn ja wie viel ist in Abhängigkeit von der Erwartungshaltung des Auftraggebers, bzw. Umstände im Projekt, wie oben ausgeführt zu bestimmen.

Literatur:

(1) Mike Cohn: Succeeding with Agile – Software Development using Scrum, Addison-Wesley, Mai 2010

(2) Project Management Institute (PMI): Project Management Body of Knowledge (PMBOK)