09
Nov 2018
Meilenstein – Der Projektmanagement-Blog

Mit agilen Methoden weniger Ressourcenkonflikte?

Ressourcenmanagement wird in Ihrem Unternehmen zwar als sehr wichtig eingestuft, aber sowohl Sie als Projektleiter als auch Ihre Teammitglieder und selbst die Geschäftsführung sind unzufrieden mit der aktuellen Praxis? Damit sind Sie nicht allein. Bis vor fünf Jahren ging es uns bei TPG genauso. Lesen Sie folgende Erfahrungen, wie Ressourcenmanagement besser gelingen kann.

Anzeige

Die Frage im Titel dieses Beitrags kann ich mit einem klaren "JA" beantworten. Agile Methoden verringern Ressourcenkonflikte – aber nur, wenn Sie die dafür nötigen Voraussetzungen etablieren! Seien Sie also auf einen echten Paradigmenwechsel gefasst.

Ressourcenmanagement hat drei Ebenen

Für ein agiles Ressourcenmanagement brauchen Sie dieselben drei Betrachtungsebenen wie im klassischen Bereich:

  1. kurzfristig operative (Tage / Wochen)
  2. mittelfristig taktische (Wochen / Monate) sowie
  3. langfristig strategische (Monate / Jahre).

Diese Anforderung gilt für Unternehmen aller Branchen und Größen. Nur die Umstände und die dazu passenden Lösungen sind nicht überall gleich. Die größten Gemeinsamkeiten gibt es bei der langfristigen Betrachtung. Dort wird die Unternehmensstrategie der Geschäftsleitung über Projekte vorausschauend geplant und umgesetzt. Hier beginnt auch – unabhängig ob agile oder klassische Methoden genutzt werden – das gemeinsame Dilemma, das Sie sicher auch kennen: Es wird immer versucht, mehr ins Portfolio hineinzupressen, als tatsächlich leistbar ist.

Bei Ihnen ist auch immer alles Prio A? Dann müssen Sie auf jeden Fall zunächst ganz oben ansetzen. Sie müssen eine realistische Reihung der Vorhaben in Ihrer Produkt- und Projektlandschaft schaffen. Nachdem es derzeit immer zu viel Arbeit für zu wenig Mitarbeitende gibt, werden Sie auf keiner Ebene des Ressourcenmanagements ohne Prioritäten auskommen.

Geht nicht, gibt´s nicht?

Dieses Credo der Experten ist für die inhaltliche Umsetzung natürlich immer zu begrüßen. Aber eben nicht im Sinne des Ressourcenmanagements: Wenn alle Mitarbeitenden bereits voll ausgelastet sind, dann muss man bei weiteren Forderungen vorher auch was weglassen. Das ist doch ganz einfach. In einen vollen Bus kann erst dann jemand einsteigen, wenn vorher jemand aussteigt. Ein Teammitglied fragt in so einem Fall immer "welchen Teil von NEIN verstehst Du nicht?".

Wenn das Verständnis für die beiden genannten Punkte bei den strategischen Entscheidern fehlt, können Sie im taktischen und operativen Bereich nicht mehr gewinnen. Sie können sich dann höchstens noch irgendwie "durchwurschteln". Spaß macht die Überlastung keinem und die Qualität leidet dabei ganz sicher.

Klassisches Ressourcen Ping-Pong

Im klassischen Projektmanagement führt das dann dazu, dass Teamleiter und Projektleiter in einer Matrixorganisation mit den Ressourcen Ping-Pong spielen. Man hängt immer hinterher und ist ständig damit beschäftigt umzuplanen. Mitarbeitende müssen Aufgaben aus verschiedenen parallellaufenden Projekten erledigen; deswegen müssen sie immer wieder umdenken, das Team wechseln, sich neu zurechtfinden.

Bild 1: Mit klassischen Methoden werden für neue Projekte Teams immer wieder neu zusammengestellt
Bild vergrößern

Außerdem werden Budgets für Arbeitspakete von Sales oder dem Projektleiter vorgegeben, die den zugeteilten Personen oft nicht ausreichen, weil sie bisher vielleicht ähnliche, aber nicht genau diese Art von Aufgaben erledigt haben. Sie benötigen deshalb länger als geplant oder werden zwischendurch zu noch dringlicheren Aufgaben gerufen. Und so hören die Probleme im Ressourcenmanagement nie auf.

Mit agilen Methoden werden auf der kurz- und mittelfristigen Ebene viele dieser Probleme abgefedert oder sogar ganz vermieden. Das führt dann ganz automatisch zu besserem Ressourcenmanagement.

Aber Achtung: das gilt nur unter der Voraussetzung, dass Sie die folgenden Bedingungen erfüllen.

Agile, feste Teams

Wie Sie wissen, werden bei klassischen Methoden zuerst Aufgaben zur Erreichung fester Ziele geplant. Und dazu wird dann versucht, die jeweils geeigneten Personen zu finden, die alle Aufgaben bis zum gesetzten Endtermin erledigen sollen. Es wird solange daran gearbeitet, bis das Ziel erreicht ist.

Im Gegensatz dazu werden bei agilen Methoden zuerst feste Teams gebildet. Das Team arbeitet das selbst geschätzte Backlog in festen Iterationen so ab, dass zwischendurch und am Ende der gegebenen Zeit Ergebnisse vorliegen. Die Ergebnisse müssen nutzbar sein, aber es bleibt bis zum Schluss möglicherweise offen, wie sie genau aussehen.

Festes Team bedeutet, dass es einmal zusammengestellt wird und während der Durchführung unverändert bleibt. Das ist für die auf Dauer angelegte Weiterentwicklung von Produkten recht einfach, für wechselnde Kundenprojekte schon schwieriger. Generell ist dies umso einfacher, je länger das Vorhaben dauern soll und umso wichtiger das Vorhaben ist. Aus Sicht des Ressourcenmanagements ist das auch schon die wesentliche Änderung.

Bild 2: Mit agilen Methoden arbeiten feste Teams möglichst konstant an selbst geschätzten Inhalten
Bild vergrößern

Wenn Sie also drei Produkte haben, bilden Sie drei Teams in passender Größe und lassen diese machen. Sie müssen dann nur noch den strategischen Teil weiter betrachten, also welche und wie viele Produkte Sie künftig entwickeln wollen. Entsprechend sind Teams zu bilden, und fertig.

Wir haben bei TPG seit mehr als fünf Jahren feste Teams in der Produktentwicklung und müssen uns nur um die Neueinstellung von weiteren Mitarbeitern und um die Betreuung innerhalb der Teams kümmern. Ping-Pong spielen wir in der Freizeit, nicht mit unseren Produktentwicklern.

Agiler Ergebnispoker

Ressourcenkonflikte aus der klassischen Welt wandeln sich zu Ergebnisoffenheit in der agilen Welt. Klingt doch auch gleich viel freundlicher. Wird aber in der Praxis genauso hart diskutiert. Nur eben mit anderen Personen und mit vielen Vorteilen.

Bild 3: In vielen Bereichen können Sie Ressourcenkonflikte gegen Ergebnisoffenheit tauschen

Die Diskussion bezüglich Ergebnisse erfolgt im Rahmen der Releaseplanung zwischen Produktmanagement, Entwicklungsteam, Consulting und Sales. Aber eben nicht bezüglich Personen im Rahmen der Ressourcenplanung zwischen Teamleitern und Projektleitern.

Im festen Zyklus von zwei Monaten planen wir die Features des jeweils nächsten Releases, die in vier zweiwöchigen Sprints umgesetzt werden sollen. Der Vorteil ist, dass das Team selbst geschätzt hat und sehr gut weiß, was es leisten kann. Außerdem sind alle Teammitglieder eingearbeitet und auf ein Produkt fokussiert, denn interne ungeplante Ablenkungen werden ferngehalten. Das macht mehr Spaß und führt automatisch zu mehr Durchsatz und Qualität.

Das ist für die intern gesteuerte Produktentwicklung natürlich einfacher als für extern beauftragte Kundenprojekte. Es denken aber immer mehr Kunden auch in diese Richtung, weil sie mittlerweile intern auch so arbeiten. In einem weiteren Beitrag werde ich dieses Thema noch näher beleuchten.

Ressourcenmanagement ist am Ende eine Kulturfrage

Je nach Unternehmenskultur ist Ressourcenmanagement eine recht heikle Angelegenheit – oder auch nicht. Mit klassischen Methoden sind Sie mehr damit beschäftigt, die richtigen Personen für gegebene Projekte zu finden. Mit agilen Methoden sind Sie mehr damit beschäftigt, die besten Ergebnisse mit dem gegebenen Team zu finden.

Die Auswahl von Methoden, Prozessen und Tools spielt dabei natürlich auch eine wichtige Rolle. Die Zufriedenheit mit dem großen Thema Ressourcenmanagement können aber letztlich nur die beteiligten Personen mit entsprechendem Umgang untereinander selbst herstellen.

Was sind Ihre Erfahrungen zum Thema Ressourcenplanung im agilen Umfeld? Ich freue mich über Ihren Kommentar hier im Blog oder auch per Mail an johanns@theprojectgroup.com.

Bisher gibt es 2 Kommentare
Hallo Herr Strasser,
Sie haben ja damit eröffnet, dass es drei Betrachtungsebenen bei der Verteilung von Kapazität gibt. (Den Begriff „Ressource“ weigere ich mich als Agilist zu verwenden, wenn es um Menschen geht. Rechnerleistung/-ressourcen können sie skalieren. Menschen nicht!)
 
Auf den „kurzfristigen operativen“ Kapazitätsbedarf sind Sie dann aber weder bei der klassischen Projekt-Sicht noch bei der agile Produktorientierung eingegangen.
 
Hier passieren m.E. bei der Einführung agiler Methoden (z.B. Scrum) ein erster großer Fehler: Pilotteams werden nur um die Neuentwicklung eines Produktes herum aufgesetzt. Die, die die Wartung und den Betrieb machen, lassen wir erst einmal heraus…
 
Diese leider viel zu oft beobachtete Herangehensweise führt aber gleich zu mehreren Problemen:
1. Klassenbildung – Wir sind die (guten) Produktentwickler, die im Rampenlicht stehen; ihr seid ja nur die, die gucken, das (zumeist alte) „Haus vor dem Zerfall bewahren“
(Ohne denen würde der ganze Laden aber nicht laufen…)
2. Die Neuentwickler machen; und andere machen die Fehler weg… Die Bindung zum täglichen Alltag geht verloren
3. … weitere Fehlentwicklungen
 
Mein Tipp: Zu den Produkt-Teams gehört Neuentwicklung, Fehlerbehebung und Wartung; wobei die beiden letzteren ggf. weniger gut zu planen sind. Ich verwende für die „un-planbaren Anforderungen“ immer gerne eine vorher mit dem PO vereinbarten Anteil an der Kapazität des Teams, dessen Verbrauch in einem eigenen Burndown Chart dargestellt wird.
(In meinem leichtgewichtigen Sprint Burndown-Excel lasse ich die Kurve „geplante Aktivitäten“ von oben gegen die Kurve „ungeplante Aktivitäten“ zur Null-linie hinlaufen. So sind der zeitliche Werdegang und insbesondere Ausreißer sofort transparent.)
 
Und dann spielen wir auch kein Ping-pong zwischen Neuentwicklung (klassisch: Projekten) und Betrieb: Es liegt in der Hand des PO, sauber die Anforderungen zu priorisieren und damit die Kapazitätsverteilung zu steuern…
 
Diesen Aspekt wollte ich gerne noch nachtragen.
vor 1 Woche 4 Tagen Dieter Bertsch
alt_text
Hallo Herr Bertsch,
Danke für Ihre Ergänzung. Es gibt noch viele weitere Aspekte, die mit den Menschen und Methoden zu tun haben. Der Blogbeitrag hat leider schon den höchst zulässigen Umfang.
Mit meinem Beitrag will ich die positiven Erfahrungen mit festen Teams als Mittel zur Reduktion von Ressourcenkonflikten in der Produktentwicklung weitergeben, verbunden mit dem Hinweis auf die erforderliche Ergebnisoffenheit.
Zu Ihrem Tipp: wir haben wie beschrieben ein Team pro Produkt. In diesem Team erfolgen neue Entwicklungen, Support und alles, was zu dem jeweilgen Produkt gehört, natürlich in der Hand des PO. Damit ist der kurzfristige und mittelfristige Aspekt erledigt. Es bleiben nur die strategischen Aspekte: welche Teams brauchen wir für welche Produkte und wie viele Personen pro Team? Langfristig, nicht nur für ein paar Wochen.
Und ja, es geht um Menschen. In der Welt des PM heißt es aber nun mal Ressourcenmanagement. Deswegen macht es ja Sinn umzudenken, und ausgehend von den echten Personen in einem festen Team den selbst geschätzten Inhalt zu planen, als ständig zu versuchen, mit Wunschressourcen Luftschlösser zu bauen.
Beste Grüße
vor 1 Woche 4 Tagen Johann Strasser
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Bild-CAPTCHA
Geben Sie die Zeichen ein, die im Bild gezeigt werden.
Tech Link