Ausgebrannt – Mitarbeiterüberlastung verhindern
Deadline.
Klingt ein bisschen furchteinflößend, oder nicht? Wahrscheinlich ist das genau die Absicht, schließlich muss man sie einhalten – diese “tote Linie”. Manche Mitarbeiter eines Projekts fühlen sich ja regelrecht „tot“ gearbeitet: Zu viel Arbeit, zu viel Druck, zu viel Stress. Die Laune und die Produktivität sinken. Schlimmer: Ein Burn-out droht. Was können Sie dann tun?
Die ideale Lösung wäre natürlich, die Mitarbeiter zu entlasten, indem Sie zusätzliche Ressourcen einsetzen und die Arbeit auf diese verteilen. Im heutigen Blog-Beitrag wollen wir aber einmal das Problem von einer anderen Seite angehen. Wir stellen uns die Frage:
“Mit der Kapazität, die wir zur Verfügung haben – wie würde der aktuelle Endtermin aussehen?”
Wir gehen also ausnahmsweise nicht davon aus, eine definierte Deadline einhalten zu müssen. Stattdessen konzentrieren wir uns darauf, die Kapazitäten optimal und ohne Überlastung zu nutzen.
Beantworten Sie die Frage mit in-STEP BLUE
Eine Beispielsituation: Nehmen wir an, Sie haben 3 Arbeitspakete, deren Bearbeitung jeweils 8 Stunden dauert. Sie möchten diese auf einen Mitarbeiter verteilen, der mit einer Kapazität von 8 Stunden in dem Projekt eingesetzt ist. Zunächst einmal tun wir etwas sehr Böses:
Wir ignorieren einfach die Kapazität unseres Mitarbeiters und weisen ihm alle Arbeitspakete zu, die er parallel zueinander bearbeiten soll.
Dann würde seine Auslastung beispielweise folgendermaßen aussehen:
Die Ausgangslage sieht für den Mitarbeiter nicht gut aus.
Oha, im unteren Fenster ist etwas rot. Rot vermittelt uns immer, dass etwas gar nicht gut ist. Bastian Rosner ist eindeutig überlastet. In diesem Fall wussten wir ja zum Glück, was wir tun. Trotzdem müssen wir diese Situation schnell beheben:
Wir planen die Arbeitspakete nun so, dass der Mitarbeiter bei Laune und produktiv bleibt.
in-STEP BLUE bietet dafür die Funktion Kapazitätsabgleich. Wenden Sie diese einfach auf die Aktivität mit den Arbeitspaketen an…
Mit einem Rechtsklick auf die Aktivität gelangen Sie zur gewünschten Funktion.
… und voilà:
Als Ergebnis verteilen sich nun die Pakete auf dem Zeitstrahl.
Die Pakete verteilen sich auf dem Zeitstrahl jetzt so, dass die Kapazität des Mitarbeiters beachtet wird. Das bedeutet: Er bearbeitet sie nacheinander.
Eigentlich ist das ja gesunder Menschenverstand. Aber hier haben wir das mit einem sehr kleinen Beispiel durchgeführt. Sobald Sie größere Projekte umsetzen, mit mehreren Mitarbeitern und abweichenden Kapazitäten arbeiten, fällt diese Verteilung per Hand mit Sicherheit schwerer. Des Weiteren müssen Sie auch einen anderen Faktor berücksichtigen: Die Arbeitspakete haben unterschiedliche Prioritäten.
Kapazitätsabgleich mit Berücksichtigung der Prioritäten
Beispielweise müssen Sie auf jeden Fall Arbeitspaket A als erstes erledigen. Danach folgt Arbeitspaket C und anschließend Arbeitspaket B. Auch das ist kein Problem für in-STEP BLUE.
Geben Sie den Arbeitspaketen einfach Prioritäten und wenden Sie den Kapazitätsabgleich wie gehabt auf die Aktivität an. Schon sind diese gemäß ihrer Wichtigkeit und der Kapazität des Mitarbeiters auf dem Zeitstrahl verteilt (Priorität 3 entspricht der höchsten Priorität):
Und so sieht die Verteilung mit Berücksichtigung der Prioritäten aus.
Fazit
Der Kapazitätsabgleich bietet eine Möglichkeit, Mitarbeiterüberlastung zu verhindern. Natürlich stellt er kein Allheilmittel dar, schließlich müssen Sie in der Regel eine Deadline einhalten. Dennoch streben Sie ebenfalls danach, das Wohlbefinden und die Produktivität Ihrer Mitarbeiter so hoch wie möglich zu halten. Mit dieser Funktion erhalten Sie ein Mittel dafür.
Falls Sie dieser Blog-Beitrag neugierig gemacht hat, dann testen Sie doch in-STEP BLUE gleich einmal selbst – ganz kostenlos.
Das von mir beobachtete Problem ist eher, dass
1. von den Kunden über das (Produkt-)Management bis zur Entwicklungsleitung, zumindest im Bereich Automotive, unrealistische Zielvorgaben kommen, die nicht verhandelbar sind. Projektleiter, die es mit der PM-Ethik und der darin verankerten Forderung nach Wahrhaftigkeit ernst nehmen, werden ausgebremst oder ersetzt. Was dazu führt, dass weniger qualifizierte Mitarbeiter zu Projektleitern ernannt werden, die i.d.R. eher ad hoc Planung betreiben (mit agil hat das eher weniger zu tun) – und im Endeffekt die Dauer der vorgegebenen Gesamtentwicklungszeit überschritten wird. Dieses ist besonders in FuSi-relevanten Projekten der Fall.
2. Risiko-Management entweder nicht existiert oder nur oberflächlich durchgeführt wird.
Da helfen dann auch keine noch so guten Tool.
Dazu ein treffendes Zitat von Tom DeMarco “Risk management is project management for adults”
Hinzu kommt häufig eine mangelnde Prozess-Reife, oder die Fähigkeit, auf Grund der Vorgaben die definierte Entwicklungsprozesse einzuhalten.
Eine weiterer Effekt, der meines Wissens immer weniger betrachtet wird, ist, dass die Fehlerrate im gesamten Entwicklungsprozess und damit die Gesamt-Entwicklungszeit incl. Test und Fehlersuche, mit dem Grad der fortwährenden (Über-)Belastung überproportional ansteigt. Dazu gab es auch mal in den 90ern Studien, zwar auf anderen Gebieten, aber…
Leider wird das Thema wohl eher totgeschwiegen, da es zum Widerspruch des so beliebten Themas von AG- und zunehmend auch von AN-Verbänden bezüglich Verlängerung und “Flexibilisierung” der Arbeitszeiten ist…
Ich bin => 37 Jahre selbständiger Unternehmer und seit => 15 Jahre als Freelancer im Bereich Projekt-, FS- und Q-Management, sowie der HW/SW-Entwicklungsprozesse in der Automobil-Industrie unterwegs.
Gute Tools können auch hier helfen!
Wenn sie dem Verfasser der unrealistischen Zielvorgaben schnell und fundiert eine Aussage “auf Heller und Pfennig” darüber geben können, wie unrealistisch die Zielvorgaben genau sind, und was denn realistische wären, haben sie Argumente “für Erwachsene” um dem Projekt zu einem frühen Zeitpunkt wichtige Impulse mit zu geben. ;-)
Leider kenne ich eine andere Wirklichkeit.
Ich bin als Consultant naturgemäß selten bei den Unternehmen, wo es funktioniert und Risk-Management (z.B. zur Erfüllung der Anforderungen gemäß KonTraG) auch in der Produktentwicklung gelebt wird.
Tools, die neben Planung und Tracking auch Analyse, Simulation und Forecast in Kosten und Auslastung erlauben, gibt es schon lange, daran liegt es also nicht.
Meine Tool-Erfahrung in Projekten umfasst z.B.:
1991 – 1996: SuperProject (MSWin-3.1 bis MSWin-NT) – zu der Zeit erheblich besser als MS-Projekt (gab es auch in einer MPM-Version unter UNIX).
1998 – 2000: Planta PPMS – damals eines der leistungsfähigsten konfigurierbaren Multiprojekt Management Tools (sowohl Clients als auch Server waren verfügbar unter HP-UX (UNIX), MSWin-NT und Linux).
seit 2001: immer mal wieder MS-Project, eher selten RPLAN – und div. ALM-Tools und freie, bzw. Open Source Tools wie z.B. ProjeQtOr , Agilefant etc.
Die in-STEP-BLUE in der Personal Version habe ich immer mal wieder installiert. Ich finde das Konzept gut, habe es dann aber immer schnell wieder deinstalliert, da es mir einfach zu “fett” war (und weil ich lieber mit Linux arbeite. Nur bei Kunden mit MSWin. Wenn es denn sein muss…). Und in der Personal-Version Oracle-DB? Muss dass sein? Da gibt es schlankere DBM’s.