Ressourcen-Glättung in Monday – Fred Baker – NUR FÜR MITGLIEDER

[00:00:00] Mhm.

Galen: Hallo zusammen, willkommen zu unserer praktischen Session zur Nutzung von Monday, um Projektteam-Ressourcen zu planen, auszugleichen und zu verwalten. Für alle, die uns noch nicht kennen: Ich bin Galen und das ist der zertifizierte Monday-Berater Fred Baker.

Fred, danke, dass du heute dabei bist.

Fred: Danke, Galen.

Galen: Alles klar. Dann lass uns ins Thema Ressourcenmanagement einsteigen. Ich habe hier ein kleines Szenario. Ich weiß, du hast deine Testumgebung aufgesetzt. Ich möchte also das Szenario skizzieren. Also: Ich leite ein Team von Projektmanager:innen in einer kleinen Digitalagentur.

Wir haben ein paar PMs, die mehrere Projekte gleichzeitig steuern, unterschiedlich groß, zeitlich unterschiedlich und unterschiedlich komplex. Das Wichtigste: Alle Projekte teilen sich die Teammitglieder aus der Entwicklungs- und Kreativabteilung. Und ich möchte wissen – wie kann mein PM-Team in so einem Fall die Ressourcen für ihre Projekte auf Monday am besten prognostizieren? Und [00:01:00] im Speziellen: Woher erkenne ich, ob wir jemanden überbelegt haben? Und wenn eine Überbelegung vorliegt, wie kann ich Monday nutzen, um diese Ressource so zu nivellieren, dass sie nicht überlastet ist? Genau, das ist das Szenario, das ich heute mit dir durchgehen wollte.

Ich dachte, wir fangen mit den Grundlagen an. Zeigst du mir kurz, wie du Ressourcen auf ein paar Projekte zuteilst? Danach gehen wir in die Problemsituation, wo plötzlich jemand 12, 16 Stunden Tage arbeitet – Ist das okay?

Fred: Ja, ja, voll. Das ist ein gutes Szenario. Und als Erstes: Das was ich heute zeige, ist eine von 7.000 Möglichkeiten. Das Coole an Monday, und ich sage das immer meinen Kunden: Monday ist wie eine Kiste voller Legosteine.

Man kann bauen, was man will. Es gibt viele verschiedene Wege ein Ziel zu erreichen. Die Schwierigkeiten kommen oft, weil Leute versuchen, Monday an ihren Prozess anzupassen oder ihren Prozess an Monday [00:02:00]. Es gibt ein paar coole Tools. Das Workload-Widget, das ich hier geöffnet habe – oder besser gesagt, das ist das Workload-Widget.

Kurz zur Erklärung: Dieses Workload-Widget ist eine der neueren Funktionen, die letztes Jahr eingeführt wurden. Es ist wahrscheinlich die beste Möglichkeit, einen Überblick über die Kapazitäten zu bekommen. Hier im Beispiel: In Woche 25 bin ich bei 61 Prozent Kapazität. Man kann Projekte stapeln. Ich zeige gleich mehr dazu. So kann man Projekte stapeln und sieht, okay, Fred ist auf vielen Projekten gleichzeitig. Bei 93 Prozent wird es eng. Wenn man noch mehr auflädt, sieht man, wie es ins Rote geht. Visuell erkennt man, wer überlastet oder unterlastet ist – zum Beispiel in Woche 29.

Das Widget ist mit einem Projektboard verknüpft. Hier ist das Projektboard [00:03:00]. Das kann das High-Level-Projektboard sein – also eine Übersicht auf Portfoliolevel mit allen Projekten und Zeilen für jedes einzelne.

Vielleicht sind sie in unterschiedlichen Gruppen. Typischerweise schaut das gesamte Team oder zumindest PMs auf diese High-Level-Übersicht. Darüber hinaus gibt es noch das Detail-Board mit allen Arbeitsschritten und Details. Zum Beispiel, oben stehen alle Projekte. Und dann gibt es einen eigenen Bereich für ein bestimmtes Webdesign-Projekt eines Großkunden – das ist mit dem High-Level-Board verbunden.

Dort, im Detail-Board, steht alles wie Kick-Off, Ressourcen sammeln, Wireframe, Review usw. Im High-Level-Board nicht, dort steht nur: Wir bauen eine Webseite für die DPM, Galen ist der:die Owner:in, Fred ist Projektleiter und das Team ist zugeordnet. Das hier [00:04:00] ist ein High-Level-Board, hier sind alle Projekte. Wir fügen ein weiteres Projekt hinzu, nennen es DPM und tragen mich ein. Ich habe viele verschiedene Beispiele vorbereitet. Eins davon ist der Projekt-Kickoff. Wann startet das Projekt? Ich stelle das mal auf den 26., damit es diese Woche angezeigt wird. Man kann ein fixes Datum nehmen oder einen Zeitraum definieren.

Sagen wir, das läuft vom 26. bis zum 31. Juli. Das ist wahrscheinlich zu kurz für eine echte Webseite.

Galen: Arbeitest schnell. Hmm. Mm

Fred: Ja, ja. Sagen wir, das Projekt benötigt 100 Stunden, einfach als Beispiel. Das ist hier die Gesamtstundenzahl des Projekts, einfach eine Spalte, die ich definiert habe.

Das ist eine Zahlen-Spalte, aktuell auf Stunden eingestellt – man kann hier alles eintragen. Unten steht die Summierung – [00:05:00] also zum Beispiel: Gesamtprojektstunden? 375 Stunden in Projekten. Dieser Wert gibt die Gesamtverpflichtung an, weitere Einblicke bieten die Projektwochen. Ich habe diese Spalte hier summiert. Das ist die Gesamtsumme der Wochen, nicht Start-Stopp, sondern einfach die aufsummierten Wochen. Die Timeline gibt Start und Ende an – sagen wir hier sechs Wochen. Sieht man unten ebenfalls in der Summe. Bei der Dienstleistungsart habe ich verschiedene Projekte wie SEO, Webentwicklung, etc. Es bietet filterbare Ansichten und Sortierungsmöglichkeiten.

Zur Zeiterfassung gibt es unterschiedliche Varianten [00:06:00]. Hier eine Zeiterfassungsspalte, die Start- und Stoppzeiten festhält, oder man trägt sie manuell ein – zum Beispiel am 27. von 9 Uhr bis 10:34 Uhr: Fred hat daran gearbeitet. Das ergibt eine Stunde und 34 Minuten.

Das spielt bei der weiteren Berechnung eine Rolle. Nun habe ich weitere Spalten vorbereitet – etwa den wöchentlichen Soll-Verbrauch („assigned weekly burn“). Die Idee: 100 Stunden auf 10 Wochen aufteilen, macht 10 Stunden pro Woche. Ist das Projekt zu zweit, trägt man das hier ein. Beim DPM-Projekt ergibt sich daraus automatisch sechs Stunden pro Woche (100 Stunden auf sechs Wochen). Das wird automatisch berechnet.

Dadurch ergibt sich bei bereits verbrauchter Zeit – beispielsweise habe ich 1:34 Stunden eingesetzt – ein Rest von 98,43 Stunden. Diese Spalten stellen automatische Berechnungen dar. Sie sind flexibel anpassbar. Es gibt [00:07:00] den geplanten wöchentlichen Verbrauch, den tatsächlichen Verbrauch („actual burn“), und pro Person aufgeteilt.

Beispiel: DPM 16,7 Stunden. Ein anderes Projekt hat fünf statt zehn, weil hier zwei Personen zugewiesen sind – mich und George, macht jeweils fünf Stunden pro Person. Dieses Prinzip lässt sich individuell ausbauen.

Beim tatsächlichen wöchentlichen Verbrauch nutzt eine Formel die bisher erfassten Stunden geteilt durch die vergangenen Wochen. So sieht man, wie viel tatsächlich bisher gearbeitet wurde. Diese Spalten funktionieren meist automatisch – verbleibende Wochen, um im Zeitplan zu bleiben, werden angezeigt. Hat ein Projekt noch 36 Reststunden und keine weitere Woche, müssten 36 Stunden diese Woche erledigt werden – das ist meist unrealistisch, es sei denn, mehrere Personen arbeiten gleichzeitig am Projekt.

Weitere Spalten fassen geplante und tatsächliche Verbräuche bis heute zusammen, sodass man den Fortschritt vergleichen kann. All das [00:08:00] fließt in die Tabelle und anschließend ins Workload-Widget ein. Dort werden als Basis die Projektstunden und der Zeitraum genutzt. Das Workload-Widget zieht hier die wöchentlich zugewiesenen Stunden sowie die Timeline ein.

Hier sieht man dann die Überlastung in Woche 26, 28, 29, ausgelöst durch das DPM-Projekt. Überbelegung kann durch Verschiebung des Projekts auf eine ruhigere Zeit gelöst werden. Einfach die Timeline verändern. Oder weitere Personen assignen, zum Beispiel George.

So wird die Belastung auf Fred und George verteilt und die Überbelegung entschärft. Durch Verschieben auf Woche 29 sinkt die Arbeitsbelastung weiter.

Im Workload-View lassen sich die Projekte nach Person ein- und ausklappen, sodass die Auslastung personenzentriert betrachtet werden kann. Bei Überlastung kann das Projekt direkt in der Ansicht angepasst werden – hier hilft die Kartenansicht (neue Funktion), in der alle Felder direkt editierbar sind, inklusive der Stunden und Zeithorizonte.

Galen: Was mir daran gefällt: Du hast einige eigene Felder, z.B. für Stundenangabe und deren Zuteilung, erstellt, ergänzt durch Formeln für Burn und Ressourcenzuordnung.[00:13:00] Dann visualisiert Monday das Ganze sehr plakativ im Workload-Tab, wo man Ressourcenverteilungen simulieren kann. Änderungen lassen sich direkt vornehmen, etwa weil Arbeiten schneller oder langsamer laufen. Das erleichtert dann auch das Gespräch mit Kund:innen oder Sponsor:innen: Man kann Optionen wie das Hinzufügen von George vorschlagen oder aufzeigen, ab wann jemand verfügbar ist.

Der Benefit: Intern kann man sogar alle Projekte transparenter darstellen und visualisieren: „Rote Punkte sind schlecht, Blaue in Ordnung“.

Fred: Genau, und man sieht auch, wie nah man am Limit ist. Wenn man sagt, 70 % wäre die Zielauslastung, kann man Aufgaben anpassen. Durch Forecasting lassen sich viele Probleme bereits im Voraus vermeiden. Die Ansicht funktioniert wie ein personalisiertes Gantt-Diagramm. Es gibt das klassische Gantt-Diagramm für Gesamtprojekte, aber im Workload-Widget sieht man personalisiert, wie viele Projekte zum Beispiel Galen in den kommenden sieben Wochen hat. Die Ansicht ist beliebig weit ausrollbar (Monate, Jahre) und gibt einen schnellen Einblick. Sie erlaubt frühzeitige Umplanungen und Priorisierung.

Weil es so visuell ist, eignet es sich besonders gut für die Kommunikation mit Führungsebene, die oft wenig Zeit für Details aufbringen kann. Man muss also keine Zahlenkolonnen präsentieren, sondern zeigt einfach: „Sechs überlappende Projekte – ich empfehle, dieses zu verschieben.“ Die Entscheidung ist dann sofort da.[00:15:00]

Galen: Ich habe noch eine Frage zur Granularität: Du hast erklärt, wie man z.B. einen Designer nur für ein paar Tage insprojekt holt – aktuell sind die Spalten aber auf geplante Burn-Rates pro Woche ausgelegt. Wie würdest du jemanden flexibel für einzelne Zeiträume im Projekt zuordnen?

Fred: Genau, mein Beispiel arbeitet so, aber es gibt viele andere Wege: Man kann einen eigenen Zeitraum auf Projektebene anlegen und innerhalb dessen für bestimmte Aufgaben Unterelemente mit eigenen Zeitabschnitten („sub item timeline“) definieren – zum Beispiel für den Designer vom 8. bis 18. Juni. So sieht man im Workload-Widget, wann welche Person konkret gebraucht wird.

In Monday kann man zudem Zusammenfassungen von Unterelementen aktivieren, sodass der Gesamtzeitraum der Subitems aggregiert angezeigt wird. Zwar gibt es bei Automatisierungen noch gewisse Einschränkungen mit Spiegelspalten, doch die Zusammenfassung und Ansicht funktioniert. Für unterschiedliche Rollen (z.B. Projektmanager:in, Designer:in) können so separate Zeitabschnitte abgebildet werden.

Galen: Das Prinzip kenne ich noch aus der Agentur. Dort wurde extrem granular geplant, also Bottom-Up – man plant für jede Rolle explizit Zeiträume. Heute wird, v.a. in agilen oder internen Projekten, häufig Top-Down geplant: „Ich brauche vier Leute, acht Wochen lang, zu 50 % ihrer Zeit“. Dafür eignet sich das System genauso.

Fred: Monday ist wie eine Kiste Legosteine – wenn man die Prozesse kennt, kann man zu 90 % alles abbilden. Falls doch etwas fehlt, gibt es oft Apps oder Automatisierungen per make.com. Typischerweise gilt: Wer einen anderen Prozess hat, kann ihn meist auch in Monday abbilden. Gerade diese Vielfalt und das Problemlösen sind das, was ich an dieser Arbeit mag – keine zwei Umsetzungen sind je gleich.[00:21:00]

Gerade die Flexibilität macht Tools wie Monday gegenüber früheren Marktführern wie Microsoft Project so attraktiv: keine teure Lizenzierung, geringe Lernkurve. Man kann Monday in wenigen Stunden lernen. Wichtig ist aber, die eigenen Prozesse mit den Funktionen von Monday abzustimmen – da scheitern oft Projekte.

Galen: Kleine schnelle Frage, bevor wir schließen: Die Entwicklung auf Monday ist schnell, Features kommen hinzu. Ist dir schon einmal eine eurer komplexen Lösungen durch ein Update zerbrochen und du musstest alles umstellen?

Fred: Tatsächlich ist das Gegenteil der Fall: Monday ist sehr darauf bedacht, nichts kaputtzumachen. Es kann aber passieren, dass man viel Aufwand für eine Portfolio-Ansicht betrieben und dann kurz darauf ein offizielles Portfoliotool auf Enterprise-Level bekommt, das alles vereinfacht. Aber sie zerstören nie existierende Strukturen. Im Gegenteil: Man freut sich über Komfort, auch wenn es manchmal ein paar Wochen zu spät kommt.[00:23:00]

Galen: Na immerhin hört das Produktteam hin, oder?

Fred: Absolut! Als Partner werden wir oft vorab informiert. Kommunikation läuft gut, und ich hatte nie einen Fall, wo irgendwas durch ein Update zerstört würde. Interessant ist die Entwicklung neuer Produkte: Ursprünglich ein Work-Management-Tool, bauen Kunden selbstständig CRMs auf und Monday legt dann eine spezialisierte CRM-Plattform nach. Auch diese war zum Start noch unausgereift, hat in einem Jahr aber aufgeschlossen und ist keineswegs so komplex wie Salesforce, dafür schnell zu erlernen und sehr leistungsfähig. Funktionen wie E-Mail, Aktivitätsverfolgung, Pipeline, Automatisierungen – alles inzwischen voll integrierbar. Für kleine Unternehmen ist es inzwischen top. Außerdem gibt es eigene Produkte für Dev-Teams – vergleichbar mit Jira – und für den Servicebereich (Tickets, Supportanfragen), aktuell noch in Beta. Alles ist leicht zu lernen und schnell implementiert.

Man kann ein komplexes System einrichten und das Team in einem Wochenende einarbeiten.

Fred: Entschuldigung, Nachwirkung einer Erkältung. [00:26:00] Ein weiteres Feature: Das Gantt-Diagramm.

Galen: Oh ja.

Fred: (Technikprobleme) Die Gantt-Ansichten kann man nach Belieben für Gesamtprojekte oder Einzelprojekte einrichten. Sie bieten eine Übersicht aller Projekte, Zeiträume, Start- und Endtermine, lassen sich mit Drag&Drop verschieben, zeigen Abhängigkeiten (Dependencies), z.B. dass Projekt Z von Projekt D abhängt. Man kann sie beliebig anpassen und sieht sie nach Projekt, Zuweisung, Dienstleistung etc. gruppiert.

Am Anfang hatte ich Service-Typen (Webseite, individuelles Workflow-Projekt usw.) gezeigt. So lässt sich auf einen Blick erkennen, wann wie viele Projekte einer Kategorie laufen. Daraus können frühzeitig Umplanungen und Entscheidungen abgeleitet werden, bevor Probleme entstehen. Zusätzlich stehen Dashboards zur Verfügung, mit weiteren Auswertungen, z.B. verbleibende Stunden, Durchschnitts-Burnrate, Projektarten usw.[00:29:00]

Galen: Diese Ansichten sind klasse. Gerade auch, weil man unterschiedliche Sichten für verschiedene Rollen (Projektleitung, Ressourcenmanager, GF) bereitstellen kann. Für Gespräche mit Sponsoren reicht oft schon die Übersicht.

Fred: Noch ein Tipp: Wir dokumentieren die Boards direkt in Monday, inkl. aller Ansichten, Spalten, zugehöriger Formeln und Erläuterungen. Ein guter Standard: Als SOP steht die Doku direkt im Kontext, z.B. auch für Projektnotizen, Aufgaben, Statusupdates mit Erwähnungen. Das sorgt für Transparenz und Organisation.

Galen: Sehr cool, alles aus einer Hand.

Fred: Ja,

Galen: Fred, vielen herzlichen Dank für die ausführliche Einführung in das Ressourcenmanagement, Burn-Downs, Gantt-Charts und vor allem für deine Insights zu Monday.

Mhm.