Deadlines
Wir kennen sie alle - die “Deadline”. Bis zu einem gewissen Datum und Uhrzeit gilt es eine Leistung abzuliefern. Gerade beim Schreiben dieses Blogs ist mir der Begriff nochmals ins Auge gesprungen… “Deadline”. Eigentlich ein ziemlich heftiger Begriff, wenn man den wörtlich übersetzt.
Und dennoch sind diese Termine wichtig - oder nicht? Nach neusten Umfragen (gemäss dem Harvard Business Review) sind knapp 50% der Deadlines gar nicht wirklich so fix bzw. wichtig. Viele der Deadlines werden fast schon zufällig gesetzt bzw. deren nicht Einhaltung hat keine negativen Konsequenzen für Menschen und Firma. Auf der anderen Seite ist leider aber auch gezeigt worden, welchen doch heftigen Einfluss Deadlines auf Kreativität, Effektivität und Stress haben - bedauerlicherweise haben Deadlines auf alle diese Faktoren einen negativen Einfluss. Viel öfter sollten wir entsprechend Deadlines kritisch hinterfragen oder aber wenn wir (frühzeitig) sehen, dass die Zeit nicht reichen wird, eine entsprechende Verlängerung bzw. Anpassung der Deadline anhalten. Doch offenbar wird dies sehr wenig angewendet - wieso?
Inkompetenz: Viele Mitarbeiter haben Angst, dass eine Anpassung der Deadline sie als eher inkompetent erscheinen lässt. Aus meiner Erfahrung ist dem nicht so, vor allem dann nicht, wenn frühzeitig (und nicht jedes Mal) die Deadline diskutiert und angepasst wird. Im Gegenteil, das (öftere) Reissen einer Deadline scheint mir da viel eher ein Thema für die professionelle Weiterentwicklung zu sein.
Geschwindigkeit gegenüber Qualität: Oft wird von Mitarbeitern erwartet, dass die Geschwindigkeit aus dem Management viel höher geschätzt wird als Qualität. Damit wird versucht bei der Qualität Abstriche zu machen, um eine Deadline zu halten - bis hin zu fast “lächerlichen Deliverables”, Hauptsache “on time”. Auch hier würde ich für das Gegenteil Werbung machen wollen. Viel zu oft wird “schlechte Qualität” akzeptiert und viel zu oft zeigt sich, dass auf schlechter Qualität nicht gebaut werden kann. Aus verschiedenen agilen Delivery-Modellen kennen wir auch das Prinzip “only quality scales”. Dies gilt (leider) auch für nicht-Software-Entwicklung.
Wir sollten lernen, mit Deadlines viel bewusster umzugehen und diese vermutlich auch gezielter (d.h. weniger häufig) einzusetzen. Vielmehr könnten wir uns agilen Methoden bedienen und versuchen, mit mehr Fokus an weniger Dingen zu arbeiten. Auch ein aktives gemeinsames Arbeiten und aushelfen um rascher (und oft auch in höherer Qualität und mit mehr Freude) zum Ziel zu kommen wird noch viel zu wenig genutzt. Vielleicht ein möglicher Vorsatz oder Versuch für das noch junge Jahr.